Posted on Leave a comment

Fedora CoreOS out of preview

The Fedora CoreOS team is pleased to announce that Fedora CoreOS is now available for general use. Here are some more details about this exciting delivery.

Fedora CoreOS is a new Fedora Edition built specifically for running containerized workloads securely and at scale. It’s the successor to both Fedora Atomic Host and CoreOS Container Linux and is part of our effort to explore new ways of assembling and updating an OS. Fedora CoreOS combines the provisioning tools and automatic update model of Container Linux with the packaging technology, OCI support, and SELinux security of Atomic Host.  For more on the Fedora CoreOS philosophy, goals, and design, see the announcement of the preview release.

Some highlights of the current Fedora CoreOS release:

  • Automatic updates, with staged deployments and phased rollouts
  • Built from Fedora 31, featuring:
    • Linux 5.4
    • systemd 243
    • Ignition 2.1
  • OCI and Docker Container support via Podman 1.7 and Moby 18.09
  • cgroups v1 enabled by default for broader compatibility; cgroups v2 available via configuration

Fedora CoreOS is available on a variety of platforms:

  • Bare metal, QEMU, OpenStack, and VMware
  • Images available in all public AWS regions
  • Downloadable cloud images for Alibaba, AWS, Azure, and GCP
  • Can run live from RAM via ISO and PXE (netboot) images

Fedora CoreOS is under active development.  Planned future enhancements include:

  • Addition of the next release stream for extended testing of upcoming Fedora releases.
  • Support for additional cloud and virtualization platforms, and processor architectures other than x86_64.
  • Closer integration with Kubernetes distributions, including OKD.
  • Aggregate statistics collection.
  • Additional documentation.

Where do I get it?

To try out the new release, head over to the download page to get OS images or cloud image IDs.  Then use the quick start guide to get a machine running quickly.

How do I get involved?

It’s easy!  You can report bugs and missing features to the issue tracker. You can also discuss Fedora CoreOS in Fedora Discourse, the development mailing list, in #fedora-coreos on Freenode, or at our weekly IRC meetings.

Are there stability guarantees?

In general, the Fedora Project does not make any guarantees around stability.  While Fedora CoreOS strives for a high level of stability, this can be challenging to achieve in the rapidly evolving Linux and container ecosystems.  We’ve found that the incremental, exploratory, forward-looking development required for Fedora CoreOS — which is also a cornerstone of the Fedora Project as a whole — is difficult to reconcile with the iron-clad stability guarantee that ideally exists when automatically updating systems.

We’ll continue to do our best not to break existing systems over time, and to give users the tools to manage the impact of any regressions.  Nevertheless, automatic updates may produce regressions or breaking changes for some use cases. You should make your own decisions about where and how to run Fedora CoreOS based on your risk tolerance, operational needs, and experience with the OS.  We will continue to announce any major planned or unplanned breakage to the coreos-status mailing list, along with recommended mitigations.

How do I migrate from CoreOS Container Linux?

Container Linux machines cannot be migrated in place to Fedora CoreOS.  We recommend writing a new Fedora CoreOS Config to provision Fedora CoreOS machines.  Fedora CoreOS Configs are similar to Container Linux Configs, and must be passed through the Fedora CoreOS Config Transpiler to produce an Ignition config for provisioning a Fedora CoreOS machine.

Whether you’re currently provisioning your Container Linux machines using a Container Linux Config, handwritten Ignition config, or cloud-config, you’ll need to adjust your configs for differences between Container Linux and Fedora CoreOS.  For example, on Fedora CoreOS network configuration is performed with NetworkManager key files instead of systemd-networkd, and time synchronization is performed by chrony rather than systemd-timesyncd.  Initial migration documentation will be available soon and a skeleton list of differences between the two OSes is available in this issue.

CoreOS Container Linux will be maintained for a few more months, and then will be declared end-of-life.  We’ll announce the exact end-of-life date later this month.

How do I migrate from Fedora Atomic Host?

Fedora Atomic Host has already reached end-of-life, and you should migrate to Fedora CoreOS as soon as possible.  We do not recommend in-place migration of Atomic Host machines to Fedora CoreOS. Instead, we recommend writing a Fedora CoreOS Config and using it to provision new Fedora CoreOS machines.  As with CoreOS Container Linux, you’ll need to adjust your existing cloud-configs for differences between Fedora Atomic Host and Fedora CoreOS.

Welcome to Fedora CoreOS.  Deploy it, launch your apps, and let us know what you think!

Posted on Leave a comment

Develop GUI apps using Flutter on Fedora

When it comes to app development frameworks, Flutter is the latest and greatest. Google seems to be planning to take over the entire GUI app development world with Flutter, starting with mobile devices, which are already perfectly supported. Flutter allows you to develop cross-platform GUI apps for multiple targets — mobile, web, and desktop — from a single codebase.

This post will go through how to install the Flutter SDK and tools on Fedora, as well as how to use them both for mobile development and web/desktop development.

Installing Flutter and Android SDKs on Fedora

To get started building apps with Flutter, you need to install

  • the Android SDK;
  • the Flutter SDK itself; and,
  • optionally, an IDE and its Flutter plugins.

Installing the Android SDK

Flutter requires the installation of the Android SDK with the entire Android Studio suite of tools. Google provides a tar.gz archive. The Android Studio executable can be found in the android-studio/bin directory and is called studio.sh. To run it, open a terminal, cd into the aforementioned directory, and then run:

$ ./studio.sh

Installing the Flutter SDK

Before you install Flutter you may want to consider what release channel you want to be on.

The stable channel is least likely to give you a headache if you just want to build a mobile app using mainstream Flutter features.

On the other hand, you may want to use the latest features, especially for desktop and web app development. In that case, you might be better off installing either the latest version of the beta or even the dev channel.

Either way, you can switch between channels after you install using the flutter channel command explained later in the article.

Head over to the official SDK archive page and download the latest installation bundle for the release channel most appropriate for your use case.

The installation bundle is simply a xz-compressed tarball (.tar.xz extension). You can extract it wherever you want, given that you add the flutter/bin subdirectory to the PATH environment variable.

Installing the IDE plugins

To install the plugin for Visual Studio Code, you need to search for Flutter in the Extensions tab. Installing it will also install the Dart plugin.

The same will happen when you install the plugin for Android Studio by opening the Settings, then the Plugins tab and installing the Flutter plugin.

Using the Flutter and Android CLI Tools on Fedora

Now that you’ve installed Flutter, here’s how to use the CLI tool.

Upgrading and Maintaining Your Flutter Installations

The flutter doctor command is used to check whether your installation and related tools are complete and don’t require any further action.

For example, the output you may get from flutter doctor right after installing on Fedora is:

Doctor summary (to see all details, run flutter doctor -v): [✓] Flutter (Channel stable, v1.12.13+hotfix.5, on Linux, locale it_IT.UTF-8) [!] Android toolchain - develop for Android devices (Android SDK version 29.0.2) ✗ Android licenses not accepted. To resolve this, run: flutter doctor --android-licenses [!] Android Studio (version 3.5) ✗ Flutter plugin not installed; this adds Flutter specific functionality. ✗ Dart plugin not installed; this adds Dart specific functionality. [!] Connected device ! No devices available ! Doctor found issues in 3 categories.

Of course the issue with the Android toolchain has to be resolved in order to build for Android. Run this command to accept the licenses:

$ flutter doctor --android-licenses

Use the flutter channel command to switch channels after installation. It’s just like switching branches on Git (and that’s actually what it does). You use it in the following way:

$ flutter channel <channel_name>

…where you’d replace <channel_name> with the release channel you want to switch to.

After doing that, or whenever you feel the need to do it, you need to update your installation. You might consider running this every once in a while or when a major update comes out if you follow Flutter news. Run this command:

$ flutter upgrade

Building for Mobile

You can build for Android very easily: the flutter build command supports it by default, and it allows you to build both APKs and newfangled app bundles.

All you need to do is to create a project with flutter create, which will generate some code for an example app and the necessary android and ios folders.

When you’re done coding you can either run:

  • flutter build apk or flutter build appbundle to generate the necessary app files to distribute, or
  • flutter run to run the app on a connected device or emulator directly.

When you run the app on a phone or emulator with flutter run, you can use the R button on the keyboard to use stateful hot reload. This feature updates what’s displayed on the phone or emulator to reflect the changes you’ve made to the code without requiring a full rebuild.

If you input a capital R character to the debug console, you trigger a hot restart. This restart doesn’t preserve state and is necessary for bigger changes to the app.

If you’re using a GUI IDE, you can trigger a hot reload using the bolt icon button and a hot restart with the typical refresh button.

Building for the Desktop

To build apps for the desktop on Fedora, use the flutter-desktop-embedding repository. The flutter create command doesn’t have templates for desktop Linux apps yet. That repository contains examples of desktop apps and files required to build on desktop, as well as examples of plugins for desktop apps.

To build or run apps for Linux, you also need to be on the master release channel and enable Linux desktop app development. To do this, run:

$ flutter config --enable-linux-desktop

After that, you can use flutter run to run the app on your development workstation directly, or run flutter build linux to build a binary file in the build/ directory.

If those commands don’t work, run this command in the project directory to generate the required files to build in the linux/ directory:

$ flutter create .

Building for the Web

Starting with Flutter 1.12, you can build Web apps using Flutter with the mainline codebase, without having to use the flutter_web forked libraries, but you have to be running on the beta channel.

If you are (you can switch to it using flutter channel beta and flutter upgrade as we’ve seen earlier), you need to enable web development by running flutter config –enable-web.

After doing that, you can run flutter run -d web and a local web server will be started from which you can access your app. The command returns the URL at which the server is listening, including the port number.

You can also run flutter build web to build the static website files in the build/ directory.

If those commands don’t work, run this command in the project directory to generate the required files to build in the web/ directory:

$ flutter create .

Packages for Installing Flutter

Other distributions have packages or community repositories to install and update in a more straightforward and intuitive way. However, at the time of writing, no such thing exists for Flutter. If you have experience packaging RPMs for Fedora, consider contributing to this GitHub repository for this COPR package.

The next step is learning Flutter. You can do that in a number of ways:

  • Read the good API reference documentation on the official site
  • Watching some of the introductory video courses available online
  • Read one of the many books out there today. [Check out the author’s bio for a suggestion! — Ed.]

Photo by Randall Ruiz on Unsplash.

Posted on Leave a comment

How to setup a DNS server with bind

The Domain Name System, or DNS, as it’s more commonly known, translates or converts domain names into the IP addresses associated with that domain. DNS is the reason you are able to find your favorite website by name instead of typing an IP address into your browser. This guide shows you how to configure a Master DNS system and one client.

Here are system details for the example used in this article:

dns01.fedora.local (192.168.1.160 ) - Master DNS server
client.fedora.local (192.168.1.136 ) - Client 

DNS server configuration

Install the bind packages using sudo:

$ sudo dnf install bind bind-utils -y

The /etc/named.conf configuration file is provided by the bind package to allow you to configure the DNS server.

Edit the /etc/named.conf file:

sudo vi /etc/named.conf

Look for the following line:

listen-on port 53 { 127.0.0.1; };

Add the IP address of your Master DNS server as follows:

listen-on port 53 { 127.0.0.1; 192.168.1.160; };

Look for the next line:

allow-query  { localhost; };

Add your local network range. The example system uses IP addresses in the 192.168.1.X range. This is specified as follows:

allow-query  { localhost; 192.168.1.0/24; };

Specify a forward and reverse zone. Zone files are simply text files that have the DNS information, such as IP addresses and host-names, on your system. The forward zone file makes it possible for the translation of a host-name to its IP address. The reverse zone file does the opposite. It allows a remote system to translate an IP address to the host name.

Look for the following line at the bottom of the /etc/named.conf file:

include "/etc/named.rfc1912.zones";

Here, you’ll specify the zone file information directly above that line as follows:

zone "dns01.fedora.local" IN {
type master;
file "forward.fedora.local";
allow-update { none; };
}; zone "1.168.192.in-addr.arpa" IN {
type master;
file "reverse.fedora.local";
allow-update { none; };
};

The forward.fedora.local and the file reverse.fedora.local are just the names of the zone files you will be creating. They can be called anything you like.

Save and exit.

Create the zone files

Create the forward and reverse zone files you specified in the /etc/named.conf file:

$ sudo vi /var/named/forward.fedora.local

Add the following lines:

$TTL 86400
@   IN  SOA     dns01.fedora.local. root.fedora.local. (
        2011071001  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)
@       IN  NS          dns01.fedora.local.
@       IN  A           192.168.1.160
dns01        IN  A   192.168.1.160
client          IN  A   192.168.1.136

Everything in bold is specific to your environment. Save the file and exit. Next, edit the reverse.fedora.local file:

$ sudo vi /var/named/reverse.fedora.local

Add the following lines:

$TTL 86400
@   IN  SOA     dns01.fedora.local. root.fedora.local. (
        2011071001  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)
@       IN  NS          dns01.fedora.local.
@       IN  PTR         fedora.local.
dns01       IN  A   192.168.1.160
client          IN  A   192.168.1.136
160     IN  PTR         dns01.fedora.local.
136     IN  PTR         client.fedora.local.

Everything in bold is also specific to your environment. Save the file and exit.

You’ll also need to configure SELinux and add the correct ownership for the configuration files.

sudo chgrp named -R /var/named
sudo chown -v root:named /etc/named.conf
sudo restorecon -rv /var/named
sudo restorecon /etc/named.conf

Configure the firewall:

sudo firewall-cmd --add-service=dns --perm
sudo firewall-cmd --reload

Check the configuration for any syntax errors

sudo named-checkconf /etc/named.conf

Your configuration is valid if no output or errors are returned.

Check the forward and reverse zone files.

$ sudo named-checkzone forward.fedora.local /var/named/forward.fedora.local $ sudo named-checkzone reverse.fedora.local /var/named/reverse.fedora.local

You should see a response of OK:

zone forward.fedora.local/IN: loaded serial 2011071001
OK zone reverse.fedora.local/IN: loaded serial 2011071001
OK

Enable and start the DNS service

$ sudo systemctl enable named
$ sudo systemctl start named

Configuring the resolv.conf file

Edit the /etc/resolv.conf file:

$ sudo vi /etc/resolv.conf

Look for your current name server line or lines. On the example system, a cable modem/router is serving as the name server and so it currently looks like this:

nameserver 192.168.1.1

This needs to be changed to the IP address of the Master DNS server:

nameserver 192.168.1.160

Save your changes and exit.

Unfortunately there is one caveat to be aware of. NetworkManager overwrites the /etc/resolv.conf file if the system is rebooted or networking gets restarted. This means you will lose all of the changes that you made.

To prevent this from happening, make /etc/resolv.conf immutable:

$ sudo chattr +i /etc/resolv.conf 

If you want to set it back and allow it to be overwritten again:

$ sudo chattr -i /etc/resolv.conf

Testing the DNS server

$ dig fedoramagazine.org
; <<>> DiG 9.11.13-RedHat-9.11.13-2.fc30 <<>> fedoramagazine.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8391
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: c7350d07f8efaa1286c670ab5e13482d600f82274871195a (good) ;; QUESTION SECTION: ;fedoramagazine.org. IN A ;; ANSWER SECTION: fedoramagazine.org. 50 IN A 35.197.52.145 ;; AUTHORITY SECTION: fedoramagazine.org. 86150 IN NS ns05.fedoraproject.org. fedoramagazine.org. 86150 IN NS ns02.fedoraproject.org. fedoramagazine.org. 86150 IN NS ns04.fedoraproject.org. ;; ADDITIONAL SECTION: ns02.fedoraproject.org. 86150 IN A 152.19.134.139 ns04.fedoraproject.org. 86150 IN A 209.132.181.17 ns05.fedoraproject.org. 86150 IN A 85.236.55.10 ns02.fedoraproject.org. 86150 IN AAAA 2610:28:3090:3001:dead:beef:cafe:fed5 ns05.fedoraproject.org. 86150 IN AAAA 2001:4178:2:1269:dead:beef:cafe:fed5 ;; Query time: 830 msec ;; SERVER: 192.168.1.160#53(192.168.1.160) ;; WHEN: Mon Jan 06 08:46:05 CST 2020 ;; MSG SIZE rcvd: 266

There are a few things to look at to verify that the DNS server is working correctly. Obviously getting the results back are important, but that by itself doesn’t mean the DNS server is actually doing the work.

The QUERY, ANSWER, and AUTHORITY fields at the top should show non-zero as it in does in our example:

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6

And the SERVER field should have the IP address of your DNS server:

;; SERVER: 192.168.1.160#53(192.168.1.160)

In case this is the first time you’ve run the dig command, notice how it took 830 milliseconds for the query to complete:

;; Query time: 830 msec

If you run it again, the query will run much quicker:

$ dig fedoramagazine.org 
;; Query time: 0 msec
;; SERVER: 192.168.1.160#53(192.168.1.160)

Client configuration

The client configuration will be a lot simpler.

Install the bind utilities:

$ sudo dnf install bind-utils -y

Edit the /etc/resolv.conf file and configure the Master DNS as the only name server:

$ sudo vi /etc/resolv.conf

This is how it should look:

nameserver 192.168.1.160

Save your changes and exit. Then, make the /etc/resolv.conf file immutable to prevent it from be overwritten and going back to its default settings:

$ sudo chattr +i /etc/resolv.conf

Testing the client

You should get the same results as you did from the DNS server:

$ dig fedoramagazine.org
; <<>> DiG 9.11.13-RedHat-9.11.13-2.fc30 <<>> fedoramagazine.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8391
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: c7350d07f8efaa1286c670ab5e13482d600f82274871195a (good) ;; QUESTION SECTION: ;fedoramagazine.org. IN A ;; ANSWER SECTION: fedoramagazine.org. 50 IN A 35.197.52.145 ;; AUTHORITY SECTION: fedoramagazine.org. 86150 IN NS ns05.fedoraproject.org. fedoramagazine.org. 86150 IN NS ns02.fedoraproject.org. fedoramagazine.org. 86150 IN NS ns04.fedoraproject.org. ;; ADDITIONAL SECTION: ns02.fedoraproject.org. 86150 IN A 152.19.134.139 ns04.fedoraproject.org. 86150 IN A 209.132.181.17 ns05.fedoraproject.org. 86150 IN A 85.236.55.10 ns02.fedoraproject.org. 86150 IN AAAA 2610:28:3090:3001:dead:beef:cafe:fed5 ns05.fedoraproject.org. 86150 IN AAAA 2001:4178:2:1269:dead:beef:cafe:fed5 ;; Query time: 1 msec ;; SERVER: 192.168.1.160#53(192.168.1.160) ;; WHEN: Mon Jan 06 08:46:05 CST 2020 ;; MSG SIZE rcvd: 266

Make sure the SERVER output has the IP Address of your DNS server.

Your DNS server is now ready to use and all requests from the client should be going through your DNS server now!

Posted on Leave a comment

How to setup multiple monitors in sway

Sway is a tiling Wayland compositor which has mostly the same features, look and workflow as the i3 X11 window manager. Because Sway uses Wayland instead of X11, the tools to setup X11 don’t always work in sway. This includes tools like xrandr, which are used in X11 window managers or desktops to setup monitors. This is why monitors have to be setup by editing the sway config file, and that’s what this article is about.

Getting your monitor ID’s

First, you have to get the names sway uses to refer to your monitors. You can do this by running:

$ swaymsg -t get_outputs

You will get information about all of your monitors, every monitor separated by an empty line.

You have to look for the first line of every section, and for what’s after “Output”. For example, when you see a line like “Output DVI-D-1 ‘Philips Consumer Electronics Company’”, the output ID is “DVI-D-1”. Note these ID’s and which physical monitors they belong to.

Editing the config file

If you haven’t edited the Sway config file before, you have to copy it to your home directory by running this command:

cp -r /etc/sway/config ~/.config/sway/config

Now the default config file is located in ~/.config/sway and called “config”. You can edit it using any text editor.

Now you have to do a little bit of math. Imagine a grid with the origin in the top left corner. The units of the X and Y coordinates are pixels. The Y axis is inverted. This means that if you, for example, start at the origin and you move 100 pixels to the right and 80 pixels down, your coordinates will be (100, 80).

You have to calculate where your displays are going to end up on this grid. The locations of the displays are specified with the top left pixel. For example, if we want to have a monitor with name HDMI1 and a resolution of 1920×1080, and to the right of it a laptop monitor with name eDP1 and a resolution of 1600×900, you have to type this in your config file:

output HDMI1 pos 0 0
output eDP1 pos 1920 0

You can also specify the resolutions manually by using the res option: 

output HDMI1 pos 0 0 res 1920x1080
output eDP1 pos 1920 0 res 1600x900

Binding workspaces to monitors

Using sway with multiple monitors can be a little bit tricky with workspace management. Luckily, you can bind workspaces to a specific monitor, so you can easily switch to that monitor and use your displays more efficiently. This can simply be done by the workspace command in your config file. For example, if you want to bind workspace 1 and 2 to monitor DVI-D-1 and workspace 8 and 9 to monitor HDMI-A-1, you can do that by using:

workspace 1 output DVI-D-1
workspace 2 output DVI-D-1
workspace 8 output HDMI-A-1
workspace 9 output HDMI-A-1

That’s it! These are the basics of multi monitor setup in sway. A more detailed guide can be found at https://github.com/swaywm/sway/wiki#Multihead

Posted on Leave a comment

Most read articles in 2019 not from 2019

Some topics are very popular, no matter when they’re first mentioned. And Fedora Magazine has a few articles that have proven to be popular for a long time.

You’re reading the last article from the “best of 2019” series. But this time, it’s about articles written before 2019, but being very popular in 2019.

All of the articles below have been checked and updated to be correct even now, in early 2020. Let’s dive in!

i3 tiling window manager

Wish to try an alternative desktop? The following article introduces i3 — a tiling window manager that doesn’t require high-end hardware, but is powerful and highly customizable. You’ll learn about the installation process, some initial setup, and a few tricks to get you started.

Powerline

Would you like to have your shell a bit more organized? Then you might want to try Powerline — a utility that gives you status information, and some visual tweaks to your shell to make it more pleasant and organized.

Monospace fonts

Do you spend a lot of your time in terminal or a code editor? And is your font making you happy? Discover some beautiful monospace fonts available in the Fedora repositories.

Image viewers

Is the default image viewer on your desktop not working the way you want? The following article shows 17 image viewers available in Fedora — varying from simpler to ones full of features.

Fedora as a VirtualBox guest

Love Fedora but your machine runs Windows or macOS? One option to get Fedora running on your machine is virtualization. Your system keeps running and you’ll be able to access Fedora at the same time in a virtual machine. The following article introduces VirtualBox that can do just that.

Posted on Leave a comment

Tracking Translations with Transtats

Translation is an important step in software localization which helps make software more popular globally, and impacts international user experience. In recent years, localization processes have been evolving worldwide to become more continuous, faster, efficient with automation. In Fedora, the development of the Zanata platform and its plugins, then Transtats, and now the migration to the Weblate platform are part of this common ongoing goal. The localization of a desktop OS like Fedora is highly complex because it depends on many factors of the individual upstream projects which are packaged in Fedora. For example, different translation timelines, resources, and tooling.

What is Transtats?

Transtats is a web application which tries to tie up upstream repositories, translation platforms, build system, and product release schedule together to solve problems of mismatch, out-of-sync conditions and to assist the timely packaging of quality translations. Actually, it collects translation data, analyzes them, and creates meaningful representations.

Fedora Transtats is hosted at https://transtats.fedoraproject.org/

How to see the translation status of my package?

Just select Packages tab from left hand side navigation bar. This takes us to the packages list view. Then, search for the package and click on its name.

For example anaconda. On package details page, locate following:

Here, we have translation statistics from translation platform: Zanata and Koji build system. Syncs with the platform and build system are scheduled, which update differences periodically. Languages in red color indicate that there are translated strings remaining in the Translation Platform to be pulled and packaged, whereas, blue denote translated messages could not make 100% in the built package.

String breakage (or changes?)

In translation of software packages, one of the challenges is to prevent string breakage. Package maintainers should strive to abide by the scheduled Fedora release String Freeze. However, in some circumstances it could be necessary to break the string freeze and to inform the translation team on the mailing list. As well as, to update latest translation template (POT) file in the translation platform. Just in case these actions seem missing – translators may get new strings to translate very late or the application may have some strings untranslated. In the worst case, an outdated translation string mismatch may result in a crash. Sync and automation pipelines are there to prevent this, nevertheless it depends on the push or pull methods followed by package developers or maintainers.

To deal with the same context, we can use a job template in Transtats to detect this string change – particularly useful after string freeze in Fedora release schedule. This would be really helpful for the folks who look for packaging translations without string breakage, keeping translation template (POT) file in sync with translation platform, and testing localized form of the application for translation completeness to back trace.

How to detect string changes?

One of the options in Jobs tab is ‘YML based Jobs’. Where we can see available job templates.

The jobs framework executes all the tasks mentioned in the YAML, create appropriate logs and store results. Track String Change job basically:

  1. Clones the source repository of respective package.
  2. Tries to generate translation template (POT) file.
  3. Downloads POT file from respective translation platform.
  4. And, finds differences between both the POT files.

Actually, Transtats maintains mapping of upstream repository, Translation Platform project and respective build tag for every package.

Let’s take a closer look into this YAML. We can provide value for %PACKAGE_NAME% and %RELEASE_SLUG% in the next step – Set Values! For example: anaconda and fedora-32. Furthermore, a couple of things seek attention are:

  • In case the upstream software repository maintains separate git branch for fedora release, please edit ‘branch: master’ to ‘branch: <fedora-release-branch>’
  • In ‘generate’ block, mention the command to generate POT file. Default one should work for ‘intltool-update’ only, however, many packages do have their own.
  • A few packages may have gettext domain name different than that of package name. If this is the case, mention the gettext domain too.

As soon as the job is triggered, logs should be populated. If this is not a scratch run, a unique URL shall also be created at the end.

Left hand side is the input YAML and right hand side is respective log for each task. Here we can find the differences and figure out string mismatch.

In Transtats, we can create solutions to different problems in the form of job templates. And, scheduling of these jobs could be a step towards automation.

Posted on Leave a comment

Top articles of 2019: Editors’ choice

The year is still ending and the perfect time to reflect and look back at some Magazine articles continues. This time, let’s see if the editors chose some interesting ones from 2019. Yes, they did!

Red Hat, IBM, and Fedora

IBM acquired Red Hat in July 2019, and this article discusses how nothing changes for the Fedora project.

Some tips for the Workstation users

Using Fedora Workstation? This article gives you some tips including enhancing photos, coding, or getting more wallpapers right from the repositories.

Fedora and CentOS Stream

In this article, the Fedora Project Leader discusses the CentOS Stream announcement from September 2019 — including the relationship of Fedora, Red Hat Enterprise Linux, and CentOS.

Contribute to Fedora Magazine

Fedora Magazine exists thanks to our great contributors. And you (yes, you!) can become one, too! Contributions include topic proposals, writing, and editorial tasks. This article shows you how to join the team and help people learn about Linux.

Posted on Leave a comment

Top articles of 2019: For desktop users

It’s this time of the year again — the time to reflect, and look back at some Fedora Magazine’s most popular articles in 2019. This time it’s all about desktop users. Let’s highlight a few of the many articles written by our great contributors in 2019, focusing on Fedora as a desktop OS.

Dash to Dock extension for Workstation

When you’re serious about your desktop, and perhaps using many applications, you might want to see what’s going on at all times. Or at least the icons. The article below shows you how to have a dock at the bottom of your screen, with all your apps — both running and favourites — visible at all times.

Tweaking the look of Workstation with themes

When you like how your Linux desktop works, but not so much how it looks, there is a solution. The following article shows you how to tweak the look of your windows, icons, the mouse cursor, and the whole environment as well — all that within GNOME, the Workstation’s default environment.

i3 with multiple monitors

One of the great things about Linux desktop is the never ending possibilities of customisation. And that includes window managers, too! The following article shows how to use one of the very popular ones — i3 — with multiple monitors.

IceWM

If you’re looking for speed, simplicity, and getting out of the user’s way, you might like IceWM. The following article introduces this minimal window manager, and helps you install it, too, should you be interested.

Stay tuned for even more upcoming “Best of 2019” articles. All of us at the Magazine hope you have a relaxing holiday season, and wish you a happy new year.

Posted on Leave a comment

Best of 2019: Fedora for developers

With the end of the year approaching fast, it is a good time to look back at 2019 and go through the most popular articles on Fedora Magazine written by our contributors.

In this article of the “Best of 2019” series, we are looking at developers and how to use Fedora to be a great developer workstation

Make your Python code look good with Black on Fedora

Black made quite a big impact in the Python ecosystem this year. The project is now part of the Python Software Foundation and it is used by many different projects. So if you write or maintain some Python code and want to stop having to care about code style and code formatting you should check out this article.

How to run virtual machines with virt-manager

Setting up a development environment, running integration tests, testing a new feature, or running an older version of software for all these use cases being able to create and run a virtual machine is a must have knowledge for a developer. This article will walk you through how you can achieve that using virt-manager on your Fedora workstation.

Jupyter and data science in Fedora

With the rise of Data science and machine learning, the Jupyter IDE has become of very popular choice to share or present a program and its results. This article goes into the details of installing and using Jupyter and the different libraries and tools useful for data science.

Building Smaller Container Images

Fedora provides different container images, one of which is a minimal base image. The following article demonstrate how one can use this image to build smaller container images.

Getting Started with Go on Fedora

In 2019 the Go programming language turned 10 year old. In ten years the language has managed to become the default choice for cloud native applications and the cloud ecosystems. Fedora is providing an easy way to start developing in Go, this article takes you through the first step needed to get started.

Stay tuned to the Magazine for other upcoming “Best of 2019” categories. All of us at the Magazine hope you have a great end of year and holiday season.

Posted on Leave a comment

Best of 2019: Fedora for system administrators

The end of the year is a perfect time to look back on some of the Magazine’s most popular articles of 2019. One of the Fedora operating systems’s many strong points is its wide array of tools for system administrators. As your skills progress, you’ll find that the Fedora OS has even more to offer. And because Linux is the sysadmin’s best friend, you’ll always be in good company. In 2019, there were quite a few articles about sysadmin tools our readers enjoyed. Here’s a sampling.

Introducing Fedora CoreOS

If you follow modern IT topics, you know that containers are a hot topic — and containers mean Linux. This summer brought the first preview release of Fedora CoreOS. This new edition of Fedora can run containerized workloads. You can use it to deploy apps and services in a modern way.

InitRAMFS, dracut and the dracut emergency shell

To be a good sysadmin, you need to understand system startup and the boot process. From time to time, you’ll encounter software errors, configuration problems, or other issues that keep your system from starting normally. With the information in the article below, you can do some life-saving surgery on your system, and restore it to working order.

How to reset your root password

Although this article was published a few years ago, it continues to be one of the most popular. Apparently, we’re not the only people who sometimes get locked out of our own system! If this happens to you, and you need to reset the root password, the article below should do the trick.

Systemd: unit dependencies and order

This article is part of an entire series on systemd, the modern system and process manager in Fedora and other distributions. As you may know, systemd has sophisticated but easy to use methods to start up or shut own services in the right order. This article shows you how they work. That way you can apply the right options to unit files you create for systemd.

Setting kernel command line arguments

Fedora 30 introduced new ways to change the boot options for your kernel. This article from Laura Abbott on the Fedora kernel team explains the new Bootloader Spec (BLS). It also tells you how to use it to set options on your kernel for boot time.

Stay tuned to the Magazine for other upcoming “Best of 2019” categories. All of us at the Magazine hope you have a great end of year and holiday season.