Entries for Planet Debian.
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.
We like perfection.
Perfection is the ultimate achievement, there is nothing beyond.
Perfection is fully understood. It is not going to change, it is fact, we can rely upon it.
Perfection is final. Perfection is death.
Ideas can be perfect, and perfect ideas are easy to understand.
Perfect ideas are final and unchangeable. Perfect ideas are hard to correct, hard to refute.
Perfect ideas spread easily. They are helpful. They shed light on a little corner of our world, give it shape. They bring stability. They can be relied upon. Perfect ideas make good memes.
Perfect ideas are shared standards through which we act, interact, coordinate, cooperate. They don't change, so they are a solid base for habits, that make a bit of our life a little easier.
Thanks Lynoure for saying the right thing at the right time.
When I said "I love you"
All people ever say is: thank you (a celebration of life) and please (an opportunity to make life more wonderful). Marshall Rosenberg
I have said "I love you" many times in my life, and many times I have failed to say it, because, for me, it is not an easy thing to say.
It is not easy when I have no idea what the other person will make of it: will they be frightened? Will they feel awkward around me afterwards? Will they disappear from my life?
But do I know what I myself mean when I say it?
I have said "I love you" because I thought you somehow expected it of me. "please, consider me worth of you".
I have said "I love you" to beg for affection. "please, love me back".
I have said "I love you" because I was grateful to you for existing in my life. "thank you".
I now understand why it has not been easy for me to say "I love you" when I was feeling, or imagining, that I had to say it.
I now understand why I have sometimes made myself awkward, as I was begging.
I now understand why, when I said "I love you" out of gratitude, when I said it to celebrate that you exist in my life, that's when I felt no trouble, no fear, and when I felt that my words really were fitting with what I was feeling and what I was wanting to say.
Wheezy for industrial software development
I'm helping with setting up a wheezy-based toolchain for industrial automation.
The basic requirements are: live-build, C++11, Qt 5.3, and a frozen internal wheezy mirror.
This is Italy, and you can't simply download 21Gb of debs just to see how it goes.
Stable toolchains for C++11 now exist and have gained fast adoption. It makes sense, since given what is in C++11 it is unthinkable to start a new C++ project with the old standard nowadays.
C++11 is supported by g++ 4.8+ or clang 3.3+. None of them is available on wheezy or wheezy-backports.
Backports exist of g++ 4.8 only for Ubuntu 12.04, but they are uninstallable on wheezy due at least to a different libc6. I tried rebuilding g++4.8 on wheezy but quickly gave up.
clang 3.3 has a build dependency on g++ 4.8. LOL.
However, LLVM provides an APT repository with their most recent compiler, and it works, too. C++11 problem solved!
Qt 5.3 is needed because of the range of platforms it can target. There is no wheezy backport that I can find.
I cannot simply get it from Qt's Download page and install it, since we need it packaged, to build live ISOs with it.
I'm attempting to backport the packages from experimental to wheezy.
Here are its build dependencies:
libxcb-1.10 (needed by qt5)
Building this is reasonably straightforward.
libxkbcommon 0.4.0 (needed by qt5)
The version from jessie builds fine on wheezy, provided you remove
--fail-missing from the
libicu 52.1 (needed by harfbuzz)
The jessie packages build on wheezy, provided that mentions of clang are deleted from source/configure.ac, since it fails to build with clang 3.5 (the one currently available for wheezy on llvm.org).
Backporting this is a bloodbath: the Debian packages from jessie depend on a forest of gobject hipsterisms of doom, all unavailable on wheezy. I gave up.
qtbase-opensource-src-5.3.0+dfsg can be made to build with an embedded version of harfbuzz, with just this change:
diff -Naur a/debian/control a/debian/control --- a/debian/control 2014-05-20 18:48:27.000000000 +0200 +++ b/debian/control 2014-05-29 17:45:31.037215786 +0200 @@ -28,7 +28,6 @@ libgstreamer-plugins-base0.10-dev, libgstreamer0.10-dev, libgtk2.0-dev, - libharfbuzz-dev, libicu-dev, libjpeg-dev, libmysqlclient-dev, diff -Naur a/debian/rules b/debian/rules --- a/debian/rules 2014-05-18 01:56:37.000000000 +0200 +++ b/debian/rules 2014-05-29 17:45:25.738634371 +0200 @@ -108,7 +108,6 @@ -plugin-sql-tds \ -system-sqlite \ -platform $(platform_arg) \ - -system-harfbuzz \ -system-zlib \ -system-libpng \ -system-libjpeg \
(thanks Lisandro Damián Nicanor Pérez Meyer for helping me there!)
There are probably going to be further steps in the Qt5 toolchain.
Actually, let's try prebuilt binaries
The next day with a fresh mind we realised that it is preferable to reduce our
tampering with the original wheezy to a minimum. Our current plan is to use
wheezy's original Qt and Qt-using packages, and use Qt's prebuilt
/opt for all our custom
We run Qt's installer, tarred the result, and wrapped it in a Debian package like this:
$ cat debian/rules #!/usr/bin/make -f QT_VERSION = 5.3 %: dh $@ override_dh_auto_build: dh_auto_build sed -re 's/@QT_VERSION@/$(QT_VERSION)/g' debian-rules.inc.in > debian-rules.inc override_dh_auto_install: dh_auto_install # Download and untar the prebuild Qt5 binaries install -d -o root -g root -m 0755 debian/our-qt5-sdk/opt/Qt curl http://localserver/Qt$(QT_VERSION).tar.xz | xz -d | tar -C debian/our-qt5-sdk/opt -xf - # Move the runtime part to our-qt5 install -d -o root -g root -m 0755 debian/our-qt5/opt/Qt mv debian/our-qt5-sdk/opt/Qt/$(QT_VERSION) debian/our-qt5/opt/Qt/ # Makes dpkg-shlibdeps work on packages built with Qt from /opt # Hack. Don't try this at home. Don't ever do this unless you # know what you are doing. This voids your warranty. If you # know what you are doing, you won't do this. find debian/our-qt5/opt/Qt/$(QT_VERSION)/gcc_64/lib -maxdepth 1 -type f -name "lib*.so*" \ | sed -re 's,^.+/(lib[^.]+)\.so.+$$,\1 5 our-qt5 (>= $(QT_VERSION)),' > debian/our-qt5.shlibs $ cat debian-rules.inc.in export PATH := /opt/Qt/@QT_VERSION@/gcc_64/bin:$(PATH) export QMAKESPEC=/opt/Qt/@QT_VERSION@/gcc_64/mkspecs/linux-clang/
To build one of our packages using Qt5.3 and clang, we just add this to its debian/rules:
We got the dependencies sorted. Hopefully the mirror will rebuild itself tonight and tomorrow we can resume working on our custom live system.
I feel like in my Debian projects I have two roles: the person with the responsibility of making the project happen, and the person who does the work to make it happen.
As the person responsible for the project, I need to keep track of vision, goals, milestones, status. To make announcements, find contributors, motivate them, deal with users and bug reports, maintain documentation, digest feedback.
As the person who does the work to make it happen, I need quiet time, I need to study technology, design code, write unit tests, merge patches, code, code, code, ask around about deployment information, more code.
I have a hard time doing both things at the same time: the first engages my social skills and extroversion, requires low-latency interaction, and acting when outside things happen. The second engages my technical skills and introversion, requires quiet uninterrupted periods of flow, and acting when inspiration strikes. I never managed to make good use of "gift bugs" or "minions": I often found the phrase "it's easier for me to do than to explain it" sadly relevant. Now I understand that it's not because of the objective difficulty of explaining or doing things, nor about the value of doing or of involving people. It's about switching from one kind of workflow to another. If I rephrase that as "it's easier for me to stay in flux and fix it, than to switch my entire attitude to ask for help".
Of course this does not scale: we've all been saying it since I can remember.
Looking at the situation from the point of view of those two roles, however, I now wonder if those two roles shouldn't really require two people. In other worlds they are: the project managers, taking responsibility for making the project happen, and the software designers, artists, and all other kind of artisans doing the work to make it happen.
Of course I don't want the kind of project manager that shifts responsibilities to artisans, does nothing and takes the credit for the project: not in paid work, not in Debian.
I would be interested instead in having the kind of project manager that takes responsibility for the project, checks how the artisans are doing and communicates what is happening to the rest of the world, deals with the community, motivates more people to help, test, try, use, give feedback on things as they happen. A project manager / community manager.
So that while I'm flux there is someone who tags bugs as "gift", mentors people to find code and documentation, and remembers to write an announcement if I implemented three cool things in a row and I'm already busy working on the fourth.
So that I don't write cool ideas in my todo list where nobody can read them, but I can share them to a mailing list where someone picks up a relevant one and finds someone to make it happen while I'm busy refactoring old code that only I can understand.
So that if I say "sorry, paid work calls, I won't be able to work on this project for a month", I'll be able to completely forget about that project for a whole month, without leaving the community out there to die.
That's an interesting job for non-uploading DDs: please take over my projects. Let's share a vision, and team up to make it happen. Give me the freedom of being the craftsman I enjoy being, and take away from me those responsibilities that I've never asked for.
The worst project managers are those that never asked to be one, but were promoted to it. Let's not repeat that mistake in Debian.
A good part of the credits for this post go to Francesca Ciceri, for the discussions we had on our way back from MiniDebConf Barcelona 2014.
P.S. I'm seeing how a non-uploading DD could be in the Maintainer field for one or more packages, with uploading DDs being, well, uploaders. Food for thought.