GNU Planet!

The Free Software Movement campaigns for computer users' freedom to cooperate and control their own computing. The Free Software Movement developed the GNU operating system, typically used together with the kernel Linux, specifically to make these freedoms possible.

This speech by Richard Stallman will be nontechnical, admission is gratis, and the public is encouraged to attend.

Location: University Cinema Scala, MoravskĂŠ nĂĄm. 127/3, 602 00 Brno, Czech Republic

Registration, which can be done anonymously, while not required, is appreciated; it will help us ensure we can accommodate all the people who wish to attend.

Please fill out our contact form, so that we can contact you about future events in and around Brno.

Guix is, at its core, a source based distribution with substitutes, and as such building packages from their source code is an expected part of regular package installations and upgrades. Given this starting point, it makes sense that efforts are made to reduce the amount of time spent compiling packages, and recent changes and upgrades to the building and distribution of substitutes continues to be a topic of discussion within Guix.

One of the packages which I prefer to not build myself is the Linux-Libre kernel. The kernel, while not requiring an overabundance of RAM to build, does take a very long time on my build machine (which my children argue is actually their Kodi computer), and I will often delay reconfiguring my laptop while I want for a substitute to be prepared by the official build farm. The official kernel configuration, as is the case with many GNU/Linux distributions, errs on the side of inclusiveness, and this is really what causes the build to take such a long time when I build the package for myself.

The Linux kernel, however, can also just be described as a package installed on my machine, and as such can be customized just like any other package. The procedure is a little bit different, although this is primarily due to the nature of how the package definition is written.

The linux-libre kernel package definition is actually a procedure which creates a package.

(define* (make-linux-libre version hash supported-systems #:key ;; A function that takes an arch and a variant. ;; See kernel-config for an example. (extra-version #f) (configuration-file #f) (defconfig "defconfig") (extra-options %default-extra-linux-options) (patches (list %boot-logo-patch))) ...)

The current linux-libre package is for the 5.1.x series, and is declared like this:

(define-public linux-libre (make-linux-libre %linux-libre-version %linux-libre-hash '("x86_64-linux" "i686-linux" "armhf-linux" "aarch64-linux") #:patches %linux-libre-5.1-patches #:configuration-file kernel-config))

Any keys which are not assigned values inherit their default value from the make-linux-libre definition. When comparing the two snippets above, you may notice that the code comment in the first doesn't actually refer to the #:extra-version keyword; it is actually for #:configuration-file. Because of this, it is not actually easy to include a custom kernel configuration from the definition, but don't worry, there are other ways to work with what we do have.

There are two ways to create a kernel with a custom kernel configuration. The first is to provide a standard .config file during the build process by including an actual .config file as a native input to our custom kernel. The following is a snippet from the custom 'configure phase of the make-linux-libre package definition:

(let ((build (assoc-ref %standard-phases 'build)) (config (assoc-ref (or native-inputs inputs) "kconfig"))) ;; Use a custom kernel configuration file or a default ;; configuration file. (if config (begin (copy-file config ".config") (chmod ".config" #o666)) (invoke "make" ,defconfig))

Below is a sample kernel package for one of my computers. Linux-Libre is just like other regular packages and can be inherited and overridden like any other:

(define-public linux-libre/E2140 (package (inherit linux-libre) (native-inputs `(("kconfig" ,(local-file "E2140.config")) ,@(alist-delete "kconfig" (package-native-inputs linux-libre))))))

In the same directory as the file defining linux-libre-E2140 is a file named E2140.config, which is an actual kernel configuration file. I left the defconfig keyword of make-linux-libre blank, so the only kernel configuration in the package is the one which I included as a native-input.

The second way to create a custom kernel is to pass a new value to the extra-options keyword of the make-linux-libre procedure. The extra-options keyword works with another function defined right below it:

(define %default-extra-linux-options `(;; https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00039.html ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #t) ;; Modules required for initrd: ("CONFIG_NET_9P" . m) ("CONFIG_NET_9P_VIRTIO" . m) ("CONFIG_VIRTIO_BLK" . m) ("CONFIG_VIRTIO_NET" . m) ("CONFIG_VIRTIO_PCI" . m) ("CONFIG_VIRTIO_BALLOON" . m) ("CONFIG_VIRTIO_MMIO" . m) ("CONFIG_FUSE_FS" . m) ("CONFIG_CIFS" . m) ("CONFIG_9P_FS" . m))) (define (config->string options) (string-join (map (match-lambda ((option . 'm) (string-append option "=m")) ((option . #t) (string-append option "=y")) ((option . #f) (string-append option "=n"))) options) "\n"))

And in the custom configure script from the make-linux-libre package:

;; Appending works even when the option wasn't in the ;; file. The last one prevails if duplicated. (let ((port (open-file ".config" "a")) (extra-configuration ,(config->string extra-options))) (display extra-configuration port) (close-port port)) (invoke "make" "oldconfig"))))

So by not providing a configuration-file the .config starts blank, and then we write into it the collection of flags that we want. Here's another custom kernel which I have:

(define %macbook41-full-config (append %macbook41-config-options %filesystems %efi-support %emulation (@@ (gnu packages linux) %default-extra-linux-options))) (define-public linux-libre-macbook41 ;; XXX: Access the internal 'make-linux-libre' procedure, which is ;; private and unexported, and is liable to change in the future. ((@@ (gnu packages linux) make-linux-libre) (@@ (gnu packages linux) %linux-libre-version) (@@ (gnu packages linux) %linux-libre-hash) '("x86_64-linux") #:extra-version "macbook41" #:patches (@@ (gnu packages linux) %linux-libre-5.1-patches) #:extra-options %macbook41-config-options))

From the above example %filesystems is a collection of flags I compiled enabling different filesystem support, %efi-support enables EFI support and %emulation enables my x86_64-linux machine to act in 32-bit mode also. %default-extra-linux-options are the ones quoted above, which had to be added in since I replaced them in the extra-options keyword.

This all sounds like it should be doable, but how does one even know which modules are required for their system? The two places I found most helpful to try to answer this question were the Gentoo Handbook, and the documentation from the kernel itself. From the kernel documentation, it seems that make localmodconfig is the command we want.

In order to actually run make localmodconfig we first need to get and unpack the kernel source code:

tar xf $(guix build linux-libre --source)

Once inside the directory containing the source code run touch .config to create an initial, empty .config to start with. make localmodconfig works by seeing what you already have in .config and letting you know what you're missing. If the file is blank then you're missing everything. The next step is to run:

guix environment linux-libre -- make localmodconfig

and note the output. Do note that the .config file is still empty. The output generally contains two types of warnings. The first start with "WARNING" and can actually be ignored in our case. The second read:

module pcspkr did not have configs CONFIG_INPUT_PCSPKR

For each of these lines, copy the CONFIG_XXXX_XXXX portion into the .config in the directory, and append =m, so in the end it looks like this:

CONFIG_INPUT_PCSPKR=m CONFIG_VIRTIO=m

After copying all the configuration options, run make localmodconfig again to make sure that you don't have any output starting with "module". After all of these machine specific modules there are a couple more left that are also needed. CONFIG_MODULES is necessary so that you can build and load modules separately and not have everything built into the kernel. CONFIG_BLK_DEV_SD is required for reading from hard drives. It is possible that there are other modules which you will need.

This post does not aim to be a guide to configuring your own kernel however, so if you do decide to build a custom kernel you'll have to seek out other guides to create a kernel which is just right for your needs.

The second way to setup the kernel configuration makes more use of Guix's features and allows you to share configuration segments between different kernels. For example, all machines using EFI to boot have a number of EFI configuration flags that they need. It is likely that all the kernels will share a list of filesystems to support. By using variables it is easier to see at a glance what features are enabled and to make sure you don't have features in one kernel but missing in another.

Left undiscussed however, is Guix's initrd and its customization. It is likely that you'll need to modify the initrd on a machine using a custom kernel, since certain modules which are expected to be built may not be available for inclusion into the initrd.

Suggestions and contributions toward working toward a satisfactory custom initrd and kernel are welcome!

About GNU Guix

GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the kernel Linux, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines.

In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language.

Richard Stallman will be speaking at the Unconference (2019-05-30–06-01).

Copyright developed in the age of the printing press, and was designed to fit with the system of centralized copying imposed by the printing press. But the copyright system does not fit well with computer networks, and only draconian punishments can enforce it. The global corporations that profit from copyright are lobbying for draconian punishments, and to increase their copyright powers, while suppressing public access to technology. But if we seriously hope to serve the only legitimate purpose of copyright–to promote progress, for the benefit of the public–then we must make changes in the other direction.

This speech will be nontechnical, admission is gratis, and the public is encouraged to attend.

Location: University of Nicosia, Cyprus

Please fill out our contact form, so that we can contact you about future events in and around Nicosia.

We are pleased to announce the release of GNU Guix version 1.0.1. This new version fixes bugs in the graphical installer for the standalone Guix System.

The release comes with ISO-9660 installation images, a virtual machine image, and with tarballs to install the package manager on top of your GNU/Linux distro, either from source or from binaries. Guix users can update by running guix pull.

It’s been just over two weeks since we announced 1.0.0—two weeks and 706 commits by 40 people already!

This is primarily a bug-fix release, specifically focusing on issues in the graphical installer for the standalone system:

• The most embarrassing bug would lead the graphical installer to produce a configuration where %base-packages was omitted from the packages field. Consequently, the freshly installed system would not have the usual commands in $PATH—ls, ps, etc.—and Xfce would fail to start for that reason. See below for a “post-mortem” analysis.
• The wpa-supplicant service would sometimes fail to start in the installation image, thereby breaking network access; this is now fixed.
• The installer now allows you to toggle the visibility of passwords and passphrases, and it no longer restricts their length.
• The installer can now create Btrfs file systems.
• network-manager-applet is now part of %desktop-services, and thus readily usable not just from GNOME but also from Xfce.
• The NEWS file has more details, but there were also minor bug fixes for guix environment, guix search, and guix refresh.

A couple of new features were reviewed in time to make it into 1.0.1:

• guix system docker-image now produces an OS image with an “entry point”, which makes it easier to use than before.
• guix system container has a new --network option, allowing the container to share networking access with the host.
• 70 new packages were added and 483 packages were updated.
• Translations were updated as usual and we are glad to announce a 20%-complete Russian translation of the manual.

Recap of bug #35541

The 1.0.1 release was primarily motivated by bug #35541, which was reported shortly after the 1.0.0 release. If you installed Guix System with the graphical installer, chances are that, because of this bug, you ended up with a system where all the usual GNU/Linux commands—ls, grep, ps, etc.—were not in $PATH. That in turn would also prevent Xfce from starting, if you chose that desktop environment for your system.

We quickly published a note in the system installation instructions explaining how to work around the issue:

• First, install packages that provide those commands, along with the text editor of your choice (for example, emacs or vim):

  guix install coreutils findutils grep procps sed emacs vim

• At this point, the essential commands you would expect are available. Open your configuration file with your editor of choice, for example emacs, running as root:

  sudo emacs /etc/config.scm

• Change the packages field to add the “base packages” to the list of globally-installed packages, such that your configuration looks like this:

  (operating-system ;; … snip … (packages (append (list (specification->package "nss-certs")) %base-packages)) ;; … snip … )

• Reconfigure the system so that your new configuration is in effect:

  guix pull && sudo guix system reconfigure /etc/config.scm

If you already installed 1.0.0, you can perform the steps above to get all these core commands back.

Guix is purely declarative: if you give it an operating system definition where the “base packages” are not available system-wide, then it goes ahead and installs precisely that. That’s exactly what happened with this bug: the installer generated such a configuration and passed it to guix system init as part of the installation process.

Lessons learned

Technically, this is a “trivial” bug: it’s fixed by adding one line to your operating system configuration and reconfiguring, and the fix for the installer itself is also a one-liner. Nevertheless, it’s obviously a serious bug for the impression it gives—this is not the user experience we want to offer. So how did such a serious bug go through unnoticed?

For several years now, Guix has had a number of automated system tests running in virtual machines (VMs). These tests primarily ensure that system services work as expected, but some of them specifically test system installation: installing to a RAID or encrypted device, with a separate /home, using Btrfs, etc. These tests even run on our continuous integration service (search for the “tests.*” jobs there).

Unfortunately, those installation tests target the so-called “manual” installation process, which is scriptable. They do not test the installer’s graphical user interface. Consequently, testing the user interface (UI) itself was a manual process. Our attention was, presumably, focusing more on UI aspects since—so we thought—the actual installation tests were already taken care of by the system tests. That the generated system configuration could be syntactically correct but definitely wrong from a usability viewpoint perhaps didn’t occur to us. The end result is that the issue went unnoticed.

The lesson here is that: manual testing should also look for issues in “unexpected places”, and more importantly, we need automated tests for the graphical UI. The Debian and Guix installer UIs are similar—both using the Newt toolkit. Debian tests its installer using “pre-seeds” (code), which are essentially answers to all the questions and choices the UI would present. We could adopt a similar approach, or we could test the UI itself at a lower level—reading the screen, and simulating key strokes. UI testing is notoriously tricky so we’ll have to figure out how to get there.

Conclusion

Our 1.0 party was a bit spoiled by this bug, and we are sorry that installation was disappointing to those of you who tried 1.0. We hope 1.0.1 will allow you to try and see what declarative and programmable system configuration management is like, because that’s where the real value of Guix System is—the graphical installer is icing on the cake.

Join us on #guix and on the mailing lists!

About GNU Guix

GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the kernel Linux, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines.

In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language.

We are happy to announce the release of Bison 3.4.

A particular focus was put on improving the diagnostics, which are now
colored by default, and accurate with multibyte input. Their format was
also changed, and is now similar to GCC 9's diagnostics.

Users of the default backend (yacc.c) can use the new %define variable
api.header.include to avoid duplicating the content of the generated header
in the generated parser. There are two new examples installed, including a
reentrant calculator which supports recursive calls to the parser and
Flex-generated scanner.

See below for more details.

==================================================================

Bison is a general-purpose parser generator that converts an annotated
context-free grammar into a deterministic LR or generalized LR (GLR) parser
employing LALR(1) parser tables. Bison can also generate IELR(1) or
canonical LR(1) parser tables. Once you are proficient with Bison, you can
use it to develop a wide range of language parsers, from those used in
simple desk calculators to complex programming languages.

Bison is upward compatible with Yacc: all properly-written Yacc grammars
work with Bison with no change. Anyone familiar with Yacc should be able to
use Bison with little trouble. You need to be fluent in C, C++ or Java
programming in order to use Bison.

Here is the GNU Bison home page:
https://gnu.org/software/bison/

==================================================================

Here are the compressed sources:
https://ftp.gnu.org/gnu/bison/bison-3.4.tar.gz (4.1MB)
https://ftp.gnu.org/gnu/bison/bison-3.4.tar.xz (3.1MB)

Here are the GPG detached signatures[*]:
https://ftp.gnu.org/gnu/bison/bison-3.4.tar.gz.sig
https://ftp.gnu.org/gnu/bison/bison-3.4.tar.xz.sig

Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:

gpg --verify bison-3.4.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys 0DDCAA3278D5264E

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
Autoconf 2.69
Automake 1.16.1
Flex 2.6.4
Gettext 0.19.8.1
Gnulib v0.1-2563-gd654989d8

==================================================================

NEWS

* Noteworthy changes in release 3.4 (2019-05-19) [stable] ** Deprecated features The %pure-parser directive is deprecated in favor of '%define api.pure' since Bison 2.3b (2008-05-27), but no warning was issued; there is one now. Note that since Bison 2.7 you are strongly encouraged to use '%define api.pure full' instead of '%define api.pure'. ** New features *** Colored diagnostics As an experimental feature, diagnostics are now colored, controlled by the new options --color and --style. To use them, install the libtextstyle library before configuring Bison. It is available from https://alpha.gnu.org/gnu/gettext/ for instance https://alpha.gnu.org/gnu/gettext/libtextstyle-0.8.tar.gz The option --color supports the following arguments: - always, yes: Enable colors. - never, no: Disable colors. - auto, tty (default): Enable colors if the output device is a tty. To customize the styles, create a CSS file similar to /* bison-bw.css */ .warning { } .error { font-weight: 800; text-decoration: underline; } .note { } then invoke bison with --style=bison-bw.css, or set the BISON_STYLE environment variable to "bison-bw.css". *** Disabling output When given -fsyntax-only, the diagnostics are reported, but no output is generated. The name of this option is somewhat misleading as bison does more than just checking the syntax: every stage is run (including checking for conflicts for instance), except the generation of the output files. *** Include the generated header (yacc.c) Before, when --defines is used, bison generated a header, and pasted an exact copy of it into the generated parser implementation file. If the header name is not "y.tab.h", it is now #included instead of being duplicated. To use an '#include' even if the header name is "y.tab.h" (which is what happens with --yacc, or when using the Autotools' ylwrap), define api.header.include to the exact argument to pass to #include. For instance: %define api.header.include {"parse.h"} or %define api.header.include {<parser/parse.h>} *** api.location.type is now supported in C (yacc.c, glr.c) The %define variable api.location.type defines the name of the type to use for locations. When defined, Bison no longer defines YYLTYPE. This can be used in programs with several parsers to factor their definition of locations: let one of them generate them, and the others just use them. ** Changes *** Graphviz output In conformance with the recommendations of the Graphviz team, if %require "3.4" (or better) is specified, the option --graph generates a *.gv file by default, instead of *.dot. *** Diagnostics overhaul Column numbers were wrong with multibyte characters, which would also result in skewed diagnostics with carets. Beside, because we were indenting the quoted source with a single space, lines with tab characters were incorrectly underlined. To address these issues, and to be clearer, Bison now issues diagnostics as GCC9 does. For instance it used to display (there's a tab before the opening brace): foo.y:3.37-38: error: $2 of ‘expr’ has no declared type expr: expr '+' "number" { $$ = $1 + $2; } ^~ It now reports foo.y:3.37-38: error: $2 of ‘expr’ has no declared type 3 | expr: expr '+' "number" { $$ = $1 + $2; } | ^~ Other constructs now also have better locations, resulting in more precise diagnostics. *** Fix-it hints for %empty Running Bison with -Wempty-rules and --update will remove incorrect %empty annotations, and add the missing ones. *** Generated reports The format of the reports (parse.output) was improved for readability. *** Better support for --no-line. When --no-line is used, the generated files are now cleaner: no lines are generated instead of empty lines. Together with using api.header.include, that should help people saving the generated files into version control systems get smaller diffs. ** Documentation A new example in C shows an simple infix calculator with a hand-written scanner (examples/c/calc). A new example in C shows a reentrant parser (capable of recursive calls) built with Flex and Bison (examples/c/reccalc). There is a new section about the history of Yaccs and Bison. ** Bug fixes A few obscure bugs were fixed, including the second oldest (known) bug in Bison: it was there when Bison was entered in the RCS version control system, in December 1987. See the NEWS of Bison 3.3 for the previous oldest bug.

This is ThinkPenguin's second batch of devices to receive RYF certification this spring. The FSF announced certification of seven other devices from ThinkPenguin on March 21st. This latest collection of devices makes ThinkPenguin the retailer with the largest catalog of RYF-certified devices.

"It's unfortunate that so many of even the simplest devices out there have surprise proprietary software requirements. RYF is an antidote for that. It connects ethical shoppers concerned about their freedom with companies offering options respecting that freedom," said the FSF's executive director, John Sullivan.

Today's certifications expands the availability of RYF-certified peripheral devices. The Penguin USB 2.0 External USB Stereo Sound Adapter and the 5.1 Channels 24-bit 96KHz PCI Express Audio Sound Card help users get the most of their computers in terms of sound quality. For wireless connectivity, ThinkPenguin offers the Wireless N PCI Express Dual-Band Mini Half-Height Card and Penguin Wireless N Mini PCIe Card. For users with an older printer, the USB to Parallel Printer Cable can let them continue to use it with their more current hardware. Finally, the PCIe eSATA / SATA 6Gbps Controller Card help users to connect to external eSATA devices as well as internal SATA.

"I've spent the last 14 years working on projects aimed at making free software adoption easy for everyone, but the single greatest obstacle over the past 20 years has not been software. It's been hardware. The RYF program helps solve this problem by linking users to trustworthy sources where they can get hardware guaranteed to work on GNU/Linux, and be properly supported using free software," said Christopher Waid, founder and CEO of ThinkPenguin.

While ThinkPenguin has consistently sought certification since the inception of the RYF program -- gaining their first certification in 2013, and adding several more over the years since -- the pace at which they are gaining certifications now eclipses all past efforts.

"ThinkPenguin continues to impress with the rapid expansion of their catalog of RYF-certified devices. Adding 14 new devices in a little over a month shows their dedication to the RYF certification program and the protection of users it represents," said the FSF's licensing and compliance manager, Donald Robertson, III.

To learn more about the Respects Your Freedom certification program, including details on the certification of these ThinkPenguin devices, please visit https://fsf.org/ryf.

Retailers interested in applying for certification can consult https://www.fsf.org/resources/hw/endorsement/criteria.

About the Free Software Foundation

The Free Software Foundation, founded in 1985, is dedicated to promoting computer users' right to use, study, copy, modify, and redistribute computer programs. The FSF promotes the development and use of free (as in freedom) software -- particularly the GNU operating system and its GNU/Linux variants -- and free documentation for free software. The FSF also helps to spread awareness of the ethical and political issues of freedom in the use of software, and its Web sites, located at https://fsf.org and https://gnu.org, are an important source of information about GNU/Linux. Donations to support the FSF's work can be made at https://donate.fsf.org. Its headquarters are in Boston, MA, USA.

More information about the FSF, as well as important information for journalists and publishers, is at https://www.fsf.org/press.

About ThinkPenguin, Inc.

Started by Christopher Waid, founder and CEO, ThinkPenguin, Inc., is a consumer-driven company with a mission to bring free software to the masses. At the core of the company is a catalog of computers and accessories with broad support for GNU/Linux. The company provides technical support for end-users and works with the community, distributions, and upstream projects to make GNU/Linux all that it can be.

Media Contacts

Donald Robertson, III
Licensing and Compliance Manager
Free Software Foundation
+1 (617) 542 5942
licensing@fsf.org

ThinkPenguin, Inc.
+1 (888) 39 THINK (84465) x703
media@thinkpenguin.com

At the LibrePlanet 2019 conference, the Free Software Foundation (FSF) recorded 40 speaker sessions -- over 24 hours of video, and they are now online on our GNU MediaGoblin instance.

The FSF team put their heads together and selected a few of our favorites from the entire 2019 Libreplanet program for you to start with -- brought to you in a Digital Restrictions Management (DRM)-free, downloadable, free format.

• In their talk, entitled "Sharing global opportunities for new developers in the Wikipedia community," Srishti Sethi gave us some valuable insights into how you can get involved in the Wikipedia community.

• Amanda Sopkin's talk, "The secret battle of encryption algorithms," delved into the history of encryption, with lots of fun factoids about how encryption methods were invented, used and foiled.

• Martha Esperilla and StefanĂ­a Acevedo joined us from Hackerspace Rancho ElectrĂłnico, sharing their work in building community around their work, including CoAA TV, an online audiovisual archive.

• In "GPL enforcement and customer benefits: Evidence from OpenWRT," Do Yoon Kim explained to us how his research shows that free software wireless routers are valued higher and sell better.

• Mary Kate Fain asked us "What free software can learn from successful social movements," and answered this question by sharing experiences as a grassroots organizer and as a free software activist.

• Free Software Award winners OpenStreetMap and Deb Nicholson both shared their work talking about "OpenStreetMap" mapping developments, and the free software community challenges we face in "Free software/utopia," respectively.

These are just a few of the interesting and varied subjects discussed at the LibrePlanet 2019 conference. Please have a look at the entire collection of 2019 videos and photos for hours of viewing pleasure. And if you really can't get enough, you can scroll down to the archives, where you can revisit the 2018 videos and photos, and much more.

All the LibrePlanet 2019 videos were created using free software, with high resolution USB Web cameras and USB audio mixing desks, whose drivers are supported by Trisquel. We want to thank everyone who participated in LibrePlanet 2019, plus our sponsor, Red Hat, and you too, for your continued support of free software, the FSF, and LibrePlanet.

We look forward to welcoming you again in 2020!

2019-05-12: GNUnet 0.11.4 released

We are pleased to announce the release of GNUnet 0.11.4.

This is a bugfix release for 0.11.3, mostly fixing minor bugs, improving documentation and fixing various build issues. In terms of usability, users should be aware that there are still a large number of known open issues in particular with respect to ease of use, but also some critical privacy issues especially for mobile users. Also, the nascent network is tiny (about 200 peers) and thus unlikely to provide good anonymity or extensive amounts of interesting information. As a result, the 0.11.4 release is still only suitable for early adopters with some reasonable pain tolerance.

Download links

• http://ftpmirror.gnu.org/gnunet/gnunet-0.11.4.tar.gz
• http://ftpmirror.gnu.org/gnunet/gnunet-0.11.4.tar.gz.sig
• http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.11.0.tar.gz
• http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.11.0.tar.gz.sig
• http://ftpmirror.gnu.org/gnunet/gnunet-fuse-0.11.0.tar.gz
• http://ftpmirror.gnu.org/gnunet/gnunet-fuse-0.11.0.tar.gz.sig

(gnunet-gtk and gnunet-fuse were not released again, as there were no changes and the 0.11.0 versions are expected to continue to work fine with gnunet-0.11.4.)

Note that due to mirror synchronization, not all links might be functional early after the release. For direct access try http://ftp.gnu.org/gnu/gnunet/

Note that GNUnet is now started using gnunet-arm -s. GNUnet should be stopped using gnunet-arm -e.

Noteworthy changes in 0.11.4

• gnunet-arm -s no longer logs into the console by default and instead into a logfile (in $GNUNET_HOME).
• The reclaim subsystem is no longer experimental. Further, the internal encryption scheme moved from ABE to GNS-style encryption.
• GNUnet now depends on a more recent version of libmicrohttpd.
• The REST API now includes read-only access to the configuration.
• All manpages are now in mdoc format.
• gnunet-download-manager.scm removed.

Known Issues

• There are known major design issues in the TRANSPORT, ATS and CORE subsystems which will need to be addressed in the future to achieve acceptable usability, performance and security.
• There are known moderate implementation limitations in CADET that negatively impact performance. Also CADET may unexpectedly deliver messages out-of-order.
• There are known moderate design issues in FS that also impact usability and performance.
• There are minor implementation limitations in SET that create unnecessary attack surface for availability.
• The RPS subsystem remains experimental.
• Some high-level tests in the test-suite fail non-deterministically due to the low-level TRANSPORT issues.

In addition to this list, you may also want to consult our bug tracker at bugs.gnunet.org which lists about 190 more specific issues.

Thanks

This release was the work of many people. The following people contributed code and were thus easily identified: ng0, Christian Grothoff, Hartmut Goebel, Martin Schanzenbach, Devan Carpenter, Naomi Phillips and Julius Bünger.

11 May 2019 Unifont 12.1.01 is now available. Significant changes in this version include the Reiwa Japanese era glyph (U+32FF), which was the only addition made in the Unicode 12.1.0 release of 7 May 2019; Rebecca Bettencourt has contributed many Under ConScript Uniocde Registry (UCSUR) scripts; and David Corbett and Johnnie Weaver modified glyphs in two Plane 1 scripts. Full details are in the ChangeLog file.

Download this release at:

https://ftpmirror.gnu.org/unifont/unifont-12.1.01/

or if that fails,

https://ftp.gnu.org/gnu/unifont/unifont-12.1.01/

or, as a last resort,

ftp://ftp.gnu.org/gnu/unifont/unifont-12.1.01/

https://arstechnica.com/gadgets/2019/05/nest-the-company-died-at-google-io-2019/

On May 2, the GNU Guix project announced the release of version 1.0 of the Guix software manager. Since the project’s beginnings a little more than seven years ago, nearly 300 volunteers from all over the world have contributed more than 50,000 improvements. Guix now provides a huge collection of bit-reproducible free software packages consisting of close to 10,000 applications and libraries from a wide range of categories, including gaming, music production, video editing, programming, and specialized scientific software.

What distinguishes Guix from other free software distributions is that it is designed with reproducibility in mind. It builds packages in controlled environments to ensure that the results are bit for bit the same no matter when or where packages are built. This means that users can easily deploy the very same software environment or even the very same operating system, at different points in time or on different machines. Reproducibility provides strong assurances that are of fundamental value for security, for the use of software in computational science, and for user freedom.

While Guix offers package management features such as transactional upgrades, safe roll-backs, and per-user profiles, package management is just one special case of its general facilities for reproducible, declarative software environment management. Guix bends the notion of a traditional package manager by extending these features to building systems: lightweight containers, Docker images, virtual machine images or bare-metal operating systems -- Guix specifies a flexible, programmable configuration framework for reproducible software deployment at every level. With Guix’s simple, well-documented extension to the general purpose language Scheme, users and developers alike can easily declare custom packages and package variants, compose and inspect arbitrarily complex software environments, and generate full operating systems with minimal effort -- Guix is designed to be hackable!

Whether you’re a software developer, a user, or a free software enthusiast, we hope GNU Guix will provide you with the tools to deploy and manage software with confidence and ease, qualities that are not usually associated with software deployment. The Guix community would love to hear from you!

The FSF supports the work of GNU Guix through its Working Together for Free Software fund. Make a contribution here!

Download from https://ftp.gnu.org/pub/gnu/gettext/gettext-0.20.tar.gz

New in this release:

• Support for reproducible builds:

- msgfmt now eliminates the POT-Creation-Date header field from .mo files.

• Improvements for translators:

- update-po target in Makefile.in.in now uses msgmerge --previous.

• Improvements for maintainers:

- msgmerge now has an option --for-msgfmt, that produces a PO file meant for use by msgfmt only. This option saves processing time, in particular by omitting fuzzy matching that is not useful in this situation.
- The .pot file in a 'po' directory is now erased by "make maintainer-clean".
- It is now possible to override xgettext options from the po/Makefile.in.in through options in XGETTEXT_OPTIONS (declared in po/Makevars).
- The --intl option of the gettextize program (deprecated since 2010) is no longer available. Instead of including the intl sources in your package, we suggest making the libintl library an optional prerequisite of your package. This will simplify the build system of your package.
- Accordingly, the Autoconf macro AM_GNU_GETTEXT_INTL_SUBDIR is gone as well.

• Programming languages support:

- C, C++:
xgettext now supports strings in u8"..." syntax, as specified in C11 and C++11.
- C, C++:
xgettext now supports 'p'/'P' exponent markers in number tokens, as specified in C99 and C++17.
- C++:
xgettext now supports underscores in number tokens.
- C++:
xgettext now supports single-quotes in number tokens, as specified in C++14.
- Shell:
o The programs 'gettext', 'ngettext' now support a --context argument.
o gettext.sh contains new function eval_pgettext and eval_npgettext for producing translations of messages with context.
- Java:
o xgettext now supports UTF-8 encoded .properties files (a new feature of Java 9).
o The build system and tools now support Java 9, 10, and 11. On the other hand, support for old versions of Java (Java 5 and older, GCJ 4.2.x and older) has been dropped.
- Perl:
o Native support for context functions (pgettext, dpgettext, dcpgettext, npgettext, dnpgettext, dcnpgettext).
o better detection of question mark and slash as operators (as opposed to regular expression delimiters).
- Scheme:
xgettext now parses the syntax for specialized byte vectors (#u8(...), #vu8(...), etc.) correctly.
- Pascal:
xgettext can now extract strings from .rsj files, produced by the Free Pascal compiler version 3.0.0 or newer.
- Vala:
xgettext now parses escape sequences in strings more accurately.
- JavaScript:
xgettext now parses template literals correctly.

• Runtime behaviour:

- The interpretation of the language preferences on macOS has been fixed.
- Per-thread locales are now also supported on Solaris 11.4.
- The replacements for the printf()/fprintf()/... functions that are provided through <libintl.h> on native Windows and NetBSD are now POSIX compliant. There is no conflict any more between these replacements and other possible replacements provided by gnulib or mingw.

• Libtextstyle:

- This package installs a new library 'libtextstyle', together with a new header file <textstyle.h>. It is a library for styling text output sent to a console or terminal emulator. Packagers: please see the suggested packaging hints in the file PACKAGING.

I'm pleased to announce the release of GNU CSSC, version 1.4.1. This is a stable release. The previous stable release was 1.4.0. Stable releases of CSSC are available from https://ftp.gnu.org/gnu/cssc/. Development releases and release candidates are available from https://alpha.gnu.org/gnu/cssc/. CSSC ("Compatibly Stupid Source Control") is the GNU project's replacement for the traditional Unix SCCS suite. It aims for full compatibility, including precise nuances of behaviour, support for all command-line options, and in most cases bug-for-bug compatibility. CSSC comes with an extensive automated test suite. If you are currently using SCCS to do version control of software, you should be able to just drop in CSSC, even for example if you have a large number of shell scripts which are layered on top of SCCS and depend on it. This should allow you to develop on and for the GNU/Linux platform if your source code exists only in an SCCS repository. CSSC also allows you to migrate to a more modern version control system (such as git). There is a mailing list for users of the CSSC suite. To join it, please send email to <cssc-users-request@gnu.org> or visit the URL http://lists.gnu.org/mailman/listinfo/cssc-users. There is also a mailing list for (usually automated) mails about bugs and changes to CSSC. This is http://lists.gnu.org/mailman/listinfo/bug-cssc. For more information about CSSC, please see http://www.gnu.org/software/cssc/. These people have contributed to the development of CSSC :- James Youngman, Ross Ridge, Eric Allman, Lars Hecking, Larry McVoy, Dave Bodenstab, Malcolm Boff, Richard Polton, Fila Kolodny, Peter Kjellerstedt, John Interrante, Marko Rauhamaa, Achim Hoffann, Dick Streefland, Greg A. Woods, Aron Griffis, Michael Sterrett, William W. Austin, Hyman Rosen, Mark Reynolds, Sergey Ostashenko, Frank van Maarseveen, Jeff Sheinberg, Thomas Duffy, Yann Dirson, Martin Wilck Many thanks to all the above people. Changes since the previous release stable are: New in CSSC-1.4.1, 2019-05-07 * This release - and future releases - of CSSC must be compiled with a C++ compiler that supports the 2011 C++ standard. * When the history file is updated (with admin or delta for example) the history file is not made executable simply because the 'x' flag is set. Instead, preserve the executable-ness from the history file we are replacing. * This release is based on updated versions of gnulib and of the googletest unit test framework. Checksums for the release file are: $ for sum in sha1sum md5sum ; do $sum CSSC-1.4.1.tar.gz; done bfb99cbd6255c7035e99455de7241d4753746fe1 CSSC-1.4.1.tar.gz c9aaae7602e39b7a5d438b0cc48fcaa3 CSSC-1.4.1.tar.gz Please report any bugs via this software to the CSSC bug reporting page, http://savannah.gnu.org/bugs/?group=cssc

We are excited to announce the release of GNU Guix version 1.0.0!

The release comes with ISO-9660 installation images, a virtual machine image, and with tarballs to install the package manager on top of your GNU/Linux distro, either from source or from binaries. Guix users can update by running guix pull.

One-point-oh always means a lot for free software releases. For Guix, 1.0 is the result of seven years of development, with code, packaging, and documentation contributions made by 260 people, translation work carried out by a dozen of people, and artwork and web site development by a couple of individuals, to name some of the activities that have been happening. During those years we published no less than 19 “0.x” releases.

The journey to 1.0

We took our time to get there, which is quite unusual in an era where free software moves so fast. Why did we take this much time? First, it takes time to build a community around a GNU/Linux distribution, and a distribution wouldn’t really exist without it. Second, we feel like we’re contributing an important piece to the GNU operating system, and that is surely intimidating and humbling.

Last, we’ve been building something new. Of course we stand on the shoulders of giants, and in particular Nix, which brought the functional software deployment paradigm that Guix implements. But developing Guix has been—and still is!—a challenge in many ways: it’s a programming language design challenge, an operating system design challenge, a challenge for security, reproducibility, bootstrapping, usability, and more. In other words, it’s been a long but insightful journey! :-)

What GNU Guix can do for you

Presumably some of the readers are discovering Guix today, so let’s recap what Guix can do for you as a user. Guix is a complete toolbox for software deployment in general, which makes it different from most of the tools you may be familiar with.

This may sound a little abstract so let’s look at concrete use cases:

• As a user, Guix allows you to install applications and to keep them up-to-date: search for software with guix search, install it with guix install, and maintain it up-to-date by regularly running guix pull and guix upgrade. Guix follows a so-called “rolling release” model, so you can run guix pull at any time to get the latest and greatest bits of free software.

  This certainly sounds familiar, but a distinguishing property here is dependability: Guix is transactional, meaning that you can at any time roll back to a previous “generation” of your package set with guix package --roll-back, inspect differences with guix package -l, and so on.

  Another useful property is reproducibility: Guix allows you to deploy the exact same software environment on different machines or at different points in time thanks to guix describe and guix pull.

  This, coupled with the fact that package management operations do not require root access, is invaluable notably in the context of high-performance computing (HPC) and reproducible science, which the Guix-HPC effort has been focusing on.

• As a developer, we hope you’ll enjoy guix environment, which allows you to spawn one-off software environments. Suppose you’re a GIMP developer: running guix environment gimp spawns a shell with everything you need to hack on GIMP—much quicker than manually installing its many dependencies.

  Developers often struggle to push their work to users so they get quick feedback. The guix pack provides an easy way to create container images for use by Docker & co., or even standalone relocatable tarballs that anyone can run, regardless of the GNU/Linux distribution they use.

  Oh, and you may also like package transformation options, which allow you define package variants from the command line.

• As a system administrator—and actually, we’re all system administrators of sorts on our laptops!—, Guix’s declarative and unified approach to configuration management should be handy. It surely is a departure from what most people are used to, but it is so reassuring: one configuration file is enough to specify all the aspects of the system config—services, file systems, locale, accounts—all in the same language.

  That makes it surprisingly easy to deploy otherwise complex services such as applications that depend on Web services. For instance, setting up CGit or Zabbix is a one-liner, even though behind the scenes that involves setting up nginx, fcgiwrap, etc. We’d love to see to what extent this helps people self-host services—sort of similar to what FreedomBox and YunoHost have been focusing on.

  With guix system you can instantiate a configuration on your machine, or in a virtual machine (VM) where you can test it, or in a container. You can also provision ISO images, VM images, or container images with a complete OS, from the same config, all with guix system.

The quick reference card shows the important commands. As you start diving deeper into Guix, you’ll discover that many aspects of the system are exposed using consistent Guile programming interfaces: package definitions, system services, the “init” system, and a whole bunch of system-level libraries. We believe that makes the system very hackable, and we hope you’ll find it as much fun to play with as we do.

So much for the overview!

What’s new since 0.16.0

For those who’ve been following along, a great many things have changed over the last 5 months since the 0.16.0 release—99 people contributed over 5,700 commits during that time! Here are the highlights:

• The ISO installation image now runs a cute text-mode graphical installer—big thanks to Mathieu Othacehe for writing it and to everyone who tested it and improved it! It is similar in spirit to the Debian installer. Whether you’re a die-hard GNU/Linux hacker or a novice user, you’ll certainly find that this makes system installation much less tedious than it was! The installer is fully translated to French, German, and Spanish.
• The new VM image better matches user expectations: whether you want to tinker with Guix System and see what it’s like, or whether you want to use it as a development environment, this VM image should be more directly useful.
• The user interface was improved: aliases for common operations such as guix search and guix install are now available, diagnostics are now colorized, more operations show a progress bar, there’s a new --verbosity option recognized by all commands, and most commands are now “quiet” by default.
• There’s a new --with-git-url package transformation option, that goes with --with-branch and --with-commit.
• Guix now has a first-class, uniform mechanism to configure keyboard layout—a long overdue addition. Related to that, Xorg configuration has been streamlined with the new xorg-configuration record.
• We introduced guix pack -R a while back: it creates tarballs containing relocatable application bundles that rely on user namespaces. Starting from 1.0, guix pack -RR (like “reliably relocatable”?) generates relocatable binaries that fall back to PRoot on systems where user namespaces are not supported.
• More than 1,100 packages were added, leading to close to 10,000 packages, 2,104 packages were updated, and several system services were contributed.
• The manual has been fully translated to French, the German and Spanish translations are nearing completion, and work has begun on a Simplified Chinese translation. You can help translate the manual into your language by joining the Translation Project.

That’s a long list already, but you can find more details in the NEWS file.

What’s next?

One-point-oh is a major milestone, especially for those of us who’ve been on board for several years. But with the wealth of ideas we’ve been collecting, it’s definitely not the end of the road!

If you’re interested in “devops” and distributed deployment, you will certainly be happy to help in that area, those interested in OS development might want to make the Shepherd more flexible and snappy, furthering integration with Software Heritage will probably be #1 on the to-do list of scientists concerned with long-term reproducibility, programming language tinkerers may want to push G-expressions further, etc. Guix 1.0 is a tool that’s both serviceable for one’s day-to-day computer usage and a great playground for the tinkerers among us.

Whether you want to help on design, coding, maintenance, system administration, translation, testing, artwork, web services, funding, organizing a Guix install party… your contributions are welcome!

We’re humans—don’t hesitate to get in touch with us, and enjoy Guix 1.0!

About GNU Guix

GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the kernel Linux, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines.

In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language.

• dico-2.9
• emacs-26.2
• gama-2.04
• gawk-5.0.0
• gnuastro-0.9
• gnuhealth-client-3.4.4
• gnunet-0.11.3
• gnupg-2.2.15
• gnutls-3.6.7
• libcdio-2.1.0
• nano-4.2
• parallel-20190422
• rush-1.9
• shepherd-0.6.0
• wget-1.20.3

For announcements of most new GNU releases, subscribe to the info-gnu mailing list: https://lists.gnu.org/mailman/listinfo/info-gnu.

To download: nearly all GNU software is available from https://ftp.gnu.org/gnu/, or preferably one of its mirrors from https://www.gnu.org/prep/ftp.html. You can use the URL https://ftpmirror.gnu.org/ to be automatically redirected to a (hopefully) nearby and up-to-date mirror.

This month, we welcome Tom Tromey as comaintainer of src-hilight and Abhilash Raj as comaintainer of mailman.

A number of GNU packages, as well as the GNU operating system as a whole, are looking for maintainers and other assistance: please see https://www.gnu.org/server/takeaction.html#unmaint if you'd like to help. The general page on how to help GNU is at https://www.gnu.org/help/help.html.

If you have a working or partly working program that you'd like to offer to the GNU project as a GNU package, see https://www.gnu.org/help/evaluation.html.

As always, please feel free to write to us at maintainers@gnu.org with any GNUish questions or suggestions for future installments.

This speech by Richard Stallman will be nontechnical, admission is gratis, and the public is encouraged to attend.

Speech topic to be determined.

Location: exact location to be determined, Berner Fach Hochschule (BFH), Biel/Bienne, Schweiz

Please fill out our contact form, so that we can contact you about future events in and around Biel/Bienne.

Version 2.9 of GNU dico is available from download from the GNU archive and from its main archive site.

This version fixes compilation on 32-bit systems.

Version 1.9 is available for download from GNU and Puszcza archives. It should soon become available in the mirrors too.

New in this version:

Backreference expansion

Arguments to tranformations, chroot and chdir statements can contain references to parenthesized groups in the recent regular expression match. Such references are replaced with the strings that matched the corresponding groups. Syntactically, a backreference expansion is a percent sign followed by one-digit number of the subexpression (1-based, %0 refers to entire matched line). For example

rule X command ^cd (.+) && (.+) chdir %1 set %2 User-defined variables

The configuration file can define new variables or redefine the built-in ones using the setvar statement:

Here, VAR is the variable name, and PATTERN is its new value. The PATTERN is subject to variable and backreference expansion.

User-defined variables can be unset using the "unsetvar" statement:

Unsetting a built-in variable, previously redefined using the setvar statement causes the user-supplied definition to be forgotten and the built-in one restored.

Shell-like variable expansion

The following shell-like notations are supported:

${VAR:-WORD} Use Default Values ${VAR:=WORD} Assign Default Values ${VAR:?WORD} Display Error if Null or Unset ${VAR:+WORD} Use Alternate Value New script rush-po for extracting translatable strings from the configuration

The script rush-po.awk that was used in prior versions has been withdrawn.

U.S. energy regulators are pursuing a risky plan to share with electric utilities a secret "don't buy" list of foreign technology suppliers, according to multiple sources.

https://www.eenews.net/stories/1060176111

The Free Software Directory is an essential catalog of free software online. The Directory is maintained by countless volunteers dedicated to the promotion of software that respects your personal liberty. As with any group composed of volunteers, the informal Directory team has people who come and go, and right now, it could really use some fresh new members to kick our efforts into high gear.

Tens of thousands of people visit the Directory every month to discover free software and explore information about version control, documentation, and licensing. All of this information is also exported in machine-readable formats, making it a valuable source of data for the study of trends in free software. The Directory is powered by MediaWiki, the same software used by Wikipedia.

A few statistics on what our team and our amazing volunteers have achieved in the last few months and years:

• The Directory passed 16,000 entries last summer, and is now up to 16,176 total entries.

• The Official Backlog of the Directory has been improved to better track active and archived bugs.

• The migration to using the SPDX license identifiers for the Directory is currently underway.

• In 2018, the Directory received 962,847 unique visitors, with 1,671,047 total visits and 15,129,307 page views. So far in 2019, the directory averaged 79,859 unique visitors a month.

• The Directory currently has 3,093 registered users.

There are also several larger projects that are in need of new leaders. We organize these projects via our Project Teams. If one of those projects sounds interesting, or if you have another idea about improving the Directory, we would love for you to join us.

Adding and maintaining entries to the Directory is crucial work to give people access to free software which has only free dependencies and runs on a free OS. Every Friday at 12:00-15:00 EDT (16:00 to 19:00 UTC), volunteers meet on IRC in the #fsf channel on irc.freenode.org to add new entries, update existing ones, and talk about free software together (to see the meeting start time in your time zone, run this in GNU bash: date --date='TZ="America/New_York" 12:00 this Fri').

If you can't wait or don't have the time to jump onto IRC on Friday afternoons, you can still help: check out the Free Software Directory Participation Guide for instructions.

No matter how you participate, improving the Free Software Directory is an easy, nuts-and-bolts way to make a contribution to the free software movement, bringing us a tinier step every day to a truly free society. We look forward to seeing you on IRC!