Re: [gentoo-user] speedup remote portage
Hi Rich, I will experiment with a local metadata - that seems like it might give a worthwhile speedup (its currently about 910Mb so not too big) Bill K. On 28/2/20 3:44 am, Rich Freeman wrote: > On Thu, Feb 27, 2020 at 2:27 PM james wrote: >> On 2/26/20 7:08 PM, William Kenworthy wrote: >>> Hi, >>> >>> ��� due to space considerations on my laptop I have moved portage >>> onto a >>> network share (moosfs, mfsmounted) - slower but works fine.� However, >>> being a laptop trying to update/install when out and about is both very >>> slow and network intensive through a vpn - again, it works but is even >>> slower to the point of not always being practical >>> >>> Is there a way to localise/speedup portage scanning parts of the >>> update/install process? >> >> A simpler, much less sophisticated update, what I do is >> use emerge -f option to 'fetch only' option first. The selectively >> update; or you can use a usb-3.1+ device for fast easy upgrades, due to >> laptop limitations, but the communications data channel limitations >> leave you at the mercy of the available wireless bandwidth characteristics. > So, a few thoughts here: > > 1. Definitely make sure you're splitting out distfiles. Any new > install does this already, but mixing up the tree and distfiles is > mixing very different types of data with different requirements. > 2. Consider whether you REALLY need to share all this stuff. The > whole tree isn't THAT big, so it might be easier to just locally sync. > If network bandwidth is an issue, consider setting up a local mirror > so that you sync (and fetch distfiles) within your network when > available, and then just sync directly from the internet when you're > remote. > 3. If you REALLY need that portage tree to be on the network, > consider keeping just the metadata directory local. That can be > generated on-demand or synced, but either way it needs to be updated > anytime the repo itself is updated. Generally with rsync we > distribute both together. I suspect that having local metadata will > cut down on your network IO when you're doing dep resolution/etc. > 4. Squashfs was mentioned. In theory that is a nice compact > solution. In practice you might find it to be a pain to update since > it is read-only. But you could update your network tree, then create > a squashfs and stick that on your network, and then sync the squashfs > file for local mounting. > > I'm not sure how well moosefs performs for this sort of thing in > general. I personally use lizardfs to store large multimedia files > and it works fine, but streaming multi-GB multimedia that ends up > getting buffered is a very different access pattern than sourcing a > bazillion ebuild scripts. I'd be interested in how you're liking > moosefs for this sort of thing in general. For accessing tons of > little files I think all your latencies matter, but in particular you > want low latency to your master server as that is going to end up > limiting every read/open you perform. You might be able to play with > the cache settings on the client side, though at least in lizardfs > I've found some of those to be buggy - they're generally passed as > mount options. > > In the past I've had one main Gentoo box sync its repo from the web, > and had other hosts in the LAN either bind-mount this (containers), or > sync this over the network. Likewise I generally share my main host > distfiles as a mirror which is preferentially used by all my other > hosts - you don't get a 100% hit rate and the main host won't get a > copy of missed files, but it probably cuts down on 80+% of the network > fetching as long as the main host does its fetches before the other > hosts do. If the main host lacks a distfile then the MIRRORS setting > has a regular Gentoo mirror listed next. > > Honestly, unless you're running a completely private repo for whatever > reason I would not try to go remotely mounting your repo over the > internet from your moosefs server. I bet you could fetch anything > needed faster from a regular internet mirror in that case, and if > portage could use mirrors seamlessly over internet latencies chances > are we'd all be doing that already. Pretty much every distro > maintains a local repo on every host for this reason. >
Re: [gentoo-user] speedup remote portage
On 27/2/20 3:51 pm, Robert Bridge wrote: >> On 27 Feb 2020, at 00:08, William Kenworthy wrote: >> >> Hi, >> >> due to space considerations on my laptop I have moved portage onto a >> network share (moosfs, mfsmounted) - slower but works fine. However, >> being a laptop trying to update/install when out and about is both very >> slow and network intensive through a vpn - again, it works but is even >> slower to the point of not always being practical >> >> Is there a way to localise/speedup portage scanning parts of the >> update/install process? >> > I used to use a portage tree shared over NFS. One thing that is worth > considering, if you haven’t, is having the remote host manage tree syncing. > This would remove the need for the laptop to be involved in the sync. > > Also, I generally would try to avoid updating the system while out and about, > so that when I am updating it is a local network operation. Obviously this > won’t work if you need a package when out and about, but if you are local to > the server every night or couple of nights, it would significantly reduce the > pain of updates. > > Cheers, > RobbieAB. > All good ideas - currently the portage tree is common to ~20 odd gentoo systems, mostly similar hardware but also some vms's. This is what I have pointed the latop at. I used http-replicator for distfiles for years but its recently been deprecated for tree-cleaning (I think) so there is now an mfs mounted common distfiles (also outside the portage directory). Same with the common package files - they are extensive but live outside the tree in different folders depending on hardware type. I already have an arm host dedicated to updating portage and building arm32 packages for -K install on compatible systems - that all works great and has been running well for quite awhile. Originally I used a git synced portage master with local git syncing for each host. I have converted it to a single git synced portage mfs mounted read only via mfs on each host which while much slower, its less fussy and works well except when the laptop is off-site. I was hoping there was some way to cache portage operations and reuse them as doing a simple emerge -p world will take 30 minutes or more and pull a lot of network traffic - and if something fails it starts all over again. Once the scanning is done actual merges are fine with only a small time increase. BillK
Re: [gentoo-user] Rasp-Pi-4 Gentoo servers
On 2/27/20 9:53 PM, Dale wrote: james wrote: 5G + gentoo + embedded toys, is going to be FUN FUN FUN. Then I'll be off to other states, via a hacked out Redneck camper.. and too many microProcessors Thanks Rich, your insights and comments are always most welcome. James Off topic a bit but a question.� Would one of these Rasp-Pi-4 thingys make a NAS hard drive server? Sure, but, there may be a better solution, something all ready out there and it really depends on refining your needs, current and in the future. So lets refine your specifications (centric to your needs + growth) and figure out what and how much you need. Then we can survey the embedded-thingies, that meet your specs, with a bit of room for growth, OK? I have a Cooler Master HAF-932 case Wow, that's big. What the number and capacity (TB) of your existing hard-drives? How much more storage do you want? Replacing drives with larger capacity, might be all you need to do? but even it is running out of hard drive space.� I'm thinking about building a NAS box, taking sheet metal and bending it until it looks like a box. OK, so we first spec out options, then let you decide. Then you can 'bargain shop' for appropriate housing/rack/open chassis, etc. Thing is, it needs a small puter to take data from the drives to the network and vice-versa. embedded are not only small, they can have extended temperature ranges of tolerance, use drastically less power and many other features. If it's purposed hardware, that is only a few things todo, then yes embedded uP (abbrev for microProcessor) are the way to go. Running off of 12VDC, means an old car battery and a connection to your solar panels (assuming you have those) and it's zero on your electric bill. There is usually a vast array of tax and other incentives, particularly with solar in Ag businesses. I've never even seen one of those things, except on my monitor, so I have no idea what all they are capable of. Dale, you are pretty strong with Gentoo Linux, so putting a stripped, purposed, minimized gentoo derivative stack, with far less ebuilds, to work for your operations, is going to be quite fun. On a farm or ranch, there are a myriad of things you can do with embedded boards and gentoo-stripped. You can replace many of those expensive (vendor) systems with embedded boards +sensors +controls codes and lots of wires to do most anything. Let's focus on your NAS for now. I figure a lot of SATA connectors and a ethernet connection plus enough CPU power and memory to get the job done. SATA, was great years ago. Still it makes sense to use, if you already have them. Storage going forward is the process of faster and cheaper and leaving SATA behind, like ide. Still useful, but a power hog. So we'll start out with interfacing your existing SATA drives to the embedded board, and look/decide on options for newer Solid State Data storage options. � https://en.wikipedia.org/wiki/USB You might not even need many sata ports. usb3 and the upcoming usb4 have tons of bandwidth (date/time). Mechanical Hard drives are on the way out. Too expensive and failure prone. SSd and other types of storage, might be right for you, or a mixture. USB stick memory can be huge, very low power draw and very inexpensive. A hybrid of several types of memory storage may be useful to experiment with. You may want to categorize your long term storage: some accessed often, others maybe once a year? For data storage, long term important stuff, you should employ RAID (1-10). We can get into that later, duplication of important data, via backups or extra storage is a good idea too. Backups are an old technology, but may help, but backups do can get old too and fragmented. For now, lets not worry so much about long term bit integrity, but focus on your next FUN gentoo rig. I'm hoping other join in to so you have more than my prospective on your solution. If those things are capable of doing that fairly easily.� After all, I'm me.� :/ OK, so let's survey some system, you can just purchase with gentoo preinstalled, or a very easy pathway to embedded gentoo. Let's look at a few, have some of the other guys jump in, and find you a solution, to start with. Most will be expandable, and you can figure out the casing, mounting, power and such. At this stage, it mostly a research effort and then deciding your features/price. If you do not have massive bandwitdh requirements, I'm sure we can find you a very cost effective, DC powered solution. Just so you know, I use that fancy $300 OPtima 12vdc charger, and Optima batteries. the charger reconditions most batteries, if they are not beyond saving, even cheap lead-acid batteries. Every Farmer should have one, imho. The Digital 1200 is just awesome. https://www.optimabatteries.com/en-us/battery-charger If you like, you can read up on blue, red and yellow top versions and
Re: [gentoo-user] Rasp-Pi-4 Gentoo servers
james wrote: > > > 5G + gentoo + embedded toys, is going to be FUN FUN FUN. > > > Then I'll be off to other states, via a hacked out Redneck > camper.. and too many microProcessors > > > Thanks Rich, your insights and comments are always most welcome. > > > James Off topic a bit but a question. Would one of these Rasp-Pi-4 thingys make a NAS hard drive server? I have a Cooler Master HAF-932 case but even it is running out of hard drive space. I'm thinking about building a NAS box, taking sheet metal and bending it until it looks like a box. Thing is, it needs a small puter to take data from the drives to the network and vice-versa. I've never even seen one of those things, except on my monitor, so I have no idea what all they are capable of. I figure a lot of SATA connectors and a ethernet connection plus enough CPU power and memory to get the job done. If those things are capable of doing that fairly easily. After all, I'm me. :/ Just curious. Dale :-) :-)
Re: [gentoo-user] Rasp-Pi-4 Gentoo servers
On 2/27/20 4:49 PM, Rich Freeman wrote: On Thu, Feb 27, 2020 at 4:25 PM james wrote: Yea, I was not clear. I'd run the mail-server, on a 'cluster' (4 or more), not an individual pi-board unless it was beef up, processor and ram wise. Gig E would also be on my list. Unless you have some niche need I wouldn't generally run servers on Pis. The biggest issue with ARM is that all the cheap platforms are starved for RAM, and RAM is one of the biggest issues when running services. And of course the Pi in particular has IO issues (as do many other cheap SBCs but this is less of an ARM issue). The RAM issue isn't so many an ARM issue as a supply/demand thing - the only people asking for 64GB ARM boards are big companies that are willing to pay a lot for them. I do actually run a few services on Pis - DNS, DHCP, and a VPN gateway. That's about it. These are fairly non-demanding tasks that the hardware doesn't struggle with, and the data is almost entirely static so an occasional backup makes any kind of recovery trivial. The only reason I run these services on Pis is that they are fairly fundamental to having a working network. Most of my services are running in containers on a server, but I don't want to have to think about taking a server down for maintenance and then literally every IOT device in the house won't work. These particular services are also basically dependency-free which means I can just boot them up and they just do their jobs, while they remain a dependency for just about everything else on the network. When you start running DHCP in a container you have more complex dependency issues. A fairly cheap amd64 system can run a ton of services in containers though, and it is way simpler to maintain that way. I still get quick access to snapshots/etc, but now if I want to run a gentoo container it is no big deal if 99% of the time it uses 25MB of RAM and 1% of one core, but once a month it needs 4GB of RAM and 100% of 6 cores. As long as I'm not doing an emerge -u world on half a dozen containers at once it is no big deal at all. Now, if I needed some server in some niche application that needed to be able to operate off of a car battery for a few days, then sure I'd be looking at Pis and so on. Exactly. It's going to be a small RV, basically a 4x4 with a campershell. 2 Laptops with AMD64 and ram, the newest ones, are the powerhouses. One multicore with Radeon Graphics with a stand for 4x32" 4K 120MHZ screens to be mounted on the 1/2 table in front of the bench seat (my new mobile office). I'm hoping to get gcc-9 (10?) happy with auto-compiling using the AMD graphics (radeon chipsets). And a plethora of small embedded boards for a wide variety of toy-interfaces. Biggest problem? The arrival of the new roof mounted, 12VDC 21 SEER AC is delayed, due to that virus. Trying not to crank a genset, just solar, and fast-charge 12VDC battery banks; but we'll see how that goes in the Texas summer. I'm going to map out some 5G hot-spots and encourage folks in the areas to jump on a gentoo (derivative?) OS. The greater Dallas area is a hotbed for 5G testing and development. Austin is on fire with tons of new technologies too. Texas is pumping serious monies into everything 5G. It'll be an addon package for guys with tractors.. Making all of this fun and easy with Gentoo, should help grow our distro. The Texas Universities are moving to a new multi-homed private fiber network, where each link is 100G fiber based. So every campus in Texas, will soon be hotbeds for 5G R and play. Since the state of Texas has many 5G chip manufactures and many custom Rf shops, it's gonna be the worlds hotspot for 5G, imho. There's talk of Texas sharing this 100G multi-route network with Oklahoma, Arkansas and Mississippi; a brilliant move imho. Gentoo could 'own' Texas, with just a wee bit of effort. IBM taking over CoreOS(new version of RedHat) is leaving a very foul taste in many circles. 5G + gentoo + embedded toys, is going to be FUN FUN FUN. Then I'll be off to other states, via a hacked out Redneck camper.. and too many microProcessors Thanks Rich, your insights and comments are always most welcome. James
Re: [gentoo-user] Rasp-Pi-4 Gentoo servers
On Thu, Feb 27, 2020 at 4:25 PM james wrote: > > Yea, I was not clear. I'd run the mail-server, on a 'cluster' (4 or > more), not an individual pi-board unless it was beef up, processor and > ram wise. Gig E would also be on my list. > Unless you have some niche need I wouldn't generally run servers on Pis. The biggest issue with ARM is that all the cheap platforms are starved for RAM, and RAM is one of the biggest issues when running services. And of course the Pi in particular has IO issues (as do many other cheap SBCs but this is less of an ARM issue). The RAM issue isn't so many an ARM issue as a supply/demand thing - the only people asking for 64GB ARM boards are big companies that are willing to pay a lot for them. I do actually run a few services on Pis - DNS, DHCP, and a VPN gateway. That's about it. These are fairly non-demanding tasks that the hardware doesn't struggle with, and the data is almost entirely static so an occasional backup makes any kind of recovery trivial. The only reason I run these services on Pis is that they are fairly fundamental to having a working network. Most of my services are running in containers on a server, but I don't want to have to think about taking a server down for maintenance and then literally every IOT device in the house won't work. These particular services are also basically dependency-free which means I can just boot them up and they just do their jobs, while they remain a dependency for just about everything else on the network. When you start running DHCP in a container you have more complex dependency issues. A fairly cheap amd64 system can run a ton of services in containers though, and it is way simpler to maintain that way. I still get quick access to snapshots/etc, but now if I want to run a gentoo container it is no big deal if 99% of the time it uses 25MB of RAM and 1% of one core, but once a month it needs 4GB of RAM and 100% of 6 cores. As long as I'm not doing an emerge -u world on half a dozen containers at once it is no big deal at all. Now, if I needed some server in some niche application that needed to be able to operate off of a car battery for a few days, then sure I'd be looking at Pis and so on. -- Rich
Re: [gentoo-user] Rasp-Pi-4 Gentoo servers
On 2/27/20 2:51 PM, Ralph Seichter wrote: * ai...@aisha.cc: I'm not too sure that running it as a mail server is impossible. I never wrote that it is impossible, only that "I would not use it as an Internet-facing production Mailserver". That's a huge difference. You are free to do as you wish, but I still consider it an unsuitable role for a wee Rasberry Pi, considering the I/O load I see on our production mail servers. SD-Cards really don't like this sort of thing. -Ralph Yea, I was not clear. I'd run the mail-server, on a 'cluster' (4 or more), not an individual pi-board unless it was beef up, processor and ram wise. Gig E would also be on my list. There are also embedded boards, that can run gentoo, with up to 16 Gigs of DDR4 ram and better internal hardware for threads and such. I certainly, did not mean to offend you, so apologies galore. I'm not into running a mail server for more than a dozen folks and an ity-bity company of just one SD card? I'd find an embedded-board that runs (8Gbyte)DDR4 ram, so writes to the storage is very fast. It's a bit too detailed to look at the plethora of hardware available, that one can get for embedded projects and the matching (sensitive) price points. No need to go there (its a morass). thanks, James
Re: [gentoo-user] Rasp-Pi-4 Gentoo servers
* ai...@aisha.cc: > I'm not too sure that running it as a mail server is impossible. I never wrote that it is impossible, only that "I would not use it as an Internet-facing production Mailserver". That's a huge difference. You are free to do as you wish, but I still consider it an unsuitable role for a wee Rasberry Pi, considering the I/O load I see on our production mail servers. SD-Cards really don't like this sort of thing. -Ralph
Re: [gentoo-user] speedup remote portage
On Thu, Feb 27, 2020 at 2:27 PM james wrote: > > On 2/26/20 7:08 PM, William Kenworthy wrote: > > Hi, > > > > ��� due to space considerations on my laptop I have moved portage > > onto a > > network share (moosfs, mfsmounted) - slower but works fine.� However, > > being a laptop trying to update/install when out and about is both very > > slow and network intensive through a vpn - again, it works but is even > > slower to the point of not always being practical > > > > Is there a way to localise/speedup portage scanning parts of the > > update/install process? > > > A simpler, much less sophisticated update, what I do is > use emerge -f option to 'fetch only' option first. The selectively > update; or you can use a usb-3.1+ device for fast easy upgrades, due to > laptop limitations, but the communications data channel limitations > leave you at the mercy of the available wireless bandwidth characteristics. So, a few thoughts here: 1. Definitely make sure you're splitting out distfiles. Any new install does this already, but mixing up the tree and distfiles is mixing very different types of data with different requirements. 2. Consider whether you REALLY need to share all this stuff. The whole tree isn't THAT big, so it might be easier to just locally sync. If network bandwidth is an issue, consider setting up a local mirror so that you sync (and fetch distfiles) within your network when available, and then just sync directly from the internet when you're remote. 3. If you REALLY need that portage tree to be on the network, consider keeping just the metadata directory local. That can be generated on-demand or synced, but either way it needs to be updated anytime the repo itself is updated. Generally with rsync we distribute both together. I suspect that having local metadata will cut down on your network IO when you're doing dep resolution/etc. 4. Squashfs was mentioned. In theory that is a nice compact solution. In practice you might find it to be a pain to update since it is read-only. But you could update your network tree, then create a squashfs and stick that on your network, and then sync the squashfs file for local mounting. I'm not sure how well moosefs performs for this sort of thing in general. I personally use lizardfs to store large multimedia files and it works fine, but streaming multi-GB multimedia that ends up getting buffered is a very different access pattern than sourcing a bazillion ebuild scripts. I'd be interested in how you're liking moosefs for this sort of thing in general. For accessing tons of little files I think all your latencies matter, but in particular you want low latency to your master server as that is going to end up limiting every read/open you perform. You might be able to play with the cache settings on the client side, though at least in lizardfs I've found some of those to be buggy - they're generally passed as mount options. In the past I've had one main Gentoo box sync its repo from the web, and had other hosts in the LAN either bind-mount this (containers), or sync this over the network. Likewise I generally share my main host distfiles as a mirror which is preferentially used by all my other hosts - you don't get a 100% hit rate and the main host won't get a copy of missed files, but it probably cuts down on 80+% of the network fetching as long as the main host does its fetches before the other hosts do. If the main host lacks a distfile then the MIRRORS setting has a regular Gentoo mirror listed next. Honestly, unless you're running a completely private repo for whatever reason I would not try to go remotely mounting your repo over the internet from your moosefs server. I bet you could fetch anything needed faster from a regular internet mirror in that case, and if portage could use mirrors seamlessly over internet latencies chances are we'd all be doing that already. Pretty much every distro maintains a local repo on every host for this reason. -- Rich
Re: [gentoo-user] speedup remote portage
On 2/26/20 7:08 PM, William Kenworthy wrote: Hi, ��� due to space considerations on my laptop I have moved portage onto a network share (moosfs, mfsmounted) - slower but works fine.� However, being a laptop trying to update/install when out and about is both very slow and network intensive through a vpn - again, it works but is even slower to the point of not always being practical Is there a way to localise/speedup portage scanning parts of the update/install process? A simpler, much less sophisticated update, what I do is use emerge -f option to 'fetch only' option first. The selectively update; or you can use a usb-3.1+ device for fast easy upgrades, due to laptop limitations, but the communications data channel limitations leave you at the mercy of the available wireless bandwidth characteristics. Unlocked cell phones will (theoretically) allow you to temporarily-dynamically switch to another provider (carrier) for faster wireless bandwidth. It's baked into most of the 5G chipsets, and can even work with 4G channels. Many (stupid) carriers are fighting against giving to the citizens, the right to dynamically use a variety of services, and control your software stack on cell phones. Anti-competitive. Multi-homed bandwidth, for mobile needs (cell or lappy) is coming, but corruption in governments and companies is hindering what has already been 'designed in' to how Rf (wireless) bandwidth is articulated. Most regulators, are mentally 'arcane' thus technologist suffer... 1. put it on a squashfs share to save space (the laptop is running btrfs with compression so I don't think that will get me much) 2. put portage on an sd card and mount it when necessary The laptop is a Surface Pro4 so expanding the storage is not practical - though I could shrink the windows partition a little more. Maybe a usb-splitter would help? (no usb ports?) BillK hth, James
Re: [gentoo-user] Rasp-Pi-4 Gentoo servers
I'm not too sure that running it as a mail server is impossible. Depending on your expected traffic level, it should be more than capable enough to do it. My current server is only a 1 core + 1 GB VPS, which is much more lax than a pi-4. Depending on what guides you follow you can definitely set it up as a mail server. But I am curious how you are planning to do this, unless you have a static ip + reverse DNS configured? --- Aisha blog.aisha.cc On 2020-02-27 10:11, Ralph Seichter wrote: * james: I'm thinking about setting up a pair of Rasp-Pi-4 as DNS servers with 4GB of ram. Is that enough ram for a DNS server? For running the Nameservers, yes. Compiling Gentoo packages will likely put your SD-Card under stress, but that's just how it goes. My Model B Rev 2 of 2015 runs dnsmasq as DHCP server, NGINX, Postfix, Unbound and more for a bunch of clients in a LAN. It is quite nifty as a local DNS Resolver and DHCP server, because it is usually the fastest to boot after the occasional power outage. I would not use it as an Internet-facing production Mailserver, though, because that would generate a lot of I/O, which is not a Raspberry Pi strong suit. -Ralph
Re: [gentoo-user] mkvtoolnix: To use qt5 or not to use qt5 - that is the question (USE flag in-/valid?)
On 02/27 08:34, Neil Bothwick wrote: > On Thu, 27 Feb 2020 05:12:59 +0100, tu...@posteo.de wrote: > > > this command: > > emerge --selective=n @preserved-rebuild > > > > gives me this message when started: > > --- Invalid atom in /etc/portage/package.use/mkvtoolnix: qt5 > > That's not an atom, it's a USE flag. The format of package.use is > > atom USE [USE...] > > so you want something like > > media-video/mkvtoolnix qt5 > > You seem to be assuming that portage picks up the package name from the > file name, it does not. The contents of all of package.use/* are combined > as if a single file before portage does its stuff. This is all explained > in the portage man page. > > > -- > Neil Bothwick > > To most people solutions mean finding the answers. But to chemists > solutions are things that are still all mixed up. Thank you all for your help! :) I missed the 'media-video/mkvtoolnix' in front of 'qt5'. My fault...sorry for the trouble I may have created... Cheers! mcc
Re: [gentoo-user] Rasp-Pi-4 Gentoo servers
* james: > I'm thinking about setting up a pair of Rasp-Pi-4 as DNS servers with > 4GB of ram. Is that enough ram for a DNS server? For running the Nameservers, yes. Compiling Gentoo packages will likely put your SD-Card under stress, but that's just how it goes. My Model B Rev 2 of 2015 runs dnsmasq as DHCP server, NGINX, Postfix, Unbound and more for a bunch of clients in a LAN. It is quite nifty as a local DNS Resolver and DHCP server, because it is usually the fastest to boot after the occasional power outage. I would not use it as an Internet-facing production Mailserver, though, because that would generate a lot of I/O, which is not a Raspberry Pi strong suit. -Ralph
Re: [gentoo-user] mkvtoolnix: To use qt5 or not to use qt5 - that is the question (USE flag in-/valid?)
On Thu, 27 Feb 2020 05:12:59 +0100, tu...@posteo.de wrote: > this command: > emerge --selective=n @preserved-rebuild > > gives me this message when started: > --- Invalid atom in /etc/portage/package.use/mkvtoolnix: qt5 That's not an atom, it's a USE flag. The format of package.use is atom USE [USE...] so you want something like media-video/mkvtoolnix qt5 You seem to be assuming that portage picks up the package name from the file name, it does not. The contents of all of package.use/* are combined as if a single file before portage does its stuff. This is all explained in the portage man page. -- Neil Bothwick To most people solutions mean finding the answers. But to chemists solutions are things that are still all mixed up. pgpjtq0PmVs3g.pgp Description: OpenPGP digital signature
