Recently I got a bug report for package ent. The internal counter of processed bytes has just type long. In case you feed enough bytes to ent, there will be an overflow after about half an hour (of course that depends on your type of CPU, the bug was reported on architecture i386).
As modern C (C99) introduced a new type long long, I changed the type of some variables from simple long to unsigned long long. The overflow disappeared for now, but it will reappear just some trillion bytes later.
So, are there any recommendations on how to handle such a situation better?
This software is a programmable tool for verification, analysis and transformation of C++ source code.
It is mainly an engine that parses C++ source files and presents the result of this parsing to scripts in the form of various collections. Afterwards the scripts are actually performing the requested tasks.
This is a link to the Debian PTS page.
I was really amazed that a package like greylistd does not have an activeÂ maintainer anymore.
Further looking at popcon, this package is only installed on just a few computers. The reason might be that it is only installed on servers that do not take part in popcon.
Anyway, this package needs a maintainer and here I am.
My first upload to ‘experimental’ mainly takes care of lintian warnings and closes a few bugs:
- #375504: don’t expire entries every check:Â the fix was contributed by Steven A. Reisman and verified by JasonÂ Cormie.
- #585231: do not use Python strings exceptions anymore
The next step will be to take care of bugs with patches and than reduce the number of other bugs.
Please feel free to help fixing bugs or volunteer for becoming a comaintainer :-).
Here you can find the PTS page.
During my adoption of setserial, I was able to close 9 bugs for that package. So the compulsory exercise is already finished and the free program can start.
As a new version of libctl and meep unexpectedly appeared, the BOM of July shall be the new upload of libctl. Unfortunately the soname changed and the library package needs to go through the new-queue. So the bug is resolved but not yet closed.
As the task list of the Debian Med team is rather long and lots of packagesÂ are waiting for action, I again choosed a package from this team.
This month the winner is cluster3, which is needed to analyze genomic datasets.
The DOPOM package for this month shall be setserial. Although the serial interface is more and more replaced by other things like USB or network interfaces, I know at least one application that depends on this oldfashioned stuff.
setserial has 14 bugs, some of them are rather old. So, here we go:
- Â #314219: package configure goes wrong
- Â #589620: Cannot set baud rate to 4800
- Â #589621: Cannot set baud rate to 4800
- Â #618630: setserial does not work with USB serial interfaces
- Â #618631: (no subject)
- Â #299933: ppp: Cannot convert to /etc/network/interfaces method while serial device
- Â #311813: setserial doesn’t work with serial device
- Â #410099: setserial dosen’t work in manual Mod.
- Â #468420: During install I get: “The update-modules command is deprecated and should not be used!”
- Â #518313: installs obsolete /etc/modutils/setserial
- Â #375276: don’t mislead by saying “loading saved-state” if none
- Â #459912: would be nice if one can disable a fifo via setserial
- Â #522622: setserial as a essential package
- Â #314963: init.d bails out on detecting /etc/serial.conf
#589620 and #589621 as well as #618630 and #618631 are the same. Great, two done, twelve left
#518313 is easy, since modutils is gone, don’t install that file
#468420 can be closed by not using update-modules
The solution to #375276 is mentioned in the bugreport. In case the serial line is handled by the kernel (= #KERNEL in the config file) just say so.
#589620 might be a misunderstaning. setserial is not meant to set the baudrate but only to set the base_baud. The base_baud depends on the hardware and
might not be set under certain circumstances. So this seems to be a feature instead of a bug.
#618630 might be a problem with strange hardware or the driver not supporting the needed ioctl(). At least with my usb serial devices I could not reproduce that bug
#299933 has been resolved by just waiting. Nowadays the order of init scripts is rearranged and this problem should not occur anymore
#311813 is again an ioctl() issue. setserial uses TIOCGSERIAL and statserial uses TIOCMGET so depending on the kernel one or the other feature might not work
So for the moment only five bugs out of 14 are still left (#314219, #410099, #459912, #522622, #314963), well done :-).
The next DSOM package is cd-discid. The DiscID can be used to query for example the FreeDB database.
It is already part of the archive but needed an upload for a new version. I cheated a bit as I already did all work last month. Timur, the current maintainer, fixed an FTBFS on Hurd and I wanted to upload it before the Wheezy-freeze.
Here is the PTS page.
Besides my already mentioned activities l had some fun with
- shame on me, for my new meep packages I forgot some entries in the Conflict:-line. Luckily the piuparts-tests found the problem and assigned rc-bugs to me. Hey, I can help resolving three rc-bugs now :-).
- some sponsoring of boinc; unfortunately there still is an ftbfs on powerpc
- some sponsoring of boinc-app-seti
- the patch for ‘my’ lintian bug was already accepted for version 2.5.9; that was really fast
- Anibal accepted my patch for debtree; now debtree also prints the size of depending packages
- the dscverify bug (#679148) has been fixed by using getopts(), my patch was not really needed
fasttree (mentioned in a previous post) made it to unstable and will become part of Wheezy.
So let the next month begin 🙂
The next initiative I want to start is DTPOM (Debian Team Package Of the Month).
Each month an unfinished package from the task list of a team shall be finished and added to the archive.
This month I have choosen fasttree from the Debian Med Team. Unfortunately it is still in the new-queue and waiting for processing, so there is no link to the PTS page yet.
As you might have guessed from the previous posts, with BOM (Bug Of the Month) I want to take care of at least one bug from the Debian BTS each month.
Being a nice guy I have a five step plan in case a program does not work as expected.
1) read the manual
2) read the manual
3) ask my favourite search engine about that issue
4) read the manual
5) ask my favourite search engine about that issue
Unfortunately this plan totally failed while trying to understand the output of lintian. For an unknown reason I was always told that an init.d-script was not registered in debian/postinst. But I could see that seemingly missing call to updaterc.d
Looking at the PTS and the number of bugs for lintian, I decided that this might be the next entry. Fairly quickly I found the code where the error must be hidden. A bit shocked I was faced with something like:
my $opts_r = qr/-\S+\s*/;
my $name_r = qr/[\w.-]+/;
my $action_r = qr/\w+/;
At the sight of that regular expression I just wanted to run away and do some gardening (normally it is the other way around). After pulling up weeds for awhile, I sat down again and tried to decode that expression. Surprisingly it was not as difficult as expected before.
As a result #677142 containing a patch came into existence.
Result: regular expressions look strange but lift their secret after some time of thinking