[gentoo-user] alsamixer
I don't really know why sound is working on my machine rn. I think there is some kind of embedded USB bus AMD thingy that generates some digital stream that is simply played by a set of DACs on my mobo. The chipset listed in the motherboard manual seems irrelevant. The capacitor in my speakers is dying again, I bought these speakers back in 2006 and have hardly ever turned them off since. So they don't have much gain anymore, So I need some boost from the card Because I need to change a setting, alsamixer just dies when I try to configure it. When I try to select USB audio, the thing instantly crashes to desktop. atg@tortoise ~ $ alsamixer cannot load mixer controls: Broken pipe atg@tortoise ~ $ B L E H ! ! ! ! -- The vaccine is a LIE. Powers are not rights.
Re: [gentoo-user] alsamixer
On Thu, May 14, 2020 at 8:09 PM Alan Grimes wrote: > > Mark Knecht wrote: > > Excuse top post. Responding from phone. > > > > 1) what desktop environment? > > None, I fire up pulseaudio in my xinit script. I'm trying to configure > it with alsamixer as I always have... > > > 2) what shows up under /proc/around/cards? > > Interesting, didn't know about this: > > atg@tortoise /proc/asound $ cat cards > 0 [NVidia ]: HDA-Intel - HDA NVidia > HDA NVidia at 0xe108 irq 109 > 2 [Audio ]: USB-Audio - USB Audio > Generic USB Audio at usb-:47:00.1-5, high speed > atg@tortoise /proc/asound $ > > > > > 3) what are the speakers plugged into? > > Just a basic headphones -> RCA adaptor cable from the main output from > the motherboard, it's a surround sound type motherboard even though > those are pointless, you get surround sound out of a computer by > decoding the HDMI output ( see 0 above, ) I do that in the other room... > Anyway, it's a surround sound mobo and I don't have much say in that... > > Ok, honestly It's a MSI creator TRX 40 board > If you're running pulseaudio then try pavucontrol instead of alsamixer to control the PA server. You might need to emerge it. I'm not suggesting alsamixer cannot work, but you might not need it. Mark
Re: [gentoo-user] alsamixer
Mark Knecht wrote: > Excuse top post. Responding from phone. > > 1) what desktop environment? None, I fire up pulseaudio in my xinit script. I'm trying to configure it with alsamixer as I always have... > 2) what shows up under /proc/around/cards? Interesting, didn't know about this: atg@tortoise /proc/asound $ cat cards 0 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xe108 irq 109 2 [Audio ]: USB-Audio - USB Audio Generic USB Audio at usb-:47:00.1-5, high speed atg@tortoise /proc/asound $ > > 3) what are the speakers plugged into? Just a basic headphones -> RCA adaptor cable from the main output from the motherboard, it's a surround sound type motherboard even though those are pointless, you get surround sound out of a computer by decoding the HDMI output ( see 0 above, ) I do that in the other room... Anyway, it's a surround sound mobo and I don't have much say in that... Ok, honestly It's a MSI creator TRX 40 board -- The vaccine is a LIE. Powers are not rights.
Re: [gentoo-user] alsamixer
Excuse top post. Responding from phone. 1) what desktop environment? 2) what shows up under /proc/around/cards? 3) what are the speakers plugged into? Mark On Thu, May 14, 2020, 5:51 PM Alan Grimes wrote: > I don't really know why sound is working on my machine rn. > > I think there is some kind of embedded USB bus AMD thingy that generates > some digital stream that is simply played by a set of DACs on my mobo. > The chipset listed in the motherboard manual seems irrelevant. > > The capacitor in my speakers is dying again, I bought these speakers > back in 2006 and have hardly ever turned them off since. So they don't > have much gain anymore, So I need some boost from the card > > Because I need to change a setting, alsamixer just dies when I try to > configure it. When I try to select USB audio, the thing instantly > crashes to desktop. > > atg@tortoise ~ $ alsamixer > cannot load mixer controls: Broken pipe > atg@tortoise ~ $ > > B L E H ! ! ! ! > > -- > The vaccine is a LIE. > > Powers are not rights. > > > > >
Re: [gentoo-user] no ebuilds for telegram
Just talked to doc. If you are willing to risk it come on over and lets shop! Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, May 14, 2020 3:08 PM, n952162 wrote: > On 05/14/20 23:03, Matt Connell (Gmail) wrote: > > > On 2020-05-14 15:29, n952162 wrote: > > > > > $ lf /usr/portage/net-im/telegram-desktop > > > Manifest telegram-desktop-2.1.1.ebuild > > > files/ telegram-desktop-2.1.2.ebuild > > > metadata.xml telegram-desktop-2.1.3.ebuild > > > telegram-desktop-2.0.1-r1.ebuild telegram-desktop-2.1.4.ebuild > > > telegram-desktop-2.1.0.ebuild telegram-desktop-2.1.6.ebuild > > > > Hmm. Seems you have the ebuild for the latest (as of today) version, > > as I do, but when you try to use the ebuild, emerge isn't finding it. > > Do you have an alternative PORTDIR defined in /etc/portage/make.conf > > or anywhere else? The default is /usr/portage, according to both of > > my systems. > > $ grep PORT /etc/portage/make.conf > PORTDIR="/usr/portage"
Re: [gentoo-user] a day of PAIN.
I'm using a nearly 10 year old server, bought specifically so I can compile faster. None of my machines is newer than that. None of my machines support UEFI other than an older imac. The server, which was inexpensive ($500) only has 48 cores, 64 as soon as I update the processors (2 generations newer and more cores!). I love server grade hardware! Servers lose value quickly, they are a great bargain if you don't mind the sound of a wind tunnel or have another room to put it in. This machine was probably $20-30K new, no slouch, it was previously used for high frequency trading. Sadly the seller does seem to have emptied their' warehouse. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, May 14, 2020 11:50 AM, Andrew Udvare wrote: > > On 2020-05-12, at 18:45, Alan Grimes alonz...@verizon.net wrote: > > Why is this not a forced-on setting for any machine with UEFI enabled? I > > can't imagine that this would be unacceptable for more than 0.001% of > > the install base. > > Because not every user has UEFI and many just use the BIOS compatibility > layer (CSM) if they don't care about UEFI and Secure Boot. The CSM is going > to be there for a very long time. > > If you don't need UEFI features, then there's nothing really wrong with using > CSM. I am using UEFI because I like having a signed kernel and signed boot > loader (systemd-boot). > > -- > > Andrew
Re: [gentoo-user] Update Gentoo recently is becoming difficult
On Tue, May 12, 2020, 11:58 PM Rich Freeman wrote: > On Tue, May 12, 2020 at 3:24 PM Daniel Frey wrote: > > > > On 5/12/20 10:54 AM, Joachim Gwoke wrote: > > > Been having trouble with mainly calibre 4.9.1-r2 and have since kept it > > > out of any emerges. Otherwise everything is alright with python 3.7 on > > > my side > > > > > > > > > > I believe mine was soundconverter, but now I'm not so sure. It wanted > > something other than 3.7, and the build had no target for it, and there > > wasn't any unstable version in the tree I could unmask. > > Why not just set in /etc/portage/package.use/pythonmigrate > media-sound/soundconverter PYTHON_TARGETS: python3_6 python3_7 > > Then it will build with python-3.6 which should work fine. > > You don't HAVE to get rid of python-3.6 this instant, especially since > tons of stuff in the repository requires it still. > > -- > Rich > This fixed it with that like below to a file named calibre4 in /etc/portage/package.use/ Thanks a lot. Joachim >
Re: [gentoo-user] Building packages in different prefix without rebuilding system packages
On Thu, May 14, 2020 at 09:26:10AM -0400, Michael Orlitzky wrote: > On 5/14/20 7:55 AM, Neil Bothwick wrote: > > On Thu, 14 May 2020 18:17:06 +0800, Pengcheng Xu wrote: > > > >> That seems interesting. Do we need to include Portage install prefix > >> (/var/tmp/portage/category/package/..., the image path prefix before > >> actually merging with /)? > >> > >> Regards, > > > > No, just the --prefix=/home/blah/ that you want added to the ./configure > > invocation. > > > > This is a good way to install packages that you've built by hand into > (say) your home directory, but it will cause problems if you try to > trick portage into doing it. The big problem is that no other packages > are going to know where to find the thing you just installed. Everything > else in the Gentoo repository is designed to use standard values of > PATH, LD_LIBRARY_PATH, the compiler's include dir, PKG_CONFIG_PATH, etc. > If you take one program and put it somewhere non-standard, then every > package depending on it is going to break. > > If you install an *additional* copy (built by hand) in your home > directory, that's fine -- the system copy will still be in the right > place -- you just don't want to hide the system copy where nobody can > find it. > In my case, this wouldn't be a problem: I don't want the packages to be accessed by anyone, just one user. I can set PATH, LD_LIBRARY_PATH, PKG_CONFIG_PATH and MANPATH for that user. I already do that for things I build manually anyway. EXTRA_ECONF is nice, I didn't know about it. It looks like MYCMAKEARGS can be used for cmake ebuilds. For other build systems, it might be necessary to edit the ebuild, or set different variables. I still kinda think that being able to install with a prefix (like EPREFIX) but using the base system would be a nice feature. As discussed previously, there would be the problem of updates; but it isn't very different from installing software manually. If I clone something and build it locally, a world update might break break it, and portage cannot rebuild it automatically since it's not aware of it. This is why I think it would be nice if portage supported it; that way, after an update of the base system, updating the prefix system would solve the problems. It's probably difficult to implement that in portage, though.
Re: [gentoo-user] no ebuilds for telegram
On Thu, May 14, 2020 at 5:10 PM n952162 wrote: > > On 05/14/20 22:46, Rich Freeman wrote: > > On Thu, May 14, 2020 at 4:13 PM n952162 wrote: > >> Action: sync for repo: gentoo, returned code = 0 > >> > >>* An update to portage is available. It is _highly_ recommended > >>* that you update portage now, before any other packages are updated. > >> > >>* To update portage, run 'emerge --oneshot portage' now. > > ...and? Did you update portage as it was _highly_ recommended that > > you do so first? What version of portage are you using? This appears > > on the top line of emerge --info. > > > > $ emerge --info > Portage 2.3.49 (python 3.6.5-final-0, default/linux/x86/17.0, gcc-7.3.0, > glibc-2.26-r7, 4.14.65-gentoo x86_64) That version of portage has been removed from the repo for over a year. I would update your system so that is current and then try again. I believe that version of portage should still support EAPI 7 but there could be some other issue that is giving it problems with more recent packages in the tree. -- Rich
Re: [gentoo-user] no ebuilds for telegram
n952162 wrote: > On 05/14/20 22:46, Rich Freeman wrote: >> On Thu, May 14, 2020 at 4:13 PM n952162 wrote: >>> Action: sync for repo: gentoo, returned code = 0 >>> >>> * An update to portage is available. It is _highly_ recommended >>> * that you update portage now, before any other packages are >>> updated. >>> >>> * To update portage, run 'emerge --oneshot portage' now. >> ...and? Did you update portage as it was _highly_ recommended that >> you do so first? What version of portage are you using? This appears >> on the top line of emerge --info. >> > > $ emerge --info > Portage 2.3.49 (python 3.6.5-final-0, default/linux/x86/17.0, gcc-7.3.0, > glibc-2.26-r7, 4.14.65-gentoo x86_64) > > > > This is what it looks like in my emerge --info. Mine will be different from yours since mine is in a different location. Repositories: gentoo location: /var/cache/portage/tree sync-type: rsync sync-uri: rsync://rsync26.us.gentoo.org/gentoo-portage priority: -1000 sync-rsync-verify-max-age: 24 sync-rsync-extra-opts: sync-rsync-verify-jobs: 1 sync-rsync-verify-metamanifest: no You are looking for the section called Repositories and then Location. If you have any overlays active, those should show below that. Dale :-) :-)
Re: [gentoo-user] no ebuilds for telegram
On 2020-05-14 16:12, Ashley Dixon wrote: PORTDIR shouldn't be used; it has been deprecated in favour of the `location` attribute in repos.conf. Thanks for the correction. I thought I remembered seeing a comment in make.conf about that, but the stage3 version still had it as of my most recent install, and I try to tread lightly in make.conf so its still there. The question for n952162 then comes whether the location attribute has been changed.
Re: [gentoo-user] no ebuilds for telegram
On 05/14/20 22:46, Rich Freeman wrote: On Thu, May 14, 2020 at 4:13 PM n952162 wrote: Action: sync for repo: gentoo, returned code = 0 * An update to portage is available. It is _highly_ recommended * that you update portage now, before any other packages are updated. * To update portage, run 'emerge --oneshot portage' now. ...and? Did you update portage as it was _highly_ recommended that you do so first? What version of portage are you using? This appears on the top line of emerge --info. $ emerge --info Portage 2.3.49 (python 3.6.5-final-0, default/linux/x86/17.0, gcc-7.3.0, glibc-2.26-r7, 4.14.65-gentoo x86_64)
Re: [gentoo-user] no ebuilds for telegram
On 05/14/20 23:03, Matt Connell (Gmail) wrote: On 2020-05-14 15:29, n952162 wrote: $ lf /usr/portage/net-im/telegram-desktop Manifest telegram-desktop-2.1.1.ebuild files/ telegram-desktop-2.1.2.ebuild metadata.xml telegram-desktop-2.1.3.ebuild telegram-desktop-2.0.1-r1.ebuild telegram-desktop-2.1.4.ebuild telegram-desktop-2.1.0.ebuild telegram-desktop-2.1.6.ebuild Hmm. Seems you have the ebuild for the latest (as of today) version, as I do, but when you try to use the ebuild, emerge isn't finding it. Do you have an alternative PORTDIR defined in /etc/portage/make.conf or anywhere else? The default is /usr/portage, according to both of my systems. $ grep PORT /etc/portage/make.conf PORTDIR="/usr/portage"
Re: [gentoo-user] no ebuilds for telegram
On Thu, May 14, 2020 at 04:03:16PM -0500, Matt Connell (Gmail) wrote: > Do you have an alternative PORTDIR defined in /etc/portage/make.conf or > anywhere else? The default is /usr/portage, according to both of my > systems. PORTDIR shouldn't be used; it has been deprecated in favour of the `location` attribute in repos.conf. See bug #546210 and [1]. Anyway, modern systems should really migrate to /var/db/repos just for the sake of uniformity across the Gentoo community. [1] https://wiki.gentoo.org/wiki//etc/portage/make.conf#PORTDIR -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] no ebuilds for telegram
On 2020-05-14 15:29, n952162 wrote: $ lf /usr/portage/net-im/telegram-desktop Manifest telegram-desktop-2.1.1.ebuild files/ telegram-desktop-2.1.2.ebuild metadata.xml telegram-desktop-2.1.3.ebuild telegram-desktop-2.0.1-r1.ebuild telegram-desktop-2.1.4.ebuild telegram-desktop-2.1.0.ebuild telegram-desktop-2.1.6.ebuild Hmm. Seems you have the ebuild for the latest (as of today) version, as I do, but when you try to use the ebuild, emerge isn't finding it. Do you have an alternative PORTDIR defined in /etc/portage/make.conf or anywhere else? The default is /usr/portage, according to both of my systems.
Re: [gentoo-user] no ebuilds for telegram
On Thu, May 14, 2020 at 4:13 PM n952162 wrote: > > Action: sync for repo: gentoo, returned code = 0 > > * An update to portage is available. It is _highly_ recommended > * that you update portage now, before any other packages are updated. > > * To update portage, run 'emerge --oneshot portage' now. ...and? Did you update portage as it was _highly_ recommended that you do so first? What version of portage are you using? This appears on the top line of emerge --info. -- Rich
Re: [gentoo-user] no ebuilds for telegram
Oops ... $ lf /usr/portage/net-im/telegram-desktop Manifest telegram-desktop-2.1.1.ebuild files/ telegram-desktop-2.1.2.ebuild metadata.xml telegram-desktop-2.1.3.ebuild telegram-desktop-2.0.1-r1.ebuild telegram-desktop-2.1.4.ebuild telegram-desktop-2.1.0.ebuild telegram-desktop-2.1.6.ebuild On 05/14/20 22:19, Rich Freeman wrote: On Thu, May 14, 2020 at 4:13 PM n952162 wrote: $ lf /var/db/pkg This is NOT your package repository and you should not ever touch anything in there unless you REALLY know what you're doing. You may end up having to reinstall everything on your system at the very least to fix the resulting damage. You can find the location of your package repositories by running emerge --info, and looking for the repositories section. Each repository (such as the gentoo repo) will have a location field which is the path to its location on your disk.
Re: [gentoo-user] no ebuilds for telegram
On Thu, May 14, 2020 at 4:13 PM n952162 wrote: > > $ lf /var/db/pkg This is NOT your package repository and you should not ever touch anything in there unless you REALLY know what you're doing. You may end up having to reinstall everything on your system at the very least to fix the resulting damage. You can find the location of your package repositories by running emerge --info, and looking for the repositories section. Each repository (such as the gentoo repo) will have a location field which is the path to its location on your disk. -- Rich
Re: [gentoo-user] no ebuilds for telegram
On 05/14/20 21:59, Matt Connell (Gmail) wrote: On 2020-05-14 14:10, n952162 wrote: emerge: there are no ebuilds to satisfy "net-im/telegram-desktop". As others have said, your local repository is out of date. Suggest an emerge-webrsync or emerge --sync and trying again. I'm not interested in the binary version. There's this: https://packages.gentoo.org/packages/net-im/telegram-desktop I have this package in my local repositories. Though, I didn't know it existed before today; I've been using the -bin package myself. I might have to make the switch. ... Action: sync for repo: gentoo, returned code = 0 * An update to portage is available. It is _highly_ recommended * that you update portage now, before any other packages are updated. * To update portage, run 'emerge --oneshot portage' now. $ lf /var/db/pkg acct-group/ app-text/ mail-mta/ net-nds/ sys-power/ app-accessibility/ app-vim/ media-fonts/ net-print/ sys-process/ app-admin/ dev-db/ media-gfx/ net-wireless/ virtual/ app-arch/ dev-lang/ media-libs/ perl-core/ www-client/ app-cdr/ dev-libs/ media-sound/ sys-apps/ x11-apps/ app-crypt/ dev-perl/ media-video/ sys-auth/ x11-base/ app-dicts/ dev-python/ net-analyzer/ sys-block/ x11-drivers/ app-editors/ dev-qt/ net-dialup/ sys-boot/ x11-libs/ app-emulation/ dev-ruby/ net-dns/ sys-devel/ x11-misc/ app-eselect/ dev-util/ net-firewall/ sys-firmware/ x11-plugins/ app-misc/ dev-vcs/ net-libs/ sys-fs/ x11-terms/ app-portage/ gnome-base/ net-mail/ sys-kernel/ x11-themes/ app-shells/ mail-client/ net-misc/ sys-libs/ x11-wm/
Re: [gentoo-user] no ebuilds for telegram
On 5/14/20 3:57 PM, n952162 wrote: On 05/14/20 21:28, Rich Freeman wrote: On Thu, May 14, 2020 at 3:10 PM n952162 wrote: I tried to emerge net-im/telegram-desktop but it said: emerge: there are no ebuilds to satisfy "net-im/telegram-desktop". Are you sure there is nothing wrong with your local repository? I assume you're running an amd64 system/profile based on your accept_keywords change? Yes. Nothing particularly exciting is going on with that package as far as I can tell from the git log. Have you tried looking at your repository in the net-im directory to see if it is there? What happens if you run an emerge --sync - you don't get any errors? No, I have no /var/db/pkg/net-im directory, even after running emerge --sync. Where is your portage tree? Do you have anything at all under /var/db/pkg? What about /usr/portage/... Have you changed any of the defaults in your make.conf? I'm running profile 17.1, desktop. Do I have to do something special to get net-im? No, it is just another group in the portage tree. If you are missing it, as others have suggested, you probably have some configuration issue somewhere under /etc/portage. It does seem odd that portage would offer you net-im/telegram-desktop-bin but not net-im/telegram-desktop. Have the permissions on the net-im folder or anything under it gotten weird?
Re: [gentoo-user] no ebuilds for telegram
On 2020-05-14 14:10, n952162 wrote: emerge: there are no ebuilds to satisfy "net-im/telegram-desktop". As others have said, your local repository is out of date. Suggest an emerge-webrsync or emerge --sync and trying again. I'm not interested in the binary version. There's this: https://packages.gentoo.org/packages/net-im/telegram-desktop I have this package in my local repositories. Though, I didn't know it existed before today; I've been using the -bin package myself. I might have to make the switch.
Re: [gentoo-user] no ebuilds for telegram
On 05/14/20 21:28, Rich Freeman wrote: On Thu, May 14, 2020 at 3:10 PM n952162 wrote: I tried to emerge net-im/telegram-desktop but it said: emerge: there are no ebuilds to satisfy "net-im/telegram-desktop". Are you sure there is nothing wrong with your local repository? I assume you're running an amd64 system/profile based on your accept_keywords change? Yes. Nothing particularly exciting is going on with that package as far as I can tell from the git log. Have you tried looking at your repository in the net-im directory to see if it is there? What happens if you run an emerge --sync - you don't get any errors? No, I have no /var/db/pkg/net-im directory, even after running emerge --sync. I'm running profile 17.1, desktop. Do I have to do something special to get net-im?
Re: [gentoo-user] no ebuilds for telegram
On Thu, May 14, 2020 at 3:10 PM n952162 wrote: > > I tried to emerge net-im/telegram-desktop > but it said: > > emerge: there are no ebuilds to satisfy "net-im/telegram-desktop". > Are you sure there is nothing wrong with your local repository? I assume you're running an amd64 system/profile based on your accept_keywords change? Nothing particularly exciting is going on with that package as far as I can tell from the git log. Have you tried looking at your repository in the net-im directory to see if it is there? What happens if you run an emerge --sync - you don't get any errors? In theory you can just delete the entire repository directory and run emerge --sync again to re-create a clean version if in doubt. Also, do a grep -r telegram in /etc/portage and see if the package is mentioned in any of your config files. Oh, and while your email seems to be using standard ASCII, make sure you're not copy/pasting em-dashes or anything non-ASCII into your terminal. I have no idea how portage handles such things but if you paste a utf8 em-dash into the package name I wouldn't be surprised if it doesn't find it. -- Rich
Re: [gentoo-user] no ebuilds for telegram
On Thu, May 14, 2020 at 09:10:56PM +0200, n952162 wrote: > I tried to emerge net-im/telegram-desktop > but it said: > > emerge: there are no ebuilds to satisfy "net-im/telegram-desktop". > > emerge: searching for similar names... > emerge: Maybe you meant any of these: net-im/telegram-desktop-bin, > net-misc/grdesktop, net-im/mattermost-desktop-bin? > > I'm not interested in the binary version. There's this: > >https://packages.gentoo.org/packages/net-im/telegram-desktop > > I tried adding this to /etc/portage/package.accept_keywords because the > newest versions are shown in yellow: > >net-im/telegram-desktop ~amd64 > > but it didn't help. The error message you received doesn't indicate a masked package, so adding to package.accept_keywords will not help. "There are no ebuilds to satisfy..." indicates that it cannot find the package---masked or otherwise---in the local Portage tree. Do you have the directory `/var/db/repos/gentoo/net-im/telegram-desktop` ? If not, try an emerge-webrsync. -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
[gentoo-user] GCC 10.1 SUCKS.
IMNSHO GCC 10-1 is the suckeyest pile of sucking suck that ever did suck I am going to have to base my system on 9.3... KDE really can't update itself, I really had to flog the living bleep out of it to get it, and a lot of other stuff to settle down... The configure phases for most of these packages are so monsterously inefficient that I have to run dozens of builds concurently to get CPU utilization out of the single digits... Okay, I have a high-end processor rn but it's crazy watching the actual compile stages of various packages only blip the histogram for a fraction of a second... Here are some highlights from the fails that I consider "hard fails": Dependency of libreoffice: Libetonyek -I/usr/include/libxml2 -DNDEBUG -DLIBETONYEK_VISIBILITY -fvisibility=hidden -march=native -pipe -O3 -Wall -Wextra -Wshadow -pedantic -Weffc++ -c -o contexts/libetonyek_internal_la-IWORKLayoutElement.lo `test -f 'contexts/IWORKLayoutElement.cpp' || echo './'`context s/IWORKLayoutElement.cpp /bin/sh ../../libtool --tag=CXX --mode=compile x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../.. -DBOOST_SPIRIT_USE_PHOENIX_V3 -DLIBETONYEK_BUILD -I../../inc -I../../src/lib/contexts -I/usr/include/libxml2 -I/usr/include/mdds-1.5 -I/usr/include/librevenge-0.0 -I/usr/include/libxml2 -DNDEBUG -DLIBETONYEK_VISIBILITY -fvisibility=hidden -march=native -pipe -O3 -Wall -Wextra -Wshadow -pedantic -Weffc++ -c -o contexts/libetonyek_internal_la-IWORKLineElement.lo `test -f 'contexts/IWORKLineElement.cpp' || echo './'`contexts/IW ORKLineElement.cpp NUM3Parser.cpp: In member function ‘virtual bool libetonyek::NUM3Parser::parseDocument()’: NUM3Parser.cpp:46:8: error: ‘for_each’ is not a member of ‘std’ 46 | std::for_each(sheetListRefs.begin(), sheetListRefs.end(), std::bind(::parseSheet, this, std::placeholders::_1)); | ^~~~ Eigensux!!! removed '/var/tmp/portage/dev-cpp/eigen-3.3.7/work/eigen-3.3.7/cmake/FindLAPACK.cmake' * Hardcoded definition(s) removed in CMakeLists.txt: * set(CMAKE_BUILD_TYPE "Release") * Only gcc version(s) 4.7 4.8 4.9 5.3 5.4 6.3 6.4 7.2 7.3 8.2 8.3 are supported, * of which none is installed -- The vaccine is a LIE. Powers are not rights.
[gentoo-user] no ebuilds for telegram
I tried to emerge net-im/telegram-desktop but it said: emerge: there are no ebuilds to satisfy "net-im/telegram-desktop". emerge: searching for similar names... emerge: Maybe you meant any of these: net-im/telegram-desktop-bin, net-misc/grdesktop, net-im/mattermost-desktop-bin? I'm not interested in the binary version. There's this: https://packages.gentoo.org/packages/net-im/telegram-desktop I tried adding this to /etc/portage/package.accept_keywords because the newest versions are shown in yellow: net-im/telegram-desktop ~amd64 but it didn't help. Can I emerge this as source?
Re: [gentoo-user] a day of PAIN.
> On 2020-05-12, at 18:45, Alan Grimes wrote: > > Why is this not a forced-on setting for any machine with UEFI enabled? I > can't imagine that this would be unacceptable for more than 0.001% of > the install base. Because not every user has UEFI and many just use the BIOS compatibility layer (CSM) if they don't care about UEFI and Secure Boot. The CSM is going to be there for a very long time. If you don't need UEFI features, then there's nothing really wrong with using CSM. I am using UEFI because I like having a signed kernel and signed boot loader (systemd-boot). -- Andrew
Re: [gentoo-user] Building packages in different prefix without rebuilding system packages
On 5/14/20 7:55 AM, Neil Bothwick wrote: > On Thu, 14 May 2020 18:17:06 +0800, Pengcheng Xu wrote: > >> That seems interesting. Do we need to include Portage install prefix >> (/var/tmp/portage/category/package/..., the image path prefix before >> actually merging with /)? >> >> Regards, > > No, just the --prefix=/home/blah/ that you want added to the ./configure > invocation. > This is a good way to install packages that you've built by hand into (say) your home directory, but it will cause problems if you try to trick portage into doing it. The big problem is that no other packages are going to know where to find the thing you just installed. Everything else in the Gentoo repository is designed to use standard values of PATH, LD_LIBRARY_PATH, the compiler's include dir, PKG_CONFIG_PATH, etc. If you take one program and put it somewhere non-standard, then every package depending on it is going to break. If you install an *additional* copy (built by hand) in your home directory, that's fine -- the system copy will still be in the right place -- you just don't want to hide the system copy where nobody can find it.
RE: [gentoo-user] Building packages in different prefix without rebuilding system packages
> -Original Message- > From: Neil Bothwick > Sent: Thursday, May 14, 2020 7:56 PM > To: gentoo-user@lists.gentoo.org > Subject: Re: [gentoo-user] Building packages in different prefix without > rebuilding system packages > > On Thu, 14 May 2020 18:17:06 +0800, Pengcheng Xu wrote: > > > That seems interesting. Do we need to include Portage install prefix > > (/var/tmp/portage/category/package/..., the image path prefix before > > actually merging with /)? > > > > Regards, > > No, just the --prefix=/home/blah/ that you want added to the ./configure > invocation. That's pretty neat! > > Please don't top post, and definitely don't quote previous mails after your > signature separator as some mail clients are configured to exclude sigs from > quoted replies. > Sorry for that. It's a shame that Outlook does not provide an option for signature location in replies... (using Windows for daily office stuff, please don't roast me :) > > -- > Neil Bothwick > > "Self-explanatory": technospeak for "Incomprehensible & undocumented" Regards, -- Pengcheng Xu https://jsteward.moe openpgp-digital-signature.asc Description: PGP signature
Re: [gentoo-user] Building packages in different prefix without rebuilding system packages
On Thu, 14 May 2020 18:17:06 +0800, Pengcheng Xu wrote: > That seems interesting. Do we need to include Portage install prefix > (/var/tmp/portage/category/package/..., the image path prefix before > actually merging with /)? > > Regards, No, just the --prefix=/home/blah/ that you want added to the ./configure invocation. Please don't top post, and definitely don't quote previous mails after your signature separator as some mail clients are configured to exclude sigs from quoted replies. -- Neil Bothwick "Self-explanatory": technospeak for "Incomprehensible & undocumented" pgpq0iwPPlVlO.pgp Description: OpenPGP digital signature
RE: [gentoo-user] Building packages in different prefix without rebuilding system packages
That seems interesting. Do we need to include Portage install prefix (/var/tmp/portage/category/package/..., the image path prefix before actually merging with /)? Regards, -- Pengcheng Xu https://jsteward.moe > -Original Message- > From: Neil Bothwick > Sent: Thursday, May 14, 2020 6:07 PM > To: gentoo-user@lists.gentoo.org > Subject: Re: [gentoo-user] Building packages in different prefix without > rebuilding system packages > > On Thu, 14 May 2020 16:46:58 +0800, Pengcheng Xu wrote: > > > What you're trying to achieve sounded a lot like `./configure > > --prefix=...` to me. If you're just dealing a small amount of things, > > I would suggest modifying the ebuild (in a local overlay) and changes > > where the program installs to. > > You may be able to avoid modifying ebuilds by setting the --prefix option in > $EXTRA_ECONF. > > > -- > Neil Bothwick > > Top Oxymorons Number 8: Tight slacks openpgp-digital-signature.asc Description: PGP signature
Re: [gentoo-user] Building packages in different prefix without rebuilding system packages
On Thu, 14 May 2020 16:46:58 +0800, Pengcheng Xu wrote: > What you're trying to achieve sounded a lot like `./configure > --prefix=...` to me. If you're just dealing a small amount of things, > I would suggest modifying the ebuild (in a local overlay) and changes > where the program installs to. You may be able to avoid modifying ebuilds by setting the --prefix option in $EXTRA_ECONF. -- Neil Bothwick Top Oxymorons Number 8: Tight slacks pgppMyHeMnzca.pgp Description: OpenPGP digital signature
[gentoo-user] Building packages in different prefix without rebuilding system packages
Hi, Is there a way of installing packages in a different prefix while still using system packages? I've tried setting EPREFIX, however doing that will install all dependencies in the prefix, even if there are already installed in the system. I was hoping to install some packages in user directories, but I also don't want to duplicate the packages installed globally. For example, most packages eventually depend on gcc, which I definitely don't want to compile twice. So ideally, only dependencies that are not installed globally should be pulled in. I was not able to find a way of doing that, but I feel like it shouldn't be too hard, because EPREFIX almost does what I want. Does someone know if it's possible without too much tweaking? Thanks, -François-Xavier
RE: [gentoo-user] Building packages in different prefix without rebuilding system packages
François-Xavier's first email didn't make its way to my inbox, so I'm replying to this one instead. EPREFIX is specifically designed for the Gentoo Prefix project [1]. In a word, Portage installs _everything_ inside the prefix, and uses nothing except the kernel (and some user files under home) outside the prefix. It is widely used in supercomputing and corporate infrastructure where the user does not have escalated permissions and the existing packages are too old or missing (CentOS 5) for whatever the user is trying to do. What you're trying to achieve sounded a lot like `./configure --prefix=...` to me. If you're just dealing a small amount of things, I would suggest modifying the ebuild (in a local overlay) and changes where the program installs to. That means no special handling on Portage's side, just the app's installed to somewhere else rather than the default prefix (in most cases '/usr'). [1]: https://wiki.gentoo.org/wiki/Project:Prefix Regards, -- Pengcheng Xu https://jsteward.moe > -Original Message- > From: Dale > Sent: Thursday, May 14, 2020 1:14 PM > To: gentoo-user@lists.gentoo.org > Subject: Re: [gentoo-user] Building packages in different prefix without > rebuilding system packages > > François-Xavier Carton wrote: > > > Hi, > > Is there a way of installing packages in a different prefix while still > using system packages? I've tried setting EPREFIX, however doing that > will install all dependencies in the prefix, even if there are already > installed in the system. > > I was hoping to install some packages in user directories, but I also > don't want to duplicate the packages installed globally. For example, > most packages eventually depend on gcc, which I definitely don't want > to > compile twice. So ideally, only dependencies that are not installed > globally should be pulled in. > > I was not able to find a way of doing that, but I feel like it shouldn't > be too hard, because EPREFIX almost does what I want. Does someone know > if it's possible without too much tweaking? > > Thanks, > -François-Xavier > > > > I'm clueless on EPREFIX but if you want to avoid compiling a package twice, > would the -k option help? If you have portage set to save the binaries you > compiled before, it would install from that instead of compiling things twice. > > Just thought I'd mention just in case it would help. > > Dale > > :-) :-) openpgp-digital-signature.asc Description: PGP signature
Re: [gentoo-user] Building packages in different prefix without rebuilding system packages
On Thu, May 14, 2020 at 09:07:43AM +0100, Michael wrote: > On Thursday, 14 May 2020 06:13:33 BST Dale wrote: > > François-Xavier Carton wrote: > > > Hi, > > > > > > Is there a way of installing packages in a different prefix while still > > > using system packages? I've tried setting EPREFIX, however doing that > > > will install all dependencies in the prefix, even if there are already > > > installed in the system. > > > > > > I was hoping to install some packages in user directories, but I also > > > don't want to duplicate the packages installed globally. For example, > > > most packages eventually depend on gcc, which I definitely don't want to > > > compile twice. So ideally, only dependencies that are not installed > > > globally should be pulled in. > > > > > > I was not able to find a way of doing that, but I feel like it shouldn't > > > be too hard, because EPREFIX almost does what I want. Does someone know > > > if it's possible without too much tweaking? > > > > > > Thanks, > > > -François-Xavier > > > > I'm clueless on EPREFIX but if you want to avoid compiling a package > > twice, would the -k option help? If you have portage set to save the > > binaries you compiled before, it would install from that instead of > > compiling things twice. > > > > Just thought I'd mention just in case it would help. > > > > Dale > > > > :-) :-) > > The whole concept of EPREFIX is predicated on installing a Gentoo system > within a different path/filesystem than the / of the host installation and > being able to run it as a non-root user. As I understand it, using libraries > from the main system and potentially altering them in the process is not > going > to work without changing Gentoo's eprefix intended design. > > It should be possible to change the prefix paths selectively, in particular > the LD_LIBRARY_PATH to link binaries from within the prefix to libraries in > the host system, but I'm not sure what privileges are needed to install/run > such a hybrid linkage and how an update of the host system will break > installed packages within the EPREFIX and vice versa. We're talking of a > Frankenstein build here with the potential of install operations on one > system > would be breaking the other, including portage itself. > > With containerisation of applications there may be easier ways to achieve > what > François-Xavier is looking for. I am thinking of running sandboxed > applications in the likes of flatpack, snap, zero-install, appimage and > whatever else may have been devised lately. However, with these systems you > end up using what's already been developed and any static libraries their > devs > considered desirable. If you want a bespoke installation optimised for your > hardware and chosen compilation flags, then you are probably looking to > develop a containerised application for your own use. > > Someone more knowledgeable in both Gentoo's EPREFIX project and containerised > apps should chime in soon to offer more helpful advice. I wouldn't try to install different versions of the same package, just add new packages to the base system. But I can see your point about updates; since the base system is not aware of the prefixed one, it cannot rebuild the packages in the prefix automatically when needed. It's indeed more complex than what I hoped :(
Re: [gentoo-user] Building packages in different prefix without rebuilding system packages
On Thursday, 14 May 2020 06:13:33 BST Dale wrote: > François-Xavier Carton wrote: > > Hi, > > > > Is there a way of installing packages in a different prefix while still > > using system packages? I've tried setting EPREFIX, however doing that > > will install all dependencies in the prefix, even if there are already > > installed in the system. > > > > I was hoping to install some packages in user directories, but I also > > don't want to duplicate the packages installed globally. For example, > > most packages eventually depend on gcc, which I definitely don't want to > > compile twice. So ideally, only dependencies that are not installed > > globally should be pulled in. > > > > I was not able to find a way of doing that, but I feel like it shouldn't > > be too hard, because EPREFIX almost does what I want. Does someone know > > if it's possible without too much tweaking? > > > > Thanks, > > -François-Xavier > > I'm clueless on EPREFIX but if you want to avoid compiling a package > twice, would the -k option help? If you have portage set to save the > binaries you compiled before, it would install from that instead of > compiling things twice. > > Just thought I'd mention just in case it would help. > > Dale > > :-) :-) The whole concept of EPREFIX is predicated on installing a Gentoo system within a different path/filesystem than the / of the host installation and being able to run it as a non-root user. As I understand it, using libraries from the main system and potentially altering them in the process is not going to work without changing Gentoo's eprefix intended design. It should be possible to change the prefix paths selectively, in particular the LD_LIBRARY_PATH to link binaries from within the prefix to libraries in the host system, but I'm not sure what privileges are needed to install/run such a hybrid linkage and how an update of the host system will break installed packages within the EPREFIX and vice versa. We're talking of a Frankenstein build here with the potential of install operations on one system would be breaking the other, including portage itself. With containerisation of applications there may be easier ways to achieve what François-Xavier is looking for. I am thinking of running sandboxed applications in the likes of flatpack, snap, zero-install, appimage and whatever else may have been devised lately. However, with these systems you end up using what's already been developed and any static libraries their devs considered desirable. If you want a bespoke installation optimised for your hardware and chosen compilation flags, then you are probably looking to develop a containerised application for your own use. Someone more knowledgeable in both Gentoo's EPREFIX project and containerised apps should chime in soon to offer more helpful advice. signature.asc Description: This is a digitally signed message part.
