Jump to content
funtoo forums

nrc

Members
  • Content Count

    68
  • Joined

  • Last visited

  • Days Won

    18

Everything posted by nrc

  1. Maybe a library mismatch? Have you done a full update with dependencies? emerge -auvDN @world Do you have any preserved packages? emerge -av @preserved-rebuild
  2. I'm with you on the systemd issue. But isn't Gentoo without systemd still an option? Are you resistant to it because they support systemd at all or because you sense that they're slipping in that direction? I never used Gentoo so I don't have an informed opinion on it. I came straight to Funtoo from Fedora/Redhat because Funtoo was one of the few distros that seemed to recognize the importance of maintaining a viable Linux ecosystem apart from systemd. My impression from being downstream of Gentoo is that they've become less stable recently. It was starting to feel like a trend. Creating a new release process where stability can be maintained in spite of a much smaller developer community seems like a good step for Funtoo. I think it could be communicated and rolled out a bit more smoothly at times, but I'm excited about the progress.
  3. Where is this the case? Looking at stable releases it appears that Funtoo is ahead of Ubuntu in pretty much all instances. The key question about his new model is whether they will be able to rev it on the schedule that @drobbins has suggested and whether those updates can run as smoothly as your typical emerge. If that can be successful then I don't think there will be any problem with the freshness of the releases.
  4. That's true. It's neither a rolling release or a traditional fixed released distro now. It's changing and we won't know exactly what it will become until it gets there. I think you have to kind of review what @drobbins has said about his objectives for the distro and decide if you want to go in that direction or just stick with a rolling release.
  5. There are a fair number of downgrades when moving to 1.3. 1.2 updates continued after 1.3 was frozen. Chrome and Vivaldi were the only things that were actually an issue to downgrade because they nagged about profile version mismatches. I also had a good number of dependency knots that I had to untangle. In some cases I just ended up unmerging packages that were creating major dependency issues and then reinstalling them once the upgrade was complete.
  6. Thanks. I hadn't realized that "PasswordAuthentication" doesn't affect PAM authentication. I've always secured my machines by only allowing ssh access to accounts that I specifically configure. It's @drobbins call but I still think it's a bad idea to configure ssh by default on machines where novice users may believe that their physical console is the only vector for someone to attack their trivial password. There definitely should be some documentation in the install procedure for locking that down.
  7. @drobbins nixed the sshd suggestion in FL-6294, but I looked at the latest baselayout and it looks like the default configuration has PasswordAuthentication set to "no" which should minimize any risk. I still think it's better not to have this running if it's not needed or specifically wanted. My build process always includes setting openssh the configuration according to my standards but there's some risk there for the unaware if openssh is compromised.
  8. I agree that the status of the different releases should be better documented. Updates to 1.2 just kind of ended. The 1.3 release was communicated but if it was discussed how that would impact 1.2 then it was easily missed. One thing that should be clearly laid out is that part of the objective (as I understand it) is to minimize all the firefighting that occurs in a rolling release so that devs can focus on advancing the platform. That's a good idea in theory, but can you put off all that firefighting and still maintain a release schedule that keeps things fresh? And what is the standard for what will be updated outside of the normal release cycle? There should be a documented standard for security issues - something like CVE >5 gets rolled out immediately, everything else waits until the next point release.
  9. It seems to me that metalog and sshd defaults should depend on what flavor you're installing. A desktop flavor shouldn't have either by default while a server flavor should have metalog. I'd say that neither should have sshd by default unless you have the amazon-ec2 or some kind of "headless" mix-in. Funtoo hasn't used `eselect news` since probably 2015. I think the problem was managing news in too many different places. Originally the intent was to put them on a wiki News page but that appears abandoned. The News and Announcements forum here seems to be the best source. It looks like if you hit follow at the top of forum you can get an email notification of news items. Funtoo has gone from being just a slightly different spin on Gentoo to something really unique among distros. I think that's great. I'm happy with what I understand of the new direction. I enjoy the fact that we're not saddled with systemd and that customization is virtually limitless, but the "rolling release" model means that you can never truly have a stable system. On a regular basis something gets rolled in that breaks things badly and you are forced to drop everything and fix it right now to get a working system again. If this new stepping release model provides a more stable system that is still more flexible and current than your typical binary release, I think it will be a win. The key will be keeping updates coming on a regular basis. @drobbins launched Funtoo to work on new directions for Gentoo without dealing with the mess that Gentoo had become. Whether or not Funtoo is the right distro for someone probably depends on how closely your goals for a distro align with his. As I read his comments and see the direction of progress I'm on board. But part of the mess that Gentoo had become was lack of communication between developers and the user base, so I think your criticism of some of the communication gaps is fair.
  10. Looking at the updates in Jira, it looks like things are moving along. My latest update pulled in nvidia-cuda-toolkit and some other nvidia related packages that are required to make nvidia-docker work. nvidia-docker is in the tree. I'm not sure if we're waiting on much more than testing and documentation.
  11. It's quiet.... Too quiet. There was some comment about this in Jira as well: https://bugs.funtoo.org/browse/FL-6219 I think it will be a good thing as long as the schedule can remain at least quarterly and upgrades are reasonably painless. I'm thinking/hoping that 1.2/1.3 were the exceptions because they represented some substantial changes in the underpinnings. Rolling releases are a mixed blessing. We're all trained to pull the lever to get the next food pellet. Most of the time it's nothing useful and sometimes it creates a lot of pain by breaking things. If we can keep things fresh and avoid the breakage while freeing up the development team to create more cool Funtoo stuff then I think it will be a win.
  12. I think I'm past this. Identified texinfo as the package with the MiscXS library and it does have a perl module attached. Did an `emerge --nodeps texinfo` to update that and now I'm rolling again. Not sure why perl-cleaner didn't catch that. Sometimes solutions just require a little sleep.
  13. Upgrading to 1.3. When running `emerge -auDN @system --ignore-world` I get a failure building automake. MiscXS.c: loadable library and perl binaries are mismatched (got handshake key 0xd600000, needed 0xd880000) make: *** [Makefile:2518: doc/automake.info] Error 1 * ERROR: sys-devel/automake-1.15.1-r2::core-kit failed (install phase): * emake failed I may have screwed things up. I originally got through this step and then had to aggressively clean up packages to clear conflicts in the world build. Eventually I got this same error building gpm. So I went back and ran perl-cleaner with --reallyall and now I get the error on automake in the @system build. build.log emerge.pkg emerge.info
  14. I'm just glad that we have this awesome distro to avoid all that garbage. Thanks to everyone who contributes!
  15. I saw the announcement about xfce 4.13-release kit availability but when I do "ego kit list" I only see 4.12-prime as available. Shouldn't that command list all available kits? Just trying to make sure that I understand the feature correctly.
  16. Your log says "Greeter requests session Xsession". It should say "Greeter requests session xfce". If you have the session type indicator on your greeter screen then be sure that you have xfce selected. If not then you probably need to adjust your lightdm settings to enable the session indicator or set the default session to xfce.
  17. If space is a problem you can work around this by redirecting your portage temp directory to a larger partition by adding this to your make.conf file. PORTAGE_TMPDIR="/somelargerfilesystem"
  18. nrc

    python woes

    Assuming that you've updated your tree as per above you may need to apply --nodeps to get ego up to a serviceable version. Then run 'epro update' and 'ego sync'.
  19. Think the transition has been more difficult and piecemeal than would be ideal. I think once the transition is complete and all the tools are in place Funtoo has the potential to be a much better distro for the average user than it has been. Kits have the potential to reduce the number of breaking changes that get through to users.
  20. That's current. I agree, it sounds like you may have skipped a step somewhere. Post the output of "emerge --info app-admin/ego"
  21. Then you need start by switching to meta-repo. https://github.com/funtoo/meta-repo
  22. What version of ego do you have installed?
  23. I'm happy with where these changes are going now that I (think I) understand it better but I agree that it could have been better communicated and managed to create less impact. Ideally they would have maintained the existing system and offered access to meta-repo in alpha, beta, rc, and release versions. Unfortunately I think their path was probably necessary due to having such a small team. Maintaining the existing flow of changes from upstream while transforming so much on the back end was probably not practical. On the communication front, I agree that it's a bit much to expect people to go check the web page or forum every time they're doing an update. It would be nice if one of the command line tools could pull a feed and at least present a link to any news updates.
  24. I have ego-1.1.3-r5 and I'm still getting this. # equery l ego * Searching for ego ... [IP-] [ ] app-admin/ego-1.1.3-r5:0 # epro === Enabled Profiles: === arch: x86-64bit build: current subarch: intel64-nehalem flavor: server mix-ins: vmware-guest === Python kit: === branch: 3.4-prime === All inherited flavors from server flavor: === core (from server flavor) minimal (from core flavor) # ego sync Performing fetch... Already up-to-date. Updating permissions... # emerge -auvDN @world These are the packages that would be merged, in order: Calculating dependencies | !!! Problem resolving dependencies for dev-vcs/git from @system ... done! !!! The ebuild selected to satisfy "dev-vcs/git" has unmet requirements. - dev-vcs/git-2.11.1-r1::core-kit USE="blksha1 curl gpg iconv nls pcre perl python threads webdav -cgi -cvs -doc -emacs -gnome-keyring -gtk -highlight -libressl -mediawiki -mediawiki-experimental (-ppcsha1) -subversion -test -tk -xinetd" LINGUAS="-bg -ca -de -fr -is -it -ko -pt_PT -ru -sv -vi -zh_CN" PYTHON_TARGETS="-python2_7" The following REQUIRED_USE flag constraints are unsatisfied: python? ( python_targets_python2_7 ) The above constraints are a subset of the following complete expression: cgi? ( perl ) cvs? ( perl ) mediawiki? ( perl ) mediawiki-experimental? ( mediawiki ) subversion? ( perl ) webdav? ( curl ) gtk? ( python ) python? ( python_targets_python2_7 ) (dependency required by "@system" [set]) (dependency required by "@world" [argument])
×
×
  • Create New...