On Monday, November 13, 2023 8:34:04 PM CET Manuel Bouyer wrote:
> Hello
> I'm facing an issue with postfix+openssl3 which may be critical (depending
> on how it can be fixed).
>
> Now my postfix setup fails to send mails with
> Nov 13 20:20:53 comore postfix/smtp[6449]: warning: TLS library
Am Thu, Apr 20, 2023 at 10:38:56PM +0300 schrieb Valery Ushakov:
> On Thu, Apr 20, 2023 at 11:08:43 -0600, Brook Milligan wrote:
>
> > What should I be configuring to make sure that a tooldir compiler is
> > usable?
>
> The tools in the tooldir expect that the netbsd src makefiles call
> them
Am Fri, Mar 31, 2023 at 02:39:40PM +0200 schrieb Thomas Klausner:
> On Fri, Mar 31, 2023 at 02:35:38PM +0200, Martin Husemann wrote:
> > Which options does it pass to g++ ?
>
> Good point, but it's not the compiler, it's lua itself:
>
> tar xvzf lua-5.4.4.tar.gz
> cd lua-5.4.4/src
>
Am Fri, Feb 24, 2023 at 12:45:54PM -0800 schrieb Greywolf:
> I would be appreciative of any clues pointing toward a solution.
Two options:
(1) Force C.UTF-8 for the extract step on systems that can support it.
(2) Try --options hdrcharset=BINARY for (bsd)tar.
Joerg
Am Sat, Jan 07, 2023 at 10:00:39AM +0100 schrieb Thomas Klausner:
> #9 0x7f59b6644282 in scm_error (key=0x7f59a6a41560,
> subr=subr@entry=0x7f59b670f487 "scm_hash_fn_get_handle",
> message=message@entry=0x7f59b670c9e0 "Wrong type argument in position ~A
> (expecting ~A): ~S",
>
On Sat, Sep 03, 2022 at 10:00:04AM +1200, Lloyd Parkes wrote:
> Does anyone know of a maintained DHCP relay implementation?
The better question for me is: are DHCP relayer server still in use?
Joerg
On Sun, Aug 14, 2022 at 02:38:07AM +0700, Robert Elz wrote:
> To avoid delays in a message turnaround, this is what sysctl says is
> available (this output is from a normal boot, not the PCIDUMP one).
>
> kern.timecounter.choice = TSC(q=3000, f=3417601000 Hz) clockinterrupt(q=0,
> f=100 Hz)
Am Sun, May 01, 2022 at 01:24:01PM -0700 schrieb Chuck Silvers:
> the above patch simply resolves the symbol for the libpthread call to
> _lwp_park
> while the process is still single-threaded, by calling the _lwp_park to both
> unpark and park itself, which just returns immediately. after that,
Am Tue, Apr 05, 2022 at 02:43:08PM +0200 schrieb Thomas Klausner:
> Hi!
>
> OpenBSD fixed a problem in libuv related to kevent, here's a writeup
> by Ted Unangst.
>
> https://flak.tedunangst.com/post/sometimes-the-knote-comes-early
>
> Is that the same problem we're seeing with cmake hangs?
I
On Mon, Nov 01, 2021 at 02:35:56PM +, Chavdar Ivanov wrote:
> $ ssh 192.168.0.51
> Unable to negotiate with 192.168.0.51 port 22: no matching key
> exchange method found. Their offer:
>
On Wed, Jun 16, 2021 at 06:13:23AM +0200, Martin Husemann wrote:
> On Wed, Jun 16, 2021 at 03:42:35AM +, Thomas Mueller wrote:
> > I believe I must apply the fix/workaround every time.
>
> The entropy state gets stored on shutdown and reloaded on next boot.
> Fixing it once is enough.
On Sat, May 01, 2021 at 11:02:26AM +0200, Thomas Klausner wrote:
> gmake since version 4.3 uses posix_spawn(), but that breaks the build
> of firefox (and libreoffice). Disabling posix_spawn() support in gmake
> works around this problem.[1]
The obvious differences I see:
- SHELL is ignored by
On Fri, Apr 30, 2021 at 05:31:53PM +1200, Lloyd Parkes wrote:
> ceph4% hg --version
> Mercurial Distributed SCM (version 5.3.2)
Please note that this is quite an old version and a lot of work on
improving both CPU time and memory use has been spend since then.
Joerg
On Wed, Apr 28, 2021 at 08:30:00PM +0200, Riccardo Mottola wrote:
> I was skeptical, and... I had reason to apparently. I tried on a dual-core
> intel laptop with 3GB of RAM. Something fairly decent.
I wouldn't call 3GB RAM decent nowadays, but it should certainly be
enough.
>
> At first I
On Wed, Apr 21, 2021 at 02:21:51AM -0700, John Nemeth wrote:
> On Apr 20, 21:13, Joerg Sonnenberger wrote:
> } On Wed, Apr 21, 2021 at 12:54:36AM +0700, Robert Elz wrote:
> } > It seems as if what is happening, is that the router is sending RA's with
> } > the source-link addr o
On Wed, Apr 21, 2021 at 12:54:36AM +0700, Robert Elz wrote:
> It seems as if what is happening, is that the router is sending RA's with
> the source-link addr option, which isn't being added to the neighbour
> cache.
>
> Then NetBSD is doing a NS to discover the address it ignored from the RA,
>
On Tue, Apr 20, 2021 at 10:09:47AM -0400, Jan Schaumann wrote:
> Greg Troxel wrote:
> >
> > Jan Schaumann writes:
> >
> > > Apr 20 01:32:32 netbsd dhcpcd[17397]: xennet0: soliciting an IPv6 router
> > > Apr 20 01:32:34 netbsd dhcpcd[17397]: xennet0: Router Advertisement from
> > >
On Mon, Apr 19, 2021 at 04:39:45PM +1200, Lloyd Parkes wrote:
> Someone moved the bookmark called "@" in a way that Mercurial wasn't willing
> to blindly propagate into my local, central copy of the Mercurial src
> repository. This could easily have been done by part of the CVS to Mercurial
>
On Tue, Apr 06, 2021 at 04:49:58PM -, Michael van Elst wrote:
> Otherwise I see several infinite loops, a python deadlock in the samba4 build
> and, new, the kdelibs4 build stalls for kfiltertest_automoc.cpp.
The samba4 thing can be avoided with MAKE_JOBS_SAFE=no. I don't fully
understand
On Tue, Apr 06, 2021 at 04:26:44PM -, Christos Zoulas wrote:
> In article ,
> Manuel Bouyer wrote:
> >On Tue, Apr 06, 2021 at 02:24:50PM +0100, Chavdar Ivanov wrote:
> >> Hi,
> >>
> >> It may or may not be linked to the recent rather enthralling
> >> discussion about the entropy; I don't
On Sun, Apr 04, 2021 at 11:47:10PM +0700, Robert Elz wrote:
> If not, what prevents someone from reading (copying) the file from the
> system while it is stopped (assessing the storage device via other methods)
> and then knowing exactly what the seed is going to be when the system boots?
That is
On Sun, Apr 04, 2021 at 03:32:08PM -0700, Greg A. Woods wrote:
> At Mon, 05 Apr 2021 00:14:30 +0200 (CEST), Havard Eidnes
> wrote:
> Subject: Re: regarding the changes to kernel entropy gathering
> >
> > > What about architectures that have nothing like RDRAND/RDSEED? Are
> > > they,
On Mon, Apr 05, 2021 at 12:07:49AM +0200, Havard Eidnes wrote:
> I am still of the fairly firm beleif that the mistrust in the
> hardware vendors' ability to make a reasonable and robust
> implementation is without foundation.
It's not without foundation. Remember the first hardware RNG on x86?
On Sun, Apr 04, 2021 at 09:24:56PM +, RVP wrote:
> PS. Is there a way to get the bit-stream from the various in-kernel
> sources so that we can run them through these sort of tests? That
> way we can check--not intuit--how random the bit-streams they
> produce really are.
Part of the problem
On Sun, Apr 04, 2021 at 02:16:41PM -0700, Paul Goyette wrote:
> > Personally, I'm happy with anything that your average high school
> > student is unlikely to be able to crack in an hour. I don't run
> > a bank, or a military installation, and I'm not the NSA. If someone
> > is prepared to put
On Sat, Apr 03, 2021 at 08:14:34PM -, Christos Zoulas wrote:
> In article , Joerg Sonnenberger
> wrote:
> >On Sat, Apr 03, 2021 at 01:15:15AM -0400, Christos Zoulas wrote:
> >> Yes, I think that the appropriate change is to make those assertions
> >> so i
On Sat, Apr 03, 2021 at 01:15:15AM -0400, Christos Zoulas wrote:
> Yes, I think that the appropriate change is to make those assertions
> so if there is a broken filesystem/syscall there is a more obvious
> error (rather than infinite loop in read or core-dump in iconv), but let's
> see what joerg
On Wed, Mar 31, 2021 at 05:56:16PM -0400, Christos Zoulas wrote:
> What is the NFS server? Because on NetBSD it returns 255...
This should be fixed in the kernel. Seriously, stop adding more code to
deal with garbage from the kernel.
Joerg
On Sun, Mar 28, 2021 at 06:49:33AM +, RVP wrote:
> This might, or might not, be related. There is another bug in
> tar. It hangs when reading files on FUSE-mounted filesystems:
This is a bug in the FUSE layer. It should really sanitize the input and
not force it on any consumer.
Joerg
On Tue, Nov 10, 2020 at 12:31:26PM +0100, Matthias Petermann wrote:
> Hallo Matthew,
>
> Am 10.11.2020 um 05:35 schrieb matthew sporleder:
> > Hey -- the end of the year is coming up fast. Wouldn't you feel
> > better about yourself if you added a github sponsorship to balance out
> > your
On Mon, Nov 09, 2020 at 11:15:52PM +0100, Vincent DEFERT wrote:
> On 09/11/2020 21:49, m...@netbsd.org wrote:
> > Unfortunately it leads to surprise failures if programs ever use
> > /dev/random. If not seeded, reads from it will block forever.
> If it has such consequences, the installer - or
On Mon, Nov 09, 2020 at 11:03:31AM +, nia wrote:
> On Mon, Nov 09, 2020 at 11:18:31AM +0100, Martin Husemann wrote:
> > On Mon, Nov 09, 2020 at 10:10:56AM +, nia wrote:
> > > fwiw, i think the default options should be as close to Just Work as
> > > possible.
> > >
> > > i have installed
On Thu, Oct 01, 2020 at 02:05:52PM +0200, Martin Husemann wrote:
> On Thu, Oct 01, 2020 at 02:03:30PM +0200, Martin Husemann wrote:
> > On Thu, Oct 01, 2020 at 01:56:15PM +0200, Thomas Klausner wrote:
> > > Program Headers:
> > > Type Offset VirtAddr PhysAddr
> >
On Tue, Sep 22, 2020 at 12:34:12AM +0200, Thomas Klausner wrote:
> According to the NetBSD man page for pthread_attr_setguardsize(), the
> effect of this function is ignored when pthread_attr_setstack() is
> used. This does not seem to be the case here.
That's not exactly what happens. libpthread
On Sun, Sep 20, 2020 at 08:03:13PM +0100, Chavdar Ivanov wrote:
> On Sun, 20 Sep 2020 at 19:58, Joerg Sonnenberger wrote:
> >
> > On Sun, Sep 20, 2020 at 02:06:42PM +0100, Chavdar Ivanov wrote:
> > > I am not seeing other people report these lately, but I sti
On Sun, Sep 20, 2020 at 02:06:42PM +0100, Chavdar Ivanov wrote:
> I am not seeing other people report these lately, but I still continue
> to get these hangings, e.g. when running git as part of a zsh prompt
> function; roughly every fourth command ends up with one of these,
> again as before, it
On Sat, Aug 29, 2020 at 08:25:42AM -0700, Rob Newberry wrote:
> >>> NetBSD's implementation of vdprintf makes a special check -- if the
> >>> descriptor is in non-blocking mode, it needs to be a regular file (I
> >>> think I read that code correctly). But it apparently doesn't have this
> >>>
On Fri, Aug 28, 2020 at 10:02:51PM -, Christos Zoulas wrote:
> In article ,
> Rob Newberry wrote:
> >(Also posting to tech-userlevel...)
> >
> >
> >NetBSD's implementation of vdprintf makes a special check -- if the
> >descriptor is in non-blocking mode, it needs to be a regular file (I
>
On Thu, Jul 16, 2020 at 08:28:29PM +0100, David Brownlee wrote:
> On Thu, 16 Jul 2020 at 15:40, Christos Zoulas wrote:
> >
> > In article <7171.1594774...@splode.eterna.com.au>,
> > matthew green wrote:
> > >Martin Husemann writes:
> > >>
On Mon, Jul 13, 2020 at 04:28:56PM -0700, Greg A. Woods wrote:
> At Tue, 14 Jul 2020 00:28:46 +0200, Joerg Sonnenberger wrote:
> Subject: Re: recent changes to pthread_fork.c:fork() cause static linking to
> fail if the app provides its own malloc()
> >
> > On Mon, Jul 1
On Mon, Jul 13, 2020 at 03:05:17PM -0700, Greg A. Woods wrote:
> I think it is the following change (and perhaps more similar/related
> changes) which breaks static linking of applications which wish to
> supply their own implementation of malloc(), and which call, e.g.,
> fork():
I consider it a
On Wed, Jul 08, 2020 at 02:21:06PM +0200, Frank Kardel wrote:
> The next message is the setting of the maxiimum frequency which hoses the
> RPI3B serial port speed. Do we have a clock setting/source issue here?
That's a design flaw in the RPI3. It ties the GPU frequency to the
serial console.
On Sun, Jul 05, 2020 at 11:11:44PM +0200, Kamil Rytarowski wrote:
> Literal and unextended implementation of the standard happened to be
> unpractical. All/most mainstream users (all other BSDs, Win, Mac, GNU,
> Solaris, ...) diverged from it within the last 20 years.
Funny that you should
On Mon, Jun 29, 2020 at 12:34:31AM +0200, Kamil Rytarowski wrote:
> On 28.06.2020 23:57, Joerg Sonnenberger wrote:
> > On Sun, Jun 28, 2020 at 11:48:15PM +0200, Kamil Rytarowski wrote:
> >> On 28.06.2020 23:29, Joerg Sonnenberger wrote:
> >>> It is fundamentally wrong
On Sun, Jun 28, 2020 at 11:48:15PM +0200, Kamil Rytarowski wrote:
> On 28.06.2020 23:29, Joerg Sonnenberger wrote:
> > It is fundamentally wrong to use a handler in a library that can be
> > unloaded. Some systems hack around that problem by looping over all
> > atexi
On Sun, Jun 28, 2020 at 10:56:01PM +0200, Rhialto wrote:
> On Sun 28 Jun 2020 at 22:39:28 +0200, Joerg Sonnenberger wrote:
> > On Sun, Jun 28, 2020 at 10:35:27PM +0200, Rhialto wrote:
> > > I have at hand a program (the current svn trunk of VICE, to be exact)
> > &g
On Sun, Jun 28, 2020 at 10:35:27PM +0200, Rhialto wrote:
> I have at hand a program (the current svn trunk of VICE, to be exact)
> which does the following:
>
> 1. In the original thread, it dlopen()s libavformat.
> 2. libavformat establishes an atexit() handler.
> 3. The main thread starts a new
On Tue, Jun 09, 2020 at 11:22:27PM +, Andrew Doran wrote:
> On Sat, Jun 06, 2020 at 09:25:55PM +0200, Joerg Sonnenberger wrote:
>
> > On Sat, Jun 06, 2020 at 06:45:03PM +0100, Chavdar Ivanov wrote:
> > > On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov wrote:
> > > &
On Sat, Jun 06, 2020 at 06:45:03PM +0100, Chavdar Ivanov wrote:
> On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov wrote:
> >
> > Hi,
> >
> > I got another cmake hang during pkg_rolling-replace today, while
> > building misc/kdepimlibs4, trace as follows:
>
> Just to mention that after I quit gdb and
On Sun, May 31, 2020 at 03:06:42PM -0500, J. Lewis Muir wrote:
> On May 31, 2020, at 11:41 AM, Joerg Sonnenberger wrote:
> >
> > On Sun, May 31, 2020 at 02:07:23PM +0200, Rhialto wrote:
> >> I was looking at the git clone of the src repo
> >> (https://git
On Sun, May 31, 2020 at 02:07:23PM +0200, Rhialto wrote:
> I was looking at the git clone of the src repo
> (https://github.com/netbsd/src) and I noticed that there are lots of
> duplicate commits in there; some commits are even present 3 or 4 times.
> At first I thought this occurs only with very
On Wed, May 27, 2020 at 05:42:37PM +0200, Tobias Nygren wrote:
> There is an -mno-sse2 flag on the command line and it conflicts with
> your -mfpmath=sse flag. This COPTS setting comes from
> src/libexec/ld.elf_so/Makefile. You can remove the flag but expect
> random breakage, it is there for a
On Sun, May 24, 2020 at 09:22:41AM +0100, Chavdar Ivanov wrote:
> While doing pkg_rolling-replace on amd64 -current from yesterday, I
> got three times in a row a hang in cmake as the followingL
Please attach with gdb and run "thread apply all bt" and give me the
result. There are still two
On Wed, May 13, 2020 at 10:11:14PM -0400, John Franklin wrote:
> There are scalability issues with Mercurial, too. I cloned NetBSD src
> on a 1GB RAM, 1GB swap, 4 CPU VM (Debian Buster) using git from the
> GitHub project and from anonhg.netbsd.org.
You are comparing Apples and Oranges. The
On Wed, May 13, 2020 at 12:21:50PM -0700, Greg A. Woods wrote:
> At Wed, 13 May 2020 14:14:16 +0200, Joerg Sonnenberger wrote:
>
> > I have no idea what the OP is talking about. Mercurial doesn't have pull
> > requests, neither does git BTW. So this is about some specific we
On Tue, May 12, 2020 at 08:55:05PM -0700, Greg A. Woods wrote:
> For one, Mercurial has no staging area. That removes one level of
> the three-level hierarchy from my toolset. It’s hard to identify
> exactly when in my workflow this causes issues, but I’ve started to
> notice it.
On Sat, Apr 18, 2020 at 10:32:18AM +0300, Andreas Gustafsson wrote:
> The NetBSD Test Fixture sent three reports listing the following
> groups of commits, respectively:
>
> >2020.04.16.14.39.58 joerg src/lib/libc/gen/pthread_atfork.c,v 1.13
> >2020.04.16.14.39.58 joerg
On Sat, Apr 18, 2020 at 01:09:52AM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> lib/libc/sys/t_ptrace_wait4:fork10
> lib/libc/sys/t_ptrace_wait4:fork2
>
On Sat, Apr 18, 2020 at 12:01:37AM +0700, Robert Elz wrote:
> Date:Fri, 17 Apr 2020 18:15:01 +0200
> From: Joerg Sonnenberger
> Message-ID: <20200417161501.gb72...@bec.de>
>
> | I'm talking about the difference between this new clobber flag and
On Fri, Apr 17, 2020 at 02:10:19AM +0700, Robert Elz wrote:
> Date:Thu, 16 Apr 2020 19:27:48 +0200
> From: Joerg Sonnenberger
> Message-ID: <20200416172748.ga86...@bec.de>
>
> | What is the point of this "restriction"? They wanted to m
On Thu, Apr 16, 2020 at 07:17:06PM +0700, Robert Elz wrote:
> O_NOCLOBBER|O_CREAT is intended to be the same as O_EXCL|O_CREAT when the
> file named is a regular file, but unlike the O_EXCL variant, succeed if
> the file is a special file (like /dev/ttyN) which exists already.
What is the point
On Thu, Apr 16, 2020 at 07:17:06PM +0700, Robert Elz wrote:
> Its main purpose would be to implement noclobber mode (set -C) in sh
> (and one presumes, the similar thing in csh).
It strikes me as a lot of complexity for a limited use case.
Joerg
PS: I would find something like O_NOATIME to be
On Tue, Mar 24, 2020 at 09:27:54PM +0700, Robert Elz wrote:
> Date:Tue, 24 Mar 2020 14:13:30 +0100
> From: Joerg Sonnenberger
> Message-ID: <20200324131330.ga60...@bec.de>
>
> | Yes, so far it has been intended only for internal use as stre
On Tue, Mar 24, 2020 at 02:27:54PM +0700, Robert Elz wrote:
> Incidentally, is there a reason that strerror_lr is not exposed to
> userland, it has no prototype (not even one guarded by _NETBSD_SOURCE)
> anywhere in /usr/include/* and there's actually no alias for it
> (all that actually exists is
On Tue, Mar 24, 2020 at 12:58:15AM +0700, Robert Elz wrote:
> Date:Mon, 23 Mar 2020 18:09:50 +0100
> From: Joerg Sonnenberger
> Message-ID: <20200323170950.ga120...@bec.de>
>
> | On Mon, Mar 23, 2020 at 11:50:37PM +0700, Robert Elz wrote:
>
On Mon, Mar 23, 2020 at 11:50:37PM +0700, Robert Elz wrote:
> strerror_r is semi-deprecated, Issue 7 (current POSIX) already has a
> strerror_l() function we do not seem to support.
We do have it.
Joerg
On Sun, Mar 01, 2020 at 06:13:45PM +, David Brownlee wrote:
> Since some ports are distributing install sets in xz format would it
> make sense to add xzcat to /rescue (just hit a case where I wanted to
> reextract sets on a test machine)
zcat should handle that fine and so would tar?
Joerg
On Fri, Jan 17, 2020 at 08:53:39PM -0800, Greg A. Woods wrote:
> At Thu, 9 Jan 2020 01:19:39 +0100, Joerg Sonnenberger wrote:
> Subject: Re: unable to boot amd64-uefi-install from USB stick on a MacBook2,1
> >
> > On Wed, Jan 08, 2020 at 04:08:40PM -0800, Greg A. Woods wr
On Thu, Jan 09, 2020 at 12:42:29PM +, Chavdar Ivanov wrote:
> In order to get the above running on -current (yes, it is this way
> hardcoded in the package). If 3404 is some magic number required, then
> perhaps the package should be patched to run under -current (or,
> perhaps, the released
On Wed, Jan 08, 2020 at 04:08:40PM -0800, Greg A. Woods wrote:
> However in searching related things I just came across a reminder about
> memory issues on this particular model of MacBook2,1. It originally
> shipped with 2x1GB memory modules. At some point I upgraded it to 2x2GB
> modules.
On Wed, Jan 08, 2020 at 04:04:31PM +0100, Adam wrote:
> > Index: pkgsrc/lang/nodejs/patches/patch-deps_v8_src_zone_zone.h
> > diff -u /dev/null
> > pkgsrc/lang/nodejs/patches/patch-deps_v8_src_zone_zone.h:1.1
> > --- /dev/null Mon Jan 6 23:06:44 2020
> > +++
On Sun, Dec 29, 2019 at 09:55:16PM +, Andrew Luke Nesbit wrote:
> Please, could you (privately?) send me the name of this feature, so I know
> what to search on? Or links to specs of a few models that implement the
> feature? Thank you!!
On the specification page of the printer, you should
On Wed, Nov 13, 2019 at 10:34:51PM -, Christos Zoulas wrote:
> In article <20191113222728.ga79...@bec.de>,
> Joerg Sonnenberger wrote:
> >On Wed, Nov 13, 2019 at 10:24:21PM -, Christos Zoulas wrote:
> >> I don't want processes to die of fail to start because
On Wed, Nov 13, 2019 at 10:24:21PM -, Christos Zoulas wrote:
> I don't want processes to die of fail to start because I am extracting
> a tar file and I happen to be overwriting libc. It just does not
> need to happen and it did not happen before.
This argument is plainly false. It was never
On Wed, Nov 13, 2019 at 07:29:59PM -, Christos Zoulas wrote:
> Yes, but open(O_EXCL) does not protect you against mmapped segments
> (which has the potential to kill running processes that use shared
> libraries/jar/other mapped files) or crashing in the middle of
> writing a file and leaving
On Tue, Nov 12, 2019 at 08:25:46AM -0500, Greg Troxel wrote:
> David Brownlee writes:
>
> > On Tue, 12 Nov 2019 at 11:33, Jaromír Doleček
> > wrote:
> >>
> >> Le mar. 12 nov. 2019 à 12:05, Martin Husemann a écrit
> >> :
> >>>
> >>> Not seen this locally, but that would be the switch to
On Tue, Nov 12, 2019 at 12:05:14PM +0100, Martin Husemann wrote:
> Not seen this locally, but that would be the switch to bsd/libarchive tar.
> Maybe it does not unlink files before extraction and replaces them in-space?
It doesn't unlink them by default, yes. -U would force that.
Joerg
On Wed, Oct 30, 2019 at 12:08:09PM +1100, matthew green wrote:
> nullfs is terrible. i've always known it has the potential
> to double-cache some file when accessed on both sides.. but
> i recently had a problem where nullfs mounted system was
> stopping ffs from freeing deleted files. i
On Thu, Oct 24, 2019 at 06:56:57AM +0700, Robert Elz wrote:
> Date:Wed, 23 Oct 2019 23:30:47 +0200
> From: Joerg Sonnenberger
> Message-ID: <20191023213047.ga73...@bec.de>
>
> | (1) Abuse of symlinks to shuffle the tree somewhere else. IMO whoe
On Wed, Oct 23, 2019 at 09:41:30PM -, Christos Zoulas wrote:
> In article <20191023213047.ga73...@bec.de>,
> Joerg Sonnenberger wrote:
> >On Wed, Oct 23, 2019 at 04:58:05PM -, Christos Zoulas wrote:
> >> I am not advocating for either, perhaps we should just ad
On Wed, Oct 23, 2019 at 04:58:05PM -, Christos Zoulas wrote:
> I am not advocating for either, perhaps we should just add -P to the
> extraction and get over it :-)
>From what I can tell there are two completely separate issues:
(1) Abuse of symlinks to shuffle the tree somewhere else. IMO
On Tue, Oct 22, 2019 at 08:00:35PM +0200, Christian Groessler wrote:
> "tar" had an option to delete files which it is about to extract before
> extraction. Wouldn't this solve the "symlink" issue at hand? What am I
> missing?
See the SECURITY section in the man page. Both -U and -P are ways to
On Tue, Oct 22, 2019 at 07:26:05AM +0200, Martin Husemann wrote:
> On Tue, Oct 22, 2019 at 06:37:44AM +0700, Robert Elz wrote:
> > Date:Mon, 21 Oct 2019 21:20:25 +0200
> > From:Joerg Sonnenberger
> > Message-ID: <20191021192025.ga33...@bec.de
On Mon, Oct 21, 2019 at 05:34:44PM -, Christos Zoulas wrote:
> In article <20191021163005.ga4...@bec.de>,
> Joerg Sonnenberger wrote:
> >On Mon, Oct 21, 2019 at 06:29:18AM -0700, Hisashi T Fujinaka wrote:
> >> On Mon, 21 Oct 2019, Martin Husemann wrote:
> &
On Mon, Oct 21, 2019 at 06:29:18AM -0700, Hisashi T Fujinaka wrote:
> On Mon, 21 Oct 2019, Martin Husemann wrote:
>
> > On Mon, Oct 21, 2019 at 11:54:44AM +0200, J. Hannken-Illjes wrote:
> > > Somewhere between Netbsd-8 and NetBSD-9 "tar" changed its behaviour
> > > when it has to extract a
On Thu, Oct 17, 2019 at 12:43:48PM +0200, Rhialto wrote:
> On Thu 17 Oct 2019 at 11:07:44 +0200, Maxime Villard wrote:
> > I guess we whould disable the messages on this particular file for now as
> > the others have suggested, and file a PR in LLVM/GCC, because apart from
> > a compiler bug I
On Sun, Oct 13, 2019 at 11:25:16PM +0200, Rhialto wrote:
> On Thu 10 Oct 2019 at 12:46:43 +, m...@netbsd.org wrote:
> > Unpack all of them in / ('tar xJpf') except etc.tar.xz. That one will
>
> You don't even need the J option when decompressing, plain old z will
> work too (for all the usual
On Fri, Aug 30, 2019 at 12:09:17PM +0200, Manuel Bouyer wrote:
> clang is known to need *lots* of ram
It's not clang, it is ld. It's ~540MB peak RSS here for a non-debug
build. Debug builds are much worse though.
Joerg
On Mon, Aug 05, 2019 at 03:11:16PM +0300, Andrius V wrote:
> I noticed github and fossil repositories are not being synced since 1
> of August. Is it a known issue or syncing is deliberately stopped?
Known physical issue. It is being investigated.
Joerg
On Tue, Jul 30, 2019 at 10:51:11AM +0100, Chavdar Ivanov wrote:
> GNU tar reports the extended header and does not restore it by default - the
> file can be unlinked:
> ...
> # gtar xjvpf a1.tar.bz2
> autotroll1/
> gtar: Ignoring unknown extended header keyword 'SCHILY.fflags'
>
On Tue, Jun 25, 2019 at 07:15:14PM +, n...@n0.is wrote:
> has someone commited a fix for this in the last 8 hours or so
> since I've been compiling src?
It's been fixed now.
Joerg
On Thu, May 30, 2019 at 09:32:24PM +0100, Chavdar Ivanov wrote:
> error: 'asm' undeclared (first use in this function)
> asm volatile ("pause");
> ^~~
> ...
>
> (I had to revert to the original cpufunc.h as the cvs update was failing).
>
> What is the solution here - should I
On Wed, May 22, 2019 at 08:38:07AM +0300, Andrius V wrote:
> However, I was trying to clone repo in the system with ~36 GB free as
> well without any separate partitions, it also failed with out of
> memory error. Seems like vacuuming process is taking quite a lot of
> space by itself.
Yes,
On Sun, May 19, 2019 at 08:34:44PM +0300, Andrius V wrote:
> Hello,
>
> Is there anybody successfully using fossil repository of NetBSD source
> (https://src.fossil.netbsd.org)? Some time ago I started to get errors
> on fetching which I though there were my environment issues, so I just
>
On Fri, Apr 19, 2019 at 07:09:51PM +0800, Paul Goyette wrote:
> And while we're at it, the man page for apropos(1) says that the -p option
> _defaults_ to using more(1) as the pager, implying that it should be
> possible to use a different pager. Yet there is no option to tell apropos
> to which
On Tue, Feb 12, 2019 at 05:46:24PM +0100, Martin Husemann wrote:
> On Tue, Feb 12, 2019 at 04:35:02PM +, Patrick Welche wrote:
> > Bemused by:
> >
> > xenpmd.c:90:36: error: '%s' directive output may be truncated writing up to
> > 511 bytes into a region of size 271
On Thu, Feb 07, 2019 at 11:10:30AM -0600, John D. Baker wrote:
> [...]
> --- cleandir-external ---
> --- cleandir-lib ---
> cleandir ===> external/bsd/pkg_install/lib
> [...]
> --- cleandir-external ---
> nbmake[7]: "/x/current/src/external/bsd/pkg_install/lib/../Makefile.inc" line
> 16:
On Mon, Nov 26, 2018 at 09:33:27PM +0100, Adam wrote:
> I am try to compile lang/rust under NetBSD-amd64 8.99.26 (today's build) on
> VirtualBox. The process is extremely slow, and top is showing weird values:
Rust loves to eat as much cores as possible. That doesn't play well with
limited
On Wed, Nov 21, 2018 at 02:10:01PM -, Michael van Elst wrote:
> mar...@duskware.de (Martin Husemann) writes:
>
> >Pigz can not create .xz files, so if you force USE_PIGZ_GZIP=yes
> >it will override the USE_XZ_SETS and you will get .tgz again.
>
> I'd rather reverse that logic. Chose the
On Wed, Oct 03, 2018 at 06:57:42PM +0700, Robert Elz wrote:
> | Yes, the configure writes to the current directory. That's how it is
> | meant to be used. The current directory in the case of the tools builds
> | is the objdir.
>
> Really?
>
> This is from one of my recent builds (the same
1 - 100 of 216 matches
Mail list logo
