Re: COLUMNS handling

So COLUMNS and LINES are not needed for automatic correct behavior in a modern environment... So we still have the questions: useful to restrain programs from stomping all over the terminal which is what POSIX mandates ? Should we jump that way ?

Re: remove 'returns no value' from man pages

On Fri, Mar 11, 2016 at 05:18:52PM -0800, Michael McConville wrote: > This is specified only irregularly, and people who don't know what a > void return type means are beyond help anyway. > > This also adds a sentence specifying that X509_free(3) is NULL-safe, now > that we've removed all

Re: remove 'returns no value' from man pages

On Sat, Mar 12, 2016 at 01:18:18PM -0800, Michael McConville wrote: > Marc Espie wrote: > > On Fri, Mar 11, 2016 at 05:18:52PM -0800, Michael McConville wrote: > > > This is specified only irregularly, and people who don't know what a > > > void return type m

Re: manual section search order

Hardcoding stuff makes no sense. There are enough variations out there. Default + config probably. As far as putting links in the faq, does it make sense to let man resolve stuff instead of providing the redirection link directly ? Actually, I think that in this day and age, the query? syntax

Re: manual section search order

On Tue, Apr 12, 2016 at 09:50:44PM +0200, Ingo Schwarze wrote: > Exactly what i did. It already works. Try it. Ah, but the .Xr inside the renderer html still use the old ?query syntax, so it is not exactly obvious this is going to work!

Re: make patch: more extensive sinclude support

This survived a full bulk build. Now I'm fishing for okays. (and a seeing eye) On Tue, May 10, 2016 at 04:42:25PM +0200, Marc Espie wrote: > Both bmake and gmake support a list of files in include/sinclude > "systemV style". > > Adding this to our make would make us sl

new optimisation in dpb

People might be interested to know dpb has a new "permanent log". I've moved the "most common dependencies" into build-stats, so that dpb can use it from one run to the next. I hadn't done that before because it used to be a mixed bag of blessings: run LISTING quickly on some ports, then do a

Re: new optimisation in dpb

(if you don't have a specific interest in ports dependencies fun, you can stop reading now). Just as an example, my 25 most common dependencies + their deps end up as a list of 283 ports Here's the vars.log excerpt Most of these should be familiar to bulk builders. (which more or less means

Re: proot: why is it a bigger deal than you think

On Tue, May 10, 2016 at 01:48:18PM +, Christian Weisgerber wrote: > On 2016-05-09, Marc Espie <es...@nerim.net> wrote: > > > So far, I've been underwhelmed by the response to proot. Seems people don't > > get the picture yet. > > Probably because there has bee

make patch: more extensive sinclude support

Both bmake and gmake support a list of files in include/sinclude "systemV style". Adding this to our make would make us slightly more compatible. It also allows modern dependency patterns a la .sinclude ${SRC:R:=.d} Just went thru a full make build. could use a few eyes. The change is

ports vs mandoc, the links

Source has been wiped out of extraneous links... looks like some ports could be too (just took a random sample: bzip2) No idea whether we need some automated tool, or just @commenting out the extra entry in PLIST would be enough. If anything, we can probably write something that looks at

Re: ports vs mandoc, the links

On Mon, May 09, 2016 at 06:11:08PM +0200, Ingo Schwarze wrote: > So, bzip2(1) is actually an excellent example. > > These lines are required: > > @man man/man1/bzcat.1 > @man man/man1/bzcmp.1 > @man man/man1/bzdiff.1 > @man man/man1/bzegrep.1 > @man man/man1/bzfgrep.1 > @man

proot: why is it a bigger deal than you think

I've been routinely building ports with it over the last week. It's not bump-free *yet* but it works, and it's going to get better. One good reason it's useful is because it allows people to use the same platform to build ports that they're running stuff on. Keeping the ports isolated in a

Re: libtool -bindir support

On Mon, Aug 01, 2016 at 01:58:24PM +0200, Jeremie Courreges-Anglas wrote: > j...@wxcvbn.org (Jeremie Courreges-Anglas) writes: > > > +cc espie and jasper > > > > Antoine Jacoutot writes: > > > >> On Sun, Jul 31, 2016 at 07:21:39PM +0200, Antoine Jacoutot wrote: > >>> On

Re: Root can panic kernel with mknod on a tmpfs filesystem

On Tue, Jul 05, 2016 at 07:21:57PM -0400, Ted Unangst wrote: > Tim Newsham wrote: > > Recommendation: > > Validate the device number vap->va_rdev in tmpfs_mknod() and return > > an error if it is VNOVAL (-1). > > Sounds about right to me. > > Index: tmpfs_vnops.c >

Re: Root can panic kernel with mknod on a tmpfs filesystem

On Wed, Jul 06, 2016 at 07:18:14AM -0600, Bob Beck wrote: > ok beck@ > > On Wednesday, 6 July 2016, Todd C. Miller wrote: > > > On Wed, 06 Jul 2016 06:53:06 -0600, "Todd C. Miller" wrote: > > > > > Is there any reason to not do the check higher up in domknodat()? > >

Re: Root can panic kernel with mknod on a tmpfs filesystem

E.g., this should be equivalent. Index: tmpfs_vnops.c === RCS file: /build/data/openbsd/cvs/src/sys/tmpfs/tmpfs_vnops.c,v retrieving revision 1.27 diff -u -p -r1.27 tmpfs_vnops.c --- tmpfs_vnops.c 19 Jun 2016 11:54:33 -

make bugfix (?) / improvement

Initial problem reported by naddy@, amounts to this: -- A = truc.c EXT=.o a: echo ${A:${EXT}=.o} -- our make: echo truc.c gmake (and other BSDs): echo truc.o The substitution used is called SYSV substitution, it takes the form ${VAR:before=after} and

new style signing coming soon

I've been working on a new way to sign archives, in preparation to a change to pkg tools, with feedback from Theo and Tedu. The actual problem happened in FreeBSD. They got a hole in their gunzip pipeline a few weeks ago (rather subtle one). So if your workflow is: 1/ fetch data -> 2/ uncompress

Re: Drop main() prototype

On Mon, Sep 05, 2016 at 04:04:23AM -0400, Ted Unangst wrote: > Sevan Janiyan wrote: > > Hello, > > Attached patches remove the main() prototype from > > src/{sbin,usr.bin,usb.sbin} > > yes! I'm 100% certain I added those prototypes because some version of gcc with the appropriate warning flags

Re: mount(8): strlen + malloc + snprintf == asprintf

Are you retarded ? Go study the source code.

byebye SIGNING_PARAMETERS

seemed unclear. There's no longer any benefit to pkg_create signing packages, since signing packages is going to be signify -zS -s /etc/signify/whateverr-pkg.sec -m pkg.tgz -x signed/pkg.tgz (e.g., you have to produce the full archive first THEN you can sign it) I'll have a version of pkg_sign

ports; why I removed SIGNING_PARAMETERS

It used to make some kind of sense when pkg_create could indeed create the signed package in one pass. Now, the new signing mode means you have to build the package and copy it anyway. Heck, the code is not even inside pkg_sign proper, pkg_sign is going to become a shell that just keeps the

Re: make !!= extension

On Thu, Oct 20, 2016 at 09:55:33AM -0600, Todd C. Miller wrote: > On Thu, 20 Oct 2016 15:22:44 +0200, Marc Espie wrote: > > Comments inline. > I find "Expand the value" to be confusing. Would the following > also be accurate? > > Perform variable expansion a

Re: make obj in config

On Sun, Oct 16, 2016 at 11:52:45AM +0200, Martin Natano wrote: > We don't need to re-run 'make obj' when obj exists. Ok? > > natano > > > Index: main.c > === > RCS file: /cvs/src/usr.sbin/config/main.c,v > retrieving revision 1.55

make !!= extension

This is a new extension to make. I don't think it will hinder portability all that much, since != is already an expansion. VAR != cmd executes cmd on the spot, and replaces the output into VAR. This is a convenient feature, but it is rather expensive, since each such VAR will require the

Re: make(1): missing "fattr" pledge

On Wed, Oct 12, 2016 at 01:03:10AM +0200, Theo Buehler wrote: > $ .include \ > Makefile > $ ktrace make -t obj > touch _SUBDIRUSE > Abort trap (core dumped) > $ kdump | tail -4 > 89292 make CALL utimes(0x199a52c6c90,0) > 89292 make PLDG utimes, "fattr", errno 1 Operation

Re: signify(1): make comments optional

The comments are a necessary feature these days, actually. It is slightly warped: it says "untrusted comment" because it's outside of the signed area and shouldn't be taken at face value, BUT if you have the right public key, AND manage to validate the signature with it, then it means that it

Re: ports build failure, max_align_t

On Sun, Jan 08, 2017 at 09:53:50PM +, Stuart Henderson wrote: > graphics/ttfautohint > > c++ -std=gnu++11 -DHAVE_CONFIG_H -I. -I.. -I../lib -I../gnulib/src > -I../gnulib/src -I/usr/X11R6/include/freetype2 -O2 -pipe -MT info.o -MD > -MP -MF .deps/info.Tpo -c -o info.o info.cpp > In

Re: find -delete

On Tue, Jan 03, 2017 at 11:15:39PM +0100, Mark Kettenis wrote: > > From: "Ted Unangst" > > Date: Tue, 03 Jan 2017 16:39:48 -0500 > > > > I copied this straight from freebsd. Not fixed, but feel free to correct as > > desired. > > > > This adds a third example showing

Re: regarding OpenSSL License change

On Sun, Mar 26, 2017 at 08:49:39PM -0500, Jimmy Hess wrote: > > > From: "Constantine A. Murenin" > > > If we do not hear from you, we will assume that you have no objection. > > Is this for real?! > > Who do they think they are? ... > >People should not bother to respond to such nonsense, and

Re: sync root.mail

On Wed, Mar 29, 2017 at 09:40:32PM +0200, Christian Weisgerber wrote: > Antoine Jacoutot: > > > Why not just: > > > > # pkg_add -v rsync chromium emacs--no_x11 > > > > So we don't have to change it each release? > > Because people won't let Emacs 21 die. > > Ambiguous: choose package for

Re: regarding OpenSSL License change

On Thu, Mar 23, 2017 at 10:18:26AM -0600, Theo de Raadt wrote: > Lots of people have been receiving emails like the one below. [...] > Date: Wed, 22 Mar 2017 16:48:10 -0400 > From: lice...@openssl.org > To: dera...@cvs.openbsd.org > Subject: OpenSSL License change > Message-ID:

Re: snprintf(3) example warns under -Wextra

On Sun, Apr 23, 2017 at 05:12:16PM +0200, Timo Buhrmester wrote: > Except if the world changes... In a way that's still POSIX-compliant. > But why would anyone want to protect themselves from that, right? You're full of it. You're advocating for an unnecessary cast that can actually hide real

Re: snprintf(3) example warns under -Wextra

On Sun, Apr 23, 2017 at 10:16:38PM +0200, Timo Buhrmester wrote: > > The main difference between you and Theo is that Theo knows what he's > > talking about. > If you want to contribute anything, point out how casting a non-negative > into to size_t for comparison against another size_t could

Re: special sequences %a, %c, %m, %v in PKG_PATH [Was: Re: Fix broken example link in packages.7]

On Sat, Mar 11, 2017 at 08:42:37AM +, Raf Czlonka wrote: > Hi all, > > Ping. > > How about something like this? > > Recreated verbatim from pkg.conf.5: > > Index: usr.sbin/pkg_add/pkg_add.1 > === > RCS file:

Re: sync root.mail

On Thu, Mar 30, 2017 at 09:00:41PM +0200, Jeremie Courreges-Anglas wrote: > Marc Espie <es...@nerim.net> writes: > > > On Wed, Mar 29, 2017 at 09:40:32PM +0200, Christian Weisgerber wrote: > >> Antoine Jacoutot: > >> > >> > Why not just: > >

Re: Changing default compiler for usr/ports buiding

On Mon, Jul 31, 2017 at 05:47:59PM +0300, Denis wrote: > I'm trying to change default compiler to build some ports. > Tried to do it using bsd.port.mk and by system variables CXX=eg++ > CPP=egcc, but nothing changes while building a port. > > How can I force the default gcc 4.2 to egcc (gcc 4.9)?

patch: make share/mk support for yacc files better behaved

This is a collaboration of sort with FreeBSD. To me very specific, working on fixing depends made me look at fixing yacc support, and at the same time, I looked at FreeBSD, and they did this already (with different code, our share/mk are wildly divergent), so this comforted me this was doable and

HEADS-UP: infrastructure change for 5 ports

I've just committed TWO synchronous patches to base and ports to make yacc -> C/header file generation nicer. 5 ports are affected. Before new snapshots happen, you just need to have the most recent bsd.dep.mk and bsd.sys.mk under /usr/share/mk e.g., something like: cd /usr/src/share/mk cvs

Re: patch: make share/mk support for yacc files better behaved

On Sun, Jul 09, 2017 at 07:30:30AM -0600, Todd C. Miller wrote: > On Sun, 09 Jul 2017 10:40:43 +0200, Marc Espie wrote: > > > After a full bulk, no parts of xenocara are affected and just five ports. > > Those are all ports that include bsd.*.mk in their Makefiles, right? &

Re: Standard conformance of strtol(3)

On Thu, Jul 06, 2017 at 06:06:09PM +0200, Joerg Sonnenberger wrote: > On Thu, Jul 06, 2017 at 03:42:19PM +0200, Marc Espie wrote: > > 7.20.1.4 (3) If the value of base is zero, the expected form of the subject > > sequence is that of an integer constant *as described in 6.4.4.1*,

Re: grdc: fprintf(stderr -> warnx

On Sat, Jul 08, 2017 at 01:56:09PM -0500, Scott Cheloha wrote: > > On Jul 8, 2017, at 1:13 PM, Theo Buehler wrote: > > > > On Sat, Jul 08, 2017 at 10:27:43AM -0500, Scott Cheloha wrote: > >> Just use warnx. > > > > I don't have a real opinion on this one, but note that this

Re: patch: make share/mk support for yacc files better behaved

On Fri, Jul 07, 2017 at 09:23:30PM +0200, Marc Espie wrote: > This is a collaboration of sort with FreeBSD. > > To me very specific, working on fixing depends made me look at fixing yacc > support, and at the same time, I looked at FreeBSD, and they did this > already (with diff

Re: warning when building make(1)

On Mon, Jul 10, 2017 at 05:14:18PM +0800, Michael W. Bombardieri wrote: > Hi, > > The function build_target_group() produces two warnings when make is > built with CDIAGFLAGS. > > parse.c:1462: warning: ISO C90 forbids mixed declarations and code > parse.c:1462: warning: 'gn2' may be used

Re: getdelim(3): perror -> err in example

Another two cents: err exists on linux as well, so there is zero practical reason not to use it.

Re: broken base build at src/usr/lib/libpcap?

On Sun, Jul 23, 2017 at 05:40:24PM -0400, Rob Pierce wrote: > yacc -ppcap_yy -d grammar.y > cc -O2 -pipe -g -I. -I/usr/src/lib/libpcap -Dyylval=pcap_yylval > -DHAVE_SYS_IOCCOM_H -DHAVE_SYS_SOCKIO_H -DHAVE_ETHER_HOSTTON -DHAVE_STRERROR > -DHAVE_SOCKADDR_SA_LEN -DLBL_ALIGN -DHAVE_IFADDRS_H

Re: make: clarify an error string

On Mon, Jul 24, 2017 at 03:15:32PM +0800, Michael W. Bombardieri wrote: > Hi, > > In make(1), do_run_command() has a sanity check for a null command string. > The error message passes the null string to printf(). Is this any better? > > - Michael > > > Index: engine.c >

Re: make: clarify an error string

On Mon, Jul 24, 2017 at 10:43:03AM +0200, Marc Espie wrote: > On Mon, Jul 24, 2017 at 03:15:32PM +0800, Michael W. Bombardieri wrote: > > Hi, > > > > In make(1), do_run_command() has a sanity check for a null command string. > > The error message passes the null stri

Re: no-depends for real, the juicy part

ght be one or two more lurking... somewhat random build order with make -j4 doesn't help. On Wed, Jun 28, 2017 at 04:59:37PM +0200, Marc Espie wrote: > This is the actual patch that more or less neuters depends. > > So this gets rid of all internals for depend/beforedepend/afterdepen

Re: no-depends for real, the juicy part

On Wed, Jun 28, 2017 at 04:59:37PM +0200, Marc Espie wrote: > This is the actual patch that more or less neuters depends. > > So this gets rid of all internals for depend/beforedepend/afterdepend. > > NOTE that this does not *remove* the 'make depend' stage, just it won't do &g

Re: no-depends for real, the juicy part

Almost certainly the last version. A less used architecture met with a snag, because libsa/Makefile.inc uses depend:: which got make to barf out as target: and target:: don't mesh. Apart from that, I've got tb@'s okay, and krw@ seemed happy as well... further comments should happen about

HEADS-UP: no-depends is in

This follows on the footsteps of guenther@, who did a similar job in the kernel. Basically, the old-style "make depend, then make all" bsd makefile pattern is GONE. More accurately, dependencies are now generated on the fly using gcc and clang's -M* options. Instead of a "magical" .depend file,

patch: make lex rules parallel-safe

This is a very slight deviation from posix rules, but not in spirit. My interpretation is that posix rules describe the intent of the make rules (produce a file in such a way), but don't really care about intermediate names. FreeBSD already has something like this in tree (though they use lex

Re: Standard conformance of strtol(3)

On Wed, Jul 05, 2017 at 07:12:28PM -0400, Ted Unangst wrote: > Olivier Antoine wrote: > > Hi all, > > > > Recently a bug has been identified in Tor: > > > > https://trac.torproject.org/projects/tor/ticket/22789 > > > > As comments were made, questions were raised about the use of strtol(3), > >

Re: clang integrated asm crash while building mozilla/firefox

On Tue, Jun 27, 2017 at 11:32:44AM +0200, Marc Espie wrote: > I've attached the files that clang gives to reproduce the crash. > > I also got a similar crash in firefox-esr. > > Funnily enough, it happened after the recent update to both, BUT the crashes > seem to be unrelat

Re: patch: make lex rules parallel-safe

On Wed, Jul 05, 2017 at 06:49:30AM -0600, Todd C. Miller wrote: > I wonder if it would be better to use lex.${.PREFIX}.c instead of > ${.PREFIX}.lex.c. This would be more consistent with how lex's > -Pprefix flag behaves. > > It's not a big deal either way as the file is strictly temporary. > >

no-depends for real, the juicy part

This is the actual patch that more or less neuters depends. So this gets rid of all internals for depend/beforedepend/afterdepend. NOTE that this does not *remove* the 'make depend' stage, just it won't do anything except for a few select parts (old gcc3 and mesa in particular depend on it).

Re: patch: make lex rules parallel-safe

On Wed, Jul 05, 2017 at 01:25:59PM -0700, Philip Guenther wrote: > On Wed, 5 Jul 2017, Marc Espie wrote: > > This is a very slight deviation from posix rules, but not in spirit. My > > interpretation is that posix rules describe the intent of the make rules > > (produce

patch: choose right compiler in ports

This is a work-in-progres, now is the time to shoot holes thru it. Basically, clang in base comes with libc++, which tends to not be compatible with stuff compiled with gcc4 or clang from ports. So I tried designing an interface to choose the most appropriate compiler for most cases. The only

Re: avoid clang warnings and signed underflow in adventure(6)

On Tue, May 16, 2017 at 11:18:01AM +0200, Theo Buehler wrote: > Part of adventure's interesting internal obfuscation scheme makes clang > very unhappy. It spews 240+ warnings of this kind: > > /usr/src/games/adventure/wizard.c:71:17: warning: implicit conversion from > 'int' to 'char' changes

Re: Emulated TLS for clang

On Sun, May 07, 2017 at 05:37:47PM +0200, Mark Kettenis wrote: > So this enables the code. It makes -femulated-tls the default, > otherwise it will generated TLS relocations that we can't handle yet. > It is possible to specify -fno-emulated-tls if you really want to > generate those. > > A

Re: Finish the link-kit job

On Wed, Jun 21, 2017 at 01:13:31PM -0600, Theo de Raadt wrote: > (config(8) was modified because reaching this point on multiple > architectures was EXCEEEDINGLY PAINFUL. I am desperately trying to > avoid Makefile.* divergence) I don't know if modifying config to write more boilerplate is such

Re: ports framework change: readme and rc generation

On Mon, Jun 26, 2017 at 01:46:05PM +0200, Landry Breuil wrote: > On Mon, Jun 26, 2017 at 12:36:16PM +0200, Marc Espie wrote: > > I need to get this thru my next bulk. > > This should work around several existing issues. > > > > First, PKGDIR must exist. Creating

no depends for perl

Probably the most intricate yet. This is not entirely new, since I had to split manpages already a long time ago. The trick is to keep the "Configure stuff" in the main Makefile.bsd-wrapper, and put everything else in Makefile.bsd-wrapper1... I hope I haven't forgotten any small piece, but it

ports framework change: readme and rc generation

I need to get this thru my next bulk. This should work around several existing issues. First, PKGDIR must exist. Creating it during fake is no longer possible, because this doesn't work with dpb in privsep mode. Having PKGDIR not be a directory/pointing in the wrong location means you might

Re: git patches

On Fri, May 26, 2017 at 02:26:46PM +0300, Paul Irofti wrote: > On Fri, May 26, 2017 at 06:55:34AM -0400, Ted Unangst wrote: > > let's say, hypothetically, you're working with a blasphemer who mails you a > > git diff which looks a little like this: > > > > diff --git a/d2/bar.c b/d2/bar.c > >

backport from clang trunk

I managed to get this one in. the rationale being that -Wno-#warnings, while highly descriptive, is a total bitch to pass through shell-scripts, configure, makefiles... and gcc names the same option -Wno-cpp anyway. okay ? Index: DiagnosticGroups.td

patch(1) is fucked up

There is zero option that says "assume all those patches are correct and error out if something untowards happen". This is really annoying for ports. - prompting for non-existent filenames breaks automated builds... dpb avoids that by explicitly zapping stdin. - the new one. In the absence of

discrepancy between clang and gcc for mkdep

Consider the following: a.c: - #define TEST defined(X) #if TEST #include #endif even though it's not standard C, it does compile. It becomes interesting with the -M option. $ gcc -M a.c a.o: a.c $ clang -M a.c a.c:3:5: warning: macro expansion producing 'defined'

Re: m4(1): add -e flag support

on wed, jun 14, 2017 at 09:58:54am -0400, brian callahan wrote: > hi marc -- > > how's this version? > also includes a slight tweak to the single -e flag regress test. > > ~brian comment nit, otherwise good. > +extern int error_warns; /* make warnings cause exit_code > 0 */

Re: m4(1): add -E flag support

On Tue, Jun 13, 2017 at 05:05:56PM -0400, Brian Callahan wrote: > Hi -- > > Whoops, that was unintentional. Fixed. > > ~Brian Sorry for not looking sooner. I would rather you use two variables for -E flags. e.g., set error_warns for one -E flag, and fatal_warns for multiple -E flags. That

patch: tighten make parser and fix bug in makefile

While reading thru gnu/usr.bin/cc, I couldn't figure out where DEPENDFILE comes from. Turns out it comes from FreeBSD, which currently defines it in bsd.own.mk. The variable is empty on OpenBSD, thus yielding an always-false condition, which was definitely not the intent. This does put the

clang integrated asm crash while building mozilla/firefox

I've attached the files that clang gives to reproduce the crash. I also got a similar crash in firefox-esr. Funnily enough, it happened after the recent update to both, BUT the crashes seem to be unrelated ? The sysv crash is consistent, I got it during both builds. # 1 "" # 1

HEADS-UP: package @version

The switch to clang for some arches was a bit annoying, because suddenly you had to force an update of every package (practically, bumping every package was next to impossible). The HEADS-UP is that actually there should be *no* heads-up for 6.2. Thanks to sthen@'s prodding, I've just committed a

Re: Installer support to fetch/verify bsd.rd for release upgrade

On Sun, Oct 08, 2017 at 05:27:09PM +0200, Sebastian Benoit wrote: > Robert Peichaer(rob...@peichaer.org) on 2017.10.08 09:56:15 +: > > Up to now, the upgrade procedure from one to the next release meant > > that you had to manually download and verify the new ramdisk kernel. > > > > What

Re: Remove .depend leftovers from Makefiles

On Tue, Oct 17, 2017 at 01:51:25PM +0200, Christian Weisgerber wrote: > As far as I can tell, nothing in the build system generates .depend > files any longer, nor do they appear as prerequisites in any make > rules. The patch below removes all remaining mentions of .depend > (lists of files to

Re: make includes: use find -exec {} +

On Thu, Oct 05, 2017 at 10:08:32PM +0200, Christian Weisgerber wrote: > Admittedly, this is cosmetic: > Use the modern POSIX idiom "-exec ... {} +" instead of find|xargs. > ok? > > Index: include/Makefile > === > RCS file:

Re: maxproc limits

On Fri, Oct 06, 2017 at 04:06:15PM +0100, Stuart Henderson wrote: > I have been bumping into maxproc limits a lot recently on my > workstation. While I do have quite a lot of processes at times, I don't > think I have quite been tripping into the limits of number of actual > processes. > > It

Re: Remove commented out pledge in tsort

On Sun, Nov 12, 2017 at 11:08:54AM +, George Brown wrote: > Removes commented out pledge with whitelist, this is the only instance I > found of this grep'ing through base. > > diff --git usr.bin/tsort/tsort.c usr.bin/tsort/tsort.c > index 5caa733f4..cc1cba164 100644 > ---

Re: Remove commented out pledge in tsort

On Mon, Nov 13, 2017 at 10:38:17PM -0800, Ori Bernstein wrote: > On Sun, 12 Nov 2017 13:31:10 +0100, Marc Espie <es...@nerim.net> wrote: > > > I did this in an eager way a while back, was told in no uncertain terms > > "not yet, we're still looking at things&

Re: TLS with static non-PIE binaries

The only "tls" support we have that's currently working is emulated tls, as exemplified by both clang and the gcc 4.9 port. See /usr/src/lib/libcompiler_rt/emutls.c for how it works. It's not incredibly fast, but it does the job... Fortunately, the gcc and clang people managed to make some

Re: vi: remove awk scripts

> @@ -37,6 +37,16 @@ SRCS= cl_funcs.c cl_main.c cl_read.c cl_ > > LINKS= ${BINDIR}/vi ${BINDIR}/ex > LINKS+= ${BINDIR}/vi ${BINDIR}/view > + > +options_def.h: common/options.awk common/options.c > + awk -f ${.CURDIR}/../common/options.awk ${.CURDIR}/../common/options.c \ >

Re: Include hostname in shell prompts by default

On Sat, Dec 09, 2017 at 06:33:32PM +, Jason McIntyre wrote: > On Sat, Dec 09, 2017 at 11:10:03AM -0700, Theo de Raadt wrote: > > > the default prompt works exactly because it doesn;t try to second guess > > > what the user wants, or what is or isn;t good for them. the mechanism > > > for

a fun story about update-plist tweaks

One of my usual mantra is "untested software doesn't work". Applies to everything including my own code. Case study: new update-plist has interesting heuristics to figure out where to put variables in lists. Specifically, for each entry, it keeps track of the original line from the old plist

Re: Timeouting the pkg_add

On Thu, Jun 14, 2018 at 01:40:28PM -0400, sven falempin wrote: > Dear Tech Readers, > > In ftp command -w is available, very useful for crappy networks. > pkg_add does not have any of this. > > The HTTP layer is not configuring Timeout. > ( in

tag semantics: deletion of supporting package

So, I'm oscillatting a bit. Basically, you've got a package A that defines a tag, e.g., in the PLIST: @define-tag f at-end %D/bin/f f normally, this gets %D/bin/f to run at the end of the installation. What happens if you delete A ? The current idea was to have @tag f also in A, before

Re: malloc.c: correlation between random choices

On Wed, Jan 17, 2018 at 08:52:36AM -0700, Theo de Raadt wrote: > So the attacker has numerous small hurdles. There's a banana on the > road, but there's snare wire above it. Okay, now, I can't stop thinking of a Will.E. Coyote-shaped Theo unboxing his ACME ordered snare wire at xmas...

Re: bsd.port.mk.5: Remove mention of OLD_WRKDIR_NAME

On Sun, Jan 21, 2018 at 08:44:24PM +0100, Klemens Nanni wrote: > espie@ removed OLD_* stuff from bsd.port.mk with revision 1.1337, this > diff takes care of left overs in the manpage. > > Any takers? > > diff --git a/share/man/man5/bsd.port.mk.5 b/share/man/man5/bsd.port.mk.5 > index

pkg_add vs https

So we've been working with the tls crowd to bring you decent https support. The crux of the matter is that pkg_add does not handle https directly, it does use ftp(1) to fetch every single file. ... which means a new connection for each single package it looks at. with http, that's fairly okay.

Re: mktemp: Clarify error message

On Tue, Dec 26, 2017 at 08:25:50AM +0100, Otto Moerbeek wrote: > > This reminds me of the old IRIX compiler, that would cite complete > parapgraphs of the C standard in error mesasges. Of course logically > it was all correct, but it lead to long and unreadable error messages > that filled up

Re: openbsd code coverage

On Tue, Jan 02, 2018 at 12:40:33AM +0100, Aron Diehl wrote: > Hi, > > > I'm working on measuring OpenBSD code coverage. > > > Code coverage of what? The regression-tests make target? > > Cheers > Aron Obviously.

Re: ports.7: double distfile fetch size: 20 -> 40

On Tue, Dec 26, 2017 at 05:51:51PM +0100, Jeremie Courreges-Anglas wrote: > On Tue, Dec 26 2017, Scott Cheloha wrote: > > Hey, > > > > I just did a full ports fetch and I pulled down at least 40GB: > > > > $ du -h /usr/ports/distfiles | tail -n 1 > > 40.5G

Re: bsd.port.mk: make clean=build && make : failed

On Wed, Aug 01, 2018 at 11:03:39AM +0200, Sebastien Marie wrote: > Hi, > > After issuing a "make clean=build" on a port, I am unable to build > again. > > "make" failed in 'configure' stage: > > $ make > ... > /bin/sh: cannot create >

Re: bsd.port.mk: make clean=build && make : failed

On Wed, Aug 01, 2018 at 11:03:39AM +0200, Sebastien Marie wrote: > Hi, > > After issuing a "make clean=build" on a port, I am unable to build > again. > > "make" failed in 'configure' stage: > > $ make > ... > /bin/sh: cannot create >

Re: libtool: handle fork() error

On Sun, Aug 26, 2018 at 04:13:11PM +0200, Christian Weisgerber wrote: > I noticed this curious error in a package bulk build: > Use of uninitialized value $pid in numeric eq (==) at > /usr/libdata/perl5/LT/Exec.pm line 96. > > Perl's fork() wrapper returns undef rather than -1 on error. > Handle

Re: [patch] make(1) remove unused tutorial

Nope. Still some useful stuff in there.

Re: bsd.port.mk.5: Remove mention of old man directory

On Sat, Jul 14, 2018 at 10:04:55AM +0200, Klemens Nanni wrote: > OK? > > Index: man5/bsd.port.mk.5 > === > RCS file: /cvs/src/share/man/man5/bsd.port.mk.5,v > retrieving revision 1.486 > diff -u -p -r1.486 bsd.port.mk.5 > ---

Re: [update] base zlib

On Sat, Jul 14, 2018 at 06:15:59PM +0100, David CARLIER wrote: > Hi, > > Just to anticipate things, the age of the version starts to show with > some third party softwares, so I was thinking if we could update to > the latest while keeping just the necessary code and backporting our > internal

Re: on -current: "doas pkg_add evince" leads to "can't resolve libspectre-0.2.8p2".

On Tue, Apr 24, 2018 at 05:01:40PM +0200, Felix Maschek wrote: > Thank you for your help. > > No resolution so far: > > > > e130$ doas pkg_check > doas (fe...@e130.fritz.box) password: > Packing-list sanity: ok > Direct dependencies: ok > --- ghostscript-9.07p7 --- >

<    1   2   3   4   5   6   7   >