Entries for Planet Debian.
Fun and Sanity in Debian
A friend of mine recently asked: "is there anything happening in Debian besides systemd?"
Of course there is. He asked it 2 days after the freeze, which happened in time, and with an amazingly low RC bug count.
The most visible thing right now seems to be this endless init system argument, but there are fun and sane things in Debian. Many of them.
I think someone should put the spotlight on them, and here's my attempt.
Here are a few quotations that I collected:
The armhf and arm64 ports have for me been wonderful and exciting, and were a great time for me to start getting involved. (Jon "Aardvark" Ward)
We have a way of tracking random contributors, and as far as I know no other project has anything like it. (Enrico Zini)
codesearch.debian.net is an incredibly important resource, not just for us but for the free software community at large. (Ben Hutchings)
sources.debian.net is a very useful resource with lots of interested contributors, it received 10 OPW applicants (Stefano Zacchiroli)
It has never been easier to work on new infrastructure project thanks to the awesome work of the DSA team. We have dozens of contribution opportunities outside of just plain packaging. (Raphaël Hertzog)
The work on reproducible builds has achieved excellent results with 61.3% of packages being reproducible. (Paul Wise)
Porting arm64 has been (peversely) great fun. It's remarkably morish and I like nothing more than a tedious argument with autoconf macros. Working with lots of enthusiastic people from other teams, helping getting the port set up and build has been great - thank you everybody. (Wookey)
And here are random exciting things that were listed:
- build-profile support (for bootstrapping) is all in jessie (dpkg, apt, sbuild, python-apt, debhelper, libconfig-model-dpkg-perl, lintian).
- PointCloudLibrary (PCL) got migrated from Ubuntu to Debian
- Long Term Support has arrived!
- Debian is participating for the second time in OPW as mentor orga
- ftp-master is getting an API
- cross-toolchains for jessie are available
- arm64/ppc64el ready to go into jessie
- wheezy-backports is more useful and used than ever
- we froze, in time, with a remarkably low RC bug count, and we have a concrete plan for getting from that to a release
cryptsetup password and parallel boot
Since parallel boot happened, during boot the cryptsetup password prompt in my system gets flooded with other boot messages.
Besides showing pretty pictures (and most importantly, getting them out of my
way if I press
ESC), plymouth also provides a user prompt that works with
which sounds like what I needed.
Alternate rescue boot entry with systemd
Since systemd version 215, adding
systemd.debug-shell to the kernel command
line activates the debug shell on tty9 alongside the normal boot. I like the
idea of that, and I'd like to have it in my standard 'rescue' entry in my grub
Unfortunately, by default
update-grub does not allow to customize the rescue
menu entry options. I have just filed #766530
hoping for that to change.
After testing the patch I proposed for
/etc/grub.d/10_linux, I now have this
/etc/default/grub, with some satisfaction:
GRUB_CMDLINE_LINUX_RECOVERY="systemd.log_target=kmsg systemd.log_level=debug systemd.debug-shell"
Thanks to sjoerd and uau on #debian-systemd for their help.
I've just stumbled on this bit that seems relevant to me:
Insist on using objective criteria
The final step is to use mutually agreed and objective criteria for evaluating the candidate solutions. During this stage they encourage openness and surrender to principle not pressure.
I find the concept of "pressure" very relevant, and I like the idea of discussions being guided by content rather than pressure.
I'm exploring the idea of filing under this concept of "pressure" most of the things described in code of conducts, and I'm toying with looking at gender or race issues from the point of view of making people surrender to pressure.
In that context, most code of conducts seem to be giving a partial definition of "pressure". I've been uncomfortable at DebConf this year, because the conference PG12 code of conduct would cause me trouble for talking about what lessons can Debian learn from consent culture in BDSM communities, but it would still allow situations in which people would have to yield to pressure, as long as the pressure was done avoiding the behaviours blacklisted by the CoC.
Pressure could be the phrase "you are wrong" without further explanation, spoken by someone with more reputation than I have in a project. It could be someone with the time for writing ten emails a day discussing with someone with barely the time to write one. It could be someone using elaborate English discussing with someone who needs to look up every other word in a dictionary. It could be just ignoring emails from people who have issues different than mine.
I love how the Diversity Statement is elegantly getting all this where it says: «We welcome contributions from everyone as long as they interact constructively with our community.»
However, I also find it hard not to fall back to using pressure, even just for self-preservation: I have often found myself in the situation of having the responsibility to get a job done, and not having the time or emotional resources to even read the emails I get about the subject. All my life I've seen people in such a situation yell "shut up and let me work!", and I feel a burning thirst for other kinds of role models.
A CoC saying "do not use pressure" would not help me much here, but being around people who do that, learning to notice when and how they do it, and knowing that I could learn from them, that certainly would.
If you can link to examples, I'd like to add them here.
Laptop, I demand that you suspend!
Sometimes some application prevents suspend on my laptop. I want to disable that feature: how?
I understand that there may exist some people who like that feature. I, on the other hand, consider a scenario like this inconceivable:
- I'm on a plane working with my laptop, the captain announces preparations for landing, so I quickly hit the suspend button (or close the lid) on my laptop and stow it away.
- One connecting flight later, I pick up my backpack, I feel it unusually hot and realise that my laptop has been on all along, and is now dead from either running out of battery or thermal protection.
- I think things that, if spoken aloud in front of a pentacle, might invoke major lovecraftian horrors.
I do not want this scenario to ever be possible. I want my suspend button to suspend the laptop no matter what. If a process does not agree, I'm fine with suspending it anyway, or killing it.
If I want my laptop to suspend, I generally have a good enough real-world reason for it, and I cannot conceive that a software could ever be allowed to override my command.
How do I change this? I don't know if I should look into systemd, upowerd, pm-utils, the kernel, the display manager or something else entirely. I worry that I cannot even figure where to start looking for a solution.
This happened to me multiple times already, and I consider it ridiculous. I know that it can cause me data loss. I know that it can cause me serious trouble in case I was relying on having some battery or state left at my arrival. I know that depending on what is in my backpack, this could also be physically dangerous.
So, what knob do I tweak for this? How do I make suspend reliable?
Systemd has an inhibitor
systemd-inhibit --list only lists 'delay' blocks in my system. It
is an interesting feature that seems to be implemented in the right way, and it
could mean that I finally can get my screen to be locked before the system is
It is possible to configure the inhibitor system in /etc/systemd/logind.conf, including ways to ignore inhibitors, and a maximum time after which inhibitors are ignored if not yet released.
Try as I might to run everything that I was running on the plane that time, I could not manage to see anything take an inhibitor block that could have prevented my suspend. I now suspect that what happened to me was a glitch caused by something else (hardware? kernel? cosmic rays!) during that specific suspend.
When I had this issue in the past it looks like the infrastructure at the time was far more primitive that what we have now with systemd, so I guess that when writing my blog post I had simply correlated my old experiences with a one-off suspend glitch.
If I want to investigate or tune further, to test the situation with a runaway
block, I can use commands like
systemd-inhibit --mode=block sleep 3600.
I'm quite happy to see that we're moving to a standard and sane system for
this. In the meantime, I have learnt that
pm-utils has now become superfluous
and can be deinstalled, and so can
Thanks vbernat, mbiebl, and ah, on #debian-devel for all the help.
Good relationships are like a good video game
with an easy, intuitive interface
and lots of interesting content.
Fear of losing
If I am afraid of breaking my laptop, then I may leave it at home, and it will be as if I didn't have a laptop.
If I am afraid of losing faith, then I may closely follow the dictates of the church. I will be keeping the church's faith, but not mine.
If I am afraid of losing my children, they may have to run away from me to be free to grow into adults.
If I am afraid of losing my inner child, then I might not expose it to the world, and so my inner child will never live. I will just be a box, a mask of what the world expects from me, that shelters and cages the Me that would like to live.
If I am afraid of losing you, then I may get obsessed with preserving the beautiful image I have of you. I may stop seeing, experiencing you as you live, think, grow. I may become afraid of your depth, of your being different each day, of your being alive. I may end up with cherishing a perfect image of you in my head, while you will have become a stranger to me.
I am really asking when I can accept answers.
I am really living when I can accept myself.
I am really loving when I can accept you.