Re: [gentoo-user] sys-apps/systemd-239-r2 does not install completely
Am 19.11.18 um 08:19 schrieb YUE Daian: > Have you tried to run `eix-update`? For sure. Repeated right now, doesn't change the output of "eix -I"
Re: [gentoo-user] sys-apps/systemd-239-r2 does not install completely
On 2018-11-19 08:14, "Stefan G. Weichinger" wrote: > upgrading from sys-apps/systemd-236-r5 to 239-r2 > > the emerge runs through and warns me that it overwrites files ... so it > merges only partially ... > > after that I see: > > # systemctl --version > systemd 239 > > (which is OK) > > > # eix -I systemd > > [U] sys-apps/systemd > Available versions: 239-r2(0/2) > > Installed versions: 236-r5 > > (which is scary) > > How to clean that up? Have you tried to run `eix-update`?
[gentoo-user] sys-apps/systemd-239-r2 does not install completely
upgrading from sys-apps/systemd-236-r5 to 239-r2 the emerge runs through and warns me that it overwrites files ... so it merges only partially ... after that I see: # systemctl --version systemd 239 (which is OK) # eix -I systemd [U] sys-apps/systemd Available versions: 239-r2(0/2) Installed versions: 236-r5 (which is scary) How to clean that up?
Re: [gentoo-user] Re: AMD lappy
On 11/18/18 12:19 PM, james wrote: > On 11/17/18 9:59 PM, Grant Edwards wrote: >> On 2018-11-18, james wrote: >>> On 11/17/18 6:51 PM, Grant Edwards wrote: On 2018-11-17, Mick wrote: > On Saturday, 17 November 2018 23:00:22 GMT Grant Edwards wrote: >> On 2018-11-17, james wrote: >> >>> Actually and AMD Arm (64bit) Ryzen or newer. >> >> No, Ryzen is not an Arm processor. > Well, ... the PSP spy-in-the-die is an ARM core running within the > main AMD x86 CPU and you can't switch it off, or remove it. Right. Unless AMD has screwed up royally, the ARM security-processor-thingy is pretty much invisible to the end-user. > However, I'm sure this is not the kind of ARM James' been looking > for. I assumed not. I'd love to have an Arm based laptop, but getting full-up Linux running reliably on a Chromebook is just a bit over my hassle budget. I also want it to have a 16" 4:3 150dpi display, an RJ45 Ethernet connector, and a real DB9 serial port. I'll pass on the built in POTS modem... >>> >>> I had not realized that AMD has completely given up on Arm Systems. >> >> It's hard to tell. They still show the Opteron-A on their web site, >> but Google couldn't find anything using it... >> >>> I'm looking for an arm64 system, with enough native power to compile 64 >>> bit arm codes, natively. Here is the best I've found:: >>> >>> SynQuacer Dev Box >>> >>> [1] https://www.96boards.org/product/developerbox/ >>> >>> Purports to run gentoo (embedded?). >>> "�SC2A11� is a multi-core chip with 24 cores of ARM� Cortex-A53" >>> >>> Not quite available (alpha) and a bit pricey at $1200.00. >> >> Ouch. >> >>> Like Grant I'm looking for an arm 64 system that is straightforward >>> on installing gentoo, and has enough resources to perform most >>> compiles, natively. Or somebody has distcc running on four of those >>> 4G DDR-4 boards. >>> >>> Perhaps a gentoo cluster running on the latest R. PI ? >>> >>> Perhaps Vapier has a hidden howto to put native gentoo on Chromebooks? >> >> https://wiki.gentoo.org/wiki/Chromebook >> >> It's definitly doable ( for certain models and some value of >> "doable"). Everytime I look into it, the models for which "real" >> Linux installations are documented are always out-of-production. >> >>> Perhaps "TomH" has some suggestions. I got one of those "hikey Armv8a" >>> boards from 2015, but cannot find his gentoo image he crafted and >>> published. I do not have time for another gentoo adventure, just want to >>> use it and sync it now and again and install ebuilds and write a few >>> ebuilds for some 64 bit arm boards. >> >> Cross development might be easier. It's how a _lot_ of ARM Linux >> targets are supported. Even if the devlopment host and target are >> both ARM64, unless they're _really_ identical (same kernel, distro, >> and libraries), you still end up doing a good amount of "cross" >> compiling. >> >>> My thoughts are to consolidate my efforts into one (arm64) arch, both on >>> the development lappy and the arm64 SBCs I have to code to and >>> maintain. Perhaps All winner? (Allwinner H6)?USB 3.0 is great for SSD >>> and offgrid applications. >> > > > So, I'm going with a standard:: > > > https://wiki.gentoo.org/wiki/Raspberry_Pi_3_64_bit_Install > > I guess I'll try to cluster these guys, say four, into an old laptop > with a removed motherboard, and just cable the connections, to the > external sides of the old/large motherboard. It'll be interested to see > if I can get the 17.3 inch screen to work with this board. You'd think > that some laptop case manufacturer would have already built a generic > laptop to house 4-8 of these R.pi.3B+ boards inside and prebuilt cables > to tether to glueable connectors on the outside of the case. I like the > Molex-screw-terminals myself, particularly for RS232 serial and A/D IO. > USB and HDMI out to be easy to extend. > > And you thought those old (large) laptops were still useless > > Wish me luck. Drop a line if you find gentoo-clusterd on these R. > Pi-3B+ SBC anywhere. Surely today's kids do that sort of thing between > classes? > > It'd be great if we made this laptop to clusters (gentoo) Rpi a group > project... I might just look for a 'carrier-slot' hardware, where R.pi > can be inserted and removed kinda like the old pcmcia cards on lappies. > > Thx Grant (), > > James Found a RPiB3+ lappy kit:: https://www.techrepublic.com/article/pi-top-review-a-raspberry-pi-laptop-for-tinkering-on-the-go/ Now just add a carrier board for (4-8) RPiB3+ and cluster them together. Several web sites indicate that distcc can be use to compile native code for these Broadcom based arm64 systems:: from :: https://wiki.gentoo.org/wiki/Raspberry_Pi#WiFi "The project's GitHub page additionally contains instructions for setting up crossdev and distcc to build for the 64-bit RPi3. "
Re: [gentoo-user] Re: Firefox and Thunderbird compile issue
On 11/18/18 10:19, (Nuno Silva) wrote: > On 2018-11-18, Daniel Frey wrote: > >> On 11/18/18 02:47, Alarig Le Lay wrote: >>> Hi Daniel, >>> >>> Didi you tried to remove the temporary directory (inside /var/tmp) and >>> re-emerge id again? It looks like an incorrectly decompressed archive. >>> >> >> I just tried this, to no avail. >> >> I'm trying to rebuild the installed packages I have under dev-python/* >> but I'm not sure it will help. > > Do you, by any chance, have distcc enabled?: > > https://bugs.gentoo.org/show_bug.cgi?id=646062 > https://forums.gentoo.org/viewtopic-p-8275494.html > Aw nuts. I searched 'distcc firefox' and came across my own thread earlier this year. I never updated package.env on my backup laptop so it popped up again, and I completely forgot. It's really unfortunate that on massive builds distcc is not an option. Maybe I should consider -bin instead. Dan
[gentoo-user] Re: Firefox and Thunderbird compile issue
On 2018-11-18, Daniel Frey wrote: > On 11/18/18 02:47, Alarig Le Lay wrote: >> Hi Daniel, >> >> Didi you tried to remove the temporary directory (inside /var/tmp) and >> re-emerge id again? It looks like an incorrectly decompressed archive. >> > > I just tried this, to no avail. > > I'm trying to rebuild the installed packages I have under dev-python/* > but I'm not sure it will help. Do you, by any chance, have distcc enabled?: https://bugs.gentoo.org/show_bug.cgi?id=646062 https://forums.gentoo.org/viewtopic-p-8275494.html -- Nuno Silva
Re: [gentoo-user] Firefox and Thunderbird compile issue
On 11/18/18 02:47, Alarig Le Lay wrote: > Hi Daniel, > > Didi you tried to remove the temporary directory (inside /var/tmp) and > re-emerge id again? It looks like an incorrectly decompressed archive. > I just tried this, to no avail. I'm trying to rebuild the installed packages I have under dev-python/* but I'm not sure it will help. Dan
Re: [gentoo-user] Re: AMD lappy
On 11/17/18 9:59 PM, Grant Edwards wrote: > On 2018-11-18, james wrote: >> On 11/17/18 6:51 PM, Grant Edwards wrote: >>> On 2018-11-17, Mick wrote: On Saturday, 17 November 2018 23:00:22 GMT Grant Edwards wrote: > On 2018-11-17, james wrote: > >> Actually and AMD Arm (64bit) Ryzen or newer. > > No, Ryzen is not an Arm processor. >>> Well, ... the PSP spy-in-the-die is an ARM core running within the main AMD x86 CPU and you can't switch it off, or remove it. >>> >>> Right. Unless AMD has screwed up royally, the ARM >>> security-processor-thingy is pretty much invisible to the end-user. >>> However, I'm sure this is not the kind of ARM James' been looking for. >>> >>> I assumed not. >>> >>> I'd love to have an Arm based laptop, but getting full-up Linux >>> running reliably on a Chromebook is just a bit over my hassle budget. >>> I also want it to have a 16" 4:3 150dpi display, an RJ45 Ethernet >>> connector, and a real DB9 serial port. I'll pass on the built in POTS >>> modem... >> >> I had not realized that AMD has completely given up on Arm Systems. > > It's hard to tell. They still show the Opteron-A on their web site, > but Google couldn't find anything using it... > >> I'm looking for an arm64 system, with enough native power to compile 64 >> bit arm codes, natively. Here is the best I've found:: >> >> SynQuacer Dev Box >> >> [1] https://www.96boards.org/product/developerbox/ >> >> Purports to run gentoo (embedded?). >> "�SC2A11� is a multi-core chip with 24 cores of ARM� Cortex-A53" >> >> Not quite available (alpha) and a bit pricey at $1200.00. > > Ouch. > >> Like Grant I'm looking for an arm 64 system that is straightforward >> on installing gentoo, and has enough resources to perform most >> compiles, natively. Or somebody has distcc running on four of those >> 4G DDR-4 boards. >> >> Perhaps a gentoo cluster running on the latest R. PI ? >> >> Perhaps Vapier has a hidden howto to put native gentoo on Chromebooks? > > https://wiki.gentoo.org/wiki/Chromebook > > It's definitly doable ( for certain models and some value of > "doable"). Everytime I look into it, the models for which "real" > Linux installations are documented are always out-of-production. > >> Perhaps "TomH" has some suggestions. I got one of those "hikey Armv8a" >> boards from 2015, but cannot find his gentoo image he crafted and >> published. I do not have time for another gentoo adventure, just want to >> use it and sync it now and again and install ebuilds and write a few >> ebuilds for some 64 bit arm boards. > > Cross development might be easier. It's how a _lot_ of ARM Linux > targets are supported. Even if the devlopment host and target are > both ARM64, unless they're _really_ identical (same kernel, distro, > and libraries), you still end up doing a good amount of "cross" > compiling. > >> My thoughts are to consolidate my efforts into one (arm64) arch, both on >> the development lappy and the arm64 SBCs I have to code to and >> maintain. Perhaps All winner? (Allwinner H6)?USB 3.0 is great for SSD >> and offgrid applications. > So, I'm going with a standard:: https://wiki.gentoo.org/wiki/Raspberry_Pi_3_64_bit_Install I guess I'll try to cluster these guys, say four, into an old laptop with a removed motherboard, and just cable the connections, to the external sides of the old/large motherboard. It'll be interested to see if I can get the 17.3 inch screen to work with this board. You'd think that some laptop case manufacturer would have already built a generic laptop to house 4-8 of these R.pi.3B+ boards inside and prebuilt cables to tether to glueable connectors on the outside of the case. I like the Molex-screw-terminals myself, particularly for RS232 serial and A/D IO. USB and HDMI out to be easy to extend. And you thought those old (large) laptops were still useless Wish me luck. Drop a line if you find gentoo-clusterd on these R. Pi-3B+ SBC anywhere. Surely today's kids do that sort of thing between classes? It'd be great if we made this laptop to clusters (gentoo) Rpi a group project... I might just look for a 'carrier-slot' hardware, where R.pi can be inserted and removed kinda like the old pcmcia cards on lappies. Thx Grant (), James
Re: [gentoo-user] virt-manager qemu problem
On Sunday, 18 November 2018 13:49:12 GMT jdm wrote: > On Sat, 17 Nov 2018 23:39:42 + > > Mick wrote: > > On Saturday, 17 November 2018 10:55:21 GMT jdm wrote: > > > Hi, > > > > > > I am trying to run virt-manager and or qemu with 3d acceleration > > > using virtio-gpu options. > > > > > > When I start the virtual machine in virt-manager all I get is a > > > screen of static (complete screen corruption of lines and blocks) > > > > > > I also get the same problem when trying to start from CLI with the > > > following > > > > > > /usr/bin/qemu-system-x86_64 \ > > > -enable-kvm \ > > > -cpu host \ > > > -smp 8 \ > > > -m 4G \ > > > -net nic,macaddr=52:54:00:12:34:56 -net user \ > > > -soundhw es1370 \ > > > -usb -device usb-tablet \ > > > -show-cursor \ > > > -vga virtio \ > > > -display gtk,gl=on \ > > > -drive file=arch.img,if=virtio & > > > > > > This used to work fine but has recently gone wrong. I have tried > > > several guests all with the same results of corrupted screens. > > > > > > I can start machines with normal qxl options and all is fine so > > > think this is just an issue with virtio 3d acceleration. > > > > > > Any ideas? > > > > > > Thanks > > > > > > John > > > > All I can think is this should be related to the host GPU and any > > recent update to its drivers. On an old Radeon here I have not > > noticed any problems running: > > > > -display gtk,gl=on > > > > or > > > > -display sdl,gl=on > > I decided to update virglrenderer upto version (not sure if I > should do this but heyho) as there is only one version available. This > has allowed me to run vm from CLI so that has helped there but not with > virt-manager, which now just shows a blank screen. > > I have a RX480 radeon card which is yearish old so perhaps support for > newer cards is not as good. > > John I'm still on virglrenderer-0.6.0, with a 10+ year old RV730/M96-XT [Mobility Radeon HD 4670] and radeon rather than amdgpu firmware. I am not using virt- manager, just qemu off the CLI. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] virt-manager qemu problem
On Sat, 17 Nov 2018 23:39:42 + Mick wrote: > On Saturday, 17 November 2018 10:55:21 GMT jdm wrote: > > Hi, > > > > I am trying to run virt-manager and or qemu with 3d acceleration > > using virtio-gpu options. > > > > When I start the virtual machine in virt-manager all I get is a > > screen of static (complete screen corruption of lines and blocks) > > > > I also get the same problem when trying to start from CLI with the > > following > > > > /usr/bin/qemu-system-x86_64 \ > > -enable-kvm \ > > -cpu host \ > > -smp 8 \ > > -m 4G \ > > -net nic,macaddr=52:54:00:12:34:56 -net user \ > > -soundhw es1370 \ > > -usb -device usb-tablet \ > > -show-cursor \ > > -vga virtio \ > > -display gtk,gl=on \ > > -drive file=arch.img,if=virtio & > > > > This used to work fine but has recently gone wrong. I have tried > > several guests all with the same results of corrupted screens. > > > > I can start machines with normal qxl options and all is fine so > > think this is just an issue with virtio 3d acceleration. > > > > Any ideas? > > > > Thanks > > > > John > > All I can think is this should be related to the host GPU and any > recent update to its drivers. On an old Radeon here I have not > noticed any problems running: > > -display gtk,gl=on > > or > > -display sdl,gl=on > I decided to update virglrenderer upto version (not sure if I should do this but heyho) as there is only one version available. This has allowed me to run vm from CLI so that has helped there but not with virt-manager, which now just shows a blank screen. I have a RX480 radeon card which is yearish old so perhaps support for newer cards is not as good. John
Re: [gentoo-user] Help with dev-util/cargo blocking dev-lang/rust.
* Neil Bothwick: > That's because ~ doesn't mean unstable, it means testing. Stable in > this context means less likely to change, not less likely to fall > over. Plus the differentiation is for the ebuilds, not the software > itself. It is also worth mentioning that ebuilds cannot be added to the tree with "stable" flags, at least not by unprivileged contributors such as myself. If, for example, there is an upstream bugfix release, I will copy my existing ebuild because neither build process nor dependencies have changed one bit, but I am required to change keywords to unstable anyway. Switching to stable would require a second pull request after at least a month has passed, and many contributors just don't bother with that. -Ralph
Re: [gentoo-user] Help with dev-util/cargo blocking dev-lang/rust.
On Sun, 18 Nov 2018 00:33:41 -0500, Andrew Udvare wrote: > I switched fully to ACCEPT_KEYWORDS="~amd64" (make.conf) after running > mixed for a while. These kinds of issues come up too often and I don't > have a lot of time to solve them, plus for my dev machine I just don't > notice stable vs unstable most of the time. If something is truly > unstable from my own experience I will mask that version and downgrade. That's because ~ doesn't mean unstable, it means testing. Stable in this context means less likely to change, not less likely to fall over. Plus the differentiation is for the ebuilds, not the software itself. You can have a rock solid program still in the testing tree. -- Neil Bothwick There is absolutely no substitute for a genuine lack of preparation. pgpAZTd8AXIxs.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Firefox and Thunderbird compile issue
Hi Daniel, Didi you tried to remove the temporary directory (inside /var/tmp) and re-emerge id again? It looks like an incorrectly decompressed archive. -- Alarig
