"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/!
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.
[...] 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:
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.
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.
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.
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:
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.
We strenghten our websites security by introducing SSL certificates everywhere and recently replacing them with SHA2 certificates.
We introduced several services such as Owncloud, the Commits Bot, the Pastebin, the Etherpad, Jabber, the GNOME Github mirror.
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.
We upgraded Bugzilla to the latest release, a huge thanks goes to Krzesimir Nowak who kindly helped us building the migration tools.
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.
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.
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.
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)
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
We configured proper monitoring for all the hosted services thanks to Nagios and Check-MK
We migrated the IRC network to a newer ircd with proper IRC services (Nickserv, Chanserv) in place.
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.)
We upgraded MoinMoin to the latest release and made a substantial cleanup of old accounts, pages marked as spam and trashed pages.
We deployed DNSSEC for several domains we manage including gnome.org, guadec.es, gnomehispano.es, guadec.org, gtk.org and gimp.org
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.
We planned mass reboots of all the machines roughly every month for properly applying security and kernel updates.
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!
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.
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.
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.
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.
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 moonconstauto 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);
constauto tp2 = cctz::MakeTime(1969, 7, 20, 22, 56, 0, nyc);
return tp2 == tp1 ? 0 : 1;
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.
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:
[DLA 341-1] php5 security update
[DLA 343-1] libpng security update
[DLA 355-1] libxml2 security update
[DLA 356-1] libsndfile security update
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 .
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.
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
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.
I recently presented a talk at the Debian miniconf in Cambridge. This was a new talk explaining what goes on in a web browser to get a web page on screen.
The presentation was filmed and my slides are also available. I think it went over pretty well despite the venues lighting adding a strobe ambiance to part of proceedings.
I thought the conference was a great success overall and enjoyed participating. I should like to thank Cosworth for allowing me time to attend and for providing some sponsorship.
My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me.
Debian LTS
This month I have been paid to work 21.25 hours on Debian LTS. During this time I worked on the following things:
From November 2nd to November 8th, I was handling the LTS frontdesk, triaging new CVE, filing bugs, and ensuring timely answers on the mailing list. I pushed 26 commits to the security tracker. While investigating CVE-2015-7183 I discovered more embedded copies of nspr (which resulted in #804058). I also commented on the upstream fix for CVE-2015-5602 which looked like insufficient.
Prepared and released DLA-339-1 on libhtml-scrubber-perl fixing one CVE.
Prepared and released DLA-350-1 on eglibc with a non-trivial backport fixing one CVE.
Prepared and released DLA-353-1 on imagemagick fixing two security issues without CVE yet (and marking one as not-affecting squeeze).
Added a third patch after review by the upstream author on my still pending bouncycastle update. The upstream author asked me to further defer the update as they have some related fixes coming up.
I did preparatory work for DLA-352-1 by identifying the upstream commits that fixed the security issue.
I spent some time checking issues that have been assigned for a long time without any visible progress being made in the hope to unblock them (libvncserver, pound, quassel).
The Debian Administrator s Handbook
Now that the English version has been finalized for Debian 8 Jessie (I uploaded the package to Debian Unstable), I concentrated my efforts on the French version. The book has been fully translated and we re now finalizing the print version that Eyrolles will again edit.
Paris Open Source Summit
On November 18th and 19th, I was in Paris for the Paris Open Source Summit. I helped to hold a booth for Debian France during two days (with the help of Fran ois-R gis and several others).
Fran ois-R gis Vuillemin, Juliette Belin and Rapha l Hertzog
On the booth, we had the visit of Juliette Belin who created the theme and the artwork of Debian 8 Jessie. We lacked goodies but we organized a lottery to win 12copies of my French book.
Debian packaging work
Django. After two weeks of preparation for revers dependencies, I uploaded Django 1.8 to unstable and raised the severity of remaining bugs. Later I uploaded a new upstream point release (1.8.6). I also handled a release critical bug first by opening a ticket upstream and then by writing a patch and submitting it upstream. I uploaded 1.8.7-2 to Debian with my patch.
I also submittted another small fix which has been rejected because the manual page is generated via Sphinx and I thus had to file a bug against Sphinx (which I did). A work-around has been found in the mean time.
apt-xapian-index NMU. A long time ago, I filed a release critical bug against that package (#793681) but the maintainer did not handle it. Fortunately Sven Joachim prepared an NMU and I just uploaded his work. This resulted in another problem due bash-completion changes that Sven promptly fixed and I uploaded a second NMU a few days later.
Gnome-shell-timer. I forwarded #805347 to gnome-shell-timer issue #29 but gnome-shell-timer is abandoned upstream. On a suggestion of Paul Wise, I tried to get this nice extension integrated into gnome-shell-extensions but the request has been turned down. Is there anyone with javascript skills who would like to adopt this project as an upstream developer? It s a low maintenance project with a decent and loyal user base.
Misc. I fixed bug #804763 in zim which was the result of a bad Debian-specific patch.
I sponsored pylint-plugin-utils_0.2.3-2.dsc for Joseph Herlant to fix a release critical bug. I filed 806237 against lintian. I filed more tickets upstream, related to my Kali packaging work: one against sddm, one against john
Other Debian-related work
Distro-Tracker. I finally merged the work of Orestis Ioannou on bug #756766 which added the possibility to browse old news of each package.
Debian Installer. I implemented two small features that we wanted in Kali: I fixed #647405 to have a way to disable deb-src lines in generated sources.list files. I also filed #805291 to see how to allow kernel command line preseeding to override initrd preseeding the fix is trivial and it works in Kali. I just have to commit it in Debian, I was hoping to get an ack from someone in charge before doing it.
Thanks
See you next month for a new summary of my activities.
In case you are going to
32C3, you may be
interested to join us at the Debian
Assembly there.
As in the last years, this is going to be fairly informal, so if you are
loosely affiliated with Debian or want to become a member by the time 34C3
rolls around, you are more than welcome to show up and sit there.
mcd is the oldest one and the simplest. The others are just useful git management shortcuts. I can use gum to bring a feature branch back to master and gsb to show me which branches need to be rebased on master, typically after a pull. The list of excluded branches includes branches which should not be rebased against master (I could do some processing of git branch -r to not have those hardcoded) but the odd one is stale. Sometimes, I get an idea for a feature which is too intrusive, too messy or just too incomplete to be rebased against master. Rather than losing the idea or wasting time rebasing, I m getting into the habit of renaming the branch foo as stale-foo and gsb then leaves it alone. Equally, there are frequently times when I need to have a feature branch based on another feature branch, sometimes several feature branches deep. Identifying these branches and avoiding rebasing on the wrong branch is important to not waste time.
gsb takes a bit of getting used to, but basically the shorter and cleaner the output, the less work needs to be done. As shown, gsb is git show-branch under the hood. What I m looking for is multiple commits listed between a branch and master. Then I know which branches to use with gum.
Finally, gleaf shows which feature branches can be dropped with git branch -d.