On Tue, 10 Oct 2023 10:14:10 -0700, Chris Cappuccio wrote:
> The Message-ID should be added to any message that doesn't have one.
> An existing Message-ID should not be removed or changed.
>
> The RFC says it "MAY be applied when necessary by an originating SMTP server"
> so the port numbers aren'
Todd C. Miller [mill...@openbsd.org] wrote:
> On Tue, 10 Oct 2023 10:50:08 +0100, Stuart Henderson wrote:
>
> > Presumably 465 should be treated the same, though the hardcoded ports
> > don't feel entirely right here - this is presumably something that would
> > want adding for any connection whic
On Tue, 10 Oct 2023 10:50:08 +0100, Stuart Henderson wrote:
> Presumably 465 should be treated the same, though the hardcoded ports
> don't feel entirely right here - this is presumably something that would
> want adding for any connection which is allowed to relay ..
Yes, I think so. Hard-codin
On 2023/10/09 14:55, Todd C. Miller wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: mill...@cvs.openbsd.org 2023/10/09 14:55:33
>
> Modified files:
> usr.sbin/smtpd : smtp_session.c
>
> Log message:
> Add Message-Id as needed for messages received on the submission port.
>
This change fixes another wart in unveil/pledge which wasn't resolved in
the original design. pledge allows bypass-reading of
/usr/share/zoneinfo/ files for TZ=zone but absolute path support
remained a wart.
Once again, we have to remove a rarely used behavior of libc.
During pledge and unveil
Once initially defined engineid should be static, a lot of SNMP polling
applications use engineid as device identifier.
Consistency and uniqueness are both important. Some polling system will not
allow you to add another snmp device
If engineid is a duplicate.
Network devices usually derive en
On Mon, 2021-08-09 at 21:58 +0100, Stuart Henderson wrote:
> On 2021/08/09 22:35, Martijn van Duren wrote:
> > Moving to tech@
> >
> > On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote:
> > > On 2021/08/09 12:14, Martijn van Duren wrote:
> > > > CVSROOT:/cvs
> > > > Module name:
On 2021/08/09 22:35, Martijn van Duren wrote:
> Moving to tech@
>
> On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote:
> > On 2021/08/09 12:14, Martijn van Duren wrote:
> > > CVSROOT:/cvs
> > > Module name:src
> > > Changes by: mart...@cvs.openbsd.org2021/08/09 12:14:53
Moving to tech@
On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote:
> On 2021/08/09 12:14, Martijn van Duren wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: mart...@cvs.openbsd.org2021/08/09 12:14:53
> >
> > Modified files:
> > usr.sbin/snmpd : parse
On Fri, 24 Jan 2020, Stuart Henderson wrote:
> That works - etc/rc.d/sshd diff to match as follows:
>
> Index: sshd
> ===
> RCS file: /cvs/src/etc/rc.d/sshd,v
> retrieving revision 1.5
> diff -u -p -r1.5 sshd
> --- sshd 22 Jan 2
On Fri, 24 Jan 2020, Antoine Jacoutot wrote:
> Great :-)
> Ok aja
committed, the proctitle looks like this now in case the rc scripts need
further tweaking:
$ pgrep -lf sshd
12844 sshd: /usr/sbin/sshd -f /etc/ssh/sshd_config [listener] 0 of 10-100
startups
Great :-)
Ok aja
—
Antoine
> On 24 Jan 2020, at 13:02, Stuart Henderson wrote:
>
> On 2020/01/23 21:20, Damien Miller wrote:
>>> On Thu, 23 Jan 2020, Damien Miller wrote:
>>>
On Thu, 23 Jan 2020, Damien Miller wrote:
>>>
What information would you like there? We could put the firs
On 2020/01/23 21:20, Damien Miller wrote:
> On Thu, 23 Jan 2020, Damien Miller wrote:
>
> > On Thu, 23 Jan 2020, Damien Miller wrote:
> >
> > > What information would you like there? We could put the first N listen
> > > addrs in the proctitle if that would help.
> >
> > Maybe like this:
> >
>
On Thu, 23 Jan 2020, Damien Miller wrote:
> On Thu, 23 Jan 2020, Damien Miller wrote:
>
> > What information would you like there? We could put the first N listen
> > addrs in the proctitle if that would help.
>
> Maybe like this:
>
> 63817 ?? S0:00.05 sshd: [listen] on [0.0.0.0]:22, [
On Thu, Jan 23, 2020 at 02:36:43PM +1100, Damien Miller wrote:
> On Wed, 22 Jan 2020, Stuart Henderson wrote:
>
> > On 2020/01/21 15:39, Damien Miller wrote:
> > > CVSROOT: /cvs
> > > Module name: src
> > > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
> > >
> > > Modified f
On Thu, 23 Jan 2020, Damien Miller wrote:
> On Wed, 22 Jan 2020, Stuart Henderson wrote:
>
> > On 2020/01/21 15:39, Damien Miller wrote:
> > > CVSROOT: /cvs
> > > Module name: src
> > > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
> > >
> > > Modified files:
> > > usr.bi
On Wed, 22 Jan 2020, Stuart Henderson wrote:
> On 2020/01/21 15:39, Damien Miller wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
> >
> > Modified files:
> > usr.bin/ssh: sshd.c
> >
> > Log message:
> > expose the numbe
I guess this needs to be changed again, to retain more info from the
original title.
Stuart Henderson wrote:
> On 2020/01/21 15:39, Damien Miller wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
> >
> > Modified files:
> > u
On 2020/01/21 15:39, Damien Miller wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
>
> Modified files:
> usr.bin/ssh: sshd.c
>
> Log message:
> expose the number of currently-authenticating connections
> along with the MaxStar
On 24/10/19(Thu) 13:30, Stuart Henderson wrote:
> On 2019/10/21 04:06, Martin Pieuchot wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: m...@cvs.openbsd.org2019/10/21 04:06:31
> >
> > Modified files:
> > lib/librthread : synch.h
> >
> > Log message:
> > Use process
On 24/10/19(Thu) 13:30, Stuart Henderson wrote:
> On 2019/10/21 04:06, Martin Pieuchot wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: m...@cvs.openbsd.org2019/10/21 04:06:31
> >
> > Modified files:
> > lib/librthread : synch.h
> >
> > Log message:
> > Use process
On 2019/10/21 04:06, Martin Pieuchot wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: m...@cvs.openbsd.org2019/10/21 04:06:31
>
> Modified files:
> lib/librthread : synch.h
>
> Log message:
> Use process-private futexes to avoid the uvm_map lookup overhead.
>
> While he
Thanks for a couple of offlist replies .. I had a partial src checkout
and "make install" was installing the new binaries to / rather than /usr/sbin.
I thought I had accounted for that and copied them into place but I guess with
the late hour I must have missed something, as I've done a full src ch
On 2019/05/13 07:47, Denis Fondras wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: de...@cvs.openbsd.org 2019/05/13 07:47:36
>
> Modified files:
> usr.sbin/bgpd : rde_update.c
>
> Log message:
> fix export default-route.
>
> OK claudio@
>
I've just been updating some
On Fri, Dec 28, 2018 at 03:05:15PM -0700, Denis Fondras wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: de...@cvs.openbsd.org 2018/12/28 15:05:15
>
> Modified files:
> usr.sbin/bgpd : kroute.c
>
> Log message:
> move kroute_find() call later
>
> No need to scan the list
> Because you can tuna meltover, but you can't tune a fish.
> (hat tip to the author of the tunefs(8) manpage.)
And to REO Speedwagon!
On Thu, Jul 12, 2018 at 2:11 PM Philip Guenther
wrote:
> CVSROOT:/cvs
> Module name:src
> Changes by: guent...@cvs.openbsd.org2018/07/12 08:11:11
>
> Modified files:
> sys/arch/amd64/amd64: cpu.c identcpu.c locore.S machdep.c pmap.c
>
> On Fri, Feb 9, 2018, at 3:46 PM, Theo de Raadt wrote:
> > > On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote:
> > > > CVSROOT:/cvs
> > > > Module name:src
> > > > Changes by: dera...@cvs.openbsd.org 2018/02/08 20:01:24
> > > >
> > > > Modified files:
> > > > sys/dev
On Fri, Feb 9, 2018, at 3:46 PM, Theo de Raadt wrote:
> > On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote:
> > > CVSROOT: /cvs
> > > Module name: src
> > > Changes by: dera...@cvs.openbsd.org 2018/02/08 20:01:24
> > >
> > > Modified files:
> > > sys/dev: rnd.c
> > >
> On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: dera...@cvs.openbsd.org 2018/02/08 20:01:24
> >
> > Modified files:
> > sys/dev: rnd.c
> >
> > Log message:
> > Situation occur where bootloader cannot supply kern
On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: dera...@cvs.openbsd.org 2018/02/08 20:01:24
>
> Modified files:
> sys/dev: rnd.c
>
> Log message:
> Situation occur where bootloader cannot supply kernel with early
> ra
On Fri, 8 Sep 2017, Alexander Bluhm wrote:
> On Tue, Sep 05, 2017 at 10:20:12PM -0600, Philip Guenther wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: guent...@cvs.openbsd.org2017/09/05 22:20:12
> >
> > Modified files:
> > regress/sys/kern/ptrace: ptrace.c
> >
Wed, 30 Aug 2017 16:39:18 -0700 Mike Larkin
> On Wed, Aug 30, 2017 at 12:48:20AM -0700, Mike Larkin wrote:
> > On Tue, Aug 29, 2017 at 04:32:04PM -0700, Mike Larkin wrote:
> > > On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote:
> > > > Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted U
On Wed, Aug 30, 2017 at 12:48:20AM -0700, Mike Larkin wrote:
> On Tue, Aug 29, 2017 at 04:32:04PM -0700, Mike Larkin wrote:
> > On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote:
> > > Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst
> > > > CVSROOT:/cvs
> > > > Module name:
On 2017/08/30 09:04, Florian Obser wrote:
> On Tue, Aug 29, 2017 at 07:25:33PM -0700, Chris Cappuccio wrote:
> > li...@wrant.com [li...@wrant.com] wrote:
> > >
> > > Please let me know if you want me to generate some dumps or similar, but
> > > unfortunately, I can't yet test patches or handle com
On Tue, Aug 29, 2017 at 07:25:33PM -0700, Chris Cappuccio wrote:
> li...@wrant.com [li...@wrant.com] wrote:
> >
> > Please let me know if you want me to generate some dumps or similar, but
> > unfortunately, I can't yet test patches or handle compilation on my own.
> > I realise my info on this is
On Tue, Aug 29, 2017 at 04:32:04PM -0700, Mike Larkin wrote:
> On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote:
> > Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst
> > > CVSROOT: /cvs
> > > Module name: src
> > > Changes by: t...@cvs.openbsd.org2017/08/28 10:16:58
li...@wrant.com [li...@wrant.com] wrote:
>
> Please let me know if you want me to generate some dumps or similar, but
> unfortunately, I can't yet test patches or handle compilation on my own.
> I realise my info on this is incredibly lacking as quality & usefulness.
>
Stuart Henderson has an ar
Tue, 29 Aug 2017 16:32:04 -0700 Mike Larkin
> On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote:
> > Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst
> > > CVSROOT: /cvs
> > > Module name: src
> > > Changes by: t...@cvs.openbsd.org2017/08/28 10:16:58
> > >
> > >
On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote:
> Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: t...@cvs.openbsd.org2017/08/28 10:16:58
> >
> > Modified files:
> > usr.sbin/apmd : apmd.8 apmd.c
> >
>
Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst
> CVSROOT: /cvs
> Module name: src
> Changes by: t...@cvs.openbsd.org2017/08/28 10:16:58
>
> Modified files:
> usr.sbin/apmd : apmd.8 apmd.c
>
> Log message:
> add -z and -Z options to auto suspend or hibernate when low on bat
On 07/03/17 08:30, Martijn van Duren wrote:
> On 07/01/17 18:14, Mark Kettenis wrote:
>> CVSROOT: /cvs
>> Module name: src
>> Changes by: kette...@cvs.openbsd.org2017/07/01 10:14:10
>>
>> Modified files:
>> sys/dev/pci/drm: drm_irq.c drm_linux.c drm_linux.h
>>
Hi,
On Jul 4, 2017, at 7:40 AM, Mark Kettenis wrote:
>> From: Frank Groeneveld
>> Date: Tue, 04 Jul 2017 09:38:18 +0200
>>
>>> On Mon, Jul 3, 2017, at 08:30, Martijn van Duren wrote:
>>> This change *STILL* breaks my $DAYJOB machine.
>>>
>>> dmesg with DRMDEBUG enabled
>>
>> Maybe you should
> From: Frank Groeneveld
> Date: Tue, 04 Jul 2017 09:38:18 +0200
>
> On Mon, Jul 3, 2017, at 08:30, Martijn van Duren wrote:
> > This change *STILL* breaks my $DAYJOB machine.
> >
> > dmesg with DRMDEBUG enabled
>
> Maybe you shouldn't chose Apple hardware ;-)
Well. That machine used to work.
On Mon, Jul 3, 2017, at 08:30, Martijn van Duren wrote:
> This change *STILL* breaks my $DAYJOB machine.
>
> dmesg with DRMDEBUG enabled
Maybe you shouldn't chose Apple hardware ;-)
Works great here on a Thinkpad X260 Mark, thank you very much!
Frank
On 07/01/17 18:14, Mark Kettenis wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: kette...@cvs.openbsd.org2017/07/01 10:14:10
>
> Modified files:
> sys/dev/pci/drm: drm_irq.c drm_linux.c drm_linux.h
>drm_linux_list.h drm_mm.c drm_mm.h drm_mode.
On Mon, May 29, 2017 at 03:40:59PM +0200, Sebastien Marie wrote:
> On Mon, May 29, 2017 at 06:10:51AM -0600, Ted Unangst wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: t...@cvs.openbsd.org2017/05/29 06:10:51
> >
> > Removed files:
> > sys/sys: scanio.h
> >
Sebastien Marie wrote:
> On Mon, May 29, 2017 at 06:10:51AM -0600, Ted Unangst wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: t...@cvs.openbsd.org2017/05/29 06:10:51
> >
> > Removed files:
> > sys/sys: scanio.h
> >
> > Log message:
> > scanner support die
On Mon, May 29, 2017 at 06:10:51AM -0600, Ted Unangst wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: t...@cvs.openbsd.org2017/05/29 06:10:51
>
> Removed files:
> sys/sys: scanio.h
>
> Log message:
> scanner support died some time ago, the header can be removed
> Date: Sun, 16 Oct 2016 13:57:42 -0700
> From: Philip Guenther
> To: Jeremie Courreges-Anglas
> Cc: source-chan...@openbsd.org
> Subject: Re: CVS: cvs.openbsd.org: src
>
> On Sun, 16 Oct 2016, Jeremie Courreges-Anglas wrote:
> > CVSROOT:/cvs
> > Module
Should have sent this to tech...
-- Forwarded message --
Date: Sun, 16 Oct 2016 13:57:42 -0700
From: Philip Guenther
To: Jeremie Courreges-Anglas
Cc: source-chan...@openbsd.org
Subject: Re: CVS: cvs.openbsd.org: src
On Sun, 16 Oct 2016, Jeremie Courreges-Anglas wrote
On August 10, 2016 11:52:29 AM GMT+02:00, Sebastien Marie
wrote:
>On Tue, Aug 09, 2016 at 03:24:32PM -0600, Alexander Hall wrote:
>> CVSROOT: /cvs
>> Module name: src
>> Changes by: ha...@cvs.openbsd.org 2016/08/09 15:24:32
>>
>> Modified files:
>> etc: Makefile
>>
On Tue, Aug 09, 2016 at 03:24:32PM -0600, Alexander Hall wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: ha...@cvs.openbsd.org 2016/08/09 15:24:32
>
> Modified files:
> etc: Makefile
> etc/mtree : special
> Removed files:
> etc: cs
This is probably a good time to wait for a snapshot and install that.
That'll give ports builds a chance to catch up too. :-)
Philip Guenther
-- Forwarded message --
From: Philip Guenther
Date: Sat, May 7, 2016 at 12:05 PM
Subject: CVS: cvs.openbsd.org: src
To: source-chan
On Tue, 22 Dec 2015, David Coppa wrote:
> I suspect this broke my 3G connection:
Oops. Sorry. Try this diff (already committed):
--- sys/kern/tty_conf.c
+++ sys/kern/tty_conf.c
@@ -42,6 +42,11 @@
#include
#include
+#include "ppp.h"
+#include "nmea.h"
+#include "msts.h"
+#include "endrun.h"
On Mon, 21 Dec 2015, Stefan Fritsch wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: s...@cvs.openbsd.org2015/12/21 14:49:03
>
> Modified files:
> sys/kern : tty_conf.c tty_endrun.c tty_msts.c tty_nmea.c
> sys/net: ppp_tty.c
> sys/sys:
Ted Unangst wrote:
> > > Modified files:
> > > usr.bin/tail : extern.h forward.c misc.c read.c reverse.c
> > >tail.c
> > >
> > > Log message:
> > > another try to allow tailing multiple files. maybe it works?
> > > commit now to allow people to test.
> >
> > I just updat
> > Modified files:
> > usr.bin/tail : extern.h forward.c misc.c read.c reverse.c
> > tail.c
> >
> > Log message:
> > another try to allow tailing multiple files. maybe it works?
> > commit now to allow people to test.
>
> I just updated to very latest snapshot and ta
On Wed, Sep 30, 2015 at 06:07:54PM +0200, Joerg Jung wrote:
> On Wed, Sep 30, 2015 at 05:13:31PM +0200, Martijn van Duren wrote:
> > On 09/30/15 14:15, Joerg Jung wrote:
>
> > Thanks! Although it does add about 5-10 seconds to my boot-time, waiting
> > primarily for the temperature sensors.
>
> Y
On Sun, Oct 04, 2015 at 09:20:06PM +0200, Mark Kettenis wrote:
>
> Here is what I get on the Macmini 1,1 now:
>
> asmc0 at isa0 port 0x300/32
> asmc0: rev 1.3f503, 137 keys, 5 temperatures, 1 fan, 0 lights, kbdled
Thanks for testing! I think printing "0 lights" is not very useful,
so I will twea
> Date: Sun, 4 Oct 2015 14:10:18 +0200
> From: Joerg Jung
>
> On Wed, Sep 30, 2015 at 06:07:54PM +0200, Joerg Jung wrote:
> > On Wed, Sep 30, 2015 at 05:13:31PM +0200, Martijn van Duren wrote:
> > >
> > > What I find somewhat strange is that although the dmesg says it has "2
> > > lights", it on
On Wed, Sep 30, 2015 at 06:07:54PM +0200, Joerg Jung wrote:
> On Wed, Sep 30, 2015 at 05:13:31PM +0200, Martijn van Duren wrote:
> >
> > What I find somewhat strange is that although the dmesg says it has "2
> > lights", it only shows one illuminance sensor in my sysctl.
>
> This is expected. In
On Sat, Oct 3, 2015 at 2:12 AM, Vadim Zhukov wrote:
> CVSROOT:/cvs
> Module name:src
> Changes by: z...@cvs.openbsd.org2015/10/03 03:12:39
>
> Modified files:
> usr.bin/kdump : kdump.c
>
> Log message:
> Fix wrong cast.
>
> This one should be an unsigned long in theory
On Wed, Sep 30, 2015 at 05:13:31PM +0200, Martijn van Duren wrote:
> On 09/30/15 14:15, Joerg Jung wrote:
> >CVSROOT: /cvs
> >Module name: src
> >Changes by: j...@cvs.openbsd.org2015/09/30 06:15:12
> >
> >Modified files:
> > share/man/man4 : isa.4
> > sys/arch/amd64/conf: GENERIC
>
On 09/30/15 14:15, Joerg Jung wrote:
CVSROOT:/cvs
Module name:src
Changes by: j...@cvs.openbsd.org2015/09/30 06:15:12
Modified files:
share/man/man4 : isa.4
sys/arch/amd64/conf: GENERIC
sys/arch/i386/conf: GENERIC
sys/dev/isa: files.isa
Add
rl in base built against libpthread.19.0 cannot load
the mysql.so shared object linked against libpthread.18.1
Philip Guenther
-- Forwarded message --
From: Philip Guenther
Date: Mon, Apr 6, 2015 at 6:27 PM
Subject: CVS: cvs.openbsd.org: src
To: source-chan...@cvs.openbsd.org
CV
The patch below should unbreak make release.
On 07/15/14 11:14, Marc Espie wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: es...@cvs.openbsd.org 2014/07/15 03:14:50
>
> Removed files:
> etc/mtree : BSD.local.dist
>
> Log message:
> folded back into 4.4BSD.dist
> rem
> I am however curious about the rational behind this change. Does it
> solve any particular problem/risk?
> I seldomly use this style in my own scripts when I need to be able to
> dynamically determine variables at runtime. So it might be wise to know
> what hidden daemons I might be facing.
T
On 07/12/14 14:13, Stuart Henderson wrote:
On 2014/07/12 14:04, Martijn van Duren wrote:
Hello tech@,
I just saw the commit message below.
Currently I use the source functionality to determine whether I'm in my home
network or not and use it to customize sndiod_flags to redirect sound to my
mai
On 2014/07/12 14:04, Martijn van Duren wrote:
> Hello tech@,
>
> I just saw the commit message below.
> Currently I use the source functionality to determine whether I'm in my home
> network or not and use it to customize sndiod_flags to redirect sound to my
> main server.
>
> Is there an alterna
Hello tech@,
I just saw the commit message below.
Currently I use the source functionality to determine whether I'm in my
home network or not and use it to customize sndiod_flags to redirect
sound to my main server.
Is there an alternative to dynamically change the rc.conf flags based on
my
On Fri, Jul 11, 2014 at 4:37 PM, Bob Beck wrote:
> The fundamental probelm with this Matthew - is that next time, if we
> do this, by the next release we will
> be chasing what features we have imported from 1.0.2g and 10.2.z, and
> 1.0.2.qq - where does it end?
It ends whenever it stops helping
The fundamental probelm with this Matthew - is that next time, if we
do this, by the next release we will
be chasing what features we have imported from 1.0.2g and 10.2.z, and
1.0.2.qq - where does it end?
We will be continuing to add functionality in here from many sources,
and so assuming we cou
On Fri, Jul 11, 2014 at 3:41 PM, Bob Beck wrote:
> The OPENSSL_VERSION number is a guarantee for a certain version of the
> ABI. As we dont' provide that (in fact much
> of the ABI in LIbreSSL is "beyond" 1.0.1g, it is not accurate to use
> the old OPENSSL_VERSION. Essnentially this OPENSSL_VERSIO
> I'm worried that bogus codepaths will be taken in software that expects a
> certain openssl version - things failing to build we can cope with in ports
> easily enough, I'm more concerned about software that does build but behaves
> incorrectly at runtime.
If the software is that fragile, then I
I'm worried that bogus codepaths will be taken in software that expects a
certain openssl version - things failing to build we can cope with in ports
easily enough, I'm more concerned about software that does build but behaves
incorrectly at runtime.
And seeing as how they moved 0.0.4 revisons in 9 years, call that
0.0.05 revisions per year, they have approximately 194 years of
OpenSSL releases before the version numbering space will collide.
On Fri, Jul 11, 2014 at 4:41 PM, Bob Beck wrote:
> The OPENSSL_VERSION number is a guarantee for a c
The OPENSSL_VERSION number is a guarantee for a certain version of the
ABI. As we dont' provide that (in fact much
of the ABI in LIbreSSL is "beyond" 1.0.1g, it is not accurate to use
the old OPENSSL_VERSION. Essnentially this OPENSSL_VERSION
is "bigger than 1.0.1g"'s.
On Fri, Jul 11, 2014 at 4:
On 2014/07/11 15:21, Bob Beck wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: b...@cvs.openbsd.org2014/07/11 15:21:59
>
> Modified files:
> lib/libssl/src/crypto: opensslv.h
>
> Log message:
> Provide LIBRESSL_VERSION_NUMBER for people who use such things to
> detect ve
> On Thu, Jul 10, 2014 at 08:29:04AM -0600, Philip Guenther wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: guent...@cvs.openbsd.org2014/07/10 08:29:03
> >
> > Modified files:
> > usr.bin/rdist : common.c config-data.h
> >
> > Log message:
> > Assume POSIX: w
On Thu, Jul 10, 2014 at 08:29:04AM -0600, Philip Guenther wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: guent...@cvs.openbsd.org2014/07/10 08:29:03
>
> Modified files:
> usr.bin/rdist : common.c config-data.h
>
> Log message:
> Assume POSIX: write() takes size_t
, as I broke listing of /proc back in January
>and
>no one has noticed, suggesting that no one is actually using it...
>
>Philip Guenther
>
>
>-- Forwarded message --
>From: Philip Guenther
>Date: Sun, Jun 22, 2014 at 2:15 PM
>Subject: CVS: cvs.openbsd.org
g it...
>
> Philip Guenther
>
>
> -- Forwarded message --
> From: Philip Guenther
> Date: Sun, Jun 22, 2014 at 2:15 PM
> Subject: CVS: cvs.openbsd.org: src
> To: source-chan...@cvs.openbsd.org
>
>
> CVSROOT:/cvs
> Module name:src
>
y using it...
Philip Guenther
-- Forwarded message --
From: Philip Guenther
Date: Sun, Jun 22, 2014 at 2:15 PM
Subject: CVS: cvs.openbsd.org: src
To: source-chan...@cvs.openbsd.org
CVSROOT:/cvs
Module name:src
Changes by: guent...@cvs.openbsd.org2014/06/2
2013/11/19 Bob Beck :
> I'm inclined to agree with marc here - we bump minors on api additions
> - and yes, it was stubbed there before so it's not really an
> "addition" but it was stubbed to fail and had to be worked around -
> bump the minor - not like it's a big deal.
>
> On Tue, Nov 19, 2013 a
I'm inclined to agree with marc here - we bump minors on api additions
- and yes, it was stubbed there before so it's not really an
"addition" but it was stubbed to fail and had to be worked around -
bump the minor - not like it's a big deal.
On Tue, Nov 19, 2013 at 12:02 AM, Marc Espie wrote:
>
> On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote:
> > On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote:
> >
> > >> btw, no library version change because the function stubs already
> > >> existed.
> > >
> > > Hmm, since this is actually offering new functionality (by sem_open()
>
On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote:
> On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote:
>
> >> btw, no library version change because the function stubs already
> >> existed.
> >
> > Hmm, since this is actually offering new functionality (by sem_open()
> > and friends
On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote:
>> btw, no library version change because the function stubs already
>> existed.
>
> Hmm, since this is actually offering new functionality (by sem_open()
> and friends no longer always failing), I think it a minor bump would
> be appropriate.
> On Mon, Nov 18, 2013 at 3:19 PM, Ted Unangst wrote:
> > On Mon, Nov 18, 2013 at 16:10, Ted Unangst wrote:
> >> CVSROOT: /cvs
> >> Module name: src
> >> Changes by: t...@cvs.openbsd.org2013/11/18 16:10:48
> >>
> >> Modified files:
> >> lib/librthread : rthread.h rthread_sem.c
> >>
> >
On Mon, Nov 18, 2013 at 3:19 PM, Ted Unangst wrote:
> On Mon, Nov 18, 2013 at 16:10, Ted Unangst wrote:
>> CVSROOT: /cvs
>> Module name: src
>> Changes by: t...@cvs.openbsd.org2013/11/18 16:10:48
>>
>> Modified files:
>> lib/librthread : rthread.h rthread_sem.c
>>
>> Log message:
>> in
On 2013-W40-2 16:56 -0600, Todd C. Miller wrote:
> On Mon, 30 Sep 2013 19:26:20 -0700, "Constantine A. Murenin" wrote:
>
> > Whereas it remains to be seen what kind of bug I'm facing here
> > (Google reveals I'm not alone), it would appear that changes
> > introduced in 5.4-current would no long
On Mon, 30 Sep 2013 19:26:20 -0700, "Constantine A. Murenin" wrote:
> Whereas it remains to be seen what kind of bug I'm facing here
> (Google reveals I'm not alone), it would appear that changes
> introduced in 5.4-current would no longer cause spamd to report
> such situation, because the 0 t
Hello,
On OpenBSD 5.2 amd64, my spamd (which is used very selectively through
pf(4)) seems to have died 20 days ago, after continuously running for
many months, with the following final words in the logs:
Sep 10 09:49:25 Cns spamd[5220]: 87.225.1.10: connected (1/1), lists:
spamd-greytrap
Sep
On 06/08/13 03:14, Jonathan Gray wrote:
On Sat, Jun 08, 2013 at 03:06:26AM -0400, Scott McEachern wrote:
On 06/08/13 02:38, Ville Valkonen wrote:
Hi, did you compile the recent Xenocara too?
No, I didn't get that far. Just the kernel. That's how I know it
wasn't the recent xenocara updates t
On Sat, Jun 08, 2013 at 03:06:26AM -0400, Scott McEachern wrote:
> On 06/08/13 02:38, Ville Valkonen wrote:
> >Hi, did you compile the recent Xenocara too?
>
> No, I didn't get that far. Just the kernel. That's how I know it
> wasn't the recent xenocara updates that caused the problem and
> beli
On 06/08/13 02:38, Ville Valkonen wrote:
Hi, did you compile the recent Xenocara too?
No, I didn't get that far. Just the kernel. That's how I know it
wasn't the recent xenocara updates that caused the problem and believe
this specific commit is the culprit.
However, you did get me thinki
Hi, did you compile the recent Xenocara too?
On Jun 8, 2013 9:30 AM, "Scott McEachern" wrote:
> On 06/07/13 16:46, Mark Kettenis wrote:
>
>> CVSROOT:/cvs
>> Module name:src
>> Changes by: kette...@cvs.openbsd.org2013/06/07 14:46:15
>>
>> Modified files:
>> sys/uvm
On 06/07/13 16:46, Mark Kettenis wrote:
CVSROOT:/cvs
Module name:src
Changes by: kette...@cvs.openbsd.org2013/06/07 14:46:15
Modified files:
sys/uvm: uvm_device.c uvm_device.h
sys/dev/pci/drm: drm.h drmP.h drm_drv.c
sys/dev/pci/drm/i915: i9
On Sun, Aug 12, 2012 at 10:14 AM, Miod Vallat
wrote in a commit message:
...
> Passes the regress tests, and now devel/libsigsegv configure siglongjmp test
> will not spin (this test is however flawed as it expects a signal handler
> declared as running on the sigaltstack and `returning' through s
1 - 100 of 107 matches
Mail list logo
