Announcing the availability of first Qt 3.3 packages
Fellow users, fellow developers! I am proud to announce the availability of official Qt 3.3 beta packages for the Debian GNU/Linux Distribution. The packages have version 3.3.2-0pre1 and have been uploaded to the experimental-archive some hours ago. As they contain new components (database plugins for InterBase/FireBird and SQLite), they need manual ftp-master approval. Until they hit the mirrors, you can fetch them by adding the following to your sources.list file: deb http://people.debian.org/~madkiss/qt3.3/ ./ If you want to get the sources, you can additionally add the following: deb-src http://people.debian.org/~madkiss/qt3.3/ ./ Developers, please test these packages heavily and report anything you see -- whether the packages work fine, whether they fix bugs you reported before, and of course whether they rise new bugs. There are some minor things on my TODO; if these packages turn out to be okay, I will fix the mentioned minor bugs and upload 3.3.2-1 to the official unstable archive as soon as the -0pre1-packages made it into experimental. -- .''`. Martin Loschwitz Debian GNU/Linux developer : :' : [EMAIL PROTECTED][EMAIL PROTECTED] `. `'` http://www.madkiss.org/people.debian.org/~madkiss/ `- Use Debian GNU/Linux 3.0! See http://www.debian.org/ signature.asc Description: Digital signature
Re: qwindowstyle.h problem
On Fri, Feb 28, 2003 at 12:32:33PM +0100, Leopold Palomo Avellaneda wrote: > > I have an error > qwindowsstyle.h: No such file or directory > <0>[EMAIL PROTECTED]:~$ dpkg -S /usr/include/qt3/qwindowsstyle.h libqt3-plugins-headers: /usr/include/qt3/qwindowsstyle.h The file is in libqt3-plugins-headers package. -- .''`. Martin Loschwitz Debian GNU/Linux developer : :' : [EMAIL PROTECTED][EMAIL PROTECTED] `. `'` http://www.madkiss.org/people.debian.org/~madkiss/ `- Use Debian GNU/Linux 3.0! See http://www.debian.org/ pgp2IvCfIxjdB.pgp Description: PGP signature
Re: Rethinking Qt headers (should the header packages be recombined?)
> > > Having -DQT_NO_COMPAT as default compile option for qmake would probably > > not be too difficult to realize. I think adding this value to qmake.conf > > should almost do the job. > No, this has nothing to do with qmake at all as that wouldn't cover automake > projects either. You have to specify CPPFLAGS=-DQT_NO_COMPAT before running a > configure so it gets picked up for automake projects. So we don't have to nor > do we want to change anything about qmake at all here. I'm glad that we have > stripped the whole Qt package mess out after working on the package for full > 4 weeks and there's no way that we're going to mess it up again :) > Mixed that up then, sorry. -- .''`. Name: Martin Loschwitz : :' : E-Mail: [EMAIL PROTECTED] `. `'` www: http://www.madkiss.org/ `- Use Debian GNU/Linux - http://www.debian.org pgpnxPd04Pab0.pgp Description: PGP signature
Re: Rethinking Qt headers (should the header packages be recombined?)
On Thu, Feb 27, 2003 at 12:16:44AM +1100, Ben Burton wrote: > > To be able to build a package that uses these deprecated headers, you must > install the separate package libqt3-compat-headers, in addition to the normal > libqt3-headers. None of libqt3-dev, libqt3-mt-dev nor kdelibs4-dev depend on > this libqt3-compat-headers. > libqt3-dev/libqt3-mt-dev should not depend on libqt-3-compat-headers since that would, as you can probably imagine, completely nullify the package's intention. Anyway, the fact that kdelibs4-dev does not depend on the package yet is probably caused by the fact that it got not updated for recent changes. That is on calcs TODO, I guess. But that solution won't even be of long breath since, as far as I remember, Ralf said that he cut all references to headers from libqt3-compat-headers out of the KDE3-CVS (Was it in BRANCH or HEAD? Both? Don't remember, sorry.) > The reason (as I understand it) for splitting out these headers is so that > developers recognise that their code uses legacy headers and so they are > prompted into updating their code to use the newer headers instead. > Correct, yes. > The consequences I see are as follows. Say a user doesn't have > libqt3-compat-headers installed (since there's no obvious reason to have it > installed; none of the usual -dev packages depend on it). They download a > random Qt/KDE application to build, and it doesn't compile. They're > confused, since it builds everywhere else under Qt3. After some rummaging > around, they discover that oh, on a *debian* system you need the extra > libqt3-compat-headers package. The user installs libqt3-compat-headers so > that it builds properly, and if they're nice they'll even notify the upstream > developer that their application uses legacy headers. > Uhm, optimistic person? I would actually call that the "Best case scenario"! ;) > > There is a much better mechanism for testing a source tree for legacy > headers; > this is the -DQT_NO_COMPAT compiler option, which forces a compile error when > a legacy header is used, and which can be used on an app-by-app basis instead > of a system-wide basis (such as package management). > Having -DQT_NO_COMPAT as default compile option for qmake would probably not be too difficult to realize. I think adding this value to qmake.conf should almost do the job. Anyway, let's see what Ralf thinks about this issue. > Ben. :) -- .''`. Name: Martin Loschwitz : :' : E-Mail: [EMAIL PROTECTED] `. `'` www: http://www.madkiss.org/ `- Use Debian GNU/Linux - http://www.debian.org pgp1ituxVw8og.pgp Description: PGP signature
