> (iirc python does something strange)
Inconcievable!
On 2020/05/29 17:25, Bob Beck wrote:
> On Fri, May 29, 2020 at 06:14:44PM +0200, Marc Espie wrote:
> > In a trace:
> >
> > > > > #3 0x15e48c95459e in WebVfx::shutdown ()
> > > > > at /usr/obj/ports/webvfx-1.2.0/webvfx-1.2.0/webvfx/webvfx.cpp:193
> >
> > Now, this is NOT the default
On Fri, May 29, 2020 at 4:56 PM Jason A. Donenfeld wrote:
>
> Oh that's a nice observation about `boot disk -V`. Doing so actually
> got me booting up entirely:
>
> $ qemu-img convert -O qcow2 miniroot66.fs disk.qcow2
> $ qemu-img resize disk.qcow2 20G
> $ qemu-system-sparc64 -m 1024 -drive
On Fri, May 29, 2020 at 06:14:44PM +0200, Marc Espie wrote:
> In a trace:
>
> > > > #3 0x15e48c95459e in WebVfx::shutdown ()
> > > > at /usr/obj/ports/webvfx-1.2.0/webvfx-1.2.0/webvfx/webvfx.cpp:193
>
> Now, this is NOT the default location for WRKOBJDIR, but we are shipping
> packages
Note that you need to run this with `-nographic`, because the kernel
crashes when trying to use vgafb on sparc64/qemu. I've witnessed two
varieties crashes:
- https://data.zx2c4.com/openbsd-6.7-sparc64-vga-panic-miniroot67.png
This happens when booting up miniroot67.fs
-
On Fri, May 29, 2020 at 4:56 PM Jason A. Donenfeld wrote:
>
> Oh that's a nice observation about `boot disk -V`. Doing so actually
> got me booting up entirely:
>
> $ qemu-img convert -O qcow2 miniroot66.fs disk.qcow2
Er, copy and paste error. The below is actually from miniroot67.fs.
Oh that's a nice observation about `boot disk -V`. Doing so actually
got me booting up entirely:
$ qemu-img convert -O qcow2 miniroot66.fs disk.qcow2
$ qemu-img resize disk.qcow2 20G
$ qemu-system-sparc64 -m 1024 -drive file=disk.qcow2,if=ide -net
nic,model=ne2k_pci -net user -boot a -nographic
Le 24/04/2020 à 11:31, Damien Couderc a écrit :
Hi guys,
The following diff is adding the Marvell 88SE9215 SATA controller to
the PCI devices.
Hi,
Nobody to look at this?
===
--- pcidevs.orig Thu Apr 23 11:44:53 2020
+++
Hi
I have applied this now, thanks!
> Is there a specific reason why OpenBSD still uses an old ncurses-based
> version?
Updating ncurses in OpenBSD takes quite a lot of time because it is big
and quite integrated - so for example the file layout is where OpenBSD
would put stuff not where
Marc Espie:
> There are about 3 solutions to that:
> - change the bulk machines to /usr/ports/pobj
> - change the ports default to /usr/obj/ports
I don't think it's reasonable to expect everybody to use the same
path here.
--
Christian "naddy" Weisgerber
On Fri, May 29, 2020 at 08:48:14AM +0200, Martin Pieuchot wrote:
> On 28/05/20(Thu) 14:59, Vitaliy Makkoveev wrote:
> > socket(2) layer is already protected by solock(). It grabs NET_LOCK()
> > for inet{,6}(4) sockets, but all other sockets are still under
> > KERNEL_LOCK().
> >
> > I guess
On 2020/05/29 18:14, Marc Espie wrote:
> In a trace:
>
> > > > #3 0x15e48c95459e in WebVfx::shutdown ()
> > > > at /usr/obj/ports/webvfx-1.2.0/webvfx-1.2.0/webvfx/webvfx.cpp:193
>
> Now, this is NOT the default location for WRKOBJDIR, but we are shipping
> packages with debug
In a trace:
> > > #3 0x15e48c95459e in WebVfx::shutdown ()
> > > at /usr/obj/ports/webvfx-1.2.0/webvfx-1.2.0/webvfx/webvfx.cpp:193
Now, this is NOT the default location for WRKOBJDIR, but we are shipping
packages with debug information...
This could be a bit cumbersome, if in order to
On Fri, May 29, 2020 at 09:09:22AM +0200, Martin Pieuchot wrote:
> On 28/05/20(Thu) 15:27, Vitaliy Makkoveev wrote:
> > On Thu, May 28, 2020 at 12:26:39PM +0200, Martin Pieuchot wrote:
> > > On 27/05/20(Wed) 11:54, Vitaliy Makkoveev wrote:
> > > > pipex(4) is simultaneously protected by
On Fri, May 29, 2020 at 03:00:50PM +0200, Mark Kettenis wrote:
> > Date: Fri, 29 May 2020 13:45:37 +0100
> > From: Stuart Henderson
> >
> > On 2020/05/29 13:50, Paul Irofti wrote:
> > > +struct __timekeep {
> > > + uint32_t major; /* version major number */
> > > + uint32_t minor;
On Fri, May 29, 2020 at 01:45:37PM +0100, Stuart Henderson wrote:
> On 2020/05/29 13:50, Paul Irofti wrote:
> > +struct __timekeep {
> > + uint32_t major; /* version major number */
> > + uint32_t minor; /* version minor number */
> > +
> > + u_int64_t th_scale;
This time pppx_add_session() has mixed initialisation order. It starts
to initialise pipex(4) session, then initialises `ifnet', then links
pipex(4) session, then continue to initialize `ifnet'.
pppx_add_session() can sleep and pppx_if_start() can start to work with
unlinked pipex(4) session.
On Tue, May 26, 2020 at 12:13:02AM +0200, Ingo Schwarze wrote:
> Regarding the FreeBSD headers, i like them even less. There are both
> terrible design choices and terrible implementation choices. Regarding
> design, it appears that you *must* #include after other
> headers - if you include it
> Date: Fri, 29 May 2020 15:48:41 +0200
> From: Ingo Schwarze
Hi Ingo,
> Hi Marc,
I'm not Marc, but close enough ;).
> do i understand correctly that you intend to say: there are
> legitimate reasons to use these xlocale.h functions in portable
> software, in particular in portable
On Fri, May 29, 2020 at 03:48:41PM +0200, Ingo Schwarze wrote:
> Hi Marc,
>
> do i understand correctly that you intend to say: there are
> legitimate reasons to use these xlocale.h functions in portable
> software, in particular in portable libraries, so we should probably
> have them all, or
Hi Marc,
do i understand correctly that you intend to say: there are
legitimate reasons to use these xlocale.h functions in portable
software, in particular in portable libraries, so we should probably
have them all, or at least most of them?
I see your point that using functions like
> From: "Theo de Raadt"
> Date: Fri, 29 May 2020 07:26:50 -0600
>
> Paul Irofti wrote:
>
> > On 2020-05-29 16:00, Mark Kettenis wrote:
> > >> Date: Fri, 29 May 2020 13:45:37 +0100
> > >> From: Stuart Henderson
> > >>
> > >> On 2020/05/29 13:50, Paul Irofti wrote:
> > >>> +struct __timekeep {
Paul Irofti wrote:
> On 2020-05-29 16:00, Mark Kettenis wrote:
> >> Date: Fri, 29 May 2020 13:45:37 +0100
> >> From: Stuart Henderson
> >>
> >> On 2020/05/29 13:50, Paul Irofti wrote:
> >>> +struct __timekeep {
> >>> + uint32_t major; /* version major number */
> >>> + uint32_t minor;
On 2020-05-29 16:00, Mark Kettenis wrote:
Date: Fri, 29 May 2020 13:45:37 +0100
From: Stuart Henderson
On 2020/05/29 13:50, Paul Irofti wrote:
+struct __timekeep {
+ uint32_t major; /* version major number */
+ uint32_t minor; /* version minor number */
+
+
> Date: Fri, 29 May 2020 13:45:37 +0100
> From: Stuart Henderson
>
> On 2020/05/29 13:50, Paul Irofti wrote:
> > +struct __timekeep {
> > + uint32_t major; /* version major number */
> > + uint32_t minor; /* version minor number */
> > +
> > + u_int64_t
Hi,
Frederic Cambus wrote on Thu, May 28, 2020 at 10:44:59PM +0200:
> On Thu, May 28, 2020 at 10:52:44AM -0600, Theo de Raadt wrote:
>> -MANSUBDIR= i386 amd64 alpha
>> +MANSUBDIR= i386 amd64 arm64 armv7 alpha
>>
>> Actually, I suggest making this a MI man page. Delete that line,
>> and
On 2020-05-29 15:45, Stuart Henderson wrote:
On 2020/05/29 13:50, Paul Irofti wrote:
+struct __timekeep {
+ uint32_t major; /* version major number */
+ uint32_t minor; /* version minor number */
+
+ u_int64_t th_scale;
+ unsigned int
On 2020/05/29 13:50, Paul Irofti wrote:
> +struct __timekeep {
> + uint32_t major; /* version major number */
> + uint32_t minor; /* version minor number */
> +
> + u_int64_t th_scale;
> + unsigned intth_offset_count;
> + struct bintime
On Thu, May 28, 2020 at 10:11:28AM +0200, Otto Moerbeek wrote:
> On Thu, May 28, 2020 at 01:21:21AM -0600, Jason A. Donenfeld wrote:
>
> > On Thu, May 28, 2020 at 1:19 AM Otto Moerbeek wrote:
> > > Of course.., I was running it from a !wxallowed mount. BTW, qemu is in
> > > packages, no need to
On Thu, May 28, 2020 at 12:23:58PM +0200, Martin Pieuchot wrote:
> On 26/05/20(Tue) 11:30, Ingo Feinerer wrote:
> > video(1) supports reading frames from a webcam via mmap(). To inform the
> > V4L2 device about the number of desired buffers containing the frames to
> > be memory-mapped, a
On 2020/05/28 19:42, Jason McIntyre wrote:
> On Wed, May 27, 2020 at 08:43:47AM +0200, Martin Pieuchot wrote:
> > On 26/05/20(Tue) 10:31, Claudio Jeker wrote:
> > > [...]
> > > npppd(8) is server only it can not establish a connection. pppd(8) on the
> > > other hand is more client side (but I
On Thu, May 28, 2020 at 07:43:55PM +0200, Mark Kettenis wrote:
> > Date: Thu, 28 May 2020 17:44:31 +0300
> > From: Paul Irofti
> >
> > Hi,
> >
> > Here is a new iteration of the diff which includes support for MD high
> > resolution clocks. Currently only implements TSC on amd64. If the
> > MD
> Date: Fri, 29 May 2020 19:55:25 +1000
> From: Jonathan Gray
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Fri, May 29, 2020 at 11:25:44AM +0200, Bruno Flueckiger wrote:
> > Hi,
> >
> > My brand new laptop HP EliteBook 850 G6 comes with an Intel 300 Series
>
On Fri, May 29, 2020 at 11:25:44AM +0200, Bruno Flueckiger wrote:
> Hi,
>
> My brand new laptop HP EliteBook 850 G6 comes with an Intel 300 Series
> HD Audio device rev 0x11. The device shows up as not configured in the
> dmesg. The PCI config space of the device identifies its subclass as
>
Hi,
My brand new laptop HP EliteBook 850 G6 comes with an Intel 300 Series
HD Audio device rev 0x11. The device shows up as not configured in the
dmesg. The PCI config space of the device identifies its subclass as
PCI_SUBCLASS_MULTIMEDIA_AUDIO instead of PCI_SUBCLASS_MULTIMEDIA_HDAUDIO
The
On Fri, May 29, 2020 at 09:30:04AM +0200, Otto Moerbeek wrote:
> On Thu, May 28, 2020 at 12:54:41PM -0600, Todd C. Miller wrote:
>
> > On Thu, 28 May 2020 20:53:07 +0200, Otto Moerbeek wrote:
> >
> > > Here's the separate diff for the prefcg loops. From FreeBSD.
> >
> > OK millert@
> >
> > -
On Thu, May 28, 2020 at 12:54:41PM -0600, Todd C. Miller wrote:
> On Thu, 28 May 2020 20:53:07 +0200, Otto Moerbeek wrote:
>
> > Here's the separate diff for the prefcg loops. From FreeBSD.
>
> OK millert@
>
> - todd
>
And here's the updated diff against -current. I removed a redundant
cast
On 28/05/20(Thu) 15:27, Vitaliy Makkoveev wrote:
> On Thu, May 28, 2020 at 12:26:39PM +0200, Martin Pieuchot wrote:
> > On 27/05/20(Wed) 11:54, Vitaliy Makkoveev wrote:
> > > pipex(4) is simultaneously protected by KERNEL_LOCK() and NET_LOCK() and
> > > the last is not required. I guess to start
On 28/05/20(Thu) 14:59, Vitaliy Makkoveev wrote:
> socket(2) layer is already protected by solock(). It grabs NET_LOCK()
> for inet{,6}(4) sockets, but all other sockets are still under
> KERNEL_LOCK().
>
> I guess solock is already placed everythere it's required. Also `struct
> file' is already
On Thu, May 28, 2020 at 05:44:31PM +0300, Paul Irofti wrote:
> Hi,
>
> Here is a new iteration of the diff which includes support for MD high
> resolution clocks. Currently only implements TSC on amd64. If the
> MD function is not defined, it fallsback to the syscall.
>
> There is the question
40 matches
Mail list logo
