Mostly posting this to remind myself of the fix the next time I run into this but htis might help some other people as well.
Every once in a while I’ll be working on a git repo in the fedora packages repository and when I
git commit -a it, I’ll end up with an empty commit and the files with changes aren’t actually committed. Other intuitive variations of this like
git add FILE && git commit have the same buggy behaviour.
The reason this is occurring has something to do with the GitPython library which is used by fedpkg to add some changes to your clone of the git repo when you add new source files. It’s somehow changing the index in a way that causes this behaviour. To get out of this there’s a few simple but non-intuitive things you can try:
git reset FILE && git add FILE
git stash && git stash pop
After running one of those pairs of commands you should once more be able to
git commit -a.
Details in this GitPython bug report
Over a year ago I mentioned that the code that rsync needed in order to start using vanilla zlib was finally on its way to being merged. And today, we’ve finally built an rsync package that completes that saga.
All packed up and waiting for my plane to Raleigh. Going there to work on enabling two-factor authentication for the hosts that give shell access inside of Fedora’s Infrastructure. For the first round, I think we’re planning on going for simple and minimal to show what we can do. Briefly, the simplest and minimalist is:
* Server to verify a one time password (we already have one for yubikeys)
* CGI to take a username, password, and otp to verify in fas and the otp server
* pam module for sudo that verifies the user via the cgi
* database to store the secret keys for the otp generation and associate them with the fas username
We’re hoping to go a little beyond the minimal at the FAD:
* Have a web frontend to configure the secret keys that are stored for an account.
* Presently we’re thinking that this is a FAS frontend but we may end up re-evaluating this depending on what we decide to do for web apps and what to require for changing an auth source.
* Allow both yubikey and google-authenticator as otp
I’m also hoping that since we’ll have most of the sysadmin side of infrastructure present that we’ll get a chance to discuss and write down a few OTP policies for the future:
* Do we want to make two-factor optional for some people and required for others?
* How many auth sources do we require in order to change a separate auth source (email address, password, secret for otp generation, phone number, gpg key, etc)?
If we manage to get through all of that work, there’s a few other things we could work on as well:
* Design and implement OTP for our web apps
Congratulations and many thanks to everyone who was involved in the effort to unbundle zlib from rsync! Looks like this long standing bug that’s been a sore spot for many distributions is finally being addressed. It almost makes me want to create a Fedora 18 Feature page for it
This is something I’ve been noticing for a while and am finally getting around to blogging.
In the first days of FESCo, Thorsten Leemhuis was the chairman. One of the quirks of his time was that we’d encounter a topic where we voted on a solution and found that a majority agreed with one sentiment but it wasn’t unanimous. When that happened, Thorsten would be sure to ask if there was anything we could do to make the solution more acceptable to the dissenters even if they still wouldn’t vote for the proposal.
This sometimes lead to discussions of a proposal that had been approved with margins like 7 to 2 and after the discussion and changes, the vote was still 7 to 2. So from an external standpoint, this might be seen as unproductive. Why don’t we just get a decision made and move on?
But over the years I’ve watched a lot of other split decisions be made on several committees from both the inside and the outside and it’s struck me that, perhaps, we don’t do nearly enough of this sort of examination. Making changes after it was clear that a majority agreed with the basic proposal had several beneficial effects:
- It made the proposals more palatable to more people by getting rid of at least some issues that had made their way in to the final drafts.
- It forced dissenters to figure out what specific things they wanted to be changed in the proposal rather than simply being able to say “I hate this whole thing”.
- It made more people a part of the decision– whether or not they voted for it, if some of their ideas were in it, they felt some ownership for having help craft it.
- And perhaps most importantly, it let everyone know that the door of communication still worked. People found that their ideas were still valued by the other members even if they didn’t agree with each other on the overall picture.
So what can we do with this? Maybe it’s too much to ask that we look over every little decision we make where there’s disagreement and attempt to find every last bit of common ground that we can (There were certainly times when it seemed to take forever to make a decision) but what about decisions that are close votes? What about decisions that have days-long threads as part of their backstory? In these cases, consider the proposal that the majority agrees on to be a strawman. A starting point from which to start chipping away to see what changes can be made that are still acceptable to the majority while addressing many of the issues that the minority has. Remember that the goal is to craft a compromise that addresses as many concerns as possible.
We’ve just deployed a new Fedora Account System to production. This release just pulls a few new features that didn’t quite make the 0.8.10 release:
- Ian Cole (icole) Added a feature to allow for email address to be used instead of login name for logging in. Because of the way we do authentication, this means that email addresses can also be used on the other applications on admin.fedoraproject.org as well.
- Pierre-Yves Chibon (pingou) Implemented an audio captcha for people signing up for a new account. It generates a wav file that gets downloaded to your computer that you can listen to and then type in the proper answer to the captcha.
- Adam M. Dutko (addutko) Standardized some of the errors that can be returned from our JSON API.
- Our translation team pointed out a few areas where we weren’t loading translations correctly and I fixed them. Look forward to more complete translations in the future.
That’s it for this minor update.
/me goes to play with the audio captcha some more.
Are you on IRC? Are you at FUDCon? Do you have a project that you want to happen in Fedora?
The Fedora Board is working on choosing goals that each individual member wants to champion and bring to fruition this year in Fedora. So if you have some idea that you think a Board member’s help will make work better, grab your nearest Board member[*] and ask them to bring it up on their Sunday meeting. One of them may take it up as something they think they can work on and help accomplish in the coming year.
[*] Board members you may see wandering around at FUDCon:
- Jared Smith
- Toshio Kuratomi
- David Nalley
- Peter Robinson
- Jon Stanley
- Christoph Wickert
I’ve just added a new activity to the FUDCon Blacksburg page, a Try my keyboard! event. This is for people who realize that they spend hours and hours of their day typing into a keyboard, clicking with their mouse, drawing with their graphics tablet and… they love it! If you have a favorite keyboard, mouse, trackball, etc that you would like to give other people the chance to try out for an hour or so, consider bringing it to FUDCon Blacksburg. We’ll organize a space for people to get some hands on feel for the hardware you bring, let you talk about what makes it special, and let you interact with other people as crazy about the way their computer keyboard/trackball/input device feels as you do!
If you are going to be bringing some hardware for people to touch to the event, consider adding it to the activity’s page so that I know it won’t just be me and a couple keyboards in there
The past few weeks I’ve been coordinating a new release of the Fedora Account System(FAS). Since FAS is something used within Fedora but not a whole lot of other places, development is usually driven by a relatively small handful of people: Ricky Zhou, Mike Mcgrath, and I. This release saw a large number of other contributors which has been very good as the three of us have been increasingly pulled into other projects so our time for FAS has steadily decreased.
- Adam M. Dutko fixed several long standing bugs and feature requests
- Luis Bazán updated several pieces of the UI
- Sijis Aviles switched us from signing the CLA to the new FPCA
- Pierre-Yves Chibon created a new captcha to replace the universally hated one that we were employing
- Jun Chen added a means to clear a user’s ssh key
- Nick Bebout started the work of removing copyright phrase-ology that we no longer want to use (“All rights reserved”) and tracking down which people needed to agree that we could switch licenses from GPLv2-only to GPLv2-or-later
- Jim Lieb contributed code to make handling of languages easier and made FAS more configurable for use in other sites.
- and for the first time in several releases we coordinated our release with the Fedora Translation Team on transifex so that the translations they contributed could go out with the first release instead of when a subsequent bugfix was released.
So let’s take a brief tour of some of these new features.
Although we’ve been using transifex to manage translations for FAS for a while now, I hadn’t really understood how to leverage the full power of the Fedora Translation Team to get translations. Thanks to some prodding by pingou, I got in touch with the translation team this time around and arranged for a string freeze before release during which they worked hard to translate FAS into their native languages. Thanks to transifex, I can show you this nice graph of their hard work:
Top translations: fas » faspot Full graph of translation stats
Clearing SSH Keys
When Fedora Infrastructure recently made the decision to invalidate public ssh keys because we had no way to tell which users might have hosted their ssh private keys on other projects servers which had been attacked and infiltrated, one of the options was for a user who didn’t actually need to use ssh to simply remove their ssh. Unfortunately, the web interface didn’t include the ability to do that so user’s who wanted to go this route had to contact one of the admins and have them remove it for them manually. Thanks to Jun Chen, users can now perform this step for themselves:
There have always been many times more accounts in FAS than there were active contributors to Fedora. In itself, this wasn’t a problem. However, at some point, spammers started signing their bots up for Fedora accounts as they found that with that, they could write to the Fedora Wiki. To combat this, we added a captcha to the signup process. However, we quickly found that the captcha we added was too hard. Many people came to us to complain that they could not answer the captcha successfully. Thanks to pingou, we have a new captcha which displays a simple math equation in a much less distorted image. Writing the correct answer to the equation is all you need to do.
These are just some of the more user visible changes. If you’re interested in the more behind the scenes changes (SELinux fixes from ricky, password strength checking, and more), check out the changes in FAS’s git repository.
Fedora Infrastructure was an early adopter of the Turbogears web framework. As such, we have a large number of applications that were built targeting the TurboGears-1.0.x/1.1.x release series. Unfortunately, while the upstream TurboGears project has released new features, optimizations, and other enhancements, this work has had to be done in new releases which aren’t backwards compatible with TurboGears-1.1.x. So we’ve been faced with the task of porting our apps to the newer releases for some time… and proven remarkably success at procrastinating on that :-).
Well, thanks to the efforts of pingou we’re starting to take steps to fix that. He’s gone through the Fedora Elections application and ported it to TurboGears2.x. This is a great step that shows that there’s no blockers to getting all our apps running with TG2 (our custom auth layer was a big worry before this work was done.)
We still have four more applications to port that are more complex than elections but now we have some experience to show what needs to be done. Having an idea of what we’re in for is great for breaking through the mental reservations about starting the process.
If you see pingou online, be sure to thank him for a job well done!