https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224270
--- Comment #3 from Conrad Meyer ---
(In reply to Jilles Tjoelker from comment #2)
Plenty of people like that behavior, though. It seems like if we implement
pipefail we should follow existing expectations. If you want a looser option,
ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224330
--- Comment #2 from Mark Millard ---
(In reply to Mark Millard from comment #0)
I should have noted:
The rpi2 is a v1.1 one, a Cortex-A7, armv7 context.
Pine64 has a Cortex-A53, aarch64 context.
(rpi2 v1.2 would be Cortext-A53, thus th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223831
--- Comment #7 from o...@j.email.ne.jp ---
(In reply to Konstantin Belousov from comment #6)
I created https://reviews.freebsd.org/D13484 for this case.
I have another change-set for a improvement and also created
https://reviews.freebsd.o
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224330
Cy Schubert changed:
What|Removed |Added
CC||c...@freebsd.org
--- Comment #1 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224330
Mark Millard changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224330
Bug ID: 224330
Summary: head -r326347 breaks USB on rpi2 and pine64 (and
likely more)
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=87651
Mark Linimon changed:
What|Removed |Added
Resolution|--- |Overcome By Events
Statu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224270
--- Comment #2 from Jilles Tjoelker ---
The implementation of set -o pipefail would be fairly easy, but I don't like
that a SIGPIPE exit of a non-final process will also be treated as an error.
--
You are receiving this mail because:
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=87651
fernando.apesteg...@gmail.com changed:
What|Removed |Added
CC||fernando.apesteguia@g
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224326
Bug ID: 224326
Summary: double subnormals are not well printed on printing
with printf (and friends)
Product: Base System
Version: 11.0-STABLE
Hardware: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220727
Sam Gwydir changed:
What|Removed |Added
CC||s...@samgwydir.com
--- Comment #4 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210537
--- Comment #20 from Eugene Grosbein ---
(In reply to Mikhail T. from comment #17)
> Ironically, the very uuencode code, which you referred me to has lines like:
>
>rv = b64_ntop(buf, n, buf2, (sizeof(buf2) / sizeof(buf2[0])));
No, it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210537
--- Comment #19 from Eugene Grosbein ---
(In reply to Mikhail T. from comment #18)
Fine.
One more: https://tools.ietf.org/html/rfc2045#section-4 says:
Messages composed in accordance with this document MUST include such
a header field, w
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210537
--- Comment #18 from Mikhail T. ---
(In reply to Eugene Grosbein from comment #16)
> Wouldn't it better to use MAGIC_MIME_ENCODING instead of MAGIC_MIME
I still need the mime type to populate the Content-Type header. I do not need
the char
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210537
--- Comment #17 from Mikhail T. ---
(In reply to Eugene Grosbein from comment #16)
> our libc actually has b64_ntop() function for base64 encoding provided with
>
I saw that, but it asks for a buffer to fill, whereas -lcrypto's implement
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182466
Herbert J. Skuhra changed:
What|Removed |Added
CC||h.sku...@gmail.com
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210537
Eugene Grosbein changed:
What|Removed |Added
Status|New |In Progress
--- Comment #16 from
17 matches
Mail list logo