This exists only so that individual ports may log. Tweaking it anywhere
is awkward (and will be more so with SEPARATE_BUILD).
I just checked that the current ports tree does not abuse this.
Okay ?
Index: bsd.port.mk.5
===
RCS file:
On Fri, Mar 30, 2018 at 01:57:43AM +0200, Ingo Schwarze wrote:
> I do *NOT* want to add SIGWINCH signal handling to man(1) to abort
> less(1), reformat, and respawn less(1) in that case. That kind of
> magic would be over the top, and SIGWINCH is an abomination in the
> first place.
Why on earth
On Sat, Oct 27, 2018 at 01:01:10PM +0200, Mark Kettenis wrote:
>
> Correct. More recent GNU linkers behave the same way as lld, which is
> why I think the change in behaviour is a good thing.
>
> It is possible to make ld.lld emit DT_RPATH by passing
> -Wl,-disable-new-dtags. And if you pass
On Mon, Nov 05, 2018 at 08:43:56AM -0500, Daniel Dickman wrote:
>
>
> > On Nov 5, 2018, at 8:30 AM, Marc Espie wrote:
> >
> > Or we could just finally remove brk and sbrk from the libc ?
> >
> >
>
> you won’t get very far. they are still neede
On Mon, Nov 05, 2018 at 09:15:28AM -0500, Daniel Dickman wrote:
>gcc uses them for precompiled headers (PCH) which is a local diff added
>by kurt@ in 2009. its likely nothing in base uses PCH but i don't know
>what in ports needs this:
This has always been a mess. I suspect it's not
On Mon, Nov 05, 2018 at 11:31:53AM +, Stuart Henderson wrote:
> On 2018/11/04 10:29, Daniel Dickman wrote:
> > The below overrides the cached autoconf value that says that we have
> > sbrk(2) on our system and pretends like we don't have it.
> >
> > With this we can build tcsh without a need
On Sun, Oct 07, 2018 at 09:43:05AM +0200, Giovanni Bechis wrote:
> Hi,
> after setting LC_ALL=en_US.UTF-8 on my env locate.mklocatedb seems broken,
> resetting LC_ALL=C is a workaround.
>
> $ export LC_ALL=en_US.UTF-8
> $ doas /usr/libexec/locate.updatedb
> sort: Illegal byte sequence
>
5 years agom I introduced a tweak to pkg_add to forego updates when they
weren't strictly necessary. Then I made it the default.
This caused some unidentified problems at the time, and the code was
backed out by kili@ soon afterward.
I just *fixed* a weird bug in pkg_add, and there's a good
On Mon, Dec 10, 2018 at 03:37:48PM -0500, Ted Unangst wrote:
> Solene Rapenne wrote:
> > Not sure how to fix it. Maybe people shouldn't try to compile as root when
> > having SUDO=doas set and then, it's not an issue anymore?
>
> yeah, i would say this is an issue of your own making. you ask to
On Mon, Dec 10, 2018 at 01:33:49PM +0100, Solene Rapenne wrote:
> hi
>
> I have SUDO=doas in /etc/mk.conf for ports, this is preventing a `make build`
> in /usr/src as root if /etc/doas.conf doesn't have a line "permit nopass root
> as root". This fails when using "doas" in regress/usr/bin/ssh/
>
On Mon, Dec 10, 2018 at 08:17:04PM +0100, Anton Lindqvist wrote:
> On Mon, Dec 10, 2018 at 01:33:49PM +0100, Solene Rapenne wrote:
> > hi
> >
> > I have SUDO=doas in /etc/mk.conf for ports, this is preventing a `make
> > build`
> > in /usr/src as root if /etc/doas.conf doesn't have a line
On Tue, Dec 11, 2018 at 02:35:33PM -0700, Theo de Raadt wrote:
> Ted Unangst wrote:
>
> > Marc Espie wrote:
> > > > > - try to remove the files normally first
> > > > > rm -f ${SUDO_CLEAN} || test -z "${SUDO}" || ${SUDO} rm -f
>
On Tue, Dec 11, 2018 at 06:50:07PM +0100, Solene Rapenne wrote:
> Marc Espie wrote:
> > On Mon, Dec 10, 2018 at 01:33:49PM +0100, Solene Rapenne wrote:
> > > hi
> > >
> > > I have SUDO=doas in /etc/mk.conf for ports, this is preventing a `make
> >
On Tue, Dec 11, 2018 at 10:55:25PM +0100, Claudio Jeker wrote:
> On Tue, Dec 11, 2018 at 02:35:33PM -0700, Theo de Raadt wrote:
> > Ted Unangst wrote:
> >
> > > Marc Espie wrote:
> > > > > > - try to remove the files normally first
> > > &g
On Wed, Dec 12, 2018 at 03:20:49PM +0100, Marc Espie wrote:
> Please test:
>
> pkg_add -u -DSHORTENED
And Landry found an issue. I forgot to update some code when I tweaked stuff
to add @version support.
Please try again with just committed pkg_add code...
(basically, the older versi
On Wed, Dec 12, 2018 at 11:12:17AM +0100, Alexander Bluhm wrote:
> On Tue, Dec 11, 2018 at 11:00:30PM +0100, Marc Espie wrote:
> > Ah, so actually just
> > rm -f ${SUDO_CLEAN}
> >
> > should be fine ?
>
> Regress jumps from root to non-root in a very inconsis
On Fri, Dec 14, 2018 at 03:57:12PM -0500, Ted Unangst wrote:
> Marc Espie wrote:
> > Well, apart from the bike-shedding, it seems like the most correct
> > short-term solution.
> >
> > So I will commit it tomorrow, unless someone has an actual better idea.
>
&
On Sun, Jan 27, 2019 at 01:07:05AM -0500, 0sjfoij...@firemail.cc wrote:
> Recently on LCA2019, Joel Sing made a presentation about "Security
> Vulnerability Mitigations"[1]
> (very good, btw). He suggests function strlcpy(3) as a secure API.
> In the same conference, though, Kees Cook ("Making C
On Mon, Feb 25, 2019 at 03:02:42PM -0500, Ted Unangst wrote:
> Andre Stoebe wrote:
> > Hi,
> >
> > I, too, would like to have a way of signing the gzip archive in a
> > reproducible way, so here's a diff that uses -n, similar to gzip(1).
> >
> > However, if that's a bad idea, I'm fine with
On Sun, Feb 24, 2019 at 10:09:43PM +0100, Matthias Schmidt wrote:
> Hi,
>
> while looking at signify's man page I noticed that the names of the
> arguments in the EXAMPLES section change (newkey.sec vs key.sec, etc).
> The diff harmonizes the examples. It makes it easier to follow the examples.
On Mon, Feb 25, 2019 at 05:11:54PM -0500, Ted Unangst wrote:
> Marc Espie wrote:
> > On Mon, Feb 25, 2019 at 03:02:42PM -0500, Ted Unangst wrote:
> > > Andre Stoebe wrote:
> > > > Hi,
> > > >
> > > > I, too, would like to have a way of sign
On Sun, Mar 17, 2019 at 03:10:04PM -0400, Ted Unangst wrote:
> Hiltjo Posthuma wrote:
> > Not all BSD man pages reference the same RFCs, like RFC5322. The OpenBSD
> > strptime(3) man page (%z) describes military/nautical zones are supported.
> >
> > - NetBSD supports it (correctly since only a
On Sat, Feb 09, 2019 at 05:23:09PM -0500, Ted Unangst wrote:
> Marc Espie wrote:
> > hey, your commit to install(1) broke something.
> >
> > Specifically lang/go-boostrap now produces a broken package which can't
> > be used to build go.
> >
> > All
On Wed, Feb 13, 2019 at 04:41:56PM +0100, Oleg Pahl wrote:
> Hi all,
>
> I use 6.4 Release.
> I install fm on my laptop from http://firmware.openbsd.org/firmware/6.4/
> This URL i found in man page FW_UPDATE(1)
> You can see that ( index.txt ) has one file more then as on server!
It doesn't
On Sun, Feb 10, 2019 at 03:55:41PM +0100, Marc Espie wrote:
> Something similar to this perhaps ?
> Not fully tested yet, but it should avoid the race of trying to
> unlink tempfile several times, and also fix the file name in error messages.
That's now been tested (gone thru a build
Something similar to this perhaps ?
Not fully tested yet, but it should avoid the race of trying to
unlink tempfile several times, and also fix the file name in error messages.
Index: xinstall.c
===
RCS file:
On Sat, Feb 09, 2019 at 05:23:09PM -0500, Ted Unangst wrote:
> Marc Espie wrote:
> > hey, your commit to install(1) broke something.
> >
> > Specifically lang/go-boostrap now produces a broken package which can't
> > be used to build go.
> >
> > All
On Fri, Feb 15, 2019 at 11:55:59AM +0100, Oleg Pahl wrote:
> Hi @all,
>
> Is it ok, that on man page *PKG_SIGN(1)* there is*[-D name=[value]]*
> argument,
>
> but there is no info about value of arg. below ... (I mean what kind of
> value's is possible to use with -D)
>
> I think, that its will
On Fri, Feb 15, 2019 at 07:58:48PM +0100, Giovanni Bechis wrote:
> ping...
> any possible issue with millert@ diff ?
> Giovanni
>
> On Sun, Oct 07, 2018 at 08:35:28PM -0600, Todd C. Miller wrote:
> > On Sun, 07 Oct 2018 17:08:06 +0200, Marc Espie wrote:
> >
> &
On Wed, Jan 23, 2019 at 05:55:54PM -0500, Ted Unangst wrote:
> Stuart Henderson wrote:
> > On 2019/01/22 21:46, Ted Unangst wrote:
> > > The persist feature in doas (actually the kernel side implementation) has
> > > some
> > > additional checks. The idea was to prevent accidental usage, but in
On Sun, Feb 03, 2019 at 02:23:16PM +, Stuart Henderson wrote:
> On 2018/12/24 19:05, Andrew Hewus Fresh wrote:
> > I've finally gotten our local patches applied to perl 5.28.1 and it now
> > could use some testing. I was trying to get a few more of my
> > architectures working, but I ran out
On Wed, Jan 30, 2019 at 01:56:04PM -0600, Scott Cheloha wrote:
> We need to tell ${CC} about b.o explicitly.
>
> ok?
>
> -Scott
>
> P.S. How was BSD $> or GNU $^ or an equivalent *not* standardized as
> an automatic variable? I get that it isn't a silver bullet, but in
> the relatively common
So, in dpb, I've been forking a lot of 'chroot -u user /build'
to build various things, and it works just great.
I was wondering about the benefits of
su ${BUILDUSER} -c 'some quoted command'
vs
chroot -u ${BUILDUSER} / some unquoted command
Superficially, it looks mostly similar.
The very
On Fri, May 24, 2019 at 07:22:07PM +0700, Oleg Chumanov wrote:
> First of all, I really want to thank you for your files.
>
> However, Can you show me an example of these:
>
> > makes it easier to perform error
> > recovery in the caller. For example, the caller may wish to
> > reallocate the
On Thu, Jun 20, 2019 at 09:41:23PM +0200, Rafael Sadowski wrote:
> This's what Qt 5.13 doas. They use "<< endl;" instead of "<< "\n";", I
> would like to prefer that. std::endl calls std::flush which synchronizes
> with the underlying storage device.
>
> RS
I agree with using endl if that's
On Thu, Jul 11, 2019 at 01:20:11PM +0100, Ricardo Mestre wrote:
> Hi,
>
> pledge "stdio rpath" is already called in main(), so we can remove the
> duplicate from parse_args(), along with the pledge commented out from another
> era!
>
> The second part is about placing pledge "stdio" in main()
After some musings, I realized I just had to reorder a few things to
make MAKEOBJDIR way more powerful (and possibly useful)
The idea here is to init vars early, which is easy, and to set up
.CURDIR, MACHINE, MACHINE_ARCH, MACHINE_CPU, so that
MAKEOBJDIR can actually become a full-blown make
This happened a long time ago...
okay ?
Index: make.1
===
RCS file: /cvs/src/usr.bin/make/make.1,v
retrieving revision 1.128
diff -u -p -r1.128 make.1
--- make.1 31 Jan 2019 10:27:28 - 1.128
+++ make.1 22 Aug 2019
On Mon, Sep 16, 2019 at 05:07:21PM +0800, Michael Mikonos wrote:
> Hello,
>
> When building flex on clang 8.0.1 (i386) I noticed that assert()
> expands to nothing. This happens because of a fallback declaration
> of assert() in flexdef.h when HAVE_ASSERT_H is not set. Instead of
> changing
On Fri, Jul 26, 2019 at 05:08:06AM +, Mike Burns wrote:
> On 2019-07-26 03.02.43 +, Mike Burns wrote:
> > Poking around signify and learned that `verifyzdata` calls `verifymsg`
> > with `1` hardcoded in the `quiet` parameter.
> >
> > I do appreciate that there is a distinction between
Well, the main issue I've seen so far is you flooding my mailboxen with
lots of copies of the same useless mp4 video.
What a douche.
On Sat, Nov 02, 2019 at 02:35:28PM +0100, Solene Rapenne wrote:
> On Sat, Nov 02, 2019 at 01:18:53PM +, Stuart Henderson wrote:
> > On 2019/11/01 19:16, Theo de Raadt wrote:
> > > Ted Unangst wrote:
> > >
> > > > Theo de Raadt wrote:
> > > > > What about all the other users who aren't in
On Tue, Nov 05, 2019 at 03:22:08PM +, Lauri Tirkkonen wrote:
> Hi,
>
> make has the concept of 'expensive' jobs: if the command line includes
> the word "make" in it, the command is considered expensive and other
> jobs are held until that job finishes. It does this to avoid exponential
>
On Thu, Nov 14, 2019 at 05:30:34PM +0200, Lauri Tirkkonen wrote:
> > > @@ -347,10 +360,9 @@ print_errors(void)
> > > static void
> > > setup_signal(int sig)
> > > {
> > > - if (signal(sig, SIG_IGN) != SIG_IGN) {
> > > - (void)signal(sig, notice_signal);
> > > - sigaddset(, sig);
On Thu, Nov 14, 2019 at 05:30:34PM +0200, Lauri Tirkkonen wrote:
> Yeah, you're right, it reads like crap, I'll rewrite it. The gist of the
> thing is that 'expensive' heuristic is now only used to decide whether
> or not to print the failed command.
I object to that. Keep the "expensive"
On Fri, Dec 13, 2019 at 02:19:26PM +0100, Matija Skala wrote:
> Dne petek, 13. december 2019 ob 13:34:57 CET je Marc Espie napisal(a):
> > On Fri, Dec 13, 2019 at 08:45:08AM +0100, Jasper Lievisse Adriaanse wrote:
> > > Hello Matija,
> > >
> > > Could you ple
On Fri, Dec 13, 2019 at 08:45:08AM +0100, Jasper Lievisse Adriaanse wrote:
> Hello Matija,
>
> Could you please provide a testcase for inclusion in
> src/regress/usr.bin/pkg-config too?
> Also, is there a particular port or pkg-config file in the wild that you ran
> into which exhibits this
On Wed, Dec 11, 2019 at 01:15:40PM -0700, Theo de Raadt wrote:
> I'm not sure I understand the goal of the signal handler.
>
> sdiff is moving forward through the file, only. If you are in a pager,
> you want to increase the width for the later output not yet visible?
> the normal way one does
On Thu, Dec 12, 2019 at 02:51:18AM -0700, Theo de Raadt wrote:
> Marc Espie wrote:
>
> > On Wed, Dec 11, 2019 at 01:15:40PM -0700, Theo de Raadt wrote:
> > > I'm not sure I understand the goal of the signal handler.
> > >
> > > sdiff is moving
This patch allows sdiff to auto-detect tty width,
by passing -w auto
More importantly, sdiff will adjust its variables on the fly for
subsequent lines (I don't know if redrawing the current
lines when the tty changes is advisable).
It's pretty straightforward, tested thru sysmerge.
Doesn't seem
On Wed, Nov 27, 2019 at 05:31:48PM +0200, Lauri Tirkkonen wrote:
> I'll give you some more background that I maybe should have given
> earlier already: in my hobby OS Unleashed, we use bmake and earlier did
> some (slightly hacky) modifications to subdir.mk to enable paralellizing
> jobs in
On Wed, Nov 27, 2019 at 06:21:01PM +0200, Lauri Tirkkonen wrote:
> All that said I do understand if there is reluctance to merge the
> jobserver stuff since it doesn't actually help the current situation in
> most cases. Nevertheless it has been personally beneficial to me in
> identifying areas
On Fri, Nov 15, 2019 at 03:29:29PM +0200, Lauri Tirkkonen wrote:
> On Fri, Nov 15 2019 15:24:57 +0200, Lauri Tirkkonen wrote:
> > Your points are valid and I agree with them completely. There are
> > clearly problems with lock contention,
>
> and I should mention here that I would probably not
This should get rid of the weird error (don't know how to make
.../all/debug-*.tgz) when switching from !DEBUG_PACKAGES to DEBUG_PACKAGES.
Basically, this introduces a "build two targets at once" in bsd.port.mk.
make has some glue to figure out whether this is a "duplicate the work" or
"one
On Mon, Dec 02, 2019 at 08:31:02AM +, Miod Vallat wrote:
> grep(1), when invoked with the -R option but no path, displays a
> "recursive search of stdin" warning and acts as if -R had not been
> specified.
>
> GNU grep, in that case, will perform a recursive search in the current
> directory,
On Mon, Nov 25, 2019 at 04:11:53PM +0200, Paul Irofti wrote:
> Hi,
>
> Few people complained (hi landry@!) that stripped binaries are slightly
> larger now than they used to be when debug packages are enabled.
>
> My investigations show that this is because objcopy --strip-debug is
> less
On Wed, Nov 27, 2019 at 12:42:48PM +0200, Lauri Tirkkonen wrote:
> In a lesson to always proof-read *before* sending your message:
>
> On Wed, Nov 27 2019 12:31:51 +0200, Lauri Tirkkonen wrote:
> > - a full release build with the jobserver enabled passed after
> >disabling
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:
> > > &
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
So, basically, if we start arbitrary commands, then
the classic loop
/* Wait for the child to exit. */
while (waitpid(cpid, , 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:
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,
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
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 regress
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
---
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 changes: add s
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
The only way errorJobs ever gets filled is by engine.c
around line 680 with a snippet that reads
if (!keepgoing) {
if (!silent)
printf("\n");
job->next = errorJobs;
If we look at job_handle_status, we see there's one case where it
doesn't place the job on the errorJob list, but doesn't try to reclaim
the memory.
Index: job.c
===
RCS file: /cvs/src/usr.bin/make/job.c,v
retrieving revision 1.143
So, a job is the series of shell commands run by make
a:
cmd1
expensive_cmd2
cmd3
so the granularity of expensive should be at the command level,
not the job level.
So, instead of running the code that may start new jobs at
the end of remove_job, let's run it after each
On Thu, Jan 02, 2020 at 11:19:30AM +0100, Ingo Schwarze wrote:
> Hi Kurt,
>
> Kurt Mosiejczuk wrote on Wed, Jan 01, 2020 at 08:21:04PM -0500:
>
> > cp(1) uses -R for recursive copy. scp(1) uses -r. This diff adds -R
> > as an alias for -r to scp(1) for those assuming consistency with cp(1).
>
>
We don't normally hit this thanks to the "expensive job" heuristics
(meaning that we don't start the second target while the first is
building), but still there is a race, and if for whatever reason we
remove that heuristics we hit it fairly hard.
The patch is fairly trivial, just run both
On Sat, Dec 28, 2019 at 07:48:45PM -0500, Bryan Steele wrote:
> With FreeDB announcing[0] that the service will be shutting down as of
> March 31st of 2020, and the only other alternative (MusicBrainz) already
> having shutdown their freedb/cddb gateway in favour of their own API
> early this
-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
On Thu, Apr 09, 2020 at 06:33:25PM +0200, Marc Espie wrote:
> Our make (bsd make) has "alternate" dependency operators :: and !
>
> Twenty years ago, we made it so that ambiguous constructs like
> File::Find.3p: File/Find.pm
>
> would no longer be ambiguous thanks to
Our make (bsd make) has "alternate" dependency operators :: and !
Twenty years ago, we made it so that ambiguous constructs like
File::Find.3p: File/Find.pm
would no longer be ambiguous thanks to the added space.
Now, I believe that ! should be trumped by : if both are present in the
same
On Thu, Apr 09, 2020 at 02:44:14PM +0200, Jeremie Courreges-Anglas wrote:
> On Thu, Apr 09 2020, Jeremie Courreges-Anglas wrote:
> > find(1) uses ARG_MAX to compute the maximum space it can pass to
> > execve(2). This doesn't fly if userland and the kernel don't agree, as
> > noticed by some
I do think newcomers will tend to miss examples, even if /etc/examples is
somewhat documented elsewhere.
Also, queries to mandocdb will probably benefit... say "what commands do
have an example configuration file ?" kind of what you should be able to
ask with advanced queries.
I haven't used wsmoused in ages, but I tend to think ideas like (by default)
scaling to the font size have great merit.
There should be a debugging toggle (maybe) to get raw values.
It should work out-of-the-box preferably. ;)
If tar can't create intermediate directories due to permission
issues, the resulting message is confusing:
./tar xf gcc.tar gcc-8.3.0/include/obstack.h
tar: Unable to create gcc-8.3.0/include/obstack.h: No such file or directory
(here I have gcc-8.3.0 owned by root and no permissions)
The
On Sun, Mar 22, 2020 at 01:09:17PM +0100, Denis Fondras wrote:
> On Sun, Mar 22, 2020 at 11:41:55AM +0100, Marc Espie wrote:
> > If tar can't create intermediate directories due to permission
> > issues, the resulting message is confusing:
> >
> > ./tar xf gcc.tar
There's some inconsistency:
lists/xserv/mi:./usr/X11R6/share/aclocal/xorg-macros.m4
lists/xshare/mi:./usr/X11R6/lib/pkgconfig/xorg-macros.pc
both should be in xshare
This does explain the failures of tightvnc on some bulk machines.
By default, proot does NOT copy xserv in the chroot, and I
On Fri, May 22, 2020 at 02:31:38PM +0200, Mark Kettenis wrote:
> > Date: Fri, 22 May 2020 13:50:44 +0200
> > From: Marc Espie
> >
> > I've had to neuter some setlocale() in mlt, since our code is
> > definitely NOT thread-safe. No biggie, since we do not have su
I've had to neuter some setlocale() in mlt, since our code is definitely NOT
thread-safe. No biggie, since we do not have support for LC_NUMERIC right now.
I think we might want the thread-specific functions, namely stuff like
strtod_l, or sprintf_l and friends.
Even if they do not do anything
On Fri, May 22, 2020 at 04:02:31PM +0200, Mark Kettenis wrote:
> > From: "Todd C. Miller"
> > Date: Fri, 22 May 2020 07:23:55 -0600
> >
> > On Fri, 22 May 2020 14:57:11 +0200, Marc Espie wrote:
> >
> > > From a security standpoint, is t
I want to introduce a new mechanism (libsets) to supplement wantlib...
Note that the keyword already exists in pkg_add.
the story so far:
wantlib evolved from lib-depends
basically, you tell a given package that it requires some libs, (WANTLIB)
and pkg_create will register those libs in the
On Sun, Oct 11, 2020 at 06:03:55PM +0200, Landry Breuil wrote:
> On Sun, Oct 11, 2020 at 05:03:31PM +0200, Marc Espie wrote:
> > On Sun, Oct 11, 2020 at 04:53:18PM +0200, Christian Weisgerber wrote:
> > > Marc Espie:
> > >
> > > > The new design:
&
On Sun, Oct 11, 2020 at 06:03:55PM +0200, Landry Breuil wrote:
> On Sun, Oct 11, 2020 at 05:03:31PM +0200, Marc Espie wrote:
> > On Sun, Oct 11, 2020 at 04:53:18PM +0200, Christian Weisgerber wrote:
> > > Marc Espie:
> > >
> > > > The new design:
&
On Sun, Oct 11, 2020 at 04:53:18PM +0200, Christian Weisgerber wrote:
> Marc Espie:
>
> > The new design:
> >
> > The idea behind "libset" is to be able to specify a "set" of wantlib that
> > corresponds to our package, AND to just write
On Tue, May 26, 2020 at 12:13:02AM +0200, Ingo Schwarze wrote:
> Hi,
>
> my impression is there are two totally independent topics in this
> thread.
>
> 1. Whether and how to make things safer, ideally terminating the
> program in a controlled manner, if it uses functions that are
> not
On Thu, May 28, 2020 at 05:44:31PM +0300, Paul Irofti wrote:
> Hi,
>
> Here is a new iteration of the diff which includes support for MD high
> resolution clocks. Currently only implements TSC on amd64. If the
> MD function is not defined, it fallsback to the syscall.
>
> There is the question
On Fri, May 29, 2020 at 03:48:41PM +0200, Ingo Schwarze wrote:
> Hi Marc,
>
> do i understand correctly that you intend to say: there are
> legitimate reasons to use these xlocale.h functions in portable
> software, in particular in portable libraries, so we should probably
> have them all, or
On Tue, May 26, 2020 at 12:13:02AM +0200, Ingo Schwarze wrote:
> Regarding the FreeBSD headers, i like them even less. There are both
> terrible design choices and terrible implementation choices. Regarding
> design, it appears that you *must* #include after other
> headers - if you include it
In a trace:
> > > #3 0x15e48c95459e in WebVfx::shutdown ()
> > > at /usr/obj/ports/webvfx-1.2.0/webvfx-1.2.0/webvfx/webvfx.cpp:193
Now, this is NOT the default location for WRKOBJDIR, but we are shipping
packages with debug information...
This could be a bit cumbersome, if in order to
> - have some magic I don't know in ELF handling that would allow to either
> tweak the default location/introduce ${WRKOBJDIR} in that debug info.
Thinking some more about it, that 3rd option is possibly not that
far-fetched
we do pass most debug-info thru dwz for shrinkage, so there's one
On Sat, May 30, 2020 at 05:10:49PM +0200, Jeremie Courreges-Anglas wrote:
> On Sat, May 30 2020, Marc Espie wrote:
> >> - have some magic I don't know in ELF handling that would allow to either
> >> tweak the default location/introduce ${WRKOBJDIR} in that debug info.
>
I occasionnally use setxkbmap 'us(intl)' in order to have diacritics
as dead keys.
I have LC_CTYPE=en_US.UTF-8
If I type 'c
I get a ç in programs like firefox or chrome, BUT I get
ć in xterm ?
why are things different ? which program is right ?
(I have just tried with a test user with
On Mon, Jun 01, 2020 at 03:46:09PM +0200, Matthieu Herrb wrote:
> On Mon, Jun 01, 2020 at 03:28:52PM +0200, Stéphane Aulery wrote:
> > Hello,
> >
> > Le 01/06/2020 14:55, Matthieu Herrb a écrit :
> > >
> > > >
> > > > (I have just tried with a test user with nothing configured besides
> > > >
On Mon, Jun 01, 2020 at 03:37:45PM -0600, Anthony J. Bentley wrote:
> Marc Espie writes:
> > > To setup the right alt key as compose, you can either:
> > >
> > > - run 'setxkbmap -option compose:ralt' somewhere in your session
> > > startup script
> &
401 - 500 of 615 matches
Mail list logo
