15 Dec 2019

feedPlanet Debian

Giovanni Mascellani: Debian init systems GR

This is my vote:

-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
7b77e0f2-4ff9-4adb-85e4-af249191f27a
[ 1 ] Choice 5: H: Support portability, without blocking progress
[ 2 ] Choice 4: D: Support non-systemd systems, without blocking progress
[ 3 ] Choice 7: G: Support portability and multiple implementations
[ 4 ] Choice 3: A: Support for multiple init systems is Important
[ 5 ] Choice 2: B: Systemd but we support exploring alternatives
[ 6 ] Choice 1: F: Focus on systemd
[ 7 ] Choice 8: Further Discussion
[ 8 ] Choice 6: E: Support for multiple init systems is Required
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=---

I don't think that nowadays the choice of the init system can neutral: like the choice of a kernel, a libc and some other core components, you cannot just pretend that everything can be transparently swapped with anything else, therefore Debian rightly has to choose a default thing (Linux, glibc, the GNU userland, and now systemd) which is the standard proposal to the casual user. Systemd has clearly become the mainstream thing for a lot of good reasons, and it is the choice the most Debian users and developers should adopt (this is not to say that systemd, its development mode or its goals are perfect; but we have to choose between alternatives that exist, not between ideal ones). This is the reason why imposing that any init system should be supported at the same level is silly to me, and therefore why option E is the last one, and the only one below Further Discussion; in much the same way as it would be silly to impose that kFreeBSD, Mach and musl should be supported at the same level of their default counterparts (although I would be pretty excited to see that happening!). We cannot expect any Debian contributor to have the resources to contribute scripts/units for any init system randomly appearing.

At the same time, I like Debian to be Universal in the sense of potentially being home for any reasonable piece of software. Diversity, user choice and portability are still values, although not absolute ones, and nobody in Debian should make it impossible to pursue them. I also share the "glue" vision proposed by the principles of choices G and H. Therefore work extending support for non-default init systems (and, again, kernels, libc's, architectures, any core component) should be loyally accepted by all involved contributors, even if they do not see the need for such components.

For these reasons I consider option H the one that, despite being possibly a bit too verbose, spells out my thoughts. All the other options are essentially ordered in how close I percieve them to option H.

I'd like to thanks Ian Jackson for having proposed option H and for having collected a few important criteria to find a way in the jungle of all the available options.

15 Dec 2019 2:30pm GMT

13 Dec 2019

feedPlanet Debian

Jonathan McDowell: This Week I Voted

I voted this week. Twice, as it happens (vote early, vote often). This post is about my vote for Debian's General Resolution: Init systems and systemd. You probably want to skip it, but I thought I'd write it up anyway.

[ 1 ] Choice 5: H: Support portability, without blocking progress
[ 2 ] Choice 4: D: Support non-systemd systems, without blocking progress
[ 3 ] Choice 7: G: Support portability and multiple implementations
[ 4 ] Choice 3: A: Support for multiple init systems is Important
[ 5 ] Choice 2: B: Systemd but we support exploring alternatives
[ 6 ] Choice 1: F: Focus on systemd
[ 7 ] Choice 6: E: Support for multiple init systems is Required
[ 8 ] Choice 8: Further Discussion

Firstly, I've re-ordered the ballot in the order I ranked things in. I find the mix of numbers and letters that don't match up confusing, and I think the ordering on the ballot indicates the bias of whoever did the ordering. I don't think that's intended to be anything other than helpful, but I'd have kept the numbers and letters matching in the expected order.

I made use of Ian Jackson's voting guide (and should disclose that he and I have had conversations about this matter where he kindly took time to explain to me his position and rationale). However I'm more pro-systemd than he is, and also lazier, so hopefully this post is useful in some fashion rather than a simple rehash of anyone else's logic.

I ranked Further Discussion last. I want this to go away. I feel it's still sucking too much of the project's time.

E was easy to rank as second last. While I want to support people who want to run non-systemd setups I don't want to force us as a project to have to shoehorn that support in where it's not easily done.

I put F third last. While I welcome the improvements brought by systemd I'm wary of buying into any ecosystem completely, and it has a lot of tentacles which will make any future move much more difficult if we buy in wholesale (and make life unnecessarily difficult for people who want to avoid systemd, and I've no desire to do that).

On the flip side I think those who want to avoid systemd should be able to do so within Debian. I don't buy the argument that you can just fork and drop systemd there, it's an invasive change that makes it much, much harder to produce a derivative system. So it's one of those things we should care about as a project. (If you hate systemd so much you don't want even its libraries on your system I can't help you.)

I debated over my ordering for H and D. I am in favour of portability principles, and I'm happy to make a statement that if someone is prepared to do the work of sorting out non-systemd support for a package then as a project we should take that. I read that as it's not my responsibility as a maintainer to do these things (though obviously if I can easily do so I will), but that I shouldn't get in the way of someone else doing so. As someone who has built things on top of Debian I subscribe to the idea that it should be suitable glue for such things (as well as something I can run directly on my own machines), so I favoured H.

That leaves A and G. I deferred to Ian here; I'd rather systemd wasn't the de facto result despite best intentions, which results in placing G first of the two.

For balance you might want to read the posts by Bernd Zeimetz, Jonathan Dowland, Gunnar Wolf, Lucas Nussbaum, Philipp Kern, Sam Hartman and Wouter Verhelst.

13 Dec 2019 7:04pm GMT

Molly de Blanc: Autonomy

I've been stuck on the question: Why is autonomy an ethical imperative? or, worded another way Why does autonomy matter? I think if we're going to argue that free software matters (or if I am anyway), there needs to be a point where we have to be able to answer why autonomy matters.

I've been thinking about this in the framing of technology and consent since the summer of 2018, when Karen Sandler and I spoke at HOPE and DebConf 18 on user and software freedom. Sitting with Karen before HOPE, I had a bit of a crisis of faith and lost track of why software freedom matters after I moved to the point that consent is necessary to our continued autonomy. But why does autonomy matter?

Autonomy matters because autonomy matters. It is the postulate on which not only have I built my arguments, but my entire world view. It is an idea that is instilled in us very deeply that all arguments about what should be a legal right are framed. We have the idea of autonomy so fundamental as part of our society, that we have been trained to have negative, sometimes physical, reactions to the loss of autonomy. Pro-choice and anti-choice arguments both boil down to the question of respecting autonomy - but whose autonomy? Arguments against euthanasia come down to autonomy - questions of whether someone really have the agency to decide to die versus concerns about autonomy being ignored and death being forced on a person. Even climate change is a question of autonomy - how can we be autonomous if we can't even be?

Person autonomy means we can consent, user freedom is a tool for consent, software freedom is a tool for user freedom, free software is a tool for software freedom. We can also think about this in reverse:

Free software is the reality of software freedom. Software freedom protects user freedom. User freedom enables consent. Consent is necessary to autonomy. Autonomy is essential. Autonomy is essential because autonomy is essential. And that's enough.

13 Dec 2019 9:52am GMT

Olivier Berger: Antidote and NRELabs presentation at Paris Open Source Summit 2019

I've just presented Antidote and the NRELabs platform at Paris Open Source Summit 2019. Here are the slides of the presentation : Antidote: virtualized learning labs running over kubernetes

I made a demo and the speech in front of the few people left, unfortunately, as the conference attendance suffered from the ongoing strikes in France (opposing the pensions system reform).

In any case, I hope it triggered some interest for the platform and the project.

Many thanks to the organizers for the very nice athmosphere, despite the rather low attendance.

Also, thanks to the HubLinked project who allowed me to work on the project and participate to the summit.

13 Dec 2019 9:22am GMT

Anisa Kuci: Outreachy post 1

Couple of months ago I decided to apply for the winter 2019-2020 round of Outreachy.

Outreachy, for those who don't know, provides internships in Free and Open Source Software (FOSS) with the aim to support underrepresented groups of people. Outreachy internships are open to applicants around the world, and interns are able to work remotely.

There were quite a few very interesting projects to choose among this round, but since I have been a Debian user and contributor for a while and it is a project I really like, I decided to work towards it. I have been doing small Debian related events or gatherings in the community I was part of. The Debian project I applied for is "Create fundraising material for DebConf20+, document the fundraising processes and support a cycle".

The initial tasks were very interesting and applicable to my skill-set, so I was really enjoying working on them. Also the mentor of the project was very responsive and helpful when I would have questions or feel in doubt and quite supportive, which was motivating me to keep contributing in such a great project.

While doing research for the initial application tasks I was surprised to also learn much more about the Debian community and the Debian project itself. I learned information about how past DebConfs have been organized, tools and methods that are used to make DebConfs happen around the world, and go deeper into understanding the different structures that make the whole Debian project so functional.

I would encourage people to find the courage within themselves and apply for the projects they like on Outreachy. And if they don't get selected one round that shouldn't mean giving up but trying again next round. I find it a very welcoming environment!

I am very happy I got selected to be one of the Outreachy interns for this round and will do my best to have great results and help on supporting Debian!

13 Dec 2019 12:00am GMT

12 Dec 2019

feedPlanet Debian

Reproducible Builds: Reproducible Builds in November 2019

Welcome to the November 2019 report from the Reproducible Builds project.

As a summary of our project, whilst anyone can inspect the source code of free software for malicious flaws almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is therefore to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised.

In this month's report, we cover:

If you are interested in contributing to our project, please visit our Contribute page on our website.

Media coverage and events

We held our fifth annual Reproducible Builds summit between the 1st and 8th December in Marrakesh, Morocco. A full, in-depth report will be posted next month…

On November 16th, Vagrant Cascadian presented There and Back Again, Reproducibly at the SeaGL in Seattle, Washington.

Chris Lamb was featured on The Manifest package management podcast in an episode called Reproducible Builds project and Debian package management.

ReScience C is an open-access journal that targets computational research and encourages the explicit replication of already published research. This month they announced their Ten Years Reproducibility Challenge which promotes the idea that old code - in this instance, a "scientific article [published] before January 1st 2010" - should also run on modern hardware and software in order to check one can obtain the same scientific results in the future.

Upstream news

Mike Hommey pushed a change to Mozilla build system to add and print error messages when differences are found between builds as requested in bug #1597903.

There was fresh activity on an old pull request for the OCaml programming language regarding the usage and adoption of the BUILD_PATH_PREFIX_MAP environment variable that is used to ensure that software packages do not embed build-time paths into generated files. On the pull request in question Gabriel Scherer was kind enough to provide many helpful examples on how to use the rewrite rules.

Jan Nieuwenhuizen announced the release of GNU Mes 0.21 and Jeremiah Orians announced the release of mescc-tools-seed version 1.1:

Capable of bootstrapping from a simple hex assembler all the way to a cross-platform C compiler Work is still ongoing [to] result in a full bootstrap from a 357 byte bootstrap binary all the way to GCC.

Hervé Boutemy announced the release of three base Apache Maven plugins (source, .jar, and assembly) to get reproducible Builds as a "direct output" from this build system. For more information, please see the "Configuring for Reproducible Builds" section of their documentation.

Eli Schwartz reported a bug against the GNU groff typesetting system for incomplete SOURCE_DATE_EPOCH environment variable support; the output files appeared to be embedding the build timezone.

Distribution work

Arch Linux

A slight but temporary decline in the Arch Linux reproducibility status was determined to be due to a bug in the continuous integration framework where one build was building with --nocheck whilst the other did not, resulting in the test dependencies being installed on one build. This led to differences in the BUILDINFO file which records the build dependencies.

Morten Linderud (Foxboron) wrote a blog post on the progress of reproducible builds for Arch packages, including how to reproduce packages and a roadmap of future of work.

The standard Arch development tools package (devtools) now contains a new tool called makerepropkg which can reproduce a package from the Arch repositories given a seed PKGBUILD file.

A lot of work has been put into getting the "[core]" system more reproducible; every package has been rebuilt with a new version of pacman which resolved a previous issue with storing the package size. Build failures and download issues have also been resolved which have lead to an increase of reproducible packages in this distributions continuous integration setup.

openSUSE

Bernhard M. Wiedemann posted a summary of openSUSE updates for 2019 including rpm, a high level openSUSE status and fixing problems with .pyc files which is also relevant to Arch Linux.

The report also summarises the current reproducibility status as follows:

In addition to this, Bernhard also published his monthly Reproducible Builds status update.

Debian

Thorsten Glaser filed a bug against the debhelper packaging library to request that it sets and exports a umask of 022 for all operations as a possible "harmonisation potential". A varying umask can result in unreproducible packages as the file permissions on the build system can be embedded into archives generated by the build system.

Chris Lamb categorised a large number of packages and issues in the Reproducible Builds "notes" repository, including adding a new ocaml_dune_captures_build_path toolchain issue […].

Vagrant Cascadian filed a bug against the Lintian Debian static analyser for Debian packages to request that it checks for missing and/or unsigned .buildinfo files. He also uploaded the latest version of GNU Mes to the unstable distribution.

Other

Natanael Copa (@n_copa) posted on Twitter that he was finally able to make a fully reproducible package) for Alpine Linux.

The NixOS distribution announced that they plan to run a Christmas Hackathon hosted by Smarkets in London, England on 9th December.

Software development

Upstream patches

The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:

diffoscope

diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. It is run countless times a day on our testing infrastructure and is essential for identifying fixes and causes of non-deterministic behaviour.

diffoscope versions 131, 132 and 133 was uploaded to Debian unstable by Chris Lamb. He also made the following changes:

Other contributions were also made from:

strip-nondeterminism

strip-nondeterminism is our tool to remove specific non-deterministic results from a completed build. This month, Chris Lamb added file as a dependency for libfile-stripnondeterminism-perl (#945212) and moved away from deprecated $ADTTMP variable […] and made two uploads in total (1.6.2-1 & 1.6.3-1).

Project website

There was yet more effort put into our our website this month, including:

Test framework

We operate a comprehensive Jenkins-based testing framework that powers tests.reproducible-builds.org. This month, the following changes were made:

The usual node maintenance was performed by Holger Levsen. […][…][…][…]

Contributing

If you are interested in contributing the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:


This month's report was written by Arnout Engelen, Chris Lamb, Holger Levsen, Jelle van der Waa, Bernhard M. Wiedemann and Vagrant Cascadian. It was subsequently reviewed by a bunch of Reproducible Builds folks on IRC and the mailing list.

12 Dec 2019 4:28pm GMT

Enrico Zini: Init systems documentation

Inspired by this post about documentation1 I started a systemd/documentation page in the Debian wiki.

Systemd has an excellent reference documentation in its manpages, but it does a lot of things, and a reference documentation isn't the best starting point for getting introduced to them.

I would like to see a bit more documentation of the kind that sits between a systemctl start|stop|status and the reference manpages. Things like simple HOWTO posts on how to get a simple job done, or high-level explanations of how some specific feature works.

I put some of what I know and used (or wrote) into systemd/documentation, I'll try to add to it when I find more, and I encourage you to do the same.

If you remember an article that has been useful to you and it is missing from the page, link it.

If you found a systemd feature useful to get a task done, write a little HOWTO to the wiki or your blog, and link it.

If you don't use systemd, go ahead and start a similar index for the init system that you use, and link it, too.

I'd love it if each init system we have in Debian had an excellent documentation index in the wiki!

  1. Thanks anarcat for pointing me to it. ↩

12 Dec 2019 11:20am GMT

Enrico Zini: On crisis

There is a quote that goes around allegedly attributed to Albert Einstein:

Let's not pretend that things will change if we keep doing the same things. A crisis can be a real blessing to any person, to any nation. For all crises bring progress.

Creativity is born from anguish, just like the day is born form the dark night. It's in crisis that inventiveness is born, as well as discoveries made and big strategies. He who overcomes crisis, overcomes himself, without getting overcome. He who blames his failure to a crisis neglects his own talent and is more interested in problems than in solutions. Incompetence is the true crisis. The greatest inconvenience of people and nations is the laziness with which they attempt to find the solutions to their problems.

There's no challenge without a crisis. Without challenges, life becomes a routine, a slow agony.

There's no merit without crisis. It's in the crisis where we can show the very best in us. Without a crisis, any wind becomes a tender touch. To speak about a crisis is to promote it. Not to speak about it is to exalt conformism. Let us work hard instead. Let us stop, once and for all, the menacing crisis that represents the tragedy of not being willing to overcome it.

I like the idea of considering more valuable how a group overcomes a crisis, rather than how a group avoids it.

12 Dec 2019 9:40am GMT

Russ Allbery: Astronomy!

Starting in January of 2020, I will be joining the Data Management team (specifically the Science Quality and Reliability Engineering team) for the Large Synoptic Survey Telescope.

There's a much longer description at the above Wikipedia link and also at LSST's own site, but the short version is that the mission of LSST is to survey the entire southern night sky about twice a week for ten years. This in turn will provide vast amounts of data that will be used to do wide-ranging research in astronomy. All of that data requires indexing and processing so that scientists can use it. The team I'm joining is applying current software engineering techniques (containers, Jupyter notebooks, continuous integration, and so on) to that problem.

For me, this is an opportunity to return to the academic, non-profit world that's always been my first love. It's also an opportunity to learn a bunch of new things (astronomy, for the most obvious, and scientific research computing more generally, but also some areas of technology that I've never had enough time to explore). Even better, everything my new team does is free software and is developed on GitHub, which means I'll be returning to a job where free software is at the center of the work instead of an optional side project for which there's rarely time.

Dropbox has been a great employer and I wasn't looking to leave, but this was too good of an opportunity to pass up.

I'm going to be staying in the Bay Area and working remotely, which also means that I'm going to get about six hours a week back from the commute, and have an opportunity to wander around the area and find interesting places from which to work, something that I'm looking forward to.

When I went to Dropbox, I thought that would mean a bit more time for Debian, and was sadly completely incorrect. No promises this time, but I have some reasons to hope that I'll at least be able to get back to the levels of involvement I had at Stanford. Even if the new job, since it's scientific computing, is using CentOS....

12 Dec 2019 3:58am GMT

11 Dec 2019

feedPlanet Debian

Ian Jackson: Debian GR on init systems - Ballot paper format

This can get a bit confusing. The ballot options have letters (eg, "E"). They also have numbers, which show up on the vote page as "Choice 6" or whatever. Separately, there are the ranks you have to assign when voting, where 1 is your first preference, etc.

On the ballot paper, the choices are numbered from 1 to 8. The letters appear too along with the Secretary's summaries. Your preferences also have to be numbered. It is important not to get confused.

Reorder the ballot paper!

You are allowed to reorder the choices on your ballot paper, and this is effective.

That is, you can take the ballot paper in the CFV and edit the lines in it into your preferred order with cut and paste. You can look at the letters, or the Secretary's summary lines, when you do that.

It's important to use a proper text editor and not linewrap things while you do this.

After, that you can simply write numbers 1 to 8 into the boxes down the left hand side.

Rank all the options. That way when you get your vote ack back, any parse failure will show up as a blank space in the ack.

Worked example

If after reading my voting guide you answer "maintainers MUST support non-systemd" to Q1, and "Accepting contributions is more important" to Q2, and "I like the vision" to Q3, you fall into the top left corner of my voting table. Then you would vote like this:

> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> 7b77e0f2-4ff9-4adb-85e4-af249191f27a
> [ 1  ] Choice 6: E: Support for multiple init systems is Required
> [ 2  ] Choice 5: H: Support portability, without blocking progress
> [ 3  ] Choice 4: D: Support non-systemd systems, without blocking progress
> [ 4  ] Choice 7: G: Support portability and multiple implementations
> [ 5  ] Choice 3: A: Support for multiple init systems is Important
> [ 6  ] Choice 8: Further Discussion
> [ 7  ] Choice 2: B: Systemd but we support exploring alternatives
> [ 8  ] Choice 1: F: Focus on systemd
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

When you get your ack back from the vote system, it lists, from left to right, the preferences numbers for each vote.

In the case above, that's

Your vote has been recorded as follows
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
V: 87532146
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Understanding the devotee ack

The V: list in the ack is listed in the order of the "Choice" numbers on the ballot, not in your preference order:

       Your vote has been recorded as follows
       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
       V: 87532146
 [ 6 ]    ||||||| `-- Choice 8: Further Discussion
 [ 4 ]    |||||| `--- Choice 7: G: Support portability
 [ 1 ]    ||||| `---- Choice 6: E: Support for multipl
 [ 2 ]    |||| `----- Choice 5: H: Support portability
 [ 3 ]    ||| `------ Choice 4: D: Support non-systemd
 [ 5 ]    || `------- Choice 3: A: Support for multipl
 [ 7 ]    | `-------- Choice 2: B: Systemd but we supp
 [ 8 ]     `--------- Choice 1: F: Focus on systemd'
Edited 2019-12-11 15:35 to add the "Understanding the devotee ack" section. Thanks to my correspondent for the confusion-report and review.



comment count unavailable comments

11 Dec 2019 3:35pm GMT

Manuel A. Fernandez Montecelo: Debian GNU/Linux riscv64 port -- Sponsors and Build machines

In previous posts about the riscv64 port there were mentions about history, progress and other details, but in this one I want to address the topic of sponsors and build machines, which even if there are mentions from time to time (e.g. in talks and slides posted here), it has not been covered in a comprehensive manner.

And it's only fair that we acknowledge people and orgs sponsoring and contributing resources... and about time too. They will appear roughly in chronological order.

Bytemark

From the early days in 2015, when the plans for the port were still very preliminary, we got support from Bytemark, which already supports Debian and other FOSS projects, and important parts of the Debian infrastructure are hosted there.

In particular, they sponsored a virtual machine with a good amount of CPU, RAM and disk space (and good connectivity and great bandwidth with Debian repos :-)) in which many of the early attempts to bootstrap happened, after things started to get beyond personal laptop territory (see Debian GNU/Linux port for RISC-V 64-bit (riscv64) for more details).

This has been acknowledged here: Debian RISC-V's wiki page, "Credits" section:

"Bytemark provides hardware to help to kick-start this port. Bytemark is a long-time partner of Debian"

and in the post Debian GNU/Linux port for RISC-V 64-bit (riscv64) mentioned before, and in slides of talks.

Kurt Keville, MIT's CSAIL

Kurt Keville from MIT's CSAIL was helping since early on, in 2016.

He has very kind to help me to travel and give talks about the Debian GNU/Linux riscv64 port in RISC-V so-called "workshops" in MIT/CSAIL in 2016 and UPC/Barcelona Supercomputing Centre in 2018.

Also, and apart from other great help that can never be paid off like encouragement to go ahead in important moments, in 2018 he set up and couple of big-ish servers, the network connectivity is excellent and there's also a local Debian mirror, which is great.

Here we host the rv-mit-01 to -18 VMs (see buildd status pages), building packages "natively" (inside Qemu, but emulating a riscv64 machine). These were the main builders for most of 2018 of all suites (basically, unstable ─which is the most important and through which all packages enter the archive that it will eventually be settled as stable─, and experimental).

In the last few months most of unstable is built by hardware machines, but these ones are still busy with experimental suite, and kept as back-up if other machines fail, or in cases of extended peak times, we can easily tell them to start processing packages from unstable again.

This support was really crucial in the early days, without these important resources the port would probably not be able to lift off. It has been acknowledged in the past, but only in talks.

SiFive

SiFive is company created by many of the minds from UC Berkeley who conceived and created the RISC-V architecture.

At the moment, they are the only to offer hardware that can be purchased publicly which can be used to build packages ─and as a general purpose GNU/Linux riscv64 system, for that matter─, the HiFive Unleashed.

They sponsored one board soon after it was premiered at FOSDEM in 2018, which is named rv-hfu-01 and hosted by me (though not attached to the buildd network, but sometimes appears mentioned in build logs or bug reports), in which happen many of the tries and special builds of packages with difficulties (e.g. builds for unreleased suite special of debian-ports, with some functionality disabled or to break dependency cycles, etc.).

They also sponsored other HiFive Unleashed boards, like one intended to become a porterbox (still in the works) and another one named rv-rr44-01 and hosted by Aurélien Jarno (there are plans to move them elsewhere, but it's convenient to have them close to one's hand, in case of problems, like frequent lock-ups).

rv-rr44-01 is part of the buildd network, and appears listed in the buildd status page for rv-rr44-01, so you can see the stats and what it's currently building.

Support from SiFive has been acknowledged in the past, but only in talks.

Aurélien Jarno

Aside from lots of personal time and skill contributing to this port, and debian-ports and Debian in general, there are two VMs that have been hosted and managed by him, that have been building packages for unstable and experimental since the early days too, along with the rv-mit- ones.

They are now hosted elsewhere (but kept their names), more on this below.

GCC Compile Farm Project / Oregon State University Open Source Lab (OSUOSL)

In mid-2018 I was approached by Laurent Guerby, from the GCC Compile Farm Project, to offer another two machines that they would host and we could use.

The GCC Compile Farm Project is a facilitator for free software developers to get access to resources, mosty to compile/build software projects, as the name implies. The management system for this project is hosted by Tetaneutral, and the machines themselves are hosted by various organizations around the world. These two machines will actually be hosted by the Oregon State University Open Source Lab (OSUOSL). From Lance Albertson, OSL's director:

"These machines are owned and hosted by the Oregon State University Open Source Lab (OSUOSL). The OSUOSL is a non-profit organization and provides infrastructure hosting for over 160 open source projects including those of worldwide leaders like the Apache Software Foundation, the Linux Foundation and Drupal."

It turns out that the machines are very similar to those at MIT that we were using, so it was basically doubling resources available.

By the time that we could set the machines up it was the start of "freeze" period for buster release, so basically we moved Aurélien's rv-aurel32-01 and -02 there instead of adding new VMs. Since then and at the moment they are helping to build unstable, because the hardware machines cannot cope in peak times.

Links to their buildd status pages:

We also use these machines for some work done by Helmut Grohne's rebootstrap project, because it's been very helpful to bootstrap RISC-V and we want ports in the future to be even more easy to bootstrap and adopt in Debian :-)

Mullvad

Mullvad is a VPN service from Sweden. They are providing us with HiFive Unleashed boards, rack space, network, ancillary hardware, and staff time on site to allow us to manage the boards remotely.

At the moment rv-mullvad-01 and -02, which are part of the buildd network, are hosted by Mullvad (the hostnames are a bit of a give-away, aren't they?). We were trying to get more boards there in the recent past, and while it has not been possible so far, we expect to have more boards there in the future.

Thanks to this, it has been possible since about mid-2019 to switch and have most packages built by hardware machines (all of them HiFive Unleashed boards), instead of mostly VMs until then.

This is a very important step in the progress of the port to hopefully become first-class at some point in the future, and this would not have been possible without support from Mullvad.

Their support had not been acknowledged publicly, so it was about time and one of the reasons of this post.

Links to their buildd status pages:

And finally...

... if you want to contribute in any way, please get it touch.

Work keeps happening and there are news in other areas that would be worth mentioning, but I really wanted to keep focus in this post on sponsors and build machines, so that's all for now.

Happy Building!

11 Dec 2019 2:23am GMT

Markus Koschany: My Free Software Activities in November 2019

Welcome to gambaru.de. Here is my monthly report that covers what I have been doing for Debian. If you're interested in Java, Games and LTS topics, this might be interesting for you.

Debian Games

Debian Java

Misc

Debian LTS

This was my 45. month as a paid contributor and I have been paid to work 24,5 hours on Debian LTS, a project started by Raphaël Hertzog. In that time I did the following:

ELTS

Extended Long Term Support (ELTS) is a project led by Freexian to further extend the lifetime of Debian releases. It is not an official Debian project but all Debian users benefit from it without cost. The current ELTS release is Debian 7 "Wheezy". This was my eightteenth month and I have been assigned to work 15 hours on ELTS.

Thanks for reading and see you next time.

11 Dec 2019 12:57am GMT

Ian Jackson: Debian GR - vote without thinking?

I was shown a link to a twitter post in which a DD encourages using a curl pastebin | mutt rune to vote. The rune looked like it had been debugged, so the poster put at least a little work into developing it.

I think this is rather poor. I think you should make up your own mind. That is why I have written three blog posts to encourage you to help with drafting alternatives during the discussion started by the DPL, understand the options on the ballot, and most conveniently deal with devotee's ballot format.

But of course maybe providing such a pre-cooked rune will enable people to vote who are otherwise too busy. It's certainly important that we get good turnout. If you are too busy, and you trust my judgement, then you could run:

mutt -H <(curl https://people.debian.org/~iwj/thoughtless-vote.txt )

or

curl https://people.debian.org/~iwj/thoughtless-ballot.txt | gpg --clearsign | mail gr_initsystems@vote.debian.org

Since you can change your vote up to the deadline of 23:59:59 UTC on Friday 2019-12-27, you could run a rune like that now and then change your vote later if you get time to think about it properly.

Obviously it would be best for you to read something like my voting guide and make up your own mind. But maybe it would be better to run my rune than not vote at all? Up to you I guess.



comment count unavailable comments

11 Dec 2019 12:14am GMT

10 Dec 2019

feedPlanet Debian

Jonathan Dowland: Debian's init system GR

Debian is currently conducting a vote on a General Resolution entitled Init systems and systemd. I had a few brief thoughts about the circumstances around this that I wanted to share.

I like systemd and I use it on all of my systems. That said, I have some concerns about it, in particular the way it's gradually eating up so much other systems software. The opportunity for alternatives to exist and get feedback from interested users seems important to me as a check and balance and to avoid a monoculture. Such an environment should even help to ensure systemd remains a compelling piece of software. The question that this GR poses is really whether Debian should be a place where alternatives can exist. In answering that question I am reminded of the mantra of Extinction Rebellion. I appreciate that is about a far more important topic, but it still seems pertinent: If not us, who? If not now, when?

What is Debian for, anyway? Once upon a time, from a certain perspective, it was all counter-cultural software. Should that change? Perhaps it already has. When I was more actively involved in the project, I watched some factions strive to compete with alternative distributions like Fedora. Fedora achieves a great deal, partly by having a narrow and well-defined focus. With the best will in the world, Debian can't compete at that game. And why should it? If Fedora is what you want, then Fedora is right there, go use it!

In the UK we are also about to vote in a General Election. As happens often in FPTP voting systems, the parties are largely polarized around a single issue, although one side of that issue is more factionalised than the other. And that side stands to lose out, as the vote is diluted. This Debian GR is in a similar situation, although not as bad since Debian doesn't use FPTP. But I could understand fellow developers, not as deeply invested in the issue as those who have proposed options, getting fatigued trying to evaluate them. For pro-systemd/anti-alternative folks, the choice is easy: First-choice the one (or two) positions that express that, and rank the majority under "further discussion". For those at the other pole, this strategy is risky: those folks want their transferable vote to move to the most popular option, and so must not succumb to voter fatigue.

Whatever your position, if you hold the power to vote, please take time to evaluate the options and use it.

10 Dec 2019 9:43pm GMT

Joey Hess: announcing the filepath-bytestring haskell library

filepath-bytestring is a drop-in replacement for the standard haskell filepath library, that operates on RawFilePath rather than FilePath.

The benefit, of course, is speed. "foo" </> "bar" is around 25% faster with the new library. dropTrailingPathSeparator is 120% faster. But the real speed benefits probably come when a program is able to input filepaths as ByteStrings, manipulate them, and operate on the files, all without using String.

It's extensively tested, not only does it run all the same doctests that the filepath library does, but each function is quickchecked to behave the same as the equivilant function from filepath.

While I implemented almost everything, I did leave off some functions that operate on PATH, which seem unlikely to be useful, and the complicated normalise and stuff that uses it.

This work was sponsored by Jake Vosloo on Patron.

10 Dec 2019 8:31pm GMT

Wouter Verhelst: GR 2019 002

Just sent in my vote. After carefully considering what I consider to be important, and reading all the options, I ended up with 84312756.

There are two options that rule out any compromise position; choice 1, "Focus on systemd", essentially says that anything not systemd is unimportant and we should just drop it. At the same time, choice 6, "support for multiple init systems is required", essentially says that you have to keep supporting other systems no matter what the rest of the world is doing lalala I'm not listening mom he's stealing my candy again.

Debian has always been a very diverse community; as a result, historically, we've provided a wide range of valid choices to our users. The result of that is that some of our derivatives have chosen Debian to base their very non-standard distribution on. It is therefore, to me, no surprise that Devuan, the very strongly no-systemd distribution, was based on Debian and not Fedora or openSUSE.

Personally I consider this variety in our users to be a good thing, and something to treasure; so any option that essentially throws that away, like choice 1, is not something I could live with. At the same time, the world has evolved, and most of our users do use systemd these days, which does provide a number of features over and above the older sysvinit system. Ignoring that fact, like option 6 does, is unreasonable in today's world.

So neither of those two options are acceptable to me.

That just leaves the other available options. All of those accept the fact that systemd has become the primary option, but differ in the amount of priority given to alternate options. The one outlier is option 5; it tries to give general guidance on portability issues, rather than commenting on the systemd situation specifically. While I can understand that desire, I don't agree with it, so it definitely doesn't get first position for me. At the same time, I don't think it's a terrible option, in that it still provides an opinion that I agree with. All in all, it barely made the cutoff above further discussion -- but really only barely so.

How did you vote?

10 Dec 2019 9:55am GMT