-q is just plain broken in compat mode, it's easy to fix though.
The second issue is that, if a Makefile as an .END target, that one
will always be run, even in query mode, contrary to .BEGIN.
So let's fix that as well.
Fairly obvious patch
Index: compat.c
==
So my development branch is getting a bit too far
ahead compared to what's committed.
Here's a big diff to test. Comments as to what's going on
and the changes this contains:
- buffer changes: add support for "permanent static buffers"
that don't get reinit'd all the time (that's a mostly trivia
On Thu, Jan 09, 2020 at 01:09:59PM +0100, Marc Espie wrote:
> So my development branch is getting a bit too far
> ahead compared to what's committed.
>
> Here's a big diff to test. Comments as to what's going on
> and the changes this contains:
>
> - buffer
On Fri, Jan 10, 2020 at 10:52:03PM +0100, Alexander Bluhm wrote:
> On Fri, Jan 10, 2020 at 01:58:47PM +0100, Marc Espie wrote:
> > Bleh, I forgot to synch two patches I already committed. Here's a patch
> > that applies cleanly.
>
> I did run this make through a full re
The convoluted logic that resets must_make does not make any sense to me.
It's just as simple to set built_status to ABORTED directly.
Note that in the compat make case, there are two instances of using
must_make left, one in arch.c, which I have yet to understand, and one
in node_failure/list_par
More specifically, I'm running with this patch
The specific choice of keywords to deprecate is up for grabs, the
infrastructure for actually being able to error out on these keywords is
probably something I should commit anyhow.
diff --git a/gnode.h b/gnode.h
index 283fead..04e5462 100644
---
So I did a full bulk build with the following diff.
No failure due to old keyword.
This contains exactly:
- abort directly instead of setting pgn->must_make = false
- tag as "SPECIAL_DEPRECATED" all old keywords
- remove the conditionals with those OP. We just keep OP_INVISIBLE because
it's actua
So, basically, if we start arbitrary commands, then
the classic loop
/* Wait for the child to exit. */
while (waitpid(cpid, &status, 0) == -1 && errno == EINTR)
continue;
is not quite enough.
See the small note in manpages (not only us, but everyone):
WIFSTOPPED(status
On Thu, Jan 30, 2020 at 11:14:37AM +, Stuart Henderson wrote:
> Putting this here for discussion... good idea? bad idea? does it need
> more checks for expected file contents?
>
> Index: sysupgrade.sh
> ===
> RCS file: /cvs/src/us
On Sat, Feb 01, 2020 at 04:57:26PM +0100, Ingo Schwarze wrote:
> Hi Jeremie,
>
> Jeremie Courreges-Anglas wrote on Sat, Feb 01, 2020 at 01:37:32PM +0100:
> > On Fri, Jan 31 2020, Ingo Schwarze wrote:
> >> ngc...@gmail.com wrote on Fri, Jan 31, 2020 at 10:14:52PM +0900:
>
> >>> Reduce scope of a
On Sun, Feb 09, 2020 at 12:41:43AM +0100, Sebastian Benoit wrote:
> Ingo Schwarze(schwa...@usta.de) on 2020.02.09 00:33:06 +0100:
> > Hi,
> >
> > Jason McIntyre wrote on Sat, Feb 08, 2020 at 10:15:08PM +:
> >
> > > - i'm ok with adding the path to these files to a FILES section
> >
> > So, h
On Sun, Feb 09, 2020 at 01:37:33PM +, Jason McIntyre wrote:
> On Sun, Feb 09, 2020 at 02:27:23PM +0100, Marc Espie wrote:
> > On Sun, Feb 09, 2020 at 12:41:43AM +0100, Sebastian Benoit wrote:
> > > Ingo Schwarze(schwa...@usta.de) on 2020.02.09 00:33:06 +0100:
> > > &
On Tue, Jun 09, 2009 at 07:12:24PM +0200, Joerg Sonnenberger wrote:
> On Tue, Jun 09, 2009 at 10:37:29AM -0600, Theo de Raadt wrote:
> > The fact that you had to modify standards compliant code already in
> > the tree to make it work indicates a rather major problem.
>
> The changes for stdout / s
On Sun, Oct 11, 2009 at 04:56:00PM +0200, Robert Nagy wrote:
> Hello
>
> p2k9 (the ports hackathon in Budapest) is on since Friday. People
> are working on different things like GNOME, GCC4, BluRay support or
> even ACPI.
>
> I would like to thank everyone who donated money to the project because
Some update. Day job and stress taking their tolls. Finally getting into
a hacking mood.
I'm integrating old diffs into pkg_add, mostly to allow multiple updates
without cheating (no user visible parts, but lots of internal changes).
User-visible changes for today:
- pkg_add -u progressmeter: one
On Wed, Oct 14, 2009 at 05:33:28PM +0100, Stuart Henderson wrote:
> On 2009/10/14 08:38, Matthew Dempsky wrote:
> >
> > Doesn't this leak memory in the -P case? What about moving the
> > xstrdup() call into only the !prefix_builtins path? Then you can also
> > eliminate the const cast:
>
> Yes,
On Fri, Oct 16, 2009 at 10:37:11PM -0400, STeve Andre' wrote:
> You can see whats been happening if you are subscribed to the cvs src
> changes list. Offhand at least 30 new ports were added, more than 250
> were updated, lots were tweaked, and the pkg_add code was worked on.
Most of the tweaks d
There have been some big changes in pkg_add again.
Finally, there is now a 'quirks" package that will be used to handle weird
update scenarios. It amounts to a Quirks.pm module that can build a quirks
object that conforms to pkg_add's interface. This can change independently:
pkg_add builds the qu
On Sat, Dec 05, 2009 at 10:47:25PM +0300, Igor Zinovik wrote:
> if (-e "/var/db/pkg/ftpmirror.cache") {
> open my $fh, '<', "/var/db/pkg/ftpmirror.cache" or
> die("Permission denied");
> @mirrors = <$fh>;
> close $fh;
> print $mirrors[0];
> exit;
> }
...
On Sat, Dec 26, 2009 at 03:48:58PM -0500, David Shuman wrote:
> Security is one of the stated objectives of OpenBSD yet the current
> build process appears to be difficult to secure largely because the
> build directories are numerous and mixed in with directories for
> general machine operation. (
If you people ever need to profile some large perl code, I think I can
recommend Devel::NYTProf, it works much faster and gives much more in-depth
results than Devel::Prof.
Granted, big runs of pkg_add are not exactly average, but still,
Devel::Prof was generating 2G traces, and dprofpp was taki
On Fri, Feb 05, 2010 at 12:14:51PM +0200, Atte Peltomdki wrote:
> On Fri, Feb 05, 2010 at 02:49:16AM +0100, Ingo Schwarze wrote:
> > Atte Peltomdki wrote on Thu, Feb 04, 2010 at 12:48:47PM +0200:
> > > On Tue, Feb 02, 2010 at 09:32:43PM +0100, Ingo Schwarze wrote:
> > >> Antti Harri wrote on Tue, F
On Sun, Feb 07, 2010 at 01:59:33PM -0500, Brad Tilley wrote:
> I wrote a small cpp application to generate randomish passwords. It compiles
> and runs OK on OpenBSD, however, it does not seem to create random strings
> (the first and last chars seldom ever change, etc). The same code compiles
>
On Mon, Feb 08, 2010 at 08:10:11AM -0500, Brad Tilley wrote:
> I placed the GUI version there are source.cpp. I don't have the simpler,
> non-GUI version that I posted yesterday, but the use of srand and rand are
> the same in both examples. The GUI version compiles on OpenBSD if you have
> fltk
On Wed, Mar 03, 2010 at 04:46:18PM -0800, J.C. Roberts wrote:
> Boolean variables should be set to Yes instead of simply being
> defined, for uniformity and future compatibility.
This takes time to finish changing.
> 1.) The majority of the scripts in ports/infrastructure do not
> both
On Thu, Mar 04, 2010 at 06:14:52AM -0800, J.C. Roberts wrote:
> On Thu, 4 Mar 2010 09:38:12 +0100 Marc Espie wrote:
>
> > On Wed, Mar 03, 2010 at 04:46:18PM -0800, J.C. Roberts wrote:
> > > Boolean variables should be set to Yes instead of simply
> > > being defi
I've been using this a few times, and it's really useful for tweaking
big makefiles in ports, or very compact for other stuff.
It's like this, both our make(1) and gmake(1) support recursive variables,
so that:
A = B
C_B = yes
a:
@echo ${C_$A}}
will display "yes"
this can be used to "sp
On Mon, Mar 29, 2010 at 06:45:42PM +0200, Simon Bertrang wrote:
> On Fri, Mar 26, 2010 at 12:09:48PM +0100, Marc Espie wrote:
> > I've been using this a few times, and it's really useful for tweaking
> > big makefiles in ports, or very compact for other stuff.
> >
I think I finally figured out how to work with git for small subtrees,
and not get annoyed with the $OpenBSD$ keyword expansion...
- define a filter in your git attributes, that's either
$GITDIR/info/attributes or ~/.gitattributes:
* filter=openbsd
- set up the filter to clean files, that'
On Sun, Apr 25, 2010 at 03:01:31PM +0200, Marc Espie wrote:
> I think I finally figured out how to work with git for small subtrees,
> and not get annoyed with the $OpenBSD$ keyword expansion...
>
>
> - define a filter in your git attributes, that's either
> $GI
On Sun, Apr 25, 2010 at 03:01:31PM +0200, Marc Espie wrote:
> - create a script in your PATH that cleans up things, in my case,
> ~/bin/openbsd-zap
>
> #! /usr/bin/perl -p
> # what ? you expected another scripting language
> s/\$OpenBSD\:.*?\$/\$OpenBSD\$/g;
> s/[ \t]+$//; #
Please install -current bsd.own.mk whenever you can.
cd /usr/src/share/mk && sudo make install
Otherwise, you'll be sorry when we nuke USE_GCC3 in favor of
COMPILER_VERSION...
due to various reasons, it's getting unlinked from src in -current,
and moves to ports.
The gcc 3.3.5 version is ready, gcc 2 will follow soon.
Several reasons:
- slightly smaller base (for a compiler that's not actually used by anything
in base).
- recent ports may prefer g95 (to be done as an
I've reorg'ed a bit of code in pkg_* land, mostly to have more consistent
output, to shrink code, and to allow for further changes.
I might have broken some details. If you see something odd being printed
out, just yell.
The most significant visible change is that I replaced the controversed
(xxx
Historically, I did leave LOCKDIR empty in bsd.port.mk.
Now, I'm wondering if I should define it to something such as
/tmp/portslocks ?
My assumption was that it would be difficult to be certain that dotlocks could
be created anywhere. But it seems that most machines have local /tmp/ these
days.
On Wed, Jun 16, 2010 at 01:45:30PM +0200, Antoine Jacoutot wrote:
> On Wed, 16 Jun 2010, Marc Espie wrote:
>
> > Historically, I did leave LOCKDIR empty in bsd.port.mk.
> > Now, I'm wondering if I should define it to something such as
> > /tmp/portslocks ?
> >
On Wed, Jun 16, 2010 at 12:51:20PM +0100, Stuart Henderson wrote:
> On 2010/06/16 13:45, Antoine Jacoutot wrote:
> > On Wed, 16 Jun 2010, Marc Espie wrote:
> >
> > > Historically, I did leave LOCKDIR empty in bsd.port.mk.
> > > Now, I'm wondering if I
On Wed, Jun 16, 2010 at 02:11:47PM +0200, Bret S. Lambert wrote:
> On Wed, Jun 16, 2010 at 02:02:37PM +0200, Antoine Jacoutot wrote:
> > On Wed, 16 Jun 2010, Marc Espie wrote:
> > > > 3 days is a bit short on some arch. /var/tmp gives you 7 days,
> > &g
I should have been more specific. This is not a vote as to where we
should put the default.
If you think of the constraints (usually not NFS, user-writable), there
are about two locations that make sense: /tmp or /var/tmp.
Also remember that it makes no sense for those locks to survive reboot.
So
On Tue, Jun 22, 2010 at 06:53:12PM +, Miod Vallat wrote:
> > >> Is there any reson you use bcopy() not memcpy()?
> > >> If not considder using memcpy() please. :)
> >
> > > We couldn't care what you believe, unless you have diffs of your own
> > > to submit.
> >
> > I think the guy there aske
Actually, I think there's nothing "natural" about bcopy or memcopy order.
Those are just API, they're mostly equivalent. Switching all the time
is annoying. I tend to like that memcpy works like strlcpy, miod prefers
bcopy. Who cares ? those are totally equivalent APIs (in the documentation)
Of c
Is anyone actually using pkg_info -l ?
It's an annoying flag that's not even implemented consistently,
and I would like to actually kill it.
On Fri, Jun 25, 2010 at 06:34:33PM -0400, Kenneth R Westerback wrote:
> On Fri, Jun 25, 2010 at 04:45:24PM +0200, Marc Espie wrote:
> > Is anyone actually using pkg_info -l ?
> >
> > It's an annoying flag that's not even implemented consistently,
> >
The following patch changes the semantics of LIB_DEPENDS/WANTLIB, hopefully
to make things simpler for ports maintenance.
Historically, all libs were registered in LIB_DEPENDS. In order to handle
updates, packages had to register all needed libraries.
The current mechanism is that a package conta
Faster patch... this removes a lot of old cruft, and yields a
_print-package-args that's about twice as fast, instead of potentially slower.
Specifically, always grab lib lists off the ports tree proper, evaluate them
once, and use the fact that resolve-lib has known how to handle multiple
spec
On Fri, Jul 02, 2010 at 04:33:43PM +0200, Marc Espie wrote:
> Faster patch... this removes a lot of old cruft, and yields a
> _print-package-args that's about twice as fast, instead of potentially
> slower.
Turns out it must be slightly more complicated.
Namely, we have to bri
Hopefully final patch... moving this up from make to sh means I must escape
a bit more stuff...
Index: bsd.port.mk
===
RCS file: /home/openbsd/cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1007
diff -u -p -r1.1007 bs
Current tests goes fine, and actually show some existing problems because
the "old" infrastructure is:
- too complicated
- bsd.port.mk lies about what's going on.
Namely, libspecs were apparently tied to the pkgspec in a LIB_DEPENDS.
But that's not true ! bsd.port.mk was only using those specs as
each time xenocara farts, we get new libs (or less libs).
in order for updates to work, we *should* propagate those changes to
@wantlib in each port.
This currently isn't done automatically... check-lib-depends is sloooww
(needs to check every file before packaging) and not even flawless.
I'm beg
On Thu, Jul 08, 2010 at 12:03:47PM +0100, Stuart Henderson wrote:
> On 2010/07/08 11:50, Marc Espie wrote:
> > each time xenocara farts, we get new libs (or less libs).
> > in order for updates to work, we *should* propagate those changes to
> > @wantlib in each port.
> >
On Thu, Jul 08, 2010 at 02:03:41PM +0200, Matthieu Herrb wrote:
> On Thu, Jul 08, 2010 at 11:50:39AM +0200, Marc Espie wrote:
> > each time xenocara farts, we get new libs (or less libs).
> > in order for updates to work, we *should* propagate those changes to
> > @wantlib i
On Thu, Jul 08, 2010 at 04:28:27PM +0100, Sam Smith wrote:
> The CVS revision number is guaranteed atomically increasing
> and only relevant if it's used as a tie breaker against two
> otherwise similar versions.
> there's probably an obvious reason why this is a bad idea.
Stable branches...
On Thu, Jul 08, 2010 at 11:52:44AM -0500, Todd T. Fries wrote:
> The one with the higher numbered libs of course! (Though with manual
> building of things and people who dont update base/xbase often, this
> might produce mixed lists of updated libs, a situation where I don't
> know how automation
On Thu, Jul 08, 2010 at 08:22:38PM +, Christian Weisgerber wrote:
> I think both sthen@ and I have mentioned before that we really like
> how FreeBSD has the revision in a separate PORTREVISION variable
> that is much easier and less error prone to increment than pX
> suffixes in PKGNAME.
>
>
I remember why I did not do it before... there is a technical.
The way we build FULLPKGNAMEs with the interaction with flavors makes this
rather awkward.
Anyways, my make-fu did improve markedly since last time I tried, so this
ought to do the trick.
If you get a headache while reading this, you'
Obvious stupidity fixed...
On Fri, Jul 09, 2010 at 11:35:05AM +0200, Marc Espie wrote:
> I remember why I did not do it before... there is a technical.
> The way we build FULLPKGNAMEs with the interaction with flavors makes this
> rather awkward.
>
> Anyways, my make-fu did i
I want to tweak the directory structure for ports.
I'd like to go for a lot of stuff to
ports/infrastructure/bin
ports/infrastructure/lib
ports/infrastructure/man
the current setup (build, fetch, install, package) is my mistake, and
frankly it sucks. Some of the scripts are callable outside of b
On Thu, Aug 19, 2010 at 11:09:14AM +0100, Stuart Henderson wrote:
> On 2010/08/19 11:55, Marc Espie wrote:
> > I want to tweak the directory structure for ports.
> > I'd like to go for a lot of stuff to
> >
> > ports/infrastructure/bin
> > ports/infrastru
On Thu, Aug 19, 2010 at 02:46:44PM +0200, Joachim Schipper wrote:
> On Thu, Aug 19, 2010 at 11:55:22AM +0200, Marc Espie wrote:
> > I want to tweak the directory structure for ports.
> > I'd like to go for a lot of stuff to
> >
> > ports/infrastructure/bin
> &
Okay, I've started moving a lot of things.
I've moved aggressively stuff that is "internal" to the ports tree (all
the scripts used by bsd.port.mk) and dpb3 (renamed to dpb, as I hope
to finally deprecate the other dpb).
I'm probably going to document this part, and then do a second pass
for the
On Sun, Feb 07, 2016 at 09:42:32AM -0600, joshua stein wrote:
> We don't recommend FTP mirrors anymore, installing a package via a
> pipe doesn't seem to work anymore, and packages have to be signed to
> be installed so the advice about miscreants is not very relevant.
>
>
installing packages thr
On Mon, Feb 08, 2016 at 03:05:00PM -0800, patrick keshishian wrote:
> On Mon, Feb 08, 2016 at 07:28:24PM +0100, Marc Espie wrote:
> > On Sun, Feb 07, 2016 at 09:42:32AM -0600, joshua stein wrote:
> > > We don't recommend FTP mirrors anymore, installing a package via a
>
Already shown to a few people, but since pledge(2) aborts on non-dev, let's
check upfront that we're of the right type.
I don't think this requires a bump. It doesn't really change the interface,
just makes it stricter.
Index: opendev.3
On Thu, Mar 10, 2016 at 08:48:21AM -0700, Theo de Raadt wrote:
> The reason for these checks is because they protect the kernel,
> and they identify a program that does the wrong thing. Here, a
> program did the wrong thing. I am 100% in agreement that opendev
> may not be the right place to do t
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 NULL-che
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 t
On Mon, Mar 14, 2016 at 01:38:48AM -0600, Anthony J. Bentley wrote:
> COLUMNS handling in our tree is inconsistent.
>
> POSIX specifies that if COLUMNS is a valid value (read: 1 or greater),
> it takes precedence; otherwise, width is handled in an unspecified
> manner.
>
> Most programs follow C
On Mon, Mar 14, 2016 at 10:19:53PM +0100, Theo Buehler wrote:
> On Thu, Mar 10, 2016 at 12:52:35PM +0100, Marc Espie wrote:
> > Already shown to a few people, but since pledge(2) aborts on non-dev, let's
> > check upfront that we're of the right type.
> >
> &g
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 ?
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 is
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!
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 packages
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 man/man1/
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 corner
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 straigh
On Tue, May 10, 2016 at 01:48:18PM +, Christian Weisgerber wrote:
> On 2016-05-09, Marc Espie wrote:
>
> > So far, I've been underwhelmed by the response to proot. Seems people don't
> > get the picture yet.
>
> Probably because there has been no coherent e
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
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
> > inde
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
=
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' ha
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 i
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 way
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 */
exit_cod
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 right
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
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 miss
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
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 s
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 "/pobj/firefox-54.
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 un
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).
(ao
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
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 w
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 now,
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,
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 >$@
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.
>
>
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
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),
> >
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*,
201 - 300 of 664 matches
Mail list logo
