Planet Debian

Syndicate content
Planet Debian - http://planet.debian.org/
Updated: 1 day 2 hours ago

Sean Whitton: Debian Policy call for participation -- August 2017

Sat, 2017-08-19 17:44

At the Debian Policy BoF at DebConf17, Solveig suggested that we could post summaries of recent activity in policy bugs to Planet Debian, as a kind of call for participation. Russ Allbery had written a script to generate such a summary some time ago, but it couldn’t handle the usertags the policy team uses to progress bugs through the policy changes process. Today I enhanced the script to handle usertags and I’m pleased to be able to post a summary of our bugs.

Consensus has been reached and help is needed to write a patch

#172436 BROWSER and sensible-browser standardization

#273093 document interactions of multiple clashing package diversions

#299007 Transitioning perms of /usr/local

#314808 Web applications should use /usr/share/package, not /usr/share/doc/…

#425523 Describe error unwind when unpacking a package fails

#452393 Clarify difference between required and important priorities

#476810 Please clarify 12.5, “Copyright information”

#484673 file permissions for files potentially including credential informa…

#491318 init scripts “should” support start/stop/restart/force-reload - why…

#556015 Clarify requirements for linked doc directories

#568313 Suggestion: forbid the use of dpkg-statoverride when uid and gid ar…

#578597 Recommend usage of dpkg-buildflags to initialize CFLAGS and al.

#582109 document triggers where appropriate

#587279 Clarify restrictions on main to non-free dependencies

#587991 perl-policy: /etc/perl missing from Module Path

#592610 Clarify when Conflicts + Replaces et al are appropriate

#613046 please update example in 4.9.1 (debian/rules and DEB_BUILD_OPTIONS)

#614807 Please document autobuilder-imposed build-dependency alternative re…

#616462 clarify wording of parenthetical in section 2.2.1

#628515 recommending verbose build logs

#661928 recipe for determining shlib package name

#664257 document Architecture name definitions

#682347 mark ‘editor’ virtual package name as obsolete

#683222 say explicitly that debian/changelog is required in source packages

#685506 copyright-format: new Files-Excluded field

#685746 debian-policy Consider clarifying the use of recommends

#688251 Built-Using description too aggressive

#757760 please document build profiles

#759316 Document the use of /etc/default for cron jobs

#761219 document versioned Provides

#767839 Linking documentation of arch:any package to arch:all

#770440 policy should mention systemd timers

#773557 Avoid unsafe RPATH/RUNPATH

#780725 PATH used for building is not specified

#793499 The Installed-Size algorithm is out-of-date

#810381 Update wording of 5.6.26 VCS-* fields to recommend encryption

#823256 Update maintscript arguments with dpkg >= 1.18.5

#833401 virtual packages: dbus-session-bus, dbus-default-session-bus

#835451 Building as root should be discouraged

#838777 Policy 11.8.4 for x-window-manager needs update for freedesktop menus

#845715 Please document that packages are not allowed to write outside thei…

#853779 Clarify requirements about update-rc.d and invoke-rc.d usage in mai…

Wording proposed, awaiting review from anyone and/or seconds by DDs

#542288 Versions for native packages, NMU’s, and binary only uploads

#582109 document triggers where appropriate

#630174 forbid installation into /lib64

#645696 [copyright-format] clearer definitions and more consistent License:…

#648271 11.8.3 “Packages providing a terminal emulator” says xterm passes -…

#649530 [copyright-format] clearer definitions and more consistent License:…

#662998 stripping static libraries

#732445 debian-policy should encourage verification of upstream cryptograph…

#737796 copyright-format: support Files: paragraph with both abbreviated na…

#756835 Extension of the syntax of the Packages-List field.

#786470 [copyright-format] Add an optional “License-Grant” field

#835451 Building as root should be discouraged

#844431 Packages should be reproducible

#845255 Include best practices for packaging database applications

#850729 Documenting special version number suffixes

Merged for the next release

#587279 Clarify restrictions on main to non-free dependencies

#616462 clarify wording of parenthetical in section 2.2.1

#732445 debian-policy should encourage verification of upstream cryptograph…

#844431 Packages should be reproducible

Categories: FLOSS Project Planets

Holger Levsen: 20170819-lasercutter-sprint

Sat, 2017-08-19 12:14
laser-cutter sprint

So I'm overcoming my jetlag after DebConf17 by helping to make the Alioth sprint happen, and while it's good to witness work on the upcoming git.debian.org replacement, I'm rather minding my own business instead of getting involved…

And so I got interested in this laser cutter, which since two months has been set up in the CCCHH hackerspace and which is nicely documentend (and set up), so I managed to learn how to do my first baby steps with the laser cutter in one evening:

Basically there is a hosted web application named 'LaserWeb4' for which a pre-configuration exists, so that one only needs to load an image, scale and position it and tune the laser settings a bit. The laser itself is inside a cage, which has a physical safety switch which will turn off the laser if the cage is opened. Obviously the setup is a lot more complex and there are many parameters to tune, and I basically just learned one thing, which is "printing images on wood", but "printing images on a laptop cover" should be pretty similar and something to learn in the future

And now I'm even teaching weasel how to use this thing (and he already made interesting new mistakes) and it looks like Ganneff & formorer are next. Fun fun fun!

Oh, and the Alioth sprint also seems to be quite productive, but I'll leave reporting about this to others.

Categories: FLOSS Project Planets

Vasudev Kamath: Writing a UDP Broadcast Receiver as Python Iterator

Sat, 2017-08-19 09:28

I had to write a small Python application to listen for some broadcast message and process the message. This broadcast messages are actually sort of discovery messages to find some peers in a network. Writing a simple UDP Server to listen on a particular port was easy; but while designing an application I was wondering how can I plugin this server into my main code. There are 2 possibility

  1. Use threading module of python to send the server code in back ground and give it a callback to communicate the data to main thread.
  2. Periodically read some messages from server code and then dispose of server.

I didn't like first approach because I need to pass a callback function and I some how will end up complicating code. Second approach sounded sane but I did want to make server more like iterator. I searched around to see if some one has attempted to write something similar, but did not find anything useful (may be my Googling skills aren't good enough). Anyway so I thought what is wrong in trying?. If it works then I'll be happy that I did something different :-).

The first thing for making iterator in Python is having function __iter__ and __next__ defined in your class. For Python 2 iterator protocol wanted next to be defined instead of __next__. So for portable code you can define a next function which in return calls __next__.

So here is my first shot at writing BroadCastReceiver class.

from socket import socket, AF_INET, SOCK_DGRAM class BroadCastReceiver: def __init__(self, port, msg_len=8192): self.sock = socket(AF_INET, SOCK_DGRAM) self.sock.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1) self.sock.bind(('', port)) self.msg_len = msg_len def __iter__(self): return self def __next__(self): try: addr, data = self.sock.recvfrom(self.msg_len) return addr, data except Exception as e: print("Got exception trying to recv %s" % e) raise StopIteration

This version of code can be used in a for loop to read from socket UDP broadcasts. One problem will be that if no packet is received which might be due to disconnected network the loop will just block forever. So I had to modify the code slightly to add timeout parameter. So changed portion of code is below.

... def __init__(self, port, msg_len=8192, timeout=15): self.sock = socket(AF_INET, SOCK_DGRAM) self.sock.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1) self.sock.settimeout(timeout) self.sock.msg_len = msg_len self.sock.bind(('', port)) ...

So now if network is disconnected or no packet was received for timeout period we get a socket.timeout exception due to which StopIteration will be raised causing the for loop using server as iterator to exit. This avoids us just blocking our periodic code run forever when network is disconnected or no messages are received for long time. (may be due to connected to wrong network).

Now every thing looks fine but only part is if we create the server object each time our periodic code is called we will have binding issue as we did not properly close the socket once iterator has stopped. So I added socket closing code in __del__ function for the class. __del__ will be called when garbage collector try to recollect object when it goes out of scope.

... def __del__(self): self.sock.close()

So the server can be used in for loop or by passing the object of server to next built-in function. Here are 2 examples.

r = BroadCastReceiver(5000, timeout=10) count = 0 for (address, data) in r: print('Got packet from %s: %s' % address, data) count += 1 # do whatever you want with data if count > 10: break

Here we use an counter variable to track iteration and after some iteration we exit for loop. Another way is use for loop with range of iteration like below.

r = BroadCastReceiver(5000, timeout=10) for i in range(20): try: address, data = next(r) # do whatever you want with data except: break

Here an additional try block was needed inside the for loop to card call to next, this is to handle the timeout or other exception and exit the loop. In first case this is not needed as StopIteration is understood by for.

Both use cases I described above are mostly useful when it is not critical to handle each and every packet (mostly peer discovery) and packets will always be sent. So if we miss some peers in one iteration we will still catch them in next iteration. We just need to make sure we provide big enough counter to catch most peers in each iteration.

If its critical to receive each packet we can safely send this iterating logic to a separate thread which keeps receiving packets and process data as needed.

For now I tried this pattern mostly with UDP protocol but I'm sure with some modification this can be used with TCP as well. I'll be happy to get feed back from Pythonistas out there on what you think of this approach. :-)

Update

I got a suggestion from Ryan Nowakowski to make the server object as context manager and close the socket in __exit__ as it can't be guaranteed that __del__ will be called for objects which exists during interpreter exits. So I slightly modified the class to add __enter__ and __exit__ method like below and removed __del__

... def __enter__(self): return self def __exit__(self, exc_type, exc_value, traceback): self.sock.close()

Usage pattern is slightly modified because of this and we need to use with statement while creating object.

with BroadCastReceiver(2000) as r: # use server object as you wish ...

It is also possible to cleanly close socket without adding context manager that is adding finally statement to our try and except block in __next__. The modified code without adding context manager looks like below.

def __next__(self): try: addr, data = self.sock.recvfrom(self.msg_len) return addr, data except Exception as e: print("Got exception trying to recv %s" % e) raise StopIteration finally: self.sock.close()

When we raise StopIteration again from except block, it will be temporarily saved and finally block is executed which will now close the socket.

Categories: FLOSS Project Planets

Arturo Borrero González: Running Suricata 4.0 with Debian Stretch

Sat, 2017-08-19 06:56

Do you know what’s happening in the wires of your network? There is a major FLOSS player in the field of real time intrusion detection (IDS), inline intrusion prevention (IPS) and network security monitoring (NSM). I’m talking about Suricata, a mature, fast and robust network threat detection engine. Suricata is a community driven project, supported by the Open InfoSec Foundation (OISF).

For those who doesn’t know how Suricata works, it usually runs by loading a set of pre-defined rules for matching different network protocols and flow behaviours. In this regards, Suricata has been always ruleset-compatible with the other famous IDS: snort.

The last major release of Suricata is 4.0.0, and I’m uploading the package for Debian stretch-backports as I write this line. This means the updated package should be available for general usage after the usual buildds processing ends inside the Debian archive.

You might be wondering, How to start using Suricata 4.0 with Debian Stretch? First, I would recommend reading the docs. Please checkout:

My recommendation is to run Suricata from stretch-backports or from testing, and just installing the package should be enough to get the environment up and running:

% sudo aptitude install suricata

You can check that the installation was good:

% sudo systemctl status suricata ● suricata.service - Suricata IDS/IDP daemon Loaded: loaded (/lib/systemd/system/suricata.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2017-08-19 12:50:49 CEST; 44min ago Docs: man:suricata(8) man:suricatasc(8) https://redmine.openinfosecfoundation.org/projects/suricata/wiki Main PID: 1101 (Suricata-Main) Tasks: 8 (limit: 4915) CGroup: /system.slice/suricata.service └─1101 /usr/bin/suricata -D --af-packet -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid ago 19 12:50:44 nostromo systemd[1]: Starting Suricata IDS/IDP daemon... ago 19 12:50:47 nostromo suricata[1032]: 19/8/2017 -- 12:50:47 - <Notice> - This is Suricata version 4.0.0 RELEASE ago 19 12:50:49 nostromo systemd[1]: Started Suricata IDS/IDP daemon.

You can interact with Suricata using the suricatasc tool:

% sudo suricatasc -c uptime {"message": 3892, "return": "OK"}

And start inspecting the generated logs at /var/log/suricata/

The default configuration, in file /etc/suricata/suricata.yaml, comes with some preconfigured values. For a proper integration into your enviroment, you should tune the configuration file, define your networks, network interfaces, running modes, and so on (refer to the upstream documentation for this).

In my case, I tested suricata by inspecting the traffic of my laptop. After installation, I only had to switch the network interface:

[...] # Linux high speed capture support af-packet: - interface: wlan0 [...]

After a restart, I started seeing some alerts:

% sudo systemctl restart suricata % sudo tail -f /var/log/suricata/fast.log 08/19/2017-14:03:04.025898 [**] [1:2012648:3] ET POLICY Dropbox Client Broadcasting [**] \ [Classification: Potential Corporate Privacy Violation] [Priority: 1] {UDP} 192.168.1.36:17500 -> 255.255.255.255:17500

One of the main things when running Suricata is to keep your ruleset up-to-dated. In Debian, we have the suricata-oinkmaster package which comes with some handy options to automate your ruleset updates using the Oinkmaster software. Please note that this is a Debian-specific glue to integrate and automate Suricata with Oinkmaster.

To get this funcionality, simply install the package:

% sudo aptitude install suricata-oinkmaster

A daily cron-job will be enabled. Check suricata-oinkmaster-updater(8) for more info.

By the way, Did you know that Suricata can easily handle big loads of traffic? (i.e, 10Gbps). And I heard some scaling works are in mind to reach 100Gpbs.

I have been in charge of the Suricata package in Debian for a while, several years already, with the help of some other DD hackers: Pierre Chifflier (pollux) and Sascha Steinbiss (satta), among others. Due to this work, I believe the package is really well integrated into Debian, ready to use and with some powerful features. And, of course, we are open to suggestions and bug reports.

So, this is it, another great stuff you can do with Debian :-)

Categories: FLOSS Project Planets

Sean Whitton: The knowledge that one has an unread message is equivalent to a 10 point drop in one's IQ

Fri, 2017-08-18 13:37

According to Daniel Pocock’s talk at DebConf17’s Open Day, hearing a ping from your messaging or e-mail app or seeing a visual notification of a new unread message has an equivalent effect on your ability to concentrate as

  • a 10 point drop in your IQ; or

  • drinking a glass of wine.

This effect is probably at least somewhat mitigated by reading the message, but that is a context switch, and we all know what those do to your concentration. So if you want to get anything done, be sure to turn off notifications.

Categories: FLOSS Project Planets

Rapha&#235;l Hertzog: Freexian’s report about Debian Long Term Support, July 2017

Fri, 2017-08-18 10:16

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

Individual reports

In July, about 181 work hours have been dispatched among 11 paid contributors. Their reports are available:

  • Antoine Beaupré did 20h (out of 16h allocated + 4 extra hours).
  • Ben Hutchings did 14 hours (out of 15h allocated, thus keeping 1 extra hour for August).
  • Chris Lamb did 18 hours.
  • Emilio Pozuelo Monfort did 18.5 hours (out of 23.5 hours allocated + 8 hours remaining, thus keeping 13 hours for August).
  • Guido Günther did 10 hours.
  • Hugo Lefeuvre did nothing due to personal problems (out of 2h allocated + 10 extra hours, thus keeping 12 extra hours for August).
  • Markus Koschany did 23.5 hours.
  • Ola Lundqvist did not publish his report yet (out of 14h allocated + 2 extra hours).
  • Raphaël Hertzog did 7 hours (out of 12 hours allocated but he gave back his remaining hours).
  • Roberto C. Sanchez did 19.5 hours (out of 23.5 hours allocated + 12 hours remaining, thus keeping 16 extra hours for August).
  • Thorsten Alteholz did 23.5 hours.
Evolution of the situation

The number of sponsored hours increased slightly with two new sponsors: Leibniz Rechenzentrum (silver sponsor) and Catalyst IT Ltd (bronze sponsor).

The security tracker currently lists 74 packages with a known CVE and the dla-needed.txt file 64. The number of packages with open issues increased of almost 50% compared to last month. Hopefully this backlog will get cleared up when the unused hours will actually be done. In any case, this evolution is worth watching.

Thanks to our sponsors

New sponsors are in bold.

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

Categories: FLOSS Project Planets

Mike Gabriel: @DebConf17: Ad-hoc BoF: Bits from the Debian+Ubuntu MATE Packaging Team

Fri, 2017-08-18 05:33

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:

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. In the past, we (Martin Wimpress and myself) also invited the people from Linux Mint to join our cross-distro packaging efforts, but so far to no avail. Also the packaging for the Parrot Security OS has recently been integrated in our packaging Git repository.

Requested / Upcoming Improvements

From people attending the BoF, I got these main inputs, which I hope to accomplish with the help of all, for Debian buster:

  • Improve the MATE User Guide, I am quite optimistic that we get help from the person that asked for a better help tool on the MATE Desktop (like it was back in the times of old GNOMEv2)
  • Provide several desktop layouts in Debian, like available in Ubuntu MATE, that can be chosen / configured by the MATE Tweak Tool
  • Port the Ubuntu MATE Welcome application to Debian and autostart it on first login, like people know it from Ubuntu MATE

Another project that I will also work on for Debian buster is proper Ayatana Indicator support for Debian's MATE Desktop.

Credits

Thanks to all the people attending the BoF for your sharings and input. Feel invited to contribute to our team's effort in improving the user experience of the MATE Destkop Environment in Debian (and Ubuntu, and ...). Also a big thanks to the people already on the team for bringing MATE in Debian to where it is now. Good work, folks!

Categories: FLOSS Project Planets

Dirk Eddelbuettel: RcppArmadillo 0.7.960.1.0

Thu, 2017-08-17 20:41

The bi-monthly RcppArmadillo release is out with a new version 0.7.960.1.0 which is now on CRAN, and will get to Debian in due course.

And it is a big one. Lots of nice upstream changes from Armadillo, and lots of work on our end as the Google Summer of Code project by Binxiang Ni, plus a few smaller enhancements -- see below for details.

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) 379 other packages on CRAN---an increase of 49 since the last CRAN release in June!

Changes in this release relative to the previous CRAN release are as follows:

Changes in RcppArmadillo version 0.7.960.1.0 (2017-08-11)
  • Upgraded to Armadillo release 7.960.1 (Northern Banana Republic Deluxe)

    • faster randn() when using OpenMP (NB: usually omitted when used fromR)

    • faster gmm_diag class, for Gaussian mixture models with diagonal covariance matrices

    • added .sum_log_p() to the gmm_diag class

    • added gmm_full class, for Gaussian mixture models with full covariance matrices

    • expanded .each_slice() to optionally use OpenMP for multi-threaded execution

  • Upgraded to Armadillo release 7.950.0 (Northern Banana Republic)

    • expanded accu() and sum() to use OpenMP for processing expressions with computationally expensive element-wise functions

    • expanded trimatu() and trimatl() to allow specification of the diagonal which delineates the boundary of the triangular part

  • Enhanced support for sparse matrices (Binxiang Ni as part of Google Summer of Code 2017)

    • Add support for dtCMatrix and dsCMatrix (#135)

    • Add conversion and unit tests for dgT, dtT and dsTMatrix (#136)

    • Add conversion and unit tests for dgR, dtR and dsRMatrix (#139)

    • Add conversion and unit tests for pMatrix and ddiMatrix (#140)

    • Rewrite conversion for dgT, dtT and dsTMatrix, and add file-based tests (#142)

    • Add conversion and unit tests for indMatrix (#144)

    • Rewrite conversion for ddiMatrix (#145)

    • Add a warning message for matrices that cannot be converted (#147)

    • Add new vignette for sparse matrix support (#152; Dirk in #153)

    • Add support for sparse matrix conversion from Python SciPy (#158 addressing #141)

  • Optional return of row or column vectors in collapsed form if appropriate #define is set (Serguei Sokol in #151 and #154)

  • Correct speye() for non-symmetric cases (Qiang Kou in #150 closing #149).

  • Ensure tests using Scientific Python and reticulate are properly conditioned on the packages being present.

  • Added .aspell/ directory with small local directory now supported by R-devel.

Courtesy of CRANberries, there is a diffstat report. 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.

Categories: FLOSS Project Planets

Sean Whitton: DebCamp/DebConf17: reports on sprints and BoFs

Thu, 2017-08-17 18:21

In addition to my personal reflections on DebCamp/DebConf17, here is a brief summary of the activities that I had a hand in co-ordinating.

I won’t discuss here many other small items of work and valuable conversations that I had during the two weeks; hopefully the fruits of these will show themselves in my uploads to the archive over the next year.

Debian Policy sprint & BoF
  • released version 4.0.1.0 of the Policy Manual

  • figured out documenting reproducibility in policy. Formulating the wording turned out to be easier than I had expected

  • approx. ten years after they were first published, incorporated marga’s maintscript flowcharts into policy proper

  • converted policy from docbook to rST built with the Sphinx toolchain. Many, many thanks to Hideki Yamane and David Bremner for helping Russ and I get this merged to our master branch

  • triage of every single bug against policy, and mass closure of inactive bugs, bringing the total down from more than 200 to around 125

  • conversations with Technical Committee members about how the two teams can help each other’s work (mainly us helping them to help us!)

  • conversations about how we handle disagreement and plans to streamline our overly complex BTS usertags (watch this space)

  • very useful input from policy consumers about how the upgrading checklist is formatted, and how we can recruit more people to get patches written

Debian Emacs Team meeting/sprint
  • plans to finally drop our emacsXY binary packages, and just have a single version of Emacs in the archive, so that we no longer have to deal with bugs due to someone still having emacs21 installed (David’s idea; Rob’s implementation; Sean’s mostly-helpful comments)

  • other plans to simplify and otherwise improve the Debian Emacsen policy

  • finally finished off the work needed to RM emacs24—nine months later—including a lot of NMUs

  • mentoring a junior team member

Unfortunately we didn’t make any significant progress towards converting all addons to use dh_elpa, as the work is not that much fun. Might be worth a more focused sprint next year.

Report on team website

Git for Debian packaging BoF & follow-up conversations

The BoF was far more about dgit than I had wanted; however, I think that this was mostly because people had questions about dgit, rather than any unintended lecturing by me.

I believe that several people came away from DebConf thinking that starting to use dgit would improve Debian for themselves and for users of their packages.

Categories: FLOSS Project Planets

Sean Whitton: I went all the way to Montréal for DebConf17, and all I got was a new MUA

Thu, 2017-08-17 17:50
This year’s group photo (by Aigars Mahinovs). I really like the tagline

On Sunday night I got back from Montréal, where I attended both DebCamp17 and DebConf17. It was a wonderful two weeks. All I really did was work on Debian for roughly eight hours per day, interspersed with getting to know both people I’ve been working with since I first began contributing to Debian in late 2015, and people I didn’t yet know. But this was all I really needed to be doing. There was no need to engage in distracting myself.

I enjoyed the first week more. There were sufficiently few people present that you could know at least all of their faces, and interesting-sounding talks didn’t interrupt making progress on one’s own work or unblocking other people’s work. In the second week it was great to meet people who were only present for the second week, but it felt more like regular Debian, in that I was often waiting on other people or they were waiting on me.

While I spent one morning actually writing fresh code, and I did a fair amount of pure packaging work, the majority of my time was poured into (i) Debian Policy; (ii) discussions within the Emacs team; and (iii) discussions about dgit. This was as I expected. During DebConf, it’s not that useful to seclude oneself and sufficiently reacquaint oneself with a codebase that one can start producing patches, because that can be done anywhere in the world, without everyone else around. It’s far more useful to bring different people together to get projects unblocked. I did some of that for my own work, and also tried to help other people’s, including those who weren’t able to attend the conference.

In my ordinary life, taking a step back from the methods by which I protect my PGP keys and other personal data, I can appear to myself as a paranoid extremist, or some kind of data hoarder. It was comforting to find at DebConf plenty of people who go way further than me: multiple user accounts on their laptop, with separate X servers, for tasks of different security levels; PGP keys on smartcards; refusal to sign my PGP key based on government-issued ID alone; use of Qubes OS. One thing that did surprise me was to find myself in a minority for using the GNOME desktop; I had previously assumed that most people deep in Debian development didn’t bother with tiling window managers. Turns out they are enthusiastic to talk about the trade-offs between window managers while riding the subway train back to our accommodation at midnight—who knew such people existed? I was pleased to find them. One evening, I received a tag-teamed live tutorial in using i3’s core keybindings, and the next morning GNOME seemed deeply inelegant. The insinuation began, but I was immediately embroiled in inner struggle over the fact that i3 is a very popular tiling window manager, so it wouldn’t be very cool if I were to start using it. This difficulty was compounded when I learned that the Haskell team lead still uses xmonad. The struggle continues.

I hope that I’ve been influenced by the highly non-judgemental and tolerant attitudes of the attendees of the conference. While most people at the conference were pretty ordinary—aside from wanting to talk about the details of Debian packaging and processes!—there were several people who rather visibly rejected social norms about how to present themselves. Around these people there was nothing of the usual tension. Further, in contrast with my environment as a graduate student, everyone was extremely relaxed about how everyone was spending their time. People drinking beer in the evenings were sitting at tables where other people were continuing to silently work on Debian. It is nice to have my experience in Montréal as a reference to check my own judgemental tendencies.

I came away with a lot more than a new MUA: a certainty that I want to try to get to next year’s conference; friends; a real life community behind what was hitherto mostly a hobby; a long list of tasks and the belief that I can accomplish them; a list of PGP fingerprints to sign; a new perspective on the arguments that occur on Debian mailing lists; an awareness of the risk of unconsciously manipulating other community members into getting work done.

With regard to the MUA, I should say that I did not waste a lot of DebConf time messing with its configuration. I had actually worked out a notmuch configuration some months ago, but couldn’t use it because I couldn’t figure out how to incorporate my old mail archives into its index. Fortunately notmuch’s maintainer is also on the Emacs team … he was able to confirm that the crazy solution I’d come up with was not likely to break notmuch’s operating assumptions, and so I was able to spend about half an hour copying and pasting the configuration and scripts I’d previously developed into my homedir, and then start using notmuch for the remainder of the conference. The main reason for wanting to use notmuch was to handle Debian mailing list volume more effectively than I’m able to with mutt, so I was very happy to have the opportunity to pester David with newbie questions.

Many, many thanks to all the volunteers whose efforts made DebCamp17 and DebConf17 possible.

Categories: FLOSS Project Planets

Reproducible builds folks: Reproducible Builds: Weekly report #120

Thu, 2017-08-17 17:48

Here's what happened in the Reproducible Builds effort between Sunday 6th and Saturday 12th August 2017:

Notes about reviews of unreproducible packages

13 package reviews have been added, 7 have been updated and 34 have been removed in this week, adding to our knowledge about identified issues.

Packages reviewed and fixed, and reproducibility related bugs filed

Upstream packages:

Other bugs filed
  • During our reproducibility testing, Adrian Bunk filed 48 FTBFS bugs this week.
diffoscope development trydiffoscope development tests.reproducible-builds.org
  • Mattia:
    • Notify the#debian-reproducible-changes` IRC channel for unreproducible -> FTBFS transitions.
    • Update squid.conf for all nodes to 5.2.23 (and fixup some).
    • Enable the Munin Squid plugin on the Codethink arm64 nodes as well.
    • Force reconfiguration of Apache and Munin when update_jdn.sh is updated.
  • Holger worked on slides for his DebConf17 BoF about migrating to jenkins.debian.org, which affects tests.r-b.o as well.
Misc.

This week's edition was written by Chris Lamb & Holger Levsen & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

Categories: FLOSS Project Planets

Julian Andres Klode: Why TUF does not shine (for APT repositories)

Thu, 2017-08-17 15:49

In DebConf17 there was a talk about The Update Framework, short TUF. TUF claims to be a plug-in solution to software updates, but while it has the same practical level of security as apt, it also has the same shortcomings, including no way to effectively revoke keys.

TUF divides signing responsibilities into roles: A root role, a targets rule (signing stuff to download), a snapshots rule (signing meta data), and a time stamp rule (signing a time stamp file). There also is a mirror role for signing a list of mirrors, but we can ignore that for now. It strongly recommends that all keys except for timestamp and mirrors are kept offline, which is not applicable for APT repositories – Ubuntu updates the repository every 30 minutes, imagine doing that with offline keys. An insane proposal.

In APT repositories, we effectively only have a snapshots rule – the only thing we sign are Release files, and trust is then chained down by hashes (Release files hashes Packages index files, and they have hashes of individual packages). The keys used to sign repositories are online keys, after all, all the metadata files change every 30 minutes (Ubuntu) or 6 hours (Debian) – it’s impossible to sign them by hand. The timestamp role is replaced by a field in the Release file specifying until when the Release file is considered valid.

Let’s check the attacks TUF protects again:

  • Arbitrary installation attacks. – We protect against that with the outer signature and hashes
  • Endless data attacks. – Yes, we impose a limit on Release files (the sizes of other files are specified in there and this file is signed)
  • Extraneous dependencies attacks – That’s verified by the signed hashes of Packages files
  • Fast-forward attacks – same
  • Indefinite freeze attacks – APT has a Valid-Until field that can be used to specify a maximum life time of a release file
  • Malicious mirrors preventing updates. – Well, the user configures the mirror, so usually not applicable. if the user has multiple mirrors, APT deals with that fine
  • Mix-and-match attacks – Again, signed Release file and hashes of other files
  • Rollback attacks – We do not allow Date fields in Release files to go backwards
  • Slow retrieval attacks – TUF cannot protect against that either. APT has very high timeouts, and there is no reasonable answer to that.
  • Vulnerability to key compromises – For our purposes where we need all repository signing keys to be online, as we need to sign new releases and metadata fairly often, it does not make it less vulnerable to require a threshold of keys (APT allows repositories to specify concrete key ids they may be signed with though, that has the same effect)
  • Wrong software installation. – Does not happen, the .deb files are hashed in the Packages files which are signed by the release file

As we can see, APT addresses all attacks TUF addresses.

But both do not handle key revocation. So, if a key & mirror gets compromised (or just key and the mirror is MITMed), we cannot inform the user that the key has been compromised and block updates from the compromised repository.

I just wrote up a proposal to allow APT to query for revoked keys from a different host with a key revocation list (KRL) file that is signed by different keys than the repository. This would solve the problem of key revocation easily – even if the repository host is MITMed or compromised, we can still revoke the keys signing the repository from a different location.


Filed under: Debian, Ubuntu
Categories: FLOSS Project Planets

Shirish Agarwal: Composers are not given due recognition

Thu, 2017-08-17 14:17

Update – Some youtube links are not viewable or even seen on planet.debian.org. Seems p.d.o. tries its best to remove external links, sorry for the breakage.

Beware – some youtube-links would be shared in this entry, sorry couldn’t find a better/easier media platform to work with. If anyone knows any other platform or wants to suggest, feel free to either mail me or let me know in comments.

I want to start today’s sharing with a picture of Ganesha I saw today. It is and was public art hence sharing it without an issue.

This is starting of festivities time in India and Ganesha or Ganpati is looked up as a good omen in India.

The festival of Ganesh Chaturthi would be starting on the 25th of August and is a sight to behold. Just like Rio has its carnival, Ganesh Chaturthi is also a carnival. We also have parades where people come with Pandals (or temporary structures)

The mythology says he has a sweet tooth (hence lot of distribution of sweets, especially modak) and anything which might be troubling people, he creates solutions for them.

Here is one video of how people celebrate his immersion in India. This is from my home-town few years ago, every year the madness and the celebrations are becoming more and more. People from far off come to see how we celebrate and see how different people make their Pandals. While some are with music, others are with social messages. Usually people start going to see these structures after dusk and return home way after midnight or early morning. I hope to do this endeavour after many years. One is drunk from hearing all sorts of different kids of music, decoration, messages, a feast and a strain to all the senses.

Ganesha immersion celebrations – https://www.youtube.com/watch?v=hjWfpGUryho

If one is interested one can find more info. at https://en.wikipedia.org/wiki/Ganesh_Chaturthi

After quite a bit of time, I wrote an article about various foss internships which I knew besides GSOC over the years. I finally penned them down at https://itsfoss.com/best-open-source-internships/

Interestingly, I was amazed to see that all FOSS U.S. projects (outside of GSOC) are for students who are either living or studying in U.S. and have a student work visa (which from private discussions I came to know is lot harder to get nowadays than before). Except for the National Science Foundation (NSF) which probably has U.S. defence relations and hence they might be sensitive, I fail to understand other institutes preferences for only getting people from the U.S. and hence having a lesser talent pool of people. This also affects the growth of the projects themselves. Just think how limited Debian would have been if it had decided to only have people from only any one community develop it. Dunno if this is due to the present President Trump or these policies had been there before. It would be nice and interesting if people in the know can share.

What has also been interesting to watch is Mr. Trump blaming low-cost manufacturing centres like India and China when as far as I recall, lot of manufacturing, specifically auto-mobiles manufacturing was shifted out of the U.S. to Ireland and other places years before which are relatively high-cost places (at least compared to India). I *believe* the change was as early as in 1980’s itself where India was insulated and had a limited market for everything (similar to Russian communism as shown in popular media but not so bad.)

Interestingly, it took almost a month for the perl 2.56 to make the transition smoothly. It took quite a bit of time for all the components to work together and be installable.

Also saw this few days back http://fortune.com/2017/04/12/auto-industry-decline/

While Tesla is expensive even by American standards the idea of lesser parts, lesser complexity and hence lower costs to use, maintain is good. I do hope that he and his team or any of the competitors do overcome the significant challenges. Any significant improvement in battery technology is bound to have huge impact in almost everything that is used in 21st century.

Two recent articles tell me the future may become present very quickly.

https://www.purdue.edu/newsroom/releases/2017/Q2/instantly-rechargeable-battery-could-change-the-future-of-electric-and-hybrid-automobiles.html

Toyota could finally start mass producing electric cars thanks to China

I do hope to see EV being prevalent before the next decade is over otherwise we don’t have any hope due to climate change.

As for my health, I am much better than before. Just to share some stats, before my “illness” for lack of better word, I was 120 kgs. , when I was kept in the hospital for about 2-2.5 weeks I came down to 95 kgs. and now back upto 108 kgs. Do go for exercising every other day and trying to get back the strength, stamina and increasing a bit of both. Doctors have given me another 4-5 months after which a brain scan will reveal if there are any remaining blood clots in the brain or not.

Lastly, while it has become somewhat of a sensitive issue to love Muslims or to talk about their work in any field in the current political climate, there are 4-5 music pieces I listen whenever I can, especially before going to bed. While almost all the pieces have been sung and written by Muslims, sadly I don’t know who the composers of these beautiful songs are.

While it is much easier to get the names of the singer and the lyricist, one of the more important roles in my view is the composer or/and music arranger. Without them, the songs would not have the same haunting quality that the songs have. While I have been lucky to find the names of the composer/music arranger for the pieces below but this is not the case if and when the songs comes on television. I do remember in old times at least on Radio they used to mention about who has given the music as well, dunno in modern times.

I am sharing the songs, and hopefully will also share the translations if I find on the web, please see the lyrics. The numbering is for convenience only and am torn in these 4-5 songs which is the best. Just to share these are all sufi love songs except the last one which I am sharing.

1.

Lyrical song – https://www.youtube.com/watch?v=ehqN6oTpmb8

Translation with video of song – http://www.bollynook.com/en/lyrics/6443/aaj-din-chadheya/

While there probably are stories with each song, I was lucky to find the story about this one. The lyrics of the song are actually a love lost Punjabi poet who writes in the memory of his beloved to which he could not marry and he pens those when standing in line for his liquor. The story goes on that he marries a girl later in life who bears a resemblance to his beloved whom he couldn’t forget till his dying day.

2.

Lyrical song – https://www.youtube.com/watch?v=uTC_2c83qn0

The same song has been sung by different people and I love them all the more for it.

Another video – https://www.youtube.com/watch?v=3G7Qg4LJ7WE

Another video – https://www.youtube.com/watch?v=kOsvNuR3m5Y

Translation – http://www.bollynook.com/en/lyrics/10703/o-re-piya/

3.

Lyrical song – https://www.youtube.com/watch?v=qG7Kms_YA5Q

The translation – http://www.filmyquotes.com/songs/885

The translation of the song is a bit crude but then translations are supposed to be crude

Categories: FLOSS Project Planets

Bits from Debian: Work on Debian for mobile devices continues

Thu, 2017-08-17 09:40

Work on Debian for mobile devices, i.e. telephones, tablets, and handheld computers, continues. During the recent DebConf17 in Montréal, Canada, more than 50 people had a meeting to reconsider opportunities and challenges for Debian on mobile devices.

A number of devices were shown at DebConf:

  • PocketCHIP: A very small handheld computer with keyboard, Wi-Fi, USB, and Bluetooth, running Debian 8 (Jessie) or 9 (Stretch).
  • Pyra: A modular handheld computer with a touchscreen, gaming controls, Wi-Fi, keyboard, multiple USB ports and SD card slots, and an optional modem for either Europe or the USA. It will come preinstalled with Debian.
  • Samsung Galaxy S Relay 4G: An Android smartphone featuring a physical keyboard, which can already run portions of Debian userspace on the Android kernel. Kernel upstreaming is on the way.
  • ZeroPhone: An open-source smartphone based on Raspberry Pi Zero, with a small screen, classic telephone keypad and hardware switches for telephony, Wi-Fi, and the microphone. It is running Debian-based Raspbian OS.

The photo (click to enlarge) shows all four devices, together with a Nokia N900, which was the first Linux-based smartphone by Nokia, running Debian-based Maemo and a completely unrelated Gnuk cryptographic token, which just sneaked into the setting.

If you like to participate, please

Categories: FLOSS Project Planets

Holger Levsen: 20170816-irssi-timezones

Wed, 2017-08-16 17:02
How to change irssi's timezone without restart

Happy birthday to all you lovely Debian people!

For my future self:

<Rhonda> | h01ger: /script exec $ENV{TZ} = 'Europe/Vienna';
Categories: FLOSS Project Planets

Simon McVittie: DebConf 17: Flatpak and Debian

Wed, 2017-08-16 16:50
The indoor garden at Collège de Maisonneuve, the DebConf 17 venue

I'm currently at DebConf 17 in Montréal, back at DebConf for the first time in 10 years (last time was DebConf 7 in Edinburgh). It's great to put names to faces and meet more of my co-developers in person!

On Monday I gave a talk entitled “A Debian maintainer's guide to Flatpak”, aiming to introduce Debian developers to Flatpak, and show how Flatpak and Debian (and Debian derivatives like SteamOS) can help each other. It seems to have been quite well received, with people generally positive about the idea of using Flatpak to deliver backports and faster-moving leaf packages (games!) onto the stable base platform that Debian is so good at providing.

A video of the talk is available from the Debian Meetings Archive. I've also put up my slides in the DebConf git-annex repository, with some small edits to link to more source code: A Debian maintainer's guide to Flatpak. Source code for the slides is also available from Collabora's git server.

The next step is to take my proof-of-concept for building Flatpak runtimes and apps from Debian and SteamOS packages, flatdeb, get it a bit more production-ready, and perhaps start publishing some sample runtimes from a cron job on a Debian or Collabora server. (By the way, if you downloaded that source right after my talk, please update - I've now pushed some late changes that were necessary to fix the 3D drivers for my OpenArena demo.)

I don't think Debian will be going quite as far as Endless any time soon: as Cosimo outlined in the talk right before mine, they deploy their Debian derivative as an immutable base OS with libOSTree, with all the user-installable modules above that coming from Flatpak. That model is certainly an interesting thing to think about for Debian derivatives, though: at Collabora we work on a lot of appliance-like embedded Debian derivatives, with a lot of flexibility during development but very limited state on deployed systems, and Endless' approach seems a perfect fit for those situations.

[Edited 2017-08-16 to fix the link for the slides, and add links for the video]

Categories: FLOSS Project Planets

Ross Gammon: My Debian & Ubuntu work from April to mid-August 2017

Wed, 2017-08-16 13:16

Okay, so I have been slack with my blogging again. I have been travelling around Europe with work quite a bit, had a short holiday over Easter in Denmark, and also had 3 weeks of Summer Holiday in Germany.

Debian
  • Tidied up the packaging and tried building the latest version of libdrumstick, but tests had been added to the package by upstream which were failing. I still need to get back and investigate that.
  • Updated node-seq (targeted at experimental due to the Debian Stretch release freeze) and asked for sponsorship (as I did not have DM rights for it yet).
  • Uploaded the latest version of abcmidi (also to experimental), and again.
  • Updated node-tmp to the latest version and uploaded to experimental.
  • Worked some more on bluebird RFP, but getting errors when running tests. I still haven’t gone back to investigate that.
  • Updated node-coffeeify to the latest version and uploaded to experimental.
  • Uploaded the latest version of node-os-tmpdir (also to experimental).
  • Uploaded the latest version of node-concat-stream (also to experimental).
  • After encouragement from several Debian Developers, I applied to become a full Debian Developer. Over the summer months I worked with Santiago as my Application Manager and answered questions about working in the Debian Project.
  • A web vulnerability was identified in node-concat-stream, so I prepared a fix to the version in unstable, uploaded it to unstable, and submitted a unblock request bug so that it would be fixed in the coming Debian Stretch release.
  • Debian 10 (Stretch) was released! Yay!
  • Moved abcmidi from experimental to unstable, adding an autopkgtest at the same time.
  • Moved node-concat-stream from experimental to unstable. During the process I had to take care of the intermediate upload to stretch (on a separate branch) because of the freeze.
  • Moved node-tmp to unstable from experimental.
  • Moved node-os-tmpdir from experimental to unstable.
  • Filed a removal bug for creepy, which seems to be unmaintained upstream these days. Sent my unfinished Qt4 to Qt5 porting patches upstream just in case!
  • Uploaded node-object-inspect to experimental to check the reverse dependencies, then moved it to unstable. Then a new upstream version came out which is now in experimental waiting for a retest of reverse dependencies.
  • Uploaded the latest version of gramps (4.2.6).
  • Uploaded a new version of node-cross-spawn to experimental.
  • Discovered that I had successfully completed the DD application process and I was now a Debian Developer. I celebrated by uploading the Debian Multimedia Blends package to the NEW queue, which I was not able to do before!
  • Tweaked and uploaded the node-seq package (with an RC fix) which had been sitting there because I did not have DM rights to the package. It is not an important package anyhow, as it is just one of the many dependencies that need to be packaged for Browserify.
  • Packaged and uploaded the latest node-isarray directly to unstable, as the changes seemed harmless.
  • Prepared and uploaded the latest node-js-yaml to experimental.
  • Did an update to the Node packaging Manual now that we are allowed to use “node” as the executable in Debian instead of “nodejs” which caused us to do a lot of patching in the past to get node packages working in Debian.
Ubuntu
  • Did a freeze exception bug for ubuntustudio-controls, but we did not manage to get it sponsored before the Ubuntu Studio Zesty 17.04 release.
  • Investigated why Ardour was not migrating from zesty-proposed, but I couldn’t be sure of what was holding it up. After getting some help from the Developer’s mailing list, I prepared “no change rebuild” of pd-aubio which was sponsored by Steve Langasek after a little tweak. This did the trick.
  • Wrote to the Ubuntu Studio list asking for support for testing the Ubuntu Studio Zesty release, as I would be on holiday in the lead up to the release. When I got back, I found the release had gone smoothly. Thanks team!
  • Worked on some blueprints for the next Ubuntu Studio Artful release.
  • As Set no longer has enough spare time to work on Ubuntu Studio, we had a meeting on IRC to decide what to do. We decided that we should set up a Council like Xubuntu have. I drafted an announcement, but we still have not gone live with it yet. Maybe someone will have read this far and give us a push (or help).
Categories: FLOSS Project Planets

Bits from Debian: Debian turns 24!

Wed, 2017-08-16 11:50

Today is Debian's 24th anniversary. If you are close to any of the cities celebrating Debian Day 2017, you're very welcome to join the party!

If not, there's still time for you to organize a little celebration or contribution to Debian. For example, spread the word about Debian Day with this nice piece of artwork created by Debian Developer Daniel Lenharo de Souza and Valessio Brito, taking inspiration from the desktop themes Lines and softWaves by Juliette Belin:

If you also like graphics design, or design in general, have a look at https://wiki.debian.org/Design and join the team! Or you can visit the general list of Debian Teams for many other opportunities to participate in Debian development.

Thanks to everybody who has contributed to develop our beloved operating system in these 24 years, and happy birthday Debian!

Categories: FLOSS Project Planets

Lisandro Damián Nicanor Pérez Meyer: Qt 4 removal in Debian testing (Buster)/unstable

Tue, 2017-08-15 12:50
We have been announcing it: we are going to remove Qt 4 during the Buster cycle.

Or at least that's the best outcome we can expect. Removing a very highly used library is hard, as Qt4's Webkit has proved. Qt 4 is long dead upstream and we have already started to need to patch it with untested patches as in the OpenSSL 1.1 case (will be in experimental in a few hours after this post).

We will try to put as less effort as possible in keeping it alive meaning that from now on if we need to patch it to make it support a newer lib or alike we will simply remove its support if possible. Using the OpenSSL case as an example, if we need to support any version > 1.1 we will simply remove the SSL support. That means things will break.

So, if you depend on FLOSS which is still based on Qt 4 be sure to try to port it. If you depend on a proprietary vendor software which uses Qt 4 then you better start telling them it's really time to update it. Really.

We will soon start filing bugs against packages using Qt 4. I'll update this blog post later to add that info.

For the Qt/KDE team, Lisandro.
Categories: FLOSS Project Planets

Dirk Eddelbuettel: #9: Compacting your Shared Libraries

Mon, 2017-08-14 21:49

Welcome to the nineth post in the recognisably rancid R randomness series, or R4 for short. Following on the heels of last week's post, we aim to look into the shared libraries created by R.

We love the R build process. It is robust, cross-platform, reliable and rather predicatable. It. Just. Works.

One minor issue, though, which has come up once or twice in the past is the (in)ability to fully control all compilation options. R will always recall CFLAGS, CXXFLAGS, ... etc as used when it was compiled. Which often entails the -g flag for debugging which can seriously inflate the size of the generated object code. And once stored in ${RHOME}/etc/Makeconf we cannot on the fly override these values.

But there is always a way. Sometimes even two.

The first is local and can be used via the (personal) ~/.R/Makevars file (about which I will have to say more in another post). But something I have been using quite a bite lately uses the flags for the shared library linker. Given that we can have different code flavours and compilation choices---between C, Fortran and the different C++ standards---one can end up with a few lines. I currently use this which uses -Wl, to pass an the -S (or --strip-debug) option to the linker (and also reiterates the desire for a shared library, presumably superfluous):

SHLIB_CXXLDFLAGS = -Wl,-S -shared SHLIB_CXX11LDFLAGS = -Wl,-S -shared SHLIB_CXX14LDFLAGS = -Wl,-S -shared SHLIB_FCLDFLAGS = -Wl,-S -shared SHLIB_LDFLAGS = -Wl,-S -shared

Let's consider an example: my most recently uploaded package RProtoBuf. Built under a standard 64-bit Linux setup (Ubuntu 17.04, g++ 6.3) and not using the above, we end up with library containing 12 megabytes (!!) of object code:

edd@brad:~/git/rprotobuf(feature/fewer_warnings)$ ls -lh src/RProtoBuf.so -rwxr-xr-x 1 edd edd 12M Aug 14 20:22 src/RProtoBuf.so edd@brad:~/git/rprotobuf(feature/fewer_warnings)$

However, if we use the flags shown above in .R/Makevars, we end up with much less:

edd@brad:~/git/rprotobuf(feature/fewer_warnings)$ ls -lh src/RProtoBuf.so -rwxr-xr-x 1 edd edd 626K Aug 14 20:29 src/RProtoBuf.so edd@brad:~/git/rprotobuf(feature/fewer_warnings)$

So we reduced the size from 12mb to 0.6mb, an 18-fold decrease. And the file tool still shows the file as 'not stripped' as it still contains the symbols. Only debugging information was removed.

What reduction in size can one expect, generally speaking? I have seen substantial reductions for C++ code, particularly when using tenmplated code. More old-fashioned C code will be less affected. It seems a little difficult to tell---but this method is my new build default as I continually find rather substantial reductions in size (as I tend to work mostly with C++-based packages).

The second option only occured to me this evening, and complements the first which is after all only applicable locally via the ~/.R/Makevars file. What if we wanted it affect each installation of a package? The following addition to its src/Makevars should do:

strippedLib: $(SHLIB) if test -e "/usr/bin/strip"; then /usr/bin/strip --strip-debug $(SHLIB); fi .phony: strippedLib

We declare a new Makefile target strippedLib. But making it dependent on $(SHLIB), we ensure the standard target of this Makefile is built. And by making the target .phony we ensure it will always be executed. And it simply tests for the strip tool, and invokes it on the library after it has been built. Needless to say we get the same reduction is size. And this scheme may even pass muster with CRAN, but I have not yet tried.

Lastly, and acknowledgement. Everything in this post has benefited from discussion with my former colleague Dan Dillon who went as far as setting up tooling in his r-stripper repository. What we have here may be simpler, but it would not have happened with what Dan had put together earlier.

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

Categories: FLOSS Project Planets