Search Results: "tar"

10 March 2016

Michal Čihař: Weblate 2.5

After almost six months of development Weblate 2.5 has been released. It brings lot of improvements and it's quite hard to point few ones. The most important ones include support for Python 3, reports generators, placeables highlighting, extended keyboard shortcuts, configurable dashboard or group based ACLs. Full list of changes for 2.5: If you are upgrading from older version, please follow our upgrading instructions. You can find more information about Weblate on https://weblate.org, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Weblate is also being used https://hosted.weblate.org/ as official translating service for phpMyAdmin, OsmAnd, Aptoide, FreedomBox, Weblate itself and many other projects. Should you be looking for hosting of translations for your project, I'm happy to host them for you or help with setting it up on your infrastructure. Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far! The roadmap for next release is just being prepared, you can influence this by expressing support for individual issues either by comments or by providing bounty for them.

Filed under: English Weblate 0 comments

9 March 2016

Guido G nther: Contatacs, CardDAV, Calypso and the N900

As a follow up to calendar synchronisation with calypso, syncevolution and the N900 running maemo I finally added contacts to the mix: on the phone When you have the calendar sync already running it's as simple as: First start ssh on the n900 to ease typing: 
apt-get install dropbear
echo /bin/sh >> /etc/shells
cd /etc/dropbear && ./run
SSH into the phone and configure contacts synchronization: 
cat <<EOF > ~/.config/syncevolution/webdav/sources/addressbook/config.ini
backend = CardDAV
database = https://carddav.example.com/contacts/username
EOF
And perform the initial sync: 
syncevolution --sync slow webdav addressbook
From there on you can sync contacts and calendars in one go with: 
syncevoluton webdav
Looking at the calypso logs on the server it seems that syncevoluton does not always generate an FN entry and so the card gets skipped. This doesn't harm the overall sync, but I need to have a look how to fix this. on the laptop In order to use the contacts im mutt there's pycarddav packaged in Debian. This is basically following upstreams documentation. 
sudo apt-get install pycarddav
mkdir -p ~/.config/pycard
cp /usr/share/doc/pycarddav/examples/pycard.conf.sample ~/.config/pycard/pycard.conf
# Edit file as needed
cat ~/.config/pycard/pycard.conf
[Account username]
user: username
resource: https://carddav.example.com/
write_support = YesPleaseIDoHaveABackupOfMyData
[query]
where: vcard
[sqlite]
[default]
debug: False
To use the entries in mutt add the just extend your .muttrc: 
cat <<EOF >>~/.muttrc
set query_command="pc_query -m %s"
macro index,pager B "<pipe-message>pycard-import<enter>" "add sender address to pycardsyncer"
EOF
This allows you to query contacts using Q and add new conatcs with CTRL-B in mutt's index and pager. Calypso Changes We recently moved calypso's git repository to alioth and started to merge several out of tree patches. More will happen during this years Debian Groupware Meeting including a new upload to Debian.

8 March 2016

Tassia Camoes Araujo: Some impressions of a flourishing community bits from the MiniDebConf Curitiba @ Montreal

Last month I more-or-less accepted an invitation that got me scared at first, panicking after a while. Why do I put myself in such an uncomfortable position? Well, I think that s how we grow up ;-) I was first contacted to talk about women participation in Debian, which I kindly refused, but I said I would maybe talk about motivating new contributors, possibly with some more friends that would maybe join me at the stage. I need to confess that at that moment I had no idea (ok, a vague idea ) about what I was going to talk. So I promptly emailed some Debian friends, shared the invitation, shared some thoughts, got feedbacks, got encouragement, and we finally made it! talk_transmission For the video conference we used mconf.org which worked super well (the downside is that it requires flash, maybe you could help them get rid of it?). I had also recorded a backup video with vokoscreen, just in case Murphy would decide to go to Curitiba but everything worked well. We a single moment with connection issues, but the torrent user kindly released the bandwidth The main point I made in the talk is that Debian as a Universal Operating System is still an utopia, especially when we extend our understanding of universality to our contributors. And as an utopia, it serves to make us walk! The more we advance, the more it gets further away, so we need to keep walking. Another important point was that diversity is not an issue that touches only woman. My audience was full of Portuguese native speakers, from a third world country, a few women, many more man, a couple of DDs, some longtime contributors, some newbies, and most of them are also part of minorities in our community. I bet many of them has already felt like a weed growing surrounded by concrete at least once in their lifetimes Solidarity towards our utopia was my final message. Just for fun, and to make a recap of our conversation at the end, I made a list of 10 steps that we could all give to contribute to a more universal Debian: 1. Read our Social Contract and make sure we are all at the same page
2. Improve Debian documentation
3. Remember that diversity does not concern only women
4. Keep an eye on minority groups and show solidarity
5. Be open and alert to the needs of newbies
6. Help Debian teams to be prepared to welcome new contributors
7. Reserve part of our time to integrate new members to the community
8. Promote hands-on meetings (local and remote)
9. Promote peer-mentoring among newbie contributors
10. Do not see Debian members as special beings, we are all humans! You can check my slides or the video of the live transmission if you want to see more. In case you can not follow the audio, I d be happy to provide subtitles (but I probably won t work on that if I don t receive have any request). And if you invite me to another conference, we can have a similar chat at with your community. Note: in person is more fun ;-) Finally, I d like to thank the participants of the mini-DebConf, those that followed this session and those who were practicing how to package on the other room, Paulo Santana and all the local organization team for the invitation, Ana Guerrero and Laura Arjona for the remote support and feedback, Andreas Tille for the efforts in integrating new contributors, Christian Perrier for the developer statistics, Val ssio for being in the audience and the Debian Project for the inspiration. What we had we Brazil this weekend was a taste of a flourishing and welcoming community, I am proud and honored to be part of it!

7 March 2016

Holger Levsen: 20160307-TorDevMeeting and InternetFreedomFestival

Some impressions from the TorDevMeeting and the Internet Freedom Festival (IFF) in Valencia Overheard at the Tor Dev meeting in Valencia, from people speaking about online identities: "You were on top of the list of the people I thought were you." It was really good to be there as my plan to meet people and work on torbrowser-launcher issues worked out nicely: in total seven bugs got fixed upstream and resulted in an torbrowser-launcher upload to sid after the meeting. So now only three bugs are open in sid and it's clear how to fix #811499 in stable so that torbrowser-launcher doesn't stop working on May 3rd 2016. So yay. At the IFF we also had a small reproducible builds Debian meeting, where I took these raw notes: (please ask for clarifications, how to help or correct me if you think other things are blockers right now as well!) Too bad IFF was not really well known in advance amongst some local free software advocates, I hope this improves next year!

Laura Arjona Reina: More involved in the Debian Publicity team

More than 6months since I am Debian Developer and I m learning new things every day and trying to organize my time better to accomplish all the things I would like to do.
In September I became publicity delegate (and we joined Press+Publicity into the Publicity team). We continued discussing how the team works, and hopefully revitalizing it.
I became more active in the IRC channel, installed quassel in my home server and then I could read all the backlog too.
I ve tried to contribute more to Debian Project News (less than I d like), to bits.debian.org and to the social networks (Pump.io and GNU Social).
Since November I ve been failing to call for meeting but finally on 2016/02/29 we had it. I hope to resume semi-regular meetings each 1-2 months.
At the beginning of the year I helped to handle all the news and announcements about the loss of Ian Murdock. It has been hard work but I feel that I could turn some of the sadness into something useful for others. There is still work to be done: parse the condolence emails and setup a website to publish them.
About bits.debian.org, DPN and announcements, I ve learned how to perform the parts of the work that require membership permissions (building the blog, actually publishing the announcement, sending the DPN/announcement mail to the corresponding lists). Not without mistakes, but I guess no matter how much you care, sometimes things happen, and then you learn and then things get better and you too.
Some things I discovered Some clarifications
  • I ve written hard word 4 times in this post (well, 5 now!) but that does not mean I don t want to do those tasks. I feel going out of my comfort zone and that s ok, needed to learn and experience. I m having a good time in Debian in the last months, as always!
  • We re 4 people delegated and more team members and contributors, so anybody could think: Publicity is well covered, let s go to do other things in Debian . It s perfectly ok if you want to do other things in Debian, but please consider combining your contributions with some minutes for the publicity team. Aiming to be the universal operating system, our community and target audience is big and diverse and we d like to show that diversity to the world. The more we are, the merrier!
Comments?
You can comment about this blog post in this pump.io thread.

Filed under: My experiences and opinion Tagged: Communities, Contributing to libre software, Debian, Developer motivations, English, Free Software

Ritesh Raj Sarraf: Laptop Mode Tools 1.69 Released

Today is an auspicious day. For those who know (or follow) the Hindu religion will be familiar; Today is Maha Shivaratri On this day, It is great delight for me to be able to release Laptop Mode Tools, version 1.69 This release adds on many bug fixes and some enhancements. There is a new module (disabled by default) for cpuhotplug. The release tarball also includes a basic PolicyKit file for convenience, that packagers can use for the Laptop Mode Tools Graphical Configuration Interface. Apart from the policykit file, the graphical invocation script has been slightly fine tuned to work under pkexec and sudo. Some defaults have been tuned based on user requests - This should improve in situations where your External USB Mouse/Keyboard used to suspend after idle time periods. In January this year, I had the pleasure of meeting Bart Samwel in person at his office in Amsterdam. For those who don't know, Bart started off Laptop Mode Tools around 2004, and I took over maintenance around 2008. Meeting in person has been a delight, especially with the ones you work over email for years; This is something I cherished last year at Debconf 15 too. IMPORTANT:- Until now, Laptop Mode Tools project was hosted on Bart's webserver. Now, as you read, the homepage and mailing lists have changed. I'd urge all users to subscribe to the new mailing list and update their bookmarks. Homepage: https://github.com/rickysarraf/laptop-mode-tools/wiki Mailing List: https://groups.google.com/d/forum/laptop-mode-tools Note: For users who are not comfortable with creating a google a/c for mailing list subscription, you should still be able to subscribe with your personal email address. Please follow the steps in the mentioned homepage. Since last couple releases, I've also been providing RPM packages for Opensuse Tumbleweed and Fedora. The same should be available on the github release page. The Debian package will follow shortly in the Debian repository. Thank you and a Happy Maha Shivaratri. Har Har Mahadev. 
1.69 - Mon Mar  7 17:44:42 IST 2016
    * Wait for all forked modules to complete
    * Add new module: cputhotplug
    * CPU online/offine is reverse here
    * Fix shell syntax
    * Install policykit file
    * Detach polling daemon from main process
    * Do NOT touch speed if throttling is not set
    * Restore to MAX speed when back to AC Power
    * Fix manpage about DISABLE_ETHERNET_ON_BATTERY setting
    * Update documentation about ENABLE_LAPTOP_MODE_ON_AC setting
    * Change powersaving default for USB class devices
    * Drop usbhid from default (black)list
    * Add usb keyboard driver to the list default list
    * Be consistent with passing args to LMT from different invokers
    * Honor device plug/unplug events on a per device basis;
      like how Chromium initially submitted this patch
    * Also be consistent with option in the event parser
    * Update links in README.md
    * Update new github homepage location
    * Add lmt-config-gui shell script

Categories:

Keywords:

Like:

Hideki Yamane: Debian meeting in Tokyo (2016 March)

5th March, we've held Debian (Debian meeting) in Tokyo. (Cybozu, Inc.) kindly provides their office for meeting, thanks for folks in Cybozu.



This time, three talks were given:

    • Kentaro is "groonga"(an open-source fulltext search engine and column store) upstream author and package maintainer in Debian and Fedora. This talk is about his experience how to use Debian "porterbox" for non-DDs.
  • "Porting Debian to tilegx" by @wskoka
    • About his experience porting Debian to tilegx architecture, multicore processor family by Tilera. He is not porting expert ("I'm sale person", he said :), but did try&error and now apt is working on that machine.
  • "Introduction to Debian Ports" by John Paul Adrian Glaubitz
    • Adrian comes from Germany(!) and gave a talk about debian-ports.


During break time, did some discussion, GPG keysigning and enjoyed coffee and sweets provided by Cybozu, thanks!

And thanks for all participates!

6 March 2016

Enrico Zini: Live preview of Markdown documentation

At work, to simplify build dependencies of DB-All.e we decided to port the documentation from LaTeX to Markdown. Shortly after starting with the porting I resented not having a live preview of my work. I guess I got addicted to it with staticsite. Actually, staticsite does preview interlinked Markdown files. I wonder if GitHub supports cross-linking between Markdown files in the same repo? It does, and incidentally it uses the same syntax as staticfile. It shouldn't take long to build a different front-end on top of the staticsite engine just for this purpose. Indeed it didn't take long: here it is: mdpreview. So, as you are editing the README.md of your project, you can now run mdpreview in the project directory, and you get live preview on your browser. If your README.md links to other documentation in your project, those links will work, too. mdpreview uses the same themes as staticsite, so you can even tweak its appearance. And if you need to render the documentation and put it online somewhere, then staticsite can render it for you. I experimented with it splitting staticsite's documentation into several parts, a I had great fun with it. So, you want live preview of your project's Markdown documentation? mdpreview When you are happy with it you can commit it to GitHub and it will show just fine. You want it to show on your website instead? Build it with staticsite. I'm considering merging staticsite and mdpreview somehow. Maybe mdpreview could just be a different command line front-end to staticsite's functionality. That's food for though for the next days. Would you prefer to preview something else instead of Markdown? There is actually nothing markup specific in staticsite, so you can take this file as inspiration and implement support for the markup language of your choice in this whole toolchain. Except maybe for GitHub's website: that doesn't run on staticsite (yet).

Jaldhar Vyas: 7DRL 2016

It's time once again for the annual 7 Day Roguelike Challenge. I know I said I wasn't going to take part again until I properly finished one of my previous entries but I've thought of an interesting and novel game mechanic that I'm eager to try out so what the hell. If you are interested in following my progress, I will blog about it here starting from Monday and (hopefully successfully) finishing on the following Sunday. Of course the best part of it is coming up with names. Here are this years choices:
  • letsen[terthe]crypt
  • Make Narnia Great Again
  • Thane of Groans
  • I Am The Black Wizards

Thorsten Glaser: mksh R52c, paxmirabilis 20160306 released; PA4 paper size PDF manpages

The MirBSD Korn Shell R52c was published today as bugfix-accumulating release of low upto medium importance. Thanks to everyone who helped squashing all those bugs; this includes our bug reporters who always include reproducer testcases; you re wonderful! MirCPIO was also resynchronised from OpenBSD, to address the CVE-2015- 1193,1194 test cases, after a downstream (wow there are so many?) reminded us of it; thanks!
This is mostly to prevent extracting ../foo either directly or from a symlink(7) from actually ending up being placed in the parent directory. As such the severity is medium-high. And it has a page now initially just a landing page / stub; will be fleshed out later. Uploads for both should make their way into Debian very soon (these are the packages mksh and pax). Uploading backports for mksh (jessie and wheezy-sloppy) have been requested by several users, but none of the four(?) DDs asked about sponsoring them even answered at all, and the regular (current) sponsors don t have experience with bpo, so SOL I ve also tweaked a bug in sed(1), in MirBSD. Unfortunately, this means it now comes with the GNUism -i too: don t use it, use ed(1) (much nicer anyway) or perlrun(1) -p/-n Finally, our PDF manpages now use the PA4 paper size instead of DIN ISO A4, meaning they can be printed without cropping or scaling on both A4 and US-american letter paper. And a from the last announcement: we now use Gentium and Inconsolata as body text and monospace fonts, respectively. (And propos, the website ought to be more legible due to text justification and better line spacing now.) I managed to hack this up in GNU groff and Ghostscript, thankfully. (LaTeX too) Currently there are PDF manpages for joe (jupp), mksh, and cpio/pax/tar. And we had Gr nkohl today! Also, new console-setup package in the WTF APT repository since upstream managed to do actual work on it (even fixed some bugs). Read its feed if interested, as its news will not be repeated here usually. (That means, subscribe as there won t be many future reminders in this place.) The netboot.me service appears to be gone. I ll not remove our images, but if someone knows what became of it drop us a message (IRC or mailing list will work just fine). PS: This was originally written on 20160304 but opax refused to be merged in time Happy Birthday, gecko2! In the meantime, the Street Food festival weekend provided wonderful food at BaseCamp, and headache prevented this from being finished on the fifth. Update 06.03.2016: The pax changes were too intrusive, so I decided to only backport the fixes OpenBSD did (both those they mentioned and those silently included), well, the applicable parts of them, anyway, instead. There will be a MirCPIO release completely rebased later after all changes are merged and, more importantly, tested. Another release although not set for immediate future should bring a more sensible (and mksh-like) buildsystem for improved portability (and thus some more changes we had to exclude at first). I ve also cloned the halfwidth part of the FixedMisc [MirOS] font as FixedMiscHW for use with Qt5 applications, xfonts-base in the WTF APT repo. (Debian #809979) tl;dr: mksh R52c (bugfix-only, low-medium); mircpio 20160306 (security backport; high) with future complete rebase (medium) upstream and in Debian. No mksh backports due to lacking a bpo capable sponsor. New console-setup in WTF APT repo, and mksh there as usual. xfonts-base too. netboot.me gone?

5 March 2016

Lunar: Reproducible builds: week 44 in Stretch cycle

What happened in the reproducible builds effort between February 21th and February 27th:

Toolchain fixes Didier Raboud uploaded pyppd/1.0.2-4 which makes PPD generation deterministic. Emmanuel Bourg uploaded plexus-maven-plugin/1.3.8-10 which sorts the components in the components.xml files generated by the plugin. Guillem Jover has implemented stable ordering for members of the control archives in .debs. Chris Lamb submitted another patch to improve reproducibility of files generated by cython.

Packages fixed The following packages have become reproducible due to changes in their build dependencies: dctrl-tools, debian-edu, dvdwizard, dymo-cups-drivers, ekg2, epson-inkjet-printer-escpr, expeyes, fades, foomatic-db, galternatives, gnuradio, gpodder, gutenprint icewm, invesalius, jodconverter-cli latex-mk, libiio, libimobiledevice, libmcrypt, libopendbx, lives, lttnganalyses, m2300w, microdc2, navit, po4a, ptouch-driver, pxljr, tasksel, tilda, vdr-plugin-infosatepg, xaos. The following packages became reproducible after getting fixed: Some uploads fixed some reproducibility issues, but not all of them:

tests.reproducible-builds.org The reproducibly tests for Debian now vary the provider of /bin/sh between bash and dash. (Reiner Herrmann)

diffoscope development diffoscope version 50 was released on February 27th. It adds a new comparator for PostScript files, makes the directory tests pass on slower hardware, and line ordering variations in .deb md5sums files will not be hidden anymore. Version 51 uploaded the next day re-added test data missing from the previous tarball. diffoscope is looking for a new primary maintainer.

Package reviews 87 reviews have been removed, 61 added and 43 updated in the previous week. New issues: captures_shell_variable_in_autofoo_script, varying_ordering_in_data_tar_gz_or_control_tar_gz. 30 new FTBFS have been reported by Chris Lamb, Antonio Terceiro, Aaron M. Ucko, Michael Tautschnig, and Tobias Frost.

Misc. The release team reported on their discussion about the topic of rebuilding all of Stretch to make it self-contained (in respect to reproducibility). Christian Boltz is hoping someone could talk about reproducible builds at the openSUSE conference happening June 22nd-26th in N rnberg, Germany.

4 March 2016

Enrico Zini: Praise of component reuse

I farm bits and pieces out to the guys who are much more brilliant than I am. I say, "build me a laser", this. "Design me a molecular analyzer", that. They do, and I just stick 'em together. (Seth Brundle, "The Fly")
When I decided to try and turn siterefactor into staticsite, I decided that I would go ahead only for as long as it could be done with minimal work, writing code in the most straightforward way on top of existing and stable components. I am pleased by how far that went. Python-Markdown It works fast enough, already comes with extensions for most of what I needed, and can be extended in several ways. One of the extension methods is a hook for manipulating the ElementTree of the rendered document before serializing it to HTML, which made it really easy to go and process internal links in all <a href= and <img src= attributes. To tell an internal link from an external link I just use the standard python urlparse and see if the link has a scheme or a netloc component. If it does not, and if it has a path, then it is an internal link. This also means that I do not need to invent new Markdown syntax for internal references, avoiding the need for remembering things like [text]( < relref "blog/post.md" > ) or [text]( filename /blog/post.md). In staticsite, it's just [text](/blog/post.md) or [text](post.md) if the post is nearby. This feels nicely clean to me: if I wanted to implement fancy markdown features, I could do it as Python-Markdown extensions and submit them upstream. If I wanted to implement fancy interlinking features, I could do it with a special url scheme in links. For example, it would be straigtforward to implement a ssite: url scheme that expanded the url with elements from staticsite's settings using a call to python's string.format (ssite: SETTING_NAME /bar maybe?), except I do not currently see any use cases for extending internal linking from what it is now. Jinja2 Jina2 is a template engine that I already knew, it is widely used, powerful and pleasant to use, both on the templating side and on the API's side. It is not HTML specific, so I can also use it to generate Atom, RSS2, "dynamic" site content, and even new site Markdown pages. Implementing RSS and Atom feeds was just a matter of writing and testing these Jinja2 macros and then reusing them anywhere. toml, yaml, json No need to implement my own front matter parsing. Also, reusing the same syntax as Hugo allows me to just link to its documentation. python-slugify I found python-slugify so I did not bother writing a slug-generating function. As a side effect, now things works better than I would even have thought to implement, including transliteration of non-ascii characters: 
$ ./ssite new example --noedit --title "Cos  parl  Enrico"
/enrico-dev/staticsite/example/site/blog/2016/cosi-parlo-enrico.md
(I just filed an RFP) python-livereload Implementing ssite serve which monitors the file system and autoreloads when content changes and renders everything on the fly, took about an hour. Most of that hour went into implementing rendering pages on demand. Then I discovered that it autoreloads even when I edit staticsite's source code. Then I discovered that it communicates with the browser and even automatically triggers a page refresh. I can keep vim on half my screen and a browser in the other half, and I get live preview for free every time I save, without ever leaving the editor. Bootstrap I already use Bootstrap at work, so creating the default theme templates with it took about 10 minutes. This morning I tried looking at my website using my mobile phone, and I pleasantly saw it automatically turning into a working mobile version of itself. Pygments Python-Markdown uses Pygments for syntax highlighting, and it can be themed just by loading a .css. So, without me really doing anything, even staticsite's syntax highligthing is themable, and there's even a nice page with a list of themes to choose from. Everything else... Command line parsing? Straight argparse. Logging? python's logging support. Copying static resource files? shutil.copy2. Parsing dates? dateutil.parser. Timing execution? time.perf_counter. Timezone handling? pytz. Building the command to run an editor? string.format. Matching site pages? fnmatch.translate. ...and then some. If I ever decide to implement incremental rendering, how do I implement tracking which source files have changed? Well, for example, how about just asking git?

Mike Gabriel: My FLOSS activities in February 2016

February 2016 has been a very active month regarding me contributing to the FLOSS world.
  • Finalizing MATE uploads to Debian with regards to the Beta 1 Freeze of Ubuntu 16.04
  • Work on RDP related packages in Debian
  • Work on Debian Edu related packages
  • Work on Debian LTS
  • Work on nx-libs (NX v3)
Honouring my Sponsors I am happy to share that this month's FLOSS work has been sponsored by various sponsors.
  • Work on the packages mate-dock-applet, topmenu-gtk and getting GIR-support back into libwnck has been sponsored by Martin Wimpress, the main driving force (AFAIK) behind Ubuntu MATE [1].
  • Work on Debian LTS has been sponsored by the various Debian LTS sponsors proxied through Freexian SARL (thanks to Raphael Hertzog for organizing the paid LTS contributors team via his company) [2].
  • Work on nx-libs has been sponsored by the Qindel Group [3].
Thanks to all people and companies sponsoring my work on FLOSS projects. This month's MATE uploads to Debian With regards to the Beta 1 Freeze date of Ubuntu 16.04 LTS (18th Feb 2016), Martin Wimpress, Vangelis Mouhtsis and I performed quite some work on Debian MATE. Uploads to Debian unstable:
  • caja 1.12.4-2 [4]
  • mate-menu 5.6.8-1 [5]
  • mate-panel 1.12.2-1 [6]
  • mate-dock-applet 0.67-3 (NEW) [7]
  • mate-polkit 1.12.0-3 [8]
  • eom 1.12.2-1 [9]
  • pluma 1.12.2-1 [10]
  • topmenu-gtk 0.2.1+git20151210.8c6108f-2 (NEW) [11]
  • mate-tweak 3.5.7-1 (latest upload on 2nd of March) [12]
The Debian MATE Packaging Team also took over maintenance of the GTK-2+ legacy package libwnck [13]. The first upload introducing some major changes and package clean-ups caused a slight wave [14] because of a missing dependency in libwnck-dev (that fell victim to some clean-ups in debian/control). Those issues have been addressed immediately and have now been settled. The main reason for working on a legacy package like libwnck was the need for having gir1.2-wnck-1.0 (back) in Debian. The new MATE dock applet requires the libwnck GIR package to be present at runtime. One of the novelties in Ubuntu MATE 16.04 LTS will be the option to adapt the look and feel of the MATE desktop to how a Unity-based desktop looks like. Martin Wimpress is giving intense work to providing a dock applet and topmenu support as one alternative among the various Ubuntu MATE desktop experiences provided. The alternative desktop layouts can be configured with the MATE Tweak tool. Work on RDP related packages Work on FreeRDP 1.1 as currently in Debian I finally managed to give some priority (and thus time) to fixing various issues in the freerdp package in Debian [15]. Many people had provided patches and solutions to open issues and I tried to honour as many of those, as possible. Please note that I had to disable the GStreamer support in FreeRDP for the recent uploads, as the currently used Git snapshot of FreeRDP only supports GStreamer 0.10's API whereas the security team is in the process of having gstreamer0.10-* packages removed from the Debian stretch/unstable archives. Work on FreeRDP 2.0, coming to Debian soon Furthermore, Bernhard Miklautz is currently working on a freerdp2 package, which will bring the latest Git snapshot of FreeRDP upstream into Debian (and also re-introduce GStreamer support, based on GStreamer 1.0). Bernhard invested a lot of time on pushing the current HEAD of FreeRDP upstream [16] towards a FreeRDP 2.x version. Starting with FreeRDP 2.x it will be possible to install different FreeRDP versions on one system without file naming conflicts. For March 2016, I have doing the final freerdp2 reviewing on my todo list (possibly together with H ctor Or n Mart nez who is highly interested in the RDP backend support in Wayland/Weston), so that we can provide first uploads to Debian experimental sometime the coming month. The packaging progress is continuously discussed on the #freerdp channel on Freenode and can also be viewed on Github [17]. Review of revised XRDP package Recently, Dominik George from Teckids e.V. [18] contacted me about reviewing their effort of updating the Debian package xrdp, which currently is in ITA state [19]. Feedback has been provided and I am waiting for a ping from his side so that I can take some (ideally) final looks at the package and sponsor the upload. Work on Debian Edu related packages This month, I spent a couple of hours of work on several Debian Edu related tasks, some of them induced by problems at local school sites we support.
  • Fix the gosa package in Debian unstable [20]
  • Document a switch-over to systemd-networkd for Debian Edu jessie notebooks [21]
  • Help out in fixing outstanding issues in ldap2bind [22]
  • Upload a new shutdown-at-night package version to Debian unstable [23]
  • Fix some icon issues in the italc package [24]
  • Take a first glance at packaging terminal-quest [25]
  • Playing with the Lego Mindstorm (NXT) tools
Work on Debian LTS My 8h-portion of work for the Debian LTS Project, I performed at the very end of February. With the Debian squeeze LTS EOL date on 29th February, I saw to finalizing my personal open todos regarding Debian squeeze LTS, which basically was getting two CVE issues fixed in the lxc package [26]. The rest of the work hours has been spent on helping out the Security Team of Debian with open CVE issues in Debian wheezy packages:
  • Providing a .debdiff for gosa in Debian wheezy (addressing CVE-2015-8771 and CVE-2014-9760)
  • Investigating an open issue in smarty3 (CVE-2014-8350) and providing a recommendation on how to handle that (which is: pick the latest smarty3 3.1.21-1 from Debian jessie and provide that to users of Debian wheezy)
  • Taking a first look at pdns regarding a fix for CVE-2014-7210 in Debian wheezy
The gosa .debdiff has been approved by a member of the Security Team, the upload will happen today. With my LTS frontdesk hat on (during week 9 / 2016) I also spent some time providing help regarding SVN checkout problems and raised a couple of questions on how to coordinate the work phase between the Debian squeeze LTS EOL and the official launch of the Debian wheezy LTS project phase [27]. Work on nx-libs At the end of February, I finally managed to propose a way of dropping the libNX_Xrender.so bundled library from the nx-libs code base. I filed a PR [28] against nx-libs that proposes its removal and provides a patch for using X.Org's libXrender.so version. As a preview for nx-libs work in March 2016... I have started with removing the complete libNX_X11.so library from nx-libs and using X.Org's X11 client library. This will introduce a code removal of around 160.000 lines of code to nx-libs. More to come on this later... light+love,
Mike [1] http://ubuntu-mate.org/
[2] https://www.freexian.com/
[3] http://www.qindel.com/ [4] (caja)
https://lists.debian.org/debian-devel-changes/2016/02/msg00468.html
https://lists.debian.org/debian-devel-changes/2016/02/msg02080.html
https://lists.debian.org/debian-devel-changes/2016/02/msg02086.html
https://lists.debian.org/debian-devel-changes/2016/02/msg02183.html [5] (mate-menu)
https://lists.debian.org/debian-devel-changes/2016/02/msg00469.html [6] (mate-panel)
https://lists.debian.org/debian-devel-changes/2016/02/msg01900.html [7] (mate-dock-applet)
https://lists.debian.org/debian-devel-changes/2016/02/msg01935.html
https://lists.debian.org/debian-devel-changes/2016/02/msg02481.html
https://lists.debian.org/debian-devel-changes/2016/02/msg03097.html [8] (mate-polkit)
https://lists.debian.org/debian-devel-changes/2016/02/msg01936.html
https://lists.debian.org/debian-devel-changes/2016/02/msg02395.html [9] (eom)
https://lists.debian.org/debian-devel-changes/2016/02/msg02073.html [10] (pluma)
https://lists.debian.org/debian-devel-changes/2016/02/msg02128.html [11] (topmenu-gtk)
https://lists.debian.org/debian-devel-changes/2016/02/msg02399.html
https://lists.debian.org/debian-devel-changes/2016/02/msg02501.html [12] (mate-tweak)
https://lists.debian.org/debian-devel-changes/2016/02/msg03086.html [13] (libwnck)
https://lists.debian.org/debian-devel-changes/2016/02/msg01248.html
https://lists.debian.org/debian-devel-changes/2016/02/msg01404.html
https://lists.debian.org/debian-devel-changes/2016/02/msg01825.html [14] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814585
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814588
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814697 [15] (freerdp)
https://lists.debian.org/debian-devel-changes/2016/02/msg02487.html
https://lists.debian.org/debian-devel-changes/2016/02/msg02630.html [16] https://github.com/FreeRDP/FreeRDP
[17] https://github.com/bmiklautz/debian-freerdp2 [18] https://www.teckids.org/ [19] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719624 [20] (gosa)
https://lists.debian.org/debian-devel-changes/2016/02/msg01554.html
https://lists.debian.org/debian-devel-changes/2016/02/msg01954.html [21] https://sunweavers.net/blog/node/34 [22] (ldap2zone)
https://lists.debian.org/debian-devel-changes/2016/02/msg01966.html
https://lists.debian.org/debian-devel-changes/2016/02/msg01967.html [23] (shutdown-at-night)
https://lists.debian.org/debian-devel-changes/2016/02/msg03605.html [24] (italc)
https://lists.debian.org/debian-devel-changes/2016/02/msg01944.html [25] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815948 [26] (lxc, Debian squeeze LTS)
https://lists.debian.org/debian-lts-changes/2016/02/msg00037.html [27] https://lists.debian.org/debian-lts/2016/02/msg00155.html
(The thread continues in March 2016) [28] https://github.com/ArcticaProject/nx-libs/pull/93

Arturo Borrero Gonz lez: How are we training to climb Mulhacen

Alcazaba, Punta de la Cornisa and Mulhac n 3.479 m

I have been in some adventures with a group of friends for a couple of years now. We call ourselves Los Extraviaos (a quick translation to english is perhaps The Wanderers).

We like nature adventures. During summer we use to do water adventures (like rivers trekking, waterfall climbing, snorkeling, canyoning, rafting, kayaking and so on). During winter and spring, we use to do trekking, hiking and mountaineering (low altitudes, keep reading).

For this sport season, one of our main milestones is to climb the second most prominent mountain in Spain: Mulhacen, with 3.479 m over sea level, during summer (June).
From an alpinist point of view, this isn't a very big deal, since most of the mountain's snow and ice is completely melted and the altitude is not that high.
However, from our amateur mountaineering point of view we will be taking a lot of kilometres to walk and a lot of elevation gain uphill (almost 1.600 m), which is in fact a thing to take into account.
Anyway, Mulhacen is considered 'high mountaineering' and all cautions should be taken both during preparation/training and during the climbing of the mountain itself.

To train our bodies and minds we are climbing lower mountains. We have climbed 3 or 4 already, and will continue to climb more in upcoming moths until we go to Mulhacen.
Also, it's important to climb mountains in different weather conditions. We need to train how to overcome wind, snow, storm, cold, night situations. The way we learn most is facing new, challenging situations.

We started by going to the summit of 'El Aljibe', 1.094 m over sea level, with about 500 m elevation gain uphill during 13 km.
This time, the weather was very windy. A video of the summit moment:


A pic of the group:


Next was the 'Torrecilla' peak. The summit is at 1.919 m over sea level, with about 900 m elevation gain uphill during 15 km.
This time we faced a snowy trekking.
Here a music video of that day:


The Torrecilla peak is in fact challenging with snow, so we went a second time, with even more snow and wind:


This second time we faced winds of 70km/h which, due to wind-chill, resulted in a very cold day.

We also went to Sierra de Grazalema Natural Park, in a hard trekking under snowfall:


This time we walked about 15 km with about 500m elevation gain uphill, while enjoying this kind of environment:


What's next: more mountains! We plan to reach 2.069 m over sea level next week in 'La Maroma' and keep doing steep trekking in upcoming months until we go in June to Mulhacen.

It should be very funny to do some FLOSS contribution from the summit of a mountain. Do you know of someone who did that?

3 March 2016

Simon Richter: Why sysvinit?

As most distributions have switched to systemd as default "init", some people have asked why we actually keep sysvinit around, as it's old and crusty, and systemd can do so much more. My answer is: systemd and sysvinit solve entirely different problems, and neither can ever replace the other fully. The big argument in favour of systemd is integration: when you keep everything in one process, it is easy to make sure that components talk to each other. That is nice, but kind of misses the point: integration could be done via IPC as well, and systemd uses a lot of it to separate privileges anyway. The tighter integration comes from something else: the configuration format. Where sysvinit uses a lot of shell scripts ("imperative" format), systemd uses explicit keywords ("descriptive" format), and this is the important design decision here: descriptive formats cannot do anything unanticipated, neither good nor bad. This is important for UI programmers: if there is a button that says "if I close the lid switch, suspend the laptop", then this needs to be connected to functionality that behaves this way, and this connection needs to work in both directions, so the user will find the active setting there when opening the dialog. So, we need to limit ourselves to a closed set of choices, so the UI people can prepare translations. This is the design tradeoff systemd makes: better integration in exchange for less flexibility. Of course, it is simple to allow "custom" actions everywhere, but that starts to break the "well-integrated" behaviour. There is an old blog post from Joey Hess about how to implement a simple alarm clock, using systemd, and this shows both how powerful and how limited the system is. On one hand, the single line WakeSystem=true takes care of the entire dependency chain attached to making sure the system is actually on -- when the system is going to suspend mode, some program needs to determine that there are scheduled jobs that should wake up the system, determined which of these is the next one, program the wakeup time into the hardware and only then allow the suspend to continue. On the other hand, the descriptive framework already breaks down in this simple example, because the default behaviour of the system is to go to sleep if the lid switch is closed, and the easiest way to fix this is to tell systemd to ignore the lid switch while the program is running. The IPC permissions disallow scheduled user jobs from setting this, so a "custom" action is taken that sets up the "ignore the lid switch" policy, changes to an unprivileged user, and runs the actual job. So, it is possible to get back flexibility, but this is traded for integration: while the job is running, any functionality that the "suspend laptop when the lid is closed" button had, is broken. For something simple as a switch on a personal laptop that breaks if the user configures something that is non-standard, that is acceptable. However, the keywords in the service unit files, the timer files, etc. are also part of a descriptive framework, and the services using them expect that the things they promise are kept by the framework, so there is a limit to how many exceptions you can grant. SystemV init really comes from the other direction here. Nothing is promised to init scripts but a vague notion that they will be run with sufficient privileges. There is no dependency tracking that ensures that certain services will always start before others, just priorities. You can add a dependency system like insserv if you like and make sure that all the requirements for it to work (i.e. services declaring their dependencies) are given, and there is a safe fallback of not parallelizing so we can always play it safe. Because there is so little promised to scripts, writing them becomes a bit tedious -- all of them have a large case statement where they parse the command line, all of them need to reimplement dropping privileges and finding the PID of a running process. There are lots of helpers for the more common things, like the LSB standard functions for colorful and matching console output, and Debian's start-stop-daemon for privilege and PID file handling, but in the end it remains each script's responsibility. Systemd will never be able to provide the same flexibility to admins while at the same time keeping the promises made in the descriptive language, and sysvinit will never reach the same amount of easy integration. I think it is fairly safe to predict both of these things, and I'd even go a step further: if any one of them tried, I'd ask the project managers what they were thinking. The only way to keep systems as complex as these running is to limit the scope of the project. With systemd, the complexity is kept in the internals, and it is important for manageability that all possible interactions are well-defined. That is a huge issue when writing adventure games, where you need to define interaction rules for each player action in combination with each object, and each pair of objects that can be combined with the "Use" action. Where adventure games would default to "This doesn't seem to work." or "I cannot use this.", this would not be a helpful error message when we're trying to boot, so we really need to cut down on actions and object types here. Sysvinit, on the other hand, is both more extreme in limiting the scope to very few actions (restart, wait, once) and only one object type (process that can be started and may occasionally terminate) in the main program, and a lot more open in what scripts outside the main program are allowed to do. The prime example for this is that the majority of configuration takes place outside the inittab even -- a script is responsible for the interface that services are registered by dropping init scripts into specific directories, and scripts can also create additional interfaces, but none of this is intrinsic to the init system itself. Which system is the right choice for your system is just that: your choice. You would choose a starting point, and customize what is necessary for your computer to do what you want it to do. Here's the thing: most users will be entirely happy with fully uncustomized systemd. It will suspend your laptop if you close the lid, and even give your download manager veto power. I fully support Debian's decision to use systemd as the default init for new installs, because it makes sense to use the default that is good for the vast majority of users. However, my opening statement still stands: systemd can never support all use cases, because it is constrained by its design. Trying to change that would turn it into an unmaintainable mess, and the authors are right in rejecting this. There are use cases that define the project, and use cases that are out of scope. This is what we need sysvinit for: the bits that the systemd project managers rightfully reject, but that are someone's use case. Telling these users to get lost would be extremely bad style for the "universal operating system." For example, if someone needs a service that asks a database server for a list of virtual machines to start, runs each in its private network namespace that is named after replacing part of the virtual machine name with the last two octets of the host machine's IP address, then binds a virtual Ethernet device into the network namespace and sets up a NAT rule that allows devices to talk to the public Internet and a firewall rule to stop VMs from talking to each other. Such a beast would live outside of systemd's world view. You can easily start it, but systemd would not know how to monitor it (as long as there is some process still running, is that a good sign), not know how to shut down one instance, not know how to map processes to instances and so on. SystemV init has the advantage here that none of these things are defined by the system, and as long as my init script has some code to handle "status", I can easily check up on my processes with the same interface I'd use for everything else. This requires me to have more knowledge of how the init system works, that is true, however I'd also venture that the learning curve for sysvinit is shallower. If you know shell scripting, you can understand what init scripts do, without memorizing special rules that govern how certain keywords interact, and keeping track of changes to these rules as the feature set is expanded. That said, I'm looking at becoming the new maintainer of the sysvinit package so we can continue to ship it and give our users a choice, but I'd definitely need help, as I only have a few systems left that won't run properly with systemd because of its nasty habit to keep lots of code in memory where sysvinit would unload it after use (by letting the shell process end), and these don't make good test systems. The overall plan is to set up a CI system that
  • tests sysvinit -> systemd transition
  • tests systemd -> sysvinit transition
  • tests debootstrap with systemd
  • tests debootstrap with sysvinit
  • tests whether service start works for a list of services, so we can catch regressions
  • scans packages that have systemd unit files for init scripts, and vice versa
Ideally, I'd like to reach a state where we can actually ensure that the default configuration is somewhat similar regardless of which init system we use, and that it is possible to install with either (this is a nasty regression in jessie: bootstrapping a foreign-architecture system broke). This will take time, and step one is probably looking at bugs first -- I'm grateful for any help I can get here, primarily I'd like to hear about regressions via bug reports. tl;dr: as a distribution, we need both systemd and sysvinit. If you suggest that systemd can replace sysvinit, I will probably understand that you think that the systemd maintainers don't know project management. I'm reluctantly looking at becoming the official maintainer because I think it is important to keep around.

Tianon Gravi: Docker on VULTR + IPv6

I ve been using VULTR for a little while now and have been generally very pleased (especially with the very recent facelift the management portal received). I don t want to waste too much time talking about it, but the killer feature for me (over some of their competitors like DigitalOcean) is that I can provide a raw ISO and provision my VM directly using it as I would any local VM (which also means that once my VM is up and working, I get to use the OS s standard kernel, which is especially important for using Debian Unstable well). Anyhow, already too much about that let s get to the cool stuff. Getting right down to the beef, let s assume I ve got a VULTR instance already created, my OS is already installed and working, I ve enabled IPv6 within VULTR, ensured that my VM is able to ping6 google.com (to verify at least basic routability), and have Docker version 1.10.2 installed. For the sake of demonstration, we ll assume that VULTR has assigned my IPv6 as follows: (available under the VM details via Settings > IPv6)
  • Default IP: 2001:db8::5400:00ff:fe20:2295
  • Network: 2001:db8::
  • CIDR: 64
(The astute reader may recognize RFC3849 here. ) The relevant documentation which helped me get to the working state outlined below is in the IPv6 with Docker section. The first step I took was creating a systemd drop-in file so that I could modify the daemon startup parameters (to include --ipv6 and --fixed-cidr-v6): 
# /etc/systemd/system/docker.service.d/ipv6.conf
[Service]
ExecStart=
ExecStart=/usr/bin/docker daemon -H fd:// --ipv6 --fixed-cidr-v6 2001:db8::/80
I chose to use just /80 for Docker any other reasonable prefix (assuming it is routed to your host / host network) should also work; the documentation I linked above has an example using a /125, for example. With this half in place, I can systemctl daemon-reload and systemctl restart docker.service, and when I start a container it will be automatically assigned an IPv6 address from within that prefix. Excellent. An important caveat to note is that this will break discovery on our host due to Docker enabling forwarding for us, so (assuming your internet-facing interface is named ens3 for the sake of illustration; it might just as easily be eth0, eth1, enps3, lan0, wlan0, etc) I had to sysctl net.ipv6.conf.ens3.accept_ra=2, and I added it to /etc/sysctl.d/docker-ipv6.conf for good measure (so that I don t lose it after I reboot). The second half of our IPv6 to containers problem is routing. The nitty-gritty details of this are discussed in the Using NDP proxying section of the documentation, but the gist is that my containers have IPv6 addresses, but the outside world doesn t have a route that leads to them, and that we need to tell the kernel to respond to solicitations for our container s IPv6 addresses appropriately. The kernel has a mechanism for doing so (via ip -6 neigh ...), but it is limited to individual addresses and is thus not especially great for having a solution that works magically without further manual labor per-container. This is where ndppd (also packaged for Debian as ndppd) came in. 
# /etc/ndppd.conf
proxy ens3  
	rule 2001:db8::/80
After getting this configuration in place and restarting ndppd (systemctl restart ndppd), magic happened. My containers could ping6 google.com, and my other IPv6 hosts could ping6 the IPv6 addresses of my individual containers! You ve probably noted that this configuration isn t exactly secure, since it means that each of my individual containers has a publicly routable IPv6 address, but for this specific use case, I m OK with that! Update (2015-03-09): thanks to for correcting my systemd drop-in file usage!

Ben Hutchings: Last week 'flu by

Last Monday, I began a new project at Codethink - working on kernel support for the next generation of an interactive system fitted in some high-performance cars. I travelled up to Manchester the night before, and on Monday I met Codethink's team (most of whom I was familiar with). My first chore was to set up VPN access to the development resources (source control, wiki, etc.). I sandboxed the proprietary VPN client in a VM with a systemd unit to run it at boot, so I can control it by starting and stopping that VM. I then set to work on unpacking and exploring the SoC vendor's evaluation module (EVM), starting by looking at serial output - of which there was none. Nothing on the LCD panel or network port either. A frustrating day. On Tuesday, the architect from our immediate customer, already a friend of mine, joined us in Manchester. As for the EVM, without any obvious change in cabling it was now reliably spitting out the expected u-boot and kernel boot messages, unfortunately ending with errors from the touchscreen driver intermingled with messages from various graphics drivers. I looked at the u-boot environment to see how the kernel parameters were controlled and started tweaking them with the aim of working around the errors. None of this worked. I looked for more documentation on the EVM, but found none beyond the quick start guide. Had I been given the wrong kernel or device tree? They matched the available downloads though the device tree looked very different from the upstream version. I started trying to edit the vendor's device tree to remove the troublesome devices before realising that the decompiled tree was full of absolute cross-references that would be invalid after recompiling. So, a second day of frustration. In the evening I started to feel a cold coming on. I slept poorly, and just dragged myself out of bed in time for 11:00 checkout. In the office, I remembered that u-boot had commands for manipulating device trees in memory. I tried stepping through the boot script and then removing device tree nodes for the touchscreen and graphics hardware before booting the kernel. Success! I got a login prompt where of course username:root, password:[empty] worked. (It doesn't run sshd, but does run telnetd.) Then it was time for a team lunch at the excellent Samsi, though I hesitated to go as I was feeling quite poorly. Shortly after lunch I found myself falling asleep at my desk in the middle of reading documentation. I had to take a nap on the sofa. I got a little more work done that day, but I got progressively feebler. The train journey home was thankfully uneventful. I arrived home at midnight and soon went to sleep. I spent most of Thursday in a high fever, dreaming of abstract entities and their relationships that I struggled to name, but in retrospect might correspond to various kinds of software component. It was incredibly tedious. I had no appetite and little ability to process the real world. Nattie tended to me as she could. I called my mum to cancel her visit planned for the next day. On Friday my fever started to recede and I drank some soup. I was able to look after myself to some extent, though I sorely missed Nattie when she went out. I spent most of the day watching comedy and music docs on the BBC iPlayer, something far too passive for me to do normally. On Saturday morning I felt well enough to tackle the meze platter that Nattie brought back from her previous evening's outing. It tasted pretty damn good. I felt better hour by hour, and in the evening we both went out to a group dinner in a pub. Hot food smelled and tasted even more amazing! I was able to start catching up on email and some real work, preparing kernel stable updates. I even migrated DNS service for decadent.org.uk late that night, driven by anger at the incompetence of my previous provider that had prevented my mails reaching bugs.debian.org. Despite the awfulness of Thursday and the symptoms I still have (tickly throat and runny nose), this bout of the 'flu has been a positive experience for me, but I'll explain why that is in a subsequent entry.

Ben Hutchings: Debian LTS work, February 2016

February marked the end of Debian 6.0 "squeeze" LTS, though there was some initial confusion (partly my fault) over which day of month it should end. I carried over 10 hours from January and was assigned another 11.25 hours of work by Freexian's Debian LTS initiative. I worked a total of 14 hours. I started the month with "the final" update to the linux-2.6 kernel package (DLA-412-1), fixing 5 CVEs and incorporating upstream stable update 2.6.32.70. After it was agreed that support would continue to the end of the month, I made one more update on the last day (DLA-439-1), fixing 4 CVEs, a regression, and some issues I had found lacking CVEs (one is now CVE-2012-6701). I helped to edit the end-of-life announcement for Squeeze LTS. I spent a fairly quiet week in the front desk, triaging new issues for squeeze. As I've volunteered to handle embargoed issues, I prepared security updates to libssh and libssh2 and issued them minutes after the public disclosure of the similarly disastrous CVE-2016-0739 and CVE-2016-0787 issues.

2 March 2016

Steinar H. Gunderson: Nageru FOSDEM talk video

I got tired of waiting for the video of my FOSDEM talk about Nageru, my live video mixer, to come out, so I made an edit myself. (This wouldn't have been possible without getting access to the raw video from the team, of course.) Of course, in maximally bad timing, the video team published their own (auto-)edit of mine and a lot of other videos on the very same day (and also updated their counts to a whopping 151 fully or partial lost videos out of a bit over 500!), so now there's two competing ones. Of course, since I have only one and not 500 videos to care about, I could afford to give it a bit more love; in particular, I spliced in digital versions of the original slides where appropriate, modified the audio levels a bit when there are audience questions, added manual transcriptions and so on, so I think it ended up quite a bit better. Nageru itself is also coming pretty nicely along, with an 1.1.0 release that supports DeckLink PCI cards (not just the USB ones) and also the NVIDIA proprietary driver, for much increased oomph. It's naturally a bit more quiet now than it was, though conferences always tend to generate a flurry of interest, and then you get back to other interests afterwards. You can find the talk on YouTube; I'll also be happy to provide a full-quality master of my edit if FOSDEM or anyone else wants. Enjoy :-)

1 March 2016

Thorsten Alteholz: My Debian Activities in February 2016

FTP assistant This month I marked 364 package for accept and rejected 66. Due to the help of lamby, the length of the NEW queue dropped mostly below 50, so there is no need for complaints anymore :-) . I also sent 22 emails to maintainers asking questions. Squeeze LTS This was my twentieth month that I did some work for the Squeeze LTS initiative, started by Raphael Hertzog at Freexian. This month more people started to contribute and my workload dropped down to 11.25h. Altogether I uploaded those DLAs:
  • [DLA 424-1] didiwiki security update
  • [DLA 423-1] krb5 security update
  • [DLA 433-1] xerces-c security update
  • [DLA 444-1] php5 security update
This month I was also involved in embargoed uploads and could do an upload on my own (DLA 433-1). Now Squeeze LTS is officially done. I leave it with mixed feelings. On the one hand it became more and more difficult to backport patches for the latest version to the old software. On the other hand I could learn a lot of stuff about the methods other maintainers used some years ago. Yes, although not always visible at first sight, over the years there are lots of improvements on how packages can be handled in Debian. So, let us start with Wheezy now Other stuff On the way to pump.io, grunt and some other cool stuff, I uploaded:
  • node-abab
  • node-array-equal
  • node-array-flatten
  • node-array-unique
  • node-cors
  • node-deep-extend
  • node-original
  • node-simplesmtp
  • node-setimmediate
  • node-uglify-save-license
  • node-unpipe
Yes, sometimes this npm2deb makes it really easy to create a package. In order to fix FTBFSs, errors from DebCI or whatever might fail these days, I also uploaded new versions of:
  • node-array-equal
  • node-array-parallel
  • node-bufferjs
  • node-crc
  • node-css-what
  • node-eventsource
  • node-mime-types
  • node-mocks-http
  • node-rai
  • node-requires-port
  • node-url-parse
  • node-xoauth2
Today I could see the first fruits of my labor. Some packages, I did not touch, migrated to testing because some of their dependencies were finally able to migrate as well.

Next.

Previous.