After some talks about how we should package Bugzilla latest upstream release with my sponsor, Francesco Paolo Lovergine, we decided to split the packaging in two parts:
We will still provide Bugzilla 2.16 in debian/sid - and will follow up the task of closing Debian specifi bugs - and will upload soon Bugzilla 2.18 in debian/experimental.
The upload to sid of the 2.16.7-3 package has just been done by Francesco (it’s in the incoming pool at the time of this writing), and we might upload soon 2.18-1 to experimental.
On the other hand, I started forwarding bugs to upstream in order to start a collaborative work between Debian and Bugzilla teams.
We then decided, with the Bugzilla developers, to open a meta bug on Bugzilla which will be blocked whenever a Debian bug is forwarded to upstream.
Bugzilla
I’m glad to announce here the upcoming arrival of bugzilla 2.18 in Debian sid. This new package is not just another upstream version, it’s also, first of all, a major rewriting of the package structure.
Instead of having a lot of different paths when installing bugzilla, we would now have something like that (which I find clean and easy to remember):
/usr/share/bugzilla: the root directory.
/usr/share/bugzilla/web: the webserver’s document root.
/usr/lib/cgi-bin/bugzilla: the cgi-bin location.
Perl libraries - Bugzilla::* - will be installed in the standard Perl5 independant modules location: /usr/share/perl5/.
I also paid attention to all the whishlist items and realized that all of them were about better Debconf translations. This release will then close a lot of those bugs, which means that Bugzilla will now come with Czech, Catalan, French, German, Japanese, Dutch and Portugues localisations.
Thanks to everyone who submitted comments about the last two preview releases, that was helpful.
Bugzilla
As you might know, Bugzilla 2.18 was released a week ago and it was quickly requested to package it for Debian.
After some work, I can now provide a preview package on my repository. It’s a complete rewrite of the package structure; the goal was to provide a Policy clean package and a Bugzilla installation as close as possible to upstream.
I think that there is still some work to do before I ask my sponsor to upload this release but it’s yet usable. Feel free to give it a try if you have the time :
You can use my sources.list entry:
deb http://www.sukria.net/debian ./
Update, 2005/01/22
A new package has been uploaded on my repository, it contains a lot of fixes. As before, feel free to report me bugs either by mail or by using reportbug on #290775.
Update, 2005/01/25
Again, a new preview package is available (2.18-0pre3) and would certainly be the one that will be uploaded. That’s now the time for the last checks before I ask Francesco to upload 2.18-1 to sid…
Get ready Debian, Bugzilla 2.18 is coming 
Bugzilla
Here is a new minor release of backup-manager for providing full spanish, german and french translations. Thanks to all the people who have worked on that.
I’ve updated the web page moreover, and will try to maintain some release notes, in order to have a changelog-like area somewhere.
I can also underline here the fact that the upload process to the official Debian archive is on the way, the package is waiting for approval by the ftp-master team. That’s a great news and is possible thanks to the time of Esteban Manchado Velázquez who is my sponsor.
Of course, I’ll post something here when backup-manager would become officially debianized (this can take a couple of weeks).
backup-manager
If you don’t know the Linux for Geeks distro, named GRML, please check it up.
It’s a live CD based on Debian with everything you need to perform a nice hack session wherever you are.
The nice thing is that the GRML 0.2, which will be released on January 2005, the 10th, will include the last release of backup-manager.
Thanks to the GRML team 
backup-manager
Here it is, I believe that I can now say that I’m a Debian maintainer.
More precisely, I’m now a co-maintainer for the Bugzilla package.
That’s with pleasure and interest that I started contributing with closing a Release Critical Bug by adding an automatic installation mode in the postinst phase.
That bugfix was uploaded in a NMU by Francesco Paolo Lovergine (thanks a lot to Frankie for his uploads
).
During this period, a thread was opened on the debian-qa mailing list for underlying that the Bugzilla package was in bad shape (lots of bugs were open for long time and there were also several NMUs).
Then Rémi Perrot, the Bugzilla’s maintainer, answered that he was not MIA but welcomed co-maintenance. So he confirmed that I could add myself as a co-maintainer in order to enhance to package’s maintenance.
So here it is, I officially come into Debian with the bugzilla 2.16.7-1 release, and dude, that’s exciting !
Debian
One Bugzilla’s bug led us to work on an automatic instalaltion method, saving a lot of Debconf prompts.
This is possible for every box that has a local debian-installed MySQL server as /etc/mysql/debian.cnf will handle the debian-sys-maint user.
So we did it - in 2.16.7-0.2 - and that was working well. Instead of being prompted a lot for MySQL access values, user had just to choose a Bugzilla maintainer name, password and email. Everything was fine…
Well not really.
Indeed, if Bugzilla was already installed before the 2.16.7-0.2 release becomes configured, user would be prompted to choose the installation mode; and most of the time, he would have nicely jump on that-new-automatic-stuff-that-must-work-perfectly.
Uh, eh, well, it did not. At this time, the automatic mode wasn’t aware of the word upgrading and then assume that if you choose this mode, you want to install automaticlally a new Bugzilla database. In this particular case, it should have look if there was still a database, before assuming that installation time had come.
After some code cleanup, the last package I provide on my repository (before it gets uploaded by my sponsor) fixes this bug, with giving a smart automatic mode that works for installing a new Bugzilla database as well as upgrading an existing one.
All this makes me think that writing a postinst script that guesses values has to be done with care, as something the developer didn’t think about could lead to a really unwanted situation on the user boxes.
Debian
Recent Comments