Like you most likely know, I've been at the openSUSE Conference last week. I've been representing Debian through a talk about Debian - The Project and its Resources, covering services and resources that are usable and useful for other distributions too. The invitation to submit talks were sent to various projects and distributions because of the set topic on Collaboration across Borders for the conference. My impression was that very few distributions have followed the invitation, I am only aware of some Fedora people that have attended. Vincent Untz from GNOME gave a combined keynote with Cornelius Schumacher from KDE.
The abstract of my talk and the slides are available from the conference website. The talk was well received and interested people also asked about some of the services like how our buildd network works, or whether the screenshots service has support for localized images too, or if it would be expandable for more general usage of non-Debian based distributions.
One topic raised was with respect to the whohas tool: A mapping layer/tool/database for package names. We divert from upstream naming schemes for consistency reasons, like with our library, Perl and Python naming schemes. Other distributions have similar approaches but a different naming scheme. To make inter-distribution tools really useful it would require to have some layer that is able to map the package name from one distribution to another one. One idea for it that was thrown in was to use upstream homepage, but not all packages do have proper homepages, some only live in some git repository, others would either like to link to sourceforge's project page instead of the project's homepage, and other tricky issues. Something unique is clearly called for here and needed to get stored in the package's metadata.
Apart from my talk and the occasional mentioning of openSUSE is on my desktop, but I run Debian on my server I noticed that the beverage of openSUSE is their own beer. Taste is a tough topic, personally I rather prefer our Debian wine. And I missed the chance to seduce them into playing Mao, I forgot to bring playing cards along. I hope to get a second chance at anoter event.
Within the next few days there will be the openSUSE conference held in Nuremberg/Germany. The topic of the conference was set to Collaboration Across Borders and along that theme they invited other distributions to submit talks. Given my involvement with the Derivatives Frontdeskzack asked me whether I'd like to submit a talk proposal. I usually have a hard time to refuse such questions this will actually happen.
My talk will be in the Distributions Track on Thursday afternoon, the topic is Debian—The Project and its Resources. The resources that I will cover are those that can be very useful to other distributions too, and last Thursday I tested the talk at our local Debienna Meeting, gathered further ideas and feedback to cover in the talk. Thanks to you, guys!
Unfortunately contrary to what we are used to in Debian (extraordinary thanks to the Video Team!!!) there will be no streaming or recording of the talks from what I was told, so you have either to hurry to be there, or be satisfied with the slides I'll put up after the talk. It's the best I can offer.
I wrote the following as a foreword for the great German book Open Source Projektmanagement that Michael Prokop wrote. Unfortunately the foreword didn't manage it in time into the book because of various circumstances. As I'm not a person to throw away already written material, here is it for your reading pleasure. Maybe it makes you consider obtaining a copy of the German language book for yourself!
The Whole is more than the Sum of the Parts
When I first met Mika at a Linux conference some years ago I quickly noticed that he had potential. The way he asked questions and tackled issues did impress me. We did meet again at various events, joined forces in various projects and knew that the result would be good.
Back in the year 2004 the only real live CD was Knoppix. It always was too sluggish for me because I never really liked KDE and also OpenOffice.org was too bloated for me. I was working since a year at an Internet provider, felt comfortable in the shell and was missing the tools on Knoppix which I used daily.
Often enough the frustration with the status quo starts the best projects. And so I had the idea spinning around to start a sysadmin live CD. There was just one problem here: Exactly at the same time Mika had already started such a project. And I knew one thing: it would had been a lost race to compete with him in creating the better live CD. So I joined his team and helped with the best of my knowledge. The name choice alone showed that he was the right person for the job: Grml—an expression of the frustration that even he felt which spoke directly to the heart of so many.
But it wasn't just the chosen name that showed that Mika was the right person for the job of the project leader. It's always the sum of the parts, no matter how minor they might look. He quickly managed a first release and in light of that also created an event which was fitting for the release of the first version: the OS04—an Open Source event which managed to get Jon Maddog Hall as keynote speaker.
Mika managed through his welcoming way to lure more people into helping out. The team grew over the years, further regular releases increased the fan base, not only through the creative release names—which are surely one of the parts that helped create the success. He always was open to suggestions for new tools that helped to extend the project.
The lived openness did lead among other things to the case that other live CDs started to use the grml build system. JUXlala 2.0 (the system for preschool kids) is just one example.
Why do I write primarily about Grml, one could get subliminal advertising probably cheaper? I do it because Grml is an extremely good example of the experience revealed in this book. And even though every project is different, it is still exactly the sum of the parts that leads to the success of a project. And exactly these parts are covered in this book—and can be considered for the project at hand and get implemented accordingly.
People start to wonder why the timeouts for the passwords in sudo seem to be so short recently in squeeze. The reason is a change in the defaults that causes it. The following option changed its default:
tty_tickets
If set, users must authenticate on a per-tty basis. Normally, sudo uses a directory in the ticket dir with the same name as the user running it. With this flag enabled, sudo will use a file named for the tty the user is logged in on in that directory. This flag is on by default.
To change it back you can add this line into your sudoers file:
Defaults !tty_tickets
Please be aware that the change in default is done because of security considerations. You might not always have all the ttys you are logged in directly visible and others might be able to access them (like, sudo on a remote SSH session). Use with caution, you though might consider disabling it on local systems with no remote users.
Hope that helps! Actually this blog post was triggered by a question on ask.debian.net, a new service in the Debian eco system.
The Backports Team is pleased to announce the availability of a new suite on backports: lenny-backports-sloppy. Please read carefully before considering using or uploading to it what this entails.
The Background
You might want to ask: What's that? Let me explain it. During the etch release discussions popped up on the backports list with two clashing groups:
One that expected to always be able to upgrade from sarge + sarge-backports to etch without backports,
others that wanted new versions of packages flowing in even after the release and were happy to upgrade from sarge + sarge-backports to etch + etch-backports.
The standing at that time was to accept packages that were in testing after the release, which wasn't etch anymore but lenny.
The same discussion started again before the lenny release, and given that we are facing the upcoming squeeze release we started internally to discuss how to noise down these long and tedious discussions, because both groups of people had valid opinions that shouldn't get ignored. So this is where the idea for lenny-backports-sloppy comes from.
The Change
lenny-backports-sloppy will please the group that is happy to upgrade from lenny + lenny-backports to squeeze + squeeze-backports. lenny-backports is meant only for packages from squeeze, even after the release. Technically that means it will get locked down for uploads after the release of squeeze and require manual approval (for e.g. point release update versions, or security updates that happen during the squeeze release cycle), while lenny-backports-sloppy will accept packages from wheezy. Uploading to lenny-backports will have to get approved by the Debian Backports Team after the squeeze release, just like uploads to lenny are currently approved by the Release Team.
While lenny-backports-sloppy is created already and working we ask you to not upload packages there without prior discussion with the Backports Team. This is meant to ensure that the Uploader is aware about the expectations that come along with that: The package should have a good chance to get included in the next Debian release aka wheezy, and that the Uploader is willing to look after the package in the upcoming squeeze-backports suite after the release of squeeze to ensure upgradability.
We are also pleased to announce that the first upload to lenny-backports-sloppy already happened. From now on you will be able to install Postgresql 9.0 (which is not targeted at squeeze) from lenny-backports-sloppy.
How to use
If you want to use lenny-backports-sloppy you will have to add both lenny-backports and lenny-backports-sloppy to your sources.list. Backports from lenny-backports-sloppy may depend on packages in lenny-backports.
deb http://backports.debian.org/debian-backports lenny-backports main
deb http://backports.debian.org/debian-backports lenny-backports-sloppy main
About Backports
You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in.
Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. It is recommended to pick out single backports which fit your needs, and not to use all available backports.
Thanks for reading this far, and enjoy!
Rhonda in the name of the Backports Team
![[rss feed]](/pics/logo-xml.png){kind=logo}
![[html by vim]](/pics/logo-vim.png){kind=logo}
![[graphics by gimp]](/pics/logo-gimp.png){kind=logo}
![[generated by wml]](/pics/logo-wml.png){kind=logo}
![[powered by blosxom]](/pics/logo-blosxom.png){kind=logo}