[gentoo-user] Re: mutt, with USE="gpg", can't open a signed message

[Ian Zimmerman]

On 2018-04-24 21:13, Walter Dnes wrote:

> "$(use_enable gpg gpgme)"

"gpgme" above is _not_ a USE flag.  That incantation tells portage to
pass "--enable-gpgme" to the upstream package configure script if "gpg"
USE flag is set in gentoo.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] mutt, with USE="gpg", can't open a signed message

[Walter Dnes]

On Fri, Apr 20, 2018 at 08:15:00PM +0100, Mick wrote

> Some of the mutt USE flags changed recently.  I seem to recall
> some elog/ewarn message on this.  Instead of USE=gpg and USE=smime,
> try USE=gpgme instead and then add:
> 
> 'set crypt_use_gpgme=yes'
> 
> in your /$HOME/.muttrc.

  Thanks for the hints. I finally got it working.  In package.use I have...

mail-client/mutt gpg gpgme mbox pop smtp -smime

  "Interesting" item... "emerge -pv mutt" gives me...

[ebuild   R] mail-client/mutt-1.7.2::gentoo  USE="gpg mbox pop smtp ssl 
-berkdb -crypt -debug -doc -gdbm (-gnutls) -idn -imap -kerberos -libressl -nls 
-nntp -notmuch -qdbm -sasl (-selinux) -sidebar -slang -smime -tokyocabinet 
-vanilla"

  There is no mention of "gpgme" in the output... but... mutt-1.7.2.ebuild
contains...

==
* In CDEPEND
gpg? ( >=app-crypt/gpgme-0.9.0:= )
==

==
* In src_configure() {
 local myconf=(

"$(use_enable gpg gpgme)"
==

  The CDEPEND I can understand.  The second item is a puzzler.  How are
we supposed to know about the "gpgme" flag, if it doesn't show up under
"emerge -pv".  By the way, my mutt config is in $HOME/.mutt/muttrc

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Is running Tor hidden services on VPS a good idea?

[R0b0t1]

On Tue, Apr 24, 2018 at 2:10 PM, Hubert Hauser  wrote:
> I want to run a few Tor hidden services. My home network is behind a
> carrier gateway NAT so I can't make server from Raspberry Pi. I consider
> run Tor hidden services on VPS. What do you think about it? Is cgNAT
> obstacle if I want to run Tor hidden services?
>

A hidden service listens to connections from a Tor daemon. The
recommended setup has both on the same machine, so the web service is
only accepting connections from the machine it is run on. It does not
need to be outwardly accessible.

Tor will work even if you are behind NAT, assuming you do not run it
in a mode where it accepts Tor to Tor connections or Internet to Tor
connections.


Running a hidden service on a VPS, assuming you are not breaking the
laws in your jurisdiction, is likely the better idea. It will have
higher bandwidth and if an attacker succeeds in resolving its location
(which is possible to do and rather easy) they will get a datacenter,
not your neighborhood.

If you are breaking laws in your jurisdiction of residence I would
highly recommend moving. Whether or not it is a better idea to
self-host in this case is a tossup. On one hand, if you self-host and
the authorities resolve your hidden service's location, they get you,
but you may have a chance to destroy evidence. On the other hand, if
you VPS-host and the authorities resolve your hidden service's
location, they may subpoena the datacenter and get your details and
also the information on the server.

Cheers,
 R0b0t1

[gentoo-user] Is running Tor hidden services on VPS a good idea?

[Hubert Hauser]

I want to run a few Tor hidden services. My home network is behind a
carrier gateway NAT so I can't make server from Raspberry Pi. I consider
run Tor hidden services on VPS. What do you think about it? Is cgNAT
obstacle if I want to run Tor hidden services?

[gentoo-user] Re: Can't fetch distfiles in chroot

[Walter Dnes]

On Tue, Apr 24, 2018 at 09:40:52AM +0100, Peter Humphrey wrote
> 
> Anyway, this all leaves unanswered the question whether getting the
> -march setting right in a chroot matters to the operation of the
> chroot itself, as distinct from building good code for the target
> machine. Personally, I can't see how it can have any such effect.

  "-march" obviously has to match the target machine that the compiled
code will run on.  You have to run the query...

gcc -c -Q -march=native --help=target | grep march=

...on the "target machine" to get the necessary value.  That's true,
regardless of whether the "target machine" is physical hardware, or a
chroot, or a VM like QEMU/VMWare/etc.  Things can get ugly in some edge
cases if the final code (-march=) cannot run in the
build environment (-march=).

1) Tests run at the end of the build, on the build machine, will obviously
fail.

2) Pale Moon (and I assume Firefox as well) use the compiled code at the
end of the build process to generate a precompiled startup cache.  I ran
into this when I was manually building Pale Moon, targetted for my Atom
netbook, using my Core2 desktop as the build machine.  The "bonnell" cpu
(ancient 32-bit-only Atom variant) has an instruction set called "MOVBE"
that the Core 2 does not.  Hence, the bonnell-targeted code would fail
on the Core2 with "illegal instruction" and other weird errors.  This
will also happen building for an AMD (with "3DNOW!" instructions) on an
intel CPU.  That's "solved" by adding...

ac_add_options --disable-precompiled-startupcache

...to the mozconfig, preventing execution of that code in the build
environment.  The side effect is that the first time a profile is opened
after an install or upgrade on an end-user machine, it takes somewhat
longer, because it has execute the compiled code on the end-user machine
to generate the cache.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Can't fetch distfiles in chroot

[Peter Humphrey]

On Sunday, 22 April 2018 06:13:30 BST Peter Humphrey wrote:
> I've been NFS-exporting the portage treee from a 32-bit atom box to a chroot
> on my workstation, and it's worked well for years, if slowly.
> 
> Now when I try to do the same with a 64-bit celeron machine I'm having a
> problem getting portage to work. If the required distfile is already
> present, no problem, but otherwise, trying to fetch it just hangs. No
> errors, no status, no fetch log, no progress.
> 
> Www-client/links works in the chroot as expected, so the network is set up
> all right; portage just can't use it.
> 
> I've compared /etc/exports on the two clients; also the chroot setup
> scripts, /usr/portage permissions, the USE flags of nfs-utils and
> everything else I can think of. All identical apart from obvious things
> like 32/64 bits and network names and IPs. Google hasn't helped either.
> 
> Any ideas, anyone?

Never mind. I've rebuilt the chroot from stage 3 and it seems to be working 
fine. I only asked in the hope of not having to do that. But then, it didn't 
take too long really. Hey-ho.

-- 
Regards,
Peter.

Re: [gentoo-user] Re: Can't fetch distfiles in chroot

[Peter Humphrey]

On Monday, 23 April 2018 18:53:09 BST Walter Dnes wrote:

>   https://en.wikipedia.org/wiki/Celeron
> 
> > Celeron is a brand name given by Intel to a number of different
> > low-end IA-32 and x86-64 computer microprocessor models targeted
> > at budget personal computers.
> 
>   Looking at that page, "Celeron" can be a cheap, low end version any
> one of a whole slew of Intel CPUs.  You have to check the cpu to get the
> exact model that it's the low end version of.

..and it doesn't even mention silvermont. The page is 15 months old since its 
last update, which is about the same age as the box in question.

Anyway, this all leaves unanswered the question whether getting the -march 
setting right in a chroot matters to the operation of the chroot itself, as 
distinct from building good code for the target machine. Personally, I can't 
see how it can have any such effect.

-- 
Regards,
Peter.

Re: [gentoo-user] Re: Dependencies and PYTHON_TARGETS

[Poncho]

On 24.04.2018 01:46, Neil Bothwick wrote:
> On Mon, 23 Apr 2018 18:10:08 -0400, Mike Gilbert wrote:
> 
>> You are incorrect; PYTHON_TARGETS is never calculated based on the
>> versions of python you have installed.
> 
> Then how is it derived when not defined in make.conf? Is it set in the
> profiles?
> 
> 

yes, it's set in profiles/base/make.defaults

https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/base/make.defaults#n110