disable the ability to change tun(4) mode from p2p to bcast and back again
Currently you can change a tun interface from being point to point to
being a broadcast interface. Why?
This cuts out the ability to change it. Note that the ioctl code is
shared by tap, so it still has IFF_BROADCAST code that gets run, you
should just not be able to change the flags, only read them.
With the above in mind, this also removes the ability to make a tap
interface point to point. Why would you want that too?
This was noticed by tedu while playing with wg, and it confused me. But
that is true for a lot of tap stuff atm. Does anyone really use all the
ioctl buttons that tap provides?
ok?
Index: if_tun.c
===
RCS file: /cvs/src/sys/net/if_tun.c,v
retrieving revision 1.184
diff -u -p -r1.184 if_tun.c
--- if_tun.c3 Feb 2019 23:04:49 - 1.184
+++ if_tun.c4 Feb 2019 02:00:14 -
@@ -104,7 +104,7 @@ int tundebug = TUN_DEBUG;
#endif
/* Only these IFF flags are changeable by TUNSIFINFO */
-#define TUN_IFF_FLAGS (IFF_UP|IFF_POINTOPOINT|IFF_MULTICAST|IFF_BROADCAST)
+#define TUN_IFF_FLAGS (IFF_UP)
void tunattach(int);
@@ -650,15 +650,9 @@ tun_dev_ioctl(struct tun_softc *tp, u_lo
break;
#endif
case TUNSIFMODE:
- switch (*(int *)data & (IFF_POINTOPOINT|IFF_BROADCAST)) {
- case IFF_POINTOPOINT:
- case IFF_BROADCAST:
- tp->tun_if.if_flags &= ~TUN_IFF_FLAGS;
- tp->tun_if.if_flags |= *(int *)data & TUN_IFF_FLAGS;
- break;
- default:
+ if ((*(int *)data & (IFF_POINTOPOINT|IFF_BROADCAST)) !=
+ (tp->tun_if.if_flags & (IFF_POINTOPOINT|IFF_BROADCAST)))
return (EINVAL);
- }
break;
case FIONBIO:
avoid byteswapping at runtime in tun(4)
this has reads from tun load the AF out of the data rather than point to
it, then has the switch statement compare to the swapped AF values.
ok?
Index: if_tun.c
===
RCS file: /cvs/src/sys/net/if_tun.c,v
retrieving revision 1.184
diff -u -p -r1.184 if_tun.c
--- if_tun.c3 Feb 2019 23:04:49 - 1.184
+++ if_tun.c4 Feb 2019 00:18:54 -
@@ -833,7 +833,7 @@ int
tun_dev_write(struct tun_softc *tp, struct uio *uio, int ioflag)
{
struct ifnet*ifp;
- u_int32_t *th;
+ u_int32_t th;
struct mbuf *top, **mp, *m;
int error = 0, tlen;
size_t mlen;
@@ -842,7 +842,7 @@ tun_dev_write(struct tun_softc *tp, stru
TUNDEBUG(("%s: tunwrite\n", ifp->if_xname));
if (uio->uio_resid == 0 || uio->uio_resid > ifp->if_mtu +
- (tp->tun_flags & TUN_LAYER2 ? ETHER_HDR_LEN : sizeof(*th))) {
+ (tp->tun_flags & TUN_LAYER2 ? ETHER_HDR_LEN : sizeof(th))) {
TUNDEBUG(("%s: len=%d!\n", ifp->if_xname, uio->uio_resid));
return (EMSGSIZE);
}
@@ -917,11 +917,11 @@ tun_dev_write(struct tun_softc *tp, stru
}
#endif
- th = mtod(top, u_int32_t *);
+ th = *mtod(top, u_int32_t *);
/* strip the tunnel header */
- top->m_data += sizeof(*th);
- top->m_len -= sizeof(*th);
- top->m_pkthdr.len -= sizeof(*th);
+ top->m_data += sizeof(th);
+ top->m_len -= sizeof(th);
+ top->m_pkthdr.len -= sizeof(th);
top->m_pkthdr.ph_rtableid = ifp->if_rdomain;
top->m_pkthdr.ph_ifidx = ifp->if_index;
@@ -930,17 +930,17 @@ tun_dev_write(struct tun_softc *tp, stru
NET_LOCK();
- switch (ntohl(*th)) {
- case AF_INET:
+ switch (th) {
+ case htonl(AF_INET):
ipv4_input(ifp, top);
break;
#ifdef INET6
- case AF_INET6:
+ case htonl(AF_INET6):
ipv6_input(ifp, top);
break;
#endif
#ifdef MPLS
- case AF_MPLS:
+ case htonl(AF_MPLS):
mpls_input(ifp, top);
break;
#endif
Re: [PATCH] portgen(1) man page: Add py type
I asked tsg about this before, IIRC it was intentionally omitted as it
wasn't considered finished. (For starters it could do with some plist smarts).
--
Sent from a phone, apologies for poor formatting.
On 3 February 2019 21:22:58 Linda Lapinlampi wrote:
/usr/ports/infrastructure/bin/portgen supports "py" type, as seen in the
source code:
if ( $type eq 'p5' ) {
$o = OpenBSD::PortGen::Port::CPAN->new();
} elsif ( $type eq 'py' ) {
$o = OpenBSD::PortGen::Port::PyPI->new();
} elsif ( $type eq 'ruby' ) {
$o = OpenBSD::PortGen::Port::Ruby->new();
} else {
die "unknown module type\n";
}
This "py" type also works to generate ports from PyPI sources, mostly.
It's not documented in the man page though.
Attached diff adds a mention of the type to portgen(1) man page.
[PATCH] portgen(1) man page: Add py type
/usr/ports/infrastructure/bin/portgen supports "py" type, as seen in the
source code:
if ( $type eq 'p5' ) {
$o = OpenBSD::PortGen::Port::CPAN->new();
} elsif ( $type eq 'py' ) {
$o = OpenBSD::PortGen::Port::PyPI->new();
} elsif ( $type eq 'ruby' ) {
$o = OpenBSD::PortGen::Port::Ruby->new();
} else {
die "unknown module type\n";
}
This "py" type also works to generate ports from PyPI sources, mostly.
It's not documented in the man page though.
Attached diff adds a mention of the type to portgen(1) man page.
Index: portgen.1
===
RCS file: /cvs/src/share/man/man1/portgen.1,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 portgen.1
--- portgen.1 26 Jun 2018 05:38:49 - 1.1
+++ portgen.1 3 Feb 2019 21:15:33 -
@@ -50,6 +50,8 @@ values:
.Bl -inset -offset indent -compact
.It Cm p5
for Perl modules on CPAN.
+.It Cm py
+for Python modules on PyPI.
.It Cm ruby
for Ruby gems.
.El
Re: Update perl to 5.28.1
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 of time and now I have to go visit
> > family for the holidays so it's up to y'all to do some testing for me.
> >
> >
> > The infrastructure to do that is still here on github, including
> > instructions on using it:
> >
> > https://github.com/afresh1/OpenBSD-perl/
> >
> >
> >
> > You can also download a pre-patched perl from here, use it to replace
> > src/gnu/usr.bin/perl and do a normal build to get it installed, do note
> > that any XS modules that were built with the old version of perl will no
> > longer work, so be careful.
> >
> > http://cvs.afresh1.com/~andrew/OpenBSD-perl-5.28.1.tar.gz
> >
> >
> > You can read more on the new features and changes on the metacpan.
> >
> > https://metacpan.org/release/SHAY/perl-5.28.1
> >
> > You find them in the perldelta for the versions since 5.24.
> >
> > https://metacpan.org/pod/release/SHAY/perl-5.28.1/pod/perl5260delta.pod
> > https://metacpan.org/pod/release/SHAY/perl-5.28.1/pod/perl5280delta.pod
> > https://metacpan.org/pod/release/SHAY/perl-5.28.1/pod/perldelta.pod
> >
> >
> > One of the important changes, and the one most likely to cause trouble
> > is the removal of "." from the @INC library search list.
>
> Having fixed a bunch of these, and cwen@ fixing a bunch more, and still
> having 100-odd ports failing to build, I have come round to the idea of
> setting PERL_USE_UNSAFE_INC instead. I wasn't super happy about this but
> the upstream cpan tool seems resigned to doing this for now so we might
> as well follow suit.
>
> It seems sanest to set this in cpan.port.mk rather than individual Makefiles:
>
> Index: cpan.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/cpan.port.mk,v
> retrieving revision 1.20
> diff -u -p -r1.20 cpan.port.mk
> --- cpan.port.mk 20 Mar 2016 19:56:44 - 1.20
> +++ cpan.port.mk 3 Feb 2019 14:10:27 -
> @@ -24,6 +24,11 @@ TEST_DEPENDS +=devel/p5-Test-Pod \
> devel/p5-Test-Pod-Coverage
> .endif
>
> +# perl 5.26+ no longer has "." in @INC by default, but it's widely required
> in
> +# build/test systems. set it locally, as is also done in the upstream cpan
> tool.
> +CONFIGURE_ENV += PERL_USE_UNSAFE_INC=1
> +TEST_ENV += PERL_USE_UNSAFE_INC=1
> +
> MODCPAN_POST_INSTALL = ${INSTALL_DATA_DIR} ${MODCPAN_EXAMPLES_DIR}; \
> cd ${WRKSRC}/${MODCPAN_EXAMPLES_DIST}/ && pax -rw .
> ${MODCPAN_EXAMPLES_DIR};\
> chown -R ${SHAREOWN}:${SHAREGRP} ${MODCPAN_EXAMPLES_DIR}
>
>
> Applying that diff fixes 80+. Any major concerns about doing that
> (especially espie@, afresh1@)? It hasn't been through a full build
> (I added it after a run to mop up breakage) but I can do that.
No, I think it's sane to do that. Let cpan mop up most of the breakage,
then we'll remove that.
Re: fts and unveil issue
yes you are seeing the limitation of 6.4 unveil as mentioned at the bottom
of the man page. this should be fixed in current
On Sun, Feb 3, 2019 at 03:29 Kristaps Dzonsons wrote:
> When I unveil(2), fts doesn't behave well. But only in a subtle way.
> Enclosed is a demonstration. I found this with openrsync, which unveils
> before using fts_open to scan for files.
>
> When run with a directory with only empty subdirectories or just files,
> this works fine. But when run with a directory that contains other
> non-empty directories, the fts_read fails in the nested directories.
>
> This is on stock OpenBSD 6.4, syspatched, amd64.
>
> For example, consider the following abridged output (to fit into this
> e-mail window):
>
> % find ~/tmp/test -ls
> drwxr-xr-x3 /home/kristaps/tmp/test
> drwxr-xr-x3 /home/kristaps/tmp/test/test2
> -rw-r--r--1 /home/kristaps/tmp/test/test2/test2
> drwxr-xr-x2 /home/kristaps/tmp/test/test2/test3
> -rw-r--r--1 /home/kristaps/tmp/test/test1
> % gcc -W -Wall -Wextra -g foo.c
> % ./a.out /home/kristaps/tmp/test/
> a.out: /home/kristaps/tmp/test/
> a.out: /home/kristaps/tmp/test/test2
> a.out: /home/kristaps/tmp/test/test2/test2
> a.out: /home/kristaps/tmp/test/test2/test3
> a.out: /home/kristaps/tmp/test/test2/test3
> a.out: /home/kristaps/tmp/test/test2
> a.out: /home/kristaps/tmp/test/test1
> a.out: /home/kristaps/tmp/test/
> a.out: TRYING AGAIN.
> a.out: /home/kristaps/tmp/test/
> a.out: /home/kristaps/tmp/test/test2
> a.out: /home/kristaps/tmp/test/test2/test2: no stat
> a.out: ...but regular stat works
>
> So the first nested child fails (regardless of whether it's a file or
> directory, by the way). But a regular stat still works.
>
> The same happens if I use unveil("/", "r").
>
Re: Update perl to 5.28.1
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 of time and now I have to go visit
> family for the holidays so it's up to y'all to do some testing for me.
>
>
> The infrastructure to do that is still here on github, including
> instructions on using it:
>
> https://github.com/afresh1/OpenBSD-perl/
>
>
>
> You can also download a pre-patched perl from here, use it to replace
> src/gnu/usr.bin/perl and do a normal build to get it installed, do note
> that any XS modules that were built with the old version of perl will no
> longer work, so be careful.
>
> http://cvs.afresh1.com/~andrew/OpenBSD-perl-5.28.1.tar.gz
>
>
> You can read more on the new features and changes on the metacpan.
>
> https://metacpan.org/release/SHAY/perl-5.28.1
>
> You find them in the perldelta for the versions since 5.24.
>
> https://metacpan.org/pod/release/SHAY/perl-5.28.1/pod/perl5260delta.pod
> https://metacpan.org/pod/release/SHAY/perl-5.28.1/pod/perl5280delta.pod
> https://metacpan.org/pod/release/SHAY/perl-5.28.1/pod/perldelta.pod
>
>
> One of the important changes, and the one most likely to cause trouble
> is the removal of "." from the @INC library search list.
Having fixed a bunch of these, and cwen@ fixing a bunch more, and still
having 100-odd ports failing to build, I have come round to the idea of
setting PERL_USE_UNSAFE_INC instead. I wasn't super happy about this but
the upstream cpan tool seems resigned to doing this for now so we might
as well follow suit.
It seems sanest to set this in cpan.port.mk rather than individual Makefiles:
Index: cpan.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/cpan.port.mk,v
retrieving revision 1.20
diff -u -p -r1.20 cpan.port.mk
--- cpan.port.mk20 Mar 2016 19:56:44 - 1.20
+++ cpan.port.mk3 Feb 2019 14:10:27 -
@@ -24,6 +24,11 @@ TEST_DEPENDS += devel/p5-Test-Pod \
devel/p5-Test-Pod-Coverage
.endif
+# perl 5.26+ no longer has "." in @INC by default, but it's widely required in
+# build/test systems. set it locally, as is also done in the upstream cpan
tool.
+CONFIGURE_ENV += PERL_USE_UNSAFE_INC=1
+TEST_ENV += PERL_USE_UNSAFE_INC=1
+
MODCPAN_POST_INSTALL = ${INSTALL_DATA_DIR} ${MODCPAN_EXAMPLES_DIR}; \
cd ${WRKSRC}/${MODCPAN_EXAMPLES_DIST}/ && pax -rw .
${MODCPAN_EXAMPLES_DIR};\
chown -R ${SHAREOWN}:${SHAREGRP} ${MODCPAN_EXAMPLES_DIR}
Applying that diff fixes 80+. Any major concerns about doing that
(especially espie@, afresh1@)? It hasn't been through a full build
(I added it after a run to mop up breakage) but I can do that.
The remaining broken ports after that are:
devel/p5-PerlIO-via-Timeout
games/zangband, security/steghide, x11/xtraceroute (via autoconf autom4te)
misc/cbb
net/p5-Net-FTPServer
security/p5-Crypt-Twofish
sysutils/p5-Sys-Virt
www/ap2-mod_perl
www/p5-HTML-FormatText-WithLinks-AndTables
Re: sparc64 exception handling fix
> Date: Sat, 2 Feb 2019 17:19:07 +0100 (CET)
> From: Mark Kettenis
>
> On SPARC the address of the call instruction is placed in %o7 and a
> normal function return will jump to %o7 + 8, skipping the delay slot.
> The diff below changes the low-level libunwind code to take this into
> account. This way the addresses seen by the unwinder are as expected
> and the unwinder can find the correct information in the various
> tables.
>
> ok?
Ugh, I botched that one at the last minute. And didn't notice because
I ran the regression tests without CXX=clang++ :(.
So the situation is a bit more complicated. On SPARC, DWARF2 uses
register 15 (which maps to %o7) as the return address "column". This
means that what DWARF2 calls the return address is actually what is
stored in %o7 and therefore off by two instructions. When the
unwinders processes DWARF2 "instructions" to update the register state
we must therefore set %o7 directly and not substract 8 from the passed
value.
The higher-level unwinding code needs to see the true return address
though. Luckily the DWARF2 parsing code uses a different interface,
se we can achieve this.
The DWARF2 parsing code uses setIP(), so the diff below changes that
function to remove the minus 8 I added in the previous diff. I also
changed getIP() back to what it was, even though that interface isn't
actually used in the code.
ok?
Index: lib/libunwind/src/Registers.hpp
===
RCS file: /cvs/src/lib/libunwind/src/Registers.hpp,v
retrieving revision 1.5
diff -u -p -r1.5 Registers.hpp
--- lib/libunwind/src/Registers.hpp 3 Feb 2019 12:30:02 - 1.5
+++ lib/libunwind/src/Registers.hpp 3 Feb 2019 13:42:15 -
@@ -2648,8 +2648,8 @@ public:
uint64_t getSP() const { return _registers.__o[6] + 2047; }
void setSP(uint64_t value) { _registers.__o[6] = value - 2047; }
- uint64_t getIP() const { return _registers.__o[7] + 8; }
- void setIP(uint64_t value) { _registers.__o[7] = value - 8; }
+ uint64_t getIP() const { return _registers.__o[7]; }
+ void setIP(uint64_t value) { _registers.__o[7] = value; }
uint64_t getWCookie() const{ return _wcookie; }
private:
Re: games/fortune translation fix
Hi Pascal, Pascal Stumpf wrote on Sun, Feb 03, 2019 at 11:13:12AM +0100: > That is not correct because [...] Which illustrates yet again that getting good grades at school doesn't imply real understanding; i dared to try and research the matter anyway because i forgot that with pascal@, we have somebody in our group who really understands classical languages and literature. Thanks for your insight, Pascal. >> So if you want to keep the entry, i'd recommend >> >> Per aspera ad astra. (Through hardship to immortality.) > ok pascal@ Committed. Ingo
fts and unveil issue
When I unveil(2), fts doesn't behave well. But only in a subtle way.
Enclosed is a demonstration. I found this with openrsync, which unveils
before using fts_open to scan for files.
When run with a directory with only empty subdirectories or just files,
this works fine. But when run with a directory that contains other
non-empty directories, the fts_read fails in the nested directories.
This is on stock OpenBSD 6.4, syspatched, amd64.
For example, consider the following abridged output (to fit into this
e-mail window):
% find ~/tmp/test -ls
drwxr-xr-x3 /home/kristaps/tmp/test
drwxr-xr-x3 /home/kristaps/tmp/test/test2
-rw-r--r--1 /home/kristaps/tmp/test/test2/test2
drwxr-xr-x2 /home/kristaps/tmp/test/test2/test3
-rw-r--r--1 /home/kristaps/tmp/test/test1
% gcc -W -Wall -Wextra -g foo.c
% ./a.out /home/kristaps/tmp/test/
a.out: /home/kristaps/tmp/test/
a.out: /home/kristaps/tmp/test/test2
a.out: /home/kristaps/tmp/test/test2/test2
a.out: /home/kristaps/tmp/test/test2/test3
a.out: /home/kristaps/tmp/test/test2/test3
a.out: /home/kristaps/tmp/test/test2
a.out: /home/kristaps/tmp/test/test1
a.out: /home/kristaps/tmp/test/
a.out: TRYING AGAIN.
a.out: /home/kristaps/tmp/test/
a.out: /home/kristaps/tmp/test/test2
a.out: /home/kristaps/tmp/test/test2/test2: no stat
a.out: ...but regular stat works
So the first nested child fails (regardless of whether it's a file or
directory, by the way). But a regular stat still works.
The same happens if I use unveil("/", "r").
#include
#include
#include
#include
#include
#include
#include
int
main(int argc, char *argv[])
{
char *root[2];
struct stat st;
FTS *fts;
FTSENT *ent;
if (2 != argc)
return EXIT_FAILURE;
root[0] = argv[1];
root[1] = NULL;
if (-1 == lstat(root[0], ))
err(EXIT_FAILURE, "%s", root[0]);
else if ( ! S_ISDIR(st.st_mode))
errx(EXIT_FAILURE, "%s: not a directory", root[0]);
fts = fts_open(root, FTS_PHYSICAL, NULL);
if (NULL == fts)
err(EXIT_FAILURE, "%s: fts_open", root[0]);
while (NULL != (ent = fts_read(fts))) {
if (FTS_NS == ent->fts_info) {
errno = ent->fts_errno;
err(EXIT_FAILURE, "%s: no stat", ent->fts_path);
}
warnx("%s", ent->fts_path);
errno = 0;
}
if (NULL != ent)
err(EXIT_FAILURE, "%s: fts_read", root[0]);
fts_close(fts);
warnx("TRYING AGAIN.");
if (-1 == unveil(root[0], "r"))
err(EXIT_FAILURE, "%s: unveil", root[0]);
fts = fts_open(root, FTS_PHYSICAL, NULL);
if (NULL == fts)
err(EXIT_FAILURE, "%s: fts_open", root[0]);
while (NULL != (ent = fts_read(fts))) {
if (FTS_NS == ent->fts_info) {
errno = ent->fts_errno;
warnx("%s: no stat", ent->fts_path);
if (-1 == lstat(ent->fts_path, ))
errx(EXIT_FAILURE, "%s: really no stat", ent->fts_path);
errx(EXIT_FAILURE, "...but regular stat works: %s", ent->fts_path);
}
warnx("%s", ent->fts_path);
errno = 0;
}
if (NULL != ent)
err(EXIT_FAILURE, "%s: fts_read", root[0]);
fts_close(fts);
return EXIT_SUCCESS;
}
Re: games/fortune translation fix
Hi Ingo and Jason, On Sun, 3 Feb 2019 01:13:18 +0100, Ingo Schwarze wrote: > Hi Jason, > > oh well, these files are a mess, a random collection of funny > and not so funny stuff... I dislike this one, too, for several > reasons. > > 1. While "ad astra per aspera" sometimes occurs, the word order > "per aspera ad astra" is much more commonly used. It sounds > much better - not only because it respects the logical > chronological order, but even more so for metric reasons: > "per aspera ad astra" follows a loosely trochaic rhythm > " - | X- (x)-X- " while"ad astra per aspera" has no > discernible metric whatsoever: " - | X- | - X-- ". That is not correct because it ignores the fact that Latin employs a quantifying metre, determined by long and short syllables, not word accent. So: per aspera ad astra: v - v v - x (with elision between "aspera ad") ad astra per aspera: v - v v - v x So the word order "per aspera ad astra" clearly fits nicely at the end of a dactylic catalectic hexameter, the common metre employed for epic poetry ( – vv – vv – vv – vv – vv – x). However, I am not aware of any poetic work using the phrase in this metrical position. > 2. It doesn't actually appear to be an antique or even medieval > latin proverb but merely a modern invention. Correct. My Latin corpus (PHI) has 0 occurrences of the phrase. However, a verse from Seneca's Hercules Furens is often quoted as an antique source: Non est ad astra mollis e terris uia. (Sen. HF 437) > 3. According to my latin dictionary, "ad astra" did occur in > antiquity, in a strongly metaphoric sense where "astra = heaven, > immortality, sphere and home of the gods" rather than "stars" - > though the only source cited there is Vergilius, Aeneis: > Macte nova virtute, puer, sic itur ad astra. > literal (hence somewhat misleading) translation: > Blessings on your young courage, boy; that's the way to the stars. > free translation, capturing the meaning and register better: > Go on and increase in valor, O boy! this is the path to immortality. > See e.g. https://en.wikiquote.org/wiki/Aeneid > Seneca also appears to use it in the context of a demi-god > (Hercules) interacting with the Olympians. > > So "ad astra" appears to be a rather unsual phrase, highly poetic, > suited to heroic legends about gods and super-human men interacting > directly with the greatest gods. Agree on the meaning, but it is far from unusual, albeit quite poetic, yes. It is an expression used almost exclusively in Augustan poetry (Virgil, Horace, Ovid ...) with the connotation of "to the gods". To add to the list: Ov. M. 9, 272 and 15, 846; Verg. E. 5, 51f; Hor. C. 4, 2, 23; Hor. S. 2, 7, 29; Cic. Att. 2, 25, 1. > 4. According to my latin dictionary, "asper" is a very common > adjective with a wide range of everyday concrete meanings: > rough, uneven, sharp, coarse, gruff, wild, disagreeable, > sorrowful, severe, rancorous, ... and more. > It was sometimes - but much less commonly, it appears - > used as a noun, though usually with a qualification in the > genitive, e.g. "aspera maris" = tempests (Tacitus). > When used alone as a noun, it appears to have a relatively > narrow, figurative, relatively mild meaning of "tribulations, > annoying trouble, misfortune"; translations like "hardship" or > "adversity" appear to exceed the severity of "asper(a)", > making it sound too much like serious emergency and distress. Not necessarily. Even in the Tacitus case you cited I'd probably argue for the narrow meaning of "uneven, rugged place", describing the sea's surface during a storm. Whether the adjective has a more literal or more figurative meaning seems to depend not on whether it is used as a noun, but on context. But since "astra" already works in a metaphoric register, your conclusion is correct. > So a fitting translation of "per aspera ad astra", approximating > the meaning and stylistic register of both parts, might be > > "overcoming annoying problems to be elevated immortality" > > which sounds, yes, ridiculous. > > The word "aspiration" is definitely a blatant mistranslation. Yes. > So if you want to keep the entry, i'd recommend > > Per aspera ad astra. (Through hardship to immortality.) ok pascal@ > because that is probably how it is commonly understood today, with > a weakened sense of "immortality" = "greatness, being remembered > for one's achievements after death", and it is also a compromise > not too far deviating from the actual meaning of the latin words, > even if sharpening "aspera" a bit and weakening "astra" somewhat > to smooth out content and and stylistic register. > > I think while the literal translation "to the stars" might work in > a heroic legend, it is quite misleading out of context and ought > to be fixed. > > Yours, > Ingo > > P.S. > I don't know why
