On 2023-12-10, Lucas de Sena wrote:
> I could identify the following bugs in make(1), concerning the
> "%" character on a variable substitution:
>
> - If there's no "%" in the left or right hand side string of a
> variable substitution, make(1) prepends o
I could identify the following bugs in make(1), concerning the
"%" character on a variable substitution:
- If there's no "%" in the left or right hand side string of a
variable substitution, make(1) prepends one into them. Thus
${SRCS:.c=.o} is equivalent to ${SR
>Synopsis: cannot add prerequisites without commands in make(1)
>Category: user
>Environment:
System : OpenBSD 6.9
Details : OpenBSD 6.9 (GENERIC.MP) #4: Tue Aug 10 08:12:23 MDT 2021
r...@syspatch-69-amd64.openbsd.org:/usr/src
I will report the bug directly to OpenLDAP, as this is a bug with slaptest
command who did not update my olcTLSCertificate entries.
De : C. G.
Envoyé : lundi 28 juin 2021 00:00
À : Stuart Henderson
Cc : bugs@openbsd.org
Objet : RE: Unable to make OpenLDAP work
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 3
result: 32 No such object
# numResponses: 1
SO : THAT MEANS I WILL BE ABLE TO INSTALL THE MOST SECURE OS IN THE WORLD ON MY
CUSTOMERS'S SERVERS for those who want SECURITY
rt hes no LibreSSL support.
> ━━━
> De : Stuart Henderson
> Envoyé : samedi 26 juin 2021 18:11
> À : C. G.
> Cc : bugs@openbsd.org
> Objet : Re: Unable to make OpenLDAP work with TLS
>
>
nLDAP package nor the port hes no LibreSSL support.
De : Stuart Henderson
Envoyé : samedi 26 juin 2021 18:11
À : C. G.
Cc : bugs@openbsd.org
Objet : Re: Unable to make OpenLDAP work with TLS
On 2021/06/26 12:51, C. G. wrote:
> I think it's a LIbreSSL-
On 2021/06/26 12:51, C. G. wrote:
> I think it's a LIbreSSL-related issue, because I did the same exact
> config procedure on Ubuntu, CentOS, FreeBSD, OmniOS, and it worked,
> and on the only OS that uses LibreSSL, it doesn't work.
What can I say; I am running OpenLDAP 2.4.58 slapd on OpenBSD 6.9
se
encrypted connections with TLS 1.3 in Apache and OpenLDAP during a full
release, I mean, that's not serious. LibreSSL just breaks things, to my POV.
De : Stuart Henderson
Envoyé : samedi 26 juin 2021 15:21
À : C. G.
Cc : bugs@openbsd.org
Objet : Re: Un
On 2021/06/25 22:48, C. G. wrote:
> "You are making things hard for yourself. If you want to edit config
> online via LDAP commands then use olc and use LDAP commands to edit it."
>
> I don't have enough experience on LDAP to modify the database online with
> ldap commands. That's why I use slapt
erson
Envoyé : samedi 26 juin 2021 01:37
À : C. G.
Cc : bugs@openbsd.org
Objet : Re: Unable to make OpenLDAP work with TLS
On 2021/06/25 21:26, C. G. wrote:
> Sorry, I tried the solutions you posted,
No you didn't; I said:
"Try with chain.pem not fullchain.pem for TLSCACertificateFi
___
De : Stuart Henderson
Envoyé : samedi 26 juin 2021 01:37
À : C. G.
Cc : bugs@openbsd.org
Objet : Re: Unable to make OpenLDAP work with TLS
On 2021/06/25 21:26, C. G. wrote:
> Sorry, I tried the solutions you posted,
No you didn't; I said:
"Try with chain.pem not fullcha
On 2021/06/25 21:26, C. G. wrote:
> Sorry, I tried the solutions you posted,
No you didn't; I said:
"Try with chain.pem not fullchain.pem for TLSCACertificateFile.
OpenLDAP's TLS config is a bit nonstandard compared to other software."
but you show another file with fullchain.pem, and
"The serv
ZZ option in ldap commands :
ldap_start_tls: Protocol error (2)
additional info: unsupported extended operation
Without the -ZZ option, everything works just fine.
OpenBSD 6.9 -release
De : Stuart Henderson
Envoyé : vendredi 25 juin 2021 10:51
À : C. G.
Cc : bugs
al info: unsupported extended operation
Without the -ZZ option, everything works just fine.
OpenBSD 6.9 -release
De : Stuart Henderson
Envoyé : vendredi 25 juin 2021 19:18
À : C. G.
Cc : bugs@openbsd.org
Objet : Re: Unable to make OpenLDAP work with TLS
On 20
come back to you.
De : Stuart Henderson
Envoyé : vendredi 25 juin 2021 19:20
À : C. G.
Cc : bugs@openbsd.org
Objet : Re: Unable to make OpenLDAP work with TLS
On 2021/06/25 15:07, C. G. wrote:
> I forgot to say that my /etc/openldap/certs has the follow
On 2021/06/25 15:07, C. G. wrote:
> I forgot to say that my /etc/openldap/certs has the following permissions :
> (ls -l /etc/openldap)
>
> drwxr-xr-x 2 _openldap _openldap 512 Jun 25 05:33 certs
>
> # ls -l certs
> total 20
> -rwxr-xr-x 1 _openldap _openldap 1631 Jun 25 05:35 cert.pem
>
On 2021/06/25 14:48, C. G. wrote:
> I'm sorry, my /etc/rc.conf.local has exactly the settings you just suggested
> to me :
>
> # cat /etc/rc.conf.local
> pf=NO
> pkg_scripts=slapd
> slapd=YES
> slapd_flags="-4 -u _openldap -g _openldap ldap:///\ ldaps:///\ ldapi:///"
>
> I started the server usi
bugs@openbsd.org
Objet : Re: Unable to make OpenLDAP work with TLS
On 2021/06/25 02:03, C. G. wrote:
> When I try to use the ldapsearch or ldapwhoami commands with the -ZZ option,
> I get this error :
>
> ldap_start_tls: Protocol error (2)
> additional info: unsupported extended op
SD is Solaris 11.4 in which I get the exact
same error when I enable TLS in slapd.conf and when I use the -ZZ option in
ldapsearch and ldapwhoami commands.
De : Stuart Henderson
Envoyé : vendredi 25 juin 2021 10:51
À : C. G.
Cc : bugs@openbsd.org
Objet : Re: Una
On 2021/06/25 02:03, C. G. wrote:
> When I try to use the ldapsearch or ldapwhoami commands with the -ZZ option,
> I get this error :
>
> ldap_start_tls: Protocol error (2)
> additional info: unsupported extended operation
>
> The same commands work fine without the TLS -ZZ option.
I've confirm
uname -r :
6.9
OpenBSD 6.9 (GENERIC) #464: Mon Apr 19 10:28:56 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 2130640896 (2031MB)
avail mem = 2050850816 (1955MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at
Hi,
Early this month I produced a patch, nothing since 6.9 was committed in
print-wg.c, I just want to bring this to your attention:
https://marc.info/?l=openbsd-bugs&m=162005952303873&w=2
Best Regards,
-peter
>Synopsis: Patch to make the German T3 keyboard layout functional in
>xenocara
>Category: system
>Environment:
System : OpenBSD 6.8
Details : OpenBSD 6.8-stable (GENERIC.MP) #31: Sat Dec 19 09:24:41
CET 2020
wim...@neo2.my
On Sat, Apr 18, 2020 at 10:10:41PM +0200, Olivier Antoine wrote:
> Hi,
>
> During the installation process with the latest available bsd.rd, at
> the step 'Making all devices nodes' I noticed the following error
> message twice:
> chgrp : group is invalid: _sndiop
>
> Saw that on bsd.rd amd64 17
On 2020/04/18 22:10, Olivier Antoine wrote:
> Hi,
>
> During the installation process with the latest available bsd.rd, at
> the step 'Making all devices nodes' I noticed the following error
> message twice:
> chgrp : group is invalid: _sndiop
>
> Saw that on bsd.rd amd64 17 Apr 2020 during a fre
Hi,
During the installation process with the latest available bsd.rd, at
the step 'Making all devices nodes' I noticed the following error
message twice:
chgrp : group is invalid: _sndiop
Saw that on bsd.rd amd64 17 Apr 2020 during a fresh install.
Didn't notice any problem after.
Cheers,
--
On 29/01/20(Wed) 15:00, Marc Espie wrote:
> On Wed, Jan 29, 2020 at 02:04:06PM +0100, Martin Pieuchot wrote:
> > Diff below enables a ptrace(2) regress coming from NetBSD.
> >
> > With usr.bin/make built since -D2020-01-14, that includes -current, it
> > com
Running t_ptrace manually with the simplest possible code
shows the same problem:
#include
#include
#include
#include
int main()
{
int i = fork();
if (i == -1)
err(1, "fork");
if (i == 0) {
exe
On Wed, Jan 29, 2020 at 02:04:06PM +0100, Martin Pieuchot wrote:
> Diff below enables a ptrace(2) regress coming from NetBSD.
>
> With usr.bin/make built since -D2020-01-14, that includes -current, it
> complains during the last test:
>
> make: Child (52049) not in tab
Diff below enables a ptrace(2) regress coming from NetBSD.
With usr.bin/make built since -D2020-01-14, that includes -current, it
complains during the last test:
make: Child (52049) not in table?
FAILED
That results in a failing test, however the syscall correctly reports
EBUSY
gt; > return B.CreateLoad(Guard, true, "StackGuard");
> > + }
> >
> >// Use SelectionDAG SSP handling, since there isn't an IR guard.
> >//
> >
> > > Wiadomość napisana przez Patrick Wildt w dniu
> > > 05.07.2019,
Patrick Wildt w dniu
> > 05.07.2019, o godz. 09:02:
> >
> > On Tue, Jul 02, 2019 at 02:07:22PM +0200, Krystian Lewandowski wrote:
> >>
> >>> Wiadomość napisana przez Krystian Lewandowski w
> >>> dniu 01.07.2019, o godz. 21:50:
> >>>
>
>
> On Tue, Jul 02, 2019 at 02:07:22PM +0200, Krystian Lewandowski wrote:
>>
>>> Wiadomość napisana przez Krystian Lewandowski w dniu
>>> 01.07.2019, o godz. 21:50:
>>>
>>> I thought it would be a good idea to rebuild cross-tools because of LLVM
>
> Wiadomość napisana przez Krystian Lewandowski w dniu
> 05.07.2019, o godz. 22:46:
>
> Based on information from Dimitry Andric:
> https://bugs.llvm.org/show_bug.cgi?id=42478
> - it does happen only for -triple aarch64-unknown-openbsd
> - with -stack-protector 2
> I tried to find a reason f
p
> > but - with recent src - I'm unable to do so:
> > $ doas make -f Makefile.cross TARGET=${target} CROSSDIR="${destdir}"
> > cross-tools
> > fails with:
> > aarch64-unknown-openbsd6: error: unable to execute command: Segmentation
> > fault
>
> Wiadomość napisana przez Krystian Lewandowski w dniu
> 01.07.2019, o godz. 21:50:
>
> I thought it would be a good idea to rebuild cross-tools because of LLVM
> version bump
> but - with recent src - I'm unable to do so:
> $ doas make -f Makefile.cross TARGET=${t
8 AM, Theo Buehler wrote:
> On Tue, May 07, 2019 at 03:02:24PM +0200, Martijn van Duren wrote:
>> Hello,
>>
>> When trying to make p5-Net-SNMP connect to snmpd with seclevel enc it
>> fails to do so. This is because NET::SNMP verifies agains
>>
On Tue, May 07, 2019 at 03:02:24PM +0200, Martijn van Duren wrote:
> Hello,
>
> When trying to make p5-Net-SNMP connect to snmpd with seclevel enc it
> fails to do so. This is because NET::SNMP verifies agains
> usmStatsUnknownEngineIDs, while we return usmStatsUnsup
Hello,
Part 2 of making NET::SNMP work with snmpd(8) in seclevel enc mode.
RFC3414 Chapter 4 states:
If authenticated communication is required, then the discovery
process should also establish time synchronization with the
authoritative SNMP engine. This may be accomplished by sending an
authen
Hello,
When trying to make p5-Net-SNMP connect to snmpd with seclevel enc it
fails to do so. This is because NET::SNMP verifies agains
usmStatsUnknownEngineIDs, while we return usmStatsUnsupportedSecLevels.
According to RFC3414 chapter 4 we should return usmStatsUnknownEngineIDs
when: Request
THAT does not work.
Or more accurately, this triggers another issue,
because we do suffix work even for PHONY nodes,
so this breaks autoconf/2.52, which has an
install PHONY target, an install.texi file,
and a rule for .texi
Hilarity ensues.
That function SuffFindNormalDeps is entangled
enough t
a
> FINAL_TARGETS_PREREQUISITE=something.b
> FINAL_TARGETS=1 2 3
> all: $(FINAL_TARGETS)
> $(FINAL_TARGETS): $(FINAL_TARGETS_PREREQUISITE)
> .a.b:
> cat < $< > $@
> .c:
> cat < $< > $@
>
> $PROMPT#> make
> cat < something.a > someth
ARGETS): $(FINAL_TARGETS_PREREQUISITE)
.a.b:
cat < $< > $@
.c:
cat < $< > $@
$PROMPT#> make
cat < something.a > something.b
=== Expected behaviour ===
cat < something.a > something.b
cat < 1.c > 1
cat < 2.c > 2
cat < 3.c > 3
recent snapshot of OpenBSD btw
Basically, compat mode vs make-j should disappear at some point.
I need to find some time to work on the unified engine...
>Synopsis: the -q switch to make has no effect in "compatibility mode"
>which is the default
>Category: user
>Environment:
System : OpenBSD 6.3
Details : OpenBSD 6.3-current (GENERIC.MP) #192: Sun Apr 15
23:26:13 MDT 2018
Hello,
found multiple crashes of make utility on parsing files.
For all crashes testcase is the same: make -q -f .
Tarball with all reproducers attached. Found with afl-fuzz.
# make -q -f report-make/tc2
assertion "comment != line" failed: file "parse.c", line 1046, funct
I've looked at this. So far no real clue.
The maddening thing is that the code that triggers single suffix in
the non directory case is the same in freebsd's bmake and ours,
so obviously it doesn't trigger when there's an extra directory, as
the paths don't match.
I'll have to check if there's som
OpenBSD "make" does not correctly apply single-suffix inference rules
to paths containing slashes. Double-suffix inference rules work
correctly in this situation. Here's a little demonstration, starting
with a double-suffix inference rule and a sub-directory:
$ mkdir a
$
> >
> > Now, this was observed on OpenBSD 5.8, but a search for the changes and
> > fixes between that version and 6.0 doesn't show any changes for make.
> >
> > >How-To-Repeat:
> > === TEST MAKEFILE ===
> > a.o:# just touc
On Fri, Oct 07, 2016 at 09:03:40AM -0400, Dario Niedermann wrote:
> >Synopsis: make: empty expansion of $( >Category:user
> >Environment:
> System : OpenBSD 5.8
> Details : OpenBSD 5.8 (GENERIC.MP) #1: Wed Oct 14 19:40:42 CEST 2015
>
On Sun, May 8, 2016, at 23:41, Theo de Raadt wrote:
> Ignore faq/current.html at your own risk.
I am not quite sure which part of it you mean here.
I have built a new ld.so like current.html said:
cd /usr/src
make obj
make cleandir
make includes
cd /usr/src/libexec/ld.so
make SUBDIR= obj
m
Ignore faq/current.html at your own risk.
I get a SIGSEGV when I run 'make build' in /usr/src on octeon
(edgerouter lite):
# make build
cd /usr/src/share/mk && exec make install
install -c -o root -g bin -m 444 bsd.README bsd.dep.mk bsd.lib.mk bsd.man.mk
bsd.obj.mk bsd.own.mk bsd.port.arch.mk bsd.port.mk
cd /usr/src/bin/pax
| make obj
|make
|make install
|
|
|Index: bin/pax/ar_subs.c
|===
|RCS file: /cvs/src/bin/pax/ar_subs.c,v
|retrieving revision 1.41
|diff -u -p -r1.41 ar_subs.c
|--- bin/pax/ar_subs.c 21
Synopsis:
Category:
Environment:
System : OpenBSD 5.4
Details : OpenBSD 5.4 (XXX) #7: Thu Mar 13 10:08:46 MSK 2014
d...@xxx.xxx:/usr/src/sys/arch/i386/compile/XXX
Architecture: OpenBSD.i386
Machine : i386
Descriptio
Hi,
This is not a bug.
If you want to have a chance of getting your diff accepted, send it to
the proper list (tech@) and make sure your formatting conforms to
KNF, the diff isn't mangled by your mailer and the neccesary man page
pieces are included.
-Otto
On Thu, May 22, 2014
legends:
-->
-=>
=->
==>
<--
<=-
<-=
<==
--- /usr/src/usr.bin/fstat/fstat.c Wed Oct 23 00:40:27 2013
+++ /usr/src/usr.bin/fstat/fstat.c Thu May 22 15:59:22 2014
@@ -616,6 +616,23 @@
}
}
+void print_connection_state(uint32_t s)
+{char *o,p[]=" <==> ";
+ if(SS_CONNECTOUT&s)
+ {o=p+1;
+ o[0]='
th. When doing chroot, this would make
an unusable symbolic link.
The behavior change was introduced in OpenBSD src/usr.bin/ssh/sftp.c,v
1.132 and based on my understanding of the commit log, this is not
intentional.
How to reproduce:
# sftp dtest
sftp> symlink ./l1 22
sftp> ^D
# ssh dtest
On Wed, Aug 08, 2012 at 09:03:21PM +0200, Mark Kettenis wrote:
>
> What happens if you use make -j1?
that works
$ touch mysource.c; make -j1
date > /home/marco/myobj.o
date > myprog
> Date: Fri, 3 Aug 2012 14:21:06 +0200
> From: Marco Pfatschbacher
>
> If you address targets in a mixed form,
> as in: with or without their full path,
> make ignores source dependencies.
>
> Example
>
> $ cat Makefile
> all: myprog
>
> myobj.o: my
If you address targets in a mixed form,
as in: with or without their full path,
make ignores source dependencies.
Example
$ cat Makefile
all: myprog
myobj.o: mysource.c
date > $@
#myprog: myobj.o <- this would work
myprog: ${.CURDIR}/myobj.o
date > $@
[ first run
The following reply was made to PR system/6620; it has been noted by GNATS.
From: Myk Taylor
To: "Todd C. Miller"
Cc: "gn...@openbsd.org"
Subject: Re: system/6620: make build fails while building perl
Date: Wed, 01 Jun 2011 15:07:52 -0700
On 06/01/11 07:39, Todd C. Mill
The following reply was made to PR system/6620; it has been noted by GNATS.
From: "Todd C. Miller"
To: Myk Taylor
Cc: "gn...@openbsd.org"
Subject: Re: system/6620: make build fails while building perl
Date: Wed, 01 Jun 2011 10:39:37 -0400
This can also be caused by doin
The following reply was made to PR system/6620; it has been noted by GNATS.
From: Claudio Jeker
To: Myk Taylor
Cc: "gn...@openbsd.org"
Subject: Re: system/6620: make build fails while building perl
Date: Mon, 30 May 2011 09:08:56 +0200
On Sun, May 29, 2011 at 08:11:54PM -0700,
>Number: 6620
>Category: system
>Synopsis: make build fails while building perl, unable to find libraries
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible:bugs
>State: open
>Quarter:
>Keywords:
The following reply was made to PR user/6509; it has been noted by GNATS.
From: Reyk Floeter
To: Reyk Floeter
Cc: Stuart Henderson , gn...@openbsd.org,
Jonathan Gray
Subject: Re: user/6509: relayctl show sessions make relayd crash
Date: Thu, 19 May 2011 14:30:42 +0200
On Thu, May 19
The following reply was made to PR user/6509; it has been noted by GNATS.
From: Reyk Floeter
To: Stuart Henderson
Cc: r...@openbsd.org, gn...@openbsd.org, Jonathan Gray
Subject: Re: user/6509: relayctl show sessions make relayd crash
Date: Thu, 19 May 2011 13:59:36 +0200
On Thu, May 19, 2011
The following reply was made to PR user/6509; it has been noted by GNATS.
From: Reyk Floeter
To: Stuart Henderson
Cc: gn...@openbsd.org, Jonathan Gray ,
Reyk Floeter
Subject: Re: user/6509: relayctl show sessions make relayd crash
Date: Thu, 19 May 2011 12:33:10 +0200
I still get the
The following reply was made to PR user/6509; it has been noted by GNATS.
From: Stuart Henderson
To: gn...@openbsd.org
Cc: Jonathan Gray , Reyk Floeter
Subject: Re: user/6509: relayctl show sessions make relayd crash
Date: Wed, 18 May 2011 15:30:58 +0100
jsg@ wrote on 2010-11-18:
>
On Sun, 20 Feb 2011, klerfe [Bodegas] wrote:
> Anyone have a clue? After kernel successfully compiled (rtag
> OPENBSD_4_8, stable branch) make build has failed with the following:
Since you provided no information about the setup, I checked my crystal
ball and it suggested that you are
Anyone have a clue? After kernel successfully compiled (rtag
OPENBSD_4_8, stable branch) make build has failed with the following:
cc: unrecognized option '-I/usr/src/lib/libc/include'
cc: unrecognized option '-DAPIWARN'
cc: unrecognized option '-DYP'
cc: unrec
The following reply was made to PR user/6509; it has been noted by GNATS.
From: Jan Johansson
To: Jonathan Gray
Cc: gn...@openbsd.org
Subject: Re: user/6509: relayctl show sessions make relayd crash
Date: Thu, 2 Dec 2010 22:50:26 +0100
Hello!
Sorry for my late response, there was an typo
The following reply was made to PR user/6509; it has been noted by GNATS.
From: Jonathan Gray
To: janj+open...@wemf.org
Cc: gn...@openbsd.org
Subject: Re: user/6509: relayctl show sessions make relayd crash
Date: Fri, 19 Nov 2010 04:28:45 +1100
The problem is we have multiple handlers and get
The problem is we have multiple handlers and get
IMSG_STATISTICS when in the secondary handler.
Try the following diff from reyk:
Index: relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.124
diff -u -p -r
>Number: 6509
>Category: user
>Synopsis: relayctl show sessions make relayd crash
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible:bugs
>State: open
>Quarter:
>Keywords:
>Date-
On Sun, Oct 24, 2010 at 2:16 AM, Martynas Venckus wrote:
>
> actually, c99 requires all of those macros expand to the constant expressions.
>
> - make HUGE_VAL, HUGE_VALF, HUGE_VALL, INFINITY, NAN expand to the
> constant expressions with the help of gcc post-3.3.
>
> i'
3.3-or-newer case. The gcc2 platforms will obviously continue
> to be non-compliant. ok guenther@ on the math.h bit.
actually, c99 requires all of those macros expand to the constant expressions.
- make HUGE_VAL, HUGE_VALF, HUGE_VALL, INFINITY, NAN expand to the
constant expressions with the he
On Sat, 23 Oct 2010, Landry Breuil wrote:
> i'm porting an app which uses:
> static gdouble line_speed = NAN;
> static gdouble line_course = NAN;
>
> which yields:
> gpspoint.c:84: error: initializer element is not constant
> gpspoint.c:85: error: initializer element is not constant
>
> Kirill By
On Sat, Oct 23, 2010 at 11:40 AM, Landry Breuil wrote:
> Hi,
>
> i'm porting an app which uses:
> static gdouble line_speed = NAN;
> static gdouble line_course = NAN;
>
> which yields:
> gpspoint.c:84: error: initializer element is not constant
> gpspoint.c:85: error: initializer element is not co
Hi,
i'm porting an app which uses:
static gdouble line_speed = NAN;
static gdouble line_course = NAN;
which yields:
gpspoint.c:84: error: initializer element is not constant
gpspoint.c:85: error: initializer element is not constant
Kirill Bychkov pointed out
(http://marc.info/?l=openbsd-ports&m=
The following reply was made to PR user/6494; it has been noted by GNATS.
From: Jason McIntyre
To: gn...@openbsd.org
Cc:
Subject: Re: user/6494: make -q exits with -1
Date: Sat, 23 Oct 2010 07:52:30 +0100
On Fri, Oct 22, 2010 at 07:50:34PM +0100, Jason McIntyre wrote:
>
> the man p
The following reply was made to PR user/6494; it has been noted by GNATS.
From: Jason McIntyre
To: gn...@openbsd.org
Cc:
Subject: Re: user/6494: make -q exits with -1
Date: Fri, 22 Oct 2010 19:50:34 +0100
On Wed, Oct 20, 2010 at 02:59:00PM +0200, boudew...@indes.com wrote:
> >
>Number: 6494
>Category: user
>Synopsis: make(1) man page states -q exits with 1 or 0, but -1 is also
>possible
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible:bugs
>State: open
>Quarter:
&g
The following reply was made to PR i386/6311; it has been noted by GNATS.
From: Auclair Vincent
To: gn...@cvs.openbsd.org
Cc:
Subject: Re: i386/6311: alc driver make machine reboot
Date: Mon, 12 Apr 2010 14:53:27 +0200
I did some research.
On FreeBSD the driver works perfectly. (it was
85 matches
Mail list logo
