drobbins

I think *I* am Funtoo's Admin staff. You seem to be under the impression that there is a large team of dedicated people who exist solely to maintain these free services for you and cater to your preferences. That is not the case. This is a volunteer project and everyone including myself has very limited time. I would like to challenge your apparent perceptions that there is an actual group of people whose job it is to make sure you are happy and satisfied with our infrastructure. It's not true and that is not the way a volunteer project works, unfortunately. (I wish this was how it was) Maybe you can try to take things a little less personally and appreciate what we do have, and engage constructively to help improve our services rather than complain about them and cast negative judgement against, in this case, me. There are plenty of other Linux distributions that don't use Discord, so if it's a deal-breaker for you, I encourage you to find another Linux distro that reflects your personal values. Discord can be run in-browser and it has full functionality, and is sandboxed by Chrome or whatever browser you use when run in this way. If Funtoo is important enough for you, maybe you will engage with our community to help us maintain our infrastructure and improve what we have to offer. The technologies like Discord are often chosen in large part because they offer a lot of features we need but do not require a lot of our time to use and maintain. If you are in a position to invest your time to offer a superior solution, then you are in a rare position indeed and we would be happy if you would use this time to help the Funtoo community. Consider the perspective change.

This doesn't help your immediate problem but the next release of ramdisk should print a useful "lsblk -f" command when it opens the rescue shell to give you the information on visible block devices automatically. I think we need to figure out what modules you need and then I need to make sure I am auto-loading these. Can you give me a bit of detail on your PC/system so I have more context on what we're trying to get booting?

Try to use the rescue shell to see if that uuid exists while you are inside the rescue shell. I also notice you are using mmc devices. Possibly, the proper kernel modules for this are not being autoloaded, and that could be the issue.

@uudruid74 on the "inform users of new changes" front, I have been working on a solution -- @invakid404 has helped with a prototype. Like any new technology, it takes free time to work on. I agree that something better is needed for this, because if no one knows about an improvement or new ebuild, often it doesn't actually benefit anyone since they don't know about it.

@uudruid74 we actually do have a newsletter. If you had read it, you would have known about the deprecation of 1.4-release. OpenSSH has been updated in next-release so it is now available for use, thanks to our volunteer contributors.

Everyone, We are officially retiring 1.4-release in 2024, which means that if you have not yet done so, now is the time to upgrade to next-release. The official way to do this is to do a REINSTALL of Funtoo. You may be able to in-place upgrade from 1.4-release to next-release but THIS IS NOT OFFICIALLY SUPPORTED so if you can't get it to work, you can ask on Discord for help unofficially but if you can't work through the various quirks you WILL need to reinstall. Really, a reinstall should be done unless you have a very specific reason why you can't. The Funtoo community is around to help with issues you may have with an upgrade, but just be aware of the possibility of hitting something that may warrant reinstall. For new installs of next-release, the Funtoo community as well as myself are available to assist you with issues you may encounter. Reach out on Discord in the #install-help channel.

You are welcome! I will post a big announcement so that others are aware who might have missed it.

I bet you are using 1.4-release, which has not been receiving updates recently and will no longer be maintained after the end of the year. If you install next-release, you will getting (almost) daily updates. Relevant links:

@aitikin I gave you a sarcastic answer as a response to your threat of: "But, frankly, if you send me ANY ONE SINGLE YouTube as a solution, I'm gone." I'm calling out your threat. Do you think that maybe your inability to find support could be related to your immature and ranting behavior, rather than any deficiency in our project and documentation?

Did that video help?

Everyone, our summer 2023 newsletter has been published!

Funtoo Newsletter, June-August (Summer) 2023 Welcome to the current installment of the Funtoo Newsletter. This newsletter combines multiple months -- June through all of August -- so, essentially our summer newsletter, for those of you in the northern hemisphere. We're going to hit all the key technical changes in this newsletter: Funtoo Linux 1.4 Deprecation (re-announce) The End of Genkernel -- Welcome "Funtoo Ramdisk" Massive updates from Summer Harvest (harvester/2023-08) I'm planning a follow-up newsletter for community and development news, since this newsletter got too long. This follow-up newsletter will cover: The Forums -- Back from the Dead? Maybe! Dev Corner: All the Epics! (What's going on with bug tracker) Let's cover the important technical stuff now. Funtoo Linux 1.4 Deprecation Announced in our previous newsletter, but worth repeating here -- Funtoo Linux 1.4 will be "retired" by the end of 2023. See the previous newsletter for more details -- but for now, just know that you should upgrade to "next-release" if you are not running it already. The best way to upgrade is by performing a new install of Funtoo Linux some time before the new year. It is technically possible to upgrade from 1.4 to next, especially on server systems with minimal packages, but we don't recommend it. The End of Genkernel -- Welcome "Funtoo Ramdisk" For the longest time -- almost since the beginning of the project -- Funtoo has had a forked version of Gentoo's genkernel which we used to build our official kernel and initramfs. For an equally long time, I have wanted to completely rewrite genkernel from the ground up. There was always some distraction that prevented me from doing this, and we were able to keep genkernel hobbling along for around a decade -- but it was time to do something about it. What were some problems with genkernel? Several. Many people haven't really liked it because it built your kernel and your initramfs -- this made it cumbersome to use. There has been a long-held desire to separate this functionality. It has also amassed a ton of features and become very complex and its code base is difficult to refactor and improve. So we needed a better foundation going forward. After September 11, 2023, when harvester/2023-08 updated are merged into Funtoo Linux, Funtoo Linux will have a new initramfs building tool called ramdisk, which will be utilized by the new debian-sources 6.4.13_p1 ebuild to build your initramfs. genkernel is no longer used. As a quick introduction to ramdisk, I will include an excerpt of the README from its official funtoo-ramdisk pypi page (https://pypi.org/project/funtoo-ramdisk/😞 As you can see, ramdisk is an exciting and innovative project which will continue to deliver new goodness related to booting. I hope you enjoy it! 🙂 Summer Harvest With the close of summer comes the merging of our development work from the harvester/2023-08 branch. This is a branch where we can make possibly breaking changes and work out kinks before things hit end users. Thanks to all who contributed to the summer harvest this round. Here is a brief and incomplete summary of changes in harvester, plus any hotfixes added to the master branch during this time: gcc-12 added, along with updated binutils. Introduction of funtoo-ramdisk (see previous section) Linux 6.4: debian-sources-6.4.13_p1 Reworking of libreoffice-bin to remove unnecessary deps. Updated NVIDIA drivers. FL-11523: forward-port rtl89 Wi-Fi to address flakiness issue docker, docker-cli, docker-compose, docker-buildx, containerd, runc updates/fixes (thanks siris) ZFS 2.2.0_rc4 with Linux 6.4 compatibility, with 2.2.0 final soon to follow. zathura document viewer autogen (thanks to cuantar) pgplot update (thanks to cuantar) gocryptfs, jq, meilesearch, nix, lowdown, mdbook autogens (thanks to invakid404) libxcb, libcpuid hotfixes (thanks to invakid404) go-1.21.1 (thanks siris) Inkscape 1.3 and updates to boost to allow this. typeprof build failure (thanks borisp) geany reworked ebuilds (thanks grouche) firefox-117.0, thunderbird-115.1.1 (thanks borisp) Updated libbson, mongo-c-driver, cri-tools (thanks geaaru) Multiple python module fixes/maintenance (drobbins) lightdm-mini-greeter autogen (thanks izder456) ibus-skk and dependencies, remove ibus-pinyin and pyzy (thanks madman10k) Add feature to allow PEP 517 python modules autogens to be determined automatically (drobbins) Fixes of kit-fixups git pre-commit hooks. Many thanks to all who contributed. End OK, that's it for now -- stay tuned for an additional community/newsletter supplement that will cover more topics.

This looks like a bug. Can you report it to our bug tracker at bugs.funtoo.org?

Hi All, I've decided to move the Funtoo Telegram channel to non-official status, as we have Discord and it doesn't make sense to have two official discussion channels. If you're on Telegram, you're encouraged to come over to Discord. I've marked the Telegram channel as "Unofficial" and updated the wiki to make this clearer.

@jeon I can help you out if you can hop on Discord and DM me with the details.

Hi All -- The latest newsletter combines both April and May 2023, and I'm using Markdown for publishing for now, so I'll just provide a link to the markdown file: https://code.funtoo.org/bitbucket/projects/DOC/repos/newsletter/browse/docroot/2023/04-05.md Enjoy!

UPDATE: containers are back online -- see below for details on what happened. Everyone, Our datacenter in Taos, New Mexico experienced a very severe "fiber cut" in close proximity to the datacenter which severed its fiber links. This major fiber cut also has disrupted multiple ISPs and mobile carriers such as Verizon in Taos, NM. This has resulted in a number of community containers going offline. This has not impacted Funtoo core infrastructure. The fiber cut is very severe and we expect at least 24 hours of downtime. More info here: https://www.taosnews.com/news/severed-fiber-optic-line-causes-cell-phone-internet-outages-in-taos/article_cc7f41e6-03f7-11ee-9df2-fb4957e977a7.html UPDATE from our datacenter: What happened? At approximately 3:25 pm MT (GMT-6) yesterday a road construction crew caused a large fiber cut which knocked much of Taos, New Mexico's telecommunication infrastructure offline. This outage impacted both of our upstream networks in addition to local cell phone and phone service, as well as many local ISPs, including our sister company, TaosNet. Lumen fiber technicians worked through the night to repair the broken fiber and are still at work on it. Why did this happen? Know that we're as shocked and devastated as you are by this extended outage and again, apologize profusely. We were led to believe - by our upstream network providers - that our upstream network redundancy was complete, when in fact it was clearly not. We have had fiber cuts to one of these fiber connections or the other over the last few years, and each time our traffic failed-over perfectly. However, what this fiber cut revealed is that there is approximately a one mile stretch - of many hundreds of miles of fiber that our networks traverse - where both networks are in the same conduit. This is where the cut was. The good news is that after detailed analysis we believe a network routing change can get us back to fully geographically redundant fiber paths. We'll be working on implementing this in the coming weeks. How did Brownrice get back online? Since the fiber outage was still not fixed, early this morning the CEO of a local ISP, Kit Carson Internet, reached out to us offering network connectivity. Our network engineers, our TaosNet wireless team, and the team at Kit Carson Internet then formulated and executed a plan to build a high-speed wireless link between our two facilities and route traffic through Kit Carson Internet to our data center. This brought all of our networking services back online. The amount of skill and know-how to pull this together within a single day was truly staggering. And we can't thank Kit Carson Internet enough. What are you doing to ensure this never happens again? Now we have an active and tested, fiber-cut-proof backup connection in place and working. It's not yet as fast as we'd like, and is currently experiencing some packet loss, but our higher speed fiber connections should come back online later tonight. And once we are back to full strength we'll get the backup connection speed and packet loss sorted out. And know that we will leave this backup connection in place forever, so this never happens again.

@court-jester some changes -- the next newsletter is going to be more focused on updates on plans for funtoo and infrastructure, but I hope to be able to have the tutorial stuff available soon.

@cardinal thank you for your understanding. I don't like to enforce rules like this but if I don't, then we don't do things the right way. I don't mean it personally at all.

@cardinal please do not post patches here. The solution is not to give some Funtoo user a patch so they can "hack around" the problem. @fredmyra this is a bug -- please report it to bugs.funtoo.org and we'll look into it.

Enjoy our freshly-released March 2023 Newsletter! Thanks to @adbosco (author) and @seemant (editor) for their contributions. As always, read and enjoy. This edition contains a detailed overview of how metatools interacts with the Funtoo CDN infrastructure.

Better Late Than Never! Our third newsletter is a bit late -- but has an in-depth article on some as-yet-unexplained aspects of Funtoo related to metatools and our CDN. Definitely worth a read! Each newsletter, we are going to try to feature an in-depth article combined with key Funtoo news for the month. Linux Kernel 6.1.20_p1 is Now Available The sys-kernel/debian-sources-6.1.20_p1 has been unmasked on the meta-repo tree and is available for regular upgrade for everybody. This is basically a “bug fix” upgrade, as no new features or modules were announced. However, 1185 files have been touched by bug fix commits since v.6.1.12_p1, so you might want to consider upgrading your kernel to benefit from them. The Funtoo CDN and Metatools Most people are aware that Funtoo has its own CDN (Content Distribution Network), but few understand the role it has been playing in Funtoo and the potential it has for the future. Over the last month there have been interesting developments regarding the use of the CDN associated with Funtoo Metatools. Metatools lets Funtoo auto-generate up-to-date ebuilds from sites like GitHub. This month we saw the realization of a year-long effort which made Go and Rust packages a lot more efficient. In this article, you will learn about the evolution of our content distribution, from the early days of Gentoo to the latest stage at which Funtoo finds itself right now, as well as some of the inner workings of Metatools and how to use the new extensions in your Go and Rust autogens. Background Historically, Linux distributions used a network of mirrors to distribute their packages, installation media images and so on. This would provide faster downloads for users all over the world who could select a close-by mirror — often inside the very institution they were working from — while also alleviating some of the load on the primary servers. Gentoo made use of a traditional mirror network to distribute its installation media and distfiles but introduced an innovation: for the small files that make up the Portage tree, Gentoo started using the relatively new rsync protocol instead the traditional ftp and http, guaranteeing that only the files that needed update were downloaded, which made the updates a lot more efficient. Funtoo inherited that system from Gentoo, but soon innovated again, adopting the then new “git protocol” instead of rsync. Now instead of downloading the files that changed, it downloads only the changes themselves (the git “deltas”), making the updates even more efficient and faster. Also, this meant that the master Portage tree could now be hosted on GitHub, doing away with the burden of maintaining a network of rsync mirror servers for the Portage tree. This move also made it feasible to group the previously monolithic Portage tree into logical “kits”, each in its independent repository within the “meta-repo”. However, git by its very nature is not suitable for hosting binary files and therefore cannot be used to distribute installation media and pre-built packages, for example. Thus, just moving from rsync to git didn’t mean that Funtoo wouldn’t need to manage a mirror network anymore; installation media, stage tarballs, distfiles and occasional pre-built binaries still needed to be made available for download somehow. At this point, Daniel decided to reach out to CDN77, which generously offered to provide CDN resources to the Funtoo project. The Funtoo CDN A CDN (Content Distribution Network) serves the same purpose as the “mirror network”, but it’s hard to even try to compare what they really are. The best-maintained mirror network will look amateurish and won’t compare in terms of performance to a modern CDN service. The CDN77 service uses caching and high-speed links to make the files easily and rapidly downloadable worldwide, using several geographic endpoints that can cache files and communicate rapidly between each other. For practical purposes, let’s just say that the user doesn’t need to select a “best mirror” and there are no outdated or down mirrors. From the user standpoint, all the available ISO images and stage tarballs appear to be under one single URL: https://build.funtoo.org/, and the distfiles referred to in the ebuilds appear under https://direct.funtoo.org. The CDN will transparently select the fastest route between the user and a server that can deliver the content at the moment of the request. The CDN does not only manage mirrors in strategic points around the world, but also the content can be cached by ISP’s, making it readily available at the fastest speed possible to the users who connect to them. It doesn’t matter if you are in Los Angeles, Bucharest, Jakarta, Buenos Aires or Cape Town, you will have the same fast and reliable experience downloading content from a CDN. This move completely freed Funtoo from the need for any kind of mirror network for any purpose. At first, only the Funtoo stage tarballs and distfiles were uploaded to the CDN. But there were some distfiles referenced from some ebuilds from the Gentoo snapshots that were using Gentoo mirrors, which risked being altered or removed without notice. Realizing that, Daniel wrote a script to populate our CDN with a full collection of source code, so that this would not become an issue. Then the CDN was made the default “mirror” for all distfile sources and the “fastpull service” was added to the Funtoo Portage, providing users with a fast, reliable and universally accessible download point for all their source code. But Funtoo is not about ebuilds from Gentoo snapshots. The real deal are the “autogens”, which in theory can generate anything — not just ebuilds — using the logic contained in a “generator”, and a Jinja template. Metatools is essentially an advanced Python-based API for creating ebuilds, which contains useful tools for automatically checking the latest or all the available versions of packages, downloading the sources and generating ebuilds based on information found online or contained inside the downloaded tarballs. The generator can also take parameters from a YAML file, thus allowing a single Python generator to generate ebuilds for hundreds of different packages. It Starts With the Spider Metatools itself has a highly-efficient Web spider which is used to download the sources for all autogenned ebuilds. When the autogen is run in developer mode, fastpull only downloads the source tarball to the local computer, but when it’s run on our official regen infrastructure, all distfiles grabbed by the spider are immediately made available on the CDN, so that source code is always available even if the original repository goes offline. In 2022, the second-generation of our fastpull technology was released, which stores files indexed by their sha512 sum hash rather than their file names. Thus, Portage can request distfiles from our CDN by their sha512 sum hash, and then save them locally with their original file name. This completely eliminates the possibility of having an infamous Portage “digest mismatch”. Also in 2022, the ebuild-generation component of metatools gained a new and very powerful feature called “Dynamic Archives”, which allows the autogens to create their own tarballs. These can be modified or repackaged versions of the original source tarballs, maybe with the addition of some icons or documentation downloaded from different places. They can also be a “prepared” version of the sources, so that the generated ebuild can drop the dependencies that would then be needed to prepare the sources or build the documentation. They can be used to build tarballs from git clones that include git submodule sources, which are usually missing from the GitHub tarballs. This leads us to the biggest story of March, 2023: the new golang and rust extensions to the github-1 generator that showcase the power of the Dynamic Archives within metatools. The golang Extension Metatools have had for some time the ability to peek into source tarballs for software written in Go Language to extract the gosum hashes and download urls for its dependencies, which could then be used to create an ebuild with a long SRC_URI, which would hold both the URL for the main package and also all its dependencies. This allowed us to have up-to-date ebuilds for packages that were written in the Go Language. In order to use this generator, however, it was necessary to use a custom python autogen rather than a generic YAML one. Also, the resulting ebuild was sub-optimal, since it was based on the existing Gentoo go-modules.eclass which required listing every single required go module individually in SRC_URI. For many golang-based ebuilds, this resulted in hundreds of entries in SRC_URI. Even though our CDN is very efficient for downloads, Portage downloads files one at a time, so each entry in SRC_URI takes a minimum of a few seconds each to download. Add a hundred (or two!) entries in SRC_URI, and the download of sources could take 10 or more minutes! Quite annoying. Fortunately, Funtoo doesn’t have to settle for that sub-optimal experience. Thanks to dynamic archives, invakid404 and drobbins were able to develop a solution. Rather than individually list each required go module in an ebuild, the autogen itself could create a single tarball which contained all necessary go modules, and this tarball would be magically populated on our CDN. The ebuild could now reference one additional file, rather than hundreds, and we were able to magically work around the Portage fetch performance issue. Emerging ebuilds for golang-based packages could be made fast again. As of April 5, 2023, these dynamic golang autogens are now active in the main tree – net-misc/rclone is one example of such packages. To make these improvements easier to use, the go-modules.eclass was optimized to transparently use Funtoo’s go-module bundles, and a new extension to the metatools github-1 generator was introduced. To make your golang-based autogen automatically create a “golang bundle” (tarball), just two additional lines are needed (the last two ones in the YAML below): mypackage_rule: generator: github-1 packages: - my package extensions: - golang The rust extension Also included in the harvester/2023-03 branch is the "rust" extension to the github-1 generator, which works in an analogous form to that of the golang extension, with a conjunction of new code added to the existing rust metatools sub and to the github-1 generator. harvester/2023-03 has been merged into "production Funtoo", meaning that this functionality is now fully active and in use. Next Time In the April issue, we’ll begin a series of tutorials on Pull Requests and the Funtoo Git Repository and how it works. You’ll learn about the Funtoo tools & metatools, the kit-fixups repository, and end with the git pull request workflow.

I have created https://bugs.funtoo.org/browse/FL-11264 and made FL-11069 a sub-task of it.

@cardinal I don't think your original bug report for this issue was optimal (https://bugs.funtoo.org/browse/FL-11069) I think it identifies the wrong problem. The real problem here is not that there was a blacklist installed -- the real problem is that by default, the nvidia-drivers are not supporting a legacy card. This is not optimal and if the nouveau drivers are more compatible with all generations of NVIDIA cards, it makes a more reasonable default for our DE stage3's. Therefore, I am thinking the bug should be "default nvidia-drivers on stage3 lacks support for legacy NVIDIA cards". And we would explore nouveau by default as a solution. Then we would incorporate the nouveau blacklist into nvidia-drivers so it installs only if you opt-in to the official NVIDIA drivers.