Search Results: "ag"

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

Norbert Preining: My unconscious bias

Here is my unconscious bias, probably only one of it, though. all-taste-the-same Thanks to ANTIFA on Facebook.

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.

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.

Vincent Sanders: HTTP to screen

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.

Rapha&#235;l Hertzog: My Free Software Activities in November 2015

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: 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 Vuillemin, Juliette Belin and Rapha l HertzogFran 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 12 copies 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.

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

Simon Richter: Debian at the 32C3

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.

30 November 2015

Lunar: Reproducible builds: week 31 in Stretch cycle

What happened in the reproducible builds effort this week: Toolchain fixes Reiner Herrmann submitted a patch against debhelper to make dh_installinit source files in a stable order. Chris Lamb found how to make cython output deterministic by ordering the keys used to traverse a dict. Reiner Herrmann proposed a patch for pyside-tools to remove the timestamps embedded by rcc in the generated Python code. Mattia Rizzolo rebased our custom version of debhelper on version 9.20151126. As no objections have been made so far, Mattia Rizzolo has filled #805872 asking -Wdate-time to be turned on by default in dpkg-buildflag. Guillem has since sent a final warning before proceeding as such in the next dpkg upload. Russ Allbery added support for SOURCE_DATE_EPOCH in podlators 4.00 which Niko Tyni intend to backport to Perl 5.22. Packages fixed The following packages have become reproducible due to changes in their build dependencies: fontforge, golang-github-tinylib-msgp, libpango-perl, libparanamer-java, libxaw, sqljet, stringtemplate4, uzbl, zope-mysqlda. The following packages became reproducible after getting fixed: Some uploads fixed some reproducibility issues, but not all of them: Patches submitted which have not made their way to the archive yet: Lunar reported two issues making xz-utils unreproducible (#806328, #806331). reproducible.debian.net A seventh armhf build node has been added (resulting of two more armhf build jobs). Thanks to Vagrant Cascadian for putting this Raspberry Pi 2B to help. (h01ger) jenkins.debian.net has been made more robust against network and proxy failures. (h01ger) A new 100 GB partition has been set up on reproducible.debian.net to prevent disk space issues. Thanks to ProfitBricks for its continuous support to our continuous test system. (h01ger) New graphs showing usertagged bugs have been added on the dashboard to measure the progress without FTBFS issues. Please note that comparing the two graphs might be misleading as more than 1300 FTBFS bugs have been inventoried. (h01ger) Package reviews 78 reviews have been removed, 116 added and 49 updated this week. 25 new FTBFS have been filed by Chris West, Chris Lamb and Santiago Vila. New issues identified this week: timestamps_in_documentation_generated_with_libwibble, copyright_year_in_documentation_generated_by_sphinx, timestamps_in_documentation_generated_by_glib_genpod, random_order_of_tmpfiles_in_postinst, random_order_in_cython_output, timestamps_in_python_code_generated_by_pyside. Reiner Herrmann and Lunar improved the prebuilder script: the script can now be called through a symlink, run parallel builds, calls diffoscope by its new name and ensure to install its recommends, and save the text output aside the HTML one. Reiner also added a script to lookup the last update of notes for a given package. Misc. Santiago Villa has been recently working on making sure that Arch:all packages were properly buildable by running dpkg-buildpackage -A. This uncovered a question that is probably not currently addressed by the policy: on which architectures should architecture-independent be buildable?

Neil Williams: bashrc-git snippets

Just in case someone else finds these useful, some bash functions I ve got into the habit of having in ~/.bashrc:
mcd()  mkdir "$1"; cd "$1";  
gum()  git checkout "$1" && git rebase master && git checkout master;  
gsb()   LIST= git branch egrep -v '(release staging trusty playground stale)' tr '\n' ' ' tr -d '*' ; git show-branch $LIST;  
gleaf()  git branch --merged master   egrep -v '(release staging trusty playground pipeline review stale)';  
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.

Next.

Previous.