Search Results: "pm"

8 December 2015

Michal Čihař: Weekly phpMyAdmin contributions

As announced earlier, I will try to publish weekly reports on contributing to the phpMyAdmin. Here comes the first one. Last week I've focused on some pain points with deploying phpMyAdmin and improved these a bit. The installation using PHP Composer is now documented. It's far from being perfect (you have to add our repository), but it seems to work fine. What was more challenging for me is Docker support. I've never really used it so far, so I had to learn some things about the filesystem layering (to avoid too big image), but now it's there. You can get the sources from GitHub, it's available on Docker Hub and of course it is covered by our documentation. Bugs fixed:

Filed under: English phpMyAdmin 0 comments

7 December 2015

Ritesh Raj Sarraf: Touchpad Gestures

If you have a modern laptop, you must be having a touchpad with multitouch capability, in hardware. But on the software front, it must be crap. And if you've always craved for having support for those multitouch gestures, you must have been following the X/Wayland development. From what I've known so far, libinput is the successor to all older input support in X/Wayland. But it does have some conditions at this time. Like: Multitouch Gesture is only available in Wayland, not in X. Similarly, if you use GNOME/Wayland, not all RandR functionalities are available in Wayland, that are there in X. So if you'll still be using X for some time, and want Touchpad Gestures, you may consider looking at: https://github.com/bulletmark/libinput-gestures For Debian, this still needs to fixed before you can use. But if you read till here, you know your way.

Categories:

Keywords:

Like:

C.J. Adams-Collier: LLC-Technologies-Collier/Demo-SCCC-Byte-AngularJS

Hello dear readers and attendees, This is the post that I will be/ will have been referencing during my presentation to the Seattle Central Community College s Byte club on Thursday, December 10th at 1500-1630. I will begin with a bit of an autobio and find out what kind of students we have in attendance. Please feel free to comment if you d like to keep in touch before or after the presentation. I will discuss some of the bits and pieces of some industry standard platforms which I ve developed, deployed, maintained, managed, co-operated, administered and replaced. We can discuss some of the patterns that work well in the industry, and some that are a bit harder to tame. Once we have touched most of the areas of specialization represented at the meeting, I will dive in to an AngularJS demo I am developing in github here: https://github.com/LLC-Technologies-Collier/Demo-SCCC-Byte-AngularJS/tree/master To follow along with the presentation, please run these commands or something similar. My development environment is Debian stable. So yes, this means that we re not doing a demo of the state of the art. But it also means that the infrastructure has been exercised under load and in production. Install Debian package dependencies First, install the debian packages of nodejs and npm, the node package manager: 
cjac@debian0:~$ sudo apt-get install nodejs nodejs-dev nodejs-legacy npm
Check out the git repository After this, check out the repository from github and create a branch for your work: 
cjac@debian0:~$ mkdir -p /usr/src/git/github/LLC-Technologies-Collier
cjac@debian0:~$ cd /usr/src/git/github/LLC-Technologies-Collier
cjac@debian0:/usr/src/git/github/LLC-Technologies-Collier$ git clone git@github.com:LLC-Technologies-Collier/Demo-SCCC-Byte-AngularJS.git
...
cjac@debian0:/usr/src/git/github/LLC-Technologies-Collier$ cd Demo-SCCC-Byte-AngularJS
cjac@debian0:.../Demo-SCCC-Byte-AngularJS$ git checkout -b $USER
Upgrade to latest npm, install deps Once we have the git repository checked out, we ll grab the latest version of npm and the rest of the node modules 
cjac@debian0:.../Demo-SCCC-Byte-AngularJS$ export PATH="$PWD/node_modules/.bin:$PATH"
cjac@debian0:.../Demo-SCCC-Byte-AngularJS$ npm install --save-exact npm@"2.1.0"
cjac@debian0:.../Demo-SCCC-Byte-AngularJS$ npm install --save-exact  cat pkgackage-list.txt
This post and the associated git repository will be updated between now and the presentation on Thursday. Please chime in and feel free to get involved! C.J.

6 December 2015

Guido G nther: Debian Fun in November 2015

Debian LTS November was the seventh month I contributed to Debian LTS under the Freexian umbrella. In total I spent ten hours working on: Other Debian stuff

Jose M. Calhariz: Taking over the development of at daemon.

I decided some time ago to take over the development of at daemon. Here is a new release of at v3.1.17 From the Changelog: 
at 3.1.17 (2015-08-31):
  Jose M Calhariz:
        at.1.in: Document behaviour when using past time, thanks Kelly Price (Closes: #639900).
        Makefile.in: On distclean remove at.allow.5, auto generated file.

4 December 2015

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:

3 December 2015

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

2 December 2015

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!

Michal Čihař: 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

1 December 2015

Michal Čihař: Time for change

It has been seven years since I've joined SUSE (for second time, but that's different story). As everything has to come to the end, I've decided to make a change in my life and leave safety net of being employed and go for new experience with freelancer life. This will give me more time to spend on free software projects where I'm involved. Of course I need to earn some money to live, so many decisions about where to spend my time will be backed by money... First of all I will work on phpMyAdmin, where I was chosen as a contractor (of two for this year). This will be half time job for me and you will see weekly reports in my blog, similar to what Madhura is doing. Second priority will be Weblate, especially the hosting solution. I believe that this is something what can work quite well in the long term, but the tool needs some development to make it as great as I would like to have it. If you want me to extend hosting for free software projects, you can do it by money :-). And nobody knows what projects come next. There is some work to be done on Gammu and Wammu, but given that I don't have any recent device to use it, it's sometimes hard to fix the bugs there. Of course this can change if I get some money to work on that. PS: It's not that SUSE would be bad place to work. It's actually pretty great if you're looking for work with free software. You work there on free software, with great people and you get quite some freedom. As bonus once or twice in a year, there is Hackweek which you can spend on anything. And of course they have lot of open positions :-).

Filed under: English Gammu phpMyAdmin SUSE Weblate 2 comments

30 November 2015

Mark Brown: Unconscious biases

Matthew Garrett s recent very good response to Eric Raymond s recent post opposing inclusiveness efforts in free software reminded me of something I ve been noticing more and more often: a very substantial proportion of the female developers I encounter working on the kernel are from non-European cultures where I (and I expect most people from western cultures) lack familiarity with the gender associations of all but the most common and familiar names. This could be happening for a lot of reasons it could be better entry paths to kernel development in those cultures (though my experience visiting companies in the relevant countries makes me question that), it could be that the sample sizes are so regrettably small that this really is just anecdote but I worry that some of what s going on is that the cultural differences are happening to mask and address some of the unconscious barriers that get thrown up.

Michal Čihař: Gammu 1.36.7

Yesterday, Gammu 1.36.7 has been released. This time the list of changes got bigger, improving compatibility with many devices: You an support further Gammu development at Bountysource salt.

Filed under: English Gammu Wammu 0 comments

Stein Magnus Jodal: November contributions

The following is a short summary of my open source work in November. My hope is that keeping better track of what I m doing will help me reflect on how I spend my time, and help me to focus my efforts better.

Debian

Mopidy
  • Released Mopidy-Spotify 2.2.0: Fixes related to duplicate Starred playlists and albums from year 0.
  • Moved Mopidy s Travis CI testing from Ubuntu 12.04 to Ubuntu 14.04, to prepare for GStreamer 1.x, and eventually testing with Python 3.4. PR #1341
  • Worked on porting Mopidy from GStreamer 0.10 to PyGI and GStreamer 1.x. PR #1339
  • Briefly looked at what remains to get Mopidy running on both Python 2.7 and 3.4+ when we ve landed the port to GStreamer 1.x. Doesn t look too bad, except that ConfigParser doesn t want to work with bytes in Python 3, so there s no easy way to read a config file referring to a path on a non-UTF-8 file system.

Comics
  • Fixed two old crawlers. Added two new crawlers.
  • Needs to upgrade to Django 1.8 before the Django 1.7 security support ends this December.

29 November 2015

Dirk Eddelbuettel: gtrends 1.3.0 now on CRAN: Google Trends in R

Sometime earlier last year, I started to help Philippe Massicotte with his gtrendsR package---which was then still "hiding" in relatively obscurity on BitBucket. I was able to assist with a few things related to internal data handling as well as package setup and package builds--but the package is really largely Philippe's. But then we both got busy, and it wasn't until this summer at the excellent useR! 2015 conference that we met and concluded that we really should finish the package. And we both remained busy... Lo and behold, following a recent transfer to this GitHub repository, we finalised a number of outstanding issues. And Philippe was even kind enough to label me a co-author. And now the package is on CRAN as of yesterday. So install.packages("gtrendsR") away and enjoy! Here is a quiick demo: 
## load the package, and if options() are set appropriately, connect
## alternatively, also run   gconnect("someuser", "somepassword")
library(gtrendsR)
## using the default connection, run a query for three terms
res <- gtrends(c("nhl", "nba", "nfl"))
## plot (in default mode) as time series
plot(res)
## plot via googeVis to browser
## highlighting regions (probably countries) and cities
plot(res, type = "region")
plot(res, type = "cities")
The time series (default) plot for this query came out as follows a couple of days ago:
Example of gtrendsR query and plot
One really nice feature of the package is the rather rich data structure. The result set for the query above is actually stored in the package and can be accessed. It contains a number of components: 
R> data(sport_trend)
R> names(sport_trend)
[1] "query"     "meta"      "trend"     "regions"   "topmetros"
[6] "cities"    "searches"  "rising"    "headers"  
R>
So not only can one look at trends, but also at regions, metropolitan areas, and cities --- even plot this easily via package googleVis which is accessed via options in the default plot method. Furthermore, related searches and rising queries may give leads to dynamics within the search. Please use the standard GitHub issue system for bug reports, suggestions and alike.

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

Matthew Garrett: What is hacker culture?

Eric Raymond, author of The Cathedral and the Bazaar (an important work describing the effectiveness of open collaboration and development), recently wrote a piece calling for "Social Justice Warriors" to be ejected from the hacker community. The primary thrust of his argument is that by calling for a removal of the "cult of meritocracy", these SJWs are attacking the central aspect of hacker culture - that the quality of code is all that matters.

This argument is simply wrong.

Eric's been involved in software development for a long time. In that time he's seen a number of significant changes. We've gone from computers being the playthings of the privileged few to being nearly ubiquitous. We've moved from the internet being something you found in universities to something you carry around in your pocket. You can now own a computer whose CPU executes only free software from the moment you press the power button. And, as Eric wrote almost 20 years ago, we've identified that the "Bazaar" model of open collaborative development works better than the "Cathedral" model of closed centralised development.

These are huge shifts in how computers are used, how available they are, how important they are in people's lives, and, as a consequence, how we develop software. It's not a surprise that the rise of Linux and the victory of the bazaar model coincided with internet access becoming more widely available. As the potential pool of developers grew larger, development methods had to be altered. It was no longer possible to insist that somebody spend a significant period of time winning the trust of the core developers before being permitted to give feedback on code. Communities had to change in order to accept these offers of work, and the communities were better for that change.

The increasing ubiquity of computing has had another outcome. People are much more aware of the role of computing in their lives. They are more likely to understand how proprietary software can restrict them, how not having the freedom to share software can impair people's lives, how not being able to involve themselves in software development means software doesn't meet their needs. The largest triumph of free software has not been amongst people from a traditional software development background - it's been the fact that we've grown our communities to include people from a huge number of different walks of life. Free software has helped bring computing to under-served populations all over the world. It's aided circumvention of censorship. It's inspired people who would never have considered software development as something they could be involved in to develop entire careers in the field. We will not win because we are better developers. We will win because our software meets the needs of many more people, needs the proprietary software industry either can not or will not satisfy. We will win because our software is shaped not only by people who have a university degree and a six figure salary in San Francisco, but because our contributors include people whose native language is spoken by so few people that proprietary operating system vendors won't support it, people who live in a heavily censored regime and rely on free software for free communication, people who rely on free software because they can't otherwise afford the tools they would need to participate in development.

In other words, we will win because free software is accessible to more of society than proprietary software. And for that to be true, it must be possible for our communities to be accessible to anybody who can contribute, regardless of their background.

Up until this point, I don't think I've made any controversial claims. In fact, I suspect that Eric would agree. He would argue that because hacker culture defines itself through the quality of contributions, the background of the contributor is irrelevant. On the internet, nobody knows that you're contributing from a basement in an active warzone, or from a refuge shelter after escaping an abusive relationship, or with the aid of assistive technology. If you can write the code, you can participate.

Of course, this kind of viewpoint is overly naive. Humans are wonderful at noticing indications of "otherness". Eric even wrote about his struggle to stop having a viscerally negative reaction to people of a particular race. This happened within the past few years, so before then we can assume that he was less aware of the issue. If Eric received a patch from someone whose name indicated membership of this group, would there have been part of his subconscious that reacted negatively? Would he have rationalised this into a more critical analysis of the patch, increasing the probability of rejection? We don't know, and it's unlikely that Eric does either.

Hacker culture has long been concerned with good design, and a core concept of good design is that code should fail safe - ie, if something unexpected happens or an assumption turns out to be untrue, the desirable outcome is the one that does least harm. A command that fails to receive a filename as an argument shouldn't assume that it should modify all files. A network transfer that fails a checksum shouldn't be permitted to overwrite the existing data. An authentication server that receives an unexpected error shouldn't default to granting access. And a development process that may be subject to unconscious bias should have processes in place that make it less likely that said bias will result in the rejection of useful contributions.

When people criticise meritocracy, they're not criticising the concept of treating contributions based on their merit. They're criticising the idea that humans are sufficiently self-aware that they will be able to identify and reject every subconscious prejudice that will affect their treatment of others. It's not a criticism of a desirable goal, it's a criticism of a flawed implementation. There's evidence that organisations that claim to embody meritocratic principles are more likely to reward men than women even when everything else is equal. The "cult of meritocracy" isn't the belief that meritocracy is a good thing, it's the belief that a project founded on meritocracy will automatically be free of bias.

Projects like the Contributor Covenant that Eric finds so objectionable exist to help create processes that (at least partially) compensate for our flaws. Review of our processes to determine whether we're making poor social decisions is just as important as review of our code to determine whether we're making poor technical decisions. Just as the bazaar overtook the cathedral by making it easier for developers to be involved, inclusive communities will overtake "pure meritocracies" because, in the long run, these communities will produce better output - not just in terms of the quality of the code, but also in terms of the ability of the project to meet the needs of a wider range of people.

The fight between the cathedral and the bazaar came from people who were outside the cathedral. Those fighting against the assumption that meritocracies work may be outside what Eric considers to be hacker culture, but they're already part of our communities, already making contributions to our projects, already bringing free software to more people than ever before. This time it's Eric building a cathedral and decrying the decadent hordes in their bazaar, Eric who's failed to notice the shift in the culture that surrounds him. And, like those who continued building their cathedrals in the 90s, it's Eric who's now irrelevant to hacker culture.

(Edited to add: for two quite different perspectives on why Eric's wrong, see Tim's and Coraline's posts)

comment count unavailable comments

24 November 2015

Carl Chenet: db2twitter: Twitter out of the browser

You have a database, a tweet pattern and wants to automatically tweet on a regular basis? No need for RSS, fancy tricks, 3rd party website to translate RSS to Twitter or whatever. Just use db2twitter. db2twitter is pretty easy to use! First define your Twitter credentials: 
screen_name_of_the_user_to_retweet=journalduhacker
consumer_key=ml9jaiBnf3pmU9uIrKNIxAr3v
consumer_secret=8Cmljklzerkhfer4hlj3ljl2hfvc123rezrfsdctpokaelzerp
access_token=213416590-jgJnrJG5gz132nzerl5zerwi0ahmnwkfJFN9nr3j
access_token_secret=3janlPMqDKlunJ4Hnr90k2bnfk3jfnwkFjeriFZERj32Z
Then your database information: 
dbconnector=mysql+mysqlconnector
dbhost=localhost
database=jobboard
dbuser=jobboard
dbpass=V3rYS3cr3t
dbtables=jobs,
jobs_rows=companyname,jobtitle,id
Then the pattern of your tweet, a Python-style formatted string: 
tweet=  hires a   https://www.linuxjobs.fr/jobs/
Add db2twitter in your crontab: 
*/10 * * * * db2witter db2twitter db2twitter.ini
And you re all set! db2twitter will generate and tweet the following tweets: 
MyGreatCompany hires a web developer https://www.linuxjobs.fr/jobs/51
CoolStartup hires a devops skilled in Docker https://www.linuxjobs.fr/jobs/52
db2twitter is developed by and run for LinuxJobs.fr, the job board of th french-speaking Free Software and Opensource community. banner-linuxjobs-small db2twitter also has cool options like; db2twitter is coded in Python 3.4, uses SQlAlchemy (see supported database types) and Tweepy. The official documentation is available on readthedocs.

Michal &#268;iha&#345;: Wammu 0.40

Yesterday, Wammu 0.40 has been released. The list of changes is not really huge: I will not make any promises for future releases (if there will be any) as the tool is not really in active development.

Filed under: English Gammu Wammu 0 comments

23 November 2015

Riku Voipio: Using ser2net for serial access.

Is your table a mess of wires? Do you have multiple devices connected via serial and can't remember which is /dev/ttyUSBX is connected to what board? Unless you are a embedded developer, you are unlikely to deal with serial much anymore - In that case you can just jump to the next post in your news feed. Introducting ser2netUsually people start with minicom for serial access. There are better tools - picocom, screen, etc. But to easily map multiple serial ports, use ser2net. Ser2net makes serial ports available over telnet. Persistent usb device names and ser2netTo remember which usb-serial adapter is connected to what, we use the /dev/serial tree created by udev, in /etc/ser2net.conf: 

# arndale
7004:telnet:0:'/dev/serial/by-path/pci-0000:00:1d.0-usb-0:1.8.1:1.0-port0':115200 8DATABITS NONE 1STOPBIT
# cubox
7005:telnet:0:/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0:115200 8DATABITS NONE 1STOPBIT
# sonic-screwdriver
7006:telnet:0:/dev/serial/by-id/usb-FTDI_FT230X_96Boards_Console_DAZ0KA02-if00-port0:115200 8DATABITS NONE 1STOPBIT
The by-path syntax is needed, if you have many identical usb-to-serial adapters. In that case a Patch from BTS is needed to support quoting in serial path. Ser2net doesn't seems very actively maintained upstream - a sure sign that project is stagnant is a homepage still at sourceforge.net... This patch among other interesting features can be also be found in various ser2net forks in github. Setting easy to remember names Finally, unless you want to memorize the port numbers, set TCP port to name mappings in /etc/services: 

# Local services
arndale            7004/tcp
cubox              7005/tcp
sonic-screwdriver  7006/tcp
Now finally: 
telnet localhost sonic-screwdriver
^Mandatory picture of serial port connection in action

Lunar: Reproducible builds: week 30 in Stretch cycle

What happened in the reproducible builds effort this week: Toolchain fixes Mattia Rizzolo uploaded a version of perl to the reproducible repository including the patch written by Niko Tyni to add support for SOURCE_DATE_EPOCH in Pod::Man. Dhole sent an updated version of his patch adding support for SOURCE_DATE_EPOCH in GCC to the upstream mailing list. Several comments have been made in response which have been quickly addressed by Dhole. Dhole also forwarded his patch adding support for SOURCE_DATE_EPOCH in libxslt upstream. Packages fixed The following packages have become reproducible due to changes in their build dependencies: antlr3/3.5.2-3, clusterssh, cme, libdatetime-set-perl, libgraphviz-perl, liblingua-translit-perl, libparse-cpan-packages-perl, libsgmls-perl, license-reconcile, maven-bundle-plugin/2.4.0-2, siggen, stunnel4, systemd, x11proto-kb. The following packages became reproducible after getting fixed: Some uploads fixed some reproducibility issues, but not all of them: reproducible.debian.net Vagrant Cascadian has set up a new armhf node using a Raspberry Pi 2. It should soon be added to the Jenkins infrastructure. diffoscope development diffoscope version 42 was release on November 20th. It adds a missing dependency on python3-pkg-resources and to prevent similar regression another autopkgtest to ensure that the command line is functional when Recommends are not installed. Two more encoding related problems have been fixed (#804061, #805418). A missing Build-Depends has also been added on binutils-multiarch to make the test suite pass on architectures other than amd64. Package reviews 180 reviews have been removed, 268 added and 59 updated this week. 70 new fail to build from source bugs have been reported by Chris West, Chris Lamb and Niko Tyni. New issue this week: randomness_in_ocaml_preprocessed_files. Misc. Jim MacArthur started to work on a system to rebuild and compare packages built on reproducible.debian.net using .buildinfo and snapshot.debian.org. On December 1-3rd 2015, a meeting of about 40 participants from 18 different free software projects will be held in Athens, Greece with the intent of improving the collaboration between projects, helping new efforts to be started, and brainstorming on end-user aspects of reproducible builds.

Thomas Goirand: OpenStack Liberty and Debian

Long over due post It s been a long time I haven t written here. And lots of things happened in the OpenStack planet. As a full time employee with the mission to package OpenStack in Debian, it feels like it is kind of my duty to tell everyone about what s going on. Liberty is out, uploaded to Debian Since my last post, OpenStack Liberty, the 12th release of OpenStack, was released. In late August, Debian was the first platform which included Liberty, as I proudly outran both RDO and Canonical. So I was the first to make the announcement that Liberty passed most of the Tempest tests with the beta 3 release of Liberty (the Beta 3 is always kind of the first pre-release, as this is when feature freeze happens). Though I never made the announcement that Liberty final was uploaded to Debian, it was done just a single day after the official release. Before the release, all of Liberty was living in Debian Experimental. Following the upload of the final packages in Experimental, I uploaded all of it to Sid. This represented 102 packages, so it took me about 3 days to do it all. Tokyo summit I had the pleasure to be in Tokyo for the Mitaka summit. I was very pleased with the cross-project sessions during the first day. Lots of these sessions were very interesting for me. In fact, I wish I could have attended them all, but of course, I can t split myself in 3 to follow all of the 3 tracks. Then there was the 2 sessions about Debian packaging on upstream OpenStack infra. The goal is to setup the OpenStack upstream infrastructure to allow packaging using Gerrit, and gating each git commit using the usual tools: building the package and checking there s no FTBFS, running checks like lintian, piuparts and such. I knew already the overview of what was needed to make it happen. What I didn t know was the implementation details, which I hoped we could figure out during the 1:30 slot. Unfortunately, this didn t happen as I expected, and we discussed more general things than I wished. I was told that just reading the docs from the infra team was enough, but in reality, it was not. What currently needs to happen is building a Debian based image, using disk-image-builder, which would include the usual tools to build packages: git-buildpackage, sbuild, and so on. I m still stuck at this stage, which would be trivial if I knew a bit more about how upstream infra works, since I already know how to setup all of that on a local machine. I ve been told by Monty Tailor that he would help. Though he s always a very busy man, and to date, he still didn t find enough time to give me a hand. Nobody replied to my request for help in the openstack-dev list either. Hopefully, with a bit of insistence, someone will help. Keystone migration to Testing (aka: Debian Stretch) blocked by python-repoze.who Absolutely all of OpenStack Liberty, as of today, has migrated to Stretch. All? No. Keystone is blocked by a chain of dependency. Keystone depends on python-pysaml2, itself blocked by python-repoze.who. The later, I upgraded it to version 2.2. Though python-repoze.what depends on version <= 1.9, which is blocking the migration. Since python-repoze.who-plugins, python-repoze.what and python-repoze.what-plugins aren t used by any package anymore, I asked for them to be removed from Debian (see #805407). Until this request is processed by the FTP masters, Keystone, which is the most important piece of OpenStack (it does the authentication) will be blocked for migration to Stretch. New OpenStack server packages available On my presentation at Debconf 15, I quickly introduced new services which were released upstream. I have since packaged them all: Congress, unfortunately, was not accepted to Sid yet, because of some licensing issues, especially with the doc of python-pulp. I will correct this (remove the non-free files) and reattempt an upload. I hope to make them all available in jessie-backports (see below). For the previous release of OpenStack (ie: Kilo), I skipped the uploads of services which I thought were not really critical (like Ironic, Designate and more). But from the feedback of users, they would really like to have them all available. So this time, I will upload them all to the official jessie-backports repository. Keystone v3 support For those who don t know about it, Keystone API v3 means that, on top of the users and tenant, there s a new entity called a domain . All of the Liberty is now coming with Keystone v3 support. This includes the automated Keystone catalog registration done using debconf for all *-api packages. As much as I could tell by running tempest on my CI, everything still works pretty well. In fact, Liberty is, to my experience, the first release of OpenStack to support Keystone API v3. Uploading Liberty to jessie-backports I have rebuilt all of Liberty for jessie-backports on my laptop using sbuild. This is more than 150 packages (166 packages currently). It took me about 3 days to rebuild them all, including unit tests run at build time. As soon as #805407 is closed by the FTP masters, all what s remaining will be available in Stretch (mostly Keystone), and the upload will be possible. As there will be a lot of NEW packages (from the point of view of backports), I do expect that the approval will take some time. Also, I have to warn the original maintainers of the packages that I don t maintain (for example, those maintained within the DPMT), that because of the big number of packages, I will not be able to process the usual communication to tell that I m uploading to backports. However, here s the list of package. If you see one that you maintain, and that you wish to upload the backport by yourself, please let me know. Here s the list of packages, hopefully, exhaustive, that I will upload to jessie-backports, and that I don t maintain myself: alabaster contextlib2 kazoo python-cachetools python-cffi python-cliff python-crank python-ddt python-docker python-eventlet python-git python-gitdb python-hypothesis python-ldap3 python-mock python-mysqldb python-pathlib python-repoze.who python-setuptools python-smmap python-unicodecsv python-urllib3 requests routes ryu sphinx sqlalchemy turbogears2 unittest2 zzzeeksphinx. More than ever, I wish I could just upload these to a PPA^W Bikeshed, to minimize the disruption for both the backports FTP masters, other maintainers, and our OpenStack users. Hopefully, Bikesheds will be available soon. I am sorry to give that much approval work to the backports FTP masters, however, using the latest stable system with the latest release, is what most OpenStack users really want to do. All other major distributions have specific repositories too (ie: RDO for CentOS / Red Hat, and cloud archive for Ubuntu), and stable-backports is currently the only place where I can upload support for the Stable release. Debian listed as supported distribution on openstack.org Good news! If you go at http://www.openstack.org/marketplace/distros/ you will see a list of supported distributions. I am proud to be able to tell that, after 6 months of lobbying from my side, Debian is also listed there. The process of having Debian there included talking with folks from the OpenStack foundation, and having Bdale to sign an agreement so that the Debian logo could be reproduced on openstack.org. Thanks to Bdale Garbee, Neil McGovern, Jonathan Brice, and Danny Carreno, without who this wouldn t have happen.

Next.

Previous.