Byla vydána nová verze 2020.1 průběžně aktualizované linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Systém už neběží pod uživatelem root. V živém systému se uživatel místo root/toor přihlašuje kali/kali. Při instalaci systému je vyžadováno zadání uživatelského jména a hesla. Aktualizovat Kali Linux lze pomocí příkazů "apt update && apt -y full-upgrade". V dalších verzích spolu s příkazem sudo.
Byla vydána nová verze 5.0.0 Knot Resolveru. Přináší například změny ve způsobu konfigurace síťových zařízení. Knot Resolver je open source implementace rekurzivního DNS serveru (resolveru) vytvořená a udržovaná v Laboratořích CZ.NIC.
Intel vydal bezpečnostní upozornění INTEL-SA-00329 upozorňující na dvě nové bezpečnostní chyby ve svých procesorech. Jedná se o CVE-2020-0548 (Vector Register Sampling) a CVE-2020-0549 (L1D Eviction Sampling). Vážnější chyba CVE-2020-0549 dostala název CacheOut (pdf).
Společnost Qt na svém blogu informuje o změnách v dostupnosti svého stejnojmenného multiplatformního toolkitu. Ke stažení binárních souborů s Qt bude od února nutné mít uživatelský účet. Binární LTS verze a offline instalační programy budou nově k dispozici pouze pod komerční licencí.
Na MojeFedora.cz byl publikován článek 5 triků pro lepší práci se správcem souborů Nautilus. Jeden z triků je speciální uri: “admin://” pro procházení souborového systému jako root.
Po 9 týdnech vývoje od vydání Linuxu 5.4 oznámil Linus Torvalds vydání Linuxu 5.5 (LKML). Přehled nových vlastností a vylepšení na stránce Linux Kernel Newbies. Kódové jméno Linuxu 5.5 zůstává Kleptomaniac Octopus.
Byla vydána nová verze 0.32.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Vývojáři mpv nedoporučují používat mpv na GNOME na Waylandu. Nejnovější mpv na to přímo upozorňuje (commit).
This will be a post about the possibilities of Fedora packaging on Gentoo. I've been doing quite some Fedora packaging when actively using that distribution and later added more because of the importance of Fedora for my current employer.
Eating your own dogfood. The meaning of that sentence reaches new dimensions when you're saying it as an open source software developer. Even more so, when you're the sort of a developer I am, digging into lots of projects. I basically need to be able to incorporate any patches, releases or Git snapshots into my own system and see how well it plays with all those services I'm using on a daily basis as well as tools that I want to just test.
There are numerous possibilities with any distribution. But you typically end up doing a compromise between a stable binary distribution for every day use and pieces of Linux From Scratch. It's not hard to achieve the results you want to but it is somewhat inconvenient and you tend to spend a huge lot of time with that. And there's no way to easily repeat it. So you would finally end up automating parts of the process. It's also difficult to renew a working environment at least resembling the distribution you started with. With many packages, it's difficult to ensure that your test builds use the test build of the package and not the installed binary package that is part of your normal installation. You can take that as a very lazily assembled problem statement.
Instead of building up all of the necessary automation tools from scratch, I chose the Gentoo Portage as the toolset. As I wanted to achieve full integration with my system, I decided the system will itself be Gentoo. Therefore while I consider myself a user of the Gentoo Linux distribution, it is more of a side effect of choosing the Gentoo Portage as a build platform for my testing. This was the main reason I started using years ago, and it was also the main reason that I returned back to Gentoo after roughly five years of only using binary distributions. And it helps to answer why I'm not generally recommending my distribution of choice to anyone else.
When using and discussing Gentoo, I discovered a couple of other advantages that are less important to me but that improve my user and community experience a lot. Gentoo seems to be company-neutral. When using Gentoo, there's no natural inclination to a specific company that you would experience using Fedora, CentOS, OpenSUSE or Ubuntu. Debian would fit as well, while being a bit more tricky than Gentoo in this respect. And indeed there seems to be a large community of Gentoo developers whose members are affiliated with all sorts of companies and organizations. Arch Linux would be on the same level as Gentoo here, but I never liked the toolset. That's for the politics.
Going back to technical features that improve my experience with Gentoo. The stable package set proved to be a rather conservative one, with a unique QA system for a community distribution. I haven't seen anything comparable in the release-based distributions, not to say rolling release and I don't dare to say I understand the process, yet. It's not comparable to Debian, which has a stabilization period for the whole distribution. It's not comparable to Fedora, where package stabilization is more or less handled by the package maintainer himself. In my opinion, the results are incredibly good, especially when Gentoo lives with QA handicaps like rolling release and a relatively small developer base.
The importance of the Fedora distribution for my employer, Red Hat Czech, doesn't need to be explained. I will avoid the overall quality of Fedora as much as possible, as it substantially changes over time for better or worse. Of binary package distributions, Fedora is currently the most complete distribution for my daily tasks. That includes playing with software that's not packaged in other distributions including Fedora build tools. And I'm pretty much familiar with the process of adding new packages for whatever is missing. The RPM spec files remind me of Gentoo ebuilds and I've been using the Fedora build system for years.
Also, Fedora seems to be slowly moving to a direction I believe in for common usage, example of which is the announced future distinction of the server and workstation use cases. It is a distribution of choice for many developers and it seems to have a rather active developer community outside Red Hat. For good or bad, what you see in Fedora is very often what you will see in other distributions soon. That pushes Fedora into a position of an important development decision point as well as a preview of the future Linux ecosystem.
Fedora package definitions are stored in separate Git repositories. The repository contains a master branch,one branch for each supported Fedora release and optionally one brach for each supported EPEL release. The EPEL branches are somewhat hybrid between Fedora and RHEL (and derivatives), as they are part of the Fedora Project but they're being built for the enterprise linux releases. The version control workflow is mostly in the hands of individual package maintainers. The package maintainer explicitly requests the Fedora build service to assemble a build using the top of a branch. For released branches, updates have to be created explicitly as well and then a semi-automatic procedure is used for stabilizing the package update. So there's a couple of services that need to be interfaced and a couple of convenience tools to help with the packaging tasks.
So far I had to use a second physical or virtual system with Fedora for the pacakge work. I cheated a little bit and actually used a chroot with the filesystem tree from my previous Fedora 18 installation and it worked pretty well. Fedora 18 is now rather outdated. When Fedora 19 was out, I tried to upgrade the installation but the upgrade failed with no error message. The installation was still usable except kernel and related updates were broken since then as any new initramfs images were trying to perform the upgrade.
So far I packaged the tools I needed for everyday Fedora development and their dependencies, so I can abandon my obsolete Fedora installation. Most of the tools and libraries have their upstream projects hosted at http://fedorahosted.org/ and source code available via Git and release tarballs. Some of the projects offer sourcd code via Bazaar and Subversion. I decided to ignore the released versions for now and I created a number of live ebuilds pulling the code directly from upstream repositories. That is in line with my intention to try to resolve any problems in the upstream first. All the packages are available in David Heidelberger's ixit overlay.
# layman --fetch # layman --add ixit # emerge fedora-packager --autounmask-write # dispatch-conf # emerge fedora-packager
$ fedora-packager-setupNow you can use the fedpkg and koji commands with some limitations.
There are a couple of things that won't work for you on Gentoo. You won't be able to do local builds easily as they rely on the local RPM metadata. I didn't package the tools necessary to do a local mockbuild as I didn't need it. I haven't tested many of the features, so you may need to either fix it or use a Fedora installation in case of problems.
As mentioned earlier, my intention was to try to fix any integration issues with upstream first. So far the only major difference from Fedora is that Gentoo already defaults to Python 3, which also constitutes an exception from the above upstream first rule. Where it's necessary, the ebuilds change the code using sed to force using Python 2. I don't see a reason to disturb the upstream developers until they themselves to make the code compatible with Python 3. It might be useful to submit patches to select Python 2 in an environment where Python 3 is default.
Apart from the Python and RPM differences, I don't see anything that would make Gentoo an inferior Fedora packaging platform comparing to any released Fedora or Rawhide. The lack RPM metadata is limiting, though. Looking forward to any suggestions and ideas as I'm myself curious how all of this will work out.
Gentoo packaging is fun. I packaged some other software and put it to ixit as well and more live ebuilds are yet to be added. But my ultimate goal is to get those packaging tools as well as a number of networking related packages included in the official Gentoo repository.
The choice of English language in the article should make it readable for a broader audience if needed. It has been written at once, without any careful editing, so please take it as it is.
Fedora packaging tools for Gentoo are still maintained and have now their own overlay repository on github. Also now with Gentoo adding an overlay is as easy as putting the following lines into
[fedora] location = /usr/local/overlay/fedora sync-type = git sync-uri = https://github.com/pavlix/gentoo-fedora auto-sync = yes