On Thu Apr 25, 2019 at 01:34:24PM +0200, Federico Giannici wrote:
> Similarly to konsole, KDE's dolphin no longer works too after upgrade of
> amd64 from 6.4 to 6.5.
>
> It seems that dolphin was switched to KF5 too, ma I wasn't able to install
> the new package:
>
> casa:/home/giannici# pkg_add
On 4/26/19 4:10 PM, Rafael Sadowski wrote:
On Thu Apr 25, 2019 at 01:34:24PM +0200, Federico Giannici wrote:
Similarly to konsole, KDE's dolphin no longer works too after upgrade of
amd64 from 6.4 to 6.5.
It seems that dolphin was switched to KF5 too, ma I wasn't able to install
the new package
On 2019-04-26, Rafael Sadowski wrote:
> On Thu Apr 25, 2019 at 01:34:24PM +0200, Federico Giannici wrote:
>> Similarly to konsole, KDE's dolphin no longer works too after upgrade of
>> amd64 from 6.4 to 6.5.
>>
>> It seems that dolphin was switched to KF5 too, ma I wasn't able to install
>> the n
On 2019-04-26, Igor Podlesny wrote:
> Or would kernel's recompiling be needed anyways?
>
> Moreover, I'm actually interested in intersection of watchdogs
> provided by KVM and
> supported by OpenBSD (as KVM's guest). At least as to KVM's it's gonna
> be a short list:
>
> 1) i6300esb (PCI)
> 2) ib7
Since I upgraded to OpenBSD amd64 6.5 I wasn't able to do a disk
mirroring with a dump | restore without producing system panic like this:
https://www.neomedia.it/images/IMG_20190426_183116.jpg
I use the following script, executed after a boot in single user mode:
newfs -q /dev/rsd2a
if mount
Hello,
I had this same issue with 6.4 and 6.5. Applying this patch has fixed
the issue. I am using 2 radeon gpu's.
https://patchwork.freedesktop.org/series/28284/
This is the gdb backtrace of the crashed core file.
joe:10201$ d gdb /usr/X11R6/bin/X Xorg.core
GNU gdb 6.3
Copyright 2004 Free Soft
On Fri Apr 26, 2019 at 05:47:11PM +0200, Federico Giannici wrote:
> On 4/26/19 4:10 PM, Rafael Sadowski wrote:
> > On Thu Apr 25, 2019 at 01:34:24PM +0200, Federico Giannici wrote:
> > > Similarly to konsole, KDE's dolphin no longer works too after upgrade of
> > > amd64 from 6.4 to 6.5.
> > >
> >
Namaste misc,
As a good practice, I tried to limit the virtual and physical memory
available to the svn daemon [1]. To achieve that, I read about login
classes and login.conf(5) [2]:
...
memoryuse sizeMaximum in core memoryuse size limit.
...
vmemoryuse sizeMaxim
On 04-26 21:47, Rafael Sadowski wrote:
> []
> update all packages with the following PKG_PATH example:
>
> env PKG_PATH=https://ftp.openbsd.org/pub/OpenBSD/6.5/packages/ pkg_add -u -v
> -Dinstalled
>
> It looks like you mixed packages for 6.4 and 6.5 and/or -current.
I had to run a pkg_add
On 26/04/2019, Rafael Sadowski wrote:
> run "pkg_add -X" to remove all your installed packages
Is -X undocumented for pkg_add(1), or am I overlooking something?
On Fri, 26 Apr 2019 at 22:58, Stuart Henderson wrote:
> On 2019-04-26, Igor Podlesny wrote:
> > Or would kernel's recompiling be needed anyways?
[...]
> Recompiling would be needed.
>
> If you want to try it, see faq 5 about fetching the source tree,
> add "ichwdt* at pci?" to /sys/arch/amd64/con
Igor Podlesny wrote:
> On Fri, 26 Apr 2019 at 22:58, Stuart Henderson wrote:
> > On 2019-04-26, Igor Podlesny wrote:
> > > Or would kernel's recompiling be needed anyways?
> [...]
> > Recompiling would be needed.
> >
> > If you want to try it, see faq 5 about fetching the source tree,
> > add "
Previously users could have different behaviour of malloc simultaneously: one in
global FS, others in chroots. Say, in global it could be more relaxed
with lesser
performance impact and in some chroots more drastic, at contrary. With
6.5 it's not
possible anymore, is it really so? This change has o
On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> Previously users could have different behaviour of malloc simultaneously: one
> in
> global FS, others in chroots. Say, in global it could be more relaxed
> with lesser
> performance impact and in some chroots more drastic, at contra
On Sat, 27 Apr 2019 at 12:12, Theo de Raadt wrote:
> Igor Podlesny wrote:
[...]
> > 1) Is it true that more or less fresh OpenBSD generic kernels come with
> > no support of any watchdog hw?
> No.
I see.
> > 2) I heard that kernel modules were intentionally rid of in OpenBSD
> > primarily due s
On Sat, 27 Apr 2019 at 12:26, Sebastien Marie wrote:
> On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> > Previously users could have different behaviour of malloc simultaneously:
> > one in
> > global FS, others in chroots. Say, in global it could be more relaxed
[...]
> malloc(3
Igor Podlesny writes:
> Previously users could have different behaviour of malloc simultaneously: one
> in
> global FS, others in chroots. Say, in global it could be more relaxed
> with lesser
> performance impact and in some chroots more drastic, at contrary. With
> 6.5 it's not
> possible anymor
On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley wrote:
>
> You didn't check the manpage.
you didn't think it over.
https://www.mail-archive.com/misc@openbsd.org/msg167012.html
--
End of message. Next message?
Igor Podlesny writes:
> On Sat, 27 Apr 2019 at 12:26, Sebastien Marie wrote:
> > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> > > Previously users could have different behaviour of malloc simultaneously:
> one in
> > > global FS, others in chroots. Say, in global it could be m
Igor Podlesny wrote:
> On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley wrote:
> >
> > You didn't check the manpage.
>
> you didn't think it over.
> https://www.mail-archive.com/misc@openbsd.org/msg167012.html
No, you didn't think it through at all.
You are expecting the malloc settings to pr
On Sat, 27 Apr 2019 at 12:46, Theo de Raadt wrote:
> Igor Podlesny wrote:
> > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley wrote:
> > > You didn't check the manpage.
> > you didn't think it over.
> > https://www.mail-archive.com/misc@openbsd.org/msg167012.html
>
> No, you didn't think it thr
Igor Podlesny wrote:
> On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley wrote:
> >
> > You didn't check the manpage.
>
> you didn't think it over.
> https://www.mail-archive.com/misc@openbsd.org/msg167012.html
Igor, talking back to the developers of the operating system you use is
never a good
> > Wrong. Environment is easy to be changed by any non-privileged process.
> > OTOH, root owned /etc/malloc.conf is not.
>
> Back then, when both /etc/malloc.conf and MALLOC_OPTIONS were set, which
> did a program prefer?
I'm more concerned with cleared up environment other than changed
MALLOC_OP
On Sat, 27 Apr 2019 at 12:55, Theo de Raadt wrote:
> Igor Podlesny wrote:
> > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley wrote:
> > > You didn't check the manpage.
> >
> > you didn't think it over.
> > https://www.mail-archive.com/misc@openbsd.org/msg167012.html
>
> Igor, talking back to t
24 matches
Mail list logo