Uwe Kleine-K nig: IPv6 in my home network
I am lucky and get both IPv4 (without CGNAT) and IPv6 from my provider.
Recently after upgrading my desk router (that is an Netgear WNDR3800 that
serves the network on my desk) from OpenWRT to latest LEDE I looked into what
can be improved in the IPv6 setup for both my home network (served by a
FRITZ!Box) and my desk network.
Unfortunately I was unable to improve the situation compared to what I already
had before.
Things that work
Making IPv6 work in general was easy, just a few clicks in the configuration of the FRITZ!Box and it mostly worked. After that I have:
- IPv6 connectivity in the home net
- IPv6 connectivity in the desk net
radvd on my LEDE router, but that isn't
provided by LEDE (or OpenWRT) any more as odhcpd is supposed to be used which
AFAICT is unable to send RAs on the wan interface though. Ok, probably I could
install bird, but that seems a bit oversized. I created an entry in the LEDE
forum
but without any reply up to now.
Alternatively (but less pretty) I could setup an IPv6 route in the FRITZ!Box,
but that only works with a newer firmware and as this router is owned by my
provider I cannot update it.
Firewalling
The FRITZ!Box has a firewall that is not very configurable. I can punch a hole
in it for hosts with a given interface-ID, but that only works for hosts in the
home net, not the machines in the delegated subnet behind the LEDE router. In
fact I think the FRITZ!Box should delegate firewalling for a delegated net also
to the router of that subnet.
So having a global address on the machines on my desk doesn't allow me to reach
them from the internet.
Update: according to the German changelog firmware 6.83 seems to include that
feature. Cheers AVM. Now waiting for my provider to update ...
Debian
devscripts
Before deciding to take an
Here s my weekly report for week 39 of 2017. In this week I have
Here is my monthly update covering what I have been doing in the free software world in September 2017 (
Similar to the problem described in the post
The thirteenth release in the 0.12.* series of
I just released Debian Policy version 4.1.1.0.
There are only two normative changes, and neither is very important.
The main thing is that this upload fixes a lot of packaging bugs that
were found since we converted to build with Sphinx.
There are still some issues remaining; I hope to submit some patches
to the www-team s scripts to fix those.
Seems the breakage of my desktop computer more than 3 months ago did also caused also a hiatus on my online publishing activities... it was not really intended, it happened I was just busy with other things 

.
Both Richard and I first tried to extract all the metadata to display fonts in a proper way to the users from the font files directly. This turned out to be very difficult, since font metadata is often wrong or incomplete, and certain desirable bits of metadata (like a longer description) are missing entirely. After messing around with different ways to solve this for days (afterall, by extracting the data from font files directly we would have hundreds of fonts directly available in software centers), I also came to the same conclusion as Richard: The best and easiest solution here is to mandate the availability of metainfo files per font.
Which brings me to the second issue: What is a font? For any person knowing about fonts, they will understand one font as one font face, e.g. Lato Regular Italic or Lato Bold . A user however will see the font family as a font, e.g. just Lato instead of all the font faces separated out. Since AppStream data is used primarily by software centers, we want something that is easy for users to understand. Hence, an AppStream font components really describes a font family or collection of fonts, instead of individual font faces. We do also want AppStream data to be useful for system components looking for a specific font, which is why font components will advertise the individual font face names they contain via a 