Go to the content
or

Debian

Full screen Suggest an article
 RSS feed

Planet Debian

July 1, 2016 14:34 , by valessiobrito - | No one following this article yet.

Planet.Debian is a website that aggregates the blogs of many Debian contributors. Planet maintainers can be reached at planet at debian.org


Scarlett Clark: Debian: Reproducible builds update

June 27, 2016 17:58, by Planet Debian - 0no comments yet

A quick update to note that I did complete extra-cmake-modules and was given the green light to push upstream and in Debian and will do so asap.
Due to circumstances out of my control, I am moving a few states over and will have to continue my efforts when I arrive at
my new place of residence in a few days. Thanks
for understanding.

Scarlett



John Goerzen: I’m switching from git-annex to Syncthing

June 27, 2016 13:02, by Planet Debian - 0no comments yet

I wrote recently about using git-annex for encrypted sync, but due to a number of issues with it, I’ve opted to switch to Syncthing.

I’d been using git-annex with real but noncritical data. Among the first issues I noticed was occasional but persistent high CPU usage spikes, which once started, would persist apparently forever. I had an issue where git-annex tried to replace files I’d removed from its repo with broken symlinks, but the real final straw was a number of issues with the gcrypt remote repos. git-remote-gcrypt appears to have a number of issues with possible race conditions on the remote, and at least one of them somehow caused encrypted data to appear in a packfile on a remote repo. Why there was data in a packfile there, I don’t know, since git-annex is supposed to keep the data out of packfiles.

Anyhow, git-annex is still an awesome tool with a lot of use cases, but I’m concluding that live sync to an encrypted git remote isn’t quite there yet enough for me.

So I looked for alternatives. My main criteria were supporting live sync (via inotify or similar) and not requiring the files to be stored unencrypted on a remote system (my local systems all use LUKS). I found Syncthing met these requirements.

Syncthing is pretty interesting in that, like git-annex, it doesn’t require a centralized server at all. Rather, it forms basically a mesh between your devices. Its concept is somewhat similar to the proprietary Bittorrent Sync — basically, all the nodes communicate about what files and chunks of files they have, and the changes that are made, and immediately propagate as much as possible. Unlike, say, Dropbox or Owncloud, Syncthing can actually support simultaneous downloads from multiple remotes for optimum performance when there are many changes.

Combined with syncthing-inotify or syncthing-gtk, it has immediate detection of changes and therefore very quick propagation of them.

Syncthing is particularly adept at figuring out ways for the nodes to communicate with each other. It begins by broadcasting on the local network, so known nearby nodes can be found directly. The Syncthing folks also run a discovery server (though you can use your own if you prefer) that lets nodes find each other on the Internet. Syncthing will attempt to use UPnP to configure firewalls to let it out, but if that fails, the last resort is a traffic relay server — again, a number of volunteers host these online, but you can run your own if you prefer.

Each node in Syncthing has an RSA keypair, and what amounts to part of the public key is used as a globally unique node ID. The initial link between nodes is accomplished by pasting the globally unique ID from one node into the “add node” screen on the other; the user of the first node then must accept the request, and from that point on, syncing can proceed. The data is all transmitted encrypted, of course, so interception will not cause data to be revealed.

Really my only complaint about Syncthing so far is that, although it binds to localhost, the web GUI does not require authentication by default.

There is an ITP open for Syncthing in Debian, but until then, their apt repo works fine. For syncthing-gtk, the trusty version of the webupd8 PPD works in Jessie (though be sure to pin it to a low priority if you don’t want it replacing some unrelated Debian packages).



Alessio Treglia: A – not exactly United – Kingdom

June 27, 2016 7:54, by Planet Debian - 0no comments yet

 

Island of Ventotene – Roman harbour

There once was a Kingdom strongly United, built on the honours of the people of Wessex, of Mercia, Northumbria and East Anglia who knew how to deal with the invasion of the Vikings from the east and of Normans from the south, to come to unify the territory under an umbrella of common intents. Today, however, 48% of them, while keeping solid traditions, still know how to look forward to the future, joining horizons and commercial developments along with the rest of Europe. The remaining 52%, however, look back and can not see anything in front of them if not a desire of isolation, breaking the European dream born on the shores of Ventotene island in 1944 by Altiero Spinelli, Ernesto Rossi and Ursula Hirschmann through the “Manifesto for a free and united Europe“. An incurable fracture in the country was born in a referendum on 23 June, in which just over half of the population asked to terminate his marriage to the great European family, bringing the UK back by 43 years of history.

<Read More…[by Fabio Marzocca]>



Bits from Debian: DebConf16 schedule available

June 27, 2016 7:00, by Planet Debian - 0no comments yet

DebConf16 will be held this and next week in Cape Town, South Africa, and we're happy to announce that the schedule is already available. Of course, it is still possible for some minor changes to happen!

The DebCamp Sprints already started on 23 June 2016.

DebConf will open on Saturday, 2 July 2016 with the Open Festival, where events of interest to a wider audience are offered, ranging from topics specific to Debian to a wider appreciation of the open and maker movements (and not just IT-related). Hackers, makers, hobbyists and other interested parties are invited to share their activities with DebConf attendees and the public at the University of Cape Town, whether in form of workshops, lightning talks, install parties, art exhibition or posters. Additionally, a Job Fair will take place on Saturday, and its job wall will be available throughout DebConf.

The full schedule of the Debian Conference thorough the week is published. After the Open Festival, the conference will continue with more than 85 talks and BoFs (informal gatherings and discussions within Debian teams), including not only software development and packaging but also areas like translation, documentation, artwork, testing, specialized derivatives, maintenance of the community infrastructure, and other.

There will also be also a plethora of social events, such as our traditional cheese and wine party, our group photo and our day trip.

DebConf talks will be broadcast live on the Internet when possible, and videos of the talks will be published on the web along with the presentation slides.

DebConf is committed to a safe and welcome environment for all participants. See the DebConf Code of Conduct and the Debian Code of Conduct for more details on this.

Debian thanks the commitment of numerous sponsors to support DebConf16, particularly our Platinum Sponsor Hewlett Packard Enterprise.

About Hewlett Packard Enterprise

Hewlett Packard Enterprise actively participates in open source. Thousands of developers across the company are focused on open source projects, and HPE sponsors and supports the open source community in a number of ways, including: contributing code, sponsoring foundations and projects, providing active leadership, and participating in various committees.



Paul Tagliamonte: Hello, Sense!

June 27, 2016 1:42, by Planet Debian - 0no comments yet

A while back, I saw a Kickstarter for one of the most well designed and pretty sleep trackers on the market. I fell in love with it, and it has stuck with me since.

A few months ago, I finally got my hands on one and started to track my data. Naturally, I now want to store this new data with the rest of the data I have on myself in my own databases.

I went in search of an API, but I found that the Sense API hasn't been published yet, and is being worked on by the team. Here's hoping it'll land soon!

After some subdomain guessing, I hit on api.hello.is. So, naturally, I went to take a quick look at their Android app and network traffic, lo and behold, there was a pretty nicely designed API.

This API is clearly an internal API, and as such, it's something that should not be considered stable. However, I'm OK with a fragile API, so I've published a quick and dirty API wrapper for the Sense API to my GitHub..

I've published it because I've found it useful, but I can't promise the world, (since I'm not a member of the Sense team at Hello!), so here are a few ground rules of this wrapper:

  • I make no claims to the stability or completeness.
  • I have no documentation or assurances.
  • I will not provide the client secret and ID. You'll have to find them on your own.
  • This may stop working without any notice, and there may even be really nasty bugs that result in your alarm going off at 4 AM.
  • Send PRs! This is a side-project for me.

This module is currently Python 3 only. If someone really needs Python 2 support, I'm open to minimally invasive patches to the codebase using six to support Python 2.7.

Working with the API:

First, let's go ahead and log in using python -m sense.

$ python -m sense
Sense OAuth Client ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Sense OAuth Client Secret: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Sense email: paultag@gmail.com
Sense password: 
Attempting to log into Sense's API
Success!
Attempting to query the Sense API
The humidity is **just right**.
The air quality is **just right**.
The light level is **just right**.
It's **pretty hot** in here.
The noise level is **just right**.
Success!

Now, let's see if we can pull up information on my Sense:

>>> from sense import Sense
>>> sense = Sense()
>>> sense.devices()
{'senses': [{'id': 'xxxxxxxxxxxxxxxx', 'firmware_version': '11a1', 'last_updated': 1466991060000, 'state': 'NORMAL', 'wifi_info': {'rssi': 0, 'ssid': 'Pretty Fly for a WiFi (2.4 GhZ)', 'condition': 'GOOD', 'last_updated': 1462927722000}, 'color': 'BLACK'}], 'pills': [{'id': 'xxxxxxxxxxxxxxxx', 'firmware_version': '2', 'last_updated': 1466990339000, 'battery_level': 87, 'color': 'BLUE', 'state': 'NORMAL'}]}

Neat! Pretty cool. Look, you can even see my WiFi AP! Let's try some more and pull some trends out.

>>> values = [x.get("value") for x in sense.room_sensors()["humidity"]][:10]
>>> min(values)
45.73904
>>> max(values)
45.985928
>>> 

I plan to keep maintaining it as long as it's needed, so I welcome co-maintainers, and I'd love to see what people build with it! So far, I'm using it to dump my room data into InfluxDB, pulling information on my room into Grafana. Hopefully more to come!

Happy hacking!



Steinar H. Gunderson: Nageru 1.3.0 released

June 26, 2016 22:00, by Planet Debian - 0no comments yet

I've just released version 1.3.0 of Nageru, my live software video mixer.

Things have been a bit quiet on the Nageru front recently, for two reasons: First, I've been busy with moving (from Switzerland to Norway) and associated job change (from Google to MySQL/Oracle). Things are going well, but these kinds of changes tend to take, well, time and energy.

Second, the highlight of Nageru 1.3.0 is encoding of H.264 streams meant for end users (using x264), not just the Quick Sync Video streams from earlier versions, which work more as a near-lossless intermediate format meant for transcoding to something else later. Like with most things video, hitting such features really hard (I've been doing literally weeks of continuous stream testing) tends to expose weaknesses in upstream software.

In particular, I wanted x264 speed control, where the quality is tuned up and down live as the content dictates. This is mainly because the content I want to stream this summer (demoscene competitions) varies from the very simple to downright ridiculously complex (as you can see, YouTube just basically gives up and creates gray blocks). If you have only one static quality setting, you will have the choice between something that looks like crap for everything, and one that drops frames like crazy (or, if your encoding software isn't all that, like e.g. using ffmpeg(1) directly, just gets behind and all your clients' streams just stop) when the tricky stuff comes. There was an unofficial patch for speed control, but it was buggy, not suitable for today's hardware and not kept at all up to date with modern x264 versions. So to get speed control, I had to work that patch pretty heavily (including making it so that it could work in Nageru directly instead of requiring a patched x264)… and then it exposed a bug in x264 proper that would cause corruption when changing between some presets, and I couldn't release 1.3.0 before that fix had at least hit git.

Similarly, debugging this exposed an issue with how I did streaming with ffmpeg and the MP4 mux (which you need to be able to stream H.264 directly to HTML5 <video> without any funny and latency-inducing segmenting business); to know where keyframes started, I needed to flush the mux before each one, but this messes up interleaving, and if frames were ever dropped right in front of a keyframe (which they would on the most difficult content, even at speed control's fastest presets!), the “duration” field of the frame would be wrong, causing the timestamps to be wrong and even having pts < dts in some cases. (VLC has to deal with flushing in exactly the same way, and thus would have exactly the same issue, although VLC generally doesn't transcode variable-framerate content so well to begin with, so the heuristics would be more likely to work. Incidentally, I wrote the VLC code for this flushing back in the day, to be able to stream WebM for some Debconf.) I cannot take credit for the ffmpeg/libav fixes (that was all done by Martin Storsjö), but again, Nageru had to wait for the new API they introduce (that just signals to the application when a keyframe is about to begin, removing the need for flushing) to get into git mainline. Hopefully, both fixes will get into releases soon-ish and from there one make their way into stretch.

Apart from that, there's a bunch of fixes as always. I'm still occasionally (about once every two weeks of streaming or so) hitting what I believe is a bug in NVIDIA's proprietary OpenGL drivers, but it's nearly impossible to debug without some serious help from them, and they haven't been responding to my inquiries. Every two weeks means that you could be hitting it in a weekend's worth of streaming, so it would be nice to get it fixed, but it also means it's really really hard to make a reproducible test case. :-) But the fact that this is currently the worst stability bug (and that you can work around it by using e.g. Intel's drivers) also shows that Nageru is pretty stable these days.



Iustin Pop: Random things of the week - brexit and the pretzel

June 26, 2016 19:59, by Planet Debian - 0no comments yet

Random things of the week

In no particular order (mostly).

Coming back from the US, it was easier dealing with the jet-lag this time; doing sports in the morning or at noon and eating light on the evening helps a lot.

The big thing of the week, that has everybody talking, is of course brexit. My thoughts, as written before on a facebook comment: Direct democracy doesn't really work if it's done once in a blue moon. Wikipedia says there have been thirteen referendums in UK since 1975, but most of them (10) on devolution issues in individual countries, and only three were UK-wide referendums (quoting from the above page): the first on membership of the European Economic Community in 1975, the second on adopting the Alternative vote system in parliamentary elections in 2011, and the third one is the current one. Which means that a referendum is done every 13 years or so.

At this frequency, people are not a) used to inform themselves on the actual issues, b) believing that your vote actually will change things, and most likely c) not taking the "direct-democracy" aspect seriously (thinking beyond the issue at hand and how will it play together with all the rest of the political decisions). The result is what we've seen, leave politicians already backpedalling on issues, and confusion that yes, leave votes actually counted.

My prognosis for what's going to happen:

  • one option, this gets magically undone, and there will be rejoicing at the barely avoided big damage (small damage already done).
  • otherwise, UK will lose significantly from the economy point of view, enough that they'll try being out of the EU officially but "in" the EU from the point of view of trade.
  • in any case, large external companies will be very wary of investing in production in UK (e.g. Japanese car manufacturers), and some will leave.
  • most of the 52% who voted leave will realise that this was a bad outcome, in around 5 years.
  • hopefully, politicians (both in the EU and in the UK) will try to pay more attention to inequality (here I'm optimistic).

We'll see what happens though. Reading comments on various websites still make me cringe at how small some people think: "independence" from the EU when the real issue is EU versus the other big blocks—US, China, in the future India; and "versus" not necessarily in a conflict sense, but simply as negotiating power, economic treaties, etc.

Back to more down-to-earth things: this week was quite a good week for me. Including commutes, my calendar turned out quite nice:

Week calendar

The downside was that most of those were short runs or bike sessions. My runs are now usually 6.5K, and I'll try to keep to that for a few weeks, in order to be sure that bone and ligaments have adjusted, and hopefully keep injuries away.

On the bike front, the only significant thing was that I did as well the Zwift Canyon Ultimate Pretzel Mission, on the last day of the contest (today): 73.5Km in total, 3h:27m. I've done 60K rides on Zwift before, so the first 60K were OK, but the last ~5K were really hard. Legs felt like logs of wood, I was only pushing very weak output by the end although I did hydrate and fuel up during the ride. But, I was proud of the fact that on the last sprint (about 2K before the end of the ride), I had ~34s, compared to my all-time best of 29.2s. Was not bad after ~3h20m of riding and 1300 virtual meters of ascent. Strava also tells me I got 31 PRs on various segments, but that's because I rode on some parts of Watopia that I never rode before (mostly the reverse ones).

Overall, stats for this week: ~160Km in total (virtual and real, biking and running), ~9 hours spent doing sports. Still much lower than the amount of time I was playing computer games, so it's a net win ☺

Have a nice start of the week everyone, and keep doing what moves you forward!



Paul Wise: DebCamp16 day 3

June 26, 2016 19:31, by Planet Debian - 0no comments yet

Review, approve chromium, gnome-terminal and radeontop screenshots. Disgusted to see the level of creativity GPL violators have. Words of encouragement on #debian-mentors. Pleased to see Tails reproducible builds funding by Mozilla. Point out build dates in versions leads to non-reproducible builds. Point out apt-file search to someone looking for a binary of kill. Review wiki RecentChanges. Alarmingly windy. Report important Debian bug #828215 against unattended-upgrades. Clean up some code in check-all-the-things and work on fixing Debian bug #826089. Wind glorious wind! Much clearer day, nice view of the mountain. More check-all-the-things code clean up and finish up fixing Debian bug #826089. Twinkling city lights and more wind. Final code polish during dinner/discussion. Wandering in the wind amongst the twinklies. Whitelisted one user in the wiki anti-spam system. Usual spam reporting.



Michal Čihař: Troja bridge in Prague

June 26, 2016 16:00, by Planet Debian - 0no comments yet

I think it's time to renew tradition of photography posts on this blog. I will start with pictures taken few weeks ago on Troja bridge, which is the newest bridge over the Vltava river in Prague.

Filed under: Debian English Photography | 0 comments



Vasudev Kamath: Integrating Cython extension with setuptools and unit testing

June 26, 2016 14:24, by Planet Debian - 0no comments yet

I was reviewing changes for indic-trans as part of GSoC 2016. The module is an improvisation for our original transliteration module which was doing its job by substitution.

This new module uses machine learning of some sort and utilizes Cython, numpy and scipy. Student had kept pre-compiled shared library in the git tree to make sure it builds and passes the test. But this was not correct way. I started looking at way to build these files and remove it from the code base.

There is a cython documentation for distutils but none for setuptools. Probably it is similar to other Python extension integration into setuptools, but this was first time for me so after a bit of searching and trial and error below is what I did.

We need to use Extensions class from setuptools and give it path to modules we want to build. In my case beamsearch and viterbi are 2 modules. So I added following lines to setup.py

from setuptools.extension import Extension
from Cython.Build import cythonize

extensions = [
 Extension(
     "indictrans._decode.beamsearch",
     [
         "indictrans/_decode/beamsearch.pyx"
     ],
     include_dirs=[numpy.get_include()]
 ),
 Extension(
     "indictrans._decode.viterbi",
     [
         "indictrans/_decode/viterbi.pyx"
     ],
     include_dirs=[numpy.get_include()]
 )

]

First argument to Extensions is the module name and second argument is a list of files to be used in building the module. The additional inculde_dirs argument is not normally necessary unless you are working in virtualenv. In my system the build used to work without this but it was failing in Travis CI, so added it to fix the CI builds. OTOH it did work without this on Circle CI.

Next is provide this extensions to ext_modules argument to setup as shown below

setup(
 setup_requires=['pbr'],
 pbr=True,
 ext_modules=cythonize(extensions)
)

And for the reference here is full setup.py after modifications.

#!/usr/bin/env python

from setuptools import setup
from setuptools.extension import Extension
from Cython.Build import cythonize

import numpy


extensions = [
  Extension(
     "indictrans._decode.beamsearch",
     [
         "indictrans/_decode/beamsearch.pyx"
     ],
     include_dirs=[numpy.get_include()]
  ),
  Extension(
     "indictrans._decode.viterbi",
     [
         "indictrans/_decode/viterbi.pyx"
     ],
     include_dirs=[numpy.get_include()]
  )
]

setup(
  setup_requires=['pbr'],
  pbr=True,
  ext_modules=cythonize(extensions)
)

So now we can build the extensions (shared library) using following command.

python setup.py build_ext

Another challenge I faced was missing extension when running test. We use pbr in above project and testrepository with subunit for running tests. Looks like it does not build extensions by default so I modified the Makefile to build the extension in place before running test. The travis target of my Makefile is as follows.

travis:
     [ ! -d .testrepository ] || \
             find .testrepository -name "times.dbm*" -delete
     python setup.py build_ext -i
     python setup.py test --coverage \
             --coverage-package-name=indictrans
     flake8 --max-complexity 10 indictrans

I had to build the extension in place using -i switch. This is because other wise the tests won't find the indictrans._decode.beamsearch and indictrans._decode.viterbi modules. What basically -i switch does is after building shared library symlinks it to the module directory, in ourcase indictrans._decode

The test for existence of .testrepository folder is over come this bug in testrepository which results in test failure when running tests using tox.



Kevin Avignon: Tech questions 1-9 : LINQ questions

June 26, 2016 12:10, by Planet Debian - 0no comments yet

Hey guys, This is a new series I will try to maintain to the best of my capabilities. I have this awesome blogger who happens to be also a Microsoft MVP called Iris Classon. After her first year of programming, she started to ask and get answers for what she’d call “stupid question”. Why would … Continue reading Tech questions 1-9 : LINQ questions



Clint Adams: A local script for local people

June 26, 2016 10:05, by Planet Debian - 0no comments yet

This isn't actually answering the question, but it's close. It's also horrible, so whoever adopts Enrico's script should also completely rewrite this or burn it along with the stack of pizza boxes and the grand piano.

Input:

#!/bin/zsh

set -e

PATHS=$(tempfile)
NEWKEYS=$(tempfile)
NEWKEYRING=$(tempfile)
FARTHEST_TEN=$(tempfile)
trap "rm -f ${PATHS} ${NEWKEYS} ${NEWKEYRING} ${FARTHEST_TEN}" EXIT

keyring=${1:-ksp-dc16.gpg}
myfpr=${2:-2100A32C46F895AF3A08783AF6D3495BB0AE9A02}
#keyserver=${3:-http://pool.sks-keyservers.net:11371/}

# this doesn't handle hokey fetch failures
#(for fpr in $(hkt list --keyring ${keyring} --output-format JSON | jq '.[].publickey.fpr')
#do
#  hokey fetch --keyserver "${keyserver}" --validation-method MatchPrimaryKeyFingerprint "${(Q)fpr}"
#done) >${NEWKEYS}
#
#gpg2 --no-default-keyring --keyring ${NEWKEYRING} --import ${NEWKEYS}

cp "${keyring}" "${NEWKEYRING}"
gpg2 --no-default-keyring --keyring ${NEWKEYRING} --refresh

hkt findpaths --keyring ${NEWKEYRING} '' '' '' > ${PATHS}
id=$(awk -F, "/${myfpr})\$/ {sub(/\(/,BLANKY,\$1);print \$1;}" ${PATHS})
grep -e ",\[${id}," -e ",${id}\]" ${PATHS} | sort -n | tail -n 10 > ${FARTHEST_TEN}
targetids=(${(f)"${$((sed 's/^.*\[//;s/,.*$//;' ${FARTHEST_TEN}; sed 's/\])$//;s/.*,//;' ${FARTHEST_TEN}) | sort -n -u | grep -v "^${id}$")}"})
targetfprs=($(for i in ${targetids}; do awk -F, "/\(${i},[^[]/ {sub(/\)/,BLANKY,\$2); print \$2}" ${PATHS}; done))
gpg2 --no-default-keyring --keyring ${NEWKEYRING} --list-keys ${targetfprs}

Output:

pub   rsa4096/0x664F1238AA8F138A 2015-07-14 [SC]
      Key fingerprint = 3575 0B8F B6EF 95FF 16B8  EBC0 664F 1238 AA8F 138A
uid                   [ unknown] Daniel Lange <dl.ml1@usrlocal.de>
sub   rsa4096/0x03BEE1C11DB1954B 2015-07-14 [E]

pub   rsa4096/0xDF23DA3396978EB3 2014-09-05 [SC]
      Key fingerprint = BBBC 58B4 5994 CF9C CC56  BCDA DF23 DA33 9697 8EB3
uid                   [  undef ] Michael Meskes <michael@fam-meskes.de>
uid                   [  undef ] Michael Meskes <meskes@postgresql.org>
uid                   [  undef ] Michael Meskes <michael.meskes@credativ.com>
uid                   [  undef ] Michael Meskes <meskes@debian.org>
sub   rsa4096/0x85C3AFFECF0BF9B5 2014-09-05 [E]
sub   rsa4096/0x35D857C0BBCB3B25 2014-11-04 [S]

pub   rsa4096/0x1E953E27D4311E58 2009-07-12 [SC]
      Key fingerprint = C2FE 4BD2 71C1 39B8 6C53  3E46 1E95 3E27 D431 1E58
uid                   [  undef ] Chris Lamb <chris@chris-lamb.co.uk>
uid                   [  undef ] Chris Lamb <lamby@gnu.org>
uid                   [  undef ] Chris Lamb <lamby@debian.org>
sub   rsa4096/0x72B3DBA98575B3F2 2009-07-12 [E]

pub   rsa4096/0xDF6D76C44D696F6B 2014-08-15 [SC] [expires: 2017-06-03]
      Key fingerprint = 1A6F 3E63 9A44 67E8 C347  6525 DF6D 76C4 4D69 6F6B
uid                   [ unknown] Sven Bartscher <sven.bartscher@weltraumschlangen.de>
uid                   [ unknown] Sven Bartscher <svenbartscher@yahoo.de>
uid                   [ unknown] Sven Bartscher <kritzefitz@debian.org>
sub   rsa4096/0x9E83B071ED764C3A 2014-08-15 [E]
sub   rsa4096/0xAEB25323217028C2 2016-06-14 [S]

pub   rsa4096/0x83E33BD7D4DD4CA1 2015-11-12 [SC] [expires: 2017-11-11]
      Key fingerprint = 0B5A 33B8 A26D 6010 9C50  9C6C 83E3 3BD7 D4DD 4CA1
uid                   [ unknown] Jerome Charaoui <jerome@riseup.net>
sub   rsa4096/0x6614611FBD6366E7 2015-11-12 [E]
sub   rsa4096/0xDB17405204ECB364 2015-11-12 [A] [expires: 2017-11-11]

pub   rsa4096/0xF823A2729883C97C 2014-08-26 [SC]
      Key fingerprint = 8ED6 C3F8 BAC9 DB7F C130  A870 F823 A272 9883 C97C
uid                   [ unknown] Lucas Kanashiro <kanashiro@debian.org>
uid                   [ unknown] Lucas Kanashiro <kanashiro.duarte@gmail.com>
sub   rsa4096/0xEE6E5D1A9C2F5EA6 2014-08-26 [E]

pub   rsa4096/0x2EC0FFB3B7301B1F 2014-08-29 [SC] [expires: 2017-04-06]
      Key fingerprint = 76A2 8E42 C981 1D91 E88F  BA5E 2EC0 FFB3 B730 1B1F
uid                   [ unknown] Niko Tyni <ntyni@debian.org>
uid                   [ unknown] Niko Tyni <ntyni@cc.helsinki.fi>
uid                   [ unknown] Niko Tyni <ntyni@iki.fi>
sub   rsa4096/0x129086C411868FD0 2014-08-29 [E] [expires: 2017-04-06]

pub   rsa4096/0xAA761F51CC10C92A 2016-06-20 [SC] [expires: 2018-06-20]
      Key fingerprint = C9DE 2EA8 93EE 4C86 BE73  973A AA76 1F51 CC10 C92A
uid                   [ unknown] Roger Shimizu <rogershimizu@gmail.com>
sub   rsa4096/0x2C2EE1D5DBE7B292 2016-06-20 [E] [expires: 2018-06-20]
sub   rsa4096/0x05C7FD79DD03C4BB 2016-06-20 [S] [expires: 2016-09-18]

Note that this completely neglects potential victims who are unconnected within the KSP set.



Niels Thykier: Anti-declarative packaging – top 15 build-helpers inserting maintscripts

June 26, 2016 7:51, by Planet Debian - 0no comments yet

Debian packages can run arbitrary code via “maintainer scripts” (sometimes shortened into “maintscripts”) during installation/removal etc. While they certainly have their use cases, their failure modes causes “exciting” bugs like “fails to install” or the dreaded “fails to remove”.

They also have other undesirable effects such as:

  • Bugs in/Updates to auto-generated snippets require a rebuild of all packages (not to mention the obvious code-duplication in all packages).
  • In case of circular dependencies[1] all having “postinst” scripts, dpkg will have to guess which package to configure first.
  • They require forking a shell at least once for each maintscript.
  • They complicate the implementations of e.g. detached chroot creation.

Accordingly, I think we should aim for a more declarative packaging style.  To help facilitate this, I have implemented 3 tracking tags in Lintian.

With these, we were able to learn that 73.5% of all packages do not have any of these scripts.  But I can now also produce a list of helpers that insert the most maintainer script snippets. The current top 15 is:

  1. “dhpython” with 3775 instances
    • This is an umbrella for all helpers using dh-python’s python module, see #827774.
  2. dh_installmenu with 1861 instances
  3. dh_makeshlibs with 1396 remaining instances
  4. dh_installinit with 1224 instances
  5. dh_python2 with 1168 instances
  6. dh_installdebconf with 772 instances
  7. dh_installdeb with 754 instances
    • These are the dpkg-maintscript-helper snippets for “rm_conffile”, “mv_conffile” etc.  Hopefully in the near future, dpkg will support these directly.
  8. dh_systemd_enable with 447 instances
  9. dh_installemacsen with 179 instances
  10. dh_icons with 165 instances
  11. dh_installtex with 137 instances
  12. dh_apache2 with 117 instances
  13. dh_installudev with 98 instances
  14. dh_installxfonts with 87 instances
  15. dh_systemd_start with 79 instances

With this list, it seems to me that some obvious focus areas would be:

  • Replacing the python scripts (I presume it is the byte-code handling, but I have not looked at this at all)
  • Migrating away from menu files
  • Support enabling + starting/stopping/restarting a service declaratively.
    • This might have a “hidden” requirement on declaratively creating service users if we want these packages to become truly “maintscript-less”.

Eventually we will also have to dig through all the “manual” maintainer scripts. But I think we got plenty to start with.:)

 

[1] For some, circular dependencies in itself is an issue. I can certainly appreciate them as being suboptimal, but most of the issues we have are probably caused by insufficient tooling rather than a theoretical issue (that is, if we remove all postinst scripts).


Filed under: Debhelper, Debian, Lintian

Kevin Avignon: Shaping your profesional skills structure

June 26, 2016 0:58, by Planet Debian - 0no comments yet

Hey guys, So, professional shaped skills… What’s that. Basically, it’s the form your skills take concerning your expertise in your individual field(s). This form will depend on both depth and broadness. Trying to learn as many things as possible will lead to little depth and a large broadness of skills. The exact opposite leads to … Continue reading Shaping your profesional skills structure



Dimitri John Ledkov: Post-Brexit - The What Now?

June 25, 2016 19:24, by Planet Debian - 0no comments yet

Out of 46,500,001 electorate 17,410,742 voted to leave, which is a mere 37.4% or just over a third. [source]. On my books this is not a clear expression of the UK wishes.

The reaction that the results have caused are devastating. The Scottish First Minister has announced plans for 2nd Scottish Independence referendum [source]. Londoners are filing petitions calling for Independent London [source, source]. The Prime Minister announced his resignation [source]. Things are not stable.

I do not believe that super majority of the electorate are in favor of leaving the EU. I don't even believe that those who voted to leave have considered the break up of the UK as the inevitable outcome of the leave vote. There are numerous videos on the internet about that, impossible to quantify or reliably cite, but for example this [source]

So What Now?

P R O T E S T

I urge everyone to start protesting the outcome of the mistake that happened last Thursday. 4th of July is a good symbolic date to show your discontent with the UK governemnt and a tiny minority who are about to cause the country to fall apart with no other benefits. Please stand up and make yourself heard.
  • General Strikes 4th & 5th of July
There are 64,100,000 people living in the UK according to the World Bank, maybe the government should fear and listen to the unheard third. The current "majority" parliament was only elected by 24% of electorate.

It is time for people to actually take control, we can fix our parliament, we can stop austerity, we can prevent the break up of the UK, and we can stay in the EU. Over to you.

ps. How to elect next PM?

Electing next PM will be done within the Conservative Party, and that's kind of a bummer, given that the desperate state the country currently is in. It is not that hard to predict that Boris Johnson is a front-runner. If you wish to elect a different PM, I urge you to splash out 25 quid and register to be a member of the Conservative Party just for one year =) this way you will get a chance to directly elect the new Leader of the Conservative Party and thus the new Prime Minister. You can backdoor the Conservative election here.