On Aug 11, 2010, at 2:30 AM, Thomas Goirand wrote:

>> 
>> Thomas, thanks so much for taking the time to put this together!
>> 
>> These are versioned a little funny.
>> 
>> The libdbi-drivers upstream versions have a debian-like structure, so the 
>> ones married to libdbi 0.8.3 are versioned 0.8.3-1.
>> 
>> Hence, the package version is usually
>> 
>> 0.8.3-1-1
>> 
>> You'll probably want to fix that before upload.
> 
> Quite not! Please have a look by yourself, libdbi-drivers version isn't
> how you say it is:
> 
> http://sourceforge.net/projects/libdbi-drivers/files/
> 
> Where exactly did you find something with 0.8.3-1 as upstream version?
> As much as I see, this was the case only for version 0.8.2-1 of
> libdbi-drivers, but that's not the case anymore (which is a good thing).

Right I suppose I inferred a bit too much by the 0.8.2-1 and 0.8.3-1 releases
being the only ones I've seen.

Either way, 0.8.3-1 seems to be the latest upstream.

> 
>> 
>> Also you will probably want to bump the build-depend to libdbi0-dev 
>> (>= 0.8.3). 
> 
> I think you didn't look correctly, because this is exactly what I did.
> 

I suspect we were not looking at the same packages. Also according to Markus 
Hoenicka's message, this is ok, so probably not important to bump them.

>> Actually the bash code I pasted is in error, and segfaults even with the 
>> newer version (probably a bug in the error handling code somewhere).
>> 
>> Changing DS_BASE to 
>> 
>> "sql//sqlite3/sqlite3_dbdir=./dbname=test.db//foo_measures/tstamp/value/derive"
>> 
>> Actually makes it work even with 0.8.2 (though it breaks on Ubuntu still)
> 
> If that is the case, then we don't need to release 0.8.3 right away, and
> I should send this new version in the experimental repository of Debian,
> considering that Squeeze is now in a frozen state.
> 

Yes, I'd say this bug can be reduced in severity, and I apologize for the 
erroneous
nature. There's still a segfault, but its probably not so cut and dry as 
updating 
to 0.8.3-1. It also only affects the new functionality of rrdgraph_libdbi, so 
there
is no regression at least.

>> Either way, I think the proper thing to do is package and release 0.8.3-1
> 
> NOT in SID/Squeeze though. You guys in Ubuntu can later import the
> package from Experimental.
> 

Right, most definitely not in sid right now. We actually don't import from
experimental generally, we tend to stick to unstable (the automatic syncing 
that is
done before DebianImportFreeze is done from unstable only).

Actually all of the changes for running tests are proposed for merging into the 
Ubuntu package which is already version 0.8.3-1-0ubuntu1. So as soon as 
0.8.3-1-1 is
moved to sid, our auto-merge process will see the newer version and grab it.

Given the problems with rrdtool, we had to move forward with 0.8.3-1.

>> Anyway, the items I mention above need resolving. Also I've spent a fair
>> amount of time getting the automated tests to run on Debian and Ubuntu, 
>> and I *think* the attached debdiff will satisfy my issues above, and
>> run the automated tests during the package build.
> 
> Your diff includes things that shouldn't be there which makes them
> unreadable because too big. I believe you should have kept source format
> 1.0 and just use interdiff to make this readable. Never mind, I've
> filtered out the upstream changes. And there's a lot of issues in what
> you just sent. For example:
> 

Hm ok, I don't know what interdiff is. I bumped to 3.0 for the automatic
quilt support.

> You Build-Depends on the following, and you shouldn't have:
> +    mysql-server, mysql-client,
> +    postgresql, postgresql-client,
> +    locales-all | language-pack-en
> 

These are for the automated tests, which start a mysqld and postgresql instance
to connect to and run SQL tests against. The test_mysql.sh and test_postgres.sh
scripts are careful not to disturb any running mysqld's or postgres's.

> My package has a lot more fixes that yours doesn't add, like calling
> ./autogen.sh before configure, and Build-Depends: on automake and
> libtool, plus many others. Can you explain to me why exactly you wanted
> to Build-Depends on locales-all | language-pack-en? That doesn't seem to
> be needed, and by the way, this is Ubuntu specific, AFAIK:
> 

The test_postgresql.sh script sets LC_ALL=en_US.UTF8. It could be any UTF8
locale, but the important thing is that initdb and libpq will pick this up and
use it to run in UTF8 mode. Otherwise on buildd's the tests will fail with UTF8
because the database will be created with locale set to "C". The tests should
probably detect this and skip any tests that depend on non-existent locales,
but even if they did that, I'd want to have a UTF8 locale available so the full
functionality can be tested.

Yes, language-pack-en is only in Ubuntu, hence the OR clause with locales-all.
It shouldn't break anything to have the |, and it allows the package to be
imported into Ubuntu without any merging/delta.

> http://packages.debian.org/search?keywords=language-pack-en&searchon=names&suite=all&section=all
> 
>> Note that its missing these changelog entries:
>> 
>> * Updated to source format "3.0 (quilt)"
> 
> I don't want to use the "3.0 (quilt)" format, because when you call
> ./autogen.sh and ./configure, it's generating a lot of files that are in
> the upstream tar file. The result being that the Debian build system
> creates a useless huge patch in debian/patches, which shouldn't be
> there. Using format 1.0 solves this issue without too much work.
> 

As I understand it, one way way to handle this is to use dh_autoreconf and
dh_autoreconf_clean.

>> * Run automated tests for mysql, pgsql, sqlite, and sqlite3
> 
> I saw your tests, and I think it is a good thing to add. Could you
> please provide me a patch against the version that I just sent you?
> 

Will do, I'll file it as a wishlist bug.

>> * Add misc:Depends for debhelper lintian warnings.
> 
> Yup. Got that one in already since the beginning.
> 

I'm fairly certain now that I was not reading the same source package. :-P

>> Note that the package, with this debdiff applied, is available here:
>> 
>> https://launchpad.net/~clint-fewbar/+archive/fixes/+packages
> 
> I'm not willing to be rude, but your package doesn't fit, and it has
> still loads of lintian warnings. As it is right now, I can't use it, and
> my package is in a much better shape. The only thing I'd like to take
> from you would be the test thing (thanks a lot for that). Look at all
> the lintian warnings I got when using -Ii flags:
> 

Its not rude at all. It generally helps to send a debdiff against the
right package first and foremost, and I seem to have gotten that quite
wrong.

Would it make more sense to maintain the packages in git/svn/bzr somewhere?

> I: libdbi source: binary-control-field-duplicates-source field "section"
> in package libdbi0
> I: libdbi source: binary-control-field-duplicates-source field "section"
> in package libdbi0-dev
> W: libdbi source: obsolete-relation-form-in-source in libdbi0 conflicts:
> libapache2-mod-log-sql-dbi (< 1.100-11)
> I: libdbi source: missing-debian-source-format
> W: libdbi source: debhelper-but-no-misc-depends libdbi-doc
> W: libdbi source: debhelper-but-no-misc-depends libdbi0-dev
> W: libdbi source: ancient-standards-version 3.7.2 (current is 3.9.1)
> I: libdbi0: conflicts-with-version libapache2-mod-log-sql-dbi (<< 1.100-11)
> I: libdbi0: conflicts-with-version libdbd-mysql (<< 0.8.2-1)
> I: libdbi0: conflicts-with-version libdbd-pgsql (<< 0.8.2-1)
> I: libdbi0: conflicts-with-version libdbd-sqlite (<< 0.8.2-1)
> I: libdbi0: no-symbols-control-file usr/lib/libdbi.so.0.0.5
> W: libdbi0-dev: wrong-section-according-to-package-name libdbi0-dev =>
> libdevel
> 
> these were all fixed in what I sent you.
> 

Right, as I said, we were looking at different packages. In the case above, I 
see
stuff for libdbi-drivers and libdbi.. I hope you weren't using the source 
package
I have in my PPA for libdbi, as I didn't mean to imply that it was correct in 
any
way.

In our previous discussions, you had implied that you weren't as enthusiastic
about working on the package as much anymore, so I apologize if I tried to do 
too
much. I'm glad you've rejuvenated your excitement for libdbi. 

Its in Ubuntu main now, and some of the monitoring stuff we're doing will 
depend 
on it, so I may be feeding more patches back to you over the next couple of 
years.
I'll try to make them a little bit more focused. :)


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to