Jump to content

tux

Members
  • Content Count

    8
  • Joined

  • Last visited

About tux

  • Rank
    Newbie

Online

  • freenode
    gtlt

Personal

  • Location
    Paris, France
  1. Yes, it can be a more user friendly approach than masking. I understand a masked pkg as a package that will fails to install or may break the system. I think it's not relevant for unofficial kernels like gentoo-sources.
  2. @drobbins there is this one already https://bugs.funtoo.org/browse/FL-6035 If merge scripts allow it, maybe you can auto-insert an ewarn in pgk_setup/pkg_postinst ebuild to warn users ?
  3. I also would prefer synced up-to-date masked gentoo-sources, but we can always PR flora repo to add them. Since its not officially supported it up to the community to maintain them. I made a PR for stables amd64 4.19.x since I'm using it. I think we can make a mostly automated workflow to PR trivial ebuilds (I mean those that require just a copy-paste from gentoo). Will try to do that on some ebuilds like stable amd64 gentoo-sources, vivaldi and php I'm using.
  4. On my side, ip is not reachable so no ssh connection. Under openvz we were able to monitor our own container usage, not anymore under lxd. Its not very handy to track disk usage increase like logs, etc....
  5. Do you still have the issue ? I add it on a new Funtoo 1.3 install few days ago. I'm not sure exactly how I resolved it, I think by creating a /etc/X11/xorg.conf.d/10-keyboard.conf file... Section "InputClass" Identifier "keyboard-all" Driver "evdev" Option "XkbLayout" "fr,us" Option "XkbModel" "pc105" Option "XkbOptions" "grp:alt_shift_toggle" MatchIsKeyboard "on" EndSection
  6. Hi, I see two small issues since the migration : /usr/srv/linux symlink was broken on my container, ln -s host/linux linux fixed it. disk usage is not related to container anymore, do you know if we can monitor it ? It helps keep instances lower on disk usage :-) # df -hP Filesystem Size Used Avail Use% Mounted on /dev/loop0 600G 246G 352G 42% / none 492K 492K 0 100% /dev udev 10M 0 10M 0% /dev/tty tmpfs 100K 0 100K 0% /dev/lxd /dev/sda3 822G 592G 230G 73% /usr/src/host tmpfs 100K
  7. I just checked from a fresh ego sync (/var/git/meta-repo deleted) and it works. The big part is in upgrading process, I helped myself with gentoo Plasma upgrade (use / cleanup section). My changes in the repo are tiny : updated ebuild version dev-kit/1.2-prime/dev-libs/libdbusmenu-qt added ebuild media-kit/1.2-prime/media-libs/phonon added ebuild media-kit/1.2-prime/media-libs/phonon-vlc patched ebuild kde-kit/5.13-release/dev-qt/qtsql/qtsql-5.11.1-r1.ebuild replacing the SLOT ver_cut function (is it because of funtoo specific ??) deprecated gnome + python
  8. I had hard times upgrading / regenerating all kits, it takes a long time. So I tried to only regenerate some of them by deprecating others, but that doesn't work this way.... It should be fine now (I will double check as a lambda user with https url later today at home). Maybe you need to remove your meta repo first. For info, I had difficulties with kwin/kwayland. Kwayland doesn't build in 5.49 on my system, only 5.43 5.46, unblocking kwin upgrade. Also I was on xorg 1.20 kit and it was impossible, so better to be on xorg 1.19-prime first.
  9. I'm willing to help testing/fixing on KDE. I made a staging repo for kde-kit/5.13-release manually synced with gentoo-staging here: https://gitlab.com/gtlt-funtoo. I only fixed ebuild dev-qt/qtsql-5.11.1-r1 that blocked me upgrading from prime-5.12, rebuilding now (no other kde/qt blocker thus far) and testing. If someone want to try it, add in your /etc/ego.conf [global] sync_base_url = https://gitlab.com/gtlt-funtoo/staging/{repo} [kits] kde-kit = 5.13-release (better to backup your meta-repo before sync) # cd /var/git # mv meta-repo meta-repo.official # ego sy
  10. Right, I gave it a try but it doesn't fix anything. I also noted an empty PORTAGE_OVERLAY vs my desktop. I think something is wrong with my portage setup... on container : # eix-update --print PORTDIR_OVERLAY # on desktop: # eix-update --print PORTDIR_OVERLAY /var/git/meta-repo/kits/core-hw-kit /var/git/meta-repo/kits/desktop-kit /var/git/meta-repo/kits/dev-kit (...) /var/git/meta-repo/kits/xorg-kit # cat /etc/portage/make.conf MAKEOPTS="-j7" USE="php geoip php pdo mysql curl zip
  11. it comes from this : # eix-update --print PORTDIR /usr/portage/ my desktop is : # eix-update --print PORTDIR /var/git/meta-repo/kits/core-kit/ forcing it in /etc/portage/make.conf is not enough : # cat /etc/portage/make.conf | grep PORTDIR PORTDIR="/var/git/meta-repo/kits/core-kit/" # eix-update Reading Portage settings... Building database (/var/cache/eix/portage.eix)... [0] "core-kit" /var/git/meta-repo/kits/core-kit/ (cache: metadata-md5-or-flat) Reading category 40|40 (100) Finished # eix eix No matches found
  12. meta_repo_path was just to have a repo in rw for ego sync, but I switched back to the default one since it is now on 1.2. I also checked /etc/eixrc/00-eixrc against my desktop where eix works well and I don't have any diff. Here it is : # /etc/eixrc/00-eixrc # # All non-hidden files in /etc/eixrc # (or a subdirectory thereof) are read in alphabetical order. # # In these files system-wide defaults for variables related to eix can # be stored, i.e. the variables set in files override the built-in defaults. # Both can be overridden by ~/.eixrc and by environment variables
  13. I'm currently with ego-2.4.2 with a local repo but eix-update is broken and cannot figure out how to fix it. I don't know if it is related, but I recently switched epro build from stable to current (I was with ego-2.3.0 I think) and that broke my epro/ego/emerge somewhat. I had hard time to have all them back on track... # eix-update Reading Portage settings... Building database (/var/cache/eix/portage.eix)... cannot open /usr/portage/profiles/categories: No such file or directory [0] "" /usr/portage/ (cache: metadata-md5-or-flat) Reading category 0|0 (100) EMPTY! Applying
  14. Hi Daniel, Do we need to expect a downtime/reboot during the migration ? I'm going to backup some files just in case :) Funtoo container plans are truly impressive !
×
×
  • Create New...