drobbins
-
Posts
513 -
Joined
-
Last visited
-
Days Won
282
Content Type
Profiles
Forums
Blogs
Posts posted by drobbins
-
-
Note that once you have migrated to kits, you simply need to ensure that you have the correct python3 implementation enabled using <tt>eselect python</tt> (3.4 for 3.4-prime and 3.6 for 3.6-prime) and the correct python USE settings will be set for you automatically in <tt>/etc/portage/make.profile/parent</tt> via <tt>ego update</tt>. So you should then be able to remove all the python hacks you added, which could be what's causing problems.
-
I will give you an alternate approach -- the goal is to get ego installed, and then 'ego sync; ego update' will get everything working a lot better. Try:
# cd /var/git/meta-repo/kits/core-kit/app-admin/ego # ebuild ego-2.3.0.ebuild clean merge
Ego will now be installed. You now need to install any python modules (for your active python3 implementation) to get "ego sync" and "ego update" working properly. Based on a quick look, it looks like all it needs are standard python3 modules to run. Once you successfully run "ego update", your /etc/portage/make.profile/parent will be set up properly.
You should only need to set 'special' USE variables in order to get ego to install via ebuild, as per Oleg's link.
-
For OpenRC to manage a service through an initscript, generally OpenRC (the initscript) needs to be the thing that actually starts the service. If you are having NetworkManager start the daemons, then generally it is the one that manages them. Not sure if that is the issue but OpenRC scripts are generally only going to stop what they have started. There is no hard rule for this but it is just how the system is designed to work.
-
In theory, "epro update" should update /etc/portage/make.profile/parent to reflect whatever kits you have synced to /var/git/meta-repo/kits. It may need to be run manually in some instances, but in general should run automatically and if not print an error that you should run it manually.
-
Instead of using package.use, try using /etc/make.conf and just set things globally -- temporarily -- just to ease the transition to kits. Once you get moved over to kits, the USE vars are all set properly for python auto-magically.
-
We can roll up a new tarball and update the official page in the next few days. Thanks for reminding us about this :)
-
ego-2.3.0 is now unmasked and ready for production use.
-
If you converted over yourself, then you should be all set. The one thing that is enabled on our containers that you should know about is that if the /var/git/meta-repo directory exists and you reboot your container, a read-only meta-repo directory will be mounted there and automatically updated. If you have updated yourself, just be aware that on reboot, /var/git/meta-repo will have a bind-mount on top of it and be read-only. You can get around this (and have your own locally-managed meta-repo) by ensuring you have a recent version of ego installed and set:
[global] meta_repo_path = /var/git/meta-repo-local
...and then "mv" your existing meta-repo into this location, or run 'ego sync' to do a fresh clone.
-
Hey All,
If you have a Funtoo container and would like to upgrade to kits, please contact me. I can reload your container so you can start with a 'fresh' system that is set up to work with kits from the beginning. The actual re-image process takes about 5 minutes to complete. It does require that you back up your important data, and once reloaded, your container will need your favorite apps emerged again.
Regards,
Daniel
-
-
Yes, this is more an issue of a bad error message that is confusing rather than anything else. Adding "www-servers/apache threads" to /etc/portage/package.use or /etc/portage/package.use/apache should fix this as then all the deps should be happy.
@Oleg Vinichenko, I do think that this is probably not the greatest default -- it seems like we should enable 'threads' by default to prevent this from even bothering users. Do you see any potential downside for this?
-
I would definitely restrict your troubleshooting to a single service at a time. Look at 'ps axu' and 'ps axu --forest' to be extra sure that the daemon is not running. You should be able to work-around this with the 'service foo zap' command (or /etc/init.d/scriptname zap) which will reset the 'running' status to 'not running' in the case that the daemon has died for some reason.
For extended troubleshooting, I recommend trying to start the daemon from the command-line with very similar options to how it is started from the script, but run it in debug mode so you get more output (you can often also run the daemon so it doesn't detach and will output the debug info to your console.)
Good luck, and post more detailed info if you need more help.
-
It is also possible, if you are more adventurous, to get a funtoo container and configure it with a pentium4 chroot, and set this up as a build server for your laptop.
Also note that you will want to run "current" with kits, which is the replacement for funtoo-stable, which we've deprecated. You will get a similar set-up with funtoo-current and our 'prime' kits as you would with stable. (though you might consider using the 1.19-prime xorg-kit as well as the 3.6-prime python-kit, as these are currently high-quality and suitable for a stable system.)
-
-
Sandro, I actually encountered this problem where a package upgrade caused my printing to stop working. I should have filed a bug -- I think I needed to recompile cups-filters to deal with an update to a pdf library? I can't recall exactly. Definitely an issue where I think cups-filters should have a slot dependency on a particular library it uses. I think it may have been the upgrade from qpdf 6 to 7, which makes cups-filters need a rebuild (and no slot dep to trigger this)
-
This has been hit by a few users and is fixed in ego-2.3.0, which is available for testing. The workaround is to type something like cd /tmp before running the command (ego drops permissions to run as the Portage user and git freaks out if it can't read the current working directory.)
-
ego-2.3.0 has been released and will be appearing in the tree in the next few hours. It is currently keyword masked but is available for testing and evaluation. It should be considered beta software for end-users -- our developers will be testing it but you are free to do so as well. Several bugs have been fixed (meta-repo sync robustness, avoiding a failure when run in a root-only-readable current working directory), and in addition several unit tests have been added, the entire code base has been heavily refactored, including a completely rewritten internal API for ego profile management.
Best Regards,
Daniel
-
And it does appear that this was the issue - and it's fixed in our git version of ego and should be fixed in our next release. Until then, if you have the issue, type "cd /tmp" and re-run the command and it should work :)
-
This may be caused by being in a directory that is not readable by the portage user when you run the ego sync command. So if you see it in the future, see if changing directories to /var/tmp first helps. We are investigating to see if this is an actual bug.
-
Well meta-repo shouldn't have any branch but master. Why not just mv /var/git/meta-repo /var/git/meta-repo.bak and do an "ego sync" again? It should give you a fresh clone of everything.
-
What version of ego are you running?
-
Try using 'monkeymonkey' to log in to the bug tracker. For some reason, the code in the forums is allowing you to sign in with your full name, but really you should have used your username. I can sync the accounts if you are ok being 'monkeymonkey' in both places.
-
Note that while meta-repo has submodules for backwards-compatibility purposes, they are not officially used anymore, and new versions of ego will manage the syncing of kits directly. They can be useful in a pinch and there is no harm in using 'git submodule init/update' in a rescue situation.
-
Are you still having the issue? I'm wondering if it was an intermittent bug triggered by the addition of lang-kit.
new ego and inactive kit branches
in General Discussion
Posted
Yes, we will. And we are working on making 1.19-prime the default X implementation in a few days. Oleg is in the process of adding some CVE fixes and bumping mesa to a non-rc version.