[gentoo-user] Re: dev-python/whoosh fails to compile

[Ian Zimmerman]

On 2017-07-29 11:23, Alan McKinnon wrote:

> On 29/07/2017 10:51, John Covici wrote:
> > Hi.  In my latest world update, portage wants to include this new
> > package dev-python/whoosh.  The package fails to compile and googling
> > and searching bgo yields nothing.
> > 
> > Any assistance would be appreciated.
> 
> [snip]
> 
> > pkg_resources.DistributionNotFound: The 'sphinxcontrib-websupport' 
> > distribution was not found and is required by Sphinx
> 
> [snip]
> 
> >  * The specific snippet of code:
> >  *   sphinx-build -b html -c docs/source/ docs/source/ 
> > docs/source/build/html || die;
> 
> File a bug at bgo

What was the conclusion of this?  After syncing my portage wants to
build this too (the same exact version), and I'm afraid to let it
proceed lest I land in a mess.

I couldn't find any relevant filed bug, either.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

[gentoo-user] [SOLVED] vsftpd anonymous upload illegal PORT command

[Walter Dnes]

> Try a:
> 
> ftp> cd incoming

  Thank you, that was it.  I just pushed over a file from a Gentoo
machine to my desktop for a test.  The OS/2 Warp ftp client still
doesn't work, but that's probably a VM networking issue.  There are
other ways of getting data from inside the VM to the host machine, then
I can ftp from there.

  Annoying "feature"... if I set "anon_root=/home/ftp/incoming/", then
vsftpd refuses to run, complaining about a writable chroot directory.
So I have to do an anonymous login, starting of in /home/ftp/ and then
manually "cd incoming".

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

Re: [gentoo-user] vsftpd anonymous upload illegal PORT command

[David Haller]

Hello,

On Mon, 07 Aug 2017, Walter Dnes wrote:
>On Fri, Aug 04, 2017 at 02:23:08PM +0200, David Haller wrote
>> # mkdir /home/ftp/incoming
>> # chown ftp.ftp /home/ftp/incoming
>> # chmod 1777 /home/ftp/incoming
>> # chmod 555 /home/ftp
>
>  I did the above (copy+paste; *WITHOUT* the "#", in case anyone asks).
>Here's what happens.  Question... why is it prompting me with "530 Please
>login with USER and PASS." *AFTER* I give username "anonymous".  BTW, if
>I try any username, other than anonymous, it dies with a message about
>being only an anonymous ftp server.
>
>[i3][waltdnes][~/downloads] ftp -p 192.168.123.251
>Connected to 192.168.123.251 (192.168.123.251).
>220 (vsFTPd 3.0.2)
>Name (192.168.123.251:waltdnes): anonymous
>530 Please login with USER and PASS.
>SSL not available
>331 Please specify the password.
>Password:
>230 Login successful.
>Remote system type is UNIX.
>Using binary mode to transfer files.

Try a:

ftp> cd incoming

here...


>ftp> put install-x86-minimal-20170207.iso

or use

ftp> put install-x86-minimal-20170207.iso incoming/

there.

>local: install-x86-minimal-20170207.iso remote: 
>install-x86-minimal-20170207.iso
>227 Entering Passive Mode (192,168,123,251,117,59).
>553 Could not create file.
>ftp> bye
>221 Goodbye.

HTH,
-dnh

-- 
panic("floppy: Port bolixed.");
linux-2.2.16/include/asm-sparc/floppy.h

Re: [gentoo-user] Re: upgrading to gcc-5 (on x86_64-pc-linux-gnu)

[Neil Bothwick]

On Tue, 08 Aug 2017 16:38:34 -0400, allan gottlieb wrote:

> So you propose
> 
> # gcc-config x86_64-pc-linux-gnu-5.4.0
> # revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc
> # emerge @system
> 
> I am at 98 of 122 for the revdep-rebuild.
> I just looked and emerge @system would generate approx 50 merges.
> The only one that looks long is gcc.
> That seems unfortunate since I just activated that version of gcc and I
> believe the gcc ebuild is a bootstrap so gcc-5 was compiled with gcc-5.

That's why the recommended revdep-rebuild call passes "--exclude gcc" to
emerge. Do the same with emerge @system.


-- 
Neil Bothwick

WinErr 042: Virus error - A virus has been activated in a dos-box. The
virus, however, requires Windows. All tasks will automatically be closed
and the virus will be activated again.


pgp_XUM5ilh3U.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: upgrading to gcc-5 (on x86_64-pc-linux-gnu)

[allan gottlieb]

On Tue, Aug 08 2017, Nikos Chantziaras wrote:

> On 08/08/17 18:13, allan gottlieb wrote:
>> gcc-config -l reports
>>   [1] x86_64-pc-linux-gnu-4.9.3
>>   [2] x86_64-pc-linux-gnu-4.9.4 *
>>   [3] x86_64-pc-linux-gnu-5.4.0
>>
>> The news item from 2015-10-22 suggests (I have gentoolkit-0.3.3)
>># revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc
>>
>> Is that the entire procedure needed?  In particular, ignoring
>> performance, can I avoid emerge --emptytree and just execute?
>>
>># gcc-config x86_64-pc-linux-gnu-5.4.0
>># revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc
>
> That usually works. If you want to be 100% sure, you still need a full
> @system followed by a @world rebuild. But usually just rebuilding
> C++-linked packages will give you a stable system.
>
> I still recommend a @system rebuild at least though, since it's fast.

So you propose

# gcc-config x86_64-pc-linux-gnu-5.4.0
# revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc
# emerge @system

I am at 98 of 122 for the revdep-rebuild.
I just looked and emerge @system would generate approx 50 merges.
The only one that looks long is gcc.
That seems unfortunate since I just activated that version of gcc and I
believe the gcc ebuild is a bootstrap so gcc-5 was compiled with gcc-5.
But I guess it might well link to other items that were compiled with
gcc-4.

I believe that, even though @world includes @system,
   emerge @system; emerge @world
differs from
   emerge @world

So there are many possibilities

1.  Stop after the revdep-rebuild
2.  emerge @system
3.  emerge --emptytree @system
4.  emerge @world
5.  emerge --emptytree @world
6.  emerge @system; emerge @world
7.  emerge --emptytree @system; emerge --emptytree @world

Which ones do you recommend?

thanks,
allan

[gentoo-user] Re: upgrading to gcc-5 (on x86_64-pc-linux-gnu)

[Nikos Chantziaras]

On 08/08/17 18:13, allan gottlieb wrote:

gcc-config -l reports
  [1] x86_64-pc-linux-gnu-4.9.3
  [2] x86_64-pc-linux-gnu-4.9.4 *
  [3] x86_64-pc-linux-gnu-5.4.0

The news item from 2015-10-22 suggests (I have gentoolkit-0.3.3)
   # revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc

Is that the entire procedure needed?  In particular, ignoring
performance, can I avoid emerge --emptytree and just execute?

   # gcc-config x86_64-pc-linux-gnu-5.4.0
   # revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc


That usually works. If you want to be 100% sure, you still need a full 
@system followed by a @world rebuild. But usually just rebuilding 
C++-linked packages will give you a stable system.


I still recommend a @system rebuild at least though, since it's fast.

Re: [gentoo-user] DNS resolver doesn't

[Mike Gilbert]

On Tue, Aug 8, 2017 at 12:32 PM, Peter Humphrey  wrote:
> On Tuesday 08 Aug 2017 09:11:22 Mike Gilbert wrote:
>
>> The "order" directive in /etc/host.conf only works for very old
>> versions of glibc. Modern versions use /etc/nsswitch.conf. The default
>> nsswitch.conf will check /etc/hosts (files) before DNS anyway.
>>
>> How are you testing? I would guess you are probably using the wrong tool.
>
> nslookup -sil
>
>> The "host" command will always ignore /etc/hosts. It always does DNS
>> queries by design.
>>
>> Try using "getent hosts [hostname]".
>
> Yes, that works. Thanks Mike. I'll set up a nice short alias for it. Looks
> like I can get rid of net-dns/bind-tools.

bind-tools is quite useful for performing advanced DNS queries. The
'dig' command is especially useful if you want to see the full rrset
being returned. It also lets you set various flags on the DNS request,
and manually override the DNS server.

For casual usage, bind-tools is probably unnecessary.

Re: [gentoo-user] DNS resolver doesn't

[Peter Humphrey]

On Tuesday 08 Aug 2017 09:11:22 Mike Gilbert wrote:

> The "order" directive in /etc/host.conf only works for very old
> versions of glibc. Modern versions use /etc/nsswitch.conf. The default
> nsswitch.conf will check /etc/hosts (files) before DNS anyway.
> 
> How are you testing? I would guess you are probably using the wrong tool.

nslookup -sil
 
> The "host" command will always ignore /etc/hosts. It always does DNS
> queries by design.
> 
> Try using "getent hosts [hostname]".

Yes, that works. Thanks Mike. I'll set up a nice short alias for it. Looks 
like I can get rid of net-dns/bind-tools.

-- 
Regards
Peter

[gentoo-user] Perl 5.26 Unmasking Warning [affects all users]

[Kent Fredric]

We're finally at a point where we're nearing the unmasking[1] of Perl
5.26 and making it visible to ~arch users, and a "news item" on this
matter will appear shortly.

Due to a collection of various problems faced in this version,
extensive amounts of work has been needed to simply deliver an ~arch
release that isn't incredibly visibly broken [1][2].

Subsequently, this will require a lot of care from end users who use
~arch versions of Perl, specifically as breakages manifest all over the
tree, in places you wouldn't expect ( for example: make, automake,
autoconf, gcc, and even some python packages have been broken by
changes in this release )

If you use Gentoo as a production server, this will be a good time to
set aside a seperate box for testing the side effects of this release
on your platform, and you should assume this release *will* affect you
in some way.

There are 4 Major types of failures [3]:

1: [build] failiures related to the removal of '.' from @INC [4] such 
as:
 - Can't locate inc:: ... in @INC (you may need to install the ... module)
 - Can't locate t:: ... in @INC (you may need to install the ... module)
 - do "foo.pl" failed, '.' is no longer in @INC; did you mean do "./foo.pl"?

2: [buildtime] The default of internal OP OP_SIBLING/OP_PARENT changing:
 - error: ... has no member named ‘op_sibling'
 
3: [runtime] Unescaped "{" in regex becomming a fatal error:
 - Unescaped left brace in regex is illegal in ...

4: [runtime] The removal of POSIX::tmpname in favour of File::Temp
 - Unimplemented: POSIX::tmpnam()

Our hope is to have all the in-tree bugs [5] fixed long in advance of
needing to stabilize Perl 5.26.

However, special efforts will have to be added for anything using an
overlay, and any of your private code ( such as things you've manually
installed into /opt  or /usr/local/ ) will need additional care as
these are outside the visibility of Gentoo Devs.

Please make sure to report any bugs you find that are clearly caused by
Perl 5.26 ( of course, first skim the lengthy list of known issues for
duplicates [6] ).

For any questions, please follow up in reply to this email, or ask
us on freenode.org#gentoo-perl

1: https://bugs.gentoo.org/show_bug.cgi?id=perl-5.26-unmask
2: https://bugs.gentoo.org/show_bug.cgi?id=612408
3: https://wiki.gentoo.org/wiki/Project:Perl/5.26_Known_Issues
4: https://wiki.gentoo.org/wiki/Project:Perl/Dot-In-INC-Removal
5: https://bugs.gentoo.org/show_bug.cgi?id=perl-5.26
6: https://bugs.gentoo.org/showdependencytree.cgi?id=613764_resolved=1


pgpiVH_nvHOZi.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] upgrading to gcc-5 (on x86_64-pc-linux-gnu)

[allan gottlieb]

On Tue, Aug 08 2017, John Blinka wrote:

>> Is that the entire procedure needed?
>
> That's what I did a while back.  Nothing broke as a result.
>
> John

Thank you john (and todd).  I will give it a go.
allan

Re: [gentoo-user] upgrading to gcc-5 (on x86_64-pc-linux-gnu)

[John Blinka]

> Is that the entire procedure needed?

That's what I did a while back.  Nothing broke as a result.

John

Re: [gentoo-user] upgrading to gcc-5 (on x86_64-pc-linux-gnu)

[Todd Goodman]

That's always worked for me.

Todd


On 08/08/2017 11:13 AM, allan gottlieb wrote:
> gcc-config -l reports
>  [1] x86_64-pc-linux-gnu-4.9.3
>  [2] x86_64-pc-linux-gnu-4.9.4 *
>  [3] x86_64-pc-linux-gnu-5.4.0
>
> The news item from 2015-10-22 suggests (I have gentoolkit-0.3.3)
>   # revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc
>
> Is that the entire procedure needed?  In particular, ignoring
> performance, can I avoid emerge --emptytree and just execute?
>
>   # gcc-config x86_64-pc-linux-gnu-5.4.0
>   # revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc
>
> thanks,
> allan
>

[gentoo-user] upgrading to gcc-5 (on x86_64-pc-linux-gnu)

[allan gottlieb]

gcc-config -l reports
 [1] x86_64-pc-linux-gnu-4.9.3
 [2] x86_64-pc-linux-gnu-4.9.4 *
 [3] x86_64-pc-linux-gnu-5.4.0

The news item from 2015-10-22 suggests (I have gentoolkit-0.3.3)
  # revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc

Is that the entire procedure needed?  In particular, ignoring
performance, can I avoid emerge --emptytree and just execute?

  # gcc-config x86_64-pc-linux-gnu-5.4.0
  # revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc

thanks,
allan

Re: [gentoo-user] DNS resolver doesn't

[Mike Gilbert]

On Tue, Aug 8, 2017 at 6:19 AM, Peter Humphrey  wrote:
> Hello list,
>
> On two machines, I have my DSL modem set as DNS server, and it forwards to
> my ISP's servers. This works well for external hosts. I also have "order
> hosts, bind" in /etc/host.conf, but even though both machines have full LAN
> host names and addresses in their /etc/hosts, every DNS lookup goes straight
> to the modem, which of course knows nothing of the local layout.
>
> What else do I have to do to make host.conf effective? Would a hammer help?

The "order" directive in /etc/host.conf only works for very old
versions of glibc. Modern versions use /etc/nsswitch.conf. The default
nsswitch.conf will check /etc/hosts (files) before DNS anyway.

How are you testing? I would guess you are probably using the wrong tool.

The "host" command will always ignore /etc/hosts. It always does DNS
queries by design.

Try using "getent hosts [hostname]".

[gentoo-user] DNS resolver doesn't

[Peter Humphrey]

Hello list,

On two machines, I have my DSL modem set as DNS server, and it forwards to 
my ISP's servers. This works well for external hosts. I also have "order 
hosts, bind" in /etc/host.conf, but even though both machines have full LAN 
host names and addresses in their /etc/hosts, every DNS lookup goes straight 
to the modem, which of course knows nothing of the local layout.

What else do I have to do to make host.conf effective? Would a hammer help?

-- 
Regards
Peter

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

[Stefan Mark]

On Mon, 7 Aug 2017 12:10:30 -0500
R0b0t1  wrote:

> On Mon, Aug 7, 2017 at 11:29 AM, Stefan Mark  wrote:
> > On Mon, 7 Aug 2017 08:48:50 -0500
> > R0b0t1  wrote:
> >  
> >> On Mon, Aug 7, 2017 at 4:29 AM, Stefan Mark 
> >> wrote:  
> >> > On Sun, 6 Aug 2017 19:04:09 -0500
> >> > R0b0t1  wrote:
> >> >  
> >> >> On Sun, Aug 6, 2017 at 11:50 AM,   wrote:  
> >> >> > When I plug in such a little board into my PC, demesg
> >> >> > reports:
> >> >> > [ 1429.834140] usb 7-4: new low-speed USB device number 15
> >> >> > using ohci-pci [ 1429.965142] usb 7-4: device descriptor
> >> >> > read/64, error -62 [ 1430.203151] usb 7-4: device descriptor
> >> >> > read/64, error -62 [ 1430.438161] usb 7-4: new low-speed USB
> >> >> > device number 16 using ohci-pci [ 1430.569151] usb 7-4:
> >> >> > device descriptor read/64, error -62 [ 1430.803174] usb 7-4:
> >> >> > device descriptor read/64, error -62 [ 1431.038184] usb 7-4:
> >> >> > new low-speed USB device number 17 using ohci-pci
> >> >> > [ 1431.456157] usb 7-4: device not accepting address 17,
> >> >> > error -62 [ 1431.582204] usb 7-4: new low-speed USB device
> >> >> > number 18 using ohci-pci [ 1432.000209] usb 7-4: device not
> >> >> > accepting address 18, error -62 [ 1432.000244] usb
> >> >> > usb7-port4: unable to enumerate USB device  
> >> >>  
> >> >> >
> >> >> > My first thought was: The micronucleus bootloaed is missing or
> >> >> > is defective...
> >> >> >
> >> >> > But plugging in the board into my Android tablet (the tablet
> >> >> > runs Lollipop and is nothing special at all beside being
> >> >> > rooted) via an OTG cable and using lsusb after that, it shows
> >> >> > Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark
> >> >> >  
> >> >>
> >> >> What the dmesg output is saying is that your USB hardware has
> >> >> reported a communication error to the driver. It is my guess
> >> >> that the ATtiny85 is not meeting the timing requirements for
> >> >> USB.
> >> >>
> >> >> Looking at the board there does not seem to be a crystal
> >> >> oscillator which most people would consider necessary for doing
> >> >> USB communication. This is an oversight on DigiStump's part and
> >> >> it is very likely you will not be able to fix the communication
> >> >> issues. You should contact them and tell them that your
> >> >> computer will not recognize their device and that you suspect
> >> >> it is because the clock is too inaccurate.
> >> >>  
> >> >> >
> >> >> > What can I do to make this Digispark being correctly
> >> >> > recognized?
> >> >> >
> >> >> > Thank you VERY much for any help in advance!
> >> >> >  
> >> >>
> >> >> Three things:
> >> >>
> >> >> 1) Return the one you bought and get a new one. The ATtiny85's
> >> >> internal oscillator might be at the end of the bell curve but
> >> >> within manufacturer tolerance, which isn't enough to produce a
> >> >> USB signal close enough to the specified frequency. Expect the
> >> >> seller to pay for return shipping.
> >> >>
> >> >> 2) You can calibrate the oscillator using instructions in this
> >> >> application note:
> >> >> http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf.
> >> >> This process still might not get you close enough.
> >> >>
> >> >> 3) Add a crystal oscillator to the ATtiny85 and change its
> >> >> fuses to use the oscillator. You will need to recompile the
> >> >> firmware if the crystal is a different frequency from the
> >> >> internal oscillator.
> >> >>
> >> >> It might work on your phone and not your desktop because of
> >> >> differences in the USB hardware (your phone's serial decoder in
> >> >> the USB hardware performs clock recovery but your PC does not)
> >> >> or because there are multiple things on a USB hub in your PC
> >> >> and the ATtiny85 is less accurate than those already present
> >> >> devices. Admittedly I'm surprised it gets most of the way to
> >> >> registering as a device and then fails, but I don't think the
> >> >> problem is with the drivers or your kernel.  
> >> > USB uses a variant of non-return-to-zero for clock
> >> > synchronisation, that should™ take care of timing issues.
> >> > Actually, using microcontrollers without crystal for soft-usb is
> >> > fairly common (i have a bunch myself). As far as i understand
> >> > (but im no expert), trouble usually arises more from the
> >> > improvised level shifters than timing issues.
> >> > Anyway, i neither think there is a driver problem, i had a fair
> >> > bit of the messages myself, usually fixed by fixing the level
> >> > shifter.  
> >>
> >> An NRZ signal is part of the reason USB is so finicky. With USB the
> >> clock has to be within some tolerance of the bus speed (the
> >> justification being that there are multiple devices on the bus that
> >> need to read the bus at all times) and this is fairly