On 12/29/20 7:15 AM, Kristof Provost wrote:
On 29 Dec 2020, at 4:33, monochrome wrote:
sry forgot details:
source tree @ ead01bfe8
git -C /usr/src checkout gf20c0e331
error: pathspec 'gf20c0e331' did not match any file(s) known to git
what is the 'g' for?
That would have been a typo, I
Thank you.
I already read this thread while researching.
Doesn't help me, because not a single "Digital" output/device appears in
my FreeBSD 13.0-CURRENT System:
pcm0: on emu10kx0
pcm0:
pcm1: on emu10kx0
pcm2: on emu10kx0
pcm3: on emu10kx0
These 4 or 5 are just analog outputs/devices.
Hi there.
I'm using FreeBSD (13.0-CURRENT) since 09/2020 at my Raspberry Pi 4B as
Home-and-Web-Server-OS with Apache, PHP, SQLite etc... And it works like
a charm!
Furthermore I'm trying to switch with my main workstation from Win10 to
FreeBSD too. Because the more I'm working with FreeBSD,
https://forums.freebsd.org/threads/console-player-and-s-pdif-toslink.63371/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
On 29 Dec 2020, at 4:33, monochrome wrote:
sry forgot details:
source tree @ ead01bfe8
git -C /usr/src checkout gf20c0e331
error: pathspec 'gf20c0e331' did not match any file(s) known to git
what is the 'g' for?
That would have been a typo, I think.
git -C /usr/src checkout f20c0e331
M
On 2020-12-29 02:56, Pete Wright wrote:
>
> On 12/28/20 4:38 PM, monochrome wrote:
>> what would be the git command for reverting source to a previous
>> version using these numbers? for example, with svn and old numbers:
>> svnlite update -r367627 /usr/src
>>
> I will generally just checkout the
ok, this appears to be what I was looking for
example:
git reset --hard f20c0e331
then:
git pull --ff-only
is again able to update as normal
I should point out also that this is from the point of view of any
random person just building freebsd from source, not a developer, so
there are no
monochrome:
> the g is also in the uname output:
>
> main-c421-gf20c0e331-dirty
It's the brand new format: -c-g[-dirty]
https://cgit.freebsd.org/src/commit/sys/conf/newvers.sh?id=8d405efd73d3991fe1647f91a2b7c9989dd5f18f
--
Christian "naddy" Weisgerber
On 2020-12-29 17:11, monochrome wrote:
> ok, this appears to be what I was looking for
>
> example:
> git reset --hard f20c0e331
> then:
> git pull --ff-only
> is again able to update as normal
>
> I should point out also that this is from the point of view of any
> random person just building
On 29/12/20 18:38, Andriy Gapon wrote:
On 2020-12-29 17:11, monochrome wrote:
ok, this appears to be what I was looking for
example:
git reset --hard f20c0e331
then:
git pull --ff-only
is again able to update as normal
I should point out also that this is from the point of view of any
random
Hi freebsd-hackers@, CC'd freebsd-current@,
I hope you all had a wonderful holiday season.
I recently got a HP Spectre x360 13t-aw200 which is an Intel
TigerLake-based laptop. It has the Intel "Evo" branding and an "Optane"
SSD which I disabled (so I can get a "second" SSD).
On the Spectre,
On recent 12-STABLE, 12.1-RELENG and 12.2-RELENG I face a very nasty problem
which
occured a while ago after it seemed to have vanished for a while: running ssh
in a xterm
on FreeBSD boxes as mentioned at the beginning ends up very rapidly in a lost
connection
with
# Fssh_packet_write_wait:
>> SHA-256 arrives, if you look at the git history.
> git's SHA-256 [...] requiring a super new git version to even test it out.
It's "in" current release 2.30.0 and before, duly caveated as experimental
and not fully featured yet...
git-init(1)
--object-format=
Specify the
On 2020-12-29 16:46, John-Mark Gurney wrote:
Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100:
|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
Hi,
Post r367671...
When multiple files are being created by an NFS client in the same
directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP.
This results in a EIO return to the NFS client.
--> This causes "nfsv4 client/server protocol prob err=10026"
on the client for NFSv4.0
On 2020-12-29 20:59, Chris wrote:
On 2020-12-29 16:46, John-Mark Gurney wrote:
Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100:
|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
Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100:
> |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
If you are exporting UFS file systems via NFS and your kernel is
built from head/current sources newer than Nov. 15
(r367672 or newer), the NFS service will be broken.
The only workaround is to turn both SU and SU+j off for the
exported file systems via tunefs.
rick
On Mon, Dec 28, 2020 at 12:44:18PM -0800, John Baldwin wrote:
> On 12/28/20 12:24 PM, John Baldwin wrote:
> > I got this panic again today in a VM when quitting a gdb
> > session after killing a child process via 'kill'.
> >
> > panic: Assertion pgrp->pg_jobc > 0 failed at
> >
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
On 12/29/20 7:11 AM, monochrome wrote:
> ok, this appears to be what I was looking for
>
> example:
> git reset --hard f20c0e331
> then:
> git pull --ff-only
> is again able to update as normal
>
> I should point out also that this is from the point of view of any
> random person just building
21 matches
Mail list logo
