fidzu : fedora

The post On Free Software, Red Hat, and Iran appeared first on Justin W. Flory's blog.

Justin W. Flory's blog - Free & Open Source, travel, and life reflections

I was visiting the Fedora Council ticket tracker when I noticed this ticket up for discussion. The ticket's purpose is minor and appears inconsequential. It involves adding some legal text to the Fedora Accounts system. The change is related to Export Administration Regulations (the "EAR") as maintained by the United States Department of Commerce. And the change is not actually a change, but a clarification of a policy that has always been in effect.

I am opposed to the impact of Export Administration Regulations by the United States as it pertains to free and open source software. I am a strong believer that the impact of these regulations are most harmful to all free & open source software communities at an individual, human level. When I saw this discussion at the Fedora Council level, it offered me an opportunity to reflect on my own feelings about these regulations, and also to share an opinion on how I believe Fedora Linux could truly live up to its certification as a Digital Public Good to ensure a more equitable world.

Here is what I wrote to the Fedora Council, and perhaps also to anyone reading from Red Hat's legal team:

---

Hi, I would like to add a counter-opinion, of course one that holds no weight as an official vote.

As Fedora Linux is forced to this decision by its relationship to its legal sponsor, Red Hat, I therefore believe it is also the responsibility of Red Hat to seek a solution that does not deny an individual their right to realize the Four Freedoms of Free Software on the basis of geography or citizenship.

I recognize no policy is being changed here. It is a deliberate clarification of rules that were always in effect. Yet this ticket opens the context behind the policy for greater scrutiny, and I posit the context is harmful both to the Fedora Project and to Red Hat.

This policy is harmful for diversity and inclusion, and compromises Fedora's position to be an innovative platform built by a global community. The U.S. laws and regulations driving this decision exist within a specific context, but that context is grossly incompatible with the dynamics of inclusive Free & Open Source communities. In practice, these laws and regulations deny individuals (really, other human beings) of their ability to be a beneficiary of the open licenses we employ for creating our work, collaborating on it together, and sharing it with others.

I see two outcomes of accepting this as an unchangeable norm.

Firstly, it creates confusion, doubt, and feelings of ill intent. These laws and regulations are meant to impact governments and nation-states. In a Free & Open Source community such as ours, these regulations impact individual people. Not governments or nation-states. As an example, a Fedora community member, Ahmad Haghighi, was recently permanently removed from the Fedora Community. In a few quick clicks, Ahmad's legacy in the project was erased. As a precedent, even if someone's contributions were not "supposed" to be accepted in the first place, it does not sit well with me that any one person's legacy of contributions can so easily be removed from project records.

Secondly, it challenges the vision and foundations of the Fedora Project. Particularly our vision statement and the Friends Foundation. When I contribute to the Fedora Project, I do not see people as a citizen of this-country or that-country. I see them as my peers and fellow Fedorans, helping meet that shared vision of creating "a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities." As an American citizen, I know my country makes such discriminations about large groups of people based only on their nationality, but as a contributor to Free & Open Source communities, I see people by their individual character and intention to be a part of our shared vision. But how can we truly aspire to this vision if we are consciously making deliberate exclusions, even if they make little to no sense in our own context? This geographic restriction policy sits in contrast to the vision and purpose we spell out "on paper".

I understand why Fedora leadership is taking this action due to Fedora's legal and sociopolitical relationship to Red Hat, an American incorporation subject to American laws and regulations. To an extent, the hand of Fedora is forced.

But I believe this is a great opportunity for Red Hat to be an enabler of Fedora's First Foundation. Previously, Microsoft stood up for Iranian developers and successfully set a precedent about how the United States Office of Foreign Assets Control (OFAC) treats such cases. I found this excerpt from Nat Friedman's announcement to resonate:

Over the course of two years, we were able to demonstrate how developer use of GitHub advances human progress, international communication, and the enduring US foreign policy of promoting free speech and the free flow of information. We are grateful to OFAC for the engagement which has led to this great result for developers.

Advancing developer freedom: GitHub is fully available in Iran - github.blog

I believe Red Hat's legal team should take a stand for individuals in embargoed countries to remain a beneficiary of the free and open source licenses that enable a community Linux distribution like Fedora to exist in the first place.

After all, in Fedora, we are well-known for being first in the Open Source space for innovative new ideas and approaches. We know Fedora Linux is a digital public good that should be accessible to all and everyone. But to make this a reality, the Fedora Project cannot be first here on its own. We need our friendly primary sponsor, Red Hat, to help us clear this burden, which is brought on by our connection to Red Hat in the first place.

I'll close this counter-opinion with an excerpt from our First Foundation:

"However, the Fedora Project's goal of advancing free software dictates that the Fedora Project itself pursue a strategy that preserves the forward momentum of our technical, collateral, and community-building progress. Fedora always aims to provide the future, first."

From What is Fedora all about?

Here is a chance to be clear on the future we want to provide and for whom.

---

Background photo by Omid Armin on Unsplash.

26 Oct 2021 9:47pm GMT

In my quest to automate the testing of the Linux Kernel, I need to automate the build of the Linux Kernel. To build the Kernel, you need the requisite packages. What are they? Let's find out.

I am staring with a Baremetal Fedora Image. It has 344 packages installed already. I'm going to assume that this set is available when I do my automated build as well, or that the needed packages will get pulled in by dependencies. If not, I will find out when my automation fails to run and I will add them at that point.

Most Fedora and CentOS based documents on building the Kernel have you do a group install of the "Development Tools" yum package group. I don't want to do this for two reasons. First, I want to use the beaker format which just lists the packages in the job description. Second, I want to minimize the non-required packages, and Development Tools is general purpose group for coding; not everyone needs everythingm, and I don't want to put non-essential packages on the system.

In order to build the linux Kernel, I need to get the code on the server. While I could push it from a remote system, if I want to run this from a beaker job, I will have no machine that can push it. Thus, I will start by installing git.

sudo yum install git

That installs 66 Packages and takes Installed size: 58 MB of space.

Next I clone the Linux kernel tree. I am using https://gitlab.com/linux-kernel/linux, but you can do the same thing from the kernel.org Repo or one of the other public git mirrors. This is quite large and takes a while.

Receiving objects: 100% (8358688/8358688), 1.51 GiB | 20.57 MiB/s, done.

I'm going to use an existing config file to make the old configuration into my new one.

$ make olddefconfig -bash: make: command not found

OK, first missing package. make pulls in libtool-ltdl and guile22

$ make olddefconfig HOSTCC scripts/basic/fixdep /bin/sh: line 1: gcc: command not found make[1]: *** [scripts/Makefile.host:95: scripts/basic/fixdep] Error 127 make: *** [Makefile:552: scripts_basic] Error 2

gcc. No Suprise there. That pulls in 17 packages.

$ make olddefconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/confdata.o HOSTCC scripts/kconfig/expr.o LEX scripts/kconfig/lexer.lex.c /bin/sh: line 1: flex: command not found make[1]: *** [scripts/Makefile.host:9: scripts/kconfig/lexer.lex.c] Error 127 make: *** [Makefile:616: olddefconfig] Error 2

flex also pulls in m4

$ make olddefconfig LEX scripts/kconfig/lexer.lex.c YACC scripts/kconfig/parser.tab.[ch] /bin/sh: line 1: bison: command not found make[1]: *** [scripts/Makefile.host:17: scripts/kconfig/parser.tab.h] Error 127 make: *** [Makefile:616: olddefconfig] Error 2

bison

That gets through the config build process. Lets checkout the main compile. To speed things up, I compile with 1 thread per CPU:

make -j 32 scripts/sign-file.c:25:10: fatal error: openssl/opensslv.h: No such file or directory 25 | #include <openssl>opensslv.h> | ^~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts</openssl>Makefile.host:95: scripts/sign-file] Error 1 make: *** [Makefile:1203: scripts] Error 2

I'm sure there were flamewars about including cryptography in the Linux Kernel. openssl-devel

/bin/sh: line 1: bc: command not found make[1]: *** [Kbuild:24: include/generated/timeconst.h] Error 127 make[1]: *** Waiting for unfinished jobs…. make: *** [Makefile:1219: prepare0] Error 2

bc

main.c:55:10: fatal error: libelf.h: No such file or directory
   55 | #include <libelf.h>
      |          ^~~~~~~~~~

elfutils-libelf-devel. And with that, the make process completes successfully. Lets' now make the modules.

That works, too.

So the minimal list for compile is

• elfutils-libelf-devel
• openssl-devel
• bison
• flex
• gcc
• make

26 Oct 2021 9:19pm GMT

Here's a one liner for showing the status of all your beaker jobs.

for JOB in $( bkr job-list -o $( bkr whoami | jq -r '.username' )  | jq -r ".[]"   ) ; do bkr job-results $JOB | xpath -q -e "string(/job/recipeSet/recipe/@status)" ; done

26 Oct 2021 4:39pm GMT