26 Jun 2019

feedPlanet Debian

Matrix on Debian blog: June 2019 Matrix on Debian update

This is an update on the state of Matrix-related software in Debian.


Unfortunately, the recently published Synapse 1.0 didn't make it into Debian Buster, which is due to be released next week, so if you install 0.99.2 from Buster, you need to update to a newer version which will be available from backports shortly after the release.

Originally, 0.99 was meant to be the last version before 1.0, but due to a bunch of issues discovered since then, some of them security-related, new incompatible room format was introduced in 0.99.5. This means 0.99.2 currently in Debian Buster is going to only see limited usefulness, since rooms are being upgraded to the new format as 1.0 is being deployed across the network.

For those of you running forever unstable Sid, good news: Synapse 1.0 is now available in unstable! ACME support has not yet been enabled, since it requires a few packages not yet in Debian (they're currently in the NEW queue). We hope it will be available soon after Buster is released.


The main window of Quaternion showing the Unofficial Debian chat room in Matrix, a list of members of the room on the right, and a list of channels on the left

Quaternion is being packaged by Hubert Chathi, soon to be uploaded. Hubert has already updated and uploaded libqmatrixclient and olm, which are waiting in NEW.


On the left, a terminal window with a Curses front-end of Circle running. On the right, a graphical window running a GTK 2 front-end of Circle. Both window show the same window with IRC connection logs

There's been some progress on packaging Circle, a modular IRC client with Matrix support. The backend and IRC support have been available for some time in Debian already, but to be useful, it also needs a user-interfacing front-end. The GTK 2 front-end has just been uploaded to Debian, as have the necessary Perl modules for Matrix support. All of the said packages are now being reviewed in the NEW queue.


Early in June, Andrej Shadura looked into packaging Fractal, but found a few crates being of incompatible versions in Debian compared to what upstream expects. A current blocker is a pending release of rust-phf.

Get in touch

Come chat to us in #debian-matrix:matrix.org!

26 Jun 2019 7:36pm GMT

Sam Hartman: AH/DAM/DPL Meet Up

All the members of the Antiharassment team met with the Debian Account Managers and the DPL in that other Cambridge- the one with proper behaviour, not the one where pounds are weight and not money.

I was nervous. I was not part of decision making earlier this year around code of conduct issues. I was worried that my concerns would be taken as insensitive judgment applied by someone who wasn't there.

I was worried about whether I would find my values aligned with the others. I care about treating people with respect. I also care about freedom of expression. I value a lot of feminist principles and fighting oppression. Yet I'm happy with my masculinity. I acknowledge my privilege and have some understanding of the inequities in the world. Yet I find some arguments based on privilege problematic and find almost all uses of the phrase "check your privilege" to be dismissive and to deny any attempt at building empathy and understanding.

And Joerg was there. He can be amazingly compassionate and helpful. He can also be gruff at times. He values brevity, which I'm not good at. I was bracing myself for a sharp, brief, gruff rebuke delivered in response to my feedback. I know there would be something compassionate under such a rebuke, but it might take work to find.

The meeting was hard; we were talking about emotionally intense issues. But it was also wonderful. We made huge progress. This blog is not about reporting that progress.

Like the other Debian meetings I've been at, I felt like I was part of something wonderful. We sat around and described the problems we were working on. They were social not technical. We brainstormed solutions, talked about what worked, what didn't work. We disagreed. We listened to each other. We made progress.

Listening to the discussions on debian-private in December and January, it sounded like DAM and Antiharassment thought they had it all together. I got a note asking if I had any suggestions for how things could have been done better. I kind of felt like they were being polite and asking since I had offered support.

Yet I know now that they were struggling as much as any of us struggle with a thorny RC bug that crosses multiple teams and packages. The account managers tried to invent suspensions in response to what was going on. They wanted to take a stand against bullying and disrespectful behavior. But they didn't want to drive away contributors; they wanted to find a way to let people know that a real problem required immediate attention. Existing tools were inadequate. So they invented account suspensions. It was buggy. And when your social problem solving tools are buggy, people get hurt.

But I didn't find myself facing off against that mythical group of people sure in their own actions I had half imagined. I found myself sitting around a table with members of my community, more alike than different. They had insecurities just like I do. They doubted themselves. I'm sure there was some extent to which they felt it was the project against them in December and January. But they also felt some of that pain that raged across debian-private. They didn't think they had the answers, and they wanted to work with all of us to find them.

I found a group of people who genuinely care about openness and expressing dissenting views. The triggers for action were about how views were expressed not about those views. The biggest way to get under DAM's skin and get them started thinking about whether there is a membership issue appears to be declining to engage constructively when someone wants to talk to you about a problem. In contrast, even if something has gone horribly wrong trying to engage constructively is likely to get you the support of all of us around that table in finding a way to meet your needs as well as the greater project.

Fear over language didn't get in our way. People sometimes made errors about using someone's preferred pronouns. It wasn't a big deal: when they noticed they corrected themselves, acknowledged that they cared about the issue and went on with life. There was cursing sometimes and some really strong feelings.

There was even a sex joke. Someone talked about sucking and someone else intentionally misinterpreted it in a sexual context. But people payed attention to the boundaries of others. I couldn't have gotten away with telling that joke: I didn't know the people well enough to know their boundaries. It is not that I'm worried I'll offend. It is that I actively want to respect the others around me. One way I can do that is to understand their boundaries and respect them.

One joke did cross a line. With a series of looks and semi-verbal communication, we realized that was probably a bit too far for that group while we were meeting. The person telling the joke acknowledged and we moved on.

I was reassured that we all care about the balance that allows Debian to work. We bring the same dedication to creating the universal operating system that we do to building our community. With sufficient practice we'll be really good at the community work. I'm excited!

26 Jun 2019 2:42pm GMT

Jonathan McDowell: Support your local Hackerspace

My first Hackerspace was Noisebridge. It was full of smart and interesting people and I never felt like I belonged, but I had just moved to San Francisco and it had interesting events, like 5MoF, and provided access to basic stuff I hadn't moved with me, like a soldering iron. While I was never a heavy user of the space I very much appreciated its presence, and availability even to non-members. People were generally welcoming, it was a well stocked space and there was always something going on.

These days my local hackerspace is Farset Labs. I don't have a need for tooling in the same way, being lucky enough to have space at home and access to all the things I didn't move to the US, but it's still a space full of smart and interesting people that has interesting events. And mostly that's how I make use of the space - I attend events there. It's one of many venues in Belfast that are part of the regular Meetup scene, and for a while I was just another meetup attendee. A couple of things changed the way I looked at. Firstly, for whatever reason, I have more of a sense of belonging. It could be because the tech scene in Belfast is small enough that you'll bump into the same people at wildly different events, but I think that's true of the tech scene in most places. Secondly, I had the realisation (and this is obvious once you say it, but still) that Farset was the only non-commercial venue that was hosting these events. It's predominantly funded by members fees; it's not getting Invest NI or government subsidies (though I believe Weavers Court is a pretty supportive landlord).

So I became a member. It then took me several months after signing up to actually be in the space again, but I feel it's the right thing to do; without the support of their local tech communities hackerspaces can't thrive. I'm probably in Farset at most once a month, but I'd miss it if it wasn't there. Plus I don't want to see such a valuable resource disappear from the Belfast scene.

And that would be my message to you, dear reader. Support your local hackerspace. Become a member if you can afford it, donate what you can if not, or just show up and help out - as non-commercial entities things generally happen as a result of people turning up and volunteering their time to help out.

(This post prompted by a bunch of Small Charity Week tweets last week singing the praises of Farset, alongside the announcement today that Farset Labs is expanding - if you use the space and have been considering becoming a member or even just donating, now is the time to do it.)

26 Jun 2019 1:43pm GMT

25 Jun 2019

feedPlanet Debian

Jonathan Carter: PeerTube and LBRY

I have many problems with YouTube, who doesn't these days, right? I'm not going to go into all the nitty gritty of it in this post, but here's a video from a LBRY advocate that does a good job of summarizing some of the issues by using clips from YouTube creators:

(link to the video if the embedded video above doesn't display)

I have a channel on YouTube for which I have lots of plans for. I started making videos last year and created 59 episodes for Debian Package of the Day. I'm proud that I got so far because I tend to lose interest in things after I figure out how it works or how to do it. I suppose some people have assumed that my video channel is dead because I haven't uploaded recently, but I've just been really busy and in recent weeks, also a bit tired as a result. Things should pick up again soon.

Mediadrop and PeerTube

I wanted to avoid a reliance on YouTube early on, and set up a mediadrop instance on highvoltage.tv. Mediadrop ticks quite a few boxes but there's a lot that's missing. On top of that, it doesn't seem to be actively developed anymore so it will probably never get the features that I want.

Screenshot of my MediaDrop instance.

I've been planning to move over to PeerTube for a while and hope to complete that soon. PeerTube is a free software video hosting platform that resemble YouTube style video sites. It's on the fediverse and videos viewed by users are shared by webtorrents to other users who are viewing the same videos. After reviewing different video hosting platforms last year during DebCamp, I also came to the conclusion that PeerTube is the right platform to host DebConf and related Debian videos on. I intend to implement an instance for Debian shortly after I finish up my own migration.

(link to PeerTube video if embedded video doesn't display)

Above is an introduction of PeerTube by its creators (which runs on PeerTube so if you've never tried it out before, there's your chance!)


LBRY App Screenshot

LBRY takes a drastically different approach to the video sharing problem. It's not yet as polished as PeerTube in terms of user experience and it's a lot newer too, but it's interesting in its own right. It's also free software and implements it's own protocol that you access on lbry:// URIs and it prioritizes it's own native apps over accessing it in a web browser. Videos are also shared on its peer-to-peer network. One big thing that it implements is its own blockchain along with its own LBC currency (don't roll your eyes just yet it's not some gimmick from 2016 ;) ). It's integrated with the app so viewers can easily give a tip to a creator. I think that's better than YouTube's ad approach because people can earn money by the value their video provides to the user, not by the amount of eyes they bring to the platform. It's also possible for creators to create paid for content, although I haven't seen that on the platform yet.

If you try out LBRY using my referral code I can get a whole 20 LBC (1 LBC is nearly USD $0.04 so I'll be rich soon!). They also have a sync system that can sync all your existing YouTube videos over to LBRY. I requested this yesterday and it's scheduled so at some point my YouTube videos will show up on my @highvoltage channel on LBRY. Their roadmap also includes some interesting reading.

I definitely intend to try out LBRY's features and it's unique approach, although for now my plan is to use my upcoming PeerTube instance as my main platform. It's the most stable and viable long-term option at this point and covers all the important features that I care about.

25 Jun 2019 7:14pm GMT

Ian Jackson: Important walking/cycle link closed, poor diversion, terrible signage

Highways England have decided to close the busway track under the A14 in Cambridge. Initially now for 2 weeks, but we hear rumours of an 8-week closure later in the year.


Summary of the diversion

Overall, the extra distance is 2.7km and has an additional 9 traffic lights. One is out use meaning you have to take your life in your hands crossing at a junction where the motor vehicles have a green light.

The extra time for a pedestrian is probably about 30 minutes, replacing a 15 minute walk. For a cyclist, a pleasant 4-5 minute link, covering most of the distance between the Science Park and Histon, becomes a 15 minute odyssey.


From Histon, in pictures

( Read more... )

comment count unavailable comments

25 Jun 2019 3:50pm GMT

Dirk Eddelbuettel: RcppTOML 0.1.6: Tinytest support and more robustification

A new RcppTOML release is now on CRAN. RcppTOML brings TOML to R.

TOML is a file format that is most suitable for configurations, as it is meant to be edited by humans but read by computers. It emphasizes strong readability for humans while at the same time supporting strong typing as well as immediate and clear error reports. On small typos you get parse errors, rather than silently corrupted garbage. Much preferable to any and all of XML, JSON or YAML - though sadly these may be too ubiquitous now. TOML has been making inroads with projects such as the Hugo static blog compiler, or the Cargo system of Crates (aka "packages") for the Rust language.

Václav Hausenblas sent a number of excellent and very focused PRs helping with some input format corner cases, as well as with one test. We added support for the wonderful new tinytest package. The detailed list of changes in this incremental version is below.

Changes in version 0.1.6 (2019-06-25)

  • Propagate the escape switch to calls of getTable() and getArray() (Václav Hausenblas in #32 completing #26). Hausenblas in #36 completing #26)

  • The README.md file now mentions TOML v0.5.0 support (Watal Iwasaki in #35 addressing #33).

  • Encodings in arrays is to UTF-8 for character (Václav Hausenblas in #36 completing #28)

  • The package now use tinytest (Dirk in #38 fixing #37, also Václav in #39).

Courtesy of CRANberries, there is a diffstat report for this release.

More information is on the RcppTOML page page. Issues and bugreports should go to the GitHub issue tracker.

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

25 Jun 2019 12:14pm GMT

24 Jun 2019

feedPlanet Debian

Gunnar Wolf: LIDSOL: teaching privacy and anonymity concepts and tools to social scientists

I have been working on several privacy/anonymity topics in the past couple of years. And I am very happy, as we just achieved one of our most important stated goals.

I am coordinating LIDSOL, Laboratorio de Investigación y Desarrollo de Software Libre, at the Engineering Faculty, UNAM. LIDSOL is a very interesting and very open lab regularly inhabited by ≈7 bright students, most of them from Computer Engineering (but some from other careers in the faculty), and with over twenty years of history. And I have worked with several of them in my PAPIME project for privacy and anonymity. This time, the task was -after working a year on the broad topic- for the students to plan and present a course titled Privacidad y anonimato para un manejo seguro de mi información en redes» - Privacy and anonymity for safely handling my online information, as part of the Political and Social Sciences Faculty's intersemestral courses on technological updating.

The covered program was quite ambitious; I'm not translating it, you can look at it in Spanish in the course's information. The LIDSOL instructors (please, a round of applause for them!) were:

My friend Lourdes Reséndiz, who works at FCPyS and got us the space to present the course, also gave a module.

Lourdes, during the famous three envelopes dynamic for explaining onion routing

I felt the course to be a great success, and we were asked to repeat it in the future. As any course presenting anonymization technologies, it was of course not without its controversy and discussion - which was great! I think we got many concepts clarified for the attendees. I will later report on any measurable accounts we got, of course!

Attachment Size
grupo_priv.1500.jpg 835.55 KB
2019-II Cedula - Privacidad y anonimato para un manejo seguro de mi información en redes.pdf 96.53 KB
introd.1500.jpg 365.73 KB
tres-sobres.1500.jpg 382.81 KB

24 Jun 2019 3:46am GMT

23 Jun 2019

feedPlanet Debian

Dirk Eddelbuettel: binb 0.0.4: Several nice improvements

The fourth release of the binb package just arrived on CRAN. binb regroups four rather nice themes for writing LaTeX Beamer presentations much more easily in in (R)Markdown. As a teaser, a quick demo combining all four themes follows; documentation and examples are in the package.

This release brings a few nice pull requests. Rob Hyndman, improved the Monash theme. Johan Larsson added support for slide notes, pgfpages and beamer options. Joseph Stachelek corrected the date setting in the Presento theme to reflect the date from the YAML header.

Changes in binb version 0.0.4 (2018-06-23)

  • The Monash theme now has improved color theme handling (Rob Hyndman in #15)

  • The Monash them has a demo, a new tighttoc option and other small improvements (Rob Hyndman in #16).

  • A slide notes example was added to Metropolis, pgfpages can be used if present, beameroption was added to three templates (Johan Larsson in #17).

  • The Presento them now use the date from the yaml header (Joseph Stachelek in #18)

CRANberries provides the usual summary of changes to the previous version.

For questions or comments, please use the issue tracker off the GitHub repo.

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

23 Jun 2019 3:49pm GMT

21 Jun 2019

feedPlanet Debian

Simon Josefsson: OpenPGP smartcard under GNOME on Debian 10 Buster

Debian buster is almost released, and today I celebrate midsummer by installing (a pre-release) of it on my Lenovo X201 laptop. Everything went smooth, except for the usual issues with smartcards under GNOME. I use a FST-01G running Gnuk, but the same issue apply to all OpenPGP cards including YubiKeys. I wrote about this problem for earlier releases, read Smartcards on Debian 9 Stretch and Smartcards on Debian 8 Jessie. Some things have changed - now GnuPG's internal ccid support works, and dirmngr is installed by default when you install Debian with GNOME. I thought I'd write a new post for the new release.

After installing Debian and logging into GNOME, I start a terminal and attempt to use the smartcard as follows.

jas@latte:~$ gpg --card-status
gpg: error getting version from 'scdaemon': No SmartCard daemon
gpg: OpenPGP card not available: No SmartCard daemon

The reason is that the scdaemon package is not installed. Install it as follows.

jas@latte:~$ sudo apt-get install scdaemon

After this, gpg --card-status works. It is now using GnuPG's internal CCID library, which appears to be working. The pcscd package is not required to get things working any more - however installing it also works, and you might need pcscd if you use other applications that talks to the smartcard.

jas@latte:~$ Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.2.14-67252015) 00 00
Application ID ...: D276000124010200FFFE672520150000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 67252015
Name of cardholder: Simon Josefsson
Language prefs ...: sv
Sex ..............: man
URL of public key : https://josefsson.org/key-20190320.txt
Login data .......: jas
Signature PIN ....: inte tvingad
Key attributes ...: ed25519 cv25519 ed25519
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 710
KDF setting ......: off
Signature key ....: A3CC 9C87 0B9D 310A BAD4  CF2F 5172 2B08 FE47 45A2
      created ....: 2019-03-20 23:40:49
Encryption key....: A9EC 8F4D 7F1E 50ED 3DEF  49A9 0292 3D7E E76E BD60
      created ....: 2019-03-20 23:40:26
Authentication key: CA7E 3716 4342 DF31 33DF  3497 8026 0EE8 A9B9 2B2B
      created ....: 2019-03-20 23:40:37
General key info..: [none]

As before, using the key does not work right away:

jas@latte:~$ echo foo|gpg -a --sign
gpg: no default secret key: No public key
gpg: signing failed: No public key

This is because GnuPG does not have the public key that correspond to the private key inside the smartcard.

jas@latte:~$ gpg --list-keys
jas@latte:~$ gpg --list-secret-keys

You may retrieve your public key from the clouds as follows. With Debian Buster, the dirmngr package is installed by default so there is no need to install it. Alternatively, if you configured your smartcard with a public key URL that works, you may type "retrieve" into the gpg --card-edit interactive interface. This could be considered slightly more reliable (at least from a self-hosting point of view), because it uses your configured URL for retrieving the public key rather than trusting clouds.

jas@latte:~$ gpg --recv-keys "A3CC 9C87 0B9D 310A BAD4  CF2F 5172 2B08 FE47 45A2"
gpg: key D73CF638C53C06BE: public key "Simon Josefsson <simon@josefsson.org>" imported
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2019-10-22
gpg: Total number processed: 1
gpg:               imported: 1

Now signing with the smart card works! Yay! Btw: compare the output size with the output size in the previous post to understand the size advantage with Ed25519 over RSA.

jas@latte:~$ echo foo|gpg -a --sign


As before, encrypting to myself does not work smoothly because of the trust setting on the public key. Witness the problem here:

jas@latte:~$ echo foo|gpg -a --encrypt -r simon@josefsson.org
gpg: 02923D7EE76EBD60: There is no assurance this key belongs to the named user

sub  cv25519/02923D7EE76EBD60 2019-03-20 Simon Josefsson <simon@josefsson.org>
 Primary key fingerprint: B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
      Subkey fingerprint: A9EC 8F4D 7F1E 50ED 3DEF  49A9 0292 3D7E E76E BD60

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) 
gpg: signal Interrupt caught ... exiting


You update the trust setting with the gpg --edit-key command. Take note that this is not the general way of getting rid of the "There is no assurance this key belongs to the named user" warning - using a ultimate trust setting is normally only relevant for your own keys, which is the case here.

jas@latte:~$ gpg --edit-key simon@josefsson.org
gpg (GnuPG) 2.2.12; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret subkeys are available.

pub  ed25519/D73CF638C53C06BE
     created: 2019-03-20  expires: 2019-10-22  usage: SC  
     trust: unknown       validity: unknown
ssb  cv25519/02923D7EE76EBD60
     created: 2019-03-20  expires: 2019-10-22  usage: E   
     card-no: FFFE 67252015
ssb  ed25519/80260EE8A9B92B2B
     created: 2019-03-20  expires: 2019-10-22  usage: A   
     card-no: FFFE 67252015
ssb  ed25519/51722B08FE4745A2
     created: 2019-03-20  expires: 2019-10-22  usage: S   
     card-no: FFFE 67252015
[ unknown] (1). Simon Josefsson <simon@josefsson.org>

gpg> trust
pub  ed25519/D73CF638C53C06BE
     created: 2019-03-20  expires: 2019-10-22  usage: SC  
     trust: unknown       validity: unknown
ssb  cv25519/02923D7EE76EBD60
     created: 2019-03-20  expires: 2019-10-22  usage: E   
     card-no: FFFE 67252015
ssb  ed25519/80260EE8A9B92B2B
     created: 2019-03-20  expires: 2019-10-22  usage: A   
     card-no: FFFE 67252015
ssb  ed25519/51722B08FE4745A2
     created: 2019-03-20  expires: 2019-10-22  usage: S   
     card-no: FFFE 67252015
[ unknown] (1). Simon Josefsson <simon@josefsson.org>

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y

pub  ed25519/D73CF638C53C06BE
     created: 2019-03-20  expires: 2019-10-22  usage: SC  
     trust: ultimate      validity: unknown
ssb  cv25519/02923D7EE76EBD60
     created: 2019-03-20  expires: 2019-10-22  usage: E   
     card-no: FFFE 67252015
ssb  ed25519/80260EE8A9B92B2B
     created: 2019-03-20  expires: 2019-10-22  usage: A   
     card-no: FFFE 67252015
ssb  ed25519/51722B08FE4745A2
     created: 2019-03-20  expires: 2019-10-22  usage: S   
     card-no: FFFE 67252015
[ unknown] (1). Simon Josefsson <simon@josefsson.org>
Please note that the shown key validity is not necessarily correct
unless you restart the program.

gpg> quit

Confirm gpg --list-keys indicate that the key is now trusted, and encrypting to yourself should work.

jas@latte:~$ gpg --list-keys
pub   ed25519 2019-03-20 [SC] [expires: 2019-10-22]
uid           [ultimate] Simon Josefsson <simon@josefsson.org>
sub   ed25519 2019-03-20 [A] [expires: 2019-10-22]
sub   ed25519 2019-03-20 [S] [expires: 2019-10-22]
sub   cv25519 2019-03-20 [E] [expires: 2019-10-22]

jas@latte:~$ gpg --list-secret-keys
sec#  ed25519 2019-03-20 [SC] [expires: 2019-10-22]
uid           [ultimate] Simon Josefsson <simon@josefsson.org>
ssb>  ed25519 2019-03-20 [A] [expires: 2019-10-22]
ssb>  ed25519 2019-03-20 [S] [expires: 2019-10-22]
ssb>  cv25519 2019-03-20 [E] [expires: 2019-10-22]

jas@latte:~$ echo foo|gpg -a --encrypt -r simon@josefsson.org
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2019-10-22


The issue with OpenSSH and GNOME Keyring still exists as in previous releases.

jas@latte:~$ ssh-add -L
The agent has no identities.
jas@latte:~$ echo $SSH_AUTH_SOCK 

The trick we used last time still works, and as far as I can tell, it is still the only recommended method to disable the gnome-keyring ssh component. Notice how we also configure GnuPG's gpg-agent to enable SSH daemon support.

jas@latte:~$ mkdir ~/.config/autostart
jas@latte:~$ cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/
jas@latte:~$ echo 'Hidden=true' >> ~/.config/autostart/gnome-keyring-ssh.desktop 
jas@latte:~$ echo enable-ssh-support >> ~/.gnupg/gpg-agent.conf 

Log out of GNOME and log in again. Now the environment variable points to gpg-agent's socket, and SSH authentication using the smartcard works.

jas@latte:~$ echo $SSH_AUTH_SOCK 
jas@latte:~$ ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE cardno:FFFE67252015

Topics for further discussion and research this time around includes:

  1. Should scdaemon (and possibly pcscd) be pre-installed on Debian desktop systems?
  2. Could gpg --card-status attempt to import the public key and secret key stub automatically? Alternatively, some new command that automate the bootstrapping of a new smartcard.
  3. Should GNOME keyring support smartcards?
  4. Why is GNOME keyring used by default for SSH rather than gpg-agent?
  5. Should gpg-agent default to enable the SSH daemon?
  6. What could be done to automatically infer the trust setting for a smartcard based private key?

Thanks for reading and happy smartcarding!

21 Jun 2019 6:09pm GMT

Candy Tsai: Outreachy Week 5: What is debci?

The theme for this week in Outreachy is "Think About Your Audience". So I'm currently thinking about you.

Or not?

After being asked sooo many times what am I doing for this internship, I think I never explained it well enough so that others could understand. Let me give it a try here.

debci is short for "Debian Continuous Integration", so I'll start with a short definition of what "Continuous Integration" is then!

Continuous Integration (CI)

Since there should be quite some articles talking about this topic, here is a quick explanation that I found on Microsoft Azure (link):

Continuous Integration (CI) is the process of automating the build and testing of code every time a team member commits changes to version control.

A scenario would be whenever I push code to Debian Salsa Gitlab, it automatically runs the tests we have written in our code. This is to make sure that the new code changes doesn't break the stuff that used to work.

The debci Project

Before Debian puts out a new release, all of the packages that have tests written in them need to be tested. debci is a platform for testing packages and provides a UI to see if they pass or not. The goal is to make sure that the the packages will pass their tests before a major Debian release. For example, when the ruby-defaults package is updated, we not only want to test ruby-defaults but also all the packages that depend on it. In short, debci helps make sure the packages are working correctly.

For my internship, I am working on improving the user experience through the UI of the debci site. The most major task is to let developers easily test their packages with packages in different suites and architectures.

The terms that keep popping up in debci are:

There are three obvious suites on the debci site right now, namely unstable, testing and stable. There is also an experimental suite that a user can test their packages upon. And architecture is like amd64 or arm64.

The life of a package is something like this:

  1. When a package is updated/added, it goes into unstable
  2. After it has stayed 2-10 days in unstable without any big issues, it moves into testing
  3. It becomes stable after a release

Normally a package moves from unstable > testing > stable

Let's say, a user wants to test the ruby-defaults package in unstable on amd64 along with a package C from experimental. Here package C would be a pin-package, which means the package the user wants to test along with. Last but not least, trigger is just the name of the test job, one can choose to use it or not.

Currently, there is an API that you make this request with curl or something similar, but it's not very friendly since not everyone is familiar with how the request should look like. Therefore, not a lot of people are willing to use it and I have also seen requests for an improvement on this in the #debci channel. An easy to use UI might be the solution to make requesting these tests easier. Knowing what I am working on is useful for others is an important key to keep myself motivated.

The debci Community

The debci community is very small but active. The people that are directly involved are my mentors: terceiro and elbrus. Sometimes people drop by the IRC channel to ask questions, but basically that's it. This works pretty good for me, because I'm usually not at ease and will keep a low profile if the community gets too large.

I'm not familiar with the whole Debian community, but I have also been hanging around the #debian-outreach channel. It felt warm to know that someone realized there was an intern from Taiwan for this round of Outreachy. As far as I have experienced, everyone I have chatted with were nice and eager to share which Debian-related communities were close to me.

Week 5: Modularizing & Testing

This week I worked on adding tests and tried pulling out the authentication code to make the code a bit more DRY.

And… probably also writing this blog post! I found that blogging takes up more time than I thought it should.

21 Jun 2019 9:33am GMT

Sven Hoexter: logstash json filter error

If you've a logstash filter that contains a json filter/decoding step like

filter { json { source => "log" } }

this, and you end up with an error message like that:

[2019-06-21T09:47:58,243][WARN ][logstash.filters.json ] Error parsing json {:source=>"log", :raw=>{"file"=>{"path"=>"/var/lib/docker/containers/abdf3db21fca8e1dc17c888d4aa661fe16ae4371355215157cf7c4fc91b8ea4b/abdf3db21fca8e1dc17c888d4aa661fe16ae4371355215157cf7c4fc91b8ea4b-json.log"}}, :exception=>java.lang.ClassCastException}

It might be just telling you that the field log actually does contain valid json, and no decoding is required.

21 Jun 2019 8:08am GMT

20 Jun 2019

feedPlanet Debian

Mathieu Parent: Announcing GitLabracadabra 0.2.1

Hello all,

Mid-October I started at work a tool in Python to create and update our projects hosted in our GitLab instance.

I have now reworked and published this tool called GitLabracadabra.

This tool is still very young and documentation is sparse, but following the "release early, release often" motto I think it is ready for general usage.

Please report any bug or suggestion in the bug tracker. that I just enabled 😉 :

$ gitlabracadabra --verbose
2019-06-20 16:59:19,144 [29120] INFO gitlabracadabra.objects.object: [gitlabracadabra/gitlabracadabra] Changing param issues_enabled: False -> True

20 Jun 2019 3:13pm GMT

Louis-Philippe Véronneau: membernator -- validate membership cards

I currently work part-time for student unions in Montreal and they often have large general assemblies (more than 2000 people). As you can likely figure out by yourself, running through paper lists to validate people's identity is a real PITA and takes quite a long time.

For example, even if you have 4 people checking names, if validating someone's identity takes 5 seconds on average (that's pretty fast), it takes around 40 minutes to go through 2000 people.

Introducing membernator, a python program written using pygame that validates membership cards against a CSV database! The idea is to use barcode scanners to scan people's school ID cards and see if they are in our digital lists. Hopefull, it will make our GA process easier for everyone.

I want to thank Jonathan Carter who provided the inspiration (and a codebase) for this project. membernator is a heavily-modified fork of ToeTally, a program currently in developpement for the DebConf Video Team.

membernator will eventually be packaged in Debian (I've started packaging stuff!), but for now you can either install it manually or get it from PyPi.

Here's a quick video of what running membernator looks like. I'm typing the IDs by hand since I left my barcode scanner at work. Excuse the weird screen glitches, it seems I'm somewhat bad a screen recording.

20 Jun 2019 3:45am GMT

19 Jun 2019

feedPlanet Debian

Debian GSoC Kotlin project blog: Finished converting all the buildfiles to groovy and downgraded to Gradle 4.4.1; week 3+ update

Converting build files to groovy

During the third week I mainly spent my time converting all the build files in the "dist" task graph to groovy from kotlin-dsl.

I finished converting all the build files from kotlin-dsl to groovy. I then proceeded to build the entire project with only the subprojects required for the dist task so that we can avoid converting all the unneeded subproject build files to groovy. Ran tests on the binary obtained from the newly converted project and compared it to the test result on an original unconverted project. Since the new project only contains the needed subprojects this new project is unable to run all the needed tests. So in order to overcome this we copy the binaries built by our new project and run the tests using the original unaltered projects. The compiler test task we need is "compilerTest"; this is the only applicable test for out build binary from the "dist" task. I have run "distTest" for the unaltered project and uploaded it here; "distTest" task encompasses compilerTest task within it. Here is the log of the "compilerTest" run on the generated binaries.

Downgrading the Project to Gradle 4.4.1

I also have downgraded the project to Gradle 4.4.1 decrementaly from 5.1 to 4.7 to 4.4.1. Since Gradle 4.4.1 isn't defaulty compatible with openjdk-11 (default Java version in Debian Sid) I used an external JDK-9 to build the project with an external Gradle 4.4.1 and confirmed it has indeed been downgraded. Next step would be beginning to make this project buildable with Debian Sid Gradle.

Closing notes and things to note

I figure that to those unfamiliar with Debian packaging it would be useful to know that we are going to upload a non-free prebuilt pacakge containing only the necessary binaries for bootstrapping. Then using this we can build this project in a more Debian way. Also I am posting the environment varaibles followed by build command to build this project as of this blog.

export JAVA_HOME="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_16="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_17="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_18="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_9="/home/Java/jdk-9.0.4_linux-x64_bin/jdk-9.0.4"
./gradlew -Pteamcity=true dist

Here is a link to the work I have done so far. You can find me as m36 or m36[m] on #debian-mobile and #debian-java in OFTC.

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

19 Jun 2019 5:49pm GMT

Neil McGovern: GNOME ED Update – April/May

It's time for another update on what the GNOME Foundation has been up to, this time in April and May.


We've been to a number of events in the last couple of months. April saw myself, Kristi, Bastian, Anisa and Stefano at FOSS-North in Sweden. Zeeshan Ali presented a talk on Open Source Geolocation.

At the end of April, Molly de Blanc and Sri Ramkrishna were at Linux Fest North West. Additionally, Molly delivered a talk related to community guideline enforcement, which was featured on the LFNW web page.

We also had a couple of hackfests in may - Rust+GNOME Hackfest #5 in Berlin at the start of the month, and the GStreamer Spring Hackfest 2019 in Oslo at the end of May.

Coming up in July, we'll be attending OSCON and having a West Coast Hackfest - a combined 3-in-1 hackfest bringing in GTK, Documentation and Engagement teams!


GUADEC and GNOME.Asia planning is now very much underway, and they've now both announced their venues and dates - GUADEC will be in Thessaloniki, Greece at the end of August, and GNOME.Asia will be in Gresik, Indonesia mid October! As always, we're after sponsors for both of these, so if you know of any organisations who can help, please pass along our sponsorship brochure.


For those that didn't see my announcement, Molly de Blanc joined the Foundation as our Strategic Initiatives Manager! Molly comes from the Free Software Foundation where she was the Campaigns Manager, working on community organising around digital rights issues.
She's also the President of the Board of Directors of the Open Source Initiative, and on the Debian Outreach and Anti-harassment teams. Regularly speaking at conferences around the world, she has represented multiple projects in community and corporate contexts.


We've also been trying something new - we moved the gtk lists away from Mailman and over to discourse.gnome.org. The uptake has been rather impressive - we're now seeing more topics on Discourse then all gtk-* lists grouped together, and more and more people engaged. We also moved over builder, and are looking at other lists, with a possible goal of eventually retiring mailman all together for general purpose discussions. If you're interested, let me know!

Google Summer of Code

The Google Summer of Code internships are now underway, and we have a total of 10 students working for GNOME:

This is a fantastic set of projects, and I'm sure all students will be welcomed warmly!

19 Jun 2019 10:04am GMT

Petter Reinholdtsen: Jami/Ring, finally functioning peer to peer communication client

Some years ago, in 2016, I wrote for the first time about the Ring peer to peer messaging system. It would provide messaging without any central server coordinating the system and without requiring all users to register a phone number or own a mobile phone. Back then, I could not get it to work, and put it aside until it had seen more development. A few days ago I decided to give it another try, and am happy to report that this time I am able to not only send and receive messages, but also place audio and video calls. But only if UDP is not blocked into your network.

The Ring system changed name earlier this year to Jami. I tried doing web search for 'ring' when I discovered it for the first time, and can only applaud this change as it is impossible to find something called Ring among the noise of other uses of that word. Now you can search for 'jami' and this client and the Jami system is the first hit at least on duckduckgo.

Jami will by default encrypt messages as well as audio and video calls, and try to send them directly between the communicating parties if possible. If this proves impossible (for example if both ends are behind NAT), it will use a central SIP TURN server maintained by the Jami project. Jami can also be a normal SIP client. If the SIP server is unencrypted, the audio and video calls will also be unencrypted. This is as far as I know the only case where Jami will do anything without encryption.

Jami is available for several platforms: Linux, Windows, MacOSX, Android, iOS, and Android TV. It is included in Debian already. Jami also work for those using F-Droid without any Google connections, while Signal do not. The protocol is described in the Ring project wiki. The system uses a distributed hash table (DHT) system (similar to BitTorrent) running over UDP. On one of the networks I use, I discovered Jami failed to work. I tracked this down to the fact that incoming UDP packages going to ports 1-49999 were blocked, and the DHT would pick a random port and end up in the low range most of the time. After talking to the developers, I solved this by enabling the dhtproxy in the settings, thus using TCP to talk to a central DHT proxy instead of peering directly with others. I've been told the developers are working on allowing DHT to use TCP to avoid this problem. I also ran into a problem when trying to talk to the version of Ring included in Debian Stable (Stretch). Apparently the protocol changed between beta2 and the current version, making these clients incompatible. Hopefully the protocol will not be made incompatible in the future.

It is worth noting that while looking at Jami and its features, I came across another communication platform I have not tested yet. The Tox protocol and family of Tox clients. It might become the topic of a future blog post.

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

19 Jun 2019 6:45am GMT