Clint Byrum wrote: > Hm ok, I don't know what interdiff is. I bumped to 3.0 for the automatic > quilt support.
Interdiff does a diff out of 2 diff files. It's pretty easy to use. In our case, if we use the source format 1.0, then we can use interdiff to see what the differences are between our 2 debian folders. >> 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. Oh, I see. Thanks for letting me know. But currently, I don't have the test target in yet. >> 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. Ok, it makes sense now. Thanks for the explanations, and I think I will follow your advice when I have your test diff. > 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. Yup, got it. >>> * 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. Oh ok. That's a new stuff then, and I didn't use it before. I'd be happy to try, it seems a nice tool. >>> * 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. Cool, thanks. > Would it make more sense to maintain the packages in git/svn/bzr somewhere? Yes, I usually send all of my Debian work into Git. But I hate having a Git history full of crap, so most of the time, I start a Git project when the packaging work is finished. Then if we want to do some developments as a team, we would use a specific branch until the work is done, so that we have clean patches. But anyway, currently, I think we have managed to find all the big issues, thanks to both you and Markus. > 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. I tried it, but didn't use it. :) > 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. I'm excited about Debian as a whole, and seeing that I have support for building libdbi, with some others involved, it just motivates me. > 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. :) Please do not apologies. I had so many bad experiences with people bashing me when I was trying to learn, that I think we should try and be nice with each others. Clearly, your intervention did help here. Now, what we might want to do here, is use the colab-maint project so that we can maintain in Alioth's git as you suggested. I'll be waiting for your patch to add the test stuffs against the package, and then when I have it, I'll finally upload. Hum... Finally, I think I'll try to get your test stuff from your debdiff, I think it should be ok. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
