Planet Debian

Subscribe to Planet Debian feed
Planet Debian - https://planet.debian.org/
Updated: 44 min 12 sec ago

Thorsten Alteholz: My Debian Activities in May 2019

8 June, 2019 - 18:47

FTP master

Nothing changed compared to last month, so this was again a quiet month. I only accepted 126 packages and rejected 15 uploads. The overall number of packages that got accepted was 156.

Debian LTS

This was my fifty ninth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian.

This month my all in all workload has been 18h. During that time I did LTS uploads or prepared security uploads of:

  • [DLA 1783-1] atftp security update for two CVEs
  • [DLA 1803-1] php5 security update for three CVEs
  • [DLA 1807-1] vcftools security update for three CVEs
  • [DLA 1811-1] miniupnpd security update for six CVEs

I also helped the maintainer of lemonldap-ng to create his DLA 1791-1. Further I created a package for testing bind9 and wpa, but both failed miserably in the wild, so I have to start from scratch here.

Last but not least I did some days of frontdesk duties.

Debian ELTS

This month was the twelfth ELTS month.

During my allocated time I uploaded:

  • ELA-120-1 of php5 for one CVE
  • ELA-122-1 of curl for one CVE

As like LTS, the bind9 package did not really work, thanks to Roberto C. Sánchez for telling me this.

I also did some days of frontdesk duties.

Other stuff

I uploaded a new upstream version of …

I uploaded a new package for …

On my Go challenge I uploaded golang-github-joyent-gosign, golang-golang-x-xerrors, golang-gopkg-ldap.v3, golang-github-ovh-go-ovh

Emmanuel Kasper: PowerShell on Debian

8 June, 2019 - 18:18
I heard some time ago that Microsoft released their interactive and
scripting language PowerShell under an opensource license (MIT) but I completely missed that they were providing a repository and ready to use packages for your favorite distribution.

Anyway an apt-get away and that's it:



New-Object net.sockets.tcpclient("libera.cc", 80) opens a TCP connection to a target host, a quick way to test if a port is open ( look for Connected: True for a successful socket creation)

Benjamin Mako Hill: Sinonym

8 June, 2019 - 01:46

I’d like to use “sinonym” as another word for an immoral act. Or perhaps to refer to the Chinese name for something. Sadly, I think it might just be another word for another word.

Norbert Preining: Nessie Mystery: Finally Solved

7 June, 2019 - 20:04

The long standing mystery of Nessie, the Monster of Loch Ness, has finally been resolved! And that by my daughter of three years!

In a lovely present my daughter got recently in Berlin, a book full of sheep, in particular Shaun the Sheep (in German a so called “Wimmelbuch”), my daughter spotted Nessie on one of the images. It is clearly to be seen in the above image.

And with Sherlock Holmes worthy detectiveness, she realized the Nessie is in fact a sheep, and even more, it is Shaun. The reason is quite simple:

Both have this very strange mouth!

Finally the world can rest in peace.

Candy Tsai: Outreachy Week 1 – Week 3: Working Remotely is Hard

7 June, 2019 - 12:09

Time flies! I am already into the 3rd week of the internship, which is also a perfect time for a retrospective. This is an honest share to what working remotely has been like for me and also a report to record what I’ve been doing these three weeks.

About Working Remotely A walkthrough of my first few days

Woke up in the morning with a sense of guilt. It felt extremely weird not having to rush through the morning chores and get onto the train for work. At 10 I finally sat down on the couch in the living room, stared at the TV in front of me. Without much thought I turned it on and when it got turned off, it was already noon. “What the ****!”, my head was banging inside as more guilt poured into me.

“I really can’t go on like this”, my brain whispered to myself. Finally, I got up and cleaned out a room for “work”. Whenever I sit at this spot, it means I cannot do anything else but work.

Home used to be a place where only relaxation took place, it was super hard to concentrate on a task for more than one hour. I really had to physically clear out a space that’s exclusive for work and while at it I should do nothing else but work. Without a doubt it was guilt that pushed me forward during the first week.

11 hours of time difference

I have two mentors (terceiro and elbrus) and we live in three completely different time zones. The weekly sync meeting took place at 19:00 for me, which is 8:00 for terceiro and 13:00 for elbrus. Most of what I’m working on relates to terceiro, so that meant we have 11 hours of time difference.

To get through this, I made a decision to cut my time in half towards the end of week 2. I will work 6 hours in the day and 2 hours during midnight. This way, if I had to discuss or ask questions, I can have two chances each day. My mentors are also in full-time jobs, so I wouldn’t want to trouble them too much (but I still bump into issues every while and then).

Working out a system

I admit that I am not a person with good self control. In order to commit 40 hours to work each week, this is the current strategy I have started using at week 2.

  • Log what I did every day
  • Do not eat at “the working spot”
  • Make sure I have “off” hours
Log what I did every day

I tried to write a todo list every day, but that didn’t work out well for me. Sometimes I do get stuck on stuff, and that gives me a lot of pressure for not getting things “done”. At the end of the day, my morale got low and then the next day I started with no energy.

By logging what I did every day, especially the obstacles I bumped into and how it got solved kept me energetic, because I know I am learning something every day. When you didn’t do anything that day, meaning that the log is completely empty, guilt will build up and make sure you do something before the day ends.

Do not eat at “the working spot”

Not doing anything else at “the working spot” was actually quite easy except for eating. I thought I could get more done when I ate at my desk, but that was totally wrong. Before working remotely, taking a break after lunch was my habit. It’s not hard to imagine that after I finished lunch at “the working spot”, I started fumbling around and that put me into a late start for the afternoon.

Make sure I have “off” hours

This was the most difficult of all! “Decide for yourself when to work and when not to work”, this was probably a slogan to get people sold on working remotely. When there is no hard lines on getting to work and getting off work often becomes, working a bit the whole day. You feel like you are working or thinking about the project 24 hours, but it doesn’t seem like you have done much for a 24 hour workload.

Finally, after three weeks of adjustments, I think I can see the silver lining of how this is going to work. Hope all goes well until the end of the internship!

Week 1: Vagrant

During the application process, quite a few applicants were stuck at setting up the development environment for debci. I would like to improve the experience. At first, I used docker because I was more familiar with it. After finding an empty VagrantFile in the repository, I decided to try something new and went with vagrant. Learned some shell script and user permissions during the process and the biggest find was to use the debian/contrib-stretch64 box rather than debian/stretch64. The contrib version contains the guest addition stuff.

Week 2: Starting First Tasks

I worked on opening a self service section for users to requests tests themselves this week. Got stuck a little bit every step of the way, but not really stuck. Interesting finds that I would like to log.

  • For static file generation, create a symlink in public directory to the file to be generated in public/data/.html and add it to bin/debci-generate-html
  • Sinatra automatically loads layout.erb if it exists, and you can change set :views, <PATH> to change the default directory to store the erb files
  • In order to use Ruby to print to stdout when using foreman start you have to add $stdout.sync = true before the print runs
  • Use the general test API in order to fulfill all the user stories
  • Decide to use Ruby to generate dynamic HTML through erb templates, because it could be more customizable
  • Use Sinatra::ContentFor to seperate JavaScript files into the templates, and create dummy functions in lib/debci/html.rb for static file generation to work

Before the internship, I worked as a front end developer, which means JavaScript, JavaScript, and more JavaScript these days. Interesting when I found out that debci would also like the site to work perfectly without JavaScript functioning. This got me thinking about all those time we just neglected users who don’t enable JavaScript. I got curious and checked big sites like Facebook, Twitter, Gmail and found that you will get this big fat warning about turning off JavaScript. Although you get this big fat warning, they all left a “nonJS workable” version available, which is an interesting find.

Week 3: Searching, Pagination & UX

This week, besides the Self Service section, I also tried fixing the search package part of the index page. Currently it just takes what the user inputs and redirect them to the page which may or may not exist.

Things I did or should log down for this week:

We discussed and decided to work on non-JS versions of the Self Service Section. With JavaScript enabled, the UX will be more complicated which requires more time to generate the whole concept and I would like things to work first since it doesn’t exist yet.

That’s all for now, these weekly updates will start to come “weekly” after this post.

Reproducible builds folks: Reproducible Builds in May 2019

6 June, 2019 - 19:50

Welcome to the May 2019 report from the Reproducible Builds project! In our reports we outline the most important things which have been up to in and around the world of reproducible builds & secure toolchains over the past month.

As a quick recap, whilst anyone can inspect the source code of free software for malicious flaws, almost all software is distributed to end users pre-compiled. The motivation behind reproducible builds effort is to ensure no malicious flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing third-parties to come to a consensus on whether a build was compromised.

In this month’s report, we will cover:

  • Media coverageMore supply chain attacks, Reproducible Builds at conferences, etc.
  • Upstream newsMozilla updates their add-on policy, etc.
  • Distribution workDebian Installer progress, openSUSE updates.
  • Software developmentA try.diffoscope.org rewrite, more upstream patches, etc.
  • Misc newsFrom our mailing list, etc.
  • Getting in touchHow to contribute, contact details, etc.

If you are interested in contributing to our project, please visit our Contribute page on our website.

Media coverage

Upstream news

The IPFSPackage Managers Special Interest Group” is gathering research around package management, much of which is relevant to the Reproducible Builds effort.

Atharva Lele plans to work on reproducible builds for the Buildroot embedded Linux project as part of Google Summer of Code, ensuring that two instances of buildroot running with the same configuration for the same device yield the same result.

Mozilla’s latest update to the Firefox add-on policy now dictates that add-ons may contain “transpiled, minified or otherwise machine-generated code” but Mozilla needs to review a copy of the human-readable source code. The author must provide this information to Mozilla during submission along with instructions on how to reproduce the build.

Distribution work

Bernhard M. Wiedemann posted his monthly Reproducible Builds status update for the openSUSE distribution.

Holger Levsen filed a wishlist request requesting that Debian’s .buildinfo build environment specification documents from the Debian Long Term Support (LTS) project are also distributed by the build/archive infrastructure so that the reproducibility status of these security packages can be validated.

There was yet more progress towards making the Debian Installer images reproducible. Following-on from last months, Chris Lamb performed some further testing of the generated images and requested a status update which resulted in a call for testing the possible removal of a now-obsolete workaround that is hindering progress.

68 reviews of Debian packages were added, 30 were updated and 11 were removed this month, adding to our knowledge about identified issues. Chris Lamb discovered, identified and triaged two new issue types, the first identifying randomness in Fontconfig .uuid files [] and another randomness_in_output_from_perl_deparse.

Finally, GNU Guix announced its 1.0.0 release.

Software development Upstream patches

The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream wherever possible. This month, we wrote a large number of such patches, including:

Finally, Vagrant Cascadian submitted a patch for u-boot boot loader fixing reproducibility when building a new type of compressed image. This was subsequently merged in version 2019.07-rc2.

diffoscope

diffoscope is our in-depth “diff-on-steroids” utility which helps us diagnose reproducibility issues in packages. It does not define reproducibility, but rather provides a helpful and human-readable guidance for packages that are not reproducible, rather than relying essentially-useless diffs.

  • Chris Lamb:

    • Support the latest PyPI package repository upload requirements by using real reStructuredText comments instead of the raw directive [] and by stripping out manpage-only parts of the README rather than using the only directive [].

    • Fix execution of symbolic links that point to the bin/diffoscope entry point in a checked-out version of our Git repository by fully resolving the location as part of dynamically calculating Python’s module include path. []

    • Add a Dockerfile [] with various subsequent fixups [][][].

    • Published the resulting Docker image in diffoscope’s container registry and updated the diffoscope homepage to provide “quick start” instructions on how to use diffoscope via this image.

  • Mattia Rizzolo:

    • Uploaded version 115 to Debian experimental.
    • Adjust various build and test-dependencies, including specifying the ffmpeg video encoding tool/library and the Black code formatter [] in the build-dependencies [] and reinstating the oggvideotools and procyon-decompiler as test dependencies, now that are no-longer buggy [], etc.
    • Make the Debian autopkgtests not fail when a limited subset of “required tools” are temporarily unavailable. [][][]

In addition, Santiago Torres altered the behaviour of the tests to ensure compatibility with various versions of file(1) [] and Vagrant Cascadian added support for various external tools in GNU Guix [] and updated the version of diffoscope in that distribution [].

try.diffoscope.org

Chris Lamb made a large number of following changes to the web-based (“no installation required”) version of the diffoscope tool, try.diffoscope.org:

Test framework

We operate a comprehensive Jenkins-based testing framework that powers tests.reproducible-builds.org. The following changes were done in the last month:

  • Holger Levsen made the following (Debian-related changes):

    • Reduce the number of cron(8) mails for synchronising .buildinfo files from eight to one per day. []
    • Run rsync2buildinfos.debian.net script every other hour now that it just produces one mail per day. [][]
    • Execute the package scheduler every 2 hours (instead of 3). []
    • Switch the Codethink and OSUOSL nodes to use our updated email relay system. [][]
    • Deal with the (rare) cases of .buildinfo files with the same name. [][]
    • Save and mail the package scheduler results once a day instead of mailing ~8 times a day. []
  • In addition, Holger Levsen made the following distribution-agnositic changes:

    • Notify the #reproducible-builds (not #debian-reproducible) about Jenkins rebooting and send notifications about offline hosts to this former channel. [][]
    • Prevent the Jenkins log from growing to over 100G in size. []
  • Mattia Rizzolo:

    • Use a special code so that remote builds can abort themselves by passing back the command to the “master”. [][][][]
    • Fix a pattern matching bug to ensure all “zombie” processes are found. []
    • flake8 the chroot-installation.yaml.py file. []
    • Set a known HTTP User Agent for Git, so that server can recognise us. []
    • Allow network access for the debian-installer-netboot-images Debian package. []

Finally, Vagrant Cascadian removed the deprecated --buildinfo-id from the pbuilder(8) configuration. [] and Holger Levsen [][][][][][] Mattia Rizzolo [] and Vagrant Cascadian all performed a large amount of build node maintenance, system & Jenkins administration.

Project website

Chris Lamb added various fixes for larger/smaller screens [], added a logo suitable for printing physical pin badges [] and refreshed the opening copy text on our SOURCE_DATE_EPOCH page.

Bernhard M. Wiedemann then documented a more concise C code example for parsing the SOURCE_DATE_EPOCH environment variable [][] and Holger Levsen added a link to a specific bug blocking progress in openSUSE to our Who is involved? page [].

Misc news

Lastly, Sam Hartman, the current Debian Project Leader, wrote on the debian-devel mailing list:

The reproducible builds world has gotten a lot further with bit-for-bit identical builds than I ever imagined they would. []

Thanks, Sam!

Getting in touch

If you are interested in contributing the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:


This month’s report was written by Arnout Engelen, Bernhard M. Wiedemann, Chris Lamb, Holger Levsen, Mattia Rizzolo and Vagrant Cascadian & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

Debian GSoC Kotlin project blog: Converting build files to Groovy; week 2 update

6 June, 2019 - 18:51

I spent the first two weeks on updating build files of Kotlin to groovy so that we can reduce the dependency on kotlin-dsl while packaging Kotlin.

task("dist") is the task that we call in order to build Kotlin 1.3.30 so it would be enough to translate and deal with only those subprojects which are involed in the "dist" task graph. I wrote this code here find out exactly which tasks from which subprojects are being called; the build files of these subprojects are also shown.

There was a total of about 83 subprojects involved in the build process, out of these about 67 had build files written in kotlin-dsl. During this week I translated about 40 of those build files, so only 27 more remain. I have also translated the root projects build file. My work could be seen here.

The build logic for the build files are written in Kotlin and placed in the $rootDir/buildSrc directory. Kotlin supports writing custom extension functions like fun String.customfunction() but groovy doesnt support this behaviour, so I had to introduce intermediate functions for these functions in the build logic so that these function can be invoked from within the groovy buildfiles.

I am also ignoring all publishing code logic also the test logics that look like it may take a lot of time to translate. However I translate test logics as long as they don’t take up much time. Once I finish with translating business mostly by next week I will go on ahead with trying to build the project with only the relevant subprojects as child projects.

Also one thing I noticed is that I forgot to mention the source of intellij-core and the version we need to package Kotlin. Here is the source of intellij-core 183.5153 which is the version we need. Here is a link to the work I have done so far. You can find me as m36 or m36[m] on #debian-mobile and #debian-java in OFTC.

I’ll try to maintain this blog and post the major updates weekly.

Debian GSoC Kotlin project blog: Converting buildfiles to groovy; week 2 update

6 June, 2019 - 18:51

I spent the the first two weeks on updating build files of Kotlin to groovy so
that we can reduce the dependency on kotlin-dsl while packaging Kotlin.

task("dist") is the task that we call inorder to build Kotlin 1.3.30 so it would be
enough to translate and deal with only those subprojects which are involed in
the "dist" task graph. I wrote this code here find out exactly which tasks from
which subprojects are being called; the build files of these subprojects are also
shown.

There was a total of about 83 subprojects involved in the build process, out of
these about 67 had build files written in kotlin-dsl. During this week I
translated about 40 of those buildfiles, so only 27 more remain. I have also
translated the root projects build file. My work could be seen here.

The build logic for the build files are written in kotlin and placed in the
$rootDir/buildSrc directory. Kotlin supports writing custom extension functions
like fun String.customefunction() but groovy doesnt support this behaviour, so I
had to introduce intermediate functions for these functions in the build logic
so that these function can be invoked from within the groovy buildfiles.

I am also ignoring all publishing code logic also the test logics that look like
it may take a lot of time to translate. However I translate test logics as long
as they dont take up much time. Once I finish with translating business mostly
by next week I will go on ahead with trying to build the project with only the
relevant subporjects as child projects.

Also one thing I noticed is that I forgot to mention the source of intellij-core
and the version we need to package kotlin. Here is the source of intellij-core
183.5153 which is the version we need. Here is a link to the work I have done so
far. You can find me as m36 or m36[m] on #debian-mobile and #debian-java in OFTC.

I ll try to maintain this blog and post the major updates weekly.

Steve Kemp: Radio gaga, the odessy of automation

6 June, 2019 - 00:30

Recently I wanted to monitor the temperature and humidity of a sauna. I figured the safest way to go would be to place a battery-powered temperature/humidity sensor on a shelf, the kind of sensor that is commonly available on AliExpress for €1-5 each.

Most of the cheap "remote sensors" transmit their data over a short 433Mhz radio-transmission. So I just assumed it'd be possible to work something out.

The first step was to plug an SDR-dongle into my laptop, that worked just fine when testing, I could hear "stuff". But of course a Sauna is wood-lined, and beyond a tiled-shower area. In practice I just couldn't recieve the signal if my laptop lived in its usual location.

So I came up with a fall-back plan:

  • Wire a 433Mhz receiver to an ESP8266 device.
  • Sniff the radio-transmission.
    • Decode it
    • Inject into an MQ-host, via WiFi

Since the receiver could be within 10m of the transmitter I figured that would work fine - and it did. The real problem came when I tried to do this. There are a few projects you can find for acting as a 433Mhz -> WiFi bridge and none of them understood the transmission(s) my sensor was submitting.

In the end I had to listen for packets, work out the bit-spacing, and then later work out the actual contents of the packets. All by hand.

Anyway the end result is that I have something which will sniff the packets from the radio-transmitter, correctly calculate the temperature/humidity values and post them to MQ. From MQ a service polls the values and logs them to SQLite for later display. As a bonus I post to Slack the first time the temperature exceeds 50 &degree; a day:

  • "Hot? It's like a sauna in here."
  • "Main steam on, somebody set us up the beer."
  • etc.

Next week I'll talk about how I had a similar (read: identical) problem reacting to the 433Mhz transmission triggered by a doorbell. None of the gateways I looked at logged a thing when the button was pressed. So I'll have to save the transmission via rtl_433, analyze it with audacity, and do the necessary.

For reference these are the three existing firmwares/solutions/projects I tried; on a Wemos Mini D1:

  • https://github.com/xoseperez/espurna
  • https://github.com/arendst/Sonoff-Tasmota
    • Liked this one best for the UI.
  • https://github.com/1technophile/OpenMQTTGateway
    • This was sparse, but recommended too.
    • Tried two different modules: RF, RFPilight, wasn't clear what the difference was, no change anyway.

Gregory Colpart: Mini-DebConf Marseille 2019

5 June, 2019 - 20:15

We’ve had the idea to organize a mini-DebConf in Marseille when we were in Toulouse in 2017. After participating in many DebConfs (mini or not), getting into organizing such an event seemed a good way to give back and contribute to the Debian project.

Fast-forward to end of 2018. We’ve gathered a few motivated people and settled for a 50/70 participants event on May 25th/26th. We’ve chosen an appropriate venue in down-town Marseille. I won’t dwelve into organization details (call for speakers, sessions recording, scheduling…) since we plan to share our experience in a rather detailed “Howto organize a mini-DebConf” in the coming days/weeks.

It started on Wednesday 22nd, the wonderful DebConf video team arrived for a 3-days sprint. We had prepared a space for them to work at the venue. This gave a lot more time to setup the conference room than usual. But the main goal of the sprint was to teach new members of the team how to set everything up and be independent, in preparation of the upcoming mini-DebConf Hamburg a couple of weeks later.

On Friday 24th, the french localization team arrived for a 1-day sprint. Most of them had never met in person! They said this gave a huge boost to the team.

Most of the participants arrived Friday afternoon. The “Front Desk” was ready to welcome them with their badge and branded t-shirt. For ecological reasons, we’ve decided to restrict as much as possible useless goodies, like bags, pens or sponsors marketing material. A PDF booklet had been sent for participants to print at home if they wanted. The Debian France team had the usual goodies to sell at the front desk: mugs, hats, durable tote bags, stickers of all sizes…

On Friday evening, we’ve had a mini CheeseWineBOF with various local food (cheese, wine, pastis, olives, fruits, vegetables…) and some brought by participants. Thanks to Elena for the great italian cheese and also Judith and Tzafrir!

While the video team was struggling with a faulty cable making a ground loop, everyone was then invited to the Provence Linux Users Group meetup. Florence Devouard – a prominent member of the Wikipedia community – gave us a very nice presentation of the Wikipedia and Wikimedia history. The evening ended with a local tradition/specialty: pizzas of Marseille. The conference was already on the right track.

Saturday morning marked the official start of mini-DebConf! We opened the doors at 08:30 with a welcoming breakfast: home-made cookies, fresh coffee beans, fruit juice… During the whole weekend we’ve offered fresh, local, home-made vegetarian food. And with the goal to minimize waste we’ve chosen not to use any disposables. Besides durable dishes/glasses/cutlery, a lot of ceramic mugs were available with tape and pens to customize them and keep them around.

75 people registered. This was the maximum capacity of the venue. 73 people really came, which is a very good attendance rate, especially since it was an all-free conference, where people usually register without being sure to attend. We even had a few non-registered people.

Jérémy gave the welcome talk to a full room of Debian enthusiasts, with an overview of the schedule, presentation of the sponsors, reminder of the Code of Conduct and the photo policy, and various useful/important information…

The first session started at 10 am with a quite technical talk. Cyril Brulebois – Debian Installer release manager – presented how to visualize the migration of packages to Testing. He proposed a tool to visualize dependencies and “excuses” to help understand why a certain package might be blocked from migrating to Testing.

Then, Peter Green – co-founder of the Raspbian project – presented autoforwardportergit the tool he has made and is using to automate the creation of modified Debian packages for Raspbian.

After the coffee break, Raphaël Hertzog told us about 5 years of Debian LTS funding and what’s next. He explained the history of Debian LTS and how it works : managing the sponsors, spreading the workload between developers, the Extended LTS offer, the infrastructure… How to fund contributions in the Debian community is a hot topic which sparked a lot of questions, and even a Lightning Talk on Sunday.

During the lunch break – while the video team was training new volunteers to their tools – everyone was invited to a vegetarian (and mostly vegan) mediterranean buffet. We are very proud of offering home-made food, with local fresh products. Nothing was wasted and everyone was satisfied.

Benoît had organized a KSP (Key Signing Party) that took place after lunch. Approximately 20 people exchanged and verified their GPG key, to broaden their web of trust.

The second session started with Elena “of Valhalla” Grandi, presenting the ActivityPub protocol for federated social networks like Mastodon, Pixelfed, etc.

Coming from Madrid, Spain, Laura Arjona Reina presented the Debian Welcome Team and their work towards new participants in the Debian Project.

The Debian France organization was presented by Denis Briand – its newly elected president – to introduce the various projects and intended actions (eg. more frequent mini-DebConf events in France). Many people – including french people – discovered the existence of the organization and its important role in the whole Debian community as one of the few Trusted Organizations.

We continued with Frédéric Lenquette presenting « Hardening and Secure Debian Buster ». He explored all the opportunities to secure a Debian 10 setup.

For the final talk of the day, part of the french localization team (Thomas Vincent, Jean-Philippe Mengual and Alban Vidal) introduced us to their work : the workflow, what can be done by newcomers, etc.

Saturday evening – end of the first day – all the participants were invited to a social event at la Cane Bière, a beer place next to the venue, with a free drink for everyone (materialized by a token made from reused PCB). A few groups then formed and went to various restaurants.

Sunday morning, after another healthy breakfast, part of the DebConf video team (Nicolas Dandrimont and Louis-Philippe Véronneau) presented their amazing hardware and software setup. Everything is documented and as much free software as possible.

A series of 6 Lightning Talks, organized by Eda covered many various technical and non-technical topics : « kt-update » (Jean-François Brucker), « the Debian Constitution » (Judit Foglszinger), « Elections, Democracy, European Union » (Thomas Koch), « voting methods in Debian » (Raphaël Hertzog), « encrypt the whole disk with LUKS2 » (Cyril Brulebois), « OMEMO – the big fish in the Debian bowl » (Martin) and « Paye ton Logiciel Libre » (Victor).

After some closing remarks by Jérémy, it was already time to pack the video gear. A “brown bag lunch” was available. Some wanted to stay at the venue, to talk, hack… Some were already on their way back home. Many others had registered for a mini Day Trip ; they went down the main avenue of Marseille, to board for the Frioul islands for a good walk in the sun and a quick swim in the sea.

We sincerely want to thank a lot of people for this amazing weekend. Thank you to all 75 participants who came from all around the world (Canada, USA, Israel, UK, Germany, Italy, Spain, Switzerland, Belgium, Australia…). Thank you to the great video team who makes an amazing job capturing and streaming the content of many Debian events. Thank you to Debian France for organizing the event and to the sponsors : Bearstech, Logilab and Evolix. Thank you to La Maison du Chant for the great venue. Thank you to Valentine and Celia for the delicious and much complimented food. Thank you to Florence Devouard for the nice presentation Friday night. Thank you to all the speakers for the time and effort they put to make great content. Thank you to all volunteers who helped making this a great community event : Tristan, Anaïs, Benoît, Juliette, Ludovic, Jessica, Éric, Quentin F. and Jérémy D., with a special mention to Eda, Moussa, Quentin L. and Alban for their involvement and dedication and finally thank you to Sabiha and Jérémy L. who jumped with me in this crazy adventure many months ago : you rock!

Twitter : https://twitter.com/MiniDebConf_MRS
Mastodon : https://mamot.fr/@minidebconf_mrs
Photos : https://minidebcloud.labs.evolix.org/apps/gallery/s/keMJaK5o3D384RA
Videos : http://meetings-archive.debian.net/pub/debian-meetings/2019/miniconf-marseille/

Jonas Meurer: debian lts report 2019.05

5 June, 2019 - 00:24
Debian LTS report for May 2019

This month I was allocated 17 hours. I spent 15.25 hours on the following issues:

  • DLA 1766-1: OpenPGP signature spoofing in evolution. On this issue I actually spent way more time than expected during April. I took over some of the remaining hours to May.
  • DLA 1778-1: Several vulnerabilities in symfony, a PHP web application framework.
  • DLA 1791-1: Several vulnerabilities in drupal7, a PHP web site platform.
Links

Petter Reinholdtsen: Official MIME type "text/vnd.sosi" for SOSI map data

4 June, 2019 - 14:20

Just 15 days ago, I mentioned my submission to IANA to register an official MIME type for the SOSI vector map format. This morning, just an hour ago, I was notified that the MIME type "text/vnd.sosi" is registered for this format. In addition to this registration, my file(1) patch for a pattern matching rule for SOSI files has been accepted into the official source of that program (pending a new release), and I've been told by the team behind PRONOM that the SOSI format will be included in the next release of PRONOM, which they plan to release this summer around July.

I am very happy to see all of this fall into place, for use by the Noark 5 Tjenestegrensesnitt implementations.

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Mike Gabriel: My Work on Debian LTS/ELTS (May 2019)

3 June, 2019 - 19:49

In May 2019, I have worked on the Debian LTS project for 23.75 hours (as planned) and on the Debian ELTS project for another 10 hours (as planned) as a paid contributor.

LTS Work
  • Upload to jessie-security: 389-ds-base (DLA 1779-1), 1 CVE [1]
  • Upload to jessie-security: qt4-x11 (DLA 1786-1), 5 Hours CVEs [2]
  • Upload libav to jessie-security (DLA 1809-1), 2 CVEs [3]
  • Prepare a test-build for qemu [4]. Testing still pending.
  • Prepare a test-build for mupdf [5]. Testing still pending.
  • Triaging of open CVEs for 12 packages
ELTS Work
  • Dive deeply into questionable issues that were open for pacemaker.
    • CVE-2018-16877/pacemaker -> not affected
    • CVE-2018-16878/pacemaker -> ignored -> not affected
  • Upload to wheezy-lts: sqlite3 (ELA 123-1), 1 CVE [6]
  • Upload to wheezy-lts: glib2.0 (ELA 125-1), 1 CVE [7]
References

Julien Danjou: Advanced Functional Programming in Python: lambda

3 June, 2019 - 17:19

A few weeks ago, I introduced you to functional programming in Python. Today, I'd like to go further into this topic and show you so more interesting features.

Lambda Functions

What do we call lambda functions? They are in essence anonymous functions. In order to create them, you must use the lambda statement:

>>> lambda x: x
<function <lambda> at 0x102e23620>

In Python, lambda functions are quite limited. They can take any number of arguments; however they can contain only one statement and be written on a single line.

They are mostly useful to be passed to high-order functions, such as map():

>>> list(map(lambda x: x * 2, range(10)))
[0, 2, 4, 6, 8, 10, 12, 14, 16, 18]

This will apply the anonymous function lambda x: x * 2 to every item returned by range(10).

functools.partial

Since lambda functions are limited to being one line long, it's often that they are used to specialize longer version of an existing function:

def between(number, min=0, max=1000):
    return max > number > min

# Only returns number between 10 and 1000
filter(lambda x: between(x, min=10), range(10000))

Our lambda is finally just a wrapper of the between function with one of the argument already set. What if we would have a better way, without the various lambda limitations, to write that? That's where functools.partial comes handy.

import functools
def between(number, min=0, max=1000):
    return max > number > min

# Only returns number between 10 and 1000
atleast_10_and_upto = functools.partial(between, min=10)
# Return number betweens 10 and 1000
filter(atleast_10_and_upto, range(10000))

# Return number betweens 10 and 20
filter(lambda x: atleast_10_and_upto(x, max=20), range(10000))

The functools.partial function returns a specialized version of the between function, where min is already set. We can store them in a variable, use it, reuse it, as much as we want. We can pass it a max argument, as shown in the second part — using a lambda! You can mix and matches those two as you prefer and what seems clearer for you.

Common lambda

There is a type of lambda function that is pretty common: the attribute or item getter. They are typically used a key function for sorting or filtering.

Here's a list of 200 tuples containing two integers (i1, i2). If you want to use only i2 as the sorting key, you would write:

mylist = list(zip(range(40, 240), range(-100, 100)))

sorted(mylist, key=lambda i: i[1])

Which works fine, but make you use lambda. You could rather use the operator module:

import operator

mylist = list(zip(range(40, 240), range(-100, 100)))

sorted(mylist, key=operator.itemgetter(1))

This does the same thing, except it avoids using lambda altogether. Cherry-on-the-cake: it is actually 10% faster on my laptop.

I hope that'll make you write more functional code!

Petter Reinholdtsen: The space rover coquine, or how I ended up on the dark side of the moon

3 June, 2019 - 04:55

A while back a college and friend from Debian and the Skolelinux / Debian Edu project approached me, asking if I knew someone that might be interested in helping out with a technology project he was running as a teacher at L'école franco-danoise - the Danish-French school and kindergarden. The kids were building robots, rovers. The story behind it is to build a rover for use on the dark side of the moon, and remote control it. As travel cost was a bit high for the final destination, and they wanted to test the concept first, he was looking for volunteers to host a rover for the kids to control in a foreign country. I ended up volunteering as a host, and last week the rover arrived. It took a while to arrive after it was built and shipped, because of customs confusion. Luckily we were able fix it quickly with help from my colleges at work.

This is what it looked like when the rover arrived. Note the cute eyes looking up on me from the wrapping

Once the robot arrived, we needed to track down batteries and figure out how to build custom firmware for it with the appropriate wifi settings. I asked a friend if I could get two 18650 batteries from his pile of Tesla batteries (he had then from the wrack of a crashed Tesla), so now the rover is running on Tesla batteries.

Building the rover firmware proved a bit harder, as the code did not work out of the box with the Arduino IDE package in Debian Buster. I suspect this is due to a unsolved license problem with arduino blocking Debian from upgrading to the latest version. In the end we gave up debugging why the IDE failed to find the required libraries, and ended up using the Arduino Makefile from the arduino-mk Debian package instead. Unfortunately the camera library is missing from the Arduino environment in Debian, so we disabled the camera support for the first firmware build, to get something up and running. With this reduced firmware, the robot could be controlled via the controller server, driving around and measuring distance using its internal acoustic sensor.

Next, With some help from my friend in Denmark, which checked in the camera library into the gitlab repository for me to use, we were able to build a new and more complete version of the firmware, and the robot is now up and running. This is what the "commander" web page look like after taking a measurement and a snapshot:

If you want to learn more about this project, you can check out the The Dark Side Challenge Hackaday web pages.

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Ben Hutchings: Debian LTS work, May 2019

3 June, 2019 - 01:39

I was assigned 18 hours of work by Freexian's Debian LTS initiative and worked all those hours this month.

I released Linux 3.16.66, and then prepared and released Linux 3.16.67 with a small number of fixes. I backported the updated Linux 4.9 packages from Debian 9.9, uploaded them and issued DLA-1771.

I had a little advance notice of the MDS speculative execution flaws, and started backporting the mitigations for these to older stable branches, starting with a version for Linux 4.14. I backported to 4.9 (Debian stretch/jessie) first, then to 4.4 (CIP) and 3.16 (Debian jessie). The charge for this time was accordingly split between CIP and Freexian.

I backported the security update for Linux 4.9 from stretch to jessie and issued DLA-1787.

The backport of mitigations to Linux 3.16 took longest to finish, as the x86 kernel exit path was substantially rewritten between 3.16 and 4.4. I needed to apply the mitigation in multiple assembly-language routines rather then a single C function, and before that I needed to backport support for static_branch patching in assembly-language source files. I sent the changes out for review and testing as Linux 3.16.68-rc1, and as Debian packages on people.debian.org. Since no problems were found, I released Linux 3.16.68, uploaded updated packages, and issued DLA-1799.

Utkarsh Gupta: Becoming a Debian Maintainer in 90 days!

2 June, 2019 - 11:00

NOTE: I know this should have been posted long, long back :(
However, life happened and I couldn’t. Anyway, here it goes..

I started contributing to open source around a year back and on 1st January 2019 to Debian, specifically (wasn’t really a new year resolution, though :P).
I’ll be honest here. The reason behind taking the “Debian road” was solely to distract myself from the mental abuse I was going through.

Raju was the person who started helping me out, both, personally and professionally. He’s the one who taught me packaging from scratch with utmost patience and kept answering all my stupid doubts :D
To be honest, if it weren’t for him, I wouldn’t have been here, at this position today.

Since I wanted to distract myself from various stuff, I learned things quickly and kept working, consistently.
I turned up on IRC every single day since then. Praveen became both, my guru and my package sponsorer. He kept uploading and I kept packaging. This went on for a month until my difficulty level was bumped. From basic Ruby gems and Node libraries, I was given gems and modules that had test failures to debug and had a weirdly different build system. This made me uncomfortable. I complained. To which, Praveen said and I quote,
"If you want to keep working on simple stuff, then it's not gonna help you move forward. And it's your loss. No one else would care. So it's your call."

There was probably no option there, was it? :P
I took it on. Struggled for a few days but it became normal and I made it through. Like they say, “It gets better :)”, it did!
I took a little more challenging stuff, understood more concepts. Fixed test failures, RC bugs and learned a lot of stuff (still a lot, lot more to learn, though) in the process, like understanding about the Debian release cycle, how the migration of package takes place, setting up your own repositories, et al.

In this process, I also met another JS guru, Xavier. He did not only corrected my mistakes and sponsored my packages, but also helped me in actually understanding a lot of things. From the mailing list, we started conversing over private mail threads and soon, in a span of 3 months, the thread stretched over to 300 mails!

In early March, I was told that I could apply for the position of the Debian Maintainer, if only I understood the process of when to upload a package to experimental and when to unstable. I was given a few packages as a test by Praveen for the same.
And luckily, I passed. This meant that the only part remaining was to fulfil the initial keysigning requirement. For which, there was a Mini DebConf, Delhi around the corner.

As it happened, Praveen, Abhijith, and Sruthi came to the Mini DebConf from Kerala and I got my keys signed by them! :D
Soon after, I applied for becoming a DM.

I was lucky enough to get 3 advocates, Praveen, Xavier, and Abhijith.
Here’s my NM Process (#605).
And in a few days, I realized that I became the youngest Debian Maintainer in India \o/

I thank myself for being consistent, no matter what I started for :P
Also, much thanks to Sanyam. He really kept me going. Also, to Jatin and Sakshi.

Lastly, thanks to the Debian community. Debian has really been an amazing journey, an amazing place, and an amazing family. I am just hoping to make it to DebConf and meet all the people I adore \o/

Until next time.
:wq for today.

Louis-Philippe Véronneau: mini-DebConf Marseille 2019

2 June, 2019 - 11:00

I was in Marseille last week for the mini-DebConf the fine folks at Debian France organised and it was great! It was my first time there and I really enjoyed the city.

The venue was lovely and perfectly adapted to the size of the conference. The main auditorium was joy to work in: blinds on the windows to minimize the sun glare, a complete set of stage lighting and plenty of space to set up our gear.

If you couldn't attend the conference, you can always watch the talks on our video archive.

The highlight of my trip was the daytrip to the nearby Frioul archipelago. Although we repeatedly got attacked by angry seagulls (they were protecting their chicks), the view from the south shore of the Pomègues Island was amazing. It was also the first time I went on a daytrip during a mini-DebConf and I think it should happen more often!

If you ever are in Marseille and are looking to have a good time culinary-wise, I really recommend booking a table at La Boîte à sardine, a local fish restaurant. It's a little expensive, but the fish and shellfish we ate was definitely worth paying for.

For something a little less hard on your wallet, Le Resto Provençal serves amazing local Provençal cuisine at very reasonable prices. We went there with a large group and everyone really enjoyed their meal.

Finally, if you want to have a beer afterwards, La Cane Bière is one (if not the best) place in Marseille to drink craft beer. They have a wide selection of local beers on tap and also sell many bottles from all over Europe. Note that they close at 22:00 though, even during weekends.

Thanks again to the local team for hosting us, I really had a good time!

Utkarsh Gupta: Becoming a Debian Maintainer in 90 days!

2 June, 2019 - 11:00

NOTE: I know this should have been posted long, long back :(
However, life happened and I couldn’t. Anyway, here it goes..

I started contributing to open source around an year back and on 1st January 2019 to Debian, specifically (wasn’t really a new year resolution, though :P).
I’ll be honest here. The reason behind taking the “Debian road” was solely to distract myself from the mental abuse I was going through.

Raju was the person who started helping me out, both, personally and professionally. He’s the one who taught me packaging from scratch with utmost patience and kept answering all my stupid doubts :D
To be honest, if it weren’t for him, I wouldn’t have been here, at this position today.

Since I wanted to distract myself from various stuff, I learnt things quickly and kept working, consistently.
I turned up on IRC every single day since then. Praveen became both, my guru and my package sponsorer. He kept uploading and I kept packaging. This went on for a month until my dificulty level was bumped. From basic Ruby gems and Node libraries, I was given gems and modules that had a test failures to debug and had a weirdly different build system. This made me uncomfortable. I complained. To which, Praveen said and I quote,
"If you want to keep working on a simple stuff, then it's not gonna help you move forward. And it's your loss. No one else would care. So it's your call."

There was probably no option there, was it? :P
I took it on. Struggled for a few days but it became normal and I made it through. Like they say, “It gets better :)”, it did!
I took a little more challenging stuff, understood more concepts. Fixed test failures, RC bugs and learned a lot of stuff (still a lot, lot more to learn, though) in the process, like understanding about the Debian release cycle, how the migration of package takes place, setting up your own repositories, et al.

In this process, I also met another JS guru, Xavier. He did not only corrected my mistakes and sponsored my packages, but also helped me in actually understanding a lot of things. From the mailing list, we started conversing over private mail threads and soon, in a span of 3 months, the thread stretched over to 300 mails!

In the early March, I was told that I could apply for the position of the Debian Maintainer, if only I understood the process of when to upload a package to experimental and when to unstable. I was given a few packages as a test by Praveen for the same.
And luckily, I passed. This meant that the only part remaining was to fulfil the initial keysigning requirement. For which, there was a Mini DebConf, Delhi around the corner.

As it happened, Praveen, Abhijith, and Sruthi came to the Mini DebConf from Kerala and I got my keys signed by them! :D
Soon after, I applied for becoming a DM.

I was lucky enough to get 3 advocates, Praveen, Xavier, and Abhijith.
Here’s my NM Process (#605).
And in a few days, I realized that I became the youngest Debian Maintainer in India \o/

I thank myself for being consistent, no matter what I started for :P
Also, much thanks to Sanyam. He really kept me going. Also, to Jatin and Sakshi.

Lastly, thanks to the Debian community. Debian has really been an amazing journey, an amazing place, and an amazing family. I am just hoping to make it to DebConf and meet all the people I adore \o/

Until next time.
:wq for today.

Junichi Uekawa: What have I been doing recently?

2 June, 2019 - 07:40
What have I been doing recently? I was reading up on Zip file format and history which brings back so much memory. Wondered if EOC parsing is deterministic or not.

Pages

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