On Fri, Mar 07, 2014 at 11:20:53PM +, Stuart Henderson wrote:
> I've been umming and ahhing about this diff, the thing I don't like is
> that SCRIPT_FILENAME is an Apache extension rather than part of the
> standard CGI variables, which explains why it's not included by
> default in nginx (or o
Le 07/03/2014 12:13 PM, Theo de Raadt a écrit :
actually more painful than having to boot windows is to always have
something handy to boot the snap from in order to dd the bootblock off
in case you forget to do it before rebooting, or you're fucked.
The new installboot was enabled around a mon
Le 07/03/2014 12:02 PM, Bob Beck a écrit :
actually more painful than having to boot windows is to always have
something handy to boot the snap from in order to dd the bootblock off
in case you forget to do it before rebooting, or you're fucked.
Hi Bob,
Yeah and hopefully, with a recent post
On Fri, Mar 07, 2014 at 05:00:43PM -0700, Theo de Raadt wrote:
> > Not necessarily, could be a tsleep in a DVACT_WAKEUP handler of an
> > other driver that makes us do the context switch. The cold = 2 diff
> > didn't reveal any tsleeps in inteldrm on my x220. But then I never
> > had any issues h
> Not necessarily, could be a tsleep in a DVACT_WAKEUP handler of an
> other driver that makes us do the context switch. The cold = 2 diff
> didn't reveal any tsleeps in inteldrm on my x220. But then I never
> had any issues here either. Perhaps somebody who can reproduce the
> problem should ru
On 2014/03/07 23:20, Stuart Henderson wrote:
> I've been umming and ahhing about this diff, the thing I don't like is
> that SCRIPT_FILENAME is an Apache extension rather than part of the
> standard CGI variables, which explains why it's not included by
> default in nginx (or other servers that peo
On 2014/03/07 18:04, James Turner wrote:
> If we want to keep it simple we can just go this route.
>
> On Sat, Mar 01, 2014 at 04:39:49PM -0500, James Turner wrote:
> > The attached diff uses SCRIPT_FILENAME instead of SCRIPT_NAME to
> > determine the path of CGI scripts in slowcgi. It also update
If we want to keep it simple we can just go this route.
On Sat, Mar 01, 2014 at 04:39:49PM -0500, James Turner wrote:
> The attached diff uses SCRIPT_FILENAME instead of SCRIPT_NAME to
> determine the path of CGI scripts in slowcgi. It also updates the
> example in nginx.conf.
>
> According to CG
> Date: Fri, 7 Mar 2014 15:09:23 +0100
> From: Martin Pieuchot
>
> Since usbd pipes contain a per-controller part, I'd like to malloc them
> with M_ZERO to properly initialize the per-controller fields to 0.
>
> ok?
Makes sense to me.
> Index: usb_subr.c
> =
> >> > Meaning that the pbr must be updated with the new location.
> >>
> >> It doesn't just "tend" to move around (ie. tend == "prone to move").
> >> It moves every time, since it is using mkstemp to create a new file.
> >
> > But isn't this a good thing?
> >
> > Now it moves around consistentl
On Fri, Mar 07, 2014 at 17:44, Mark Kettenis wrote:
>> > Meaning that the pbr must be updated with the new location.
>>
>> It doesn't just "tend" to move around (ie. tend == "prone to move").
>> It moves every time, since it is using mkstemp to create a new file.
>
> But isn't this a good thing?
Yeah, just trying something similar out. :) I should probably clean it
up and give Nick an FAQ diff, as long as he commits the section on how
to do this so cvs blame doesn't make me a windows expert - "just ask
bob - he does NFS *and* Windows..."
On Fri, Mar 7, 2014 at 12:08 PM, Wade, Daniel wro
Put the following in a txt file then: diskpart /s c:\openbsd_me.txt
Untested, but that's the idea.
And yep in windows world the disks starts at 0 and the partitions at 1
Select disk 0
Select part 3
Active
Exit
-Original Message-
From: Bob Beck [mailto:b...@obtuse.com]
Sent: Friday, Mar
... although having scripted the fdisk on openbsd quite nicely so I
can't screw it up, proceeed to forget that windows numbers partitions
starting at 1, not 0, in diskpart, and am now digging for a usb stick
and kicking myself in the ass..
Someone good at windows could take pity on me and mail me
Why I hadn't thought of going back to that I don't know.. It actually
works better for me since I don't then normally have to wait for the
windows bootloader screen... as at least in my case 90% of the time
the laptop runs OpenBSD..
Of course now after testing it I have to wait for windows to fi
On Mar 7, 2014 1:10 PM, "Wade, Daniel" wrote:
>
> I've been dual booting for years and never once use dd to copy the
openbsd.pbr
> If I'm in windows world and want to boot into OpenBSD I run diskpart and
flip the active partition.
> Same in the other direction, fdisk -e and flip the active back to
I've been dual booting for years and never once use dd to copy the openbsd.pbr
If I'm in windows world and want to boot into OpenBSD I run diskpart and flip
the active partition.
Same in the other direction, fdisk -e and flip the active back to windows.
I am my own boot manager.
-Original M
On Sun, Feb 16, 2014 at 06:01:43PM -0500, James Turner wrote:
> The attached diff updates the in-tree version of SQLite to 3.8.3.1. This
> is of course for after unlock but for those interested feel free to
> start giving it a try.
>
> Tested on amd64 and loongson with a small selection of ports.
On Fri, Mar 07, 2014 at 10:22:59AM -0700, Theo de Raadt wrote:
> > * Ted Unangst [2014-03-07 07:40]:
> > > On Thu, Mar 06, 2014 at 23:56, Lawrence Teo wrote:
> > > > pf_check_congestion() simply checks if ifq->ifq_congestion is non-zero,
> > > > and returns 1 or 0 accordingly. It is only called b
> * Ted Unangst [2014-03-07 07:40]:
> > On Thu, Mar 06, 2014 at 23:56, Lawrence Teo wrote:
> > > pf_check_congestion() simply checks if ifq->ifq_congestion is non-zero,
> > > and returns 1 or 0 accordingly. It is only called by pf_test_rule().
> > >
> > > Since what pf_check_congestion() does is
It will affect everyone who needs windows on a laptop for work - or
filling out pdf forms for foundations, things like that.
It is a good way to ensure snaps get tested less on real hardware.
On Fri, Mar 7, 2014 at 10:13 AM, Theo de Raadt wrote:
>> actually more painful than having to boot windo
> actually more painful than having to boot windows is to always have
> something handy to boot the snap from in order to dd the bootblock off
> in case you forget to do it before rebooting, or you're fucked.
The new installboot was enabled around a month ago. The issue is only
being talked about
Le 2014-03-07 11:24, Bob Beck a écrit :
If you're using windows bootloader, you need to re-get the openbsd.pbr
file to the windows side like you did in the first place
according to the instructions here:
http://www.openbsd.org/faq/faq4.html#Multibooting
Someone really needs to put it in the mul
actually more painful than having to boot windows is to always have
something handy to boot the snap from in order to dd the bootblock off
in case you forget to do it before rebooting, or you're fucked.
On Fri, Mar 7, 2014 at 9:50 AM, Bob Beck wrote:
> before it was just that you had to be aware
Le 2014-03-07 11:21, Stuart Henderson a écrit :
On 2014/03/07 11:04, Jean-Philippe Luiggi wrote:
Hi everybody,
I follow "-current" for several years but recently a thing puzzles me.
My "x200" is a dual-boot system ("Seven"/OpenBSD "-current") and since (I
think) the
"amd64/i386 installboot" c
before it was just that you had to be aware to redo it when something
changed. (which for me usually means booting from external media,
dd'ing the pbr file onto a usb stick, booting into windows, and
copying it into the right place.
having to boot windows every time you upgrade is a pain.
On Fri,
No, because moving it means that you have to manually redo it every
time you install a snap. which is really a pita.
On Fri, Mar 7, 2014 at 9:44 AM, Mark Kettenis wrote:
>> From: Theo de Raadt
>> Date: Fri, 07 Mar 2014 09:24:13 -0700
>>
>> > Whereas new installboot tends to shift it around:
>>
> From: Theo de Raadt
> Date: Fri, 07 Mar 2014 09:24:13 -0700
>
> > Whereas new installboot tends to shift it around:
> >
> > # installboot -v sd1 2>&1 | grep shift
> > fs block shift 2; part offset 64; inode block 56, offset 2344
> > # installboot -v sd1 2>&1 | grep shift
> > fs block shift 2;
>>
>> Meaning that the pbr must be updated with the new location.
>
> It doesn't just "tend" to move around (ie. tend == "prone to move").
> It moves every time, since it is using mkstemp to create a new file.
Hmm.. yeah that'll be fun to deal with in multi-boot setups.
> Whereas new installboot tends to shift it around:
>
> # installboot -v sd1 2>&1 | grep shift
> fs block shift 2; part offset 64; inode block 56, offset 2344
> # installboot -v sd1 2>&1 | grep shift
> fs block shift 2; part offset 64; inode block 48, offset 16168
> # installboot -v sd1 2>&1 | gr
If you're using windows bootloader, you need to re-get the openbsd.pbr
file to the windows side like you did in the first place
according to the instructions here:
http://www.openbsd.org/faq/faq4.html#Multibooting
Someone really needs to put it in the multiboot FAQ that if you're
booting with the
On 2014/03/07 11:04, Jean-Philippe Luiggi wrote:
> Hi everybody,
>
> I follow "-current" for several years but recently a thing puzzles me.
>
> My "x200" is a dual-boot system ("Seven"/OpenBSD "-current") and since (I
> think) the
> "amd64/i386 installboot" change, each time I upgrade via "bsd.r
> I follow "-current" for several years but recently a thing puzzles me.
>
> My "x200" is a dual-boot system ("Seven"/OpenBSD "-current") and since (I
> think) the
> "amd64/i386 installboot" change, each time I upgrade via "bsd.rd", I have to
> generate a new "openbsd.pbr" and copy it to "Seven
Hi everybody,
I follow "-current" for several years but recently a thing puzzles me.
My "x200" is a dual-boot system ("Seven"/OpenBSD "-current") and since (I
think) the
"amd64/i386 installboot" change, each time I upgrade via "bsd.rd", I have to generate a new
"openbsd.pbr" and copy it to "S
Diff below unify the various *hci_timeout() functions, there should be
no functional change.
Since this code is identical in all our drivers, the next step will be
to provide a new hook to not reroll it in the two upcoming HC drivers.
ok?
Index: ehci.c
===
Since usbd pipes contain a per-controller part, I'd like to malloc them
with M_ZERO to properly initialize the per-controller fields to 0.
ok?
Index: usb_subr.c
===
RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.98
On 2014-03-06 Thu 15:42 PM |, Stuart Henderson wrote:
>
> Personally I'd keep them for releases (which also gives people a base
> to speed up updates to -current) but probably drop them for snapshots..
>
Sensible logic;- reducing workload, network & electricity costs!
* Ted Unangst [2014-03-07 07:40]:
> On Thu, Mar 06, 2014 at 23:56, Lawrence Teo wrote:
> > pf_check_congestion() simply checks if ifq->ifq_congestion is non-zero,
> > and returns 1 or 0 accordingly. It is only called by pf_test_rule().
> >
> > Since what pf_check_congestion() does is very trivia
Hello,
st...@openbsd.org (Stuart Henderson), 2014.03.06 (Thu) 16:42 (CET):
> On 2014/03/06 08:32, Theo de Raadt wrote:
> > > > > I'd like to ask. Does anyone find it useful? It is not in sync with
> > > > > the
> > > > > packages beside it.
> > > > >
> > > I thought the packages are being buil
39 matches
Mail list logo
