Byla vydána verze 3.14 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl aktualizován na verzi 8.5. Řešeno je také několik bezpečnostních chyb. Především bezpečnostní chyby v procesorech Intel.
Byla vydána nová verze 2019.2 průběžně aktualizované linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek v seznamu změn. Současně byl ve verzi 2019.2 vydán také Kali Linux NetHunter (Wikipedie), tj. obrazy s nástroji z Kali Linuxu pro chytré telefony a tablety.
Byl vydán Mozilla Firefox 67.0. Přehled novinek v poznámkách k vydání a na stránce věnované vývojářům. Zdůraznit lze blokování těžby kryptoměn a otisku prohlížeče, viditelnější účet Firefoxu nebo rychlý přístup ke správci hesel.
Rozšířená podpora operačního systémy Microsoft Windows 7 skončí 14. ledna 2020. Poté je možné využít placené podpory, přejít na Windows 10 nebo prostě na Linux. Vláda Jižní Koreje zkouší Linux. Přechod na Linux včetně nákupu nových počítačů by ji měl vyjít na 655 milionů dolarů.
CZ.NIC ODVR (Otevřené DNSSEC Validující Resolvery) nově podporují vedle DNS-over-TLS (DoT) také DNS-over-HTTPS (DoH). DoH lze vyzkoušet ve Firefoxu od verze 62, Chrome od verze 66 nebo Bromite od verze 67.
Americké společnosti omezují spolupráci se společností Huawei, protože Ministerstvo obchodu Spojených států amerických přidalo Huawei na černou listinu. Omezení již oznámili Google, Qualcomm, Intel, Xilinx nebo Broadcom. Google omezí přístup k Androidu a Google Play. Existujících zařízení by se to nemělo týkat. Prohlášení společnosti Huawei.
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