hartmans | Entries tagged with debian

I could definitely use some suggestions here, both in terms of things to try or effective places to ask questions about Pipewire audio. The docs are improving, but are still in early stages. Pipewire promises to combine the functionality of PulseAudio and Jack. That would be great for me. I use Jack for my DJ work, and it’s somewhat complicated and fragile. However, so far my attempts to replace Jack have been unsuccessful, and I might need to even use PulseAudio instead of Pipewire to get the DJ stuff working correctly.

The Setup

In the simplest setup I have a DJ controller. It’s both a MIDI device and a sound card. It has 4 channel audio, but it’s not typical surround sound. Two channels are the main speakers, and two channels are the headphones. Conceptually it might be better to model the controller as two sinks: one for the speakers and one for the headphones. At a hardware level they need to be one device for several reasons, especially including using a common clock. It’s really important than only the main mix go out channel 1-2 (the speakers). Random beeps or sound from other applications going out the main speakers is disruptive and unprofessional.

However, because I’m blind, I need that sound. I especially need the output of Orca (my screen reader) and Emacspeak (another screen reader). So I need that output to go to the headphones.

Under Pulse/Jack

The DJ card is the Jack primary sound device (system:playback_1 through system:playback_4). I then use themodule-jack-sink Pulse module to connect Pulse to Jack. That becomes the default sink for Pulse, and I link front-left from that sink to system:playback_3. So, I get the system sounds and screen reader mixed into the left channel of my headphones and nowhere else.

Enter Pipewire

Initially Pipewire sees the DJ card as a 4-channel sound card and assumes it’s surround4.0 (so front and rear left and right). It “helpfully” expands my stereo signal so that everything goes to the front and rear. So, exactly what I don’t want to have happen happens: all my system sounds go out the main speakers (channel 1-2).

It was easy to override Wireplumber’s ALSA configuration and assign different channel positions. I tried assigning something like a1,a2,fl,fr hoping that Pipewire wouldn’t mix things into aux channels that weren’t part of the typical surround set. No luck. It did correctly reflect the channels in things like pacmd list sinks so my Pipewire config was being applied. But the sound was still wrong. * I tried turning off channelmix.upmix. That didn’t help; that appears to be more about mixing stereo into center, rear and LFE. The basic approach of getting a stream to conform to the output node’s channels appears to be hurting me here.

Turning off stream.dont-remix actually got stereo sound to do exactly what I wanted. If I use sox to play a stereo MP3 for example, it comes out the headphones and not my speakers. Unfortunately, that didn’t help with the accessibility sounds at all. Those are mono in pulse land, and apparently mono is always expanded to all channels.
I didn’t try turning off channelmix entirely. I’m reasonably sure that would break mono sound entirely, so I’d get no accessibility output which would make my computer entirely unusable.
I tried using jack_disconnect to disconnect the accessibility ports from all but the headphones. The accessibility applications aren’t actually using Jack, but one of the cool things about Pipewire is that you can use Jack interfaces to manipulate non-Jack applications. Unfortunately, at least the Emacspeak espeak speech server regularly shuts down and restarts its sound connection. So, I get speech through the headphones for a phrase or two, and then it reverts to the default config.

I’d love any ideas about how I can get this to work. I’m sure it’s simple I’m just missing the right mental model or knowledge of how to configure things.

Pipewire Not Talking to Jack

I thought I could at least use Pipewire the same way I use Pulse. Namely, I can run a real jackd and connect up Pipewire to that server. According to the wiki, Pipewire can be a Jack client. It’s disabled by default, because you need to make sure that Wireplumber is using the real Jack libraries rather than the Pipewire replacements. That’s the case on Debian, so I enabled the feature.

A Jack device appeared in wpctl status as did a Jack sink. Using jack_lsp on that device showed it was talking to the Jack server and connected to system:playback_*. Unfortunately, it doesn’t work. The sink does not show up in pacmd list sinks, and pipewire-pulse gives an error about it not being ready. If I select it as the default sink in wpctl set-default I get no sound at all, at least from Pulse applications.

Versions of things

This is all on debian, approximately testing/bookworm or newer for the relevant libraries.

Pipewire 0.3.51-1
Wireplumber 0.4.10-2
pipewire-pulse and libspa0.2-jack are also 0.3.51-1 as you’d expect
Jackd2 1.9.17~dfsg-1

Recently, I migrated this blog from Livejournal over to Dreamwidth. As part of the process, I was looking back at my blog entries from around 2007 or so.

I miss those days. I miss the days when blogging was more of an interactive community. Comments got exchanged, and at least among my circle of friends people wrote thoughtful, well-considered entries. There was introspection into what was going on in people's lives, as well as technical stuff, as well as just keeping up with people who were important in my life.
Today, we have some of the same thought going into things like Planet Debian, but it's a lot less interactive. Then we have things like Facebook, Twitter, and the more free alternatives. There's interactivity, but it feels like everything has to fit into the length of a single tweet. So it is a lot faster paced and a lot less considered. I find I don't belong to that fast-paced social media as much as I did to the blogs of old.

I felt disgust and horror when I learned yesterday that rms had returned to the FSF board. When rms resigned back in September of 2019, I was Debian Project Leader. At that time, I felt two things. First, I was happy that the community was finally taking a stand in favor of inclusion, respect, and creating a safe, welcoming place to do our work. It was long past time for rms to move on. But I also felt thankful that rms was not my problem to solve. In significant part because of rms, I had never personally been that involved in the FSF. I considered drafting a statement as Debian Project Leader. I could have talked about how through our Diversity Statement and Code of Conduct we had taken a stand in favor of inclusion and respect. I could have talked about how rms's actions displayed a lack of understanding and empathy and how this created a community that was neither welcoming nor respectful. I didn't. I guess I didn't want to deal with confirming I had sufficient support in the project. I wanted to focus on internal goals, and I was healing and learning from some mistakes I made earlier in the year. It looked like other people were saying what needed to be said and my voice was not required. Silence was a mistake.

It's a mistake I've been making all throughout my interactions with rms. Enough is enough. It's long past time I added my voice to those who cry for accountability and who will not sit aside while rms's disrespect and harm is tolerated.

The first time I was silent about rms was around 15 years ago. I was at a science fiction convention in a crowded party. I didn't know anyone, other than the host of the party. I was out of my depth. I heard his voice---I recognized it from the Share the Software Song. He was hitting on some girl, talking about how he invented Emacs. As best I could tell, she didn't even know what Emacs was. Back then, I wondered what she saw in the interaction; why she stuck around even though she didn't know what he was talking about. I sure didn't want to be around; the interaction between the two of them was making me uncomfortable. Besides, the wings on her costume kept hitting me in the face. So I left as fast as I could.

I've learned a lot about creating safe spaces and avoiding sexual harassment since then. Thinking back, she was probably hitting me because she was trying to back away and getting crowded. If this happened today, I think I would do a better job of owning my responsibility for helping keep the space around me safe. I've learned better techniques for checking in to make sure people around me are comfortable.

I didn't come to silence alone: I had been educated into the culture of avoiding rms and not calling him out. There was a running game in the group of computer security professionals I learned from. The goal was to see how much you could contribute to free software and computer security without being recognized by or interacting with rms. And so, indoctrinated into a culture of silence about the harm that rms caused, I took my first step.

Things weren't much better when I attended Libreplanet 2019 just before taking office as Debian Project Leader. I had stayed away from the conference in large part because of rms. But there were Debian people there, and I was missing community interaction. Unfortunately, I saw that even after the problems of 2018, rms was still treating himself as above community standards. He interrupted speakers, objecting to how they phrased the problem they were considering. After a speech on codes of conduct in the free software community, he cornered the talk organizer to "ask her opinion" about the GNU project's lack of code on conduct. He wasn't asking for an opinion. He was justifying himself; there wasn't much listening in the conversation I heard. Aspects of that conversation crossed professional boundaries for what should be said. The talk organizer was okay--we talked about it after--but if we did a better job of policing our community, that wouldn't even be a question. I think the most telling sign was a discussion with an FSF board member. We were having a great conversation, but he had to interrupt it. He was on rms duty (my words) at the next session. The board had decided it was necessary to have members there so that the staff would not be put in awkward positions by their president. If someone needed to call rms out, it could be a board member rather than the staff members of the conduct team.

And yet again, I held my silence. It's so easy to keep silent. It's not that I never speak up. There are communities where I have called people out. But it's hard to paint that target on yourself. It's hard to engage and to stand strong for a community's standards when you aren't the target. It's hard to approach these problems while maintaining empathy for everyone involved. Some people give into the rage; I don't have that option if I want to be the person I've chosen to be. And so, when I do speak up, the emotional cost is high.

Yet, it's long past time I raised my voice on this issue. Rms has demonstrated that he cannot hold to standards of respect for others, respect for their boundaries, or standards of community safety. We need those standards to be a welcoming community.

If the people who came before me--those who taught me the game of avoiding rms--had spoken up, the community could have healed before I even came on the scene. If I and others had stood up fifteen years ago, we'd have another couple generations who were more used to respect, inclusion, welcoming and safety. The FSF board could have done their job back in 2018. And perhaps if more of us had spoken out in 2019, the FSF board would have found the strength to stand strong and not accept rms's return.

And so, finally, I raise my voice. I signed the open letter calling for the resignation of rms and the entire FSF board. Perhaps if we all get used to raising our voice, it will be easier. Perhaps if we stand together, taking the path of community rather than the path of silence, we'll have the support we need to create communities inclusive enough to welcome everyone who can contribute. For me, I'm done being silent.

There's one criticism of the open letter I'd like to respond to. I've heard concerns about asking for the resignation of the entire FSF board under the understanding that some board members voted against rms's return. It should be obvious why those who voted for rms's return need to resign. But resignation does not always mean you did something wrong. If you find yourself in a leadership role in an organization that takes decisions in significant conflict with your standards of ethics, resignation is also the right path. Staying on the board even if you voted against rms's return means that you consider voting for rms to be a reasonable thing to do. It means that even if you disagreed with it, you can still be part of an organization that takes the path of welcoming rms. At this point, I cannot do that, nor can I support leaders in the FSF who do.

So, I needed a container of Debian Slink (2.1), released back in 1999. I expected this was going to be a long and involved process. Things didn't look good from the start:

root@mount-peerless:/usr/lib/python3/dist-packages/sqlalchemy# debootstrap  slink /build/slink2 
http://archive.debian.org/debian                                                               
E: No such script: /usr/share/debootstrap/scripts/slink

Hmm, I thought I remembered slink support for debootstrap--not that slink used debootstrap by default--back when I was looking through the debootstrap sources years ago. Sure enough looking through the changelogs, slink support was dropped back in 2005.
Okay, well, this isn't going to work either, but I guess I could try debootstrapping sarge and from there go back to slink.
Except it worked fine.
Go us!

Last night, a series of forged emails was sent to a number of places around the Debian, Ubuntu and Free Software communities. The meat of the mail was a fake message from me to debian-private with the subject "DebConf19 Diversity Girls." I didn't write such a message.
I view this message as the latest installment in a campaign of attacks on Debian that attempt to undermine the project and take up the time of our members.
I was expecting something like this: yesterday, I banned Daniel Pocock from the project.There's been a pattern of related events over the past year and a half:

Confrontational messages from Daniel that do not stop even when moderators of the discussion forum ask him to stop.
Anonymous messages that expand on the points Daniel has been making accusing people and organizations of misconduct
Without claiming authorship of these anonymous messages, Daniel quickly expands on the messages in his blogs and goes forward assuming these anonymous claims are true
Use of mechanisms described on Daniel's websites to bypass moderation of community forums and other mechanisms designed to reach people who are not interested in the communication on the part of Daniel and the anonymous messages
And now, forged emails

That's not what is happening here.

December has been a difficult month for me and I think for Debian as a whole. It was strongly suggested to me that I (and Debian in general) needed more music. I'm reminded of the fun I had dancing with you all at DebConf. It's been a while since I dug out my DJ kit. But Dec 25, I pulled it out and spent a couple of hours looking at some of the tracks that came out since I last DJed. And then I put together a mix. I had fun. Perhaps you'd like a little more music in your holiday. If so, I join you on the (virtual) dance floor.

There are a lot of options on the ballot for the Init Systems GR.
There have been hundreds of messages on debian-vote, and more scattered
across debian-devel, debian-project, and bugs. Reading all that is no
easy task. so I would like to summarize my understanding of the options
and what they would mean. I've tried to remove as much bias as I can,
but this is still Sam's personal opinion.

I'm focused entirely on the effects of the proposals. Several options
(D, F, and G) spend significant time outlining principles. That is
something I'm ignoring here in this post, although I acknowledge it is
really important to some.

Areas of Agreement

One of the big surprises for me in this discussion is things that are
true of all the ballot options so far. We are agreed that programs
designed to use systemd features that only work with systemd are welcome
in Debian. That's true even if there is no way for these programs to
work without systemd. Under Proposal D, this is a bug, but not a
release-critical bug.

Init Diversity Options

Several options focus on encouraging or requiring packages to support
init systems others than systemd when that is possible. These include
Proposal
E, Proposal F,
and Proposal
A. Under proposal E, it is a release critical bug if a program does
not work when something other than systemd is pid 1 unless that program
is designed explicitly to work with systemd and no support for running
without systemd is available. Lack of an init script alone is not
sufficient to count as designed to work exclusively with systemd.

So, under this proposal, a maintainer must integrate support for running
without systemd if it is available. They are responsible for going out
and finding this support. If the support is as simple as writing an
init script, the maintainer has an RC bug until they write the init
script. If the support is more complex, the maintainer is not
responsible for writing it. Proposal A is the same as Proposal E,
except that the bug is not release-critical. I'll go into Proposal A in
more detail after discussing Proposal D.

Proposal D is similar to Proposal E. My interpretation is that Proposal D places
somewhat less of a burden on maintainers to go out and find existing
non-systemd support. My interpretation is that the bug becomes RC when
someone contributes that support. (Or if the support is present in the
upstream but turned off in the package). Proposal D requires that
non-systemd support not have a substantial effect on systemd
installations. So where as Proposal E uses the designed exclusively for
systemd criteria, Proposal D uses the no substantial effect on systemd
systems criteria to determine whether working only with systemd is
acceptable. The discussions seemed to imply that if Gnome uses systemd
features in excess of what technologies like elogind can handle, it is
likely to meet both criteria.

Proposal D goes into a lot more detail than Proposal E. Proposal E
would likely be a long-term block on using systemd facilities like
sysusers. Proposal D specifically proposes a mechanism whereby such
facilities can be documented in policy. This mechanism is only
available if it is likely that developers of non-systemd (including
non-Linux) systems will implement the facility. After a six-to-twelve
month transition time, the facility can be used even on non-systemd
systems. So, sufficiently low effort in the non-systemd community that
it is unreasonable to expect a facility could be implemented could still
permanently block adoption of such facilities. Proposal D is definitely
about a long-term commitment to non-systemd systems even if the effort
in the non-systemd community is not as high as we'd like to adopt new
features elsewhere.

Proposal D also includes a number of guidelines for proper behavior
around these emotionally charged issues.

The only difference between Proposal E and Proposal A is the severity of
the bug when non-systemd support is not in a package. In Proposal A,
this bug is important: potentially sufficient for a stable update, but
not release critical. As a practical matter, Proposal A allows the
non-systemd community to contribute (and NMU) patches for non-systemd
support. However, it does not place an obligation on maintainers to
write this support themselves. Proposal A would permit systemd
facilities like sysusers to be used, although doing so might be a bug.
In the specific case of sysusers, someone could justify NMUing a patch
to use adduser in a maintainer script. Unlike Proposal D, Proposal A
places the burden of keeping up with systemd facilities fully on the
non-systemd community. Proposal A does not have Proposal D's
requirement that it be reasonable to expect that the non-systemd
community can implement the facility.

Systemd Options

There are two systemd options: Proposal F
and Proposal
B. Proposal F replaces a previous Proposal C. As far as I can tell
Proposal F and C do the same thing, but Proposal F has some text
describing principles. As I said in the introduction, I'm not
discussing that here.

Under Proposal F, systemd is the only officially supported option.
Other init systems may be explored at wishlist priority. Systemd
facilities such as sysusers are encouraged, and we will use our usual
mechanisms to plan transitions from Debian facilities where appropriate.

Proposal B does not explicitly say that alternate init system work can
only be wishlist. Under Proposal B, I think it would be reasonable to
file some bugs at normal severity, but it would also be reasonable for a
maintainer to downgrade them. I don't consider that a significant
difference.

The big difference is that Proposal B commits us as a project to
reviewing integrations of technologies that are alternatives to
systemd facilities. The current example is elogind. But things like
a non-systemd implementation of sysusers, tmpfiles.d, etc, would also
qualify. The rationale is that sometimes alternatives like that touch
on core infrastructure, and even if other maintainers are doing the
work, gatekeeper review is needed. Under Proposal B, the alternate technologies would be available, but whether to use them in a specific package would be up to the maintainer. I've discussed in another, more opinionated blog post why this might be a good idea.

Proposal G

As best I can tell Proposal G is just a set of principles. so, in the context of the analysis I have set out to perform here, I think there is nothing to say.

This is my personal opinion, not that of the project leader. Tomorrow,
I'll write an essay trying to discuss the various options in with as
little bias as I can manage (although even that will be Sam's opinion).
Several people have asked me why I included Proposal B.
This is my answer.

While I was talking to people about systemd and init systems, people
seemed to inherently assume that being uncomfortable with systemd meant
that you were in favor of sysvinit, or at least init-script based
solutions. At least, people who were heavily involved in the issue made
that assumption. That didn't resonate with me.

Several concerns commonly raised with systemd resonate with me:

It combines a bunch of things in one project; as an example how you
start daemons ends up being tied to how you configure the network.

This combination seems like it might reduce innovation at least
outside of the systemd ecosystem, because interfaces are coupled.

It is Linux specific

Of these, the biggest concern for me is the idea that systemd might
stifle innovation by becoming one point of control.

And yet, in my opinion, systemd is vastly superior to the current
alternatives. I'd far rather be writing service units than init
scripts. They are more declarative. Dependencies that I care about are
easier to express. There are better security isolation facilities. In
non-Debian work I've found that I depend heavily on systemd because it
is easier and more pleasurable to code to than the alternatives.
Declarative syntax for managing users is useful. I haven't personally
seen the huge joy of socket activation, but if I were writing somewhat
different things, perhaps I would. Given
the options today, I would pick systemd hands down and not look back.

But what about tomorrow? For me, one of the great things about Debian
has been that it's possible to integrate new technologies and to try
things out. Debian has been the OS where I and many others could try
out new technologies and figure out what it was like to fully integrate
them into the operating system. Systemd is the best we've got now, but
I'm reluctant to step away from Debian as a platform for innovation and
experimentation.

Yet I don't think focusing on sysvinit or other init-script based
solutions actually has anything to do with the kind of innovation I'm
talking about. I understand that for people who value sysvinit (or
something like runit) above systemd, that work is valuable. My
experience is that for my needs, systemd is a better fit. I wanted a
proposal that allowed us to maintain Debian as a platform for innovation
without focusing on the legacy of init scripts. I think that if there
is going to be something that some day replaces systemd, it will support
service units (or a significant subset) not init scripts. I suspect it
will have a way to handle socket activation and so on. And I cannot
imagine a future systemd replacement that does not have advanced
security isolation features.

How it Works

Proposal B is a systemd focused proposal. It's very similar to Proposal F.
The text is different, but the implications of both proposals are
similar. Maintainers can use whatever systemd facilities they choose.
Init scripts are not required. For most maintainers, even thinking
about alternate init systems or future experiments is something entirely
optional. That's true under both proposal F and Proposal B.

Where they differ is in how much support the project gives to
experiments involving alternate init systems. Under Proposal F, that's
entirely optional at each member's discretion. My experience is that's
not sufficient for Debian to remain a community for innovation. My
experience is that key maintainers and teams maintaining central
infrastructure or packages often need to work with people who are trying
to integrate new features. The difference between Proposal B and F is
that under Proposal B, we commit to making that happen for technologies
that are important in exploring alternatives to systemd.

Obviously, no member of our community is obligated to do work. In
practice this commitment might mean working to find new volunteers to
help out key packages or teams and do this work. Sadly, there are areas
where the history of interaction has not been so good; behavior on
multiple sides of discussions has not lived up to our standards. In
addition to making sure we have the necessary volunteers for key
packages and teams,
part of meeting this commitment may involve working with people who
want to explore alternatives to systemd to find advocates who foster a
climate where we can be excellent to each other.

The Risks

There are some real risks with Proposal B. The biggest is that we'll
spend time working on integrations and nothing innovative will come out
of it. A possible outcome is that we spend a lot of time integrating
elogind and similar technologies, but they end up not being useful
because packages start depending on service units and socket
activations. Unless something new comes along, we may waste our
effort. Yet we've often been willing to spend effort to enable people
to try things. For me, this proposal is about reaffirming that aspect
of Debian.

In the worst case, it's possible that we decrease the quality of our
systemd integration leaving room for something else, spend significant
emotional energy, and do not end up with interesting innovation.
I think it's much more likely that if there is no interesting
innovation, Proposal B will slowly morph into Proposal F.

Why did You Do this?

In the beginning of this post, I talked about how I personally
considered the concerns about systemd separate than the desire to keep
init-script based systems running. That view is uncommon among people
who have been spending a lot of time on this issue. In general people
who are spending a lot of time on init systems seem to be fairly
divided. If you are trying to get work done today, you are probably
either fully using systemd or using one of the existing init-script
based alternatives.

However, my concern resonated with developers I talk to who spend less
time involved in the issue. Not people who were going to go research
things enough to write a proposal. But people who weren't sure that
systemd was the way and the light of the future, but found it had a lot
of great things going for it.

I was one of the few people who was taking the time to really understand
the issues but who was somewhat flexible. I didn't even know how I was
going to rank the options on my ballot until this morning. Yes, I've
been systemd leaning in some ways, but I also very much see the
arguments in favor of enabling people to keep other init systems
working. I'd be happy with most of the options on this ballot winning.
So, I tried to listen and see if there were ways of splitting
disagreement that wouldn't work for the people most committed to one
position, but might appeal to people who are less involved.

Why are you Writing This Post?

I think it's dangerous for someone who is project leader to speak a
personal opinion, especially on a controversial issue. However, I've
heard people struggling with some of the issues I discuss here in our
community. What I say may give people another way of looking at
things. I do think I have a valuable prospective because I have spent a
lot of time thinking about the issues but have not been as intimately
involved as others who have spent similar time. I think my need to act
as a facilitator at least for this GR is over. And after spending a day
considering, I think it's more beneficial to specifically ask the
project to think about Debian as a community for experimentation than to
say nothing.

Recently, we’ve been having some discussion around the use of non-free software and services in doing our Debian work. In judging consensus surrounding a discussion of Git packaging, I said that we do not have a consensus to forbid the use of non-free services like Github. I stand behind that consensus call. Ian Jackson, who initially thought that I misread the consensus later agreed with my call.

I have been debating whether it would be wise for me as project leader to say more on the issue. Ultimately I have decided to share my thoughts. Yes, some of this is my personal opinion. Yet I think my thoughts resonate with things said on the mailing list; by sharing my thoughts I may help facilitate the discussion.

We are bound together by the Social Contract. Anyone is welcome to contribute to Debian so long as they follow the Social Contract, the DFSG, and the rest of our community standards. The Social Contract talks about what we will build (a free operating system called Debian). Besides SC #3 (we will not hide problems), the contract says very little about how we will build Debian.

What matters is what you do, not what you believe. You don’t even need to believe in free software to be part of Debian, so long as you’re busy writing or contributing to free software. Whether it’s because you believe in user freedom or because your large company has chosen Debian for entirely pragmatic reasons, your free software contributions are welcome.

I think that is one of our core strengths. We’re an incredibly diverse community. When we try to tie something else to what it means to be Debian beyond the quality of that free operating system we produce, judged by how it meets the needs of our users, we risk diminishing Debian. Our diversity serves the free software community well. We have always balanced pragmatic concerns against freedom. We didn’t ignore binary blobs and non-free firmware in the kernel, but we took the time to make sure we balanced our users’ needs for functional systems against their needs for freedom. By being so diverse, we have helped build a product that is useful both to people who care about freedom and other issues. Debian has been pragmatic enough that our product is wildly popular. We care enough about freedom and do the hard work of finding workable solutions that many issues of software freedom have become mainstream concerns with viable solutions.

Debian has always taken a pragmatic approach to its own infrastructure and to how Debian is developed. The Social Contract requires that the resulting operating system be 100% free software. But that has never been true of the Debian Project nor of our developers.

At the time the Social contract was adopted, uploading a package to Debian involved signing it with the non-free PGP version 2.6.3. It was years later that GnuPG became commonly used.

Debian developers of the day didn’t use non-free tools to sign the Social Contract. They didn’t digitally sign it at all. Yet their discussions used the non-free Qmail because people running the Debian infrastructure decided that was the best solution for the project’s mailing lists.

“That was then,” you say.

Today, some parts of security.debian.org redirect to security-cdn.debian.org, a non-free web service

Our recommended mirror (deb.debian.org) is backed by multiple non-free CDN web services.

Some day we may be using more non-free services. If trends in email handling continue, we may find that we need to use some non-free service to get the email we send accepted by major email providers. I know of no such plan in Debian today, but I know other organizations have faced similar choices.

Yet these choices to use non-free software and non-free services in the production of Debian have real costs. Many members of our community prefer to use free software. When we make these choices, we can make it harder for people to contribute to Debian. When we decline to use free software we may also be missing out on an opportunity to improve the free software community or to improve Debian itself. Ian eloquently describes the frustrations those who wish to use only free software face when faced with choices to use non-free services.

As alternatives to non-free software or services have become available, we as a project have consistently moved toward free options.

Normally, we let those doing the work within Debian choose whether non-free services or software are sufficiently better than the free alternatives that we will use them in our work. There is a strong desire to prefer free software and self-hosted infrastructure when that can meet our needs.

For individual maintainers, this generally means that you can choose the tools you want to do your Debian work. The resulting contributions to Debian must themselves be free. But if you want to go write all your Debian packaging in Visual Studio on Windows, we’re not going to stop you, although many of us will think your choices are unusual.

And my take is that if you want to store Debian packages on Github, you can do that too. But if you do that, you will be making it harder for many Debian contributors to contribute to your packages. As Ian discussed, even if you listen to the BTS, you will create two classes of contributors: those who are comfortable with your tools and those who are not. Perhaps you’ve considered this already. Perhaps you value making things easier for yourself or for interacting with an upstream community on Github over making it easier for contributors who want to use only free tools. Traditionally in Debian, we’ve decided that the people doing the work generally get to make that decision. Some day perhaps we’ll decide that all Debian packaging needs to be done in a VCS hosted on Debian infrastructure. And if we make that decision, we will almost certainly choose a free service to host. We’re not ready to make that change today.

So, what can you do if you want to use only free tools?

You could take Ian’s original approach and attempt to mandate project policy. Yet each time we mandate such policy, we will drive people and their contributions away. When the community as a whole evaluates such efforts we’ll need to ask ourselves whether the restriction is worth what we will lose. Sometimes it is. But unsurprisingly in my mind, Debian often finds a balance on these issues.

You could work to understand why people use Github or other non-free tools. As you take the time to understand and value the needs of those who use non-free services, you could ask them to understand and value your needs. If you identify gaps in what free software and services offer, work to fix those gaps.

Specifically in this instance, I think that setting up easy ways to bidirectionally mirror things between Github and services like Salsa could really help.

Conclusions

We have come together to make a free operating system. Everything else is up for debate. When we shut down that debate—when we decide there is one right answer—we risk diluting our focus and diminishing ourselves.

We and the entire free software community win through the Debian Project’s diversity.

Freedom within the Debian Project has never been simple. Throughout our entire history we’ve used non-free bits in the sausage making, even though the result consists (and can be built from) entirely free bits.

This complexity and diversity is part of what allows us to advocate for software freedom more successfully. Over time, we have replaced non-free software that we use with free alternatives, but those decisions are nuanced and ever-changing.

All the members of the Antiharassment team met with the Debian Account Managers and the DPL in that other Cambridge— the one with proper behaviour, not the one where pounds are weight and not money.

I was nervous. I was not part of decision making earlier this year around code of conduct issues. I was worried that my concerns would be taken as insensitive judgment applied by someone who wasn’t there.

I was worried about whether I would find my values aligned with the others. I care about treating people with respect. I also care about freedom of expression. I value a lot of feminist principles and fighting oppression. Yet I’m happy with my masculinity. I acknowledge my privilege and have some understanding of the inequities in the world. Yet I find some arguments based on privilege problematic and find almost all uses of the phrase “check your privilege” to be dismissive and to deny any attempt at building empathy and understanding.

And Joerg was there. He can be amazingly compassionate and helpful. He can also be gruff at times. He values brevity, which I’m not good at. I was bracing myself for a sharp, brief, gruff rebuke delivered in response to my feedback. I know there would be something compassionate under such a rebuke, but it might take work to find.

The meeting was hard; we were talking about emotionally intense issues. But it was also wonderful. We made huge progress. This blog is not about reporting that progress.

Like the other Debian meetings I’ve been at, I felt like I was part of something wonderful. We sat around and described the problems we were working on. They were social not technical. We brainstormed solutions, talked about what worked, what didn’t work. We disagreed. We listened to each other. We made progress.

Listening to the discussions on debian-private in December and January, it sounded like DAM and Antiharassment thought they had it all together. I got a note asking if I had any suggestions for how things could have been done better. I kind of felt like they were being polite and asking since I had offered support.

Yet I know now that they were struggling as much as any of us struggle with a thorny RC bug that crosses multiple teams and packages. The account managers tried to invent suspensions in response to what was going on. They wanted to take a stand against bullying and disrespectful behavior. But they didn’t want to drive away contributors; they wanted to find a way to let people know that a real problem required immediate attention. Existing tools were inadequate. So they invented account suspensions. It was buggy. And when your social problem solving tools are buggy, people get hurt.

But I didn’t find myself facing off against that mythical group of people sure in their own actions I had half imagined. I found myself sitting around a table with members of my community, more alike than different. They had insecurities just like I do. They doubted themselves. I’m sure there was some extent to which they felt it was the project against them in December and January. But they also felt some of that pain that raged across debian-private. They didn’t think they had the answers, and they wanted to work with all of us to find them.

I found a group of people who genuinely care about openness and expressing dissenting views. The triggers for action were about how views were expressed not about those views. The biggest way to get under DAM’s skin and get them started thinking about whether there is a membership issue appears to be declining to engage constructively when someone wants to talk to you about a problem. In contrast, even if something has gone horribly wrong trying to engage constructively is likely to get you the support of all of us around that table in finding a way to meet your needs as well as the greater project.

Fear over language didn’t get in our way. People sometimes made errors about using someone’s preferred pronouns. It wasn’t a big deal: when they noticed they corrected themselves, acknowledged that they cared about the issue and went on with life. There was cursing sometimes and some really strong feelings.

There was even a sex joke. Someone talked about sucking and someone else intentionally misinterpreted it in a sexual context. But people payed attention to the boundaries of others. I couldn’t have gotten away with telling that joke: I didn’t know the people well enough to know their boundaries. It is not that I’m worried I’ll offend. It is that I actively want to respect the others around me. One way I can do that is to understand their boundaries and respect them.

One joke did cross a line. With a series of looks and semi-verbal communication, we realized that was probably a bit too far for that group while we were meeting. The person telling the joke acknowledged and we moved on.

I was reassured that we all care about the balance that allows Debian to work. We bring the same dedication to creating the universal operating system that we do to building our community. With sufficient practice we’ll be really good at the community work. I’m excited!

Current Location: Cambridge, England

This is copied over from my spiritual blog. I'm nervous doing that, especially at a point when I'm more vulnerable than usual in the Debian community. Still, this is who I am, and I want to be proud of that rather than hide it. And Debian and the free software community are about far more than just the programs we write. So hear goes:

The Libreplanet opening keynote had me in tears. It was a talk by Dr. Tarek Loubani. He described his work as an emergency physician in Gaza and how 3d printers and open hardware are helping save lives.

They didn't have enough stethoscopes; that was one of the critical needs. So, they imported a 3d printer, used that to print another 3d printer, and then began iterative designs of 3d-printable stethoscopes. By the time they were done, they had a device that performed as well or better than than a commercially available model. What was amazing is that the residents of Gaza could print their own; this didn't introduce dependencies on some external organization. Instead, open/free hardware was used to help give people a sense of dignity, control of some part of their lives, and the ability to better save those who depended on them.

Even more basic supplies were unavailable. The lack of tourniquets caused the death of some significant fraction of casualties in the 2014 war. The same solution—3d-printed tourniquets had an even more dramatic result.

Dr. Loubani talked about how he felt powerless to change the world around him. He talked about how he felt like an insignificant ant.

By this point I was feeling my own sense of hopelessness and insignificance. In the face of someone saving lives like that, I felt like I was only playing at changing the world. What is helping teach love and connection when we face that level of violence? Claming that sexual freedom is worth fighting for seems like a joke in the worst possible taste in the face of what he is doing. I felt like an imposter.

Then he went on to talk about how we are all ants, but it is the combination of all our insignificant actions that eventually change the world. He talked about how the violence he sees is an intimate act: he talked about the connection between a sniper and their victim. We die one at a time; we can work to make things better one at a time.

He never othered or judged those committing violence. Not as he talked about his fellow doctor and friend who was shot, radioed that he could not breathe, and eventually died pinned down by gunfire so that no one could rescue him. Not as he talked about how he himself was shot. Not as he helped the audience connect with grief-stricken family members facing the death of their loved ones. He never withdrew compassion.

To me I heard hope that what I try to teach can matter; it can connect. If he can face that violence and take a stand against it while still maintaining compassion, then this stuff I believe actually can work. Facing the world and making real changes without giving up compassion and empathy seems more possible: I’ve seen it done.

Somewhere in this talk, I regained a connection with my own value. People like him are helping save people. However, the violence will continue until we have the love, empathy and compassion to understand and connect with each other and find better options. In my own way I’m doing that. Every time I help someone see a different way of looking at things, I make it easier for them to start with empathy first rather than fear.

Everything I’ve written about sex is still true. That journey can bring us closer to accepting ourselves, stepping past fear and shame. Once we accept our own desires and our own need, we’re in a better position to meet in the Strength of Love and advocate for our own needs while offering compassion to others. Once we know what we can find when we have empathy and connection, we can learn to strive for it.

So I will find joy in being my own little ant. Insignificant and divine: take your pick as it’s all the same in the end.

Bringing that Round to Debian

Debian is back in the center of my compassion work. I'm running for Debian project Leader (DPL). I served on the Debian Technical Committee for over a year, hoping to help bring understanding of diverse positions to our technical dispute resolution process. That ended up being the wrong place. Everyone seems to believe that the DPL is currently at the center of most of the work of helping people connect. I hope to fix that: more than one person should be driving that work.

After the keynote I found myself sitting between Micky Metts and Henry Poole. Micky asked me what I did that I loved. “Ah, she’s not expecting this answer,” I thought to myself as I talked about my spiritual work and how it overlaps with my Debian work. It turns out that she was delighted by the answer and we had a great time chatting about self empowerment. I’m looking forward to her keynote later today.

Then Henry asked how I was going to accomplish bringing empathy into Debian. I talked about my hopes and dreams and went through some of the specifics I’ve discussed in my platform and what I’ve had success with so far. He talked about similarities and overlaps with work his company does and how he works to teach people about free software.

Especially after that keynote it was joyful to sit between two luminaries and be able to share hopes for empathy, compassion and connection. I felt like I had found validation and energy again.

Recently, when asked to engage with the Debian Technical Committee, a maintainer chose to orphan their package rather than discuss the issue brought before the committee. In another decision earlier this year, a maintainer orphaned their package indicating a lack of respect for the approach being taken and the process. Unfortunately, this joins an ever longer set of issues where people walk away from the TC process disheartened and upset.

For me personally the situations where maintainers walked away from the process were hard. People I respect and admire were telling me that they were unwilling to participate in our dispute resolution process. In one case the maintainer explicitly did not respect a process I had been heavily involved in. As someone who values understanding and build a team, I feel disappointed and hurt thinking about this.

Unfortunately, I don't feel much better when I consider several of the other issues brought before the TC. In a number of cases, the process has concluded, but it feels like a pyrrhic victory. We have an answer, but often we never reached an understanding of one of the key stakeholder's positions. People are sufficiently disappointed or frustrated that they reduce their involvement. That is, the answer is not one they can live with. Sometimes, I'm not even sure that answering the question was worth the cost.

My initial suspicion as I begin to consider issues that have come before the TC in the last few years is that as a necessary consequence of how the TC operates, we will drive a significant chunk of those who come to us away from our community. I will not be part of that. If I end up eventually agreeing with this suspicion, I will either work to improve the TC process or find a different way to contribute to the project that is more aligned with my goals.

Our Community is More Important than Technical Correctness

I firmly believe that Debian's strength is its community. Distributions, upstreams, free-software advocates, corporate interests, and everything in between work together. Because we are working on a concrete product,we actually have to understand how our needs conflict and compliment each other. Also, like any organization, our ability to get things done is dependent on our contributors and the time we all put in.

I cannot think of anything more harmful we can do than drive away a constructive contributor. Technical quality is important: many of us will eventually go away if quality drops too much. However, Debian itself can be improved incrementally. Yes, new people do join Debian. However, it takes a lot of new people to make up for a situation where everyone involved is frustrated, and some leave and tell their friends to stay away from Debian.

When a Disagreement Reaches the TC

When a disagreement reaches the TC, we know a few things. First, people have not have not been able to resolve it on their own. Second, the disagreement is important enough to at least one of the parties to ask for outside help.

If the TC were to simply announce a decision, it is very likely that at least one party would feel frustrated and disappointed. If the decision is important to someone it almost always means that they care about the outcome. If previous efforts have not reached agreement then there is an outcome that is undesired. While it's possible under the constitution that two parties could bring an issue to the TC mutually where the dynamics could be different, this does not happen in practice.

When we "lose"

When a decision making process decides to select one of my undesired outcomes, I have strong negative feelings. First, there is the technical result itself. Because of an adverse decision it is generally harder for me to do my technical work, or some ethical position or group I care about is disadvantaged. However, the strongest feelings are related to needs about my place in the community, not a direct response to the technical decision. I worry about whether issues I care about will be valued in the future; I would likely feel weary or scared thinking of contributing in an environment where issues that matter to me aren't going to be considered. I tend to feel frustrated if my position was not adequately considered this time around.

Often, the strongest feelings do not stem from how I am impacted by the decision itself. Thus, if my more general needs are addressed, I will feel a lot better about not having my preferred outcome selected. Confidence that my position was understood is the single biggest factor in being able to accept the result. If the community took the time to understand me, then I have confidence that I am valued. I can advocate for change and be part of the ongoing discussion. If I understand the other positions then I can understand that the position was not arbitrary. Understanding the other positions is also a prerequisite to seeing how things I value were considered, especially when the tradeoff did not ultimately favor these values.

My conversations with others about their experience with conflict suggest my feelings and needs are common.

However, the TC focuses almost exclusively on the technical matter before it. I don't think the TC has done a good job of actually understanding maintainers or the people bringing issues to us. Especially when we're fairly sure we understand what the ultimate decision will be, we focus on getting to that decision. Of course part of actually understanding someone is considering what they have to say. Even when you have high confidence in an outcome, if you want someone to feel understood, you do have to listen at a point where you can consider what they bring forward.

Frustration of Being Questioned

On the other side, it's frustrating to have your decisions questioned. Reviewing a decision takes time. Even if the TC agrees with a maintainer, asking that maintainer to sit through a long process can create frustrations as deep as any I discussed in the previous section.

So the process is doubly bad for maintainers. Someone can bring up an issue which requires precious time. Then if the TC decides against the maintainer, we have all the problems I discussed previously.

I acknowledge this. A good process must respect the maintainer's time. However, it must respect the community members who disagree with maintainers. Everyone who brings an issue to the TC is a developer. They have contributed significantly to our community and are part of our team. Yes, we need to protect the process against abuse. But in a very real sense if we aren't willing to consider an issue and we aren't willing to engage with someone, understand why they think the issue should be considered, and work until they understand why we made our decision, we are saying we do not respect them enough to take that time. We should expect that to drive people away.

I wonder if the solution here involves a two phase process. During the first phase we work with someone bringing an issue to us until we understand it. We either engage the maintainer at that point, spend the time to help the person bringing an issue to us understand why we are not engaging the maintainer, or have decided the issue is abusive of the processs/misdirected. For this to work maintainers would have to trust us enough to actually be willing to sit back and not spend a lot of their time.

Sam, It's Just Personalities

One criticism I've heard as I discuss this is that a lot of the negative feelings surround interpersonal conflict and are personality conflicts. Yes, personalities matter. Yes, we’re still healing from the Systemd discussion.

However, as a community, I think we need to figure out how we respect the inevitable personality conflicts. I can think of one or two developers I'm still upset with years after an issue. It happens. Perhaps if I were a maintainer when one of these developers raised a concern with my packages, I could ask that someone else be a primary advocate for an issue. Similarly, if a developer wanted to address an issue with me as a maintainer but would prefer not to deal with me, perhaps we could figure out some way that we could see if someone else shared the concern.

Dropping a Package is Sometimes an Answer

My concerns were sparked by instances where a maintainer dropped a package rather than interact with the TC. Sometimes that can be a healthy step in a transition. At Debconf this year, Enrico Zini gave a talk on consent culture in Debian. One of the key points of his talk is that we can find over time that what we're being asked to do in Debian is no longer consistent with our boundaries. If it isn’t helping us move forward—if it isn’t fun—then it is likely time to stop.

In that sense, approaching disagreement can be a great time to take stock and ask whether we still enjoy maintaining a package. If we don’t, then stepping aside and letting others take it on can be a great way that we and they can be happier. I don’t really think that’s what happened in these instances though. Based on comments made to me, this sounded more like a lack of faith in being treated well or in our ability as a committee.

Even so, Enrico’s talk applies in a number of ways here. He suggests that the approach we should take when someone is done and steps away is to thank then. I couldn’t agree more. From the depth of my heart I offer thanks: “Thank you for taking care of yourself and stepping away when it is no longer fun. Thank you for all the effort you have put into these packages. I hope to work with you on great things in the future.”

Current Mood: sad

I recently returned from Debconf. This year at Debconf, Matthew Garrett gave a talk about the next twenty years in free software. In his talk he raised concerns that Debian might not be relevant in that ecosystem and talked about some of the trends that contribute to his concerns.
I was talking to Marga after the talk and she said that Debian used to be a lot more innovative than it is today.
My initial reaction was doubt; what she said didn't feel right to me. At the time I didn't have a good answer. Since then I've been pondering the issue, and I think I have a partial answer to both Marga and Matthew and so I'll share it here.
In the beginning Debian focused on a lot of technical innovations related to bringing an operating system together. We didn't understand how to approach builds and build dependencies in a uniform manner. Producing packages in a clean environment was hard. We didn't understand what we wanted out of packages in terms of a uniform approach to configuration handling and upgrades. To a large extent we've solved those problems.
However, as the community has grown, our interests are more diverse. Our users and free software (and the operating system we build together) are what bring us together: we still have a central focus. However, no one technical project captures us all. There's still significant technical innovation in the Debian ecosystem. That innovation happens in Debian teams, companies and organizations that interact with the Debian community. We saw several talks about such innovation this year. I found the talk about ostree and flatpak interesting, especially because it focused on people in the broader Debian ecosystem valuing Debian along with some of the same technologies that Matthew is worried will undermine our relevance.
Matthew talked about how Debian ends up being a man-in-the-middle. We're between users and developers. we're between distributions and upstreams. Users are frustrated because we hold back the latest version of software they want from getting to them. Developers are frustrated because we present our users with old versions of their software configured not as they would like, combined with different dependencies than they expect.
All these weaknesses are real.
However, I think Debian-in-the-middle is our greatest strength both on the technical and social front.
I value Debian because I get a relatively uniform interface to the software I use. I can take one approach to reporting bugs whether they are upstream or Debian specific. I expect the software to behave in uniform ways with regard to things covered by policy. I know that I'm not going to have to configure multiple different versions of core dependencies; for the most part system services are shared. When Debian has value it's because our users want those things we provide. Debian has also reviewed every source file in the software we ship to understand the license and license compatibility. As a free software supporter and as someone who consumes software in commercial context, that value alone is enormous.
The world has evolved and we're facing technologies that provide different models. They've been coming for years: Python, Ruby, Java, Perl and others have been putting together their own commons of software. They have all been working to provide virtualization to isolate one program (and its dependencies) from another. Containerization takes that to the next level. Sometimes that's what our users want.
We haven't figured out what the balances are, how we fit into this new world. However, I disagree with the claim that we aren't even discussing the problem. I think we're trying a lot of things off in our own little technical groups. We're just getting to the level of critical mass of understanding where we can take advantage of Debian's modern form of innovation.
Because here's the thing. Debian's innovation now is social, not technical. Just as we're in the middle technically, we're in the middle socially. Upstreams, developers, users, derivatives, and all the other members of our community work together. we're a place where we can share technology, explore solutions, and pull apart common elements. This is the first Debconf where it felt like we'd explored some of these trends enough to start understanding how they might fit together in a whole. Seven years ago, it felt like we were busy being convinced the Java folks were wrong-headed. A couple of years later, it felt like we were starting to understand our users' desires that let to models different than packaging, but we didn't have any thoughts. At least in my part of the hallway it sounded like people were starting to think about how they might fit parts together and what the tradeoffs would be.
Yes, Matthew's talk doubtless sparked some of that. I think he gave us a well deserved and important wake-up call. However, I was excited by the discussion prior to Thursday.
What I'm taking a way is that Debian is valuable when there's a role in the middle. Both socially and technically we should capitalize on situations where something between makes things better and get out of the way where it does not.

I recently diagnosed a problem in Debian's pam-p11 package. This package allegedly permits logging into a computer using a smart card or USB security token containing an ssh key. If you know the PIN and have the token, then your login attempt is authorized against the ssh authorized keys file. This seems like a great way to permit console logins as root to machines without having a shared password. Unfortunately, the package didn't work very well for me. It worked once, then all future attempts to use it segfaulted. I'm familiar with how PAM works. I understand the basic ideas behind PKCS11 (the API used for this type of smart card), but was completely unfamiliar with this particular PAM module and the PKCS11 library it used. The segfault was in an area of code I didn't even expect that this PAM module would ever call. Back in 1994, that would have been a painful slog. Gdb has improved significantly since then, and I'd really like to thank all the people over the years who made that possible. I was able to isolate the problem in just a couple of hours of debugging. Here are some of the cool features I used:

"target record-full" which allows you to track what's going on so you can go backwards and potentially bisect where in a running program something goes wrong. It's not perfect; it seems to have trouble with memset and a few other functions, but it's really good.
Hardware watch points. Once you know what memory is getting clobbered, have the hardware report all changes so you can see who's responsible.
Hey, wait, what? I really wish I had placed a breakpoint back there. With "target record-full" and "reverse-continue," you can. Set the breakpoint and then reverse continue, and time runs backwards until your breakpoint gets hit.
I didn't need it for this session, but "set follow-fork-mode" is very handy for certain applications. There's even a way to debug both the parent and child of a fork at the same time, although I always have to go look up the syntax. It seems like it ought to be "set follow-fork-mode both," and there was once a debugger that used that syntax, but Gdb uses different syntax for the same concept.

Anyway, with just a couple of hours and no instrumentation of the code, I managed to track down how a bunch of structures were being freed as an unexpected side effect of one of the function calls. Neither I nor the author of the pam-p11 module expected that (although it is documented and does make sense in retrospect). Good tools make life easier.

Saturday was an excellent day. There was a gathering at SIPB to work on Debian and try to fix release-critical bugs. I was expecting we might have around 7 people. We had around 30. There is incredible energy in a room of 30 smart people all working on different problems. People were moving around as they finished problems, helping each other learn new skills, and so on. Those of us most familiar with Debian were working on uploads and on helping people understand packaging. Then, later, I spent the evening at an excellent party where I met some great new people and ran into other friends I see infrequently.