t know what a reflog is,
yet ;-)
Thus: Should I use "-m" or "-M" in my scenario when switching from stable/12 to
stable/13 in the near future?
Thanks and regards,
Michael
___
freebsd-current@freebsd.org mailing list
https://lists.fr
> On 15. Dec 2020, at 08:44, Matthias Apitz wrote:
>
> El día lunes, diciembre 14, 2020 a las 10:16:21a. m. +0100, Matthias Apitz
> escribió:
>
>> I did a step by step down grading with 'svn up -r. hdaa.c hdaa.h'
>> (only these two files), starting from r368166 down to the following
>>
the panic output included below under QEMU and leaves nothing in
/var/crash
What expectations should I set for RISC-V STABLE and CURRENT?
All the best,
Michael
t[0] == 0xffc0006c9d98
t[1] == 0x40c5
t[2] == 0x40c65000
t[3] == 0x0001
t[4] == 0x
> On 11. Dec 2020, at 15:51, Jakob Alvermark wrote:
>
>
>> On 12/11/20 8:06 AM, Matthias Apitz wrote:
>>> El día miércoles, diciembre 09, 2020 a las 11:55:18a. m. +0100, Hans Petter
>>> Selasky escribió:
>>>
>>> On 12/9/20 11:48 AM, Matthias Apitz wrote:
El día miércoles, diciembre
kern/elf_load_obj.c off the top of my head), looked at mailing
> >> list archives and forums etc, all to no avail.
> >>
> >> I have / on UFS+J and /usr on ZFS and nothing in /etc/src.conf. I
> >> had /etc/malloc.conf with the recommended symlink from UPDATING,
> >> but the same happens with that moved out of the way. Nothing seems
> >> to help.
> >>
> >> Do I need to go back further to get into a usable state or is
> >> there something else I should be doing?
> >
> > With very few exceptions (bug 250897, 2020/11/6), I've found
> > 13-current bootable since 10/26 (up through my current system, 13.0
> > r368388 (2020/12/6). You obviously need to make sure that an extra
> > drivers you add in are compiled against the kernel, but ZFS is
> > typically one of those.
>
> I think we covered that.
>
> Thanks for the help and the pointers, but unfortunately the mystery
> remains.
>
Do you have anything in /boot/modules?
(wild shot)
-m
--
Michael Gmelin
___
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"
On 12/7/20 2:40 PM, Mitchell Horne wrote:
My bad, the extra '=' is a typo. It should be:
-append "vfs.root.mountfrom=ufs:/dev/vtbd0p3"
That worked perfectly and I added it to the wiki page:
https://wiki.freebsd.org/riscv
All the best
Thank you and keep up the good work!
Michael
___
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"
rrdev="vtbd0p3"
Or these in the fstab:
/dev/gpt/rootfs / ufs rw,noatime 1 1
/dev/vtbd0p3 / ufs rw,noatime 1 1
Are there any other options? Perhaps building the device name into the
kernel?
Thank you!
Michael
> On 26. Nov 2020, at 19:21, Gary Jennejohn wrote:
>
> On Thu, 26 Nov 2020 10:44:19 -0700
> Warner Losh wrote:
>
>>> On Thu, Nov 26, 2020 at 4:16 AM Michael Gmelin wrote:
>>>
>>>
>>>
>>> On Thu, 26 Nov 2020 10:12:06 +0100
>&
simple
> > > searches.
> >
> > For SAS drives, there's a mode page that controls this behavior.
> >
> > You might see if the sysutil/ataidle port/package does what you
> > want.
>
> Thanks, Warner, but that port is not in my HEAD ports tree. It's
>
Not for me, it's not ..
imb@toshi:/usr/src/usr.sbin/pkg> pkg info -a
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: n
And yet ..
imb@toshi:/home/imb> ll /usr/local/sbin/pkg
-rwxr-xr-x 1 root wheel 2890304 Oct 11 09:54
Thank you, Kostya and Mark!
I will update to head. :)
On Tue, Sep 29, 2020 at 4:32 PM Mark Johnston wrote:
> On Tue, Sep 29, 2020 at 04:20:26PM +0300, Konstantin Belousov wrote:
> > On Tue, Sep 29, 2020 at 02:59:43PM +0300, Michael Zhilin wrote:
> > > Hi,
> > >
Hi,
I'm using FreeBSD 13-CURRENT (pre-ZoF, r359724) on my laptop with installed
Gnome. Sometimes
(once a week/month) gnome hangs and the system may be still responsible
(may be not).
This week it happened again and I've gathered information via ddb/textdump
and rebooted laptop.
gnome-shell is
On 9/20/20 10:58 AM, Mark Murray wrote:
Hi *
I've been getting these build failures for a while (weeks/months). The machine is a MacchiatoBin
DoubleShot (arm64, Quad core). with SATA disks and zfs filesystem. If I empty out /usr/obj, then
the build works, but takes a few hours. If I do a
> On 16. Sep 2020, at 22:53, Michael Gmelin wrote:
>
>
>
>>> On 16. Sep 2020, at 22:45, mike tancsa wrote:
>>>
>>> On 9/16/2020 2:07 PM, sth...@nethelp.no wrote:
>>> # override default of no subsystems
>>> -Subsystemsftp/u
> On 16. Sep 2020, at 22:45, mike tancsa wrote:
>
> On 9/16/2020 2:07 PM, sth...@nethelp.no wrote:
>> # override default of no subsystems
>> -Subsystemsftp/usr/libexec/sftp-server
>> +Subsystemsftpinternal-sftp -l INFO
>
> Hi,
>
> What is the difference between these two ?
> On 16. Sep 2020, at 20:08, sth...@nethelp.no wrote:
>
>
>>
>> FTP is (becoming?) a legacy protocol, and I think it may be time to
>> remove the ftp server from the FreeBSD base system - with the recent
>> security advisory for ftpd serving as a reminder.
>>
>> I've proposed adding a
> On 12. Sep 2020, at 11:06, Hartmann, O. wrote:
>
> On Sat, 12 Sep 2020 10:03:18 +0200
> Michael Gmelin wrote:
>
>>> On 12. Sep 2020, at 09:55, Hartmann, O.
>>> wrote:
>>> On Fri, 11 Sep 2020 07:18:33 -0600
>>> Alan Somers wrote
ch /tmp/foo
>>>>> cp /tmp/foo /tmo/foo2
>>>>>
>>>>> I'm wondering if the issue is that copy_file_range isn't
>>>>> handling empty files, or if it's a devfs issue.
>>>>>
>>>>>
>>>>> On Thu, Sep
> On 11. Sep 2020, at 22:12, Yasuhiro KIMURA wrote:
>
> Hello,
>
> I made regular update of my 13-CUREENT amd64 environment from r365330
> to r365634. Host OS is successfully updated with regular steps written
> in /usr/src/Makefile. But update of poudriere jail is failed with
> error.
he error ..
imb@vm01:/home/imb> touch xx
imb@vm01:/home/imb> cp xx yy
imb@vm01:/home/imb>
imb@vm01:/home/imb> cp /dev/null yy
cp: /dev/null: Invalid argument
imb@vm01:/home/imb>
>
> On Thu, Sep 10, 2020 at 11:45 AM Michael Butler
> wrote:
>> It seems that SVN r365549 b
It seems that SVN r365549 broke "cp /dev/null ..."
imb
On 9/10/20 10:35 AM, Michael Butler wrote:
> Is anyone else seeing failures like this in building world and, in my
> case, cron jobs as well?
>
>
> Building /usr/obj/usr/src/amd64.amd64/stand
Is anyone else seeing failures like this in building world and, in my
case, cron jobs as well?
Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr
--- all_subdir_sbin ---
Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel
--- all_subdir_stand ---
--- zfsboot.ldr ---
> On 6. Sep 2020, at 21:09, Yoshihiro Ota wrote:
>
> On Sun, 6 Sep 2020 14:47:00 +0200
> Michael Gmelin wrote:
>
>>
>>
>>>> On 6. Sep 2020, at 12:00, Niclas Zeising
>>>> wrote:
>>>
>>> 〓On 2020-09-06 09:00, grarp
e’s a use case for having access to this information, we could simply
provide it through a static index.html that’s recreated every time the
directory changes.
Cheers,
Michael
___
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"
On 8/29/20 5:48 PM, Glen Barber wrote:
> On Sat, Aug 29, 2020 at 09:43:25PM +, Glen Barber wrote:
>> On Sat, Aug 29, 2020 at 09:40:17PM +, Glen Barber wrote:
[ .. ]
>>> Nevermind, I see the problem. Standby.
>>>
>>
>> r364966 should fix it. Thank you again for your help here.
>>
>
>
On 8/29/20 5:17 PM, Glen Barber wrote:
> On Sat, Aug 29, 2020 at 04:38:05PM -0400, Michael Butler wrote:
>> The build-from-existing mode fails with ..
>>
>> imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf
>> fatal: not a git repository (or any
On 8/29/20 12:04 PM, Glen Barber wrote:
> On Sat, Aug 29, 2020 at 03:51:23PM +, Glen Barber wrote:
>> I added a way to update an existing tree in r364959. I have only done
>> very trivial testing on this change, however, so please let me know if
>> it does not work as expected.
>>
> r364960
On 8/29/20 11:14 AM, Glen Barber wrote:
> NOPORTS=yes is the problem, and I forgot to address it before merging
> the project branch back. Please try with r364956.
Trying now but, in the interim, I noted ..
With SVN, I could re-use a previously existing build directory and it
would simply apply
On 8/28/20 1:44 PM, Glen Barber wrote:
> Note, not entirely tested, however, since future snapshots and 13.0 will
> be exclusively built from the git sources.
When building with ..
## Set miscellaneous 'make release' settings.
NODOC=yes
NOPORTS=yes
WITH_DVD=yes
The build fails after building
Is there any documentation around the changes to the release build
system from SVN to GIT?
I currently keep a mirrored SVN repo and the revised release scripts
seem not to have that as a build option. Can I still use this or do I
need to throw it all out and start over?
With one target machine
> On 24. Aug 2020, at 17:20, Shawn Webb wrote:
>
> Hey FreeBSD peeps,
>
> The zfs(8) manpage says that the maximum length of a dataset name is
> MAXNAMELEN (256 bytes). I've created a ZFS volume that has a dataset
> name length of 62. I don't see the ZFS volume in /dev/zvol and I
> noticed
> On 19. Aug 2020, at 06:19, Dustin Marquess wrote:
>
> On Tue, Aug 18, 2020 at 3:19 PM Michael Butler
> wrote:
>>
>> Any thoughts as to why this is happening when I build a (custom) kernel?
>>
>> kldxref: /boot/kernel/kernel: too many segments
>
Any thoughts as to why this is happening when I build a (custom) kernel?
kldxref: /boot/kernel/kernel: too many segments
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,
When cross-compiling for i386 on amd64 (which has 2 by 4 cores), I get
the error below after a previously successful build.
Running the build again (a 3rd time) completes successfully :-(
This is the output from
cd /usr/src/release; ./release.sh -c release-i386.conf
[ .. ]
===>
> On 29. Jul 2020, at 21:29, Poul-Henning Kamp wrote:
>
> ----
> Michael Gmelin writes:
>
>> I meant which xorg driver - modesetting or Intel?
>
> It looks like "modesetting":
>
You could try installing xf86-video-intel and see if that makes a d
> On 29. Jul 2020, at 21:18, Poul-Henning Kamp wrote:
>
> ----
> Michael Gmelin writes:
>
>> Which driver are you using?
>
> drm-devel-kmod-5.3.g20200724
>
I meant which xorg driver - modesetting or Intel?
-m
> dmesg:
>
>drmn0: on vgap
> On 29. Jul 2020, at 21:02, Poul-Henning Kamp wrote:
>
>
> Ed Maste writes:
>>> On Wed, 29 Jul 2020 at 06:20, Poul-Henning Kamp wrote:
>>>
>>> I just noticed that KiCad's scroll-bars flash a lot whenever the mouse
>>> pointer is moved, that sounds like it could be the
On Wed, 29 Jul 2020 09:36:29 +
"Poul-Henning Kamp" wrote:
> ----
> Michael Gmelin writes:
>
> > This sounds a bit like it could be related to
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245854
>
> That sounds like something in the
easy things you could check:
- try connecting a usb mouse (to rule out synaptics being the issue).
- try using a different WM and see if the problem persists.
Touch jumps are common and haven’t caused me any problems so far (then
again, I'm not kicad user).
-m
--
Michael Gmelin
it with '--debug' is very
informative. Perhaps run a typescript for each run to capture this?
All, is the debug output something that should be logged?
Michael
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
> On 22. Jun 2020, at 15:55, Michael Tuexen wrote:
>
>> On 21. Jun 2020, at 23:12, Rodney W. Grimes
>> wrote:
>>
>>>> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
>>>>>> On 21. Jun 2020, at 14:28, Kostya Berger
&
nue
> make: stopped in /usr/ports/shells/bash
> (bash)5025}
>
>> On Jul 8, 2020, at 5:33 PM, Michael Butler
>> wrote:
>>
>> Did the bmake update break the updating of ports or something else?
>>
>> # sudo -E portmaster -a
>> ===>>> Gathering disti
Did the bmake update break the updating of ports or something else?
# sudo -E portmaster -a
===>>> Gathering distinfo list for installed ports
===>>> Starting check of installed ports for available updates
make: "/usr/ports/Mk/Uses/python.mk" line 384: warning: String
comparison operator should
hflags -R 0 /tmp/
>>
>> Okay, I am currently working on an update for clear_tmp_enable="YES"
>> to include
>> a check like this. I would think that an rc option like this should
>> delete
>> everything in /tmp.
>>
>
> I disagree. One
On Sat, 27 Jun 2020 06:21:17 -0700
John Baldwin wrote:
> On 6/27/20 2:59 AM, Michael Gmelin wrote:
> >
> >
> > On Sat, 27 Jun 2020 12:06:17 +0300
> > Andriy Gapon wrote:
> >
> >> On 27/06/2020 10:44, Li-Wen Hsu wrote:
> >>> On
0.00u 2.46s 21% 2676k
398+0 records in
398+0 records out
417333248 bytes transferred in 2.528253 secs (165067835 bytes/sec)
...
--
Michael Gmelin
___
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"
ronment as that user, starting firefox and see if the page still
doesn't render properly.
-m
--
Michael Gmelin
___
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"
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.
>
&g
-p now` fails to power off with VirtualBox UEFI boot
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247474
>>
>
> Does setting the tunable hw.efi.poweroff=0 help you?
That works for me (FreeBSD head on Virtual Box, latest release, on Mac OS).
Best regards
Mic
> On 21. Jun 2020, at 23:12, Rodney W. Grimes
> wrote:
>
>>> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
>>>>> On 21. Jun 2020, at 14:28, Kostya Berger
>>>>> wrote:
>>>>>
>>>>> Ok, it turns out, it give
> On 21. Jun 2020, at 23:12, Rodney W. Grimes
> wrote:
>
>>> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
>>>>> On 21. Jun 2020, at 14:28, Kostya Berger
>>>>> wrote:
>>>>>
>>>>> Ok, it turns out, it give
> On 21. Jun 2020, at 20:02, Ian Lepore wrote:
>
> On Sun, 2020-06-21 at 19:54 +0200, Michael Tuexen wrote:
>>> On 21. Jun 2020, at 19:40, Ian Lepore wrote:
>>>
>>> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
>>>>> On 21. J
> On 21. Jun 2020, at 19:40, Ian Lepore wrote:
>
> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
>>> On 21. Jun 2020, at 14:28, Kostya Berger
>>> wrote:
>>>
>>> Ok, it turns out, it gives the previously mentioned error only if I
>&g
.0.0 is a valid destination address you can use in connect().
Using 127.0.0.1 should
be fine.
I guess, https://svnweb.freebsd.org/changeset/base/361752 is the relevant
commit here.
Best regards
Michael
> Отправлено из Yahoo Почты для Android
>
> вс, 21 июн. 2020 в 9:40 Kostya Berger напис
I'm seeing this message repeatedly during port builds. Should I be
concerned?
file: File 5.39 supports only version 16 magic files.
`/usr/share/misc/magic.mgc' is version 14
imb
___
freebsd-current@freebsd.org mailing list
t isn't used often.
Thanks for the hint. I tried to find one. Let's see how good this guess is.
Best regards
Michael
>
> Damjan
>
>
> On Wed, Jun 10, 2020 at 7:40 PM Michael Tuexen wrote:
> > On 10. Jun 2020, at 18:59, Mark Johnston wrote:
> >
> > On
> On 10. Jun 2020, at 18:59, Mark Johnston wrote:
>
> On Wed, Jun 10, 2020 at 06:41:50PM +0200, Michael Tuexen wrote:
>> Dear all,
>>
>> consider the following program test.c:
>>
>> #include
>> #include
>>
>> int
>> m
> On 10. Jun 2020, at 18:59, Mark Johnston wrote:
>
> On Wed, Jun 10, 2020 at 06:41:50PM +0200, Michael Tuexen wrote:
>> Dear all,
>>
>> consider the following program test.c:
>>
>> #include
>> #include
>>
>> int
>> m
ant to get syzkaller working on
32-bit with clang.
Best regards
Michael
___
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"
> On 9. May 2020, at 18:07, Gordon Bergling wrote:
>
> Hi Michael,
>
> On Sat, May 09, 2020 at 05:42:55PM +0200, Michael Tuexen wrote:
>>> On 9. May 2020, at 16:25, Gordon Bergling wrote:
>>> I tried tcp_rack and tcp_bbr, since both are separate TCP stacks. I
> On 9. May 2020, at 16:25, Gordon Bergling wrote:
>
> Hi Michael,
>
> thanks for your reply.
>
> I tried tcp_rack and tcp_bbr, since both are separate TCP stacks. I just
> posted the wrong error message. Both TCP stacks weren’t loadable as a kernel
> module wit
eck
> dmesg(8) for more details.
This indicates that you want to load the RACK stack.
Please note that you need for BBR and RACK:
options TCPHPTS
in the kernel config and in addition to that for RACK
options RATELIMIT
Best regards
Michael
>
> dmesg shows:
>
On Mon, 27 Apr 2020 17:06:28 +0200
Malcolm Matalka wrote:
> Michael Gmelin writes:
>
> >
> > Could you share your setup by running
> >
> > pkg install ca_root_nss
> > fetch \
> >
> > https://raw.githubusercontent.com/grembo/xorg-
t;
> No I don't. I just did a bunch of sysctls to configure the mouse (it
> was very sensitive to touch such that if my palm grazed the trackpad
> it became a click).
>
Could you share your setup by running
pkg install ca_root_nss
fetch \
https://raw.githubusercontent.com/grembo
et-prop 'TPPS/2 IBM TrackPoint' \
'libinput Scroll Method Enabled' 0 0 0
After this, Ctrl+middle works as expected in xterm.
Note: Check `xinput' output to get the correct device name for your
trackpoint (you can also use its numeric identifier, but the name is
supposed to be more stable).
Che
> On 27. Apr 2020, at 10:43, Niclas Zeising wrote:
>
> On 2020-04-27 10:28, Poul-Henning Kamp wrote:
>>
>> In message <65670198-e725-5b66-646c-5b147c943...@daemonic.se>, Niclas
>> Zeising writes:
>>> With my touchpad, ctrl left click and ctrl right click opens two
>>> different
> On 27. Apr 2020, at 09:26, Poul-Henning Kamp wrote:
>
>
> In message <7549a5dd-3edc-4efd-bc0b-4d67232b4...@grem.de>, Michael Gmelin
> writes:
>
>>> In my case, with the default
>>>
>>> sysctl kern.evdev.rcpt_mask=12
>&g
verify that you have xf86-input-libinput installed?
>
> In my case yes, this is CURRENt and I have xf86-input-libinput-0.29.0
>
> In my case, with the default
>
>sysctl kern.evdev.rcpt_mask=12
>
> CTRL + middle button would not activate the menu in xterm.
>
Are
a change should fix this issue and does not impact other protocols.
Best regards
Michael
>
>
> R
>
>> On Apr 26, 2020, at 8:55 AM, Randall Stewart wrote:
>>
>> Sure..
>>
>> I will take a look at it.
>>
>> R
>>
>>> On Apr
o you get what you want if you add
lines like the existing one
netinet/cc/cc_newreno.c optional inet | inet6
to sys/conf/files for the CC modules you would like to get compiled in your
kernel?
Best regards
Michael
>
> Thanks in advance,
> kind regards
>
> O. Hartmann
__
> On 24. Apr 2020, at 23:41, Neel Chauhan wrote:
>
> Not OP, but would BBR work with VNET, or is that a WIP?
I would say it should work. At least, if not I would consider it a bug.
I think most testing was not done with multiple VNETs.
Best regards
Michael
>
> I'm sorry
with
makeoptions WITH_EXTRA_TCP_STACKS=1
options TCPHPTS
Best regards
Michael
>
>
> --
> Rod Grimes rgri...@freebsd.org
> ___
> freebsd-current@freebsd.org mailing list
>
> GENERIC.
We talked about these yesterday in the FreeBSD telco. At least some of them are
related to OOB data. The plan is to disable handling of OOB data in the
alternate
stacks. Will bring up a patch and see if that fixes the issues.
Best regards
Michael
> _
On 4/15/20 7:19 PM, Michael Butler wrote:
> This instance is/was running in a jail but now fails sometime after SVN
> r359823 .. I'm trying to bisect but any hints appreciated ..
>
> named[98746]:
> named[98746]: BIND
This instance is/was running in a jail but now fails sometime after SVN
r359823 .. I'm trying to bisect but any hints appreciated ..
named[98746]:
named[98746]: BIND 9 is maintained by Internet Systems Consortium,
named[98746]: Inc. (ISC), a
On Thu, 12 Mar 2020 10:36:42 -0500
Bob Willcox wrote:
> On Thu, Mar 12, 2020 at 07:24:42AM -0500, Bob Willcox wrote:
> > On Wed, Mar 11, 2020 at 11:46:49PM +0100, Michael Gmelin wrote:
> > >
> > >
> > > SNIP SNAP
> > > >> It m
's default config, which
changed to evdev in 1.20.
Cheers,
Michael
--
Michael Gmelin
___
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"
> On 11. Mar 2020, at 23:25, Bob Willcox wrote:
>
> On Wed, Mar 11, 2020 at 11:04:18PM +0100, Michael Gmelin wrote:
>>
>>
>>>> On 11. Mar 2020, at 22:58, Bob Willcox wrote:
>>>
>>> ???On Wed, Mar 11, 2020 at 02:48:56PM +0100, Michael Gmel
> On 11. Mar 2020, at 22:58, Bob Willcox wrote:
>
> 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
>> 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.
>> Indeed. This doesn't just affect -CURRENT: it happened to me on
>> -STABLE last week, so I'm copying that list too.
>
>
> On 7. Mar 2020, at 22:12, Andrey Fesenko wrote:
>
> On Sun, Mar 8, 2020 at 12:02 AM Michael Tuexen wrote:
>>
>>
>>
>>> On 7. Mar 2020, at 21:37, Michael Gmelin wrote:
>>>
>>>
>>>
>>>> On 7. Mar 2020, at 19:01,
> On 7. Mar 2020, at 23:39, Greg 'groggy' Lehey wrote:
>
> On Saturday, 7 March 2020 at 16:46:58 +0100, Michael Gmelin wrote:
>
> [much irrelevant text deleted]
>
> People, please trim your replies. Only relevant text should remain
>
>>> On Sat, 07 Mar 2
> On 7. Mar 2020, at 21:37, Michael Gmelin wrote:
>
>
>
>> On 7. Mar 2020, at 19:01, Michael Tuexen wrote:
>>
>>
>>>
>>>> On 7. Mar 2020, at 18:18, Michael Gmelin wrote:
>>>>
>>>>
>>>>
>>
> On 7. Mar 2020, at 19:01, Michael Tuexen wrote:
>
>
>>
>>> On 7. Mar 2020, at 18:18, Michael Gmelin wrote:
>>>
>>>
>>>
>>>> On 7. Mar 2020, at 18:08, Michael Tuexen wrote:
>>>
>>>
>>>>
> On 7. Mar 2020, at 18:18, Michael Gmelin wrote:
>
>
>
>> On 7. Mar 2020, at 18:08, Michael Tuexen wrote:
>>
>>
>>>
>>> On 7. Mar 2020, at 16:46, Michael Gmelin wrote:
>>>
>>>
>>>
>>>> On Sat
> On 7. Mar 2020, at 18:08, Michael Tuexen wrote:
>
>
>>
>> On 7. Mar 2020, at 16:46, Michael Gmelin wrote:
>>
>>
>>
>>> On Sat, 07 Mar 2020 11:30:58 -0400
>>> Waitman Gobble wrote:
>>>
>>> On 2020-03-07 05:1
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to
> > "freebsd-current-unsubscr...@freebsd.org"
>
>
> Did you try:
> pkg update -f
>
>
> I i
y packages were affected and not setting
it on `pkg upgrade' meant that pkg checks for that (at least that's
what I assume it does) and therefore I won't have to deal with
different ABIs in my installed packages later.
All of this should be really temporary anyway and hopefully be resolved
s
In case anyone else is seeing this ..
Forwarded Message
Subject: Re: SVN r358655 breaks i386 buildworld :-(
Date: Thu, 5 Mar 2020 09:49:01 -0500
From: Michael Butler
To: Gleb Smirnoff
On 3/4/20 10:00 PM, Michael Butler wrote:
> On i386, I get this ..
>
> Building
&
On 2/21/20 11:49 AM, Ed Maste wrote:
> It seems starting sshd from inetd via tcpd is a reasonable approach
> for folks who want to use it; also, have folks using libwrap looked at
> sshd's Match blocks to see if they provide the desired functionality?
While match blocks can disallow a login from
Seems there's an issue with freebsd.org's reverse DNS resulting in
refused email, e.g.
Feb 17 08:58:54 mail postfix/smtpd[41811]: NOQUEUE: reject: RCPT from
unknown[2610:1c1:1:606c::19:2]: 550 5.7.25 Client host rejected: cannot
find your hostname, [2610:1c1:1:606c::19:2];
from= to=
proto=ESMTP
On 2/14/20 6:37 PM, Ben Woods wrote:
> On Sat, 15 Feb 2020 at 4:27 am, Joey Kelly wrote:
>
>> On Friday, February 14, 2020 01:18:44 PM Ed Maste wrote:
>>> Upstream OpenSSH-portable removed libwrap support in version 6.7,
>>> released in October 2014. We've maintained a patch in our tree to
>>>
e request for page
> 0xfd0031880490
This problem is NOT arm specific. I've seen it on an amd64 system running
syzkaller:
http://212.201.121.91:1/crash?id=00704eb865e893ffda473a4859e062eef512cbde
Best regards
Michael
>
> cpuid = 2
> time = 1577921727
> KDB: stack backtrace:
> db_trace_
-current now fails to build the DRM drivers :-(
Building
/usr/obj/usr/src/amd64.amd64/sys/TOSHI/modules/usr/local/sys/modules/drm-current-kmod/drm/drm_os_freebsd.o
--- drm_os_freebsd.o ---
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_os_freebsd.c:47:3:
error: implicit declaration
This member removal has other consequences. As follows ..
--- lib/libprocstat__L ---
Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/smbfs.o
--- libprocstat.o ---
/usr/src/lib/libprocstat/libprocstat.c:620:29: error: no member named
'next' in 'struct vm_map_entry'
for
Something missing from a header here?
Building /usr/obj/usr/src/amd64.amd64/sys/VM01/uma_core.o
--- uma_core.o ---
/usr/src/sys/vm/uma_core.c:1864:39: error: use of undeclared identifier
'sysctl___vm_uma'
zone->uz_oid = SYSCTL_ADD_NODE(NULL,
SYSCTL_STATIC_CHILDREN(_vm_uma),
Unless your laptop is really old, make sure to install amd64.
Best,
Michael
> On 22. Nov 2019, at 22:25, Robert wrote:
>
> Thanks all, in the process of installing 13-current snapshot.
>
>> On Fri, 22 Nov 2019 at 22:21, Clay Daniels
>> wrote:
>>
>> Just
The no-relax flag can't be used on all architectures ..
Building /usr/obj/usr/src/amd64.amd64/usr.sbin/jail/jail
--- jail ---
ld: error: unknown argument '--no-relax'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
--- all_subdir_usr.sbin/portsnap ---
---
I'm sure I did this yesterday without a failure; any hints as to what
broke/how to fix it?
imb
===> tests/sys/cddl/zfs/tests/threadsappend (all)
===> tests/sys/cddl/zfs/tests/truncate (all)
===> usr.sbin/amd/libamu (all)
===> usr.sbin/audit (all)
===>
201 - 300 of 1690 matches
Mail list logo
