Hi Micheal,
On Fri, Jun 21, 2024 at 11:27:33AM -, Michael van Elst wrote:
> >> We also have 'df' where 'df -W' prints the original symbolic path
> >> (but just for NAME=) because a resolved symbol path cannot be
> >> reversed.
>
> >'df -W' just uses getmntinfo() and mount(8) only calls getfss
rein...@dropje.13thmonkey.org (Reinoud Zandijk) writes:
>> We have 'fsck' which resolves the device name and 'fsck_*' that gets passed
>> the resolved name.
>If they were never intended to be used separately then shouldn't they be in
>libexec?
Well, that's history for you :)
>> We also have 'd
Hi Michael,
On Fri, Jun 21, 2024 at 05:50:56AM -, Michael van Elst wrote:
> rein...@netbsd.org (Reinoud Zandijk) writes:
>
> > int getdiskinfo(const char *s, int fd, const char *dt, struct disk_geom
> > *geo,
> > struct dkwedge_info *dkw);
> > int getdisksize(const char *name, u_int *s
Hi Michael, thanks for your feedback,
On Fri, Jun 21, 2024 at 06:24:53AM -, Michael van Elst wrote:
> rein...@netbsd.org (Reinoud Zandijk) writes:
>
> >that returns a canonical raw device name when passed a device name in one of
> >the following ways:
> > /dev/ld0
> > name="UUID"
> >
rein...@netbsd.org (Reinoud Zandijk) writes:
>that returns a canonical raw device name when passed a device name in one of
>the following ways:
> /dev/ld0
> name="UUID"
> name="ROOT.x"
> /dev/dk1
> /some/mountpoint
> some/file/name
That looks like many distinc
rein...@netbsd.org (Reinoud Zandijk) writes:
> int getdiskinfo(const char *s, int fd, const char *dt, struct disk_geom *geo,
> struct dkwedge_info *dkw);
> int getdisksize(const char *name, u_int *secsize, off_t *mediasize);
There are kernel functions of the same name:
int getdiskinfo(s
Dear folks,
i'd like to add the following files to libutil since they are referenced
multiple times all reaching over to fsck while they are not fsck specific.
sbin/fsck/partutil.h
sbin/fsck/partutil.c
which define the following functions:
struct dkwedge_info;
struct disk_geom;
int g
Dear folks,
I'd like to add a function implementing fsck/fsutil.c's blockcheck()
char *blockcheck(const char *origname);
as
char *canonical_rdev(char *buf, size_t buflen, const char *origname,
int *flags);
that returns a canonical raw device name when passed a device nam
There has been a bunch of discussion in various places, most
recently as part of the PR xsrc/54851 about (amongst various
other things) adding a -l option to sh.
The option exists in many other shells - its purpose is to make
the shell into a login shell (and hence can also be written -o login
On Wed, May 19, 2021 at 08:58:42PM +0200, Joerg Sonnenberger wrote:
> On Wed, May 19, 2021 at 09:56:23AM +, nia wrote:
> > The current situation in pkgsrc (where lots of software using alloca
> > needs to be BUILDLINK_TRANSFORMED to use the -std=gnu... variant, or
> > is patched to use the buil
On Wed, May 19, 2021 at 09:56:23AM +, nia wrote:
> The current situation in pkgsrc (where lots of software using alloca
> needs to be BUILDLINK_TRANSFORMED to use the -std=gnu... variant, or
> is patched to use the builtin directly) is not really one I'm happy
> with.
For most software it is e
> If some software expects an but the base OS does not
> provide it, then is it more useful to have a devel/alloca package
> which can be buildlinked which would provide it?
I'm not sure whether that can be done even in principle. I don't
really understand alloca all that well, but my impression
lloca
> needs to be BUILDLINK_TRANSFORMED to use the -std=gnu... variant, or
> is patched to use the builtin directly) is not really one I'm happy
> with.
pkgsrc is used on more than just NetBSD; adding the file to NetBSD does
not help on other operating systems..
iain
I think there's several points of view:
1) Everything using alloca() is broken (valid, it's a nasty function)
2) Everything using extensions should properly declare it does so
(using eg. -std=gnu99 and so on), and not use standards mode.
2) Software that makes certain assumptions about almos
Date:Thu, 13 May 2021 16:00:56 -0700
From:John Nemeth
Message-ID: <202105132300.14dn0uwz026...@server.cornerstoneservice.ca>
| On May 13, 22:37, Joerg Sonnenberger wrote:
| } The source is wrong to request strict C++14
| } compatibility and then use an extension
On May 13, 22:37, Joerg Sonnenberger wrote:
} On Thu, May 13, 2021 at 09:58:50PM +0200, JaromÃr DoleÄek wrote:
} > Le jeu. 13 mai 2021 à 21:44, Joerg Sonnenberger a écrit :
} > > > No we don't, unless you are using PCC :D
} > > >
} > > > The block in only provides an alloca(3) prototype, and
On Thu, May 13, 2021 at 09:58:50PM +0200, Jaromír Doleček wrote:
> Le jeu. 13 mai 2021 à 21:44, Joerg Sonnenberger a écrit :
> > > No we don't, unless you are using PCC :D
> > >
> > > The block in only provides an alloca(3) prototype, and only
> > > if the compiler already #defines alloca as __bu
Le jeu. 13 mai 2021 à 21:44, Joerg Sonnenberger a écrit :
> > No we don't, unless you are using PCC :D
> >
> > The block in only provides an alloca(3) prototype, and only
> > if the compiler already #defines alloca as __builtin_alloca.
> >
> > While this works for gcc in some -std modes (e.g. gnu
gt; > > > > e.g. MySQL 8.0.* seems to rely on this.
> > > >
> > > > We provide it in stdlib.h as long as a standard mode is not set.
> > > > I don't see the point of adding alloca.h.
> > >
> > > We don't provide the builti
Le jeu. 13 mai 2021 à 12:58, Martin Husemann a écrit :
>
> On Thu, May 13, 2021 at 12:51:45PM +0200, Jaromír Dole?ek wrote:
> > On the contrary, Linux explicitely #undefs alloca(), then
> > #define alloca() as __builtin_alloca(), so it always works, regardless
> > which -std.
>
> But isn't that o
On Thu, May 13, 2021 at 12:51:45PM +0200, Jaromír Dole?ek wrote:
> On the contrary, Linux explicitely #undefs alloca(), then
> #define alloca() as __builtin_alloca(), so it always works, regardless
> which -std.
But isn't that obviously wrong and our version the correct one?
(Well, maybe we shoul
ote:
> > > > would it be a bad thing to add a compatibility which would
> > > > use the builtin alloca() instead of the libc one when available?
> > > >
> > > > e.g. MySQL 8.0.* seems to rely on this.
> > >
> > > We provide it i
> > use the builtin alloca() instead of the libc one when available?
> > >
> > > e.g. MySQL 8.0.* seems to rely on this.
> >
> > We provide it in stdlib.h as long as a standard mode is not set.
> > I don't see the point of adding alloca.h.
>
> We don't provide the builtin in stdlib.h.
Yes, we do.
Joerg
> e.g. MySQL 8.0.* seems to rely on this.
>
> We provide it in stdlib.h as long as a standard mode is not set.
> I don't see the point of adding alloca.h.
We don't provide the builtin in stdlib.h.
The definition in stdlib.h makes the app use the libc-provided
alloca(), which i
On Wed, 12 May 2021 08:38:39 +0200
Jaromír Doleček wrote:
> e.g. MySQL 8.0.* seems to rely on this.
>
> Jaromir
MySQL 8.0.* reports problems because they compile without extensions
using -std=c++14 , if they used -std=gnu++14 it would work.
Or the could use SET(CMAKE_CXX_STANDARD 14) and
SET(C
dard mode is not set.
I don't see the point of adding alloca.h.
Joerg
Hi,
would it be a bad thing to add a compatibility which would
use the builtin alloca() instead of the libc one when available?
e.g. MySQL 8.0.* seems to rely on this.
Jaromir
On 28.11.2018 18:25, Michał Górny wrote:
> arcn->sb.st_gid = (gid_t)asc_u32(hd->gid, sizeof(hd->gid), OCT);
> arcn->sb.st_size = (off_t)ASC_OFFT(hd->size, sizeof(hd->size), OCT);
> + if (arcn->sb.st_size == -1)
> + return -1;
> arcn->sb.st_mtime = (time_t)(int32_t)
On Wed, 2018-11-28 at 08:20 +0700, Robert Elz wrote:
> Date:Wed, 28 Nov 2018 00:23:47 +0100
> From:=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=
> Message-ID: <1543361027.17222.11.ca...@gentoo.org>
>
> I have no idea whether this is something that we want or not,
> but assuming
Date:Wed, 28 Nov 2018 00:23:47 +0100
From:=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=
Message-ID: <1543361027.17222.11.ca...@gentoo.org>
I have no idea whether this is something that we want or not,
but assuming that we do ...
| so I'd appreciate some pointers if I'm doing
the 'safer'
11-digit size (i.e. 8 GiB).
I think adding base-256 decoding support to pax is rather
straightforward, so I've went ahead and wrote a patch. It adds support
for reading archives using this extension (i.e. unpacking them). It's
my first real patch to NetBSD, so I
Is there any rule for what names get added to share/dict/propernames?
Would adding more names, even uncommon ones, be okay?
--
Eitan Adler
On Thu, Jul 06, 2017 at 06:24:07PM +0200, Jan Danielsson wrote:
>I don't know how complicated those web login-things generally are.
> The one at the university didn't require a session; one could just
> submit the form and it worked. If that's the norm, then it's pretty
> trivial to write a "w
On Thu, Jul 06, 2017 at 09:34:08PM +0530, Utkarsh Anand wrote:
> | for example people usally need $EDITOR other than vi/ed
>
> Has vi ever worked for anyone (in NetBSD)?
I don't use anything but NetBSD's vi (I even install it on linux)
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront t
| There is 'x' in vi(1) to delete a character.
Спасибо (Thanks)! That works!
Regards,
Utkarsh Anand
| for example people usally need $EDITOR other than vi/ed
Has vi ever worked for anyone (in NetBSD)? At least, for me, the backspace
and delete keys never work (this happens only with NetBSD). Would you
consider replacing it with nano?
Regards,
Utkarsh Anand
>
> Works just fine :-) I am typing on it right now. What does 'stty -a'
> say on your terminal?
speed 9600 baud; 67 rows; 240 columns; queue = 1024; line = termios;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
On Jul 6, 10:12pm, uanand...@gmail.com (Utkarsh Anand) wrote:
-- Subject: Re: adding stuff to the base installation to make user experience
| speed 9600 baud; 67 rows; 240 columns; queue = 1024; line = termios;
| lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
| -echoprt
On Thu, Jul 06, 2017 at 04:54:16PM +0100, Sevan Janiyan wrote:
> On 06/07/2017 16:52, Joerg Sonnenberger wrote:
> > On Thu, Jul 06, 2017 at 11:23:09AM -0400, Christos Zoulas wrote:
> >> 1. A text browser in base. "lynx" or "links" come to mind, I don't
> >>mind which, both are GPL2.
> > No. Ser
On 07/06/17 17:23, Christos Zoulas wrote:
[---]
> Alas, because of network policy on the wifi network, I needed to enter
> a code to access the network, and for that I needed a browser. We don't
> ship a browser in base.
>
>>From the looks of it, a text browser would suffice (and it did), so
> I d
On 06.07.2017 18:06, Christos Zoulas wrote:
> On Jul 6, 9:34pm, uanand...@gmail.com (Utkarsh Anand) wrote:
> -- Subject: Re: adding stuff to the base installation to make user experience
>
> | Has vi ever worked for anyone (in NetBSD)? At least, for me, the backspace
> | and de
On 6 July 2017 at 08:52, Joerg Sonnenberger wrote:
> On Thu, Jul 06, 2017 at 11:23:09AM -0400, Christos Zoulas wrote:
>> 1. A text browser in base. "lynx" or "links" come to mind, I don't
>>mind which, both are GPL2.
>
> No. Seriously, no.
Well, this is 2017, and not having any kind of browse
On Jul 6, 9:34pm, uanand...@gmail.com (Utkarsh Anand) wrote:
-- Subject: Re: adding stuff to the base installation to make user experience
| Has vi ever worked for anyone (in NetBSD)? At least, for me, the backspace
| and delete keys never work (this happens only with NetBSD). Would you
On 06/07/2017 16:52, Joerg Sonnenberger wrote:
> On Thu, Jul 06, 2017 at 11:23:09AM -0400, Christos Zoulas wrote:
>> 1. A text browser in base. "lynx" or "links" come to mind, I don't
>>mind which, both are GPL2.
> No. Seriously, no.
>
Could we ensure it's one of the available packages on the
anced libc with a new function.
My needs would would be satisfied if we could formalize and create a
build cluster with daily pkgsrc packages for the newest stable release
and/or -current. Hopefully for both. **
I don't like putting more stuff into the base distribution, it's already
f
ular NetBSD version,
>but that can be fixed. It surely beats running pkg-add "n" times to
>install firefox. Yes, it takes a single pkg_add to add it...
We already have enough fun with pkg_install in base. Adding more doesn't
help -- it's a huge maintainance pain. It also doesn't help at all
without (2).
Joerg
Hello,
Yesterday I installed netbsd-8 on an ancient dell latitude x1. For the
most part the installation went fine, and I booted to a working system,
with both X and networking working. NetBSD runs very nicely on it and
it is quite fast :-)
Alas, because of network policy on the wifi network, I
On Fri, Jan 27, 2017 at 05:08:58PM +, David Holland wrote:
> On Thu, Jan 26, 2017 at 02:53:45AM +, Roy Marples wrote:
> > As we don't ship a ftp user, why do we ship a very basic skeletion of a
> > classical ftp directory in /var/spool/ftp?
>
> I assume to allow turning it on easily
On Thu, Jan 26, 2017 at 02:53:45AM +, Roy Marples wrote:
> As we don't ship a ftp user, why do we ship a very basic skeletion of a
> classical ftp directory in /var/spool/ftp?
I assume to allow turning it on easily?
> IMHO we should either punt the directory from the base install OR add an
user to
complete the easy setup of anon FTP server. Any objections to me adding
this?
Since decades, "enabling ftpd" in /etc/inetd.conf means "enabling
it for real users only". Enabling anonymous ftp is an additional,
simple, well-documented step which needs to be conscious
the easy setup of anon FTP server. Any objections to me adding
> this?
Since decades, "enabling ftpd" in /etc/inetd.conf means "enabling
it for real users only". Enabling anonymous ftp is an additional,
simple, well-documented step which needs to be consciously done
by the
to supply a FTP user to
complete the easy setup of anon FTP server. Any objections to me adding
this?
Roy
52 matches
Mail list logo
