sunweaver's NET

I never fancied having accounts with the big players that much, so I never touched e.g. Twitter.

But Mastodon is the kind of service that works for me. You can find me on https://fosstodon.org.

My nick over there is sunweaver. I'll be posting intersting stuff of my work there, probably more regularly than on the blog.

After some nice family vacation in Scandinavia, I did six hours of work on the Debian LTS project as a paid contributor at the end of this month. Thanks to all LTS sponsors for making this possible.

This is my list of work done in August 2018:

• Research phpldapadmin (CVE-2018-12689) [1], overhead from July 2018, upload is still to come (planned for the coming week)
• Upload of 389-ds-base (DLA 1483-1)
• Upload of spice (DLA 1486-1).
  The patch that has been proposed by upstream to fix CVE-2018-10873 has been controversially discussed [2].
  Please refer to my review comment in the package's patch file for my reasoning [3] behind accepting upstream's patch for the fix of this package in Debian LTS.
• Upload of spice-gtk (DLA 1489-1).
• Fix a corner case flaw in the gen-DLA (and gen-DSA) script [4].

light+love
Mike

References

[1] https://lists.debian.org/debian-lts/2018/07/msg00123.html

[2] http://www.openwall.com/lists/oss-security/2018/08/17/4 (follow thread)

This month, after a longer pause, I have started working again for the Debian LTS project as a paid contributor. Thanks to all LTS sponsors for making this possible.

This is my list of work done in July 2018:

• Triage CVE issues of ~27 packages during my front desk week.
• Upload gosa 2.7.4+reloaded2-13+deb9u1 (DLA-1436-1) to jessie-security.
• Upload network-manager-vpnc 0.9.10.0-1+deb8u1 (DLA-1454-1) to jessie-security.
• At the end of the month, I started looking at one of two open issues in phpldapadmin. More details on this, I have sent to the Debian LTS mailing list [1].

light+love
Mike

[1] https://lists.debian.org/debian-lts/2018/07/msg00123.html

There are as many ways of doing the Let's Encrypt thing as there are site admins on this planet. So here is my way of doing it, mainly as a documentation for myself and as a tutorial for a supervision class I'll be teaching tomorrow morning.

TL;DR;

This blog post describes how to obtain certificates from Let's Encrypt on a production web server in a non-privileged user context. We use the small and well-readable acme-tiny [1] Python script for it.

Assumptions

• You know how e.g. Apache2 gets configured (in general)
• and you have a host running Apache2 that is reachable on the internet
• and it least has one DNS hostname associated with its public IP address.
• You have an idea about OpenSSL, requesting a signed certificate
• You know what privileges on a *nix system are and why it is bad mostly to run self-updating scripts under a privileged user account (e.g. root)...

This is to make people aware and inform about an ongoing effort to replace Indicators in Debian (most people know the concept from Ubuntu) by a more generically developed and actively maintained fork: Ayatana Indicators.

TL;DR;

In Debian, we will soon start sending out patches to SNI supporting applications via Debian's BTS (and upstream trackers, too, probably), that make the shift from Ubuntu AppIndicator (badly maintained in Debian) to Ayatana AppIndicator.

Status of the work being done is documented here: https://wiki.debian.org/Ayatana/IndicatorsTransition

Why Ayatana Indicators

The fork is currently pushed forward by the Debian and Ubuntu MATE packaging team.

The Indicators concept has originally been documented by Canonical, find your entry point in the readings here [1,2].

Some great work and achievement was done around Ubuntu Indicators by Canonical Ltd. and the Indicators concept has always been a special identifying feature of Ubuntu. Now with the switch to GNOMEv3, the future of Indicators in Ubuntu is uncertain. This is where Ayatana Indicators come in...

The main problem with Ubuntu Indicators today (and ever since) is (has been): they only work properly on Ubuntu, mostly because of one Ubuntu-specific patch against GTK-3 [3].

In Ayatana Indicators (speaking with my upstream hat on now), we are currently working on a re-implementation of the rendering part of the indicators (using GTK's popovers rather then menushells), so that it works on vanilla GTK-3.

More a reminder for myself, than a blog post...

If you want to backport a project from unstable based on the meson build system and your package uses debhelper to invoke the meson build process, then you need to modify the backported package's debian/control file slightly:

diff --git a/debian/control b/debian/control
index 43e24a2..d33e76b 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Build-Depends: debhelper (>= 11~),
                libmate-menu-dev (>= 1.16.0),
                libmate-panel-applet-dev (>= 1.16.0),
                libnotify-dev,
-               meson,
+               meson (>= 0.40.0),
                ninja-build,
                pkg-config,
 Standards-Version: 4.1.3

Enforce the build to pull-in meson from stretch-backports, i.e. a meson version that is newer than 0.40.0.

Reasoning: if you want to build your package against debhelper (>= 11~) from stretch-backports it will use the --wrap-mode option when invoking meson. However, this option only got added in meson 0.40.0. So you need to make sure, the meson version from stretch-backports gets pulled in, too, for your build. The build will fail when using the meson version that we find in Debian stretch.

This is a quick call for help to all non-English native speakers.

Please visit projects hosted by the Arctica Project and the Ayatana Indicators project on Weblate and help localizing our projects into your native language.

Projects waiting for Your Language Expertise

The projects on Weblate are:

Arctica Project:
https://hosted.weblate.org/projects/arctica-framework/

Ayatana Indicators:
https://hosted.weblate.org/projects/ayatana-indicators/

If interested in helping with localizations for these project, please add your language for these projects to your Hosted Weblate Dashboard and stay informed when changes occur, components get added, etc.

Credits

Thanks to all those who already have contributed with translation, so far. However, more work is needed. Let's come together!!!

light+love
Mike Gabriel

This is to announce that finally all MATE Desktop 1.18 components have landed in Debian testing (aka buster).

Credits

Again a big thanks to the packaging team (esp. Vangelis Mouhtsis and Martin Wimpress, but also to Jeremy Bicha for constant advice and Aron Xu for joining the Debian+Ubuntu MATE Packaging Team and merging all the Ubuntu zesty and artful branches back to master).

Fully Available on all Debian-supported Architectures

The very special thing about this MATE 1.18 release for Debian is that MATE is now available on all Debian hardware architectures. See "Buildd" column on our DDPO overview page [1]. Thanks to all the people from the Debian porters realm for providing feedback to my porting questions.

References

• [1] https://qa.debian.org/developer.php?login=pkg-mate-team@lists.alioth.deb...

On Tuesday, late afternoon, at DebConf17, I offered an ad-hoc BoF about the current status of the MATE Desktop packaging efforts in Debian and Ubuntu. I need to get this written down, before DebConf17 feels too far away...

Unfortunately, I scheduled that BoF with Joey Hess's talk about his post-Debian life, which attracted many people. So, only a small group of people came together to share and discuss about the current status of MATE in Debian and Ubuntu.

Ongoing efforts around MATE in Debian and Ubuntu

A quick summary of ongoing efforts was provided and also a collection of URLs for reporting bugs, looking up packaging status, etc. was listed:

• Upstream: https://github.com/mate-desktop
• Debian Packaging: https://qa.debian.org/developer.php?login=pkg-mate-team@lists.alioth.deb...
• Ubuntu MATE: http://ubuntu-mate.org/
• Git Packaging Repositories: https://anonscm.debian.org/cgit/pkg-mate/
• IRC (upstream): #mate-dev on Freenode (irc.freenode.net) # IRC (Debian + Ubuntu): #debian-mate on OFTC (irc.debian.org)

Cross-Distro Packaging Workflow

The workflow of Debian and Ubuntu packaging in the MATE Packaging Team was described in detail (basically, all packages go through Debian, only exception being freeze states of this or that distro) and the benefit of the close cooperation between the two projects underlined. We reduce the packaging effort tremendously by working very closely together.

On Thursday at DebConf17, all people interested in using this or that Remote Desktop solution on Debian (as a server, as a client, as both) came together for a BoF.

Sharing about Usage Scenarios

Quite some time we informally shared with one another what technologies and software we use for remote access to Debian machines and what the experiences are.

The situation in Debian and on GNU/Linux in general is that many technical approaches exist, all of them have certain features and certain limitations. The composition of features and limitations finally lead the users to choosing one or another technology as his or her favourite solution.

The Debian Remote Maintainers Team

On the developers' side, Dominik George and I set up a packaging team for Remote Desktop related software in Debian. A packaging team that we invite everyone who is maintaining such software in the widest sense to join: https://qa.debian.org/developer.php?login=pkg-remote-team%40lists.alioth...

'DebianRemote' namespace on the Debian Wiki

For users of Debian, the group agreed, we need an overview page (on wiki.debian.org) that provides an entry point for Debian on the Remote Desktop. An entry point that provides user information as well as developer information.

A skeleton of this wiki page, I have just set up (thanks to Vagrant for taking some notes in Gobby during the BoF): https://wiki.debian.org/DebianRemote

However, the page still contains loads of FIXMEs, so the actual work only now really starts.