Re: libc/libsys split coming soon

[Steffen Nurpmeso]

Brooks Davis wrote in
 :
 |TL;DR: The implementation of system calls is moving to a seperate
 |library (libsys).  No changes are required to existing software (except
 |to ensure that libsys is present when building custom disk images).
 ...
[]
 |This change serves three primary purposes:
 |  1. It's easier to completely replace system call implementations for
 | tracing or compartmentalization purposes.
 |  2. It simplifies the implementation of restrictions on system calls such
 | as those implemented by OpenBSD's msyscall(2)
 | (https://man.openbsd.org/msyscall.2).
 |  3. It allows language runtimes to link with libsys for system call
 | implementations without requiring libc.

That is so cool.  Much love for 3.!

  ..
 |After nearly a decade of intermittent work, I'm about to land a series
 |of patches which moves system calls, vdso support, and libc's parsing of
 |the ELF auxiliary argument vector into a separate library (libsys).  I
 |plan to do this early next week (February 5th).

Congratulations.  Thanks for all your efforts.  All FreeBSD!
Oh i had a mail in the queue for another list, and whereas
i admire all efforts, how i love this one!

Thank you, and nice weekend i wish from Germany!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: noatime on ufs2

[Steffen Nurpmeso]

Chris wrote in
 <9155214edb61b1bc3bad3bc96f96e...@bsdforge.com>:
 ...
 |I haven't seen anything in this thread that wouldn't be better placed in 
 |tuning(7)
 |or tunefs(8).
 |
 |* Silicon disks fail without warning
 |   tapes did as well. Unless you're working with punch cards please \
 |   implement 
 |an
 |   effective backup strategy -- snapshot(8)
 |* writing to my disk takes a long time
 |   see tuning(7) or tunefs(8)
 |* atime doesn't work like "realtime" does on Linux
 |   use Linux instead or add the ability to also use realtime

'Seems to me from a "git grep" that ZFS supports relatime.
The number of atime matches for ufs is not that horrifying either.
Sure the daily disc crawler touches anything, as was said, so
relatime does not help once.  For that the crawlers (locate,
whatis, whatever) would need to use O_NOATIME, but FreeBSD says
/* XXX LINUX_O_NOATIME: unable to be easily implemented. */, so
that sucks.  Maybe then noatime is the better way out.
Having said that, i have never tried it, whether nullfs overmount
for the crawlers would get over that.  Would be a good thing i'd
say, for jailed servers or what.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: noatime on ufs2

[Steffen Nurpmeso]

Hallo

Olivier Certner wrote in
 <2367131.USjQqFH40Q@ravel>:
 |> I would not exactly call this a gimmick.
 |
 |I wish I hadn't used that term since it attracts too much attention \
 |on itself, making people forget it was part of a sentence that was \
 |quite balanced and seemingly altering their judgement.

Sure.

 |I think you're confusing the need and the mechanism (or implementation). \
 | In substance, we (Robert and I) were talking about turning "atime" \
 |off *by default*.  What I tried to convey is that the needs that justify \
 |this mechanism are those of a minority in my view (and I'm certainly \
 |not opposed to be educated if it's not true), and additionally that \

It is not true.

 |the "atime" mechanism addresses these needs poorly.

I hate atime.  In the past i always turned it off on most
partitions, under FreeBSD.  If i recall correctly reading FreeBSD
documentation (which was my main UNIX learning factor; including
the /usr/share stuff that i much admired) ignited that feeling of
waste of prescious time (on a Cyrix 166+ with 49 MB RAM and a, uh,
maybe 200 or ~250 MB hard disk -- i have forgotten!, i seem to
recall about ~300 or 330 MB/sec memory and ~30 MB/sec cached disk
performance (Linux), and i am pretty sure about the less than
5 MB/sec otherwise).  I think i always used noatime by this time,
on FreeBSD (whenever i read out the old IDE disks i hopefully will
discover also that).  I seem to recall "birth time" did not exist.

Now it must be said that today i do not care that much.  I do not
even have a special partition for /var no more (on the laptop, at
least).  The memory and that incredible NVME disk are so
unbelievable fast that i would not even have dreamed of it.
Whereas i still do not truly look at access time myself
consciously, i let it happen.  (Unless it does not make sense; for
example /x/music -- greetings to Kaiserslautern! -- is actually
living on multiple disks, and (backup) sticks (well those:
actually all), and it is only hm populated on one master (at the
moment not NFS shared, but maybe later).  That is then cloned
everywhere.  So.  Hm.

Ie, twenty and more years ago i surely would have agreed in that
i turn(ed) off atime, but today, .. i for myself use relatime
here.  Also: as a general by-default policy: i do not think so.
(But i am only a user.)

 |With that in mind, developing "relatime" to try to alleviate the shortco\
 |mings of "atime" has a low ROI: It doesn't add the crucial functionality \
 |most needs (like auditing) would require and doesn't even really address \
 |the I/O shortcomings in some frequent scenarios.  Deactivating "atime", \

Aha?  Which?  Today??  Well i mean writing must happen.

 |by contrast, doesn't require any development, suppresses all I/O overhead, \
 |and doesn't suppress any functionality for an overwhelming majority \
 |of uses (at least, this is my current view; other inputs welcome).

Not mines.

 |I did not say that the needs themselves are a gimmick, e.g., having \
 |a notification of new mail (although, in this case, frankly, I'm on \
 |the verge of arguing it).  Simply, relying on "atime" (or "relatime") \

Actually it is often distress, as i work on multiple terminals,
and the reported "new" mail has often already worked when the
message appears. :)

 |for this is unnecessary, as you must have understood reading the various \
 |previous answers in this thread.
 |
 |> On Linux mount(8) from https://github.com/karelzak/util-linux says
 |> 
 |>relatime
 |>Update inode access times relative to modify or change time. \
 |>Access
 |>time is only updated if the previous access time was earlier than
 |>or equal to the current modify or change time. (Similar to \
 |>noatime,
 |>but it doesn’t break mutt(1) or other applications that need to
 |>know if a file has been read since the last time it was modified)
 |> 
 |> and this is what i use, except for some noatime mount points
 |> (/x/doc, /x/music, /x/pub, to be exact).
 |
 |It seems that the other answers (mostly those of Robert IIRC) have \
 |shown that this manpage text isn't up-to-date with current practices.

Ah ja?

 |Which need(s) of yours are you trying to address exactly by using "relat\
 |ime"?

I address that i do not turn off atime.  Actually i do not, but
get that automatically.  But would otherwise.  I only set noatime
at times.  Some utitilities even actively restore access time
after they are doing their thing, in a standardized way.

 |Thanks and regards.

I think i want to day that i would not like it if a global policy
enforces noatime.  Especially since the necessary changes are
small, and could even be automatized easily.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: git repo port issues?

[Steffen Nurpmeso]

Bakul Shah wrote in
 <46c8698a-a004-4b5f-9107-6d9fd3685...@iitbombay.org>:
 |On Jan 3, 2024, at 11:22 AM, Brooks Davis  wrote:
 |> 
 |> Nothing about dates is centralized in git, but some server side checks
 |> could be implemented on CommitDate.  IMO we should require that
 |> CommitDate be >= the previous one and less than "now".
 |
 |Given that git commit objects form a DAG, I don't see how you can
 |impose linearity.

On the other hand, if a project agrees, and for example locks the
main branch, any merging or plain committing to it can enforce
commit-amending including date-updates etc, as well as expanding
$CVS and @# SCCS format strings (i think by then this discussion
came up in the past, and Warner Losh rejected such a thing, if
i recall correctly ... but may not).

 --End of <46c8698a-a004-4b5f-9107-6d9fd3685...@iitbombay.org>

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Freebsd 14+ -- tcsh incompatible with terminfo

[Steffen Nurpmeso]

Hello Thomas Dickey.

Thomas Dickey wrote in
 :
 |On Thu, Nov 02, 2023 at 06:58:55PM +0100, Steffen Nurpmeso wrote:
 |> I do understand that a bit.  Other than that plain termcap was so
 |> small and i would assume essentially unchanged for decades, that
 |> i do not.  Termcap entries, yes.  I could imagine vt220, xterm,
 |> screen-256color, and take one of st-256color, whatever KDE and
 |> GNOME terminal, and rxvt-unicode.  Makes seven.  Likely
 |> automatically extractable via "infocmp -C" of Dickey's terminfo.
 |> 
 |> Let's just try that:
 |> 
 |>   $ rm .TCAP;\
 |> for f in vt220 xterm screen-256color st-256color \
 |> rxvt-256color gnome-256color konsole-256color; do \
 |>   infocmp -C $f >> .TCAP;\
 |> done;\
 |> ls -l .TCAP
 |>   -rw-r- 1 steffen steffen 7145 Nov  2 18:40 .TCAP
 |
 |There's more data in termcap than that (which some people would like \
 |to use).

You know the entire thread is moot as i think bapt@ has thrown
away the BSD termcap years ago, if i recall correctly (i think
i spoke up by then).
I only answered because of the "great it is gone" thing.

 |And there's additional data for terminfo -- again, some want it.
 |
 |man infocmp:
 |
 |   For best results when converting to termcap format, you should \
 |   use both
 |   -C  and  -r.   Normally a termcap description is limited to \
 |   1023 bytes.

And i do not know whether BSD termcap can work with larger ones.

 |   infocmp trims away less essential parts to make it  fit.   If \
 |you  are
 |   converting to one of the (rare) termcap implementations which \
 |   accept an
 |   unlimited size of termcap, you may want to add the -T option. \

Yes.  I heard about the limit.

 |More of‐
 |   ten  however, you must help the termcap implementation, and \
 |   trim excess
 |   whitespace (use the -0 option for that).
 |
 |(-T is appropriate here - ymmv)
 |
 |With -C alone, I get
 |-rw--- 1 tom users 7315 Nov  2 21:02 .TCAP
 |
 |With -CrT,
 |-rw--- 1 tom users 14390 Nov  2 21:02 .TCAP
 |
 |For terminfo, no options
 |-rw--- 1 tom users 16027 Nov  2 21:03 .TCAP
 |
 |For terminfo with -x
 |-rw--- 1 tom users 19533 Nov  2 21:03 .TCAP

One would have to add that OpenGL-accelerated terminal (allacritty
or so) at least, too.

I am not speaking against your ncurses and the work and effort you
put there, you know, i spent about 30% of my live in front of
a st/tmux combination, and i would think tmux uses more and more
of the optimizations, and improvements of yours.  For example
i saw fly by an OpenBSD commit where tmux started using tparm_s or
what its name was.  They imported some ncurses snapshot only for
it (in the end), if i got that right.  The function is not on my
box -- and i do not "track" ncurses no more because i will likely
never reach a point where i need it as such.

I was speaking pro BSD termcap.  I do not know whether even the
omnipresent readline library would need anything more than the
absolute basics.  I know my mailer can, .. it can even without
termcap, .. at least a little bit, and very expensive.  (I have
not tried that out for years so.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Directory 1002/ missing from /var/run/user/

[Steffen Nurpmeso]

Jan Beich wrote in
 :
 |Graham Perrin  writes:
 |
 |> What normally takes care of creation of the numbered directories?
 |
 |/var/run/user/ (or /run/user/ on Linux with systemd) is a common prefix

It seems to me the latter is just a more modern variant, which
slowly enters non-systemd systems like AlpineLinux (and CRUX Linux
fwiw) including a (likely temporary) symbolic link

  lrwxrwxrwx1 root root  4 May 11 17:59 /var/run -> /run/

 |for XDG_RUNTIME_DIR, a standardized place for user-owned unix(4) sockets.
 |Fallbacks are either app-specific or shared (e.g., CVE-2020-25697).
 |
 |/var/run/user/ is managed by sysutils/consolekit2 or sysutils/pam_xdg.
 |In consolekit2 case the directory is created (contents destroyed if
 |already exists) on the first session of the specific UID either via
 |C API, DBus API, ck-launch-session(1) or pam_ck_connector(8) and removed
 |when the last session terminates. In pam_xdg case the directory is
 |created but not removed unless track_sessions is set.

 |> A few hours ago, it was unexpectedly missing:
 |
 |Probably auto-removed by consolekit2 either due to logout or dbus restart.
 |
 |> I recreated the directory.
 |
 |Can be automated via PAM e.g.,
 |
 |  # pkg install consolekit2
 |  # echo "session optional pam_ck_connector.so nox11" >>/etc/pam.d/system
 |  # service dbus onestart
 |  $ exit # log out on VT console to re-trigger PAM
 |
 |or
 |
 |  # pkg install pam_xdg
 |  # echo "session optional pam_xdg.so notroot runtime" >>/etc/pam.d/system
 |  $ exit # log out on VT console to re-trigger PAM

The reason for the explicit "track_sessions" is mentioned in the manual

  CAVEATS
 On Unix systems any “daemonized” program or script is reparented to the
 program running with PID 1, most likely leaving the PAM user session
 without PAM recognizing this.  Yet careless such code may hold or expect
 availability of resources of the session it just left, truly performing
 cleanup when sessions end seems thus unwise.  Since so many PAM modules
 do support session tracking and cleanup pam_xdg.so readded optional sup‐
 port for this.

I reiterate (from freebsd-hackers or -devel from some time ago)
that it is a problem of PAM "session"s that they are not,
actually, sessions.  login and such should be extended to make use
of the "reaper" feature so that sessions are safe to use.
Unfortunately in the Linux world they all throw anything onto
systemd, like you say, instead of iterating the other tools.

Like written the "XDG Base Directory Specification" desires the
impossible for XDG_RUNTIME_DIR (except for systemd of the
Poettering who took part in the 2010 v0.7 of that standard).

 --End of 

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|~~
|..and in spring, hear David Leonard sing..
|
|The black bear,  The black bear,
|blithely holds his own   holds himself at leisure
|beating it, up and down  tossing over his ups and downs with pleasure
|~~
|Farewell, dear collar bear

Re: Dragonfly Mail Agent (dma) in the base system

[Steffen Nurpmeso]

Ed Maste wrote in
 :
 |The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA)
 |which accepts mail from a local Mail User Agent (MUA) and delivers it
 |locally or to a smarthost for delivery. dma does not accept inbound
 |mail (i.e., it does not listen on port 25) and is not intended to
 |provide the same functionality as a full MTA like postfix or sendmail.
 |It is intended for use cases such as delivering cron(8) mail.
 |
 |Since 2014 we have a copy of dma in the base system available as an
 |optional component, enabled via the WITH_DMAGENT src.conf knob.
 |
 |I am interested in determining whether dma is a viable minimal base
 |system MTA, and if not what gaps remain. If you have enabled DMA on
 |your systems (or are willing to give it a try) and have any feedback
 |or are aware of issues please follow up or submit a PR as appropriate.

I used it for years and even maintained a package for a Linux
distribution (CRUX) until last October, and i think maybe even
AlpineLinux before?  I know for sure i maintained a package with
Author: emaste
Date: Fri Oct 27 20:21:09 2017
New Revision: 325047
URL: https://svnweb.freebsd.org/changeset/base/325047
patched on top of it for years.
Very basic usage, only local delivery.

But i plan to readd the package as part of the postfix-lmdb
package i maintain, because, you know, postfix's sendmail(1) and
local deliveries need read access to the postfix configuration,
and as part of my effort to totally box (unshare + overlay mount)
all my daemons which cross ingress/egress (and place their config
under /root/hosts/$HOSTNAME), it's need to access
/etc/postfix-lmdb is in the way.
(The plan is thus to make dma "part of this package" and make it
provide /usr/sbin/sendmail, configured to proxy to local SMTP,
where postfix then regulary sits.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: PAM module for loading ZFS keys on login

[Steffen Nurpmeso]

Konstantin Belousov wrote in
 :
 |On Mon, Sep 06, 2021 at 04:01:37PM +0200, Steffen Nurpmeso wrote:
 |> Eric McCorkle wrote in
 |>  :
 |>|Interesting, I wasn't aware of the upstream module.  I'd say that's
 |> 
 |> It's existence was the reason i have readded (now optional, and
 |> a tad different) session support for my pam_xdg PAM module,
 |> because i was thinking that, if such a many-eyes-seen thing of
 |> a software project that claims to be and aims at being enterprise,
 |> ships such a terrible and terribly broken thing, then i can also
 |> offer session tracking.  But my manual at least states
 |> 
 |>   CAVEATS
 |>On Unix systems any “daemonized” program or script is reparented \
 |>to the
 |>program running with PID 1, most likely leaving the PAM user \
 |>session
 |>without PAM recognizing this.  Yet careless such code may \
 ...

 |If you use reaper facility, that would ensure that all (grand-)children
 |of your session are always reparented to the reaper and not to init.  In
 |other words, you can reliable know when the session ends.  See
 |procctl(2) PROC_REAP_* commands.
 |
 |I believe that reaper-like functionality is available on all current
 |Unix-like systems, even if under different names.

Ah it is really, really cool what becomes possible (everywhere;)!
So (Open)PAM should maybe (configurably) enable this does for all
programs which actually use modules which use session management.

  #?0|kent:free-src.git$ git grep PROC_REAP_ origin/main |
grep -vE '\.2:|:tests/' |
sed -E 's/^(.+:.+):.+$/\1/' |
sort -u
  origin/main:sys/compat/freebsd32/freebsd32_misc.c
  origin/main:sys/kern/kern_procctl.c
  origin/main:sys/sys/procctl.h
  origin/main:usr.bin/timeout/timeout.c

I do not have systemd here, but on Linux situation seems similar:

  #?0|kent:x$ tar -xf /x/balls/shadow/shadow-4.8.1.tar.xz
  #?0|kent:x$ grep -r REAP shadow-4.8.1/
  #?1|kent:x$ tar -xf /x/balls/linux-pam/Linux-PAM-1.5.1.tar.xz
  #?0|kent:x$ grep -r REAP Linux-PAM-1.5.1/
  [yes, pam_unix defines UNIX_REAP, not PR_SET_CHILD_SUBREAPER]
  #?0|kent:x$ tar -xf /x/balls/openssh/openssh-8.7p1.tar.gz
  #?0|kent:x$ grep -r REAP openssh-8.7p1/
  #?1|kent:x$

Maybe this is why systemd flies, i would guess it does, and this
gives you then reliable session management.  I did not really know
that actually, .. consciously.  This is really cool, but still
also that upstream OpenZFS module, and my one, and who knows which
other PAM module also, perform really bad sad and bitter session
counting via counter files, ... but that is a different topic.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: PAM module for loading ZFS keys on login

[Steffen Nurpmeso]

Eric McCorkle wrote in
 :
 |Interesting, I wasn't aware of the upstream module.  I'd say that's

It's existence was the reason i have readded (now optional, and
a tad different) session support for my pam_xdg PAM module,
because i was thinking that, if such a many-eyes-seen thing of
a software project that claims to be and aims at being enterprise,
ships such a terrible and terribly broken thing, then i can also
offer session tracking.  But my manual at least states

  CAVEATS
   On Unix systems any “daemonized” program or script is reparented to the
   program running with PID 1, most likely leaving the PAM user session
   without PAM recognizing this.  Yet careless such code may hold or expect
   availability of resources of the session it just left, truly performing
   cleanup when sessions end seems thus unwise.  Since so many PAM modules
   do support session tracking and cleanup pam_xdg.so readded optional sup‐
   port for this.

But the real solution would be PAM session tracking in-kernel,
somehow, wouldn't it?
Also, on FreeBSD and OpenPAM many separate files exist in
/etc/pam.d for things which might open a session, whereas linuxpam
at least has /etc/pam.d/common-session; it has many common- things
in fact, and in /etc/pam.d/sshd i for example see

  #
  # /etc/pam.d/sshd - openssh service module configuration
  #

  authinclude common-auth

  account include common-account

  passwordinclude common-password

  session include common-session

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: PAM module for loading ZFS keys on login

[Steffen Nurpmeso]

Eric McCorkle wrote in
 :
 ...
  >> This patch creates a new PAM module that will load a ZFS key upon a
  >> successful login: https://reviews.freebsd.org/D31844.  It will use the
  >> user's auth token as the key argument to loading a ZFS encryption key on
  >> a user-specific ZFS data set.
  ...

Without knowing about libzfs i personally was stunned about the
simplicity of your patch, having read the upstream one.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Rationalizing sed -i/-I (in-place editing) argument handling

[Steffen Nurpmeso]

Ian Lepore wrote in
 <8e9983a4243d158789029ec8b16837b35ca4451a.ca...@freebsd.org>:
 |On Mon, 2021-03-08 at 15:13 -0500, Ed Maste wrote:
 |> A relatively minor but longstanding incompatibility between FreeBSD
 |> and many other systems is the way sed handles backup files for
 |> in-place editing -- sed's -I and -i options. GNU sed and other BSDs
 |> accept an optional argument: -I.bak will save a backup file with a
 |> .bak extension, and -I with no argument will not create a backup
 |> file.
 |> FreeBSD currently accepts either -I.bak or -I .bak to save a backup
 |> with the given extension, and -I "" (an empty argument) to specify no
 |> backup.
 |> 
 |> I've been tripped up by this in the past and I know many others have.
 |> Most recently tobik@  filed PR 254091 for this. Now, I think a single
 ...
 |> change to make -i/-I to be compatible with other sed implementations
 |> in one step is too much of a POLA violation, but I think it can
 |> reasonably be done in stages:
 |> 
 |> 1. Update the man page to indicate that -i/-I should not have a space
 |> between the flag and the extension. This is compatible with current
 |> FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below.
 |> No backup is still a special case and remains as -I "".
 ...
 |As someone who has to take care of common software that runs on
 |everything from freebsd 8 through -current, I HATE the very idea of
 |this.  If we keep whittling away at the backwards compatibility freebsd
 |is so famous for, I'll have abosolutely zero arguments left for why
 |$work shouldn't just switch to the much more popular and better-
 |supported linux.
 |
 |I also hate the idea of requiring no space between -I and its related
 |value.  That seems like a huge POLA violation compared to how virtually
 |every other command's options and arguments work.

I hate it too.  But just wanted to note that sccs used this (and
still does, even standardized) decades ago already (and i always
did it wrong).

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Steffen Nurpmeso]

John-Mark Gurney wrote in
 <20201229011939.gu31...@funkthat.com>:
 |Steffen Nurpmeso wrote this message on Wed, Dec 23, 2020 at 17:24 +0100:
 |>|Then there's also the point that the repo is (looks like it) using
 |>|SHA-1 hashes, which are effectively broken, so depending upon them
 |>|to validate the tree is questionable anyways.
 |> 
 |> git uses the hardened SHA-1 for sure, which is, as far as i know,
 |> at least safe against the known attack.
 |> I .. have not tracked this, but i think upgrading to SHA-256 is
 |> possible, once this will become standard.  Just even more
 |> metadata, then.  I have not looked into this, still in progress.
 |
 |A new attack came out earlier this year:
 |https://eprint.iacr.org/2020/014.pdf

Impressive document.  Not a mathematician here, but still.

 |>From the paper:
 |> In particular, chosen-prefix collisions can break signature schemes and
 |> handshake security in secure channel protocols (TLS, SSH), if generated
 |> extremely quickly.
 |
 |The previous attack in 2017 did not break SHA-1 enough to render it's
 |use by git vulnerable, but the writing was on the wall for SHA-1...
 |
 |I believe this new attack makes git's use a SHA-1 vulnerable...
 |The type/length prefix that prevented the previous attacks from
 |working is not effective against the new attack...
 |
 |Also, the cost of the attack is not great ($45k), considering the recent

Ha.

 |SolarWinds supply chain attack, being able to smuggle a modified file
 |into a git repo, say an OS's build server, such that the tools don't
 |know the tree is modified is a real problem...

SHA-256 arrives, if you look at the git history.  Until then
signing a git tag even with SHA-1 is better than being unsealed.

This attack, well, interesting that FreeBSD with so many
developers with ssh push hasn't been soiled more often.  I am
cautious regarding such, there is a tremendous amount of
propaganda against Russia and China going on .. and then who
tapped the cables, who has the budget, hmm.  I have read one US
national security alert report once, and all i could see was
a supposed russian who logged into an open management console, and
immediately logged out again (if the session was printed
correctly).  On some software where this login possibility was
publicly announced as being a problem months before.  (I read
around once i read this report.) So given that the software would
at least log such login attempts it could even have been seen as
a kind reminder, whatever.  Maybe not.  Was it "national security
alert"?, i think yes.  Well.  It is always easy to point with
fingers at someone else.  But as always, situation is horror.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 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/sqli

Re: src: continued use of Subversion for getting updates

[Steffen Nurpmeso]

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.

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

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

Then there are basically two options.  One is to simply switch to
the vendor branch, work and commit there as often as necessary,
and then mer

Re: src: continued use of Subversion for getting updates

[Steffen Nurpmeso]

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:
 |>>|>Jeffrey Bouquet wrote in
 |>>|> :
 |>>|>|On Wed, 23 Dec 2020 11:13:07 +0100, Johan Hendriks
 |>> >|>|om> wrote:
 |>>|>|> On 23/12/2020 09:49, Warner Losh wrote:
 |>>|>|>> On Wed, Dec 23, 2020, 1:48 AM Graham Perrin <
 |>> grahamper...@gmail.com> \
 |>>|>|>> wrote:
 |>>|> ...
 |>>|>|> First of all a big thank you for all your time and effort you and
 |>> all
 |>>|>|> the other people put in this tremendous task.
 |>>|>
 |>>|>Yes, it is great to have FreeBSD as a stable git repository now,
 |>>  ...
 |>>|>I really dislike that vendor imports have been tagged.  Because
 |>>|>there is only one tag namespace you cannot avoid getting all this
 |>>|>cruft.  I mean, it is too late now, but one could have used
 ...
 |>>|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
 |>> correctly, did it?  I mean it has been two months or so since
 |>> i last had it because "git fetch" bailed here due to the errors
 |>> that i have reported, and fetching more than a gigabyte for
 |>> brand-new fetches devastates here.
 |>
 |> 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
branches, of course.  Only the tags are the problem.

 |> The multiple gigabyte fetch is because we changed the hashes two or three
 |> times in the last few months.

Yes i know.  No problem (well, for me, of course), i tried it at
least once more by the end of November, but the server did not
finish my request (the simple "git fetch" in a non-clean repo).

 |> But i _think_ all the tags below refs/tags/vendor/ like
 |>>
 |>>   vendor/wpa/2.9
 |>>   vendor/wpa_supplicant/0.3.8
 |>>   vendor/wpa_supplicant/0.5.10
 |>>   vendor/wpa_supplicant/0.5.11
 |>>   vendor/x86emu/4.6
 |>>   vendor/xe/1.13
 |>>
 |>> etc. did not exist in cgit-beta?  I surely would have said
 |>> something once comments have been requested, wouldn't i?
 |>
 |> 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.

 |>> The thing is if i do
 |>>
 |>>   #?0|kent:free-src.git$ git ls-remote|wc -l
 |>>   From https://git.freebsd.org/src.git
 |>>   6814
 |>>
 |>> This is a tremendous amount of head references that need to be
 |>> compared.
 ...
 |>> 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.

  ...
 |>> and thus
 |>>
 |>>   #?0|kent:free-src.git$ git sr | grep vendor | wc -l
 |>>   2118
 |>>
 |>> 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.

  ...
 |>>|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 you
revert nothing but the commit.  In fact doing so messes the tag,
it has to be retagged when you do re-commit an import proper,
which requires a forced push even!

Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: src: continued use of Subversion for getting updates

[Steffen Nurpmeso]

Ulrich Spörlein wrote in
 :
 |On Wed, 2020-12-23 at 15:35:45 +0100, Steffen Nurpmeso wrote:
 |>Jeffrey Bouquet wrote in
 |> :
 |>|On Wed, 23 Dec 2020 11:13:07 +0100, Johan Hendriks |om> wrote:
 |>|> On 23/12/2020 09:49, Warner Losh wrote:
 |>|>> On Wed, Dec 23, 2020, 1:48 AM Graham Perrin  \
 |>|>> wrote:
 |> ...
 |>|> First of all a big thank you for all your time and effort you and all
 |>|> the other people put in this tremendous task.
 |>
 |>Yes, it is great to have FreeBSD as a stable git repository now,
 ...
 |>I really dislike that vendor imports have been tagged.  Because
 |>there is only one tag namespace you cannot avoid getting all this
 |>cruft.  I mean, it is too late now, but one could have used
 |>per-vendor import branches and step them via "git rm -rf '*' &&
 |>tar -xf newball && git add . && git commit bla" or whatever, and
 |>then join them in.  It does not matter for those who have all the
 |
 |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
correctly, did it?  I mean it has been two months or so since
i last had it because "git fetch" bailed here due to the errors
that i have reported, and fetching more than a gigabyte for
brand-new fetches devastates here.

But i _think_ all the tags below refs/tags/vendor/ like

  vendor/wpa/2.9
  vendor/wpa_supplicant/0.3.8
  vendor/wpa_supplicant/0.5.10
  vendor/wpa_supplicant/0.5.11
  vendor/x86emu/4.6
  vendor/xe/1.13

etc. did not exist in cgit-beta?  I surely would have said
something once comments have been requested, wouldn't i?
The thing is if i do

  #?0|kent:free-src.git$ git ls-remote|wc -l
  From https://git.freebsd.org/src.git
  6814

This is a tremendous amount of head references that need to be
compared.

  #?0|kent:free-src.git$ cd ../net-src.git/
  #?0|kent:net-src.git$ git ls-remote|wc -l
  From https://github.com/NetBSD/src.git
  609
  #?0|kent:net-src.git$ cd ../open-src.git/
  #?0|kent:open-src.git$ git ls-remote|wc -l
  From https://github.com/openbsd/src.git
  34
  #?0|kent:open-src.git$ cd ../dfly-src.git/
  #?0|kent:dfly-src.git$ git ls-remote|wc -l
  From git://git.dragonflybsd.org/dragonfly.git
  349

Linux is a little bit more

  #?0|kent:linux.git$ git ls-remote|wc -l
  From https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
  7019

but this specific repository tracks all release candidates and all
the update releases, which alone go into the hundreds.

Anyhow, the difference is the number of local references that
effectively have to be compared against remote heads.  For example
my local Linux repo is this:

  [remote "origin"]
  url = https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
  fetch = +refs/heads/linux-4.19.y:refs/remotes/origin/linux-4.19.y
  fetch = +refs/heads/linux-5.10.y:refs/remotes/origin/linux-5.10.y
  fetch = +refs/heads/master:refs/remotes/origin/master

And if i "sr" (show-ref) i get:

  #?0|kent:linux.git$ git sr|wc -l
  925

which is a lot due to Linux update policy, but it only relates to
the project itself, there is not one reference of what is
effectively vendor data like for example

Merge tag 'wireless-drivers-next-2020-12-12' of
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next

may it be in refs/tags or anywhere else, whereas with FreeBSD and

  [remote "origin"]
  url = https://git.freebsd.org/src.git
  fetch = +refs/heads/releng/5.5:refs/remotes/origin/releng/5.5
  fetch = +refs/heads/releng/6.4:refs/remotes/origin/releng/6.4
  fetch = +refs/heads/releng/7.4:refs/remotes/origin/releng/7.4
  fetch = +refs/heads/releng/8.4:refs/remotes/origin/releng/8.4
  fetch = +refs/heads/releng/9.3:refs/remotes/origin/releng/9.3
  fetch = +refs/heads/releng/10.3:refs/remotes/origin/releng/10.4
  fetch = +refs/heads/releng/11.4:refs/remotes/origin/releng/11.4
  fetch = +refs/heads/releng/12.2:refs/remotes/origin/releng/12.2
  fetch = +refs/heads/stable/12:refs/remotes/origin/stable/12
  fetch = +refs/heads/main:refs/remotes/origin/main

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

namely

  a62107ed19a1095158f454132a3b6ec536a4de7c refs/remotes/origin/main
  8411c9ac24aabdbbde468778b35da58dc3c15178 refs/remotes/origin/releng/10.4
  4adbf1f6686ffdc4c0555a018e14ec63b5981534 refs/remotes/origin/releng/11.4
  2120d07af09cb830873554ba5405c5d3e51b41cc refs/remotes/origin/releng/12.2
  d4c364b3dcf6dfe4e20c70d31912aad7e6219c14 refs/remotes/origin/releng/5.5
  0df48150179039ce25e09b48c85aa39bffdbb4c4 refs/remotes/origin/releng/6.4
  1c7fe7463d0204f08806b9da6d5d50fb7f75c5ad refs/remotes/origin/releng/7.4
  554a1309dbd71bb59ed4e97ea5e0bc829dad0f04 refs/remotes/origi

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

[Steffen Nurpmeso]

John-Mark Gurney wrote in
 <20201223023242.gg31...@funkthat.com>:
 |Steffen Nurpmeso wrote this message on Fri, Dec 18, 2020 at 19:28 +0100:
 |> Brooks Davis wrote in
 |>  <20201218175241.ga72...@spindle.one-eyed-alien.net>:
 |>|On Thu, Dec 17, 2020 at 05:53:20PM -0800, Thomas Mueller wrote:
 ...
 |>|Signed commits have no practicl effect on users of a repo.
 |> 
 |> Well you can verify integrity of a repository regardless of how it
 |> was distributed, this is why it is done, right.
 ...

 |TL;DR I don't see any reason for devs to sign commits.
 |
 |I could see use for RE (or another entity) to occasionally (weekly?)
 |sign the repo (say COPYRIGHT or UPDATING), and it would be nice for
 |them to sign all the tags used for releases, but having every dev
 |would both make the dev's life difficult...

Sure.  Signing at least releases makes a lot of sense.
Your idea of periodically sealing the tree is interesting, because
it can even be automatized (dependent on the key).
stable/ patch pumpkins could sign at least the last commit they
cherry pick back to stable, aren't ehy in distress already :)

 |It's also hard to collect ALL the keys of the devs at any point in
 |time to decide if that key is authorized to sign a commit in the
 |repo...  Like if a dev starts in 2021, any commits made by that
 |dev prior to 2021 should not be "valid"..  Then there's also the
 |issue that people's keys change over time, and now you need to know
 |what time period each key was valid for, otherwise a compromised key
 |could be used to insert malicious changes into your/the tree...
 |
 |Then there's also the point that the repo is (looks like it) using
 |SHA-1 hashes, which are effectively broken, so depending upon them
 |to validate the tree is questionable anyways.

git uses the hardened SHA-1 for sure, which is, as far as i know,
at least safe against the known attack.
I .. have not tracked this, but i think upgrading to SHA-256 is
possible, once this will become standard.  Just even more
metadata, then.  I have not looked into this, still in progress.

Imho: devs should show "muchos cojones".
I am sure you appreciate a daunting post, i think it is ok to
quote this post from openssl-...@openssl.org ("Re: Attribution of
pull requests in git"):

  Theodore Ts'o wrote in
   <20140426145907.ga1...@thunk.org>:
   |On Sat, Apr 26, 2014 at 11:29:39AM +0100, Ben Laurie wrote:
   |> I just noticed that if I merge a pull request, then both author and
   |> committer are set to whoever made the pull request.
   |
   |Are you using github, or git using its standard pull request workflow?
   |
   |In the standard git workflow, the author and committer is set to the
   |person who merged the pull.  The person who requested the pull request
   |is recorded in the signed git tag.  For example, I recently signed a
   |git tag:
   |
   |% git tag -s ext4_for_linus_stable
   |
   | 

Wonderful.

   |% git push ssh://gitol...@ra.kernel.org/pub/scm/linux/kernel/git/tytso/e\
   |xt4.git tags/ext4_for_linus_stable
   |
   |   

Ah yes.
Correct enough for German public law television at its best!

   |% git request-pull origin git://git.kernel.org/pub/scm/linux/kernel/git/\
   |tytso/ext4.git tags/ext4_for_linus_stable > /tmp/pull
   |
   |(I have aliases and shell scripts for most of this, but I've expanded
   |all of this out for clarity.)
   |
   |Then I e-mailed the following to Linus, and then after he merged the
   |pull request, when I pulled down his tree, tou can see the following:
   |
   |% git show --pretty=fuller --show-signature  origin
   |commit 9ac03675010a69507c0a9d832d6a722e07d35cc6
   |merged tag 'ext4_for_linus_stable'
   |gpg: Signature made Sun 20 Apr 2014 10:23:16 PM EDT using RSA key ID \
   |C11804F0
   |gpg: Good signature from "Theodore Ts'o "
   |gpg: aka "Theodore Ts'o "
   |gpg: aka "Theodore Ts'o "
   |Merge: a798c10 0a04b24
   |Author: Linus Torvalds 
   |AuthorDate: Sun Apr 20 20:43:47 2014 -0700
   |Commit: Linus Torvalds 
   |CommitDate: Sun Apr 20 20:43:47 2014 -0700

   ...

   |The advantage of doing this way is that git will detach the signature
   |from the tag, and save it in the merge conflict, so years later, the
   |cryptographic accountability chain is preserved in the git tree.
   |
   |Cheers,

Hope that helps.
I personally sign releases and (at least the head of a bunch of)
commits to [master] and [stable] (it is a git alias which does
it).  Looser that i am i have a setup-privacy script on an
encrypted partition that loads keys, unfortunately not even root
can kill -SOMESIG to cause all ssh-agents etc to unload and clear
the loaded keys, therefore i hook acpi and do something like

   if command -v ssh-add >/dev/null 2>&1; then
  for a in /tmp/ssh-*/agent.*; do
 [ -e "$a" ] || continue
 act '( SSH_AUTH_SOCK=&

Re: src: continued use of Subversion for getting updates

[Steffen Nurpmeso]

Jeffrey Bouquet wrote in
 :
 |On Wed, 23 Dec 2020 11:13:07 +0100, Johan Hendriks  wrote:
 |> On 23/12/2020 09:49, Warner Losh wrote:
 |>> On Wed, Dec 23, 2020, 1:48 AM Graham Perrin  \
 |>> wrote:
 ...
 |> First of all a big thank you for all your time and effort you and all 
 |> the other people put in this tremendous task.

Yes, it is great to have FreeBSD as a stable git repository now,
not only due to "gc --aggressive --prune=all" and the possibility
to use (pseudo) bare repositories without checkouts, but also
because of this.  Downloaded it today (from fresh), currently
doing the mentioned command, but it may be it does not reduce that
much :)

I really dislike that vendor imports have been tagged.  Because
there is only one tag namespace you cannot avoid getting all this
cruft.  I mean, it is too late now, but one could have used
per-vendor import branches and step them via "git rm -rf '*' &&
tar -xf newball && git add . && git commit bla" or whatever, and
then join them in.  It does not matter for those who have all the
repository, but you decided to loose one of the strengts of git,
selective tracking.  Also i think it causes updates to require
more network traffic, i see this with the repos i have at
repo.or.cz, the one with few heads/tags is minimal, the other
requires hundreds of kilobytes just for the check that happens
many times a day.  All these references have to be compared each
and every time.  I think.  On the other hand, a few years back
i accidentally "heard" a discussion about improving the network
protocol and that "head" reference matching, iirc, so it may
change in the future.

Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Steffen Nurpmeso]

Brooks Davis wrote in
 <20201218175241.ga72...@spindle.one-eyed-alien.net>:
 |On Thu, Dec 17, 2020 at 05:53:20PM -0800, Thomas Mueller wrote:
 |>>> I hope we don't have to start signing all commits.  saltstack/salt has
 |>>> that policy, and it's extremely annoying.
 |> 
 |>> Have to? Not currently. As with all process changes, there will be
 |>> community discussion around the different points.
 |> 
 |>> Warner
 |> 
 |> I hope not!
 |> 
 |> Signatures, at least in email messages, are just an annoyance as \
 |> I see them.
 |> 
 |> I don't even know how do sign an email message or make use of a signatur\
 |> e in a message I receive.
 |> 
 |> I have never made a commit to a repository, so would not be familiar \
 |> with signatures there; imagine it would be a barrier.
 |
 |Signed commits have no practicl effect on users of a repo.

Well you can verify integrity of a repository regardless of how it
was distributed, this is why it is done, right.

  #?0$ git log --oneline --show-signature -1 v14.9.20.ar
  16a21755 (...)
  gpg: Signature made Sun 13 Dec 2020 12:43:44 AM CET
  gpg:    using RSA key DF082F6AEEC8C2FF
  gpg: Good signature from "Steffen Nurpmeso "
  Bump S-nail v14.9.20.ar ("Sombre Tit (Trauermeise)"), 2020-12-12

  #?0$ git tag -v v14.9.20.ar; echo $?
  object 16a21755fd1fade2b15fdb78a592f12169c3453f
  type commit
  tag v14.9.20.ar
  tagger Steffen Nurpmeso  1607816624 +0100
  
  Bump S-nail v14.9.20.ar ("Sombre Tit (Trauermeise)"), 2020-12-12
  gpg: Signature made Sun 13 Dec 2020 12:43:44 AM CET
  gpg:using RSA key DF082F6AEEC8C2FF
  gpg: Good signature from "Steffen Nurpmeso "
  0

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Please check the current beta git conversions

[Steffen Nurpmeso]

Ulrich Spörlein wrote in
 :
 |On Mon, Oct 5, 2020 at 7:21 PM Steffen Nurpmeso  wrote:
 |> Ulrich Spörlein wrote in
 |>  :
 |>|On Sun, Oct 4, 2020 at 1:53 AM Bakul Shah  wrote:
 |>|> git clone --bare https://cgit-beta.freebsd.org/src.git
 |>|> cd src.git
 |>|> git fetch origin 'refs/notes/*:refs/notes/origin/*' # <<< not sure
 ...
 |>|This is a quirk of the conversion. We have to patch up several tags
 |>|post-conversion, which patches up their notes, but that happens after the
 |>|full conversion is done. Notes are just 1 long linear branch, which ...
 |>|well, is unfortunate. So essentially every update to the repo changes the
 |>|last couple hundred of hashes for the commit notes
 ...
 |>|This will all cease with the final transition, obviously.
 |>
 |> I guess they will simply vanish and i could remove the reference
 |> from my config already today?
 |>
 |They will not vanish. They are there to map git commits back to SVN
 |revisions.
 |What will change is that they'll never change again and are just a static,
 |eternal record
 |of that mapping.
 |
 |Of course, freebsd committers can then in the future push their own notes
 |(but not force-push them) , but it's not clear what you would want to put
 |into them?
 |
 |If you don't have a need to ever map git <-> svn commits, then you don't
 |need to fetch
 |them indeed.

Fantastic!  Sure thing if FreeBSD moves over to git as such.
Thank you.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Please check the current beta git conversions

[Steffen Nurpmeso]

Ulrich Spörlein wrote in
 :
 |On Sun, Oct 4, 2020 at 1:53 AM Bakul Shah  wrote:
 |> git clone --bare https://cgit-beta.freebsd.org/src.git
 |> cd src.git
 |> git fetch origin 'refs/notes/*:refs/notes/origin/*' # <<< not sure about
 |> this
 |> # don't recall if I manually added the second fetch line in the
 |> config file.
 |> # but notes get fetched fine; though I don't understand why \
 |> 100MB+
 |> get
 |> # downloaded every time even though only a few files change.
 |
 |This is a quirk of the conversion. We have to patch up several tags
 |post-conversion, which patches up their notes, but that happens after the
 |full conversion is done. Notes are just 1 long linear branch, which ...
 |well, is unfortunate. So essentially every update to the repo changes the
 |last couple hundred of hashes for the commit notes objects/tree/DAG/linear
 |train. They always need to get force-pushed upstream and you always have to
 |re-fetch quite a bunch of them.

I was astonished to see third-to-last commit on my notes is from
Dag-Erling Smørgrav "+svn path=/vendor-crypto/openssh/5.8p2/;
revision=221485; tag=vendor/openssh/5.8p2".

 |This will all cease with the final transition, obviously.

I guess they will simply vanish and i could remove the reference
from my config already today?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Please check the current beta git conversions

[Steffen Nurpmeso]

Hello.

Bakul Shah wrote in
 :
 |On Oct 3, 2020, at 3:14 PM, Steffen Nurpmeso  wrote:
 |> And still "git fetch" fails with
 |> 
 |>  POST git-upload-pack (chunked)
 |>  error: RPC failed; curl 55 OpenSSL SSL_write: Broken pipe, errno 32
 |>  fatal: the remote end hung up unexpectedly
 |> 
 |> My config file is
 |> 
 |>  [core]
 |>repositoryformatversion = 0
 |>filemode = true
 |>bare = false
 |>logallrefupdates = true
 |>  [remote "origin"]
 |>url = https://cgit-beta.freebsd.org/src.git
 |>#url = https://github.com/freebsd/freebsd.git
 |>fetch = +refs/heads/releng/5.5:refs/remotes/origin/releng/5.5
 |>fetch = +refs/heads/releng/6.4:refs/remotes/origin/releng/6.4
 |>fetch = +refs/heads/releng/7.4:refs/remotes/origin/releng/7.4
 |>fetch = +refs/heads/releng/8.4:refs/remotes/origin/releng/8.4
 |>fetch = +refs/heads/releng/9.3:refs/remotes/origin/releng/9.3
 |>fetch = +refs/heads/releng/10.3:refs/remotes/origin/releng/10.4
 |>fetch = +refs/heads/releng/11.4:refs/remotes/origin/releng/11.4
 |>fetch = +refs/heads/releng/12.1:refs/remotes/origin/releng/12.1
 |>fetch = +refs/heads/stable/12:refs/remotes/origin/stable/12
 |>fetch = +refs/heads/main:refs/remotes/origin/main
 |>fetch = +refs/notes/*:refs/notes/*
 |
 |FWIW, I have a bare repo with the following config file
 |
 |[core]
 | repositoryformatversion = 0
 | filemode = true
 | bare = true
 | logallrefupdates = true
 |[remote "origin"]
 | url = https://cgit-beta.freebsd.org/src.git
 | fetch = +refs/heads/*:refs/remotes/origin/*
 | fetch = +refs/notes/*:refs/notes/*
 |[branch "main"]
 | remote = origin
 | merge = refs/heads/main
 |
 |/usr/src is a worktree and everything seems to be working fine.
 |
 |I manually converted to a bare repo (first testing this with a much
 |smaller repo) and fixed up various refs. But probably safer to
 |just start from scratch:
 |
 |git clone --bare https://cgit-beta.freebsd.org/src.git
 |cd src.git
 |git fetch origin 'refs/notes/*:refs/notes/origin/*' # <<< not sure \
 |about this
 | # don't recall if I manually added the second fetch line in the config \
 | file.
 | # but notes get fetched fine; though I don't understand why 100MB+ get
 | # downloaded every time even though only a few files change.
 |
 |git worktree add  main
 |git worktree add  stable/12

Interesting new way to work with external check out directories,
i only knew about the environment variable approach.  (Though have
forgotten the details, i am using less of git than what mankind
does with its brain.)
I use bare repositories only for the git repositories i publish in
the web (i have the very same thing locally 1:1 and the
post-receive hook then forwards).
This old habit of mine (an arena-manager-null branch without
files) is maybe strange.  The monthly update still updates all
repos, merges, garbage collects and then checks out this branch in
order to create the backup without any checkout.  Except for some
bootstrap things, like git itself.  It was meant for minimal
backup sizes while still being able to bootstrap in the nowhere
without internet accesss.  I never used that.  Hm.

Sure, after the lengthy matching of objects failed i was about to
simply refetch the entire repository, but i only had ~800 MB
download left, so i had to interrupt that.
I was just reporting because i thought an automated updater should
work instead of failing as above.  It must be some limit on the
server, runtime or whatever, which causes the common history
search to be aborted.  Maybe it does not abort for you because you
have a tremendously potent internet connection, whereas with this
wifi thing you always have to take into account tenths of seconds
(i would say) delay whenever a new chunk comes in after some
delay.  Maybe it is this.

Anyhow, it seems for now it would be better for me to either wait
until -beta becomes stable or switch back to the github version
until then.  I should not have thrown that thing away, 1.4+ GB of
data, that is ugly.  And all the stuff is so badly packed, on
Saturday i then cloned wolfssl out of interest and had to download
179 or so MB from github for [master] which after packing ended up
as not more than 39 MB.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Please check the current beta git conversions

[Steffen Nurpmeso]

...
Steffen Nurpmeso wrote in
...
 > I tried simply updating my github clone by switching
 > 
 >url = https://cgit-beta.freebsd.org/src.git
 >#url = https://github.com/freebsd/freebsd.git
 ...
 |It fails again, repeatedly [.]
 |
 |  POST git-upload-pack (chunked)
 |  error: RPC failed; curl 18 transfer closed with outstanding read \
 |  data remaining
 |  fatal: the remote end hung up unexpectedly

And still "git fetch" fails with

  POST git-upload-pack (chunked)
  error: RPC failed; curl 55 OpenSSL SSL_write: Broken pipe, errno 32
  fatal: the remote end hung up unexpectedly

My config file is

  [core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
  [remote "origin"]
url = https://cgit-beta.freebsd.org/src.git
#url = https://github.com/freebsd/freebsd.git
fetch = +refs/heads/releng/5.5:refs/remotes/origin/releng/5.5
fetch = +refs/heads/releng/6.4:refs/remotes/origin/releng/6.4
fetch = +refs/heads/releng/7.4:refs/remotes/origin/releng/7.4
fetch = +refs/heads/releng/8.4:refs/remotes/origin/releng/8.4
fetch = +refs/heads/releng/9.3:refs/remotes/origin/releng/9.3
fetch = +refs/heads/releng/10.3:refs/remotes/origin/releng/10.4
fetch = +refs/heads/releng/11.4:refs/remotes/origin/releng/11.4
fetch = +refs/heads/releng/12.1:refs/remotes/origin/releng/12.1
fetch = +refs/heads/stable/12:refs/remotes/origin/stable/12
fetch = +refs/heads/main:refs/remotes/origin/main
fetch = +refs/notes/*:refs/notes/*

And i am somewhat behind due to the update failures (not that it
matters, of course)

  #?141|kent:free-src.git$ git sr
  d7ad7208f47d37aae16d55f5dcb743b25dcd0288 refs/heads/arena-manager-null
  ef7e23176ea6dcda108f4e19b9c1852b7fa5fb55 refs/notes/commits
  88fc88f775381ab664fc2ca52ab143b94315743d refs/remotes/origin/main
  c032bc8ca5d4618ad349a53392fd692afef9fe4e refs/remotes/origin/releng/10.4
  24e863807ab509af9c38e84b4e5df34ff4fdf9e2 refs/remotes/origin/releng/11.2
  889f726543f5202c54ad14b81d5d16a85379ffe5 refs/remotes/origin/releng/11.4
  6fb517db6dea0333c4b0bef3098abb87656a6d34 refs/remotes/origin/releng/12.1
  101374bc1b346a37aa46393599b0969a03c8ca46 refs/remotes/origin/releng/5.5
  385a94b8751c71f178bba86c13f083895dbe006d refs/remotes/origin/releng/6.4
  f864cd1bca002396fa92715878379bc2fdad8af0 refs/remotes/origin/releng/7.4
  b4323ad1fd9f310a36e595a031d77fe0f0e38472 refs/remotes/origin/releng/8.4
  6845fb3a03394a42484e36d5f9e07e0cf14fec0d refs/remotes/origin/releng/9.3
  ae4ea149fd21ae30fb0faa7104f5e4ee51e3147c refs/remotes/origin/stable/11
  6a26cffb54271f343520a1731cf5c8f2c909194b refs/remotes/origin/stable/12
  77a8b861086dccc41c08ce7d0c795a0bd2f7a1fb refs/tags/release/10.3.0
  6025619ef8af561f9d8f3dff13c7802a1d447b7a refs/tags/release/11.4.0
  4b3b0f6c1e9d013d6cff6dfd9459f5dc4d9ece08 refs/tags/release/12.1.0
  2326bdbbcad4640f22d387060c7d3b363fff3b39 refs/tags/release/5.5.0
  b9083afc65e8ac36f65d52d7859d31a11da05aef refs/tags/release/6.4.0
  c6788c2a1bd371b64a299c6f98fe753f9a610de2 refs/tags/release/7.4.0
  acbed3693070aed8e250cd993b4d4975dd12efb1 refs/tags/release/8.1.0
  98566c7da1c45611953885e902507c562388660b refs/tags/release/8.4.0
  87d65461806585dcf89d3c80f46135117a055140 refs/tags/release/9.3.0
  #?0|kent:free-src.git$ git log -1 origin/main
  commit 88fc88f775381ab664fc2ca52ab143b94315743d (refs/remotes/origin/main)
  Author: Andrew Turner 
  AuthorDate: 2020-09-03 10:11:12 +
  Commit: Andrew Turner 
  CommitDate: 2020-09-03 10:11:12 +

  Switch to an empty ttbr0 pagetable when the MMU is enabled

  We don't need these pagetables after the early boot. Remove the chance we
  write to memory we didn't expect to and remove architectural undefined
  behaviour.

  Reviewed by:alc (earlier version), mmel
  Sponsored by:   Innovate UK
  Differential Revision:  https://reviews.freebsd.org/D22606

  Notes:
  svn path=/head/; revision=365296

Somewhat eagerly waiting for cgit-beta. becoming cgit.,

Thanks and an affordable Sunday and (uff)
Ciao, 

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Please check the current beta git conversions

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20200903191410.sgjuq%stef...@sdaoden.eu>:
 |For one: thanks all, it now works!
 |
 |Steffen Nurpmeso wrote in
 | <20200903151825.g_rv9%stef...@sdaoden.eu>:
 ||Renato Botelho wrote in
 || :
 |||On 02/09/20 20:20, Steffen Nurpmeso wrote:
 |||> Ed Maste wrote in
 |||>   :
 |||> 
 |||> I tried simply updating my github clone by switching
 |||> 
 |||>url = https://cgit-beta.freebsd.org/src.git
 |||>#url = https://github.com/freebsd/freebsd.git
 |||> 
 |||> and whereas ls-remote worked fine fetch -v --dry-run aborted as
 |||> well as normal fetch, after dumping dozens of POSTs
 |||> 
 |||>POST git-upload-pack (gzip 1472 to 804 bytes)
 |||>...
 |||>POST git-upload-pack (gzip 976722 to 483608 bytes)
 |||>POST git-upload-pack (chunked)
 |||>error: RPC failed; HTTP 413 curl 22 The requested URL returned \
 |||>error: 413
 |||>fatal: the remote end hung up unexpectedly
 ...

It fails again, repeatedly and reproducably for my monthly update.

  POST git-upload-pack (chunked)
  error: RPC failed; curl 18 transfer closed with outstanding read data 
remaining
  fatal: the remote end hung up unexpectedly

A nice Sunday from Germany i wish.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: error pulling from the Beta git repo

[Steffen Nurpmeso]

Patrick McMunn wrote in
 :
 |I'm using the beta git repo at , and I have been compiling source in that
 |directory. Today, when I ran "git pull", it errored out instead of updating
 |fully. I don't know if the error was a result of me building in the
 |directory, but it seems like a reasonable possibility. It was never an
 |issue with SVN, but should I build the source in a separate directory to
 |avoid problems with git? I don't know if git keeps a log that I can check
 |for the full output. If it does, I'd check if I knew the location. As it
 |is, I only have the partial output still present in my terminal window.

  $ git clean -fxd [--dry-run]
  $ [git reset --hard HEAD]
  $ [git fetch -vv]
  $ [git gc [--aggressive --prune=all]]
  $ git checkout -B local-branch-name origin/branch-name
  [Or git update-ref local-branch-name refs/remotes/origin/branch-name]

Alternatively just use a bare repository as a database and several
different checked-out working directories somewhere else.

Btw. the Linux distro i use has a git driver for its ports system,
it goes like that:

  cd "$REPOSITORY" 2> "/dev/null"

  if [ $? -lt 1 ]; then
  git checkout -q "$BRANCH"
  git fetch -q
  git diff --pretty=format: --name-status "$BRANCH" origin/"$BRANCH" | 
sed "s/M\t/ Edit /g; s/A\t/ Checkout /g; s/D\t/ Delete /g" | sort
  git clean -q -f
  git reset -q --hard origin/"$BRANCH"
  gc=
  else
  git clone -q -b "$BRANCH" "$URL" "$REPOSITORY"
  ls -1 $REPOSITORY | sed "s/^/ Checkout /"
  gc=--aggressive
  fi
  git gc --quiet $gc --prune=all

That gc stuff is a local addition of mine, i hate stale stuff.

Good night.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Plans for git

[Steffen Nurpmeso]

Warner Losh wrote in
 :
 |On Mon, Sep 21, 2020 at 2:55 PM Steffen Nurpmeso  \
 |wrote:
 |> Lev Serebryakov wrote in
 |>  <23e7fc1c-6769-ceaf-4089-46e5cc575...@freebsd.org>:
 |>|On 19.09.2020 19:05, Bakul Shah wrote:
 |>|>> These are the main ones. The three down sides are lack of $FreeBSD$ \
 |>|>> support
 |>|>> and tags in general.
 |>|>
 |>|> Can a git hook be used for this?
 |>|
 |>|git filters could be used for that, problem is it should be local config\
 |>|uration. You could not configure filters in clones automatically :-(
 |>
 |> I do not think you can do that.  Once i switched to git (2011 or
 |> a bit before) i even looked around for this, because i have been
 |> educated by BSD and used such tags everywhere, and found a thread
 |> with the Linus from where the elks live regarding this topic.
 |> I guess that $SHA-1$ git (supported by git by then) is the outcome
 |> of this thread, offered as a compromise.  That mail thread exists.
 |>
 |
 |It's documented to be the hash of the blob, not the hash of the commit.,
 |which makes it basically useless for our purposes...

Never used that.  Even if it requires additional tooling and/or
the repository, whereas the BSD way is that you can take such
a freely licensed file, include it somewhere, and strings(1)
etc. still gives you an immediately human graspable output.
I mean, if the project agrees by policy then of course the master
copy at freebsd.org can expand such things when commits are
merged.  There are now also many more hooks available, in fact
i have no idea of what i am talking about ^_^

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Plans for git

[Steffen Nurpmeso]

Lev Serebryakov wrote in
 <23e7fc1c-6769-ceaf-4089-46e5cc575...@freebsd.org>:
 |On 19.09.2020 19:05, Bakul Shah wrote:
 |>> These are the main ones. The three down sides are lack of $FreeBSD$ \
 |>> support
 |>> and tags in general.
 |> 
 |> Can a git hook be used for this?
 |
 |git filters could be used for that, problem is it should be local config\
 |uration. You could not configure filters in clones automatically :-(

I do not think you can do that.  Once i switched to git (2011 or
a bit before) i even looked around for this, because i have been
educated by BSD and used such tags everywhere, and found a thread
with the Linus from where the elks live regarding this topic.
I guess that $SHA-1$ git (supported by git by then) is the outcome
of this thread, offered as a compromise.  That mail thread exists.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Plans for git

[Steffen Nurpmeso]

Bakul Shah wrote in
 :
 |On Sep 18, 2020, at 11:21 PM, Warner Losh  wrote:
 |> 
 |> These are the main ones. The three down sides are lack of $FreeBSD$ \
 |> support
 |> and tags in general.
 |
 |Can a git hook be used for this?

I use a git pre-commit hook to fake-update SCCS IDs for my web
site (

  if git rev-parse --verify HEAD >/dev/null 2>&1
  then
  against=HEAD
  else
  # Initial commit: diff against an empty tree object
  against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
  fi

  DATE=`date -u +%Y-%m-%dT%H:%M:%S`

  git diff-index --name-status --cached $against -- |
  grep -E '^[AM][[:space:]]+.+\.(html|js|css)' |
  cut -f2 |
  while read f; do
  if grep -F '@(#)' ${f} > /dev/null 2>&1; then
  < ${f} perl -e '
  while () {
  unless ($_ =~ /@\(#\)/) {
  print;
  next;
  }
  chomp;
  $_ =~ /^((?:.*?)@\(\#\)(?:.+?) \d+\.)
  (\d+)
  ( .+\+)(.*)$/x;
  print $1, int($2) + 1,
  " '"${DATE}"'+", $4, "\n";
  }
  ' > ${f}.new
  mv ${f}.new ${f}
  git add ${f}
  fi
  done
  exit 0

and do not look to seriously) but of course this is a crux that
can only work well with a single developer / changeset branch tip,
as soon as you join in other branches you are in trouble unless
you cherry-pick everything onto a main line by policy.

 |> Yes. I've started doing a series of short videos explaining the change, \
 |> why
 |> we are doing it and what to do in the new world order. I'll be doing blog
 |> entries as well as turning that material into handbook entries. I \
 |> have some
 |> of those written.
 |> 
 |> Does this help?
 |
 |It would be useful to describe the development model (e.g. how major/minor
 |features get added etc), how to maintain multiple local branches (e.g.
 |release branch or -current) or working on more than one feature at \
 |a time etc.
 |
 |Do you plan to move to something like the github review process?
 |
 |When is the cutover supposed to occur?
 |
 |The cgit-beta.FreeBSD.org and github trees are not identical the last
 |time I looked (mainly in meta data). Any reason for not keeping them
 |identical? I switched from the github tree to the cgit-beta tree.
 |
 |FWIW, I have used sccs, rcs, cvs, subversion, mercurial, git & a few more.
 |I have used git exclusively for the last few years. I felt more comfortable
 |with git once I understood the on-disk storage model. The Pro Git book is
 |pretty good for that & more.

That gc (--aggressive --prune=all) thing is a tremendous plus for
git in my opinion.  I track all BSDs and the Linux kernel via git
and in bare repositories without checked out work dir, and it is
as compact as can be.  Whereas with Mercurial and Subversion (as
i used to know them a decade(+) ago) you had all that mess lying
around.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Please check the current beta git conversions

[Steffen Nurpmeso]

For one: thanks all, it now works!

Steffen Nurpmeso wrote in
 <20200903151825.g_rv9%stef...@sdaoden.eu>:
 |Renato Botelho wrote in
 | :
 ||On 02/09/20 20:20, Steffen Nurpmeso wrote:
 ||> Ed Maste wrote in
 ||>   :
 ||> 
 ||> I tried simply updating my github clone by switching
 ||> 
 ||>url = https://cgit-beta.freebsd.org/src.git
 ||>#url = https://github.com/freebsd/freebsd.git
 ||> 
 ||> and whereas ls-remote worked fine fetch -v --dry-run aborted as
 ||> well as normal fetch, after dumping dozens of POSTs
 ||> 
 ||>POST git-upload-pack (gzip 1472 to 804 bytes)
 ||>...
 ||>POST git-upload-pack (gzip 976722 to 483608 bytes)
 ||>POST git-upload-pack (chunked)
 ||>error: RPC failed; HTTP 413 curl 22 The requested URL returned \
 ||>error: 413
 ||>fatal: the remote end hung up unexpectedly
 ||> 
 ||> Maybe clone from scratch instead, but mysterious it is?
 ||> Good night, and Ciao from Germany,
 ||
 ||github and cgit-beta repositories are not the same.  Commit hashes won't 
 ||match so you cannot simply change the URL.
 |
 |Yes i know that, but most of the blobs are of course the same, no?

Having said that, i switched to git in i think 2011 and never ever
read anything about the protocol or almost anything else ever
since ...  Except that rev-parse changed its output order which
broke a (primitive) script (git-topic-creator) of mine, but that
was in 2013.

So: it may well be that git does not really take care for finding
local data blobs unless there are commits with shared ancestors or
what (the two repositories anyway show up as "warning: no common
commits").  Let's see where this ends...

That reminds me of the fossil/venti storage system of Plan9, with
the short-time local cache and the hash-based backing store, which
just stores digested blocks.  There was a graphic which showed how
data consumption exploded at the beginning, but the curve went
flatter and flatter, and it was explicitly noted that the masses
of people in Bell Labs did a lot with multimedia, videos and such.
Which i found surprising.

Old github pack
  -r--r- 1 steffen code 1526603739 Aug  2 01:47 
pack-92bcd61e50e1a09e27e8aa4a67e0878468f01f79.pack
  -r--r- 1 steffen code  136779336 Aug  2 01:47 
pack-92bcd61e50e1a09e27e8aa4a67e0878468f01f79.idx

  warning: no common commits
  remote: Enumerating objects: 920487, done.
  remote: Counting objects: 100% (920487/920487), done.
  remote: Compressing objects: 100% (254705/254705), done.
  remote: Total 4909613 (delta 876272), reused 665791 (delta 665782), 
pack-reused 3989126
  Receiving objects: 100% (4909613/4909613), 1.25 GiB | 396.00 KiB/s, done.

Hm.  It definetely must have downloaded masses of duplicate data.
I must admit, the largest repo which had to be updated very often
(despite the borked NetBSD thing on github, years ago) was
ghostscript.  There i looked, but find it quite different, if
i recall correctly.  I did not blame git for the mess there.

  Resolving deltas: 100% (3429285/3429285), done.
  From https://cgit-beta.freebsd.org/src
   + 606d234876ce...101374bc1b34 releng/5.5 -> origin/releng/5.5  
(forced update)
   + 2132c100d27f...385a94b8751c releng/6.4 -> origin/releng/6.4  
(forced update)
   + c462a28e0cae...f864cd1bca00 releng/7.4 -> origin/releng/7.4  
(forced update)
   + 3ffe9881628f...b4323ad1fd9f releng/8.4 -> origin/releng/8.4  
(forced update)
   + 34073209c9c9...6845fb3a0339 releng/9.3 -> origin/releng/9.3  
(forced update)
   + 57fbb64699be...c032bc8ca5d4 releng/10.3-> origin/releng/10.4  
(forced update)
   + da2894488950...889f726543f5 releng/11.4-> origin/releng/11.4  
(forced update)
   + e1a11e350964...6fb517db6dea releng/12.1-> origin/releng/12.1  
(forced update)
   + a9ff142f7dcc...6a26cffb5427 stable/12  -> origin/stable/12  
(forced update)
   + c660a28c68a8...88fc88f77538 main   -> origin/main  (forced 
update)

A masterpiece!

   + 16be7204f705...ef7e23176ea6 refs/notes/commits -> refs/notes/commits  
(forced update)
   * [new tag]   release/10.3.0 -> release/10.3.0
   * [new tag]   release/11.4.0 -> release/11.4.0
   * [new tag]   release/12.1.0 -> release/12.1.0
   * [new tag]   release/5.5.0  -> release/5.5.0
   * [new tag]   release/6.4.0  -> release/6.4.0
   * [new tag]   release/7.4.0  -> release/7.4.0
   * [new tag]   release/8.1.0  -> release/8.1.0
   - [new tag]   release/8.4.0  -> release/8.4.0
   - [new tag]   release/9.3.0  -> release/9.3.0

  -r--r- 1 steffen code 1344409784 Sep  3 20:44 
pack-0f656d44c6c8301d98ee51b69c3aacd8db9255ac.pack
  -r--r- 1 steffen code  137470236 Sep  3 20:4

Re: Please check the current beta git conversions

[Steffen Nurpmeso]

Renato Botelho wrote in
 :
 |On 02/09/20 20:20, Steffen Nurpmeso wrote:
 |> Ed Maste wrote in
 |>   :
 |> 
 |> I tried simply updating my github clone by switching
 |> 
 |>url = https://cgit-beta.freebsd.org/src.git
 |>#url = https://github.com/freebsd/freebsd.git
 |> 
 |> and whereas ls-remote worked fine fetch -v --dry-run aborted as
 |> well as normal fetch, after dumping dozens of POSTs
 |> 
 |>POST git-upload-pack (gzip 1472 to 804 bytes)
 |>...
 |>POST git-upload-pack (gzip 976722 to 483608 bytes)
 |>POST git-upload-pack (chunked)
 |>error: RPC failed; HTTP 413 curl 22 The requested URL returned \
 |>error: 413
 |>fatal: the remote end hung up unexpectedly
 |> 
 |> Maybe clone from scratch instead, but mysterious it is?
 |> Good night, and Ciao from Germany,
 |
 |github and cgit-beta repositories are not the same.  Commit hashes won't 
 |match so you cannot simply change the URL.

Yes i know that, but most of the blobs are of course the same, no?
The same files.  All that is new are likely the notes and commit
objects, even the directory tree objects could often be the same,
but i do not know, also because i do not have the new data yet.
(But it is 100% that i will not actually inspect this deeply.)
Maybe they should split in cgit. and scm. (or .git) and use the
git-http-backend for clones on scm. (or .git) and then redirect
some requests, this works fine for years:

  url.redirect = (
 "^.*/([^/]+\.git/objects/.*)" => "https://???/scm/$1;,
 "^.*/([^/]+\.git/info/refs\?service.*)" =>
   "https:///scm/$1;
  )

I mean i really like saving some download that would go over
thousands of kilometres for absolutely nothing.
And i think it would be cool if all the many people which clone
the github repo just update to the finally landed freebsd.org
instance.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Please check the current beta git conversions

[Steffen Nurpmeso]

Ed Maste wrote in
 :

I tried simply updating my github clone by switching

  url = https://cgit-beta.freebsd.org/src.git
  #url = https://github.com/freebsd/freebsd.git

and whereas ls-remote worked fine fetch -v --dry-run aborted as
well as normal fetch, after dumping dozens of POSTs

  POST git-upload-pack (gzip 1472 to 804 bytes)
  ...
  POST git-upload-pack (gzip 976722 to 483608 bytes)
  POST git-upload-pack (chunked)
  error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413
  fatal: the remote end hung up unexpectedly

Maybe clone from scratch instead, but mysterious it is?
Good night, and Ciao from Germany,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: В ответ на: Re: ? ????? ??: Re: FYI: forum web site is .. unreadable

[Steffen Nurpmeso]

Hello.

Michael Gmelin wrote in
<20200624104439.62f0a...@bsd64.grem.de>:
 |On Tue, 23 Jun 2020 19:47:21 +0200
 |Steffen Nurpmeso  wrote:
 |> ...shortened...
 |>|Data point: I tried on latest Firefox on macOS, no problems there
 |> (but |the resolution isn't as high as yours).
 |>|
 |>|Does it look less broken on different devices/resolutions when using
 |>|"Web Developer" => "Responsive Design Mode"?
 |> 
 |> Now, that i never tried, it is a mysterious thing, but when
 |> i enabled it i got a small window inside the normal window, and
 |> then it looked just fine!  So i disabled that again, and resized
 |> the browser window as such, and when the window is smaller than
 |> 470 then suddenly the content springs into existence!!
 |> Thanks for this pointer!!
 | 
 |If you have no solution yet, I would test on a fresh set of settings
 |by adding a temporary user (e.g. "fftest"), logging into the desktop
 |environment as that user, starting firefox and see if the page still
 |doesn't render properly.

Hm, i see no changes.  Actually i would like to unregister the
user again, i just thought it would help to get me going, but it
seems unregistering is not an option.  Changing theme, which was
a suggestion, does not work here, too.
But thanks again, now i know how to deal with that bug :)
Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: В ответ на: Re: ? ????? ??: Re: FYI: forum web site is .. unreadable

[Steffen Nurpmeso]

Hello!!

Michael Gmelin wrote in
<20200623192523.7c595...@bsd64.grem.de>:
 |On Tue, 23 Jun 2020 17:34:37 +0200
 |Steffen Nurpmeso  wrote:
 |> Kostya Berger wrote in
 |> <811812565.4605472.1592924651...@mail.yahoo.com>:
 |>||вт, 23 июн. 2020 в 17:55 Steffen Nurpmeso
 |>|| написал(-а):
 |>||Gary Jennejohn wrote in
 |>||<[2]20200623130733.658b4...@ernst.home[/2]>:
 |>|||On Tue, 23 Jun 2020 09:05:06 + (UTC)
 |>|||Kostya Berger <[3]berger...@yahoo.co.uk[/3]> wrote:
 |>|||
 |>|||> Looks fine in my Firefox. No such problems. Locally built

I clean this mess, ok?

 |>|||> se> __(-__): On 2020-06-23 08:48, Gary Jennejohn
 |> wrote: |||>> On Tue, 23 Jun 2020 01:14:52 +0200
 |>|||>> Steffen Nurpmeso <[5]stef...@sdaoden.eu[/5]> wrote:  
 |>||...
 |>|||>>> Normally i do not do forums (web interface etc etc), but i was
 |>|||>>> interested in ZFS encryption support and so i searched, and
 |> found |||>>> a page[1].__ Now when i open that on a glibc Linux box
 |> with |||>>>
 |>|||>>>__ __ #?0|kent:src$ prt-get info firefox-bin  
 ...
 |>|||>>> i.e. Mozilla.com-compiled firefox, then i see a small forum
 |>|||>>> "frame" on the right side, it is right of the "Foundation"
 |> link in |||>>> the link bar.__ It is just large enought to place "To
 |> be honest," |||>>> in a single line, on a, well, pretty wide screen.
 ...
 |>|||>> I see exactly the same bad formatting with the standard
 |> firefox \ |||>> port.__ All the
 |>|||>> text is pushed to the right.
 |>|||>> 
 |>|||>> seamonkey works, but it's been removed from ports.  
 |>|||> 
 |>|||> It looks fine on my 1080p display, using Firefox from FreeBSD
 |> packages. |||
 |>|||I just installed the latest firefox from the package repository
 |> and \ |||the forum page
 |>|||is still mis-formatted.
 |>|||
 |>|||This is the only website of the many I use which displays this
 |> error. |||
 |>|||My display is 2560x1440 (probably irrelevant). Not really all
 |> that \ |||important
 |>|||to me in any case.
 ...
 |>|Anyway, you can try resetting your Firefox to defaults.
 |> 
 |> I am using a default Firefox, no add-ons or anything.  I only have
 |> a stylesheet which increases the font used in menus, *if* that is
 |> still used, actually, one of the versions passed changed that
 |> i think, it is that ../chrome/userChrome.css file (and it took
 |> many hours to find this possibility).
 |
 |Data point: I tried on latest Firefox on macOS, no problems there (but
 |the resolution isn't as high as yours).
 |
 |Does it look less broken on different devices/resolutions when using
 |"Web Developer" => "Responsive Design Mode"?

Now, that i never tried, it is a mysterious thing, but when
i enabled it i got a small window inside the normal window, and
then it looked just fine!  So i disabled that again, and resized
the browser window as such, and when the window is smaller than
470 then suddenly the content springs into existence!!
Thanks for this pointer!!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: В ответ на: Re: ? ????? ??: Re: FYI: forum web site is .. unreadable

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
<20200623153437.m2ntn%stef...@sdaoden.eu>:
 |Kostya Berger wrote in
 |<811812565.4605472.1592924651...@mail.yahoo.com>:
 |||вт, 23 июн. 2020 в 17:55 Steffen Nurpmeso
 ||| написал(-а):
 |||Gary Jennejohn wrote in
 |||<[2]20200623130733.658b4...@ernst.home[/2]>:
 On Tue, 23 Jun 2020 09:05:06 + (UTC)
 Kostya Berger <[3]berger...@yahoo.co.uk[/3]> wrote:
 ...
 > , 23 __. 2020 __ 10:32 Niclas Zeising n\
 > ic.[/4]\
 |
 |(Actually an error in my html filter, hm.)

Ha!  Not true!

  ; wrote: | | Looks fine in my Fir=
  efox. No such problems. Locally built Firefox. ... |  , 23 __. 2020 __ 10:32 Niclas Zeising=
  ;zeising+mailto:freebsd@daemonic.; href=3D"mai=
  lto:freebsd@daemonic.">freebsd@daemonic.\ |=
  ;  se __(-__):  On 2020-06-23 08:48, Gary Jennejohn w=
  rote: | On Tue, 23 Jun 2020 01:14:52 +0200https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: В ответ на: Re: ? ????? ??: Re: FYI: forum web site is .. unreadable

[Steffen Nurpmeso]

Kostya Berger wrote in
<811812565.4605472.1592924651...@mail.yahoo.com>:
 ||вт, 23 июн. 2020 в 17:55 Steffen Nurpmeso
 || написал(-а):
 ||Gary Jennejohn wrote in
 ||<[2]20200623130733.658b4...@ernst.home[/2]>:
 |||On Tue, 23 Jun 2020 09:05:06 + (UTC)
 |||Kostya Berger <[3]berger...@yahoo.co.uk[/3]> wrote:
 |||
 |||> Looks fine in my Firefox. No such problems. Locally built Firefox.
 ||...
 |||> , 23 __. 2020 __ 10:32 Niclas Zeising ic.[/4]\

(Actually an error in my html filter, hm.)

 |||> se> __(-__): On 2020-06-23 08:48, Gary Jennejohn wrote:
 |||>> On Tue, 23 Jun 2020 01:14:52 +0200
 |||>> Steffen Nurpmeso <[5]stef...@sdaoden.eu[/5]> wrote:
 ||...
 |||>>> Normally i do not do forums (web interface etc etc), but i was
 |||>>> interested in ZFS encryption support and so i searched, and found
 |||>>> a page[1].__ Now when i open that on a glibc Linux box with
 |||>>>
 |||>>>__ __ #?0|kent:src$ prt-get info firefox-bin
 ||...
 |||>>>__ __ Version:__ __ __ 77.0.1
 ||..
 |||>>> i.e. Mozilla.com-compiled firefox, then i see a small forum
 |||>>> "frame" on the right side, it is right of the "Foundation" link in
 |||>>> the link bar.__ It is just large enought to place "To be honest,"
 |||>>> in a single line, on a, well, pretty wide screen.
 |||>>>
 |||>>>__ __ [1] [6]https://forums.freebsd.org/threads/native-encryption-of-z\
 |||>>>fs.70\[/6]
 |||>>>284/
 |||>>>
 |||>>> Ciao, and good night from Germany,
 |||>>> 
 |||>> 
 |||>> I see exactly the same bad formatting with the standard firefox \
 |||>> port.__ All the
 |||>> text is pushed to the right.
 |||>> 
 |||>> seamonkey works, but it's been removed from ports.
 |||> 
 |||> It looks fine on my 1080p display, using Firefox from FreeBSD packages.
 |||
 |||I just installed the latest firefox from the package repository and \
 |||the forum page
 |||is still mis-formatted.
 |||
 |||This is the only website of the many I use which displays this error.
 |||
 |||My display is 2560x1440 (probably irrelevant). Not really all that \
 |||important
 |||to me in any case.
 |
 |  [2] mailto:20200623130733.658b4...@ernst.home
 |  [3] mailto:berger...@yahoo.co.uk
 |  [4] mailto:freebsd@daemonic.
 |  [5] mailto:stef...@sdaoden.eu
 |  [6] https://forums.freebsd.org/threads/native-encryption-of-zfs.70\
 |
 ||I have registered myself at the forum, but it is still unusable
 ||even thereafter. I looked at the source but i miss two decades of
 ||CSS etc. development to truly understand what there is, and since
 ||even the stylesheets are generated via monstrous URLs from a PHP
 ||script (!!) i cannot tell at all what is going on, to give a hint.
 ||But FreeBSD is not a marginal side note, even if i do not have
 ||a FreeBSD system with X display right now.
 |
 ||Accessing forums.freebsd.org via lynx "looks much better", but it
 ||says "JavaScript is disabled. For a better experience, please
 ||enable JavaScript in your browser before proceeding.".
 ||Forums are not for me, it was just for your interest.

 |Can it be due to some interference/filtering by your router or your \
 |ISP? I have never EVER seen such problem in Firefox on ANY system.

???  I cannot imagine this.

 |Did you try from Windows from the same place?

I have not used Windows in over twenty years, i do not know!

 |Anyway, you can try resetting your Firefox to defaults.

I am using a default Firefox, no add-ons or anything.  I only have
a stylesheet which increases the font used in menus, *if* that is
still used, actually, one of the versions passed changed that
i think, it is that ../chrome/userChrome.css file (and it took
many hours to find this possibility).

 |[1]Отправлено из Yahoo Почты для Android[/1]
 |
 |  [1] https://go.onelink.me/107872968?pid=InProductc=Global_Internal_\
 |  YGrowth_AndroidEmailSig__AndroidUsersaf_wl=ymaf_sub1=Internal&\
 |  amp;af_sub2=Global_YGrowthaf_sub3=EmailSignature

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ? ????? ??: Re: FYI: forum web site is .. unreadable

[Steffen Nurpmeso]

Gary Jennejohn wrote in
<20200623130733.658b4...@ernst.home>:
 |On Tue, 23 Jun 2020 09:05:06 + (UTC)
 |Kostya Berger  wrote:
 |
 |> Looks fine in my Firefox. No such problems. Locally built Firefox.
 ...
 |>   , 23 __. 2020 __ 10:32 Niclas Zeising   se> __(-__):   On 2020-06-23 08:48, Gary Jennejohn wrote:
 |>> On Tue, 23 Jun 2020 01:14:52 +0200
 |>> Steffen Nurpmeso  wrote:
 ...
 |>>> Normally i do not do forums (web interface etc etc), but i was
 |>>> interested in ZFS encryption support and so i searched, and found
 |>>> a page[1].__ Now when i open that on a glibc Linux box with
 |>>>
 |>>>__ __ #?0|kent:src$ prt-get info firefox-bin
 ...
 |>>>__ __ Version:__ __ __ 77.0.1
 ..
 |>>> i.e. Mozilla.com-compiled firefox, then i see a small forum
 |>>> "frame" on the right side, it is right of the "Foundation" link in
 |>>> the link bar.__ It is just large enought to place "To be honest,"
 |>>> in a single line, on a, well, pretty wide screen.
 |>>>
 |>>>__ __ [1] https://forums.freebsd.org/threads/native-encryption-of-zfs.70\
 |>>>284/
 |>>>
 |>>> Ciao, and good night from Germany,
 |>>>  
 |>> 
 |>> I see exactly the same bad formatting with the standard firefox \
 |>> port.__ All the
 |>> text is pushed to the right.
 |>> 
 |>> seamonkey works, but it's been removed from ports.
 |> 
 |> It looks fine on my 1080p display, using Firefox from FreeBSD packages.
 |
 |I just installed the latest firefox from the package repository and \
 |the forum page
 |is still mis-formatted.
 |
 |This is the only website of the many I use which displays this error.
 |
 |My display is 2560x1440 (probably irrelevant).  Not really all that \
 |important
 |to me in any case.

I have registered myself at the forum, but it is still unusable
even thereafter.  I looked at the source but i miss two decades of
CSS etc. development to truly understand what there is, and since
even the stylesheets are generated via monstrous URLs from a PHP
script (!!) i cannot tell at all what is going on, to give a hint.
But FreeBSD is not a marginal side note, even if i do not have
a FreeBSD system with X display right now.

Accessing forums.freebsd.org via lynx "looks much better", but it
says "JavaScript is disabled. For a better experience, please
enable JavaScript in your browser before proceeding.".
Forums are not for me, it was just for your interest.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FYI: forum web site is .. unreadable

[Steffen Nurpmeso]

Hello.

Normally i do not do forums (web interface etc etc), but i was
interested in ZFS encryption support and so i searched, and found
a page[1].  Now when i open that on a glibc Linux box with

  #?0|kent:src$ prt-get info firefox-bin
  Name: firefox-bin
  Path: /usr/ports/opt
  Version:  77.0.1
  Release:  1
  Description:  Firefox binary
  URL:  http://www.mozilla.com
  Maintainer:   Fredrik Rinnestam, fredrik at crux dot guru
  Dependencies: gtk3,dbus-glib

i.e. Mozilla.com-compiled firefox, then i see a small forum
"frame" on the right side, it is right of the "Foundation" link in
the link bar.  It is just large enought to place "To be honest,"
in a single line, on a, well, pretty wide screen.

  [1] https://forums.freebsd.org/threads/native-encryption-of-zfs.70284/

Ciao, and good night from Germany,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Happy birthday.

[Steffen Nurpmeso]

Just saw it and have seen nothing yet, and having reread GDBE
paper from BSDCON 2003 today: happy birthday FreeBSD!

You seem to have reached the age of Janis Joplin, Jim Morrison and
Jimmi (Hendrix)!  That makes optimistical.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Move from termcap(5) to terminfo(5)

[Steffen Nurpmeso]

Just my one cent.

Baptiste Daroussin wrote in
<20200507124126.g4z5op4cyv45p...@ivaldir.net>:
 |I can't find any proper rationale in our history (maybe I missed it) which
 |explains why our ncurses is stuck on using termcap(5) instead of terminf\
 |o(5)
 ...
 |I would like to make the move from termcap to terminfo which would \
 |give us the
 |bonus to be able to track terminfo sources from upstream aka ncurses and to
 |add and use tic(1).
 |
 |Given the very few people that are actually maintaining the termcap \
 |database. I
 |don't think there is a good rationale at keeping our own format (as \
 |far as I
 |know everyone moved to terminfo(5)) and parser.
 |
 |Without any strong arguments against it I will start working on that \
 |move by
 |next week.
 |
 |If you have some knowledge you want to share: "be careful about this \
 |or that" I
 |would be more than happy to collect it, to make sure the transition \
 |is as smooth
 |as possible.

If termcap is implemented by means of termcap and not by means of
internally converting termcap to curses which then does the job,
then termcap is a very small library and the terminal descriptions
almost as powerful.  They miss some keys, otherwise i do not know
what they miss.

Otherwise termcap is terribly expensive and my MUA tries to go for
-ltinfo before falling back to -lcurses or -lcursesw.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: New Xorg - different key-codes

[Steffen Nurpmeso]

Bob Willcox wrote in
<20200311214930.gc5...@rancor.immure.com>:
 |On Wed, Mar 11, 2020 at 02:48:56PM +0100, Michael Gmelin wrote:
 |>>> On 11. Mar 2020, at 10:29, Mark Martinec
 |>>>  wrote:
 ...
 | I just updated my laptop from source, and somewhere along the way
 | the key-codes Xorg sees changed.
 ...
 |> This *might* help you:
 |> 
 |> https://lists.freebsd.org/pipermail/freebsd-x11/2020-February/025046.html
 |> 
 |> (Short version: run setxkbmap in ~/.xinitrc, e.g.,
 |> setxkbmap -model pc105 -layout de)
 |
 |Will running that command return my key mappings back to what they \
 |use to be?

I for one am totally baffled that you all "just can go".
My ~/.xinitrc is (in parts)

  if command -v setxkbmap >/dev/null 2>&1; then
 if [ -f ~/.${HOSTNAME}.xkbmap ]; then
setxkbmap `cat ~/.${HOSTNAME}.xkbmap`
 elif [ -f ~/.xkbmap ]; then
setxkbmap `cat ~/.xkbmap`
 fi
  fi
  if command -v xmodmap >/dev/null 2>&1; then
 [ -f ~/.xmodmaprc ] && xmodmap ~/.xmodmaprc
 [ -f ~/.${HOSTNAME}.xmodmaprc ] && xmodmap ~/.${HOSTNAME}.xmodmaprc
  fi

  if command -v xrdb >/dev/null 2>&1; then
 [ -f ~/.Xdefaults ] && xrdb -merge ~/.Xdefaults
 [ -f ~/.${HOSTNAME}.Xdefaults ] && xrdb -merge ~/.${HOSTNAME}.Xdefaults
  fi

and i (i think ever) had to _have_ those (former being
'de(nodeadkeys)', the middle one too long to paste, but also works
around the "g" key of that Lenovo notebook ever since that stopped
working).

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Steffen Nurpmeso]

O. Hartmann wrote in <20190821145234.6fe455b4@freyja>:
 |I ran into serious trouble booting several boxes off UEFI. On modern \
 |hardware,
 |the ESP is around 200 - 300 MB in size and usually I install
 |/efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On \
 |some older
 |hardware, specifically on a Lenovo E540 with latest available firmware \
 |(2.28),
 |which uses 12-STABLE and a ZFS-only installation, there seems no working \
 |loader
 |anymore!
 |The installation of the Laptop has been performed using 12.0-PRERELEASE \
 |on an
 |Samsung EVO 860 500GB SSD. The ESP is 200M in size and contained
 |/efi/boot/BOOTx64.efi and /efi/boot/startup.nsh.

It may be that the Lenovo BIOS/firmware searches for that specific
Microsoft location

  EFI/Microsoft/Boot/bootmgfw.efi

Onto which i radically (according to docu) moved refind_x64.efi:

  #?0|kent:~# ll /mnt/EFI/Microsoft/Boot/bootmg*
  -rwxr-xr-x 1 root root 1453056 Sep 14  2018 
/mnt/EFI/Microsoft/Boot/bootmgr.efi
  -rwxr-xr-x 1 root root 1469752 Mar 21 17:43 
/mnt/EFI/Microsoft/Boot/bootmgfw.efi.safe
  -rwxr-xr-x 1 root root  208776 Mar 21 17:43 
/mnt/EFI/Microsoft/Boot/bootmgfw.efi

and that now finds its normal installation (etc.), simply copied
via cp(1):

  #?0|kent:~# ll /mnt/EFI/refind/
  total 260
  drwxr-xr-x 2 root root   4096 Mar 21 17:13 drivers_x64
  -rwxr-xr-x 1 root root 208776 Mar 21 17:14 refind_x64.efi
  drwxr-xr-x 3 root root   8192 Mar 21 17:18 icons
  drwxr-xr-x 2 root root   4096 Apr  8 13:39 vars
  drwxr-xr-x 5 root root   4096 Apr  8 13:39 ..
  -rwxr-xr-x 1 root root  32233 Apr 16 22:55 refind.conf
  drwxr-xr-x 5 root root   4096 Apr 16 22:55 .

  ...
 |What is wrong here? What am I missing?

Maybe that helps.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Danish FreeBSD Developer hates jews collectively

[Steffen Nurpmeso]

Rozhuk Ivan wrote in <20190510073249.73a17721@rimwks>:
 |On Thu, 09 May 2019 18:03:04 +
 |ossobser...@redchan.it wrote:
 |
 |> Background: Apparently a FreeBSD developer, a viking looking fellow,  
 |> has been hiding a secret: just as many of his predecessors in the
 |> Danish cities during WWII (collaborators); He has a disdain for "the
 |> jews" collectively.
 |> 
 |
 |Who cares!?

I want to point out one thing.  No, two.  One is that i concur
with all left hand side arguments of PHKs blog post that was
linked a 100 percent.  But that is my personal opinion.

The second is, and i think this is important, because over the
centuries it occasionally is forgotten by spiritless people like
the Nazis and then, short, "leads to massacres", small or
otherwise overwhelming, etc., and, furthermore, in difference to
the time before the first world war there was a tremendous amount
of spirit and art in the heaven under which we live, meaning that
topics were on the table, newspapers, universities, club talks
etc.  The "Jew" as in anti-semitism has never been anything else
than an allegory of bad characteristics present in each and every
homo sapiens sapiens (that cheetah thing).

It is an allegory.  Back in the day people like Richard Wagner
pointed their finger onto the yews and often in a way that
"everybody" knew that three fingers would point back, so even more
simple minded people would understand it is an allegory, and the
brain f.s would also have something to talk about.  Of course
it is true when Carl Dahlhaus says that "real Jews" had to stand
the consequences ([Wagner] "macht es dem Judentum – der Allegorie,
für die dann die realen Juden einstehen müssen"), but during the
time of Wagner no Jew had to suffer in Germany.  That was over
half a century later, and Mr.  Dahlhaus lived even later than
that.
But guess what the wonderful Daniel Barenboim reaped when he
and his orchestre started playing a Wagner piece in Israel?
Fanatic old-style jews started screaming and other terror.

Todays standards are mindless and dumb.  They guzzle life on
earth.  There is no Richard Wagner.  People are as wise and
intelligent as back then, they penetrated the physical, chemical,
biological essence of life intellectually even further than back
then, but they lost soul and spirit just as much, or even more.
No one dares to cross any line, while at the same time guzzling
life on earth.  That is pathological, that is delirious.
In short.  I am an antisemitist.  But this has nothing to do with
real Jews.  Despite that, the situation in Israel is
a catastrophe, and in Jemen, but let's just not talk about it.
Will ya?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Request for Review: Generate /etc/services from the IANA registry

[Steffen Nurpmeso]

Eric van Gyzen wrote in :
 |On 9/11/18 10:04 AM, Steffen Nurpmeso wrote:
 |> Alan Somers wrote in  w...@mail.gmail.com>:
 |>|Don't worry Steffen.  Python won't be a build requirement for FreeBSD \
 |>|even after Eric's patch.  His Python script will only need to be run \
 |>|whenever IANA
 |>|updates its database, and the results will be checked into source contro\
 |>|l.  So for a normal user, there is no change to "make buildworld && make
 |>|installworld".
 |> 
 |> I cannot, unfortunately.  I use binary updates and even
 |> preinstalled VM images (thanks for that, by the way).
 |
 |So there will be no impact on you at all, except that /etc/services will 
 |have a lot more services.  As Alan said, Python and XML will only be 
 |added to the developer workflow.

Oh please, of course.  For me personally the FreeBSD version is
good enough anyway, it is just that i discovered this script for
a pretty common Linux distribution, and adopted it for a lesser
common one when there was a need to update the DBs.  To be honest
i have discovered it in the packaging system in some repository,
and that is a pity.  FreeBSD as i got to know it, and i would have
snooped around in /usr/share/misc of a default install in that
case first, and if i would have been lucky i would have discovered
good stuff to help me out.  That is all.

 |>|As for Python vs Awk, I too tried to do this with Awk.  However, Awk \
 |>|can't easily handle things like IANA's representation of aliases, and \
 |>|it can't
 |>|easily format the list in the same order as our current list.  Python \
 |>|is truly a better choice.
 |> 
 |> I absolutely fail to see what you mean.  The script (which is in
 |> actual use, mind you) generates the desired output except that
 |> comments get lost, but this could be added upon interest, of
 |> course.  It (or a derivative) would have been a good candidate for
 |> /usr/share/misc/ in elder times i guess, too.
 |
 |That awk script depends on the formatting of the XML file.  It will 
 |break if the IANA decides to format it differently.  Granted, this is 
 |unlikely, but it's possible.

If you argue like this, anything is possible, is it.  If IANA
changes the XML tags, the Python script needs to be adjusted, too.
And if you ask me, i would vote for, and change to JSON.  No
offense, i said the same on a Unicode list, for example.

 |Also, that script would become much more complex if it supported local 
 |additions and overrides, which are unfortunately necessary in our case.

Come one.  I mean, come on.  What are you talking about?  You have
written these things, and they will likely enter FreeBSD.  This
does not make it just just any better in my eyes.  (Though the
counting program could be adjusted and be used as a test if the
sorted output would be compared against a sed(1) run on
/etc/services.)  If it would be me, a very small awk script would
enter /usr/share/misc, and some makefile would be adjusted and
call it, or a duplicate.  Base system self-contained, and some
nice hint to be found for someone who looks around.

I mean, i really looked out of interest at some review page in the
webbrowser (glad that you posted this for people who do not like
browsers that much, or get email notifications or whatever), which
was so large or whatever, anyway it blocked the tab.  Isn't that
absurd for a simple update framework for IANA databases in /etc?
(And what about protocols, by the way.)
Just my one cent, of course.  I am not even a developer.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Request for Review: Generate /etc/services from the IANA registry

[Steffen Nurpmeso]

Alan Somers wrote in :
 |Don't worry Steffen.  Python won't be a build requirement for FreeBSD \
 |even after Eric's patch.  His Python script will only need to be run \
 |whenever IANA 
 |updates its database, and the results will be checked into source contro\
 |l.  So for a normal user, there is no change to "make buildworld && make 
 |installworld".

I cannot, unfortunately.  I use binary updates and even
preinstalled VM images (thanks for that, by the way).

 |As for Python vs Awk, I too tried to do this with Awk.  However, Awk \
 |can't easily handle things like IANA's representation of aliases, and \
 |it can't 
 |easily format the list in the same order as our current list.  Python \
 |is truly a better choice.

I absolutely fail to see what you mean.  The script (which is in
actual use, mind you) generates the desired output except that
comments get lost, but this could be added upon interest, of
course.  It (or a derivative) would have been a good candidate for
/usr/share/misc/ in elder times i guess, too.

 |-Alan

Ciao.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Request for Review: Generate /etc/services from the IANA registry

[Steffen Nurpmeso]

Eric van Gyzen wrote in <59cd421e-f5d4-855a-83ec-65726f792...@vangyzen.net>:
 |On 9/10/18 12:04 PM, Eric van Gyzen wrote:
 |> Would anyone like to review this change to generate /etc/services from 
 |> the IANA registry?
 |> 
 |>  https://reviews.freebsd.org/D17106
 |
 |If that review made your browser unhappy, try this one instead:

Yes it did.

 | https://reviews.freebsd.org/D17115

I mean, i have nothing to do with FreeBSD except that i use it
since 4.7 (though some yours only indirectly as Mac OS X), and
i am in opposition to quite some directions taken, but who am i,
that is ok, i have a very narrow use case.  But this is one of the
things i really do not understand, bringing XML and Python stuff
needlessly into FreeBSD seems very odd.  For example, ArchLinux
and CRUX Linux use a simple portable awk script to generate
services and protocols, and all you need to count the number of
services is a normal Unix pipeline which strips comments and then
calls wc -l.  I'll paste the script below this.  Thank you.
And ciao already here

#!/bin/sh -
#@ Update protocols and services from IANA.
#@ Taken from ArchLinux script written by Gaetan Bisson.  Adjusted for CRUX.

awk=awk
curl=curl
url_pn=https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml
url_snpn=https://www.iana.org/assignments/service-names-port-numbers/\
service-names-port-numbers.xml

datetime=`date +'%FT%T%z'`

download() {
   echo 'Downloading protocols'
   ${curl} -o protocols.xml ${url_pn}
   [ ${?} -eq 0 ] || exit 20
   echo 'Downloading services'
   ${curl} -o services.xml ${url_snpn}
   [ ${?} -eq 0 ] || exit 21
}

process() {
   echo 'Processing protocols'
   ${awk} -F "[<>]" -v URL="${url_pn}" -v DT="${datetime}" '
  BEGIN{
 print "# /etc/protocols, created " DT
 print "# Source: " URL
  }
  / protocols.new
   [ ${?} -eq 0 ] || exit 30

   echo 'Processing services'
   ${awk} -F "[<>]" -v URL="${url_snpn}" -v DT="${datetime}" '
  BEGIN{
 print "# /etc/services, created " DT
 print "# Source: " URL
  }
  / services.new
   [ ${?} -eq 0 ] || exit 31
}

update() {
   mv protocols.new protocols
   [ ${?} -eq 0 ] || exit 40
   mv services.new services
   [ ${?} -eq 0 ] || exit 41
   rm -f protocols.xml services.xml
}

download
process
#update

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Would O_APPEND for /dev/null be possible?

[Steffen Nurpmeso]

and i wrote:
  ...
 |The POSIX standard says that the error condition shall be set if
 |a read or write error occurs only, but this should not be the case
 |here, no?  So looking at [master]:lib/libc/stdio/fseek.c:_fseeko()
 |(note my machine is not strong enough to compile any compiler (but
 |pcc, tcc) or even operating systems, i cannot verify) there is
 |only one condition where the stream error indicator is set, after
 |the dumb: label.
 |
 |I would expect the error indicator for a failing __srefill() or
 |__sflush() (only: not following branches), but _here_ it is set
 |for a "long overflow" check failure.  This looks wrong to me, but
 |of course: without having any idea nor test possibilities.  Also
 |note this is 32-bit FreeBSD, can it be that /dev/null -2L,SEEK_END
 |sees enters 64-bit range?  That also feels wrong, for /dev/null
 |anyway, where it should not matter and simply succeed.  (The
 |tested OpenBSD was 32-bit, too.)

Also, the return of fseek(3) is "int", so testing LONG_MAX looks
a bit odd as such, from my point of view?

Ciao.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Would O_APPEND for /dev/null be possible?

[Steffen Nurpmeso]

i wrote:
 |Bryan Drewery <bdrew...@freebsd.org> wrote:
 ||On 8/7/2017 2:36 PM, Steffen Nurpmeso wrote:
 ||> I can open a file with "a+", which, for this software, means
 ||> "O_RDWR | O_APPEND | O_CREAT | n_O_NOFOLLOW" on Linux, Solaris and
 ||> OpenBSD, but FreeBSD complains, i think because O_APPEND.  (I
 | ...
 ||> openat(AT_FDCWD,"/dev/null",O_RDWR|O_APPEND|O_NOFOLLOW|O_CREAT,037625\
 ||> 2\
 ||> 0) = 3 (0x3)
 ||
 ||Seems to work fine.
 ..
 |locking, so i thought ...  Hmm, this is even more complicated than
 |i thought, wait, i have to debug that.  And: it turns out that
 |a fseek(3) on the descriptor opened not only fails but sets the
 |ferror(3) state of the FILE!  I would need to look into the
 |standard whether this behaviour is correct, but in any case we are
 |not prepared for that, and neither of Linux, Solaris nor OpenBSD
 |enter this condition.

The POSIX standard says that the error condition shall be set if
a read or write error occurs only, but this should not be the case
here, no?  So looking at [master]:lib/libc/stdio/fseek.c:_fseeko()
(note my machine is not strong enough to compile any compiler (but
pcc, tcc) or even operating systems, i cannot verify) there is
only one condition where the stream error indicator is set, after
the dumb: label.

I would expect the error indicator for a failing __srefill() or
__sflush() (only: not following branches), but _here_ it is set
for a "long overflow" check failure.  This looks wrong to me, but
of course: without having any idea nor test possibilities.  Also
note this is 32-bit FreeBSD, can it be that /dev/null -2L,SEEK_END
sees enters 64-bit range?  That also feels wrong, for /dev/null
anyway, where it should not matter and simply succeed.  (The
tested OpenBSD was 32-bit, too.)

Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Would O_APPEND for /dev/null be possible?

[Steffen Nurpmeso]

Good evening.

Bryan Drewery <bdrew...@freebsd.org> wrote:
 |On 8/7/2017 2:36 PM, Steffen Nurpmeso wrote:
 |> I can open a file with "a+", which, for this software, means
 |> "O_RDWR | O_APPEND | O_CREAT | n_O_NOFOLLOW" on Linux, Solaris and
 |> OpenBSD, but FreeBSD complains, i think because O_APPEND.  (I
 ...
 |> # cat uh.c
 |> #include 
 |> #include 
 |> 
 |> int main() {
 |> int fd;
 |> 
 |> fd = open("/dev/null", O_RDWR | O_APPEND | O_CREAT | O_NOFOLLOW);
 |> if (fd == -1)
 |> err(1, "open");
 |> return 0;
 |>}
 |
 |> # truss ./uh
 |...
 |> openat(AT_FDCWD,"/dev/null",O_RDWR|O_APPEND|O_NOFOLLOW|O_CREAT,0376252\
 |> 0) = 3 (0x3)
 |
 |Seems to work fine.

Puh. ...  I really looked, logically this codepath should not use
locking, so i thought ...  Hmm, this is even more complicated than
i thought, wait, i have to debug that.  And: it turns out that
a fseek(3) on the descriptor opened not only fails but sets the
ferror(3) state of the FILE!  I would need to look into the
standard whether this behaviour is correct, but in any case we are
not prepared for that, and neither of Linux, Solaris nor OpenBSD
enter this condition.

(What i did is with the MUA i maintain use the rather useless
`write' command which by default writes to /dev/null, this stacks
over c_write()[1] over to save1()[2] which does a lot of stuff,
anyway /dev/null opened via n_fopen_any()[3] to MBOX preparation
call n_folder_mbox_prepare_append()[4] which is defined here[5].
This never made problems yet, but of course i admit it is
a generalization (of several instances of rather identical code in
former versions of this MUA) which is truly bad and will,
hopefully, in a distant future be replaced by a "Mailbox" object
which then has some kind of Mailbox::append() (or prepare_append()
first if anything else fails), and that could act better for some
special files.  Anyway, that not today.)

  [1] https://git.sdaoden.eu/cgit/s-nail.git/tree/cmd-write.c#n380
  [2] https://git.sdaoden.eu/cgit/s-nail.git/tree/cmd-write.c#n56
  [3] https://git.sdaoden.eu/cgit/s-nail.git/tree/cmd-write.c#n145
  [4] https://git.sdaoden.eu/cgit/s-nail.git/tree/cmd-write.c#n168
  [5] https://git.sdaoden.eu/cgit/s-nail.git/tree/folder.c#n900

Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Would O_APPEND for /dev/null be possible?

[Steffen Nurpmeso]

I can open a file with "a+", which, for this software, means
"O_RDWR | O_APPEND | O_CREAT | n_O_NOFOLLOW" on Linux, Solaris and
OpenBSD, but FreeBSD complains, i think because O_APPEND.  (I
think only because the VM does not survive resumes and other
pauses here, which frustrated me over time.  It is old VM.)
I mean, it seems i have to sprinkle more /dev/null string
comparisons all over the place, but i wonder whether that really
belongs there.. for /dev/null?

Well, now that i am here.  I have installed pcc and tcc ports
because clang is much too slow, especially in VM, but they cannot
be used because of mysterious attributes in some system header.
I usually compile them on my own, but that did not help on FreeBSD
too, at least not last time i tried.  This is a bit of a pity,
i have not tried it myself but one of the core developers of the
tiny CC, who was part of ELF development, said, once that
happened, that he made it compile the Linux kernel (!) again and
"that seems to work", so it is a *real* pity that not even rather
primitive C89 user programs can be compiled (with those
compilers).  That on v11.1, and with pkg stuff.

Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: The futur of the roff toolchain

[Steffen Nurpmeso]

Mr. McKusick,

Kirk McKusick  wrote:
 |Thanks for all your work on this project. As I still use roff for
 |our book and for many of my presentations, it is a topic of interest
 |to me. That said, I am fine with roff dropping out of base as I can
 |easily enough bring it in from ports. And I am curious to try using
 |heirloom doctools on our book to see if it works. We do some pretty
 |evil things with diversions, so I can easily believe that it will
 |not work. But it would be great if it does work, because the groff
 |in base has some bugs that are annoying to work around.

i would be interested to hear about all bugs for future references.
I will continue to work on the GPLv2 clone of GNU roff -- that
i will maintain -- again in the nearer future, and have brought
that almost in sync with v1.22.3 years before.  (In sync, but
having left off some things which touch code, and that is GPLv3.
Etc.)
I have not seen annoying bugs in my daily, very unscientific
though, use of the FreeBSD version of groff for what can be called
many years.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r302185 - head/release/doc/en_US.ISO8859-1/relnotes

[Steffen Nurpmeso]

Glen Barber <g...@freebsd.org> wrote:
 |On Sat, Jun 25, 2016 at 03:02:11PM +0200, Steffen Nurpmeso wrote:

 |>|  A selection of system daemons, including:
 |>|  fingerd,
 |>|  ftpd,
 |>|- rlogind,
 |>|- rshd, and
 |>|- sshd have been modified to support
 |>|+ rlogind, and
 |>|+ rshd have been modified to support
 |>|  sending notifications to the blacklistd
 |>|  daemon.
 |> 
 |> Allow me to continue hoping nonetheless.
 |> In this great future, you can't forget your past.
 |
 |I hope the issues can be resolved before 11.0-RELEASE.  I personally
 |look forward to this change, but the revert was necessary.

It is very likely that you and D.E. Smørgrav are right, and then
11.0 is to be expected for September.

In fact i was only looking at this from a very narrow user
perspective and, in addition, never liked that log files have to
be parsed to recollect states that were known by the generating
daemon.  It can only be that commercial software does this better,
more integrated, but i don't know.  So once the blacklistd idea
came up, which was, if i recall correctly, shortly after DragonFly
BSD introduced their own logfile analyzer, didn't they?, i was
kind of thrilled, because isn't that the first time that the right
thing is done to face that problem?

In my opinion it would be great if all servers that listen to the
outside world would gain the necessary hooks for "bad command",
"bad login", "good login", possibly more.  This would create an
integrated, synchronous mesh of firewall and servers, so talking
about clowds.., i am looking forward to this.  If rules would
become more sophisticated, e.g., "user IP tried to post messages
with more than X KB the Y time", and that could be taken into
account.  And then it also requires less CPU time and thus energy,
then having a logfile analyzer running in addition.

Thank you.  Have a nice weekend.

--steffen
___
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: svn commit: r302185 - head/release/doc/en_US.ISO8859-1/relnotes

[Steffen Nurpmeso]

 |Author: gjb
 |Date: Fri Jun 24 23:42:33 2016

Sigh.

 |Log:
 |  Update the release notes following r302182.

 |  A selection of system daemons, including:
 |  fingerd,
 |  ftpd,
 |- rlogind,
 |- rshd, and
 |- sshd have been modified to support
 |+ rlogind, and
 |+ rshd have been modified to support
 |  sending notifications to the blacklistd
 |  daemon.

Allow me to continue hoping nonetheless.
In this great future, you can't forget your past.

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

blacklistd and base-system's sendmail

[Steffen Nurpmeso]

Hello,

thank you for importing NetBSD's blacklistd into FreeBSD, that
really was great news!  For those of us who don't want to have
a logfile analyzer running that needs to reevaluate things which
the program who produced the entry already knew.

I have my very own exposed server since 2016, the first such ever
(the first six weeks with FreeBSD with services via inetd and five
lines more ipfw rules than i normally have, that was essentially
it, currently AlpineLinux, because i haven't really done anything
with Linux since 2002 and wanted to get up-to-date, so then using
it, too, but i will come back to FreeBSD, for s sure), and it
seems i can get away with some firewall rules and traffic shaping
to declassify some of those players which seem to be around.

The most annoying thing that still happens is that mostly
"unknown" people connect to the SMTP server, and then drop the
connection without doing something useful: it is a valid
connection, the connection rate is so low that it doesn't trigger
the shaper, but if you have 60 connections which don't do
something an hour then it produces a lot of noise in the log.

I was hoping that blacklistd would catch those
"nonsense-connections", leaving me with a small and
self-contained, all C/C++ base system.  In particular none of
those pkg-managed log parsers which are mostly Python, or Perl,
but anyway bring in a lot of dependencies for nothing (but parsing
log output of servers and thus reevaluate state that was known to
the generating server).  I.e., NanoBSD the base system and then
get away with normal -- thanks again for all of this, it is
fantastic! -- FreeBSD binary updates.

I would like to kindly ask why it seems as if the blacklistd
support is not patched into sendmail?  That is a real pity!  It is
only local by default, what that HTML review thing says, but with
a single line in inetd, for example, you can have your
world-accessible receiver and you always get the world-wide
sender.  That is enough for even many even "mid-size" companies
i'd assume.  Being protected against the mentioned attacks from
the base system with no further administrative effort i would
appreciate a lot, and i think blacklistd has this capability?

Thanks for your consideration, and have a nice weekend.
Ciao,

--steffen
___
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: [RFC] Replace gnu groff in base by heirloom doctools

[Steffen Nurpmeso]

Baptiste Daroussin b...@freebsd.org wrote:
 |On Sat, May 16, 2015 at 01:42:26AM +0200, Julian H. Stacey wrote:

 | I think keeping a fully functionnal roff(7) toolchain part of the
 | base system is very good on a unix.

 | From what I could check I cannot find any regression when \
 | migrating from gnu
 | groff to heirloom doctools, if there is a particular area \
 | when you think extra
 | care is needed please share it.

It seems you haven't checked at all.
It seems to me that e.g. mdoc(7) of n-t-r seems to require quite
a bit of work in order to be at all usable.

 |Heirloom in base is a win over groff because it has better \
 |support for roff(7)
 |better font handling etc.

The macros i use for myself don't work with n-t-r, too: once
i truly looked (a few months ago) i found that i would have to
rewrite all traps and other positioning in order to get that
right.

Despite that you seem to do what you want to do anyway, n-t-r is
possibly a usable troff, if you go its way and deal with it you
may be able to gain a bit nicer output _faster_ and without
converting your beloved special fonts first, but in no way is
n-t-r a _replacement_ for groff.
Ciao,

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

Re: [RFC] Replace gnu groff in base by heirloom doctools

[Steffen Nurpmeso]

Hello,

Baptiste Daroussin b...@freebsd.org wrote:
 |On Tue, May 19, 2015 at 02:37:22PM +0200, Steffen Nurpmeso wrote:
 | Baptiste Daroussin b...@freebsd.org wrote:
 ||On Sat, May 16, 2015 at 01:42:26AM +0200, Julian H. Stacey wrote:
 | 
 || I think keeping a fully functionnal roff(7) toolchain part of the
 || base system is very good on a unix.
 | 
 || From what I could check I cannot find any regression when \
 || migrating from gnu
 || groff to heirloom doctools, if there is a particular area \
 || when you think extra
 || care is needed please share it.
 | 
 | It seems you haven't checked at all.
 | It seems to me that e.g. mdoc(7) of n-t-r seems to require quite
 | a bit of work in order to be at all usable.
 |
 |Lots of work has been done recently on heirloom in particular regarding
 |the support of mdoc(7) and I have opened tickets for all issues \
 |I could find and
 |they have been fixed. Please point me to issues you can have \
 |regarding mdoc(7).

.Ns doesn't work right, so is why this strong emphasis of mine in
the first sentence.  Carsten has this example of mine (last week):

  .Dd Apr 30, 2015
  .Dt xxx 1
  .Os
  .Sh NAME
  .Nm xxx
  .Nd yyy
  .
  Read the system mailbox of
  .Ar user
  (appropriate privileges presumed), and
  .Dq assume to be
  .Ar user
  in some aspects, e.g. in respect to
  .Ic file Ns
  \(enexpansions of
  .Ql %
  etc.; also see
  .Ev USER .

 |(Note that I'm speaking of doctools as of latest git, not latest release)

As of last week right shortly after your mail i guess it was.

 ||Heirloom in base is a win over groff because it has better \
 ||support for roff(7)
 ||better font handling etc.
 | 
 | The macros i use for myself don't work with n-t-r, too: once
 | i truly looked (a few months ago) i found that i would have to
 | rewrite all traps and other positioning in order to get that
 | right.
 |
 |Can you tell me more about the macros you do use and a sample \
 |document so I can
 |check and see if we can add support for it?

Well Carsten asked me this too last year and i've given him as
much as i could.  But the macros are really rather simple layout
via traps.  If i recall correctly the examples i've shown Carsten
where letters.  I would have to rewrite the macros before i can
make them public, but it is pretty normal troff stuff with
traps and positioning, like e.g. the context-free following, for
an example (i think i have sent Carsten some trap info back then?)

  .MACRO RECEIVER
  .  S:BOOLIFY \\$1
  .  ie \\n[S:#IS_BOOL] \{\
  . vs \\n(.su*\\*[RECEIVER_LINE_SPACING_SCALE_FACTOR]
  . nf
  . de S:RECEIVER_TRAP EOT
  .blm PARA
  .ds S:RECEIVER_DIVERSION_HOOK
  .sp 1v
  \\*[RECEIVER_PREHOOK]\c
  .EOT
  . di S:RECEIVER_DIVERSION
  . blm S:RECEIVER_TRAP
  .  \}
  .  el \{\
  . if d S:RECEIVER_DIVERSION_HOOK \{\
  \\*[RECEIVER_POSTHOOK]\c
  .rm S:RECEIVER_DIVERSION_HOOK
  . \}
  . di
  . \ Calculate best position for address field and box out
  . if (\\n(dnu  \\n[#RECEIVER_HEIGHT]u) \{\
  .WARNING \
  \\$0 address does not fit in address window! Growing window!!
  .nr #RECEIVER_HEIGHT \\n(dnu
  . \}
  . nr #1 (\\n[#RECEIVER_HEIGHT]u-\\n(dnu)/2u
  . sp |(\\n[#RECEIVER_START]u+\\n(#1u
  . rr #1
  . S:RECEIVER_DIVERSION
  . rm S:RECEIVER_DIVERSION
  . rm S:RECEIVER_TRAP
  . fi
  . vs
  .  \}
  ..

Pretty clean letter stuff like that it is.  (You asked for an
example.)

 | Despite that you seem to do what you want to do anyway, n-t-r is
 | possibly a usable troff, if you go its way and deal with it you
 | may be able to gain a bit nicer output _faster_ and without
 | converting your beloved special fonts first, but in no way is
 | n-t-r a _replacement_ for groff.
 |
 |As I said you will be able to use groff from ports. I do not \

I will have my own one, then.  Enough work for getting old.  d^.^b

 |claim that n-t-r is
 |a replacement for groff in general I propose it for a replacement \
 |for groff in
 |base.
 |
 |groff in base is stuck at 1.19.2 version while upstream is at 1.22.3 version
 |which in particular has a couple of fixes for mdoc(7) format and a bit more.

The mdoc(7) macros are BSD licensed.  Nothing prevents anyone from
taking those from GNU troff [master] branch and integrating them
into their own roff version.  I did that for (the one that will
be) mine.

 |Every user of groff will have huge benefit using newer groff versions: bug
 |fixes, full functionnalities available etc.

The above macros originate from stuff written under FreeBSD 4.9
and especially 5.3 and ran almost a decade there, very smoothly.
Also i'm not so sure about that huge when i compare groff
1.19.2-574-gecbf4f1 (which is the last GPL2 commit) and 1.22.3.
Also Carsten said that.  Until now i have indeed assumed it is
purely rhetoric.

Out of interest: what do you mean when you say full
functionality?  I see some improvements in the line breaking
algorithm