Re: [gentoo-user] Illegal State in Chroot Environment

2017-08-06 Thread P Levine 
On Sun, Aug 6, 2017 at 9:17 PM, symack  wrote:
>
> >>> Installing (4 of 199) app-arch/bzip2-1.0.6-r8::gentoo
> bash: line 1: 26183 Illegal instruction 
> ${PORTAGE_BUNZIP2_COMMAND:-${PORTAGE_BZIP2_COMMAND}
> -d} -c -- /var/db/pkg/app-arch/bzip2-1.0.6-r8/environment.bz2 >
> /var/tmp/portage/._unmerge_/app-arch/bzip2-1.0.6-r8/temp/environment
> ​​
>
CFLAGS="-O2 -pipe -fomit-frame-pointer -mcx16 -msahf -maes
> ​​
> -mpclmul -mpopcnt -mabm -mlwp -mavx -march=native"
>
> ​One or more "-m" flags in CFLAGS isn't valid for the host processor​.
Why have them in the first place if you've enabled -march=native?

[gentoo-user] Illegal State in Chroot Environment

2017-08-06 Thread symack 
Hello Everyone, I was able to get as far as installing grub however through
the installation I would find some strange behaviour such as not being able
to mount /dev/sda2 to the boot directory. I would do it on the livecd (ie,
mount /dev/sda2 /mnt/gentoo/boot).

When it came to installing `grub grub-install /dev/sda` I got an 'Illegal
State'. emerge -e world would fail with:

>>> Installing (4 of 199) app-arch/bzip2-1.0.6-r8::gentoo
bash: line 1: 26183 Illegal instruction
${PORTAGE_BUNZIP2_COMMAND:-${PORTAGE_BZIP2_COMMAND} -d} -c --
/var/db/pkg/app-arch/bzip2-1.0.6-r8/environment.bz2 >
/var/tmp/portage/._unmerge_/app-arch/bzip2-1.0.6-r8/temp/environment
!!! FAILED prerm: 132
 * ERROR: app-arch/bzip2-1.0.6-r8::gentoo failed (postrm phase):
 *   eutils.eclass could not be found by inherit()
 *
 * Call stack:
 *   ebuild.sh, line 611:  Called source
'/var/db/pkg/app-arch/bzip2-1.0.6-r8/bzip2-1.0.6-r8.ebuild'
 *   bzip2-1.0.6-r8.ebuild, line   9:  Called inherit 'eutils'
'toolchain-funcs' 'multilib' 'multilib-minimal'
 *   ebuild.sh, line 284:  Called die
 * The specific snippet of code:
 *   [[ -z ${location} ]] && die "${1}.eclass could not be found by
inherit()"
 *
 * If you need support, post the output of `emerge --info
'=app-arch/bzip2-1.0.6-r8::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=app-arch/bzip2-1.0.6-r8::gentoo'`.
 * The complete build log is located at
'/var/tmp/portage/._unmerge_/app-arch/bzip2-1.0.6-r8/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/._unmerge_/app-arch/bzip2-1.0.6-r8/temp/die.env'.
 * Working directory:
'/var/tmp/portage/._unmerge_/app-arch/bzip2-1.0.6-r8/homedir'
 * S: '/var/tmp/portage/._unmerge_/app-arch/bzip2-1.0.6-r8/work/bzip2-1.0.6'
 * QA Notice: ECLASS 'eutils' inherited illegally in
app-arch/bzip2-1.0.6-r8
 * ERROR: app-arch/bzip2-1.0.6-r8::gentoo failed:
 *   eutils.eclass could not be found by inherit()
 *
 * Call stack:
 *   misc-functions.sh, line  17:  Called source
'/var/tmp/portage/._portage_reinstall_.vay4msqy/bin/ebuild.sh'
 *   ebuild.sh, line 611:  Called source
'/var/db/pkg/app-arch/bzip2-1.0.6-r8/bzip2-1.0.6-r8.ebuild'
 *   bzip2-1.0.6-r8.ebuild, line   9:  Called inherit 'eutils'
'toolchain-funcs' 'multilib' 'multilib-minimal'
 *   ebuild.sh, line 284:  Called die
 * The specific snippet of code:
 *   [[ -z ${location} ]] && die "${1}.eclass could not be found by
inherit()"
 *
 * If you need support, post the output of `emerge --info
'=app-arch/bzip2-1.0.6-r8::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=app-arch/bzip2-1.0.6-r8::gentoo'`.
 * The complete build log is located at
'/var/tmp/portage/._unmerge_/app-arch/bzip2-1.0.6-r8/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/._unmerge_/app-arch/bzip2-1.0.6-r8/temp/die.env'.
 * Working directory:
'/var/tmp/portage/._unmerge_/app-arch/bzip2-1.0.6-r8/homedir'
 * S: '/var/tmp/portage/._unmerge_/app-arch/bzip2-1.0.6-r8/work/bzip2-1.0.6'
!!! FAILED postrm: 1
 * The 'postrm' phase of the 'app-arch/bzip2-1.0.6-r8' package has failed
 * with exit value 1.
 *
 * The problem occurred while executing the ebuild file named
 * 'bzip2-1.0.6-r8.ebuild' located in the '/var/db/pkg/app-
 * arch/bzip2-1.0.6-r8' directory. If necessary, manually remove the
 * environment.bz2 file and/or the ebuild file located in that directory.
 *
 * Removal of the environment.bz2 file is preferred since it may allow the
 * removal phases to execute successfully. The ebuild will be sourced and
 * the eclasses from the current portage tree will be used when necessary.
 * Removal of the ebuild file will cause the pkg_prerm() and pkg_postrm()
 * removal phases to be skipped entirely.
Traceback (most recent call last):
  File
"/var/tmp/portage/._portage_reinstall_.vay4msqy/bin/filter-bash-environment.py",
line 157, in 
re.compile(var_pattern), file_in, file_out)
  File
"/var/tmp/portage/._portage_reinstall_.vay4msqy/bin/filter-bash-environment.py",
line 81, in filter_bash_environment
file_out.write(line.replace("\1", ""))
BrokenPipeError: [Errno 32] Broken pipe
 * ERROR: app-arch/bzip2-1.0.6-r8::gentoo failed (postinst phase):
 *   filter-bash-environment.py failed
 *
 * Call stack:
 *ebuild.sh, line 767:  Called __ebuild_main 'postinst'
 *   phase-functions.sh, line 949:  Called __filter_readonly_variables
'--filter-path' '--filter-sandbox' '--allow-extra-vars'
 *   phase-functions.sh, line 137:  Called die
 * The specific snippet of code:
 *   "${PORTAGE_PYTHON:-/usr/bin/python}"
"${PORTAGE_BIN_PATH}"/filter-bash-environment.py "${filtered_vars}" || die
"filter-bash-environment.py failed"
 *
 * If you need support, post the output of `emerge --info
'=app-arch/bzip2-1.0.6-r8::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=app-arch/bzip2-1.0.6-r8::gentoo'`.
 * The complete build log is located at

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

2017-08-06 Thread R0b0t1 
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. It's also not very likely to be a problem with the USB code
unless it was reimplemented for DigiStump's product (check against
these libraries
http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__alternative_stacks.html).

R0b0t1.

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

2017-08-06 Thread Mick 
On Sunday 06 Aug 2017 18:50:07 tu...@posteo.de wrote:
> Hi,
> 
> sorry, this will become a little longish...
> 
> Background: To program an ATMEL ATtiny85 via USB
> without a dedicated USB chip there is a bootloader
> called "micornucleys", which bitbangs the USB protocoll.
> This mechanism is used in Digistupms Digispark ATTtiny
> developmnent board (http://digistump.com/products/1).
> 
> So far so nice?
> 
> 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
> 
> or similiar. lsusb does not show anything related at all.
> 
> As recommended on related pages on the internet, I installed
> dedicated udev rules to show the needed ttyACM device. But
> since the kernel itsself fails to accept the device, the best
> udev rules will not work.
> 
> 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
> 
> dmesg reports for this device to use the modyle xhci_hcd.
> 
> I loaded that module by hand on my Gentoo PC and reinserted
> the Digispark: Nothing...same errors as before.
> 
> What can I do to make this Digispark being correctly recognized?
> 
> Thank you VERY much for any help in advance!
> 
> Cheers
> Meino

Did you compare the Android kernel and loaded modules with your Gentoo kernel?

Did you compare lsusb and lshw for other related modules and drivers?  What 
I'm saying is there may be other modules needed like UART, serial over usb and 
what not.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

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

2017-08-06 Thread tuxic 
Hi,

sorry, this will become a little longish...

Background: To program an ATMEL ATtiny85 via USB
without a dedicated USB chip there is a bootloader
called "micornucleys", which bitbangs the USB protocoll.
This mechanism is used in Digistupms Digispark ATTtiny
developmnent board (http://digistump.com/products/1).

So far so nice?

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

or similiar. lsusb does not show anything related at all.

As recommended on related pages on the internet, I installed
dedicated udev rules to show the needed ttyACM device. But 
since the kernel itsself fails to accept the device, the best
udev rules will not work.

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

dmesg reports for this device to use the modyle xhci_hcd.

I loaded that module by hand on my Gentoo PC and reinserted
the Digispark: Nothing...same errors as before.

What can I do to make this Digispark being correctly recognized?

Thank you VERY much for any help in advance!

Cheers
Meino

[gentoo-user] upgrading to gcc-f (was: chromium 60 build failure)

2017-08-06 Thread allan gottlieb 
On Mon, Jul 31 2017, Mateusz Lenik wrote:

> On Mon, Jul 31, 2017 at 08:02:34PM +, Grant Edwards wrote:
>> ../../third_party/vulkan-validation-layers/src/loader/debug_report.c:50:5: 
>> note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to 
>> compile your code
>> ../../third_party/vulkan-validation-layers/src/loader/debug_report.c:
>> In function ‘util_CreateDebugReportCallbacks’:
>> ../../third_party/vulkan-validation-layers/src/loader/debug_report.c:235:5:
>> error: ‘for’ loop initial declarations are only allowed in C99 or
>> C11 mode
>
> Most likely gcc-4.9 defaults to older C standard (C89, I guess).
> The easiest way to solve this would be to update your gcc to 5.4, 
> otherwise you'd have to pass one of the suggested flags to the compiler 
> somehow.

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