Planet Debian

Subscribe to Planet Debian feed
Planet Debian -
Updated: 39 min 29 sec ago

Joey Hess: counterpoint on Yahoo Groups archiving

10 December, 2019 - 04:53

Yahoo Groups being shut down and the data deleted is a big enough story that it's being talked about on the radio. The typical presentation is that they're deleting these mailing list archives, and blocking attempts to save them and so huge amount of things will be lost from the historical record.

That's a common story these data, but it's not entirely accurate in this case. These are mailing lists, so they're not necessarily only archived by Yahoo. Anyone who subscribed to a mailing list may have archived it. I've been on a couple of those mailing lists, and the emails I kept from them are already archived rather well (10+ copies). I probably didn't keep every email, and I probably won't be exhuming those emails to add them to some large collection of Yahoo Groups. But multiply all the people who subscribed to these lists by all the traffic to them, by the probability that people keep copies of mailing list mails, and there's a huge, well-distributed archive of Yahoo Groups out there.

That ensures some of it will survive in the historical record, probably enough to satisfy a historian.

Probably even after Gmail and the other cloud mail services shut down and delete all their archives.

Previously: I am ArchiveTeam (but not speaking for them above)

Chris Lamb: Tour d'Orwell: Marrakesh

10 December, 2019 - 03:56

(Previously in George Orwell-themed travel posts: Hampstead, Paris, Southwold, Ipswich…)

In the winter of 1938, Orwell travelled to Marrakech in Morocco — one R in the latter yet two in the former — in an attempt to quell the tuberculosis that would take his life in 1950. Like his Parisian apartment he was not quite the fan, writing that:

When you walk through a town like this, when you see how the people live and still more how easily they die it is always difficult to believe that you are walking among human beings.

Whilst reading this curiously fragmented essay during my own sojourn in the souq (entitled simply Marrakech) it becomes particulary purplexing that it was during this very stay (where "life is an endless struggle" and flies swarm over corpses covered only in rags passing in the street) that Orwell wrote Coming Up for Air. Set in the antebellum period prior to the First World War, his fourth novel displays a number of features that were already becoming recurring themes in his output, including an unromantic but nostalgic love of the workings of the countryside (reaching its apotheosis Animal Farm), pessimism towards advertising and modern concrete buildings (Keep the Aspidistra Flying) as well as a dislike of mechanical political speech (Politics and the English Language). At one point the protagonist visits a Left Book Club meeting and asserts:

These chaps can churn it out by the hour. Just like a gramophone. Turn the handle, press the button and it starts.

Whilst the ventriloquisation of the author's own sentiments are a little too transparent here, less obvious are the physical ailments being adopted as literary symbols — George Bowling's false teeth clearly mirror Winston Smith's varicose ulcer in Nineteen Eighty Four, both revealed within their respective opening paragraphs.

Returning to his Marrakech essay, Orwell is not best known for his humour but even in these supposedly torrid surroundings his wit and acumen were recorded for those with a keen eye: upon noting (in 1938) the robust 13,000-strong Jewish population, he remarks dryly that it is a "good job Hitler isn't here".

Philipp Kern: Voting for systemd

10 December, 2019 - 03:19
I have voted putting Proposal F first, Proposal B second and everything else after Further Discussion. I think if something truly better than systemd comes around, people in Debian will not stand in the way of people making it work - even despite this GR passing. That's how systemd started out after all. But the fact that we also want to support inferior old ways holds us back.

At the point where Debian decided on the question of upstart vs. systemd, to me upstart was not a valid contender anymore. I had to deal professionally with it and no-one really know how to hold it in the right way so that modifications to upstart jobs did not break the boot. For systemd - despite the complexity everyone mentions as the problem - I only recall one major one where a certain machine type did not boot anymore and that was actually due to a regression in udev. If we would be discussing this as we debate the next serious contender to systemd, I would vote differently. Proposal F, being a statement about development du jour, thus makes sense to me. We should aim for the best possible integration with what we have. While I acknowledge that others try to keep old things working, they should also not hold the distribution hostage to a lofty "only if you provide two implementations you can use a feature". A distribution is always opinionated. We pick a default C library, a default compiler, a default desktop environment, a default installer. Some people prefer to diverge from that and within boundaries we support this. To be honest, as an example: If sysvinit had active maintainers, they could come up with technical solutions to provide missing init scripts from sysvinit. systemd started off no differently, overriding some of the init scripts using unit files. There are only few points of centralized contention that everyone needs to agree on (for instance as a pre-depends of the init metapackage). Most notably the systemd maintainers carefully worked through all of these issues of being a parallel init system and did not pressure others (again maybe except for few centralized touchpoints).

A distribution without deep systemd integration is just unappealing to me at this point. It's a well working system with excellent documentation in the form of manpages that's easy enough to coerce to do my bidding in a non-surprising way. Limiting ourselves to units autogenerated from init scripts is not cool and just makes the whole thing harder to debug as there are non-obvious moving pieces in shell scripts. Plus we cannot actually benefit from the other improvements like hardening you can just flip on with a flag and declarative configuration of users and temporary files and directories. Let's not forget that there are still people trying to argue that a dependency on libsystemd is not ok - a library that effectively does not do anything when systemd is not active, while we accepted many other somewhat fringe libraries as core (libselinux) in an opinionated distribution. If the argument is that packages behave different under compilation with systemd support that is probably something that can be addressed with patches or those active maintainers need to come up with alternative approaches to spawn things the new way within their ecosystem. For instance by fixing inetd to do the right thing for socket-activated services.

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

10 December, 2019 - 00:36
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


Enrico Zini: JavaScript and Mobile Apps links

9 December, 2019 - 18:00
ES2015+ cheatsheet js devel 2019-12-09 One-page guide to ES2015+: usage, examples, and more. A quick overview of new JavaScript features in ES2015, ES2016, ES2017, ES2018 and beyond. ECMAScript 6: New Features: Overview and Comparison js devel 2019-12-09 Learn ES2015 · Babel js devel 2019-12-09 Service Workers: an Introduction  |  Web Fundamentals js devel 2019-12-09 Rich offline experiences, periodic background syncs, push notifications—functionality that would normally require a native application—are coming to the web. Service workers provide the technical foundation that all these features rely on. ServiceWorker Cookbook js devel 2019-12-09 The Service Worker Cookbook is a collection of working, practical examples of using service workers in modern web sites. Using Service Workers js devel 2019-12-09 One overriding problem that web users have suffered with for years is loss of connectivity. The best web app in the world will provide a terrible user experience if you can’t download it. There have been various attempts to create technologies to solve this problem, as our Offline page shows, and some of the issues have been solved.

Russell Coker: systemd-nspawn and Private Networking

9 December, 2019 - 09:10

Currently there’s two things I want to do with my PC at the same time, one is watching streaming services like ABC iView (which won’t run from non-Australian IP addresses) and another is torrenting over a VPN. I had considered doing something ugly with iptables to try and get routing done on a per-UID basis but that seemed to difficult. At the time I wasn’t aware of the ip rule add uidrange [1] option. So setting up a private networking namespace with a systemd-nspawn container seemed like a good idea.

Chroot Setup

For the chroot (which I use as a slang term for a copy of a Linux installation in a subdirectory) I used a btrfs subvol that’s a snapshot of the root subvol. The idea is that when I upgrade the root system I can just recreate the chroot with a new snapshot.

To get this working I created files in the root subvol which are used for the container.

I created a script like the following named /usr/local/sbin/container-sshd to launch the container. It sets up the networking and executes sshd. The systemd-nspawn program is designed to launch init but that’s not required, I prefer to just launch sshd so there’s only one running process in a container that’s not being actively used.


# restorecon commands only needed for SE Linux
/sbin/restorecon -R /dev
/bin/mount none -t tmpfs /run
/bin/mkdir -p /run/sshd
/sbin/restorecon -R /run /tmp
/sbin/ifconfig host0 netmask
/sbin/route add default gw
exec /usr/sbin/sshd -D -f /etc/ssh/sshd_torrent_config
How to Launch It

To setup the container I used a command like “/usr/bin/systemd-nspawn -D /subvols/torrent -M torrent –bind=/home -n /usr/local/sbin/container-sshd“.

First I had tried the --network-ipvlan option which creates a new IP address on the same MAC address. That gave me an interface iv-br0 on the container that I could use normally (br0 being the bridge used in my workstation as it’s primary network interface). The IP address I assigned to that was in the same subnet as br0, but for some reason that’s unknown to me (maybe an interaction between bridging and network namespaces) I couldn’t access it from the host, I could only access it from other hosts on the network. I then tried the --network-macvlan option (to create a new MAC address for virtual networking), but that had the same problem with accessing the IP address from the local host outside the container as well as problems with MAC redirection to the primary MAC of the host (again maybe an interaction with bridging).

Then I tried just the “-n” option which gave it a private network interface. That created an interface named ve-torrent on the host side and one named host0 in the container. Using ifconfig and route to configure the interface in the container before launching sshd is easy. I haven’t yet determined a good way of configuring the host side of the private network interface automatically.

I had to use a bind for /home because /home is a subvol and therefore doesn’t get included in the container by default.

How it Works

Now when it’s running I can just “ssh -X” to the container and then run graphical programs that use the VPN while at the same time running graphical programs on the main host that don’t use the VPN.

Things To Do

Find out why --network-ipvlan and --network-macvlan don’t work with communication from the same host.

Find out why --network-macvlan gives errors about MAC redirection when pinging.

Determine a good way of setting up the host side after the systemd-nspawn program has run.

Find out if there are better ways of solving this problem, this way works but might not be ideal. Comments welcome.

Related posts:

  1. Ethernet Interface Naming With Systemd Systemd has a new way of specifying names for Ethernet...
  2. systemd – a Replacement for init etc The systemd projecct is an interesting concept for replacing init...
  3. Systemd Notes A few months ago I gave a lecture about systemd...

Joey Hess: left handed scissors

9 December, 2019 - 00:04

They return my hand's grasp, smotheringly close. Was this how it was meant to feel, in a classroom cutting multi-colored construction paper? Not a pain to be gotten through, but comfort, closeness, togetherness. Their design now feels aggressively overdone, broad curve just so around the thumb, as if they might tighten and snap it off. Only too large index finger's knuckle, chafing, provides some relief, some reminder that I shouldn't run.

(Thanks, liw.)

Bernd Zeimetz: Public service annoucement for a modern Debian

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

Ruby Team: Update to packaging the Jekyll import tool

8 December, 2019 - 07:34

For moving my personal blog away from blogger I’ve put a lot of work into packaging and/or updating (the most common) Jekyll plugins for Debian. To ease the work further I began to package the Jekyll importers. But they need some (yet) unpackaged gems. So I’ve created an issue to track the progress and put my work on this package on hold. Yesterday @utkarsh2102-guest contacted me and asked me for more details. So I’ve spent the last hours to track down what actually needs to be done. And the news are a lot better than expected.

Only fastercsv, reverse_markup, behance and unidecode must be packaged as (runtime dependencies).

Using jekyll-import right now with bundler

If you are in need of these importers you can use this Gemfile:

source ""

gem "jekyll-import"

then set GEM_HOME to somewhere you are allowed to write to (e.g. $HOME/.gem/) and run bundle install on the Gemfile:

$ export GEM_HOME=$HOME/.gem/
$ bundle install

Then write your importer (mine) and run it with ruby.

Using jekyll-import right now mixing Debian packages and bundler

If you want to minimize the installation of non-Debian provided gems you probably want to run this on Debian Sid:

$ apt-get install ruby-public-suffix ruby-concurrent ruby-eventmachine \
                  ruby-ffi ruby-rb-inotify ruby-listen ruby-nokogiri \
                  ruby-bundler ruby-concurrent ruby-http-parser.rb ruby-sass \
                  ruby-forwardable-extended jekyll

This installs all the necessary ruby packages. Then run bundle install on the following Gemfile:

source ""

# This will help ensure the proper Jekyll version is running.
gem "jekyll", "~>"

# This will ensure we use the ruby packages in Sid.
gem "concurrent-ruby", "~>"
gem "eventmachine", "~>"
gem "ffi", "~>"
gem "listen", "~>"
gem "nokogiri", "~>"
gem "pathutil", "~>"
gem "public_suffix", "~>"
gem "rb-inotify", "~>"

# This will install jekyll-import.
gem "jekyll-import"

Charles Plessy: I voted

8 December, 2019 - 06:57

While the vote on init systems was being prepared, I thought about proposing an option telling that this vote is not necessary, and reminding that general resolutions should be used with parcimony, like in 2014. However, I then remembered that a) Sam was elected on a platform proposing more votes, and b) I proposed something similar in the elections in 2010...

Nevertheless, I am crushed under the number of options. Their texts are long, sometimes very similar, and do not separate clearly the normative from the preambles. Like in a parody of the dysfunctions of modern democracies, I ended up considering only the proposals written or seconded by people with whom I feel in phase. I have not voted for the others, which ranks them equally under « further discussion ».

Enrico Zini: Stopping libreoffice

8 December, 2019 - 06:00

This is part of a series of post on the design and technical steps of creating Himblick, a digital signage box based on the Raspberry Pi 4.

We've started implementing reloading of the media player when media on disk changes.

One challenge when doing that, is that libreoffice doesn't always stop. Try this and you will see that the presentation keeps going:

$ loimpress --nodefault --norestore --nologo --nolockcheck --show example.odp
$ pkill -TERM loimpress

It turns out that loimpress forks various processes. After killing it, these processes will still be running:

/usr/lib/libreoffice/program/oosplash --impress --nodefault --norestore --nologo --nolockcheck --show talk.odp
/usr/lib/libreoffice/program/soffice.bin --impress --nodefault --norestore --nologo --nolockcheck --show talk.odp

Is there a way to run the media players in such a way that, if needed, they can easily be killed, together with any other process they might have spawned meanwhile?


Yes there is: systemd provides a systemd-run command to run simple commands under systemd's supervision:

$ systemd-run --scope --slice=player --user  loimpress --nodefault --norestore --nologo --nolockcheck --show media/talk.odp

This will run the player contained in a cgroup with a custom name, and we can simply use that name to stop all the things:

$ systemctl --user stop player.slice

Ian Jackson: Debian init systems GR - voting guide

8 December, 2019 - 03:30

If you don't know what's going on, you may wish to read my summary and briefing blog post from a few weeks ago. There are 7 options on the ballot, plus Further Discussion (FD). With this posting I'm trying to help voting Debian Members (Debian Developers) cast their votes.

I am going to be neutral about the technical merits of systemd. My advice does not depend on your opinion about that.

So my advice here is addressed to people who like systemd and want to keep running it, and developing with it, as well as, of course, people who prefer not to use systemd. I'm even addressing readers who think systemd has useful features which they would like Debian packages to be able to use.

However, I am going to be opinionated about one key question: My baseline is that Debian must welcome code contributions to support running without systemd, just as it welcomes code contributions for other non-default setups. If you agree with that principle, then this posting is for you. Unfortunately this principle is controversial. Several of the options on the current GR mean rejecting contributions of non-systemd support. So in that sense I am not neutral.


(Using # to indicate the "Choice" numbers on the ballot.)

Rank H (#5), D (#4) and E (#6) ahead of all other options unless you can't accept the "portability" principles in H (#5), or can't accept the MUST in E (#6). For more on D vs E vs H, see below.

Do not be fooled by A (#3) which sounds like it actually answers the question, with a compromise. But making these bugs "important" does not have any practical effect. It just sets us up for more arguments. A also enables continuation of blocking behaviours by maintainers who want to support only systemd - probably more than G (#7) does. Both A and G are poor in their practical effect, but I would rank G ahead of A, unless you really disagree with the Principles in G.

Summary of the options

Ordered from strongest support for contributors of non-systemd support, and users who don't want to use systemd, to weakest. H (#5) is the Principles part of G (#7) pasted onto the front of the specific decisions in D (#4) - the similar-looking texts are identical.

#6 E Dmitry Packages MUST work on non-systemd systems #5 H Ian Portability and multiple implementations, "without blocking progress" #4 D Ian Compromise, "Support non-systemd systems, without blocking progress" #7 G Guillem Portability and multiple implementations, avoids giving any guidance on specifics. Options below here will mean that systemd becomes effectively mandatory for most users and developers #3 A Sam Vaguely positive words, but maintainers can (and some will) block non-systemd support. Fudge, not compromise. Sets us up for more arguments. #2 B Sam Encourages adoption of systemd features #1 F Michael Support only systemd, encourages tighter systemd integration Voting flowchart

You should probably vote H (#5), D (#4) and E (#6) ahead of all the other options, in some order or other For more details, and the exceptions, read on.

Q1 - Non-systemd support mandatory ?

Do you think support for non-systemd systems should be mandatory - ie that maintainers of leaf packages should be required to write init scripts, etc ?

Yes, maintainers should do the work to support non-systemd init systems.
Rank: E > H+D. (# 6 > 5+4. )
No, the non-systemd commmunity should do this work.
Rank: H+D > E. (# 5+4 > 6. )
How far down you put E depends how strongly you feel about this. I have assumed in the rest of this posting that you think the principle that the non-systemd community should be allowed to do this work is more important than the principle that other people shouldn't be required to do it. If you don't agree, you should rank E (#6) lower than the suggestions I make in the rest of this post.
Q2 - Discussion closure

How much do you care that we settle this matter once and for all? (compared to valuing accepting contributions, and thereby enabling variety in software, flexibility, portability, Debian's centrality, and so on)

Accepting contributions is more important. I expect the non-systemd community to keep using, supporting (and working on) non-systemd regardless, even if Debian makes it difficult, and in a downstream if necessary.
Rank: H+D+E > G > A > FD > B > F. (# 5+4+6 > 7 > 3 > 8 > 2 > 1. )
I want closure somewhat. If we have support in principle, I am prepared to have to revisit some of the details in another GR and/or escalate individual bugs to the Technical Committee (TC). Otherwise we should just make systemd mandatory and be done with it.
Rank: H+D+E > G > A > F > B > FD. (# 5+4+6 > 7 > 3 > 1 > 2 > 8. )
I want closure very much. I want this settled once and for all. (But I would rather have one more GR than a bunch of TC fights over individual bugs.)
Rank: H+D+E > F > FD > B > G > A. (# 5+4+6 > 1 > 8 > 2 > 7 > 3. )
NB the Rank listings here here are subject to Q3, regarding G (#7), and Q1, regarding E (#6).

You may be surprised that I suggest ranking G (#7) ahead of A (#3) even if you very much want closure, despite G's lack of any detailed guidance. This is because I think both A and G would lead to many arguments about details, but G provides clearer principles for resolving those arguments - so there would be fewer of them and they will be less bad. A also leaves much more open the possibility of a renewed attempt to desupport non-systemd systems via another GR. You may very well disagree with me on this, in which case you will want to rank A ahead of G; however I would still advise against ranking A highly.

Q3 - "Glue", portability and multiple implementations

Do you agree with the Principles at the top of proposals G (#7) and H (#5) ? Do you see the init systems debate as part of a pattern and think this is something the project needs to make a more general statement about ?

I like this vision for Debian as the universal operating system.
Rank: H > D. (# 5 > 4. )
I have concerns about making such a strong general statement, or this is a distraction which unnecessarily broadens the debate; but I can live with it if the practical results are right for init systems.
Rank: D > H. (# 4 > 5. )
Probably keep G (#7) ahead of A (#3). If you want the arguments to be over, both are poor.
I disagree with this vision and do not want it as part of the winning option.
Rank: D > H. (# 4 > 5. )
You may wish to demote H (#5) and G (#7) below other options, perhaps even below FD or A (#3). I would caution against demoting H (#5), too far, because several of those other options answer the specific init systems question badly or not at all. Consider whether you can live with this rather woolly vision text if it means the init systems arguments are ended satisfactorily.
Voting table

Q1: Maintainers must support non-systemd Q1: Non-systemd community should do the work "portability" vision I like it I have concerns I like it I have concerns Q2: Must accept contribs E H D G A FD B F
Choice 6 5 4 7 3 8 2 1 E D H* G* A FD B F
Choice 6 4 5* 7* 3 8 2 1 H D E G A FD B F
Choice 5 4 6 7 3 8 2 1 D H* E G* A FD B F
Choice 4 5* 6 7* 3 8 2 1 Q2: Want closure somewhat E H D G A F B FD
Choice 6 5 4 7 3 1 2 8 E D H* G* A F B FD
Choice 6 4 5* 7* 3 1 2 8 H D E G A F B FD
Choice 5 4 6 7 3 1 2 8 D H* E G* A F B FD
Choice 4 5* 6 7* 3 1 2 8 Q2: Want closure very much E H D F FD B G A
Choice 6 5 4 1 8 2 7 3 E D H* F FD B G A
Choice 6 4 5* 1 8 2 7 3 H D E F FD B G A
Choice 5 4 6 1 8 2 7 3 D H* E F FD B G A
Choice 4 5* 6 1 8 2 7 3

* If you really dislike the Principles in G (#7), you may wish to rank it, and maybe H (#5), lower. See also my comments in Q1 about the MUST in E (#6).

Detailed analysis of the options

I have dealt with this by theme, rather than going through the options one by one.

Overall framing and vision

E (#6)
Supporting non-systemd init systems is simply and clearly required. No wider philosophical points.
H (#5)
Strong general principles about Debian's central "glue" role, combined with detailed rules of engagement for stopping dysfunctional blocking behaviours. (Operative text is from D; principles are from G.)
D (#4)
Contributions of work, both to support non-systemd systems, and systemd, should be welcomed, but init system communites must do their own work. Detailed rules of engagement for stopping dysfunctional blocking behaviours.
G (#7)
Strong general principles about Debian's central "glue" role, support for portability, and so on. Deliberately avoids giving specific guidance; instead has some extremely vague words about being respectful.
A,B (#3,2)
Hard to discern a clear vision.
F (#1)
Claims that systemd is for "cross-distro collaboration". What this means is mainly collaboration on desktop operating systems with RPM-based distros, notably Red Hat. But it will actually hinder or prevent collaboration with (for example) GNU Guix, embedded operating systems, non-Linux operating systems such as FreeBSD, and even other distros like Gentoo or our own downstreams like Devuan. So the sense of "cross-distro collaboration" meant here is much narrower than it seems.
Clarity, vision and consequences

E (#6)
Admirably clear and straightforward. Non-systemd systems will be properly supported; some strong systemd supporters may go to work elsewhere. No wider implications.
H (#5)
Addresses specific situations relating to init systems in detail. If it is followed, the atmosphere should improve. Additionally, I find the clarity of vision attractive. Adopting it may preempt or help settle other disputes.
D (#4)
Addresses specific situations in detail (and thus rather long). If it is followed, the atmosphere should improve and we can get on with programming.
G (#7)
Clear statement of principles, undermined by an explicit refusal to give specific guidance; instead there is some extremely vague text about being respectful and compromising. In practice if this wins we are likely to continue to have a lot of individual fights over details. Despite the strong words in favour of portability etc., some maintainers are still likely to engage in blocking behaviours which will have to be referred to the TC.

Another GR is a possibility. At least, G winning now would make it look unlikely that that 2nd GR would completely de-support non-systemd, so that 2nd GR will hopefully be on a narrower question and less fraught: it will have to give the answers to details that G lacks.

A (#3)
Looks like it supports working with different init systems. It also looks like it gives specific answers. It declares that systemd-only is an "important" bug, and discusses NMUs. But NMUs are only permitted "according to the NMU guidelines" - which means that maintainers can block them simply by saying they don't like the patch. The only escalation route for an "important" bug where the maintainer does not want to take the patch is the TC. TC disputes are generally very unpleasant, especially if (as in this case) the decision involves a conflict between the interests of different communities, and the underlying principles are in dispute.

Unlike G (#7), there is no statement of broader principles that would discourage a maintainer from blocking in this way (and would narrow a TC debate by de-legitimising the kinds of very weak arguments often presented to justify these blocking behaviours). The result will be a continuation of the existing situation where some maintainers are deleting init scripts and/or rejecting patches to support non-systemd. So there will be further fights over details, probably more even than with G (#7).

I would expect another GR at some point; that 2nd GR would probably involve a renewed attempt to de-support non-systemd systems. So I think this provides even less of a clear decision than G.

B,F (#2,1)
In the short term, Debian contributors and users who don't like systemd may switch to Devuan instead (or simply shrug their shoulders and reduce their engagement). In the medium to longer term, Debian's narrowing of focus will make it less attractive for its current variety of interesting use cases. Debian's unwillingness to let people within Debian forge their own path will make it less fun.

Are init scripts required and who must write them?

Actually, init scripts are really just an example. All of the proposals treat other kinds of leaf package support for non-systemd init systems in a roughly similar way.

E (#6)
init scripts are mandatory. Maintainers must write them.
H,D (#5,4)
Maintainers do not have to write them, but they must accept them if they are provided (and they must not simply delete them from existing packages, as some have been doing). Ie, the non-systemd community must write them if it wants them where they are currently missing.
G (#7)
No guidance. We might hope that the strong words on portabilility and multiple implementations will cause constructive behaviours by the various contributors, but in practice escalation of some kind, or a further GR, will be needed.
A,B,F (#3,2,1)
Maintainers do not have to write them and do not need to accept them.
What about systemd sysusers.d, timer units, etc.

Consider for example, sysusers.d: this is a facility for creating needed system users - an alternative to our current approach of debhelper script fragments containing adduser calls. Or consider timer units, which overlap with cron. These do not necessarily imply actually running systemd; other implementations would be possible. Some people think some of these facilities are better and are unhappy that progress in Debian (particularly in Policy) has been blocked in this area.

Note that although this has been regarded by some people as being blocked by systemd sceptics, in fact it's mostly that the proponents of these facilities have not wanted to write a 2nd implementation for non-systemd systems.

E (#6)
Such facilities may only be used if there is an implementation for non-systemd systems. Effectively, this means proponents of such a facility must do the reimplementation work. But if they do, adoption of these facilities is unblocked.
H,D (#5,4)
There is a list of criteria for whether such a facility may be adopted, including feasibility of implementation for non-systemd (and non-Linux) systems, and whether the facility is any good. If a facility is approved then the non-systemd community get time (probably in practice 6 months) to reimplement the facility for their init system(s). In case of dispute the TC is to adjudicate the listed criteria.
G (#7)
No specific guidance. Formal adoption of these facilities in Policy is likely to remain blocked but uncontrolled adoption in individual packages is a real possibility.
A,B,F (#3,2,1)
Package maintainers are free to adopt these facilities in an uncoordinated way, making their packages work only with systemd. Presumably systemd Depends or Recommends would follow.
Dependencies which force (or switch) the init system

Some packages which would work fine without systemd cannot be installed, because the dependencies are overly strict. (This because of difficulties expressing the true situation in our dependency system, and what I see as largely theoretical concerns that systemd systems might come to miss parts of the systemd infrastructure.)

E,H,D (#6,5,4)
Dependencies on systemd are forbidden (E) or dependencies are not allowed to try to switch the init system (H,D). Effectively, this means that this situation is forbidden.
G (#7)
No specific guidance. This will lead to further arguments, unfortunately, since this situation is contrary to the Principles in the resolution but not clearly discussed.
A,B,F (#3,2,1)
These dependencies are to be tolerated. Core package maintainers can maintain strict dependencies even if they make running without systemd difficult or impossible.

Thanks to everyone who helped review this posting. Thanks also to the Debian Members who proposed and seconded of the options on the ballot. Everyone who helped draft, or seconded, any one of these options has helped make sure that we have a good slate of choices.

I would like particularly to thank: Russ Allbery for his review comments on my option D which substantially improved it, and his encouragement (all remaining deficiencies are of course mine); Sean Whitton and Matthew Vernon whose support and friendship have been invaluable; Guillem Jover for having an excellent vision and then being very constructive and tolerant about the way I appropriated his language; Dmitry Bogatov for providing a very clear and simple proposal and engaging with the process well; and I even want to thank Michael Biebl for drafting an option which (although I strongly disagree with it, and with its framing) clearly represents the views of the pro-systemd-integration community. And I would like to thank my friends and partners for their support, without which I could not have coped.


Shirish Agarwal: Rape, aftermath, GST

8 December, 2019 - 03:21

While I do not usually like to start with bad news, but seems bad news is the flavor of the month. We seem to be going downhill one day after that. So let’s see what happened. First there is this piece which came in Washington Post and then there was the travel advisory for women travelling by their lonesome from UK and USA . It probably applies to women, even couples for sure . I am sure it was not an easy decision to come to but they had to as they as citizens come first for them. In between my last blog post and this, couple of more horrific things happened. The first thing we came to know is the burning of the Unnao rape victim which happened on Thursday i.e. 2 days from now when I am blogging. Apparently, she had gone to give her statement in a court hearing when the 5 people burned her. It does raise questions about the quality of protection being given to her. Just to be clear, there were no reports of any of the policeman coming to any harm which makes it all the most curious.

The second horrific incident were when the 4 accused in the Hyderabad rape case were ‘encountered‘ . Curiously in this case as well, except for some slight injuries to the policeman there were no injuries. This was when there were 10 policeman accosting the 4 accused. The 4 accused have supposed to taken away all the guns, how we don’t know and still didn’t manage to fire on one of them. It raises and raised too many unanswered questions. Because of these killings, we will never know the answers. What if it turned in investigation that these were not the culprits or there was a fifth or a sixth person who was not named. There was also lot of celebration of this ‘encounter’ which seems that we are still a medieval state rather than a 21st century state. Of course when you have majoritarian narratives such as ‘Hindu Khatre mein hain‘ driving election campaigns rather than anything else than all sorts of things are possible. This is when the country is going through its worst economic history, probably parallel to 1991 although that one was more externally driven while this was is more due to internal factors rather than externals.


Apart from demonetization which was a huge disaster to the country, GST is perhaps one of the biggest badly implemented ideas in the country. Whereas, in other countries it is used as only as a single tax to be levied to the end-user stage, here it was put at very stage which instead of making it easier to use, made it much harder to use. While I had been numbed by seeing quite a few MSME units shutting down due to GST issues and mostly attributing to slow-down rather than blaming demonetization and GST, I was till surprised and shocked to find Reserved bit, a makerspace shutting down the end of the month. While Siddesh, Nisha had attributed a bit towards GST, they also shared they should have done more. While I have been to reserved-bit a few times and did find it engaging quite a bit, getting there was always an issue for me. The GST refund issue has been an eye-sore for everybody but neither the center or the state did anything for it, of course both being in BJP’s hands all this while, this is in my state Maharashtra, one of the more progressive states. The entire process of GST has been anal and had been in popular media for a while now but nobody seeks or shares any proper answers. Why, it even crashed last month and the month before that and before but nobody raises a voice.

The FM being as arrogant as ever. In such situations how startups are supposed to survive ? There were some reliefs given to start-ups but they were too small and still have a sting in their tale to be anywhere effective. Having retrospective taxes is another thing that people are afraid of and that is the reason you are not seeing people investing in new ventures. As it is, there is demand-slowdown or to put it perhaps more boldly perhaps, a demand recession while food inflation is at all-time high. While our FM wants to blame everything on externalities such as global slow-down but won’t answer as to why China is still growing faster than us without using questionable stats. which we are accused of. This is when they are 7 times larger than us in economy size and having a war with U.S. (economically) This is when conventional wisdom holds such that as you become a bigger economy your rate of growth decreases quite a lot as you need more economic muscle to move like for e.g. the United States or the Japanese . This is when they are far more efficient economies and have a larger tax-gdp ratio vis-a-vis compared to India. There is also the savings bit where India excelled which was wiped by demonetization and even now from the moves of Central Govt. savings are failing India which is and was one of the backbones of our economy.

For all their failings, people forget to honor Chidambaram and Manmohan Singh to make it easy to file Income Tax Returns. Of course the present regime has been making it more and more invasive but that’s story for another day. All in all a sad note to end the day on

Petter Reinholdtsen: When terms and policy turn users away

8 December, 2019 - 03:15

When asked to accept terms of use and privacy policies that state it will to remove rights I otherwise had or accept unreasonable terms undermining my privacy, I choose away the service. I simply do not have the conscience to accept terms I have no indention of upholding. But how are the system and service providers to know how many people they scared away? Normally I just quietly walk away. But todya, I tried a new approach. I sent the following email (removing the specifics, as I am not out to take the specific service in question) to the service provider I decided to drop, to at least give them one data point on how many users are unhappy with their terms:

From: Petter Reinholdtsen
Subject: When terms of use turn users away
To: []
Date: Sat, 07 Dec 2019 16:30:56 +0100

Dear [Site Owner],

I was eager to test the system, as it seemed like a fun and interesting application of [some] technology, but after reading the terms of use and privacy policy on <URL: https://www.[]/terms-of-use > and <URL: https://www.[]/privacy-policy > I want you to know that I decided to turn away. There were several provisions in the terms and policy turning me off, but the final term that convinced me was being asked to sign away my right to reverse engineer.

Happy hacking
Petter Reinholdtsen

I do not expect much to come out of it, but sharing it here in case others want to give something similar a try too. If companies discover their terms scare away enough people, perhaps they will be improved...

Dirk Eddelbuettel: RcppArmadillo 0.9.800.3.0

7 December, 2019 - 23:38

A small Armadillo bugfix upstream update 9.800.3 came out a few days ago. The changes, summarised by Conrad in email to me (and for once not yet on the arma site are fixes for matrix row iterators, better detection of non-hermitian matrices by eig_sym(), inv_sympd(), chol(), expmat_sym() and miscellaneous minor fixes. It also contains a bug fix by Christian Gunning to his sample() implementation.

Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. RcppArmadillo integrates this library with the R environment and language–and is widely used by (currently) 679 other packages on CRAN.

Changes in RcppArmadillo version 0.9.800.3.0 (2019-12-04)
  • Upgraded to Armadillo release 9.800.3 (Horizon Scraper)

  • The sample function passes the prob vector as const allowing subsequent calls (Christian Gunning in #276 fixing #275)

Courtesy of CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

If you like this or other open-source work I do, you can now sponsor me at GitHub. For the first year, GitHub will match your contributions.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Dirk Eddelbuettel: RDieHarder 0.2.1

7 December, 2019 - 23:26

A new version, now at 0.2.1, of the random-number generator tester RDieHarder (based on the DieHarder suite developed / maintained by Robert Brown with contributions by David Bauer and myself) is now on CRAN.

This version has only internal changes. Brian Ripley, tireless as always, is testing the impact of gcc 10 on CRAN code and found that the ‘to-be-default’ option -fno-common throws off a few (older) C code bases, this one (which is indeed old) included. So in a nutshell, we declared all global variables extern and defined them once and only once in new file globals.c. Needless to say, this affects the buildability options. In the past we used to rely on an external library libdieharder (which e.g. I had put together for Debian) but we now just build everything internally in the package.

Which builds on the changes in RDieHarder 0.2.0 which I apparently had not blogged about when it came out on December 21 last year. I had refactored the package to use either the until-then-required-but-now-optional external library, or the included library code. Doing so meant more builds on more systems including Windows.

This (very old) package has no NEWS.Rd file to take a summary from, but the ChangeLog file has all the details.

Thanks to CRANberries, you can also look at a diff from 0.2.1 to 0.2.0. or the older diff from 0.2.0 to 0.1.4.

If you like this or other open-source work I do, you can now sponsor me at GitHub. For the first year, GitHub will match your contributions.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Rhonda D'Vine: Oxa

7 December, 2019 - 06:01

It's been a while. And to be honest, I'm overdue with a few things that I want to get out. One of those things is … Brazil doesn't let me go. I'm watching this country since over a year now, hopefully understandable with the political changes last year and this year's debconf being there, and I promise to go into more details with that in the future because there is more and more to it …

Because one of those things that showed me that Brazil doesn't want to let me go was stumbling upon this artist. They were shared by some friends, and I instantly fell for them. This is about Oxa, but see for yourself:

  • Toy: Their first performance at the show »The Voice of Germany«, where they also stated that they are non-binary. And the song is lovely.
  • Born This Way: With this one, the spoken word interlude gave me goosebumps and I'm astonished that this was possible to get into the show. Big respect!
  • I'm Still Standing: The lyrics in this song are also just as powerful as the other chosen ones. Extremely fine selection!

I'm absolute in love with the person on so many levels–and yes, they are from Brazil originally. Multo brigado, Brazil!

/music | permanent link | Comments: 0 | Flattr this

Enrico Zini: Read only rootfs

7 December, 2019 - 06:00

This is part of a series of post on the design and technical steps of creating Himblick, a digital signage box based on the Raspberry Pi 4.

Another nice to have in a system like Himblick is the root filesystem mounted readonly, with a volatile tempfs overlay on top. This would kind of always guarantee a clean boot without leftovers from a previous run, especially in a system where the most likely mode of shutdown is going to be pulling the plug.

This won't be a guarantee about SD issues developing over time in such a scenario, but it should at least cover the software side of things.

In theory, systemd supports this out of the box with the systemd.volatile=overlay kernel command line option, including integrating this with journald and the way other things get mounted.

In practice:

While things catch up, dracut has a rootovl option that implements something similar.

The procedure becomes, roughly:

# apt install --no-install-recommends dracut
# echo filesystems+=overlay > /etc/dracut.conf.d/overlay.conf
# dracut /boot/initrd.img
# sed -ri -e '/$/ rootovl/' /boot/cmdline.txt" rootovl" in cmdline
# echo "initramfs initrd.img" >> /boot/config.txt

Here's how it ended up in python:

    def setup_readonly_root(self):
        Setup a readonly root with a tempfs overlay
        # Set up a readonly root using dracut's 'rootovl' feature.
        # Eventually do this with systemd's systemd.volatile=overlay option.
        # See
        self.write_file("/etc/dracut.conf.d/overlay.conf", "filesystems+=overlay\n")["dracut", "--force", "/boot/initrd.img", "4.19.75-v7l+"])
        with self.edit_kernel_commandline("/boot/cmdline.txt") as parts:
            # Add 'rootovl' to /etc/cmdline
            if "rootovl" not in parts:

        # Add initramfs initrd.img to config.txt
        with self.edit_text_file("/boot/config.txt") as lines:
            if "initramfs initrd.img" not in lines:
                lines.append("initramfs initrd.img")

Vincent Bernat: Replacing Orange Livebox router by a Linux box

6 December, 2019 - 18:15

A few months ago, I moved back to France and I settled for Orange as an ISP with a bundle combining Internet and mobile subscription. In Switzerland, I was using my own router instead of the box provided by Swisscom. While there is an abundant documentation to replace the box provided by Orange, the instructions around a plain Linux box are kludgy. I am exposing here my own variation. I am only interested in getting IPv4/IPv6 access: no VoIP, no TV.


Orange is using GPON for its FTTH deployment. Therefore, an ONT is needed to encapsulate and decapsulate Ethernet frames into GPON frames. Two form-factors are available. It can be small Huawei HG8010H box also acting as a media converter to Ethernet 1000BASE-T:

The rebranded Huawei HG8010H is acting as an ONT and media converter

With a recent Livebox, Orange usually provides an SFP to be plugged inside the Livebox. For some reason I got the external ONT instead of the SFP version. As I have a Netgear GS110TP with two SFP ports, I have bought an SFP GPON FGS202 on eBay. It is the same model than Orange is providing with its Livebox 4. However, I didn’t get the motivation to test it.1

The Sercomm FGS202 GPON SFP ONT IPv4 configuration

Internet is provided over VLAN 832 and configured with DHCPv4. The first step is to setup the DHCP client to send some additional information, notably the RFC 3118 authentication string. It includes the alphanumeric connection identifier prefixed by fti/ and provided by snail mail. /etc/dhcp/dhclient.conf looks like this:

option rfc3118-authentication code 90 = string;
interface "internet" {
  timeout 60;
  retry 1;
  select-timeout 0;
  send vendor-class-identifier "sagem";
  send user-class "+FSVDSL_livebox.Internet.softathome.Livebox4";
  # fti/xxxxxx identifier can be converted to hexadecimal with:
  #  echo -n 123456 | od -A n -t x1
  send rfc3118-authentication 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:66:74:69:2f:xx:xx:xx:xx:xx:xx:xx;
  request subnet-mask, routers,
          domain-name-servers, domain-name,
          dhcp-lease-time, dhcp-renewal-time, dhcp-rebinding-time,

Orange expects some control packets, notably DHCP, to be tagged with 802.1p PCP 6. This is a 3-bit field within the Ethernet frame when using VLANs. By default, Linux leaves this field blank. With ip link, we can translate Linux’s skb->priority to a PCP. On Debian, here is how to declare the VLAN interface:2

auto internet
iface internet inet dhcp
  pre-up    ip link add link eno1 name internet type vlan id 832 egress-qos-map 0:0 6:6
  pre-up    /etc/firewall/run
  post-down ip link del internet

The last step is to add the appropriate code in /etc/firewall/run to ensure DHCP, ARP, IGMP and ICMP packets have an internal priority of 6. Netfilter’s CLASSIFY target would be the easiest solution. However, ISC DHCP client is using raw sockets and the packets it sent won’t pass throught Netfilter. A clean solution is to use tc to modify packets just before handing them to the network card. The skbedit action allows to change the priority associated to a packet:

# We need a qdisc to set filters
tc qdisc replace dev internet root handle 1: prio
tc filter del dev internet

# DHCP (raw sockets, do not specify "protocol ip")
tc filter add dev internet parent 1: prio 1 u32 \
     match ip protocol 17 ff \
     match ip dport 67 ffff \
     action skbedit priority 0:6
tc filter add dev internet parent 1: prio 2 protocol 0x806 u32 \
     match u32 0 0 \
     action skbedit priority 0:6
tc filter add dev internet parent 1: prio 3 protocol ip u32 \
     match ip protocol 2 ff \
     action skbedit priority 0:6
tc filter add dev internet parent 1: prio 4 protocol ip u32 \
     match ip protocol 1 ff \
     action skbedit priority 0:6

With this configuration in place, ifup internet should get you connected through IPv4.

IPv6 configuration

Native IPv6 is also available over the same VLAN. SLAAC autoconfiguration should be used to get a default route, but not the IP address. Instead, Orange is providing a /60 prefix through DHCPv6 “prefix delegation.”

The DHCP configuration is completed to send the DHCPv6 equivalents for vendor class, user class and authentication string:

# […]
option dhcp6.auth code 11 = string;
option dhcp6.userclass code 15 = string;
option dhcp6.vendorclass code 16 = string;
interface "internet" {
  timeout 60;
  retry 1;
  select-timeout 0;
  # […]
  send dhcp6.vendorclass 00:00:04:0e:00:05:73:61:67:65:6d;
  send dhcp6.userclass 00:2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:6c:69:76:65:62:6f:78:34;
  send dhcp6.auth 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:66:74:69:2f:xx:xx:xx:xx:xx:xx:xx;
  also request dhcp6.auth, dhcp6.vendorclass, dhcp6.userclass;

The firewall script is amended to classify DHCPv6 and ICMPv6 packets with priority 6:

# DHCPv6
tc filter add dev internet parent 1: prio 5 protocol ipv6 u32 \
     match ip6 protocol 17 ff \
     match ip6 dport 547 ffff \
     action skbedit priority 0:6
# ICMPv6
tc filter add dev internet parent 1: prio 6 protocol ipv6 u32 \
     match ip6 protocol 58 ff \
     action skbedit priority 0:6

The definition of the internet interface is updated to invoke the DHCPv6 client:

auto internet
iface internet inet dhcp
  pre-up    ip link add link eno1 name internet type vlan id 832 egress-qos-map 0:0 6:6
  pre-up    /etc/firewall/run
  post-down ip link del internet
  post-up   /lib/ifupdown/ && \
            dhclient -6 -P -pf /run/dhclient6.$ \
                           -lf /var/lib/dhcp/dhclient6.$IFACE.leases \
                           -df /var/lib/dhcp/dhclient.$IFACE.leases \
  post-down dhclient -6 -r -pf /run/dhclient6.$ dhclient \
                           -lf /var/lib/dhcp/dhclient6.$IFACE.leases \
                           -df /var/lib/dhcp/dhclient.$IFACE.leases \
                           $IFACE || true

The /lib/ifupdown/ script waits for the interface to get a link-local address before continuing. The -P option for the DHCPv6 client enables prefix delegation and disables the normal address query.

It is not over: the DHCPv6 client will receive a /60 prefix but there is nothing configured to make use of it. You need to drop a script in /etc/dhcp/dhclient-exit-hooks.d to actually distribute this prefix to your internal network. Here is a simplified non-tested version of this script:

IA_PD_IFACES="lan-trusted lan-guest lan-games"

case $reason in
    for iface in $IA_PD_IFACES; do
      # Remove old /64 prefix if there is a change
      [ -n "$old_ip6_prefix" ] && \
        [ "$old_ip6_prefix" != "$new_ip6_prefix" ] && \
        ip -6 addr flush dev $iface scope global
      # Compute and add new /64 prefix
      [ -n "$new_ip6_prefix" ] && {
        offset=$((offset + 1))
        address=$(sipcalc --v6split=64 --split-verbose "$new_ip6_prefix" \
                   | grep '^Compressed' \
                   | awk "(NR == $offset)"' { print $NF }')1/64
        ! ip -6 addr show dev $iface | grep -qwF $address || \
          ip -6 addr add $address dev $iface

At the top of the script, the IA_PD_IFACES variable contains the list of internal interfaces. From the /60 provided in $new_ip6_prefix, the script will assign a /64 to each of them—along with the first address. For example, when being assigned 2001:db8:f:b00::/60, we get:

$ ip -brief -6 a show scope global
lan-trusted@eno1  UP  2001:db8:f:b00::1/64
lan-guest@eno1    UP  2001:db8:f:b01::1/64
lan-games@eno1    UP  2001:db8:f:b02::1/64

I am using dnsmasq to offer IPv6 router advertisements to hosts in each network. This is done through the dhcp-range directive:


The script also handles the default route by switching accept_ra to 2 for the internet interface to accept IPv6 router advertisements even when forwarding is enabled and sending an IPv6 router discovery packet using rdisc6:

case $old_ip6_prefix,$new_ip6_prefix in
    # No IPv6 prefix delegation, remove old route
    sysctl -qw net/ipv6/conf/$interface/accept_ra=0
    ip -6 route del default proto ra || true
    # Otherwise, get a default route
    sysctl -qw net/ipv6/conf/$interface/accept_ra=2
    rdisc6 $interface

Be sure to use the complete script instead of the shortened code above! If after ifdown internet && ifup internet, you don’t get a /60 prefix, you may have to reboot the ONT to clear an old DHCP lease.

  1. As Orange is using the serial number to authorize the ONT, my plan is to call Orange customer service, pretend I have got a replacement and provide the new serial number. ↩︎

  2. There is no need to have the VLAN number in the interface name. I usually leaves them out as it doesn’t help to describe the interface. The VLAN number can still be recovered with ip -d link show. ↩︎

Gunnar Wolf: My greedy hands are full of books! (Made With Creative Commons) @ccmx @creativecommons @xattack @scannopolis

6 December, 2019 - 07:44


Made with Creative Commons is translated to Spanish, printed, and available!

Over two years after starting the project, 976 commits, getting involved in long processes (besides the scope we originally envisioned, such as waiting for the translation to be refereed or going over two quite long rounds of copyediting), after leading a team of five translators to Spanish and working closely with a similar team that's quite close to publishing the equivalent translation in Norwegian... Behold!

I won't get again in details on the contents of this book, as I have repeatedly talked about it in the blog. The photo above is of the pages where the CC licensing schemes are presented. And the following is a page I like including in all of my (so far, three) published books:

I have made a point of requiring my university's editorial department to use the legal page to be very explicit regarding the expected usage of this book, by inviting every person that comes across it to copy this book.

So... Where can you get your paws on one of them? Well, of course, you are welcome to come to our institute's bookstore and buy one. For people in general, MX$280 (≈US$15), for UNAM-community, MX$140 (≈US$7.50).

Of course, that's quite inconvenient for people living over 15Km from me, right? What about those living in other countries?

The book can also be downloaded from the Institute's repository. And I will soon upload it to an online, on-demand printing site (probably or something like that. Can you suggest one?).

AttachmentSize Finally: a box full of books80.66 KB How to use CC licenses?78.48 KB Copy this book!70.5 KB


Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้