Search Results: "ed"

4 December 2015

Lunar: Why is Jack so angry?

Last summer, Innuendo Studios made a series of 6 short videos trying to understand why would anyone get involved in a coordinated harrasment campaign. The recent articles making straw man arguments and gross mischaracterization of the actions of people trying to grow the pool of free software contributors reminded me of these videos, especially the fifth episode which describes why some people get so angry when others point out that maybe the general homogeneity of backgrounds is also related to how we treat people. Guess we can transpose one of the explanation in the video to free software communities:
Bad People do bad things; a sexist is a wife-beater or sexual assailant; I am neither; therefore I am a Good Person and the things I do are good; I work on free software where people report sexist biases; therefore they say I am a wife-beater or sexual assailant; this is a false and ridiculous claim; therefore they are bad.
This slightly helps to better understand why some people would attack efforts that don't concern them so strongly. Sadly, it doesn't help much with what we could do about it. Perhaps we can help them understand that they might be just as biased as everyone else living in an institutionally sexist and racist society. This does not make them bad people. It's just something we all need to keep in mind to improve the situation. (Also, be sure to read the follow-up post if you watch the series until the last episode.) Thanks to Nicolas Dandrimont for his comments and suggestions.

Ritesh Raj Sarraf: Freedom, Privacy and Our Choices

When I bought my Lenovo Yoga 2 13, I had great plans. I wanted a device, that I could use both, as a laptop, and also as a tablet. The path hasn't been easy. But then, no path in Free Software against Freedom and Privacy has been easy. The choice is left to us, the users. I had been a long time KDE User. With KDE's decision to have different UIs for different form factors (plasma active, plasma netbook, plasma desktop), it was now time to try something different. I had 2 choices to explore: Unity and GNOME. But given that Unity is not feasible in Debian, the obvious first option to explore was GNOME. And I guess my timing was perfect. I started with 3.14 which showed great promises about touch support, followed by 3.16 and now 3.18. There's still a long way to go, but GNOME definitely is in the right direction and improves impressively with each release. I would like to thank the Debian GNOME Team. You guys just are amazing. The pace at which the packages are prepared and pushed, it is a tough job. So, thank you. Now that I use GNOME, I also follow some GNOME development, file bugs and read User Feedback. While (many of) the design decisions that GNOME makes today is in line with what I desire, there are other users who aren't happy. Many don't like the new UI design GNOME is heading to, i.e. the fusion of the UI such that it is usable on both form factors: Desktop and Tablet. People find the Toolbars bloated. GNOME developer Allan Day has a good blog post showing the facts. But I think there's the other aspect which needs to be emphasized. By improving the same tools, the GNOME devs are making them capable to be used both, on Laptops and Tablets. This is important to me as a user. I still have the freedom of the tools I use.. And those tools don't sniff. By using the same tools in both modes, I also can reliably build a workflow. I remember when I was moving from IceDove to Evolution. It was painful, but once done, I now have an email client I can still use with basic touch workflow. If you take current GNOME out of the picture, what would a user do. Live with a Laptop and a Tablet, 2 separate device. The laptop running Debian and the Tablet ??? In the direction GNOME is in, it allows me to be liberated for both the use cases. My most valuable assets: data and time, both are efficient in use. And not to forget the reason for this blog entry: Freedom and Privacy. Sure you can choose not to buy/use a tablet at all, and live in a world 10yrs behind. By improving the same tools for both use cases, GNOME is also ensuring that they don't throw away learnings from the past. Today Gtk is touch ready and the same libs also are running when on Laptop. A feature addition/enhancement gets leveraged by both. The Search Bar addition into File Dialog is available both, in Laptop and Tablet mode. And the list could go on.... On the other hand, I'm not sure what the KDE User Experience is today. But if I have to log out of my plasma desktop session, to use in Tablet Mode (plasma active), that workflow is already a broken one. I do miss the flexibility KDE used to provide, where in a substantial part of the user flow could be heavily customized. This is one gripe I have with the GNOME Project in general. They just don't balance things at all. Elegance is not about cutting out features. There are simple things you'll miss in GNOME if you come from KDE. Like Ctrl+R in Kwrite. You can't do that in GEdit. Today, with companies like Google, who are developing tools that are cross-platform, stand as good examples as to what GNOME/KDE should do. Don't bloat the UI, but then again don't strip it off either. The Chromium Browser's UI is a great example. The Chromium UI Devs are pretty strict on what new visible field can be added. But under one Wrench button, they provide a world for everyone to be happy. Power Users can run through the option available, and Super Power Users can use things like chrome://settings and chrome://flags I the new world today, where without a proprietary stack running on your mobil device, it is literally useless; Efforts like that of from the GNOME Project, gives some hope.

Categories:

Keywords:

Like:

Steve Kemp: I jumped on the SSL-bandwagon

Like everybody else on the internet today was the day I started rolling out SSL certificates, via let's encrypt. The process wasn't too difficult, but I did have to make some changes. Pretty much every website I have runs under its own UID, and I use a proxy to pass content through to the right back-end. Running 15+ webservers feels like overkill, but it means that the code running start.steve.org.uk cannot read/modify/break the code that is running this blog - because they run as different UIDs. To start with I made sure that all requests to the top-level /.well-known directory were shunted to a local directory - via this in /etc/apache2/conf-enabled/well-known.conf:
Alias /.well-known/ /srv/well-known/
<Directory "/srv/well-known/">
    ForceType text/plain
    Options Indexes FollowSymLinks MultiViews
    AllowOverride all
    AuthType None
    Require all granted
</Directory>
Then configured each proxy to avoid forwarding that path to the back-ends, by adding this to each of the individual virtual-hosts that run proxying:
<Proxy *>
  Order allow,deny
  Allow from all
</Proxy>
ProxyPass /.well-known !
ProxyPass        / http://localhost:$port/
..
Then it came to be time to actually generate the certificates. Rather than using the official client I used a simpler one that allowed me to generate requests easily:
CSR=/etc/apache2/ssl/csr/
KEYS=/etc/apache2/ssl/keys/
CERTS=/etc/apache2/ssl/certs/
# generate a key
openssl genrsa 4096 > $KEYS/lumail.key
# make a CSR
openssl req -new -sha256 -key $KEYS/lumail.key -subj "/" -reqexts SAN \
   -config <(cat /etc/ssl/openssl.cnf \
   <(printf "[SAN]\nsubjectAltName=DNS:www.lumail.org,DNS:lumail.org")) \
   > $CSR/lumail.csr
# Do the validation
acme_tiny.py --account-key ./account.key --csr $CSR/lumail.csr \
  --acme-dir /srv/well-known/acme-challenge/ > $CERTS/lumail.crt.new
And then I was done. Along the way I found some niggles: The first issue is an annoyance. The second issue is a real pain. For example *.steve.org.uk listens on one machine except for webmail.steve.org.uk. Since there are no wildcards created a single certificate with Alt-names for a bunch of names such as: Then seperately create a certificate for the webmail host - which I've honestly not done yet. Still I wrote a nice little script to generate SSL for a number of domains, with different Alt-Names, wrapping around the acme_tiny.py script, and regenerating all my deployed certificates is now a two minute job. (People talk about renewing certificates. I don't see the gain. Just replace them utterly every two months and you'll be fine.)

Dirk Eddelbuettel: RcppArmadillo 0.6.200.3.0

armadillo image The regular monthly upstream Armadillo update gave us the second update in the 6.* series: version 6.300.2. This was rolled into RcppArmadillo 0.6.300.2 which was once again tested against all reverse-dependencies before being sent to CRAN and Debian where the new packages arrived yesterday. Besides the changes by Conrad, this version of RcppArmadillo also contains a really nice pull request by Nathan Russell which adds input conversion support for Armadillo Cube types, templated to all common inputs, and along with proper unit tests. Thanks! 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. This release brings the following changes:
Changes in RcppArmadillo version 0.6.300.2.0 (2015-12-03)
  • Upgraded to Armadillo 6.300.2 ("Flying Spaghetti Monster")
    • expanded solve() to find approximate solutions for rank-deficient systems
    • faster handling of non-contiguous submatrix views in compound expressions
    • added .for_each() to Mat, Row, Col, Cube and field classes
    • added rcond() for estimating the reciprocal condition number
    • fixes for spsolve(), eigs_sym(), eigs_gen(), svds()
  • Added support for Cube types via as<> converters (PR #64 by Nathan Russell, fixing #63 and #42)
Courtesy of CRANberries, there is also a diffstat report for the most recent CRAN release. As always, 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.

Dirk Eddelbuettel: RQuantLib 0.4.2: Now with intra-day times

A new minor release of RQuantLib was released onto CRAN and into Debian. It takes advantages of some changes from last week's QuantLib release 1.7. 500 Rcpp packages Particularly noteworthy is the addition of support for intra-daily times in QuantLib based on work by Klaus Spanderen. If QuantLib was configured with the -enable-intraday option, we use the higher granularity of the time representation in all option pricers and implied volatility calculations. The impact of this feature is illustrated in the graph below. The graph shows the valuation of a Call option, European expiry, struck at the money with sensible short rate, dividend yield and volatility. We vary the time to expiry from five days to zero in steps of a quarter day. In darker blue is the correct valuation declining in parabolic shape. In lighter blue is what we get with QuantLib up to release 1.6, or newer releases configured without intra-day time support: an ugly step function that is off, and increasingly so we approach the expiration. Which leads to an appeal: a volunteer is needed to update the QuantLib 1.7 build for Windows. Jeroen tried, but ran into a snag and out of time. If you can help, please get in touch to Jeroen and myself. We suspect that the largest part of RQuantLib users relies on the prebuilt binaries from CRAN, and it would nice to have these updated to the current version of QuantLib. The full changes are detailed below.
Changes in RQuantLib version 0.4.2 (2015-12-03)
  • Changes in RQuantLib code:
    • Intra-day times are now available if QuantLib 1.7 or later is used, and has been configured with --enable-intraday
    • New helper functions getQuantLibVersion() and getQuantLibCapabilties()
    • New package startup code detects and warns about outdated QuantLib versions, or missing intra-day capability, unless not interactive.
    • The missing Monthly parameter has been added to matchFrequency (fixing issue ticket #19)
Courtesy of CRANberries, there is also a diffstat report for the this release. As always, more detailed information is on the RQuantLib page. Questions, comments etc should go to the rquantlib-devel mailing list off the R-Forge page. Issue tickets can be filed at 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.

3 December 2015

Bits from Debian: Software Freedom Conservancy needs your support!

Software Freedom Conservancy Logo "Software Freedom Conservancy helps promote, improve, develop, and defend Free, Libre, and Open Source Software (FLOSS) projects. Conservancy provides a non-profit home and infrastructure for FLOSS projects.", that is how Software Freedom Conservancy defines itself. Organizations like Conservancy allow free software developers to focus on what they do the best by doing copyleft enforcement, taking care of legal aspects and provide many services to its project members. Last August, Debian and Conservancy announced a partnership and formed the Copyright Aggregation Project where, among other things, Conservancy will be able to hold copyrights for some Debian works and ensure compliance with copyleft so that those works remain in free software. Recently, Conservancy launched a major fundraising campaign and needs more individual supporters to gain more sustainable and independent funding. This will allow the Conservancy to continue its efforts towards convincing more companies to comply with free software licenses such as the GPL and take legal actions when dialogue turns out to be unsuccessful. Conservancy needs your support now, more than ever! Many Debian Developers and Contributors have already become Conservancy supporters. Please consider signing up as a supporter on https://sfconservancy.org/supporter/!

Arturo Borrero Gonz lez: current status of HA stack on Debian


Let's analyse the current status of the HA (high availability) stack on Debian.

For me, the two most important packages are corosync and pacemaker.
It is widely known that Debian jessie was released without these two packages in shape.

But, why?
Problem 1One of the main problems was with the relationship between pacemaker and libqb.
In short, a libqb issue prevented pacemaker to be built for Debian jessie. And that wasn't fixed in time for the Debian jessie stable release.
You can read the Debian bug #768618 [pacemaker: FTBFS in jessie: build-dependency not installable: libqb-dev (>= 0.16.0.real)] to know a bit more about the issue.
Problem 2
While at it, the corosync package was in very bad shape.
To get an idea of what I mean for bad shape, just look at the size of the changelog of the first try to fix the package, almost 90 lines long.
Problem 3
Perhaps the most important problem: the Debian team behind the HA stack seems inactive.

This was sent by one of the members, 19 Jan 2015:
[...]
I wonder if there are any active members of the Debian linux-ha team.
[...]

So, there is clearly lack of manpower, lack of interest in maintaining the stack.
I'm sure the first 2 problems could have been resolved in time if the Debian team were active.
It's Debian! How is this possible!?I have asked that myself several times. Debian is a community and collaborative project. This means that the quality of the product (the OS itself) is directly related to the amount of effort spent on it (by people that in most cases aren't being paid for the task).
I believe that in such specific pieces of software, we require a bit more push from companies which are using it for their own benefit as well.

Also, perhaps the Debian QA team may step in and do something about the situation, let's say simply distributing a big REQUEST FOR HELP alert in all official Debian channels.
So, what if I need to run now corosync+pacemaker in Debian?
I'm sorry, you should stick to Debian wheezy :-(

Fortunately, the versions shipped in Debian wheezy are fine. Unfortunately, Debian wheezy contains lots of old software (such as the kernel).
What should I expect for Debian stretch?
Well, some good news: corosync and libqb have been already fixed and they look good.
The pacemaker package is still lacking the needed updates, but there are some people [slowly] working on it.
I myself have contributed a bit: tested some related packages, opened some bugs, and so on. See #801853 and #801870 for instance.

Note that the development status is not easy to follow. Among other things, the 'official' git packaging repos aren't being used.

From the user/sysadmin point of view, any important news will be reflected in the Debian package trackers. Here are links to both:
(BTW the new Debian tracker: what a nice tool)
I want to contribute!By now, I recommend you to head to the Debian IRC channel #debian-ha

Russ Allbery: podlators 4.02

Another day, another podlators release. This time, a slightly misguided cleanup I did on the build system broke useful installation for versions of Perl prior to 5.11. (The module would be installed, but in a directory shadowed by the Perl core library, so to no real effect.) Thanks very much to Peter Rabbitson for all the help in sorting out these build issues. Now I have better comments about all the interesting traps for dual-life modules. You can get the latest version from the podlators distribution page.

Dirk Eddelbuettel: RcppCCTZ 0.0.2 -- now with Solaris support

Following on yesterday's announcement of RcppCCTZ, what is the only thing better than another date, time, or timezones library package? One that works on Solaris too :) Bradley White from CCTZ upstream spotted the failed compilation on the machine in Oxford and suggested a quick fix. Jeroen quickly tested what I had put into a branch, and there we have it: version 0.0.2 which now builds everywhere. Changes (for both releases) are summarized here:
Changes in version 0.0.2 (2015-12-02)
  • Additional #ifdef statements suggested by Bradley White in CCTZ ticket #5 permitting compilation on Solaris with thanks to Jeroen for testing our branch.
Changes in version 0.0.1 (2015-12-01)
  • Initial CRAN upload.
  • Package is functional and provides examples.
We now also have a diff to the previous version thanks to CRANberries. More details, issue tickets etc at the GitHub repository.

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

2 December 2015

Colin Watson: SSH SHA-2 support in Twisted

Launchpad operates a few SSH endpoints: bazaar.launchpad.net and git.launchpad.net for code hosting, and upload.ubuntu.com and ppa.launchpad.net for uploading packages. None of these are straightforward OpenSSH servers, because they don t give ordinary shell access and they authenticate against users SSH keys recorded in Launchpad; both of these are much easier to do with SSH server code that we can use in library form as part of another service. We use Twisted for several other tasks where we need event-based networking code, and its conch package is a good fit for this. Of course, this means that it s important that conch keeps up to date with the cryptographic state of the art in other SSH implementations, and this hasn t always been the case. OpenSSH 7.0 dropped support for some old algorithms, including disabling the 1024-bit diffie-hellman-group1-sha1 key exchange method at run-time. Unfortunately, this also happened to be the only key exchange method that Launchpad s SSH endpoints supported (conch supported the slightly better diffie-hellman-group-exchange-sha1 method as well, but that was disabled in Launchpad due to a missing piece of configuration). SHA-2 support was clearly called for, and the fact that we had to get this sorted out in conch first meant that everything took a bit longer than we d hoped. In Twisted 15.5, we contributed support for several conch improvements: Between them and with some adjustments to the lazr.sshserver package we use to glue all this together to add support for DH group exchange, these are enough to allow us not to rely on SHA-1 at all, and these improvements have now been rolled out to all four endpoints listed above. I ve thus also uploaded OpenSSH 7.1 packages to Debian unstable. If you also run a Twisted-based SSH server, upgrade it now! Otherwise it will be harder for users of recent OpenSSH client versions to use your server, and for good reason.

Andrea Veri: Three years and counting

It s been a while since my last what s been happening behind the scenes e-mail so I m here to report on what has been happening within the GNOME Infrastructure, its future plans and my personal sensations about a challenge that started around three (3) years ago when Sriram Ramkrishna and Jeff Schroeder proposed my name as a possible candidate for coordinating the team that runs the systems behind the GNOME Project. All this followed by the official hiring achieved by Karen Sandler back in February 2013. The GNOME Infrastructure has finally reached stability both in terms of reliability and uptime, we didn t have any service disruption this and the past year and services have been running smoothly as they were expected to in a project like the one we are managing. As many of you know service disruptions and a total lack of maintenance were very common before I joined back in 2013, I m so glad the situation has dramatically changed and developers, users, passionates are now able to reach our websites, code repositories, build machines without experiencing slowness, downtimes or
unreachability. Additionally all these groups of people now have a reference point they can contact in case they need help when coping with the infrastructure they daily use. The ticketing system allows users to get in touch with the members of the Sysadmin Team and receive support right away within a very short period of time (Also thanks to Pagerduty, service the Foundation is kindly sponsoring) Before moving ahead to the future plans I d like to provide you a summary of what has been done during these roughly three years so you can get an idea of why I define the changes that happened to the infrastructure a complete revamp:
  1. Recycled several ancient machines migrating services off of them while consolidating them by placing all their configuration on our central configuration management platform ran by Puppet. This includes a grand total of 7 machines that were replaced by new hardware and extended warranties the Foundation kindly sponsored.
  2. We strenghten our websites security by introducing SSL certificates everywhere and recently replacing them with SHA2 certificates.
  3. We introduced several services such as Owncloud, the Commits Bot, the Pastebin, the Etherpad, Jabber, the GNOME Github mirror.
  4. We restructured the way we backup our machines also thanks to the Fedora Project sponsoring the disk space on their backup facility. The way we were used to handle backups drastically changed from early years where a magnetic tape facility was in charge of all the burden of archiving our data to today where a NetApp is used together with rdiff-backup.
  5. We upgraded Bugzilla to the latest release, a huge thanks goes to Krzesimir Nowak who kindly helped us building the migration tools.
  6. We introduced the GNOME Apprentice program open-sourcing our internal Puppet repository and cleansing it (shallow clones FTW!) from any sensitive information which now lives on a different repository with restricted access.
  7. We retired Mango and our OpenLDAP instance in favor of FreeIPA which allows users to modify their account information on their own without waiting for the Accounts Team to process the change.
  8. We documented how our internal tools are customized to play together making it easy for future Sysadmin Team members to learn how the infrastructure works and supersede existing members in case they aren t able to keep up their position anymore.
  9. We started providing hosting to the GIMP and GTK projects which now completely rely on the GNOME Infrastructure. (DNS, email, websites and other services infrastructure hosting)
  10. We started providing hosting not only to the GIMP and GTK projects but to localized communities as well such as GNOME Hispano and GNOME Greece
  11. We configured proper monitoring for all the hosted services thanks to Nagios and Check-MK
  12. We migrated the IRC network to a newer ircd with proper IRC services (Nickserv, Chanserv) in place.
  13. We made sure each machine had a configured management (mgmt) and KVM interface for direct remote access to the bare metal machine itself, its hardware status and all the operations related to it. (hard reset, reboot, shutdown etc.)
  14. We upgraded MoinMoin to the latest release and made a substantial cleanup of old accounts, pages marked as spam and trashed pages.
  15. We deployed DNSSEC for several domains we manage including gnome.org, guadec.es, gnomehispano.es, guadec.org, gtk.org and gimp.org
  16. We introduced an account de-activation policy which comes into play when a contributor not committing to any of the hosted repositories at git.gnome.org since two years is caught by the script. The account in question is marked as inactive and the gnomecvs (from the old cvs days) and ftpadmin groups are removed.
  17. We planned mass reboots of all the machines roughly every month for properly applying security and kernel updates.
  18. We introduced Mirrorbrain (MB), the mirroring service serving GNOME and related modules tarballs and software all over the world. Before introducing MB GNOME had several mirrors located in all the main continents and at the same time a very low amount of users making good use of them. Many organizations and companies behind these mirrors decided to not host GNOME sources anymore as the statistics of usage were very poor and preferred providing the same service to projects that really had a demand for these resources. MB solved all this allowing a proper redirect to the closest mirror (through mod_geoip) and making sure the sources checksum matched across all the mirrors and against the original tarball uploaded by a GNOME maintainer and hosted at master.gnome.org.
I can keep the list going for dozens of other accomplished tasks but I m sure many of you are now more interested in what the future plans actually are in terms of where the GNOME Infrastructure should be in the next couple of years. One of the main topics we ve been discussing will be migrating our Git infrastructure away from cgit (which is mainly serving as a code browsing tool) to a more complete platform that is surely going to include a code review tool of some sort. (Gerrit, Gitlab, Phabricator) Another topic would be migrating our mailing lists to Mailman 3 / Hyperkitty. This also means we definitely need a staging infrastructure in place for testing these kind of transitions ideally bound to a separate Puppet / Ansible repository or branch. Having a different repository for testing purposes will also mean helping apprentices to test their changes directly on a live system and not on their personal computer which might be running a different OS / set of tools than the ones we run on the GNOME Infrastructure. What I also aim would be seeing GNOME Accounts being the only authentication resource in use within the whole GNOME Infrastructure. That means one should be able to login to a specific service with the same username / password in use on the other hosted services. That s been on my todo list for a while already and it s probably time to push it forward together with Patrick Uiterwijk, responsible of Ipsilon s development at Red Hat and GNOME Sysadmin. While these are the top priority items we are soon receiving new hardware (plus extended warranty renewals for two out of the three machines that had their warranty renewed a while back) and migrating some of the VMs off from the current set of machines to the new boxes is definitely another task I d be willing to look at in the next couple of months (one machine (ns-master.gnome.org) is being decommissioned giving me a chance to migrate away from BIND into NSD). The GNOME Infrastructure is evolving and it s crucial to have someone maintaining it. On this side I m bringing to your attention the fact the assigned Sysadmin funds are running out as reported on the Board minutes from the 27th of October. On this side Jeff Fortin started looking for possible sponsors and came up with the idea of making a brochure with a set of accomplished tasks that couldn t have been possible without the Sysadmin fundraising campaign launched by Stormy Peters back in June 2010 being a success. The Board is well aware of the importance of having someone looking at the infrastructure that runs the GNOME Project and is making sure the brochure will be properly reviewed and published. And now some stats taken from the Puppet Git Repository:
$ cd /git/GNOME/puppet && git shortlog -ns
3520 Andrea Veri
506 Olav Vitters
338 Owen W. Taylor
239 Patrick Uiterwijk
112 Jeff Schroeder
71 Christer Edwards
4 Daniel Mustieles
4 Matanya Moses
3 Tobias Mueller
2 John Carr
2 Ray Wang
1 Daniel Mustieles Garc a
1 Peter Baumgarten
and from the Request Tracker database (52388 being my assigned ID):
mysql> select count(*) from Tickets where LastUpdatedBy = '52388';
+----------+
  count(*)  
+----------+
  3613  
+----------+
1 row in set (0.01 sec)
mysql> select count(*) from Tickets where LastUpdatedBy = '52388' and Status = 'Resolved';
+----------+
  count(*)  
+----------+
  1596  
+----------+
1 row in set (0.03 sec)
It s been a long run which made me proud, for the things I learnt, for the tasks I ve been able to accomplish, for the great support the GNOME community gave me all the time and most of all for the same fact of being part of the team responsible of the systems hosting the GNOME Project. Thank you GNOME community for your continued and never ending backing, we daily work to improve how the services we host are delivered to you and the support we receive back is fundamental for our passion and enthusiasm to remain high!

Daniel Pocock: Is giving money to Conservancy the best course of action?

There has been a lot of discussion lately about Software Freedom Conservancy's fundraiser. Various questions come to my mind: Is this the only way to achieve goals such as defending copyright? (There are other options, like corporate legal insurance policies) When all the options are compared, is Conservancy the best one? Maybe it is, but it would be great to confirm why we reached that conclusion. Could it be necessary to choose two or more options that complement each other? Conservancy may just be one part of the solution and we may get a far better outcome if money is divided between Conservancy and insurance and something else. What about all the other expenses that developers incur while producing free software? Many other professionals, like doctors, do work that is just as valuable for society but they are not made to feel guilty about asking for payment and reimbursement. (In fact, for doctors, there is no shortage of it from the drug companies). There seems to be an awkwardness about dealing with money in the free software world and it means many projects continue to go from one crisis to the next. Just yesterday on another mailing list there was discussion about speakers regularly asking for reimbursement to attend conferences and at least one strongly worded email appeared questioning whether people asking about money are sufficiently enthusiastic about free software or if they are only offering to speak in the hope their trip will be paid. The DebConf team experienced one of the more disappointing examples of a budget communication issue when developers who had already volunteered long hours to prepare for the event then had to give up valuable time during the conference to wash the dishes for 300 people. Had the team simply insisted that the high cost of local labor was known when the country was selected then the task could have been easily outsourced to local staff. This came about because some members of the community felt nervous about asking for budget and other people couldn't commit to spend. Rather than stomping on developers who ask about money or anticipate the need for it in advance, I believe we need to ask people if money was not taboo, what is the effort they could contribute to the free software world and how much would they need to spend in a year for all the expenses that involved. After all, isn't that similar to the appeal from Conservancy's directors? If all developers and contributors were suitably funded, then many people would budget for contributions to Conservancy, other insurances, attending more events and a range of other expenses that would make the free software world operate more smoothly. In contrast, the situation we have now (for event-related expenses) is that developers funding themselves or with tightly constrained budgets or grants often have to spend hours picking through AirBNB and airline web sites trying to get the best deal while those few developers who do have more flexible corporate charge cards just pick a convenient hotel and don't lose any time reading through the fine print to see if there are charges for wifi, breakfast, parking, hidden taxes and all the other gotchas because all of that will be covered for them. With developer budgets/wishlists documented, where will the money come from? Maybe it won't appear, maybe it will. But if we don't ask for it at all, we are much less likely to get anything. Mozilla has recently suggested that developers need more cash and offered to put $1 million on the table to fix the problem, is it possible other companies may see the benefit of this and put up some cash too? The time it takes to promote one large budget and gather donations is probably far more efficient than the energy lost firefighting lots of little crisis situations. Being more confident about money can also do a lot more to help engage people and make their participation sustainable in the long term. For example, if a younger developer is trying to save the equivalent of two years of their salary to pay a deposit on a house purchase, how will they feel about giving money to Conservancy or paying their own travel expenses to a free software event? Are their families and other people they respect telling them to spend or to save and if our message is not compatible with that, is it harder for us to connect with these people? One other thing to keep in mind is that budgeting needs to include the costs of those who may help the fund-raising and administration of money. If existing members of our projects are not excited about doing such work we have to be willing to break from the "wait for a volunteer or do-it-yourself" attitude. There are so many chores that we are far more capable of doing as developers that we still don't have time for, we are only fooling ourselves if we anticipate that effective fund-raising will take place without some incentives going back to those who do the work.

Norbert Preining: SJW attitude in science

Recently, Eric Raymond, famous for is The Cathedral and the Bazaar , stepped forward to speak out against mixing social agenda, like equal treatment for everyone outside the white straight group, with meritocracy, the evaluation of one solely based on his/her contribution. And without fail, the SJW side of the Internet didn t take much time to munch down on Raymond like hungry wolves in a long winter: Coraline Ada Ehmke (should that recall Ada Lovelace?), Tim Chevalier, Matthew Garret, just to name a few. rastafari2 The arguments are quite easy to summarize: The meritocracy party proposes that One s contribution should only be evaluated based on the content and the quality , while the SJW party asserts that in case the submitter as from a minority group, in particular everyone outside the white straight group, the contribution has to be accepted with higher probability (or without discussion) to ensure equality. (Added here for clarification: A SJW is someone who puts the agenda of anti-genderization and anti-biasization (nice word) above all other objectives, often by quoting scientific results on existing and not deniable bias) Well, I am a scientist, and I can tell you just one thing: I simply don t give a shit for whether someone is white, black, red, green, red, straight, gay, a Rastafari or Pastafari (well, to be honest, I really give an extra 3 plus points to Pastafari!), really, I check their proofs. And if they are rubbish, they are rubbish. If they are ok, they are ok. Let us for a moment assume that the world of research would work the same way as the proposed world of Ehmke, Chevalier, Garret, and all the other SJW: A lesbian female black is submitting an article to a scientific journal (first of all, as a referee I wouldn t even know about her sexual interest, nor her color, nor her background in most of the cases), and the honest referee reports would dare to reject the paper due to technical and methodological insufficiencies. A very common case. Now, the average SJW (including the above named, according to their blog posts) would require us to be open and, well, publish a rubbish paper just because it is written by an non-white-non-male author. What should I say well stupidity seemingly does not have a limit. Hopefully software projects around the world do not fall into this stupid trap, and continue evaluating contributions solely on their actual merit. This is all I am asking for, quite in contrast to the SJW groupies. And this is also what Raymond is asking for so I have not the slightest idea why anyone around this planet sees a need to step up and become noisy.

Michal &#268;iha&#345;: Supporting Software Freedom Conservancy

Last week the Software Freedom Conservancy has launched fundraiser to be able to continue operation under new circumstances, where some sponsors left them after GPL enforcement activities. I think Conservancy does quite a lot for free software ecosystem and GPL enforcement is something what has to be done, if we want to protect free software world. That's reason, why I've decided to become their supporter: Become a Conservancy Supporter!

Filed under: Debian English phpMyAdmin SUSE 0 comments

Russ Allbery: podlators 4.01

The previous release, switching to Module::Build, created a circular dependency with Module::Build itself with older versions of Perl. I pondered various ways to get around this, since I'm no longer a fan of ExtUtils::MakeMaker, but I finally decided that I was being silly. So podlators now just uses ExtUtils::MakeMaker it does support the new metadata keys these days rather than trying to support two separate build systems. (ExtUtils::MakeMaker is required for Perl core integration.) This release also didn't fix the problems with Term::Cap 1.16 in particular (although it worked with 1.17). That's also now fixed in this release by ensuring that Pod::Text::Termcap doesn't override an existing TERMPATH environment variable setting, something it shouldn't have been doing in the first place. You can get the latest release from the podlators distribution page.

Dirk Eddelbuettel: RcppCCTZ 0.0.1

A new package! A couple of weeks ago folks at Google released CCTZ: a C++ library for translating between absolute and civil times using the rules of a time zone. It requires only a proper C++11 compiler and the standard IANA time zone data base which standard Unix, Linux, OS X, ... computers tend to have in /usr/share/zoneinfo. And as the world needs nothing more than additional date, time, or timezones libraries, I started to quickly create a basic R wrapper package. This stalled as the original version of CCTZ used an __int128 for extended precision. That is not only not portable, but also prohibits compilation on baby computers still running a 32 OS (such as my trusted X1 laptop merrily plugging along with 4 gb of ram under Linux). Hence I filed an issue ticket which, lo and behold, got resolved two days ago. And so now we have a shiny new RcppCCTZ package on CRAN in a very basic version 0.0.1. It happily runs all the original examples from CCTZ as e.g. this one:
// from examples/hello.cc
//
// [[Rcpp::export]]
int helloMoon()  
    cctz::TimeZone syd;
    if (!cctz::LoadTimeZone("Australia/Sydney", &syd)) return -1;
    // Neil Armstrong first walks on the moon
    const auto tp1 = cctz::MakeTime(1969, 7, 21, 12, 56, 0, syd);
    const std::string s = cctz::Format("%F %T %z", tp1, syd);
    Rcpp::Rcout << s << "\n";
    cctz::TimeZone nyc;
    cctz::LoadTimeZone("America/New_York", &nyc);
    const auto tp2 = cctz::MakeTime(1969, 7, 20, 22, 56, 0, nyc);
    return tp2 == tp1 ? 0 : 1;
 
which results in
R> library(RcppCCTZ)
R> helloMoon()
1969-07-21 12:56:00 +1000
[1] 0
R>
indicating that the two civil times in fact correspond to the same absolute times when Armstrong walked on the moon. If you want to learn more about CCTZ, there was a corresponding talk CppCon (Youtube, Slides). I hope this provides a starting point for some new interesting computation on time from R. Collaboration welcome via the RcppCCTZ 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.

1 December 2015

Thorsten Alteholz: My Debian Activities in November 2015

FTP assistant This month I marked 352 packages for accept and rejected 61 of them. I had to send only 15 emails to maintainers. I also started to work on #796095 and #796784, but my first patch was rejected. So expect more to come here Squeeze LTS This was my seventeenth month that I did some work for the Squeeze LTS initiative, started by Raphael Hertzog at Freexian. Due to Toshiba becoming the first platinum sponsor, I got a workload of 21.25h. This is a new and delightful record! Altogether I uploaded those DLAs: I also started to work on two bugs that were filed against the pseudo-package ftp.debian.org, which are somehow related to the security team: #796095 and #796784 (see above). Moreover I started to work on the next php5 upload, which will happen at the end of December. As more and more people work at the LTS frontdesk now, this month I could chill out a bit and let the others do the work. Other stuff As the Advent season started again I would also like to draw some attention to the Debian Med Advent Calendar. It was announced here and like the past years, the Debian Med team starts a bug squashing event from the December 1st to 24th. Every bug that is closed will be registered in the calendar. So instead of taking something from the calendar, this special one will be filled and at Christmas hopefully every Debian Med related bug is closed. Don t hestitate, start to squash :-) .

Scott Kitterman: Debian LTS Work November 2015

This was my seventh month as a Freexian sponsored LTS contributor. I was assigned 8 hours for the month of November. As I did last month, I worked on review and testing of the proposed MySQL 5.5 packages for squeeze-lts and did a bit more work on Quassel. It has been suggested that maybe we ought to just EOL Quassel since backporting the necessary fixes is so complicated. I think they may be right, but I haven t quite given up yet. I reviewed CVE-2015-6360 for SRTP and my assessment was that squeeze-lts was not affected (same for the other Debian releases while I was at it). I published one security update, it was for libphp-snoopy. This resolves the outstanding security issues by updating to the newest version as was done for all other Debian releases. Finally, in the interest of getting better support in tools for Debian LTS, I came up with a patch for the pull-debian-source[1] script in ubuntu-dev-tools so that it will download Debian LTS packages correctly. Although it took a bit of investigating, the patch turned out to be very simple. I filed bug #806749. I also started looking at the distro-info package (thinking I d need it updated to fix pull-debian-source, which turned out not to be the case), but didn t finish it yet. I plan to work on that this month. [1] Even though this is in ubuntu-dev-tools and not devscripts, there s really nothing Ubuntu specific about it.

Laura Arjona: Software Freedom Conservancy supporter

I think it s important that organizations as Software Freedom Conservancy exist.
They provide a non-profit home, infrastructure, and advice for FLOSS projects. They take care that the will of the project members, choosing free software licenses, is respected by third parties. They care about all the rest so free software contributors can focus in improving the software itself. They have an agreement with the Debian community to protect the freedoms that Debian Developers provide to the Debian end users (and derivative distributions). So I decided to join as supporter. I m happy that this week there is a matching fund so my donation will count double. I hope that many others join too, so the organization s voice and action continues loyal to their goals and representative of all the projects (wether big or small) under their umbrella. This way (small donations from many individuals as funding model), no single or few actors can use their big money as pressure to deviate or block Conservancy s action. We free software/free knowledge contributors know very well the power that many micro actions can provide, when coordinated towards the common good, isn t it?
Filed under: My experiences and opinion Tagged: Communities, Contributing to libre software, Debian, Economic Aspects, English, Free Software, licenses, Project Management

Enrico Zini: akonadi-fails-to-sync

When Akonadi silently fails to sync your calendar... Bug severity: seriously ruining my life. Try to use korganizer to create a calendar entry when the server is not reachable (say, you are offline, or you typed the wrong password), and you may find that you end up with no error messages, an entry that shows up perfectly fine, but that will never be synced to the server, ever again. I use korganizer, radicale and caldav for important things. The practical ramifications of me inserting entries in korganizer, seeing that everything looks ok, and then not finding them on my phone while on the go, are scary. Think of things like importing .ics files with flight schedules, entering tax deadlines, time and places for customer meetings, time and places of arrival of loved ones I'm supposed to pick up. I spent time setting up my own infrastructure for this exactly because I care that all of this works reliably. And now I urgently took a morning off work to find a way to detect those entries that Akonadi is refusing to update, The whole thing is cumbersome to run, but if you are using kdepim-based tools to manage your calendars and sync them across devices, you may want to give it a go every once in a while. You can find the script and the notes I took so far on the issue at https://github.com/spanezz/akonadi-workarounds.

Next.

Previous.