The first good excuse is the addition of a new member to our team.
Everybody please send your condolences to Luca Falavigna, dktrkranz.
He joined us a while ago as a trainee and is now an FTP Assistant.

And while I have your attention, let me tell you that we need your help!

I’m starting with a call for volunteers but will follow it with a (kind
of) todo list which interested people can work on. And, while some of the
jobs can only be done by team members, many can be done without joining
the team, and a few can even be worked on by people who aren’t Debian
Developers (yet).

If you are interested feel free to contact us at ftpmaster@debian.org!

Of course, as with any team, a few points you should think about (not
all apply for all tasks, of course):

– You need to be able to deal with all the existing team members.
(And they with you).

– You need to be able to deal with sometimes unpopular decisions. People
do not always like it when you reject a package, but that is no reason
to allow bad ones in. If you can’t stand a bit of flames / don’t like
to take hard decisions, this is no job for you. (But look out for the
other possibilities ).

– You must love to read and deal with legal texts, like licenses and
their effect on the package in Debian. The ftpteam is *the* one place
to decide if something is ok for Debian to distribute or not, and you
will have to take this decision.

– You need a very good understanding of the archive, how packaging works,
know qa processes and the general way things are dealt with in
Debian. This job will throw you right in the middle of all this.
You have to know the basics of just about every programming language
you can imagine (and all those you can’t but that are still there),
of all the different packaging systems people use. NEW will present
all of them and more stuff you never heard about and you need to be
able to dig through it, searching for possible bad things.

– You should be able to read and write python. At least if you want to
understand the code behind our archive, or even want to help
maintaining it.

————————————————————————

So of course the one task that is seen by most people, and as such is
mentioned first, is NEW processing. (You have to be a DD for this!)
The current team of assistants is doing a very good job keeping the
process running; packages usually pass NEW in a very short time. Of
course there are always exceptions, not all packages are simple, but
overall they just rock!

Debian is not getting smaller and the NEW queue is a kind of Sisyphean
task – uploads that want to get processed never stop. As such, more
manpower to spread the load is very much wanted, the more, the better
(to a limit, but we aren’t at that limit yet).

What will happen when you decide to volunteer for NEW (and rm) processing?

Simple: You get added to our ftptrainee group. This got setup some while
ago and is a simple but effective way to let you find out if this is
work you actually want to commit to and at the same time enables us to
see you working and help you learn the rules we have in NEW. The way
this setup works is simply letting trainees access the ftpmaster machine
and the NEW queue. You can look at packages and their source as any other
team member. But trainees can not do the actual ACCEPT or REJECT. Instead
you have a special ability to leave notes about the packages, explaining
what action you would take and why. The other team members will then
review those notes and either follow your advice or tell you why they
decided to do something different.

After a while we and you will know if you actually fit the team, but
more important we (and you yourself) will know if you should (want to)
continue doing NEW and will promote you up to assistant. We set ourself
a time limit of 6 months as a maximum stay in the trainee group, but
none of the current team members has ever stayed in trainee that long.
The longest is 3 months, the shortest is 6 days.

————————————————————————

Another good way helping the ftpteam is – by not joining us! Yvan eht
Nioj! (Or for people not watching Simpsons: Join the Navy!)
Err, no, of course not, but: Join the QA team!

There is a lot of work commonly associated to the QA group but not many
people doing it. You could help out there, which in turn will help us
again.

————————————————————————

Do various coding work. This is the one point where even non-Debian
Developers can help (in many cases). Some cases of course need Developer
status at least, but not all of them.

We have a lot of open todo points, presenting them all here would probably
only get this mail rejected due to its size, so I will randomly select
a few. If you happen to have something of your own that really really
needs to get into dak, fine, speak up, im open.

First: Our git is at (http and https, both work)

http://ftp-master.debian.org/git/dak.git/

and the list associated with it is

http://lists.debian.org/debian-dak/

and our IRC channel for development is #debian-dak on irc.debian.org.

As our code is mainly python with a few shell and perl additions, you
should be familiar with python. We are using sqlalchemy for database
access, so knowledge there does not hurt. And if coding needs changes
to the database schema, SQL is very helpful, so you should have basic
knowledge there as well.

- Improve our testsuite.
This is a task that can be done even if you are not a Debian Developer
yet. Our code has a good start at a test suite already since our
ftpmaster meeting in Essen, but this can surely be extended a lot.

- General code cleanup.
Every codebase that is as old as dak now is loves people cleaning up.
Have fun.

- Contents files, Packages files
For quite a while we have been working on changing the way we create
and update our Contents files. And when this is done the generation of
Packages/Sources files should follow suit. Basically, this will move
the extraction of the data for Contents (and then Packages/Sources)
files from the few dinstall runs we have per day over to the many many
upload processing runs we have per day. And dinstall will only write
out the pre generated data from our database.

Due to some issues not related to the ftpteam, the person who was
mainly working on this task is not available to do it, so someone
should take over. Much of the work for the contents part is done, it
mainly needs testing and final integration. The Packages/Sources part
that follows will work on top of this later on.

- Autosigning
There are plans to allow buildds to automatically sign packages. There
already have been discussions between the buildd folks, DSA and
ftpmaster how this can work out (DSAed buildds, certain firewall and
access restrictions, special keyrings, special upload queues), but the
details aren’t very interesting for this mail. Just – we need a little
work on the archive side to make it work. Much is, again, already
prepared, the patchset developed during our Essen meeting allows
certain restrictions we have to use. But there are still a few things
to be thought over and written, and here you (as a DD, sorry, needs
.debian.org host access I think) can help.

- Throw away DD uploaded .debs.
The initial dependency of this task, having lintian based automated
rejects, is in use for some time now, so we can do the final steps for
this task now. This needs a bit of work, from the top of my head:
– Needs a way to define a build-architecture for arch: all debs. Some
of them can only build on certain architectures. Maybe a control file
header.
– Needs a way to define exceptions. Both, based on suites (we do not
want to throw away security uploads to stable!) and maybe also per
package or per gpg key.

- debianqueued seriously needs a replacement.
This is the perl monster that every uploader knows. It is the tool
that forwards uploads to localhost, after you put them up with ftp. It
is really really old perl code that got modified many times. It is
near to unmaintainable and really should get a replacement.

There have been many ideas, including
http://lists.debian.org/debian-dak/2008/12/msg00052.html. It doesn’t
need to be this, of course. Feel free to discuss with us any ideas
you have, but something smart would be nice. For example if we could
move various checks we do to an upload to here we could reject various
packages even before they are uploaded. (Easy examples are: expired
key in the keyring we use or the upload is for an older version,
the archive knows a newer one).

There are millions more on the todo list, but for now I will stop.

– bye, Joerg .SH AUTHOR This manual page was not written by anyone. It sprang forth into existence on its own.

Snmpd installation is a little obtuse so here is how to do the installation on Debian Lenny.

The time line looks like:
| Period | Start | End |
|————+————————–+—————————-|
| Nomination | Friday, March 5th, 2010 | Thursday, March 11th, 2010 |
| Campaign | Friday, March 12th, 2010 | Thursday, April 1st, 2010 |
| Vote | Friday, April 2th, 2010 | Thursday, April 15th, 2010 |

Please make sure that nominations are sent to (or cc:’d to)
debian-vote, and are cryptographically signed.

Kurt Roeckx
Debian Project Secretary

This year we were guests at the booth of Univention, a German company
basing their products upon Debian, in exhibition hall 2, near one of the
main entrances of the exhibition. While I must say that we had less
visitors (an overall trend at this year), the quality of questions asked
was far better than previously. This also left time to look out for old
friends, such as the LiMux people or Thomas Krenn, whom we of course
thanked for their recent donation. It was also nice to meet with the
people of the Perl booth in real life. Being a first timer at CeBIT
they had asked us for advice, and it was nice to see that their booth
run pretty well. On request of our sysadmins, we also went to the Bind
people in order to get some contact information for some dnssec things.
They where very pleased, and — thinking about recent problems with the
introduction of dnssec of another bigger Linux Distribution — offered
to step by and help us doing it the proper way. They will soon contact
us at our project mailing list.

Even though our presence there was settled (and announced) on quite
short notice, many visitors stepped by, some asking interesting
questions (e.g. about our Sparc port and 32-bit issues) but most people
just came by to thank us. We didn’t count them, but there were many!

So we would like to forward the thanks of a huge amount of people to
you! Thanks for your good work and keep up the good work!

Some more common topics were the differences between (Open)SuSE and
Debian and why we rebranded Firefox to Iceweasel. Oh, and of course
when KDE 4.4.x will be uploaded to our unstable branch. Thankfully the
KDE Team had expected that question, and informed us about their plans
in advance.

Last but not least, many questions where asked about our Debian
GNU/kFreeBSD port, even before I did my two talks about it. The
questions about that topic ranged from “Does it support XEN?” to “Do you
want to replace the Linux Kernel?” and of course related to the
possibility of using ZFS with Debian GNU/kFreeBSD. Some visitors asked
about our relationship to the FreeBSD people, and what they think about
our port. I must confess, that I wasn’t prepared for that question. I
think our relationship is good. The BSD people invited Axel Beckert to
speak about the port in their Developer Room at the recent FOSDEM, so I
think they are interested in it.

Another hot topic was of course our release process. Many people came
by to ask when we will release, and some even complained about us
starting to release in two / half year intervals. Which is of course
bullsh*t, but let’s take it as another indicator that we should
communicate these things more clearly.

On Thursday the Linux New Media Award was awarded in different
categories. For those not aware of the LNM Award, it is given away by a
jury of over 200 people from wider open source community, open source
business, and journalists. This year the Debian project was nominated
in the category “outstanding contribution to Linux / Open Source”, which
is considered the king’s class of the categories. Sadly I must inform
you that we didn’t win the prize. We came in second only beaten by the
Linux Kernel itself, which by nature made an outstanding contribution to
itself But I have been told, that it was only a slim majority for
the Linux Kernel.

Finally I would like to thank some people, who made it possible for us
to represent Debian. First to mention is Univention, namely Peter
Ganten and Alice Horstmann, who accepted us as one of their
sub-exhibitors at their booth. Considering that we only asked them two
weeks before the CeBIT started, they did a really great job of
integrating us in the booth so well. Also thanks to the “normal”,
paying sub-exhibitors at the booth, who gave us a warm welcome, and to
Mr. Umminger from the Messe AG, who cut the normal sub-exhibitor fees
down to a sixth of the normal fees and made it affordable.

I would also like to thank the kFreeBSD people for all the help we got,
especially for Axel Beckert for allowing me to steal his slides for my
talk. Cyril Brulebois for the his help with the graphical installer,
Joey for the fast approval of some money to print flyer’s, the German
national library of science and technology for the hardware, and
Univention, again for their great catering service

And of course special thanks to Jörg Jaspert, Rene Stegmaier, Meike
Reichle, Dirk Meyer and Uli Martens for volunteering (well, more or
less) to help us staff the booth!

Best regards,
Alexander

PS: Also thanks to John Goerzen for proofreading my en_DE and removing
zillions of comma

Information systems in the era of Information Technology (IT) as this has an important role in various areas of life, both in industry and education. One of the implementation of information systems in education is at the library information system. In this regard, to consider, before making a choice and implement software to build a library information system is, in terms of the operating system, programming language to what the appropriate database used to manage data and document libraries.

I have chosen Debian for the operating system of choice to load on the embedded hardware because of my prior experience with it and because it is a free distribution that continues to be actively maintained and supported

For the administration of the MySQL database you can use web based tools like phpMyAdmin which will also be installed in this howto. phpMyAdmin is a comfortable graphical interface which means you do not have to mess around with the command line.

I mostly followed what the official wxPython installation guide says. It was not a smooth installation for me, so this is my own installation note. The version is 2.8.10.1.