You are here

Agreguesi i feed

Lucas Nussbaum: Removal of jessie-updates and jessie-backports from Debian mirrors

Planet Debian - Mër, 27/03/2019 - 10:46md

If you are still running jessie you probably noticed that the jessie-updates and jessie-backports suites have been removed from mirrors, because you got those error messages:

W: Failed to fetch 404 Not Found [IP: 80] W: Failed to fetch 404 Not Found [IP: 80]

I was not involved in that decision (which was made by the FTP masters team), but since there is some confusion around it, I will try to give my understanding of the resulting issues.

The typical /etc/apt/sources.list file for a jessie system with backports enabled is:

deb jessie main deb-src jessie main deb jessie/updates main deb-src jessie/updates main deb jessie-updates main deb-src jessie-updates main deb jessie-backports main contrib non-free deb-src jessie-backports main contrib non-free

Debian packages are distributed using suites (which can be understood as channels). The global picture looks like this:

(This is slide 42 of the Debian Packaging Tutorial.)

deb jessie main is the easy one. It contains the bulk of packages. It is initialized by copying the content of the testing suite when a new stable release happens, approximately every two years. It is then updated from stable-new (an internal suite) when stable point releases happen (see below).

deb jessie/updates main is the security suite in the figure above. It is used by the Debian security team to provide security updates. They are announced on the debian-security-announce mailing list.

deb jessie-updates main (stable-updates above) is a suite used to distribute important updates that are unrelated to security, and that cannot wait the next stable point release. They are announced on the debian-stable-announce mailing list. Interestingly, a large proportion of those updates are related to changes to daylight-saving-time rules that are sometimes made very late by some countries.

stable point releases happen every few months (see for example the Debian 8.11 stable point release). They consist in updating the stable suite by copying important updates that were submitted to stable-proposed-updates. Security updates are also included.

backports follow an entirely different path. They are new versions of packages, based on the version currently in the testing suite. See the backports team website.

So, what happened?

In June 2018…

Debian 8.11 (in June 2018) was the final update for Debian 8. As stated in its announcement:

After this point release, Debian's Security and Release Teams will no longer be producing updates for Debian 8. Users wishing to continue to receive security support should upgrade to Debian 9, or see for details about the subset of architectures and packages covered by the Long Term Support project.

In other words: jessie and jessie-updates won’t receive any update. The only updates will be through the security suite, by the Debian Long Term Support project.

At about the same time (I think – I could not find an announcement — Update: announcement), the maintenance of backports for jessie was also stopped. Which makes sense, because the backports team provides backports for the current release, and stretch was released in June 2017.

In March 2019…

The FTP masters team decided to remove the jessie-updates and jessie-backports suite from the mirrors. This was announced on debian-devel-announce, resulting in the errors quoted above.

How to solve this?

For the jessie-updates suite, you can simply remove it from your /etc/apt/sources.list. It is useless, because all packages that were in jessie-updates were merged into jessie when Debian 8.11 was released.

The jessie-backports suite was archived on, so you can use:

deb jessie-backports main contrib non-free deb-src jessie-backports main contrib non-free

But then you will run into another issue:

E: Release file for is expired (invalid since 36d 1h 9min 51s). Updates for this repository will not be applied.

Unfortunately, with the APT version in jessie, this cannot be ignored on a per source basis (it can with the APT version from stretch, using the deb [check-valid-until=no] ... syntax). So you need to disable this check globally, using:

echo 'Acquire::Check-Valid-Until no;' > /etc/apt/apt.conf.d/99no-check-valid-until

After that, apt-get update just works.

(There are some discussions about resurrecting the jessie-updates suite to avoid the above errors, but it is probably getting less and less useful as time passes.)

Emmanuele Bassi: Layout managers in GTK 4

Planet GNOME - Mër, 27/03/2019 - 6:06md

Containers and layout policies have been a staple of GTK’s design since the very beginning. If you wanted your widget to lay out its children according to a specific policy, you had to implement GtkContainer for handling the addition, removal, and iteration of the child widgets, and then you had to implement the size negotiation virtual functions from GtkWidget to measure, position, and size each child.

One of the major themes of the GTK 4 development cycle is to delegate more functionality to ancillary objects instead of encoding it into the base classes provided by GTK. For instance, we moved the event handling from signal handlers described by GtkWidget into event controllers, and rendering is delegated to GtkSnapshot objects. Another step in that direction is decoupling the layout mechanism from GtkWidget itself to an ancillary type, GtkLayoutManager.

Layout Managers

A layout manager is the object responsible for measuring and sizing a widget and its children. Each GtkWidget owns a GtkLayoutManager, and uses it in place of the measure() and allocate() virtual functions—which are going away. The gist of the change: instead of subclassing a GtkWidget to implement its layout policy, you subclass GtkLayoutManager, and then assign the layout manager to a widget.

Just like in the old GtkWidget code, you will need to override a virtual function to measure the layout, called measure(), which replaces the get_preferred_* family of virtual functions of GTK 3:

static void layout_measure (GtkLayoutManager *layout_manager, GtkWidget *widget, GtkOrientation orientation, int for_size, int *minimum, int *natural, int *minimum_baseline, int *natural_baseline)

After measuring, you need to assign the size to the layout; this happens in the allocate() virtual function, which replaces the venerable size_allocate() virtual function of previous GTK major versions:

static void layout_allocate (GtkLayoutManager *layout_manager, GtkWidget *widget, int width, int height, int baseline)

On the more esoteric side, you can also override the get_request_mode() virtual function, which allows you to declare whether the layout manager requests a constant size, or if one of its sizes depend on the opposite one, like height-for-width or width-for-height:

static GtkSizeRequestMode layout_get_request_mode (GtkLayoutManager *layout_manager, GtkWidget *widget)

As you may notice, each virtual function gets passed the layout manager instance, as well as the widget that is using the layout manager.

Of course, this has bigger implications on various aspects of how GTK widgets work, the most obvious being that all the complexity for the layout code can now stay confined into its own object, typically not derivable, whereas the widgets can stay derivable and become simpler.

Another feature of this work is that you can change layout managers at run time, if you want to change the layout policy of a container; you can also have a per-widget layout policy, without adding more complexity to the widget code.

Finally, layout managers allow us to get rid of one of the special cases of GTK, namely: container child properties.

Child properties

Deep in the guts of GtkContainer sits what’s essentially a copy of the GObject property-related code, and whose only job is to implement “child” properties for types deriving from GtkContainer. These container/child properties exist only as long as a child is parented to a specific class of container, and are used for a variety of reasons—but, generally, to control layout options, like the packing direction in boxes and box-like containers; the fixed positioning inside GtkFixed; or the expand/fill rules for notebook tab widgets.

Child properties are hard to use, as they require ad hoc API instead of the usual GObject one, and thus require special casing in GtkBuilder, gtk-doc, and language bindings. Child properties are also attached to the actual direct child of the container, so if a widget interposes a child—like, say, GtkScrolledWindow or GtkListBox do—then you need to keep a reference to that child around in order to change the layout that applies to your own widget.

In GTK’s master branch we got rid of most of them—either by simply removing them when there’s actual widget API that implements the same functionality, or by creating ancillary GObject types and moving child properties to those types. The end goal is to remove all of them, and the relative API from GtkContainer, by the time GTK 4 rolls out. For layout-related properties, GtkLayoutManager provides its own API so that objects are created and destroyed automatically once a child is added to, or removed from, a widget using a layout manager, respectively. The object created is introspectable, and does not require special casing when it comes to documentation or bindings.

You start from deriving your own type from the GtkLayoutChild class, and adding properties just like you would for any other GObject type. Then, you override GtkLayoutManager‘s create_layout_child() virtual function:

static GtkLayoutChild * create_layout_child (GtkLayoutManager *manager, GtkWidget *container, GtkWidget *child) { // The simplest implementation return g_object_new (your_layout_child_get_type (), "layout-manager", manager, "child-widget", child, "some-property", some_property_initial_state, NULL); }

After that, you can access your layout child object as long as a widget is still a child of the container using the layout manager; if the child is removed from its parent, or the container changes the layout manager, the layout child is automatically collected.

New layout managers

Of course, just having the GtkLayoutManager class in GTK would not do us any good. GTK 4 introduces various layout managers for application and widget developers:

  • GtkBinLayout implements the layout policy of GtkBin, with the added twist that it supports multiple children stacked on top of each other, similarly to how GtkOverlay works. You can use each widget’s alignment and expansion properties to control their location within the allocated area, and the GtkBinLayout will always ask for as much space as it’s needed to allocate its largest child.
  • GtkBoxLayout is a straight port of the layout policy implemented by GtkBox; GtkBox itself has been ported to use GtkBoxLayout internally.
  • GtkFixedLayout is a port of the fixed layout positioning policy of GtkFixed and GtkLayout, with the added functionality of letting you define a generic transformation, instead of a pure 2D translation for each child; GtkFixed has been modified to use GtkFixedLayout and use a 2D translation—and GtkLayout has been merged into GtkFixed, as its only distinguishing feature was the implementation of the GtkScrollable interface.
  • GtkCustomLayout is a convenience layout manager that takes functions that used to be GtkWidget virtual function overrides, and it’s mostly meant to be a bridge while porting existing widgets towards the layout manager future.

We are still in the process of implementing GtkGridLayout and make GtkGrid use it internally, following the same pattern as GtkBoxLayout and GtkBox. Other widgets inside GTK will get their own layout managers along the way, but in the meantime they can use GtkCustomLayout.

The final step is to implement a constraint-based layout manager, which would let us create complex, responsive user interfaces without resorting to packing widgets into nested hierarchies. Constraint-based layouts deserve their own blog post, so stay tuned!

Reproducible builds folks: Reproducible Builds: Weekly report #204

Planet Debian - Mër, 27/03/2019 - 3:01md

Here’s what happened in the Reproducible Builds effort between Sunday March 17 and Saturday March 23 2019:

Don’t forget that Reproducible Builds is part of May/August 2019 round of Outreachy which offers paid internships to work on free software. Internships are open to applicants around the world and are paid a stipend for the three month internship with an additional travel stipend to attend conferences. So far, we received more than ten initial requests from candidates and the closing date for applicants is April 2nd. More information is available on the application page.

diffoscope development

diffoscope is our in-depth “diff-on-steroids” utility which helps us diagnose reproducibility issues in packages. This week:

  • Chris Lamb:
    • Always warn if the tlsh module is not available (not just if a specific fuzziness threshold is specified) to match the epilog of the --help output. This prevents missing support for file rename detection. (#29)
    • Fix a number of tests when using GhostScript 9.20 vs 9.26 for Debian stable vs. the same distribution with the security/point release applied. []
  • Mattia Rizzolo:
    • Ignore the version mismatch detection when building backport. []
    • Make test_ps.test_text_diff pass with ghostscript 9.26. []
  • Milena Boselli Rosa:
    • Remove the type HTML attribute from style elements. []
    • Prevent empty values for the name attribute name on HTML anchor tags and add an id to its parent div container. []
    • Fix a Text run is not in Unicode Normalization Form C HTML validation warning. []
    • Fix a Table column x established by element ‘col’ has no cells beginning in it HTML validation error. []
Packages reviewed and fixed, and bugs filed Test framework development

We operate a comprehensive Jenkins-based testing framework that powers This week, Mattia Rizzolo:

  • Fixed the dsa-check-running-kernel script after Ubuntu updated their packages. []
  • Do not blindly forward the jenkins@ emails, otherwise procmail cannot filter them (breaking our email2irc script). []
  • Gave Vagrant Cascadian root everywhere. []

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

Tobias Bernard: Designing for the Librem 5

Planet GNOME - Mër, 27/03/2019 - 1:53md

So you’re excited about the Librem 5 and GNOME going mobile, and want to start building an app for it. Of course, the first step is to design your app. This can seem quite challenging if you’re just starting out with a new platform, but fear not! In this blog post I’ll walk you through some of the most important UI patterns, and the process of going from idea to mockups step by step. Throughout this I’ll be using a read-it-later app as an example.

The GNOME design philosophy

Before starting to design for a platform, it’s good to familiarize yourself with the design philosophy of the platform. The GNOME Human Interface Guidelines have a “design principles” page which I encourage you to read in its entirety, but will paraphrase a few highlights from here:

Simplicity and Focus — Make sure you have clear goals for your app from the outset, and focus on those. Often it’s better to make a separate application to cover an additional use case rather than cramming too many things into one app (e.g. video podcasts are different enough from audio podcasts to be better off as their own app).

Search and Undo — If there are large amounts of content in your app, provide full-text search to make it easy to find things. Be forgiving about people making mistakes by making it hard to lose data, and never use a warning when you mean undo.

Avoid Preferences — “Just adding an option” often seems like a quick fix, but in most cases you’re just treating symptoms rather than the root cause. It’s better to figure out what that root cause is and fix the problem for everyone, rather than papering over the cracks with a preference. I highly recommend this article by Havoc Pennington on the topic.

Design Process

Now that we’re full of high-minded ideals, let’s jump into the actual design process. Let’s design a great read-it-later app.

We will follow the GNOME design process, which primarily consists of three steps (plus iterations):

  1. Define goals and non-goals for your app
  2. Collect relevant art, i.e. examples of similar apps to borrow ideas from
  3. Make sketches/mockups of the main views and user flows
1. Define Goals

The app we’re designing is going to be a native client for read-it-later web services (such as Pocket). These services allow you to store articles and other web pages that you are interested in, but don’t have time to read right now. That way you can catch up on all the stuff you saved later on, when you have more time. As such, our primary goals are:

  • Listing your saved articles
  • Providing a great, focused experience for reading articles in the app
  • Helping you actually catch up with your reading list
  • Storing articles offline, so they can be read without a network connection

Some non-goals, i.e. things that are out of scope for this application:

  • Social features
  • Content discovery
2. Relevant Art

The next step is to find some examples of existing apps that do similar things. It’s good to look at how other people have solved the same problems, what they do well, and what could be improved before jumping into designing a new app.

So let’s check out the competition:

Pocket on Android (screenshots by me)

Pocket on Android has a lot of features, and a pretty complicated interface. It has lots of categories, social features, a discover section, text-to-speech, and much more. I’ve personally never used most of these features, and they make the app feel quite cluttered. In my experience Pocket is also not very good at helping me get through the list of things I’ve already saved. It feels like it mostly wants me to discover new things to save (and then not read).

Clearly there are some lessons to be learned here for our app.

Instapaper on iOS (screenshots from App Store listing)

I’ve never used the app myself, but judging from screenshots, Instapaper’s UI feels a lot saner and more focused than Pocket. I also really like the rich article previews in the list view and the nice typography.

Wallabag for Android (screenshots from Google Play listing)

Wallabag is a self-hosted alternative to Pocket and Instapaper. This Android client for it (also called Wallabag) is not very sophisticated UI-wise, but it’s a good example of a very simple native client for this kind of service.

Structurally, these apps are all quite similar: a main view with a list of articles, and an article view that just displays the article in a clean, readable format.

Depending on the service, there are multiple lists for different types of articles such as Archive, Highlights, Favorites, Notes, etc. To keep things simple, and because we’re targeting Wallabag first and foremost (since it’s the only self-hosted service), we’re going with only three categories: Unread, Archive, and Favorites.

This means that our application is going to have four main screens we need to design: the three article categories mentioned above plus a reader view, which displays the article content.

3. Sketches/Mockups

Now that we have a basic idea of the structure of the app, we can finally dive into designing the UI. Personally, I like starting off with sketches on paper and then move to Inkscape for more detailed mockups, but you can use any tool you’re familiar with. You don’t need to be good at drawing or a particular application for this, just find a way to visualize your ideas which works for you

If you’re using Inkscape for mockups, you might want to check out the GNOME mockup template which contains some common layouts and patterns to use in your designs. If you are looking for GNOME-style symbolic icons for your mockups, you can find them here, here, and here.


When it comes to the layout of an interface, one of the first things to consider is what navigation structure makes the most sense for the type of content you have.

The most common navigation patterns in GNOME apps are the Stack, the View Switcher, and the Sidebar List.

Example of Stack navigation in GNOME Photos

The Stack pattern is when you have completely separate views with no shared UI, and a back button to go back to the overview. This is what Photos does for navigating between the stream of photos and the detailed view of an individual photo, for example. There is a bit more friction to switch between views than with other patterns, but it’s also more focused. This pattern is great for situations where you don’t switch between views a lot.

View switcher in GNOME Clocks

The View Switcher is for cases where there are a small number of views that are equally important or need to always be easily accessible. It’s used in GNOME apps such as Clocks, Music, and Software as the primary navigation. On the desktop, this switcher is always in the headerbar, but there’s work on a new adaptive version of it, which moves to the bottom of the screen for mobile. This is not quite ready yet, but will hit a version of Libhandy near you soon.

Sidebar List in Fractal

The Sidebar List is for cases where there are a lot of views that you need to switch between often. For example, it’s used in Fractal for the room list, because it gives an overview of all rooms and allows for quick context switching. Of course, on mobile there’s not enough space for a content pane and a sidebar, so there is a Libhandy widget called Leaflet, which transforms from a Sidebar List on desktop to a Stack on mobile.

Experimental branch of GNOME Settings using HdyLeaflet to switch between Sidebar List and Stack navigation

For our read-it-later app, we need navigation to switch between the different lists (Unread, Archive, Favorites), and to switch between list and article views.

The former is a small set of views that we want to be easily accessible, so a view switcher is a good fit. Since we can’t use the shiny new adaptive view switcher widget yet, we can use a plain old view switcher in the header bar for now (though we can already design the UI with the new switcher in mind).

For the latter we could either use a stack or a sidebar list (using the Leaflet widget so it works on mobile). Since we want this app to be a focused reading experience and switching back and forth quickly between articles is not a very common use case, a Stack is probably the best solution here.

This means that our main screens will look something like this:

Quick pencil sketch of the layout for the list and article screens Article List Screens

Now that we have a basic navigation structure we can design the individual screens in more detail. The three article list screens are basically the same lists with different content.

The main purpose of these screens is to provide a nice, legible list of the saved articles that entices people to catch up with their reading list. In order to do this we’re going with a comfortable layout including article title, preview, and some information about the article.

To help people catch up with their saved articles, we should also try to make the content as interesting as possible. A simple reverse-chronological list of saved items is quite boring, and I’ve noticed in my own use that I often scroll down the list randomly to discover older articles. A potential way to build this into the core experience would be to show the reading list in randomized order, and show the most recently saved articles at the top in a separate category. I’ve tried that in the mockups below.

Mockups of the Unread, Archive and Favorites screens (the latter two are structurally identical, though of course in the real app they’d have different content)

In terms of actions, we need to expose search and selection mode (for operations on multiple elements), as well as the application’s primary menu. The primary menu contains global app-level things such as Help, Preferences, and About.

In selection mode we need the ability to move articles to Favorites and Archive, and delete them from our reading list. Since this is not essential functionality though, we won’t be doing designs for it yet. If you want to learn more, have a look at the selection mode page in the GNOME HIG. The same goes for search (relevant HIG page).

Article Screen

The article screen’s job is pretty straightforward: provide a great reading experience for the saved articles. Since many websites kind of suck in this regard, a reader mode (like Epiphany and Firefox have) should be the default view whenever possible. However, since there’s no guarantee that a given article will be rendered perfectly, we need some way to show to the website with its native styling when necessary.

We also need a way to move an article to Favorites and Archive, delete it, and share it. The most important actions are usually exposed directly in the header bar, but for less important actions (or if there’s not enough space), we can use a secondary menu.

Mockup of the article screen Desktop

We now know more or less what the app looks like on mobile, but what about the desktop? As with responsive web design, if you design your app for mobile first, it’s usually pretty easy to make it work well on larger screens too.

In this case, since we don’t have any sidebars or other complicated layout elements, the main change happening at larger sizes is that the content column width grows with the window, until it reaches a maximum width comfortable for reading. This can be implemented by wrapping the content area in an HdyColumn. The view switcher also moves up to the header bar, and there is a close button on the right side.

Desktop mockups of some screens There’s more…

What we now have is the basic structure and most important screens of the application, but that’s of course far from everything. We don’t yet have designs for login and account settings, empty states, first run experience, errors, search, and a number of other things. I wanted to stick to the basics for this post, but perhaps I could expand on these things in future blog posts if there’s interest.

It’s also worth noting that mockups are never final, and interfaces almost always change during implementation, as you learn more about use cases, the underlying technology, and other constraints. Ideally you’d also do some informal user testing on real people, and get feedback on the design that way.

I hope this has been useful as an introduction to designing apps for the Librem 5 (and GNOME more generally). If you have any questions feel free to drop by on #gnome-design on IRC/Matrix or the Librem 5 apps Matrix room (

If you want to play with the mockups I made for this tutorial, here’s the source SVG.

Joachim Breitner: How to merge a Pull Request

Planet Debian - Mër, 27/03/2019 - 11:46pd

It’s easy!

How to merge a pull request

Bits from Debian: Call for Proposals: Debconf 19, Curitiba, Brazil

Planet Debian - Mar, 26/03/2019 - 7:00md

The DebConf Content team would like to call for proposals in the DebConf 19 conference, which will take place in Curitiba, Brazil, between July 21th and 28th. It will be preceded by DebCamp from July 14th to 19th, and Open Day on the 20th.

You can find this Call for Proposals, in its latest form, online:

Please refer to this URL for updates on the present information.

Submitting an Event

You can now submit an event proposal. Events are not limited to traditional presentations or informal sessions (BoFs): we welcome submissions of tutorials, performances, art installations, debates, or any other format of event that you think would be of interest to the Debian community.

Regular sessions may either be 20 or 45 minutes long (including time for questions), other kinds of sessions (workshops, demos, lightning talks, ...) could have different durations. Please choose the most suitable duration for your event and explain any special requests.

You will need to create an account on the site, to submit a talk. We suggest that Debian account holders (including DDs and DMs) to use Debian SSO when creating an account. However, this isn't required, as you can sign up with an e-mail address and password.


If you depend on having your proposal accepted in order to attend the conference, please submit it in a timely fashion so that it can be considered (and potentially accepted) as soon as possible.

All proposals must be submitted before Sunday April 28th, 2019 to be evaluated for the official schedule.

Topics and Tracks

Though we invite proposals on any Debian or FLOSS related subject, we have some broad topics on which we encourage people to submit proposals, including but not limited to:

  • Cloud and containers
  • Debian Blends
  • Debian in Science
  • Embedded
  • Introduction to Free Software & Debian
  • Packaging, policy, and Debian infrastructure
  • Security
  • Social context
  • Systems administration, automation and orchestration

You are welcome to either suggest more tracks, or to become a coordinator for any of them. For more information, see the Content team wiki.

Open Day

This call for proposals also targets Open Day, a day of activities targeted at the general public on July 20th. Topics of interest range from topics specific to Debian to the greater Free Software community and maker movement. The idea of Open Day is to bring the general public closer to Debian and vice-versa, so activity proposals that go in that direction are more than welcome.

If you are interested in presenting on Open Day, let us know in the "Notes" field of your submission. We might also invite proponents that are not specifically targeting Open Day to present in it if we find that the topic fits the above goals.

The Open Day will host activities in multiple languages. We expect to have activities in English, Portuguese, and Spanish.

If your talk will be in portuguese, you can write the Abstract field in portuguese too.

Talk proposal help on IRC

This year we will be holding holding office hours on IRC. Those will be designated times where the DebConf content team will be available to help potential speakers prepare their talk proposals for DebConf.

Dates and times for those will be announced later.

Code of Conduct

Our event is covered by a Code of Conduct designed to ensure everyone’s safety and comfort. The code applies to all attendees, including speakers and the content of their presentations. Do not hesitate to contact us at if you have any questions or are unsure about certain content you’d like to present.

Video Coverage

Providing video is one of the conference goals, as it makes the content accessible to a wider audience. Unless speakers opt-out, scheduled talks may be streamed live over the Internet to promote remote participation, and recordings will be published later under the DebConf license (MIT/Expat), as well as presentation slides and papers whenever available.

Closing note

DebConf 19 is still accepting sponsors; if you are interested, or think you know of others who would be willing to help, please get in touch with

In case of any questions, or if you wanted to bounce some ideas off us first, please do not hesitate to reach out to the content team at

We hope to see you in Curitiba!

The DebConf team

Raphaël Hertzog: Freexian’s report about Debian Long Term Support, February 2019

Planet Ubuntu - Mar, 26/03/2019 - 1:59md

Like each month, here comes a report about the work of paid contributors to Debian LTS.

Individual reports

In February, about 204.5 work hours have been dispatched among 13 paid contributors. Their reports are available:

  • Abhijith PA did 14 hours (out of 14 hours allocated).
  • Adrian Bunk did 8 hours (out of 8 hours allocated).
  • Antoine Beaupré did 16 hours (out of 19.5 hours allocated + 11.5 extra hours, but gave back the remaining hours because he wanted to stop working on LTS).
  • Ben Hutchings did 4 hours (out of 19.5 hours allocated plus 1 extra hour, thus keeping 16.5 extra hours for March).
  • Brian May did 10 hours (out of 10 hours allocated).
  • Chris Lamb did 18 hours (out of 18 hours allocated).
  • Emilio Pozuelo Monfort did 20.5 hours (out of 19.5 hours allocated + 3.25 extra hours, thus keeping 2.25 hours for March).
  • Hugo Lefeuvre did 19.5 hours (out of 19.5 hours allocated).
  • Markus Koschany did 19.5 hours (out of 19.5 hours allocated).
  • Mike Gabriel did 6 hours (out of 10 hours allocated, thus keeping 4 extra hours for March).
  • Ola Lundqvist did 14 hours (out of 8 hours allocated + 8 extra hours, thus keeping 2 extra hours for March).
  • Roberto C. Sanchez did 13.25 hours (out of 19.5 hours allocated + 9.75 extra hours, but he gave back the remaining hours).
  • Thorsten Alteholz did 19.5 hours (out of 19.5 hours allocated).
Evolution of the situation

The number of sponsors (and thus the funding level) did not change for a couple of months. On the contributors side, we have some turn-over: Antoine Beaupré is stopping after many years of good work. Many thanks to him! Fortunately, Sylvain Beucler just started and the workload did not increase too much on existing contributors. But we are still looking for more paid LTS contributors.

The security tracker currently lists 42 packages with a known CVE and the dla-needed.txt file has 28 packages needing an update.

Thanks to our sponsors

New sponsors are in bold (none this month).

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

Raphaël Hertzog: Freexian’s report about Debian Long Term Support, February 2019

Planet Debian - Mar, 26/03/2019 - 1:59md

Like each month, here comes a report about the work of paid contributors to Debian LTS.

Individual reports

In February, about 204.5 work hours have been dispatched among 13 paid contributors. Their reports are available:

  • Abhijith PA did 14 hours (out of 14 hours allocated).
  • Adrian Bunk did 8 hours (out of 8 hours allocated).
  • Antoine Beaupré did 16 hours (out of 19.5 hours allocated + 11.5 extra hours, but gave back the remaining hours because he wanted to stop working on LTS).
  • Ben Hutchings did 4 hours (out of 19.5 hours allocated plus 1 extra hour, thus keeping 16.5 extra hours for March).
  • Brian May did 10 hours (out of 10 hours allocated).
  • Chris Lamb did 18 hours (out of 18 hours allocated).
  • Emilio Pozuelo Monfort did 20.5 hours (out of 19.5 hours allocated + 3.25 extra hours, thus keeping 2.25 hours for March).
  • Hugo Lefeuvre did 19.5 hours (out of 19.5 hours allocated).
  • Markus Koschany did 19.5 hours (out of 19.5 hours allocated).
  • Mike Gabriel did 6 hours (out of 10 hours allocated, thus keeping 4 extra hours for March).
  • Ola Lundqvist did 14 hours (out of 8 hours allocated + 8 extra hours, thus keeping 2 extra hours for March).
  • Roberto C. Sanchez did 13.25 hours (out of 19.5 hours allocated + 9.75 extra hours, thus keeping 16 extra hours for March).
  • Thorsten Alteholz did 19.5 hours (out of 19.5 hours allocated).
Evolution of the situation

The number of sponsors (and thus the funding level) did not change for a couple of months. On the contributors side, we have some turn-over: Antoine Beaupré is stopping after many years of good work. Many thanks to him! Fortunately, Sylvain Beucler just started and the workload did not increase too much on existing contributors. But we are still looking for more paid LTS contributors.

The security tracker currently lists 42 packages with a known CVE and the dla-needed.txt file has 28 packages needing an update.

Thanks to our sponsors

New sponsors are in bold (none this month).

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

Steinar H. Gunderson: Optimal stable filtering

Planet Debian - Mar, 26/03/2019 - 9:22pd

This was originally an email to Casey Muratori's blog post about stable filtering; in it, he left a few open questions. Like me, he doesn't allow comments on his blog, so I sent this by email, but evidently, it didn't make it, because now part 2 is out and still doesn't show how to actually find such filters.

Thus, here are the relevant excerpts:

[...] generally, FIR filter response is calculated by means of the Z-transform, giving a complex response of

Y[w] / X[w] = (... + b2 e^2jw + b1 e^jw + b0) F[w] = sum(k=0..5, e^(jkw) * b_k)

where the normalized frequency w goes from 0..2pi (the interesting part is from 0..pi, the rest is just aliasing), and j = sqrt(-1) so that e^jx = cos(x) + j sin(x).

Your “stability” criterion here seems to be that |F[w]| <= 1, ie., no frequency is ever boosted.

As you've no doubt discovered, the coefficients b_i need to be symmetric (b_0 = b_5, b_1 = b_4, b_2 = b_3); there's a theorem (whose name I've forgotten) that says that this is a necessary and sufficient condition for linear phase (ie., all frequencies are delayed by the same amount). This makes for a great simplification, as we can look at the real part only (the imaginary part will just be the same as the real part multiplied by a constant factor):

|F[w]| = sum(k=0..5, cos(kw) * b_k) / cos(2.5 w)

So we want F[w] to be as close as possible to 1, without ever exceeding it. I'm sure someone will have a fancy way of optimizing it symbolically, but I chose to just sample w a bunch of times from 0..pi and formulate it as a linear program. Ie., every F[w] <= 1, the objective is sum(F[w]) over all sampled w. (I wonder if I should theoretically do abs() somewhere, but it seems not to be needed.)

This returned the coefficients

[0.052519, -0.152582, 0.600063, 0.600063, -0.152582, 0.052519]

which I'm fairly certain are at least accurate to three decimal points; more samples may help with the lower decimals.

The six coeficients sum to almost exactly 1.0, which makes sense; more than that, and very low frequencies would pass the 1.0 limit. I have no idea why the middle coefficient is so close to decimal 0.6, though; there may be some deep reason, but I haven't seen it.

You can see frequency plots by Octave comparing your filter [first] and mine [second]:

You can see that mine is a bit better in the upper filters, trading off a little bit of ripple. I would assume they're fairly close in practice.

Some more discussion hidden deep into ryg's tweets.

David Tomaschik: So You Want to Red Team?

Planet Ubuntu - Mar, 26/03/2019 - 8:00pd

So there’s a lot of confusion out there about Penetration Testing and Red Teaming. I wanted to put together a list of resources for those familiar with infosec or penetration testing who want to get into red teaming or at least get a better understanding of the methodologies and techniques used by red teamers.

First, it’s important to note that Red Teaming is predominantly comprised of two things: alternative analysis and adversary simulation. Red teams do not attempt to find “all the vulnerabilities” and do not usually try to have a wide breadth of coverage. Instead, red teams seek to simulate an adversary with a particular objective, predominantly to act as a “sparring partner” for blue teams. Keep in mind, red teams are the only adversary that will debrief with the blue team so that blue team can figure out what they missed or could have done differently.

For more about the specific definition of Red Teaming, check out the presentation Red Teaming Probably Isn’t For You by fellow red teamer Toby Kohlenberg.

This is not intended to be a comprehensive list of everything you need to know, but more of a “differences course” for those with penetration testing or similar backgrounds to get an introduction to red teaming.

Concepts of Red Teaming Penetration Testing vs Red Teaming Technical Resources (Not Necessarily Red Team Specific) Red Team Courses Conclusion

This is by no means a comprehensive list, and if you have other suggestions, please let me know.

Jonathan Carter: DPL 2019 Election: Rebuttals

Planet Debian - Mar, 26/03/2019 - 5:51pd

Writing rebuttals is not easy. You have to scrutinise the ideas of the people you admire and highlight the flaws in the ideas that they have put a lot of thought in to. At first I wanted to hold back a bit, because I don’t like being mean, but I think it may be a healthy part of the process to offer a critique towards the fellow candidates. I hope that the other candidates will understand that and not take it personally, my feelings towards them have not changed during this process.

Here are the links:

Links to other updated platforms with rebuttals can be found here:

Gunnar Wolf: Many random blurbs on Debian

Planet Debian - Mar, 26/03/2019 - 5:03pd

I have been busy as hell this year. I might have grabbed a bigger bite than what I can swallow – In many fronts! Anyway, sitting at an airport, at least I have time to spew some random blurbs to The Planet and beyond!

We all feared when no candidates showed up at the first call for DPL. But things sorted out themselves as they tend to (and as we all knew that would happen ;-) ), and we have four top-notch DPL candidates. It's getting tough to sort through their platforms and their answers in the lists; the old-timers among us have the additional advantage of knowing who they are and probably having worked closely with some of them. I am still drafting my Condorcet ballot. It won't be an easy task to completely rank them!
DebConf 20 and world politics
For personal and selfish reasons, I am very, very happy to have a reason to go back to Israel after over two decades. Of course, as everybody would expect, there is a bothering level of noise that's not going to quiet down until probably late August 2020... DebConf has often taken controversial turns. Israel is not the toughest one, even if it seems so to some readers. And... Well, to those that want to complain about it — Please do understand that the DebConf Committee is not a politically-acting body. Two bid submissions were presented fully, and the Israeli one was chosen because its local team is stronger. That is probably the best, most important criteria for this conference to be successful. No, it's not like we are betraying anything — It's just the objective best bidding we got from completely volunteer teams.
DebConf 19
What are you waiting for? Register! Submit a talk! Pack up and get your ticket for Brazil!

I'd better get moving, the plane might be getting some ideas about taking off.

Russ Allbery: Spring haul

Planet Debian - Mar, 26/03/2019 - 12:51pd

I think it's becoming safe to call this spring. For once, it's a rainy, cold spring in Northern California. This is a collection of relatively random things (mostly pre-orders) that I've picked up in the last couple of months.

Elizabeth Bear — Ancestral Night (sff)
Robert Jackson Bennett — City of Stairs (sff)
Curtis C. Chen — Kangaroo Too (sff)
Maddox Hahn — The Love Song of Numo and Hammerfist (sff)
Karoliina Korhonen — Finnish NIghtmares (graphic novel)
Ann Leckie — The Raven Tower (sff)
Jenn Lyons — The Ruin of Kings (sff)
Cal Newport — Digital Minimalism (nonfiction)
Noelle Stevenson — Nimona (graphic novel)
Foxfeather Zenkova, et al. — Dry Season Only (nonfiction)

I already read and reviewed Hahn's book, and have read (but not yet written the review of) The Raven Tower by Leckie.

Bits from Debian: Google Platinum Sponsor of DebConf19

Planet Debian - Hën, 25/03/2019 - 12:30md

We are very pleased to announce that Google has committed to support DebConf19 as a Platinum sponsor.

"The annual DebConf is an important part of the Debian development ecosystem and Google is delighted to return as a sponsor in support of the work of the global community of volunteers who make Debian and DebConf a reality" said Cat Allman, Program Manager in the Open Source Programs and Making & Science teams at Google.

Google is one of the largest technology companies in the world, providing a wide range of Internet-related services and products as online advertising technologies, search, cloud computing, software, and hardware.

Google has been supporting Debian by sponsoring DebConf since more than ten years, and is also a Debian partner sponsoring parts of Salsa's continuous integration infrastructure within Google Cloud Platform.

With this additional commitment as Platinum Sponsor for DebConf19, Google contributes to make possible our annual conference, and directly supports the progress of Debian and Free Software helping to strengthen the community that continues to collaborate on Debian projects throughout the rest of the year.

Thank you very much Google, for your support of DebConf19!

Become a sponsor too!

DebConf19 is still accepting sponsors. Interested companies and organizations may contact the DebConf team through, and visit the DebConf19 website at

Petter Reinholdtsen: PlantUML for text based UML diagram modelling - nice free software

Planet Debian - Hën, 25/03/2019 - 9:35pd

As part of my involvement with the Nikita Noark 5 core project, I have been proposing improvements to the API specification created by The National Archives of Norway and helped migrating the text from a version control system unfriendly binary format (docx) to Markdown in git. Combined with the migration to a public git repository (on github), this has made it possible for anyone to suggest improvement to the text.

The specification is filled with UML diagrams. I believe the original diagrams were modelled using Sparx Systems Enterprise Architect, and exported as EMF files for import into docx. This approach make it very hard to track changes using a version control system. To improve the situation I have been looking for a good text based UML format with associated command line free software tools on Linux and Windows, to allow anyone to send in corrections to the UML diagrams in the specification. The tool must be text based to work with git, and command line to be able to run it automatically to generate the diagram images. Finally, it must be free software to allow anyone, even those that can not accept a non-free software license, to contribute.

I did not know much about free software UML modelling tools when I started. I have used dia and inkscape for simple modelling in the past, but neither are available on Windows, as far as I could tell. I came across a nice list of text mode uml tools, and tested out a few of the tools listed there. The PlantUML tool seemed most promising. After verifying that the packages is available in Debian and found its Java source under a GPL license on github, I set out to test if it could represent the diagrams we needed, ie the ones currently in the Noark 5 Tjenestegrensesnitt specification. I am happy to report that it could represent them, even thought it have a few warts here and there.

After a few days of modelling I completed the task this weekend. A temporary link to the complete set of diagrams (original and from PlantUML) is available in the github issue discussing the need for a text based UML format, but please note I lack a sensible tool to convert EMF files to PNGs, so the "original" rendering is not as good as the original was in the publised PDF.

Here is an example UML diagram, showing the core classes for keeping metadata about archived documents:

@startuml skinparam classAttributeIconSize 0 !include media/uml-class-arkivskaper.iuml !include media/uml-class-arkiv.iuml !include media/uml-class-klassifikasjonssystem.iuml !include media/uml-class-klasse.iuml !include media/uml-class-arkivdel.iuml !include media/uml-class-mappe.iuml !include media/uml-class-merknad.iuml !include media/uml-class-registrering.iuml !include media/uml-class-basisregistrering.iuml !include media/uml-class-dokumentbeskrivelse.iuml !include media/uml-class-dokumentobjekt.iuml !include media/uml-class-konvertering.iuml !include media/uml-datatype-elektronisksignatur.iuml Arkivstruktur.Arkivskaper "+arkivskaper 1..*" <-o "+arkiv 0..*" Arkivstruktur.Arkiv Arkivstruktur.Arkiv o--> "+underarkiv 0..*" Arkivstruktur.Arkiv Arkivstruktur.Arkiv "+arkiv 1" o--> "+arkivdel 0..*" Arkivstruktur.Arkivdel Arkivstruktur.Klassifikasjonssystem "+klassifikasjonssystem [0..1]" <--o "+arkivdel 1..*" Arkivstruktur.Arkivdel Arkivstruktur.Klassifikasjonssystem "+klassifikasjonssystem [0..1]" o--> "+klasse 0..*" Arkivstruktur.Klasse Arkivstruktur.Arkivdel "+arkivdel 0..1" o--> "+mappe 0..*" Arkivstruktur.Mappe Arkivstruktur.Arkivdel "+arkivdel 0..1" o--> "+registrering 0..*" Arkivstruktur.Registrering Arkivstruktur.Klasse "+klasse 0..1" o--> "+mappe 0..*" Arkivstruktur.Mappe Arkivstruktur.Klasse "+klasse 0..1" o--> "+registrering 0..*" Arkivstruktur.Registrering Arkivstruktur.Mappe --> "+undermappe 0..*" Arkivstruktur.Mappe Arkivstruktur.Mappe "+mappe 0..1" o--> "+registrering 0..*" Arkivstruktur.Registrering Arkivstruktur.Merknad "+merknad 0..*" <--* Arkivstruktur.Mappe Arkivstruktur.Merknad "+merknad 0..*" <--* Arkivstruktur.Dokumentbeskrivelse Arkivstruktur.Basisregistrering -|> Arkivstruktur.Registrering Arkivstruktur.Merknad "+merknad 0..*" <--* Arkivstruktur.Basisregistrering Arkivstruktur.Registrering "+registrering 1..*" o--> "+dokumentbeskrivelse 0..*" Arkivstruktur.Dokumentbeskrivelse Arkivstruktur.Dokumentbeskrivelse "+dokumentbeskrivelse 1" o-> "+dokumentobjekt 0..*" Arkivstruktur.Dokumentobjekt Arkivstruktur.Dokumentobjekt *-> "+konvertering 0..*" Arkivstruktur.Konvertering Arkivstruktur.ElektroniskSignatur -[hidden]-> Arkivstruktur.Dokumentobjekt @enduml

The format is quite compact, with little redundant information. The text expresses entities and relations, and there is little layout related fluff. One can reuse content by using include files, allowing for consistent naming across several diagrams. The include files can be standalone PlantUML too. Here is the content of media/uml-class-arkivskaper.iuml:

@startuml class Arkivstruktur.Arkivskaper { +arkivskaperID : string +arkivskaperNavn : string +beskrivelse : string [0..1] } @enduml

This is what the complete diagram for the PlantUML notation above look like:

A cool feature of PlantUML is that the generated PNG files include the entire original source diagram as text. The source (with include statements expanded) can be extracted using for example exiftool. Another cool feature is that parts of the entities can be hidden after inclusion. This allow to use include files with all attributes listed, even for UML diagrams that should not list any attributes.

The diagram also show some of the warts. Some times the layout engine place text labels on top of each other, and some times it place the class boxes too close to each other, not leaving room for the labels on the relationship arrows. The former can be worked around by placing extra newlines in the labes (ie "\n"). I did not do it here to be able to demonstrate the issue. I have not found a good way around the latter, so I normally try to reduce the problem by changing from vertical to horizontal links to improve the layout.

All in all, I am quite happy with PlantUML, and very impressed with how quickly its lead developer responds to questions. So far I got an answer to my questions in a few hours when I send an email. I definitely recommend looking at PlantUML if you need to make UML diagrams. Note, PlantUML can draw a lot more than class relations. Check out the documention for a complete list. :)

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

Jelmer Vernooij: Breezy evolves

Planet Debian - Dje, 24/03/2019 - 5:00md

Last month Martin, Vincent and I finally released version 3.0.0 of Breezy, a little over a year after we originally forked Bazaar.

When we started working on Breezy, it was mostly as a way to keep Bazaar working going forward - in a world where Python 2 has mostly disappeared in favour of Python 3).


Since then, we have also made other improvements. In addition to Python 3 support, Breezy comes with the following other bigger changes:

Batteries Included

Breezy bundles most of the common plugins. This makes the installation of Breezy much simpler (pip install brz), and prevents possible issues with API incompatibility that plagued Bazaar.

Bundled plugins include: grep, git, fastimport, propose, upload, stats and parts of bzrtools.

>120 fixed bugs

Since Bazaar 2.7, lots of bugs in the Bazaar code base have been fixed (over 120 as of March 2019). We've also started an effort to go through all bugs in the Bazaar bug tracker to see whether they also apply to Breezy.

Native Git Support

Breezy now supports the Git file formats as a first class citizen; Git support is included in Breezy itself, and should work just as well as regular Bazaar format repositories.

Improved abstractions

Bazaar has always had a higher level API that could be used for version control operations, and which was implemented for both Bazaar, Git and Subversion formats.

As part of the work to support the Git format natively, we have changed the API to remove Bazaar-specific artefacts, like the use of file ids. Inventories (a Bazaar concept) are now also an implementation detail of the bzr formats, and not a concept that is visible in the API or UI.

In the future, I hope the API will be useful for tools that want to make automated changes to any version controlled resource, whether that be Git, Bazaar, Subversion or Mercurial repositories.

Petter Reinholdtsen: Release 0.3 of free software archive API system Nikita announced

Planet Debian - Dje, 24/03/2019 - 2:30md

Yesterday, a new release of Nikita Noark 5 core project was announced on the project mailing list. The free software solution is an implementation of the Norwegian archive standard Noark 5 used by government offices in Norway. These were the changes in version 0.3 since version 0.2.1 (from

  • Improved ClassificationSystem and Class behaviour.
  • Tidied up known inconsistencies between domain model and hateaos links.
  • Added experimental code for blockchain integration.
  • Make token expiry time configurable at upstart from properties file.
  • Continued work on OData search syntax.
  • Started work on pagination for entities, partly implemented for Saksmappe.
  • Finalise ClassifiedCode Metadata entity.
  • Implement mechanism to check if authentication token is still valid. This allow the GUI to return a more sensible message to the user if the token is expired.
  • Reintroduce browse.html page to allow user to browse JSON API using hateoas links.
  • Fix bug in handling file/mappe sequence number. Year change was not properly handled.
  • Update application yml files to be in sync with current development.
  • Stop 'converting' everything to PDF using libreoffice. Only convert the file formats doc, ppt, xls, docx, pptx, xlsx, odt, odp and ods.
  • Continued code style fixing, making code more readable.
  • Minor bug fixes.

If free and open standardized archiving API sound interesting to you, please contact us on IRC (#nikita on or email (nikita-noark mailing list).

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

Riku Voipio: On the #uploadfilter problem

Planet Debian - Sht, 23/03/2019 - 5:07md
The copyright holders in europe are pushing hard mandate upload filters for internet. We have been here before - when they outlawed circumventing DRM. Both have roots in the same problem. The copyright holders look at computers and see bad things happening to their revenue. They come to IT companies and say "FIX IT". It industry comes back and says.. "We cant.. making data impossible to copy is like trying to make water not wet!". But we fail at convincing copyright holders in how perfect DRM or upload filter is not possible. Then copyright holders go to law makers and ask them in turn to fix it.

We need to turn tables around. If they want something impossible, it should be upto them to implement it.

It is simply unfair to require each online provider to implement an AI to detect copyright infringement, manage a database of copyrighted content and pay for the costs running it all.. ..And getting slapped with a lawsuit anyways, since copyrighted content is still slipping through.

The burden of implementing #uploadfilter should be on the copyright holder organizations. Implement as a SaaS. Youtube other web platforms call your API and pay $0.01 each time a pirate content is detected. On the other side, to ensure correctness of the filter, copyright holders have to pay any lost revenue, court costs and so on for each false positive.

Filtering uploads is still problematic. But it's now the copyright holders problem. Instead people blaming web companies for poor filters, it's the copyright holders now who have to answer to the public why their filters are rejecting content that doesn't belong to them.

Dirk Eddelbuettel: RcppArmadillo 0.9.300.2.0

Planet Debian - Pre, 22/03/2019 - 11:57md

A new RcppArmadillo release based on a new Armadillo upstream release arrived on CRAN and Debian today.

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

The (upstream-only this time) changes are listed below:

Changes in RcppArmadillo version 0.9.300.2.0 (2019-03-21)
  • Upgraded to Armadillo release 9.300.2 (Fomo Spiral)

    • Faster handling of compound complex matrix expressions by trace()

    • More efficient handling of element access for inplace modifications in sparse matrices

    • Added .is_sympd() to check whether a matrix is symmetric/hermitian positive definite

    • Added interp2() for 2D data interpolation

    • Added expm1() and log1p()

    • Expanded .is_sorted() with options "strictascend" and "strictdescend"

    • Expanded eig_gen() to optionally perform balancing prior to decomposition

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

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

Enrico Zini: debian-vote statistics

Planet Debian - Pre, 22/03/2019 - 12:48md

Updated: re-run after merging Andreas Tille's addresses

Updated: re-run after fixing a bug in the code that skips signatures

Updated: re-run on a mailbox with only the post-nomination discussion.

I made a script to compute some statistics on debian-vote's election discussions.

Here are the result as of 2019-03-23 08:15 UTC+1:

These are the number of mails sent by people who posted more than 2 messages:

Name Mails ============================== Joerg Jaspert 15 Martin Michlmayr 13 Andreas Tille 11 Jonathan Carter 11 Sam Hartman 8 Lucas Nussbaum 7 Jose Miguel Parrella 5 Sean Whitton 4 Ian Jackson 3

These are sum and averages of lines of non-quoted message text sent by people:

Name Sum Avg ================================== Jonathan Carter 604 55 Sam Hartman 389 49 Martin Michlmayr 346 27 Joerg Jaspert 306 20 Andreas Tille 287 26 Lucas Nussbaum 165 24 Ian Jackson 140 47 Jose Miguel Parrella 136 27 Sean Whitton 49 12

These are the top keywords of messages sent by the candidates so far, scored by an improvised TFIDF metric:

Sam Hartman people, valuable, doing, ways, focus, work, might Jonathan Carter software, perhaps, help, make, free, large, easier Joerg Jaspert upload, thing, nice, something, good, such, just Martin Michlmayr believe, maybe, foss, change, question, absolutely, people


Subscribe to AlbLinux agreguesi