Re: Rethinking Qt headers (should the header packages be recombined?)
> If it doens't compile using just -dev then it is a > app that needs to be fixed, and they can help the debian movement by sorting > this out :) Indeed, they *can* help. I don't believe it's debian's place to force them to. Ben. :)
Re: Rethinking Qt headers (should the header packages be recombined?)
On Wed, Feb 26, 2003 at 05:44:02PM -0800, Michael Peddemors wrote: > On Wednesday 26 February 2003 16:03, Ivan E. Moore II wrote: > > > I have to agree with Ben on this one. There are more negative aspects of > > breaking out these headers than positive. I also think that when a user > > (note user, not developer) wants to build a Qt based app they would assume > > that installing the -dev package would be all they would need. Makes > > sense. It's not the users job to try to figure header issues out. > > Disagree... User's don't 'build' apps.. devleopers do, even if they might be > beginning developers... If it doens't compile using just -dev then it is a > app that needs to be fixed, and they can help the debian movement by sorting > this out :) Users barely handle apt-get :) User's do indeed build apps. They may not be able to do anything other than build it, but they do build apps. Especially when we make it easy for them to do so. There are alot of users who build their own kernels as well...but that doesn't make them developers. I for one thing would never even think of being a kernel developer. In that sense I am a user. But I always build my own kernel. Ivan -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
Re: Rethinking Qt headers (should the header packages be recombined?)
On Wednesday 26 February 2003 16:03, Ivan E. Moore II wrote: > I have to agree with Ben on this one. There are more negative aspects of > breaking out these headers than positive. I also think that when a user > (note user, not developer) wants to build a Qt based app they would assume > that installing the -dev package would be all they would need. Makes > sense. It's not the users job to try to figure header issues out. Disagree... User's don't 'build' apps.. devleopers do, even if they might be beginning developers... If it doens't compile using just -dev then it is a app that needs to be fixed, and they can help the debian movement by sorting this out :) Users barely handle apt-get :) -- -- "Catch the Magic of Linux..." Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security Wizard IT Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com LinuxMagic is a Registered TradeMark of Wizard Tower TechnoServices Ltd. (604)589-0037 Beautiful British Columbia, Canada
Re: KDE Multimedia - Latest updates.
On Wednesday 26 February 2003 15:55, Paul Cupis wrote: > Somebody has just recently asked this exact question. Please check the > lists before you post. > *Sheepish Grin* Must have deleted that thinking it had somethign to do with the other kdemultimedia issue .. but reviewing the list, you are right.. bad me.. -- -- "Catch the Magic of Linux..." Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security Wizard IT Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com LinuxMagic is a Registered TradeMark of Wizard Tower TechnoServices Ltd. (604)589-0037 Beautiful British Columbia, Canada
Re: Rethinking Qt headers (should the header packages be recombined?)
>> >> It's as simple as reading README.Debian if something doesn't compile. > >hahahahahahha...that's a funny statement. I believe that if we were to >pole folks out there the README.Debian would be the last place anyone >would look to find out why something didn't compile. They would first >assume that they had either the wrong version or that the package they >downloaded was incomplete. > Yes, that is a good one. One thing folloing Debian for the past several years has taught me was that no one ever reads the README.Debian files. Seems that about half of the problems I've seen involve not having read this file. I don't think that most Debian users would even know where to find these. Two examples that quickly come to mind are: A previous KDE packager decided to offer some assistance in getting AA working on KDE. He packaged a set of needed programs, along with detailed instructions in the README.Debian file. This resulted in the debian-kde list getting filled with 'Why isn't AA working?' for almost three months even though the README.Debian file described, in detail, what had to be done to try to wrestle AA in. X is packaged with no fonts required. This is explained in detail in the README.Debian since X can get fonts from a font server, either local or over a network connection, therefore fonts are not required for X to run. Yet, every week or so, another bug report is filed against X due to no fonts being installed by default. The installation even prints and explaination of this during install, and people still file the bogus bugs. I'm sure a quick search of other debian mailing lists would turn up thousands of other examples of README.Debian files not being read. In saying that, though, if someone is going to go to the bother and risk of compiling non-debian apps on their system, this is one way to highlight the depreciated headers and hopefully getting compaints sent up-stream to get these fixed. They should certainly be reading any and all README files before compiling stuff on their box. Cheers, John Gay
Re: Rethinking Qt headers (should the header packages be recombined?)
On Wed, Feb 26, 2003 at 08:01:51PM -0500, Matt Zimmerman wrote: > On Thu, Feb 27, 2003 at 12:16:44AM +1100, Ben Burton wrote: > > 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. > I do not think that the package split makes sense. > It is not justifiable to burden Debian users and Debian package maintainers > with these legacy issues. A deprecated header file should issue a #warning > explaining that it is deprecated (and, ideally, what replaces it). Simply > breaking the builds of a lot of existing software (packaged and not) does > not make sense here. Even better, if you look inside the replacement headers, you'll find that the *official* headers contain backwards-compatible #defines for all of the deprecated classes. So you can #include , and continue using QArray as your class type. So what do we gain by weaning developers off the old headers again? -- Steve Langasek postmodern programmer pgpZSq3lj6QlD.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: > 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. I do not think that the package split makes sense. It is not justifiable to burden Debian users and Debian package maintainers with these legacy issues. A deprecated header file should issue a #warning explaining that it is deprecated (and, ideally, what replaces it). Simply breaking the builds of a lot of existing software (packaged and not) does not make sense here. -- - mdz
Re: Rethinking Qt headers (should the header packages be recombined?)
On Thu, Feb 27, 2003 at 01:11:20AM +0100, Simon Richter wrote: > E: Unable to lock the administration directory (/var/lib/dpkg/), are you root? Exactly. Remember that bit in the social contract about these "users"? -- - mdz
Re: Rethinking Qt headers (should the header packages be recombined?)
> Ben, I always appreciate your work but I think from the developers > perspective > you just need to have a way to get the legacy headers out of the way. We have that already. -DQT_NO_COMPAT. > So if we revert this and put the legacy headers back, even change > them, which I consider to be even more evil than anything else because you're > supposed to package the code and not to put your own stuff into it ... It's not evil at all. We're allowed to by the Qt license, and adding #warnings to the legacy headers will not change any of the interfaces that the headers define. > whole point of 4 weeks of hard work was pretty pointless. I appreciate this and I wish I'd written this email four weeks ago. I've also had similar experiences where I've poured a large amount of work into something only to be told later that there are technically preferable solutions. And in a situation like this, it's frustrating but I'll argue that the technical benefit should outweigh the emotional and time investment. > It's as simple as reading README.Debian if something doesn't compile. Well, it's simpler if things compile in the first place. Let's compare the libqt3-compat-headers solution vs the #warnings in legacy headers solution. Both solutions make the developer aware that they're using legacy headers. The difference is that the libqt3-compat-headers solution forces a compile error, saying "address this issue NOW", whereas the #warning solution just alerts the developer, saying "address this issue when you get around to it". If the developer is conscientious, they'll fix the warnings by fixing their #includes. You're happy and the developer is happy. If the developer is lazy, they'll ignore the warnings. But then again, if the developer is lazy, I'd expect they'll just install libqt3-compat-headers to make the build errors go away. Which then has the disadvantage that they'll never be told about legacy headers again (as opposed to the #warning solution, where they'll continue to be reminded). So in this sense, I can't see any clear benefit that libqt3-compat-headers has over the #warnings. However, it has the clear disadvantage that, for users (who aren't upstream developers), code will fail to compile and they'll have to rummage around looking for information on how to fix it (and, as has been pointed out elsewhere on this thread, they'll need to be root to do it). Ben. :)
Re: Rethinking Qt headers (should the header packages be recombined?)
Ralf, > Ben, I always appreciate your work but I think from the developers > perspective > you just need to have a way to get the legacy headers out of the way. And the > README.Debian explains *in detail* that if an app doesn't compile, install > the compat-headers package. E: Unable to lock the administration directory (/var/lib/dpkg/), are you root? Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgppNyEbJ8re2.pgp Description: PGP signature
Re: Rethinking Qt headers (should the header packages be recombined?)
> Ben, I always appreciate your work but I think from the developers > perspective > you just need to have a way to get the legacy headers out of the way. And the > README.Debian explains *in detail* that if an app doesn't compile, install > the compat-headers package. That's that, and that was a goal that was > desired. So if we revert this and put the legacy headers back, even change > them, which I consider to be even more evil than anything else because you're > supposed to package the code and not to put your own stuff into it, then the > whole point of 4 weeks of hard work was pretty pointless. > > It's as simple as reading README.Debian if something doesn't compile. hahahahahahha...that's a funny statement. I believe that if we were to pole folks out there the README.Debian would be the last place anyone would look to find out why something didn't compile. They would first assume that they had either the wrong version or that the package they downloaded was incomplete. If putting the answer in the README.Debian was the proper way to go then we could just put a note in there telling people that using the compat headers was wrong in the first place and tell them how to fix it. This would save on having yet another package in Debian that only contains a very small amount of files and size. 4 weeks either way doesn't matter. I've put months of work into packages in the past doing what I thought was the right thing to do only to have others revert it, change it, or convince me that i was doing it the wrong way (or that there was a better way). I have to agree with Ben on this one. There are more negative aspects of breaking out these headers than positive. I also think that when a user (note user, not developer) wants to build a Qt based app they would assume that installing the -dev package would be all they would need. Makes sense. It's not the users job to try to figure header issues out. Ivan -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
Re: KDE Multimedia - Latest updates.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody has just recently asked this exact question. Please check the lists before you post. That said, try: dpkg --purge --force-depends kio-audiocd apt-get install kdemultimedia Regards, Paul Cupis - -- [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+XVP9IzuKV+SHX/kRAkRiAJ4onhK5YfNirv5Up79yGDa2EYNUxgCfdsNp 7+4c0OLDjIFVmAc/MKtC8VA= =yJGH -END PGP SIGNATURE-
Re: mouse bad configuration
Thanks Paul! It worked great selecting the PS/2 mouse. Thanks again, Martín Nigoul At 10:18 a.m. 26/02/03 +, you wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 26 Feb 2003 07:15, Martin wrote: > Hi: I try to install debian woody in an AMD duron 750 with a genius > netmouse pro with a ps/2 plug. > when I was prompted, I choose netmouse/ps2 but when KDE starts up > the mouse cursor seems to like the under left corner of the screen > -it does move just a little an then goes back- (and do some sort of > strange things, like open aplications that I don't want to). > So I think that I've made a bad choice when selecting the mouse > type. If any of you knows the way to reconfigure the mouse I'll be > very gratefull if you tell me what command to run. dpkg-reconfigure xserver-xfree86 should be the command to run. Just accept the defaults for all of the answers except for the mouse ones (which you'll want to change). You might try the PS/2 option (or imPS/2 if you have a wheel on your mouse). Regards, Paul Cupis - -- [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+XJSZIzuKV+SHX/kRAiosAJ40/imyi84BM8vMQ9ERV9qJSqJm2ACeJLGK 0aCywS+ctfVs/z7uf5rBMpQ= =WHdL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
KDE Multimedia - Latest updates.
Just did an 'update' and 58 packages needed upgrading.. But a few faliures... kdemultimedia-kio-plugins had a problem, to do with kcm_audiocd.la in two packages, mpeglib had a problem conflicting with files from 'yaf' apt-get wanted to hold back kdemultimedia so I expected a problem, and can't install kdemultidia now at all. apt-get install kdemultimedia Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: kdemultimedia-kio-plugins The following NEW packages will be installed: kdemultimedia kdemultimedia-kio-plugins (Reading database ... 25315 files and directories currently installed.) Unpacking kdemultimedia-kio-plugins (from .../kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i386.deb) ... dpkg: error processing /var/cache/apt/archives/kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i386.deb (--unpack): trying to overwrite `/usr/lib/kde3/kcm_audiocd.la', which is also in package kio-audiocd dpkg-deb: subprocess paste killed by signal (Broken pipe) Selecting previously deselected package kdemultimedia. Unpacking kdemultimedia (from .../kdemultimedia_4%3a3.1.0-0woody3_all.deb) ... Errors were encountered while processing: /var/cache/apt/archives/kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Tried a remove but... apt-get remove kio-audiocd Reading Package Lists... Done Building Dependency Tree... Done You might want to run `apt-get -f install' to correct these: Sorry, but the following packages have unmet dependencies: kdemultimedia: Depends: kdemultimedia-kio-plugins (>= 4:3.1.0-0woody3) but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). -- -- "Catch the Magic of Linux..." Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security Wizard IT Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com LinuxMagic is a Registered TradeMark of Wizard Tower TechnoServices Ltd. (604)589-0037 Beautiful British Columbia, Canada
Re: Rethinking Qt headers (should the header packages be recombined?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mittwoch, 26. Februar 2003 23:15, Ben Burton wrote: > > Almost all of KDE CVS should be working without the compat-headers ... > > I'm not referring to KDE CVS specifically; I believe perfectly that > package maintainers are capable of sorting out this situation in time. > > The thing is that most users *aren't* package maintainers, and most > people who build some application that they download from the net > *aren't* the developer of that application. > > > It's simply doable by runnning fixincludes from kdesdk in the source > > directory to make apps/packages compile. This is a job that is too easy > > for users, packagers and developers without having to recompile > > everything ... > > Sure, but I'll argue that this isn't something we should force users to > do. It's the job of the developer to remove legacy headers from their > applications. I don't think debian should be forcing users to discover > and then work around these problems. > > > > 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. > > I don't believe that -DQT_NO_COMPAT should be made into a default > option. Again this would mean we force the users to be responsible for > updating the developers' legacy code. > > > Ben, I know that it's been a bit troublesome but OTOH we could have just > > used libqt3-compat-headers and do nothing in KDE CVS. Instead, we used > > fixincludes to fix the BRANCH so that it doesn't depend on the package. > > Sure. But we, or the KDE developers could have done that just as easily > without splitting the header packages. As you say, it's simple - just > run "fixincludes", send your patches upstream and we improve the quality > of free software. Without having to split the Qt header packages and > cause needless confusion for users trying to compile other software on > debian boxes. > > > And compiling and packaging isn't the only thing that Qt is intended to > > be good for, it's mainly for developers developing new software :) > > Well, no. It's for (a) developers to write software, and (b) users to > recompile and/or tweak that software. You're essentially asking that we > break (b) in certain situations so that (a) results in less legacy code. > > Again, I applaud your motives. I nevertheless don't believe that Debian > should be the body that polices legacy headers. We should make a > distribution where compliation just works, and those of us who wish to > encourage better code can simply rebuild apps on our own with > -DQT_NO_COMPAT and/or run fixincludes, and pass the patches upstream. > > > It had to be done sooner or later ... > > No, I don't think it did, not until TrollTech releases a new Qt > upstream with a similar level of anti-legacy enforcement. As it stands > now, with a default Qt development environment installed, Qt apps can > break on debian where they work everywhere else. > > > So it seems to me that a good idea would be to include them in the usual > > -dev package, and then patch them with #warning directives that say > > "foo.h is deprecated and may disappear in the future; please use bar.h". > > I'm very happy with this proposal. It means builds still work under > debian just like every other distribution, but it also means that users > and/or developers are made aware of the use of legacy headers, which is > your motive AIUI. Ben, I always appreciate your work but I think from the developers perspective you just need to have a way to get the legacy headers out of the way. And the README.Debian explains *in detail* that if an app doesn't compile, install the compat-headers package. That's that, and that was a goal that was desired. So if we revert this and put the legacy headers back, even change them, which I consider to be even more evil than anything else because you're supposed to package the code and not to put your own stuff into it, then the whole point of 4 weeks of hard work was pretty pointless. It's as simple as reading README.Debian if something doesn't compile. Ralf > > Ben. :) - -- We're not a company, we just produce better code at less costs. - Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+XUNqu0nKi+w1Ky8RAjDtAKCIkTsnNhuas8p4csrBkvOXs9x+CQCeP057 o5gDP5kvTHzvM9evc73gq+g= =9DLH -END PGP SIGNATURE-
Re: Upgrade Woody from KDE-2.2.2 to KDE-3.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mittwoch, 26. Februar 2003 20:45, Leopold Palomo Avellaneda wrote: > A Dimecres 26 Febrer 2003 20:10, Ralf Nolden va escriure: > > > I do the same the last week , and I have found differences betweend > > > the directories /dist/stable/main/binary-i386 and > > > /dist/woody/main/binary-i386. > > > > > > It's normal? > > > > No, stable is a symlink to woody. You probably pulled once that version, > > once the other directory and in between was my updating of packages :) > > Ok, maybe it would be a good idea to put same update in the change log. > > Did you update daily? No, of course not. As said, I've just updated stuff this week after madkiss and I were done with Qt and we needed updated packages at our company. Ralf > > Leo - -- We're not a company, we just produce better code at less costs. - Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+XUEou0nKi+w1Ky8RAhyxAKCZmCKrxt9pmhsuVeqWPNcszjiRLgCdEtWt yiU3HQosYClTD8rMv/2WCeQ= =nOb2 -END PGP SIGNATURE-
Re: Rethinking Qt headers (should the header packages be recombined?)
> Almost all of KDE CVS should be working without the compat-headers ... I'm not referring to KDE CVS specifically; I believe perfectly that package maintainers are capable of sorting out this situation in time. The thing is that most users *aren't* package maintainers, and most people who build some application that they download from the net *aren't* the developer of that application. > It's simply doable by runnning fixincludes from kdesdk in the source > directory to make apps/packages compile. This is a job that is too easy for > users, packagers and developers without having to recompile everything ... Sure, but I'll argue that this isn't something we should force users to do. It's the job of the developer to remove legacy headers from their applications. I don't think debian should be forcing users to discover and then work around these problems. > > 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. I don't believe that -DQT_NO_COMPAT should be made into a default option. Again this would mean we force the users to be responsible for updating the developers' legacy code. > Ben, I know that it's been a bit troublesome but OTOH we could have just used > libqt3-compat-headers and do nothing in KDE CVS. Instead, we used fixincludes > to fix the BRANCH so that it doesn't depend on the package. Sure. But we, or the KDE developers could have done that just as easily without splitting the header packages. As you say, it's simple - just run "fixincludes", send your patches upstream and we improve the quality of free software. Without having to split the Qt header packages and cause needless confusion for users trying to compile other software on debian boxes. > And compiling and packaging isn't the only thing that Qt is intended to > be good for, it's mainly for developers developing new software :) Well, no. It's for (a) developers to write software, and (b) users to recompile and/or tweak that software. You're essentially asking that we break (b) in certain situations so that (a) results in less legacy code. Again, I applaud your motives. I nevertheless don't believe that Debian should be the body that polices legacy headers. We should make a distribution where compliation just works, and those of us who wish to encourage better code can simply rebuild apps on our own with -DQT_NO_COMPAT and/or run fixincludes, and pass the patches upstream. > It had to be done sooner or later ... No, I don't think it did, not until TrollTech releases a new Qt upstream with a similar level of anti-legacy enforcement. As it stands now, with a default Qt development environment installed, Qt apps can break on debian where they work everywhere else. > So it seems to me that a good idea would be to include them in the usual > -dev package, and then patch them with #warning directives that say > "foo.h is deprecated and may disappear in the future; please use bar.h". I'm very happy with this proposal. It means builds still work under debian just like every other distribution, but it also means that users and/or developers are made aware of the use of legacy headers, which is your motive AIUI. Ben. :)
kpilot
Does anyone know if there is an eta for kpilot to show up in SID? I've read about the holdup with the network pieces (aka kmail), so I guess what I'm realy asking is kpilot and the other pieces of the PIM (korganizer, kab, etc..) being held up somewhere? (preferably somewhere I could download a copy to install like I did with kmail) Thanks Fizz -- Matt (Fizz) Filizzi http://beyond.hjsoft.com [EMAIL PROTECTED]
Re: Problems with kdemultimedia-kio-plugins
A Dimecres 26 Febrer 2003 20:51, Leopold Palomo Avellaneda va escriure: > > apt-get remove --purge kio-audiocd > > apt-get -f install I forget to say that I did it before. -- Linux User 152692 Catalonia
Re: Problems with kdemultimedia-kio-plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 26 Feb 2003 19:51, Leopold Palomo Avellaneda wrote: > A Dimecres 26 Febrer 2003 20:13, Ralf Nolden va escriure: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Mittwoch, 26. Februar 2003 07:23, Jens Wolfgarten wrote: > > > Hi! > > > > > > I just wanted to upgrade my box with an normal > > > > > > linux:/home/jens# apt-get -u upgrade > > > Reading Package Lists... Done > > > Building Dependency Tree... Done > > > You might want to run `apt-get -f install' to correct these. > > > Sorry, but the following packages have unmet dependencies: > > > kdemultimedia: Depends: kdemultimedia-kio-plugins (>= > > > 4:3.1.0-0woody3) but it is not installed > > > E: Unmet dependencies. Try using -f. > > > > apt-get remove --purge kio-audiocd > > apt-get -f install > > Oh, oh. > > I do : [snip] > lira:/home/palomo# apt-get install kdemultimedia > Reading Package Lists... Done > Building Dependency Tree... Done > The following extra packages will be installed: > kdemultimedia-kio-plugins libarts1-mpeglib mpeglib > The following NEW packages will be installed: > kdemultimedia kdemultimedia-kio-plugins libarts1-mpeglib mpeglib > 0 packages upgraded, 4 newly installed, 0 to remove and 5 not > upgraded. Need to get 0B/504kB of archives. After unpacking 1720kB > will be used. Do you want to continue? [Y/n] Y > (Llegint la base de dades ... 119317 fitxers i directoris instal·lats > actualment.) > Desempaquetant kdemultimedia-kio-plugins (de > .../kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i386.deb) ... > dpkg: error processant > /var/cache/apt/archives/kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i >386.deb (--unpack): > intentant sobreescriure `/usr/lib/kde3/kcm_audiocd.la', que també > està en el paquet kio-audiocd [snip] > /var/cache/apt/archives/kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i >386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) > lira:/home/palomo# > > > > > and so? Please try: dpkg --purge --force-depends kio-audiocd apt-get install kdemultimedia And let us know how that goes. Thank you. Paul Cupis - -- [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+XSd1IzuKV+SHX/kRAhW8AJ9KtqoaOnJ2FtLoCD/DlW2t6g9YxwCfd3fE IybsODJyx6SskDJVCLUX4Tw= =lmeN -END PGP SIGNATURE-
Re: (automatically) making deb's from cvs head
Ralf Nolden wrote at Wednesday 26 February 2003 21:39: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Mittwoch, 26. Februar 2003 09:13, J. Woch wrote: >> Hi list, >> >> I want to (automatically) generate debian packages from kde cvs, >> but since I'm new to packaging I don't even know, where to start. >> Any hints? > Yes. Forget about it. Thanks for the warning ;-) > Orth has been doing debs from HEAD so use these if > you like. Great! However, just the one i'm interested in (kopete), isn't present. Thanks, Jens
kweather dosent update data
hi, i have a short problem with my kweather-applet. since the update to kde3.1 (i run sid and have installed the packages from official debianserver + kdenetwork from cheney) it doesent updates the information. either manualy or automaticly update does the work. have anyone the same problem or has anyone some hints to solve this problem? thanks cu,mirko
Re: KDE 3.1-woody: krec doesn't work
I have exactly the same problem as you have with krec. Must be a bug. Maybe updating Ralph's packages would help. I havn't tryed that yet. Cheers Peter --- Frank Mehnert <[EMAIL PROTECTED]> wrote: > On Tuesday 25 February 2003 14:25, Frank Mehnert > wrote: > > I wonder if _anyone_ has success in using krec > with your (Ralfs) debs under > > Woody? Everything else other than krec works very > well for me. > > PLEASE!!! Could someone who installed Ralf's debs on > Woody please try to > start krec? > > Thanks in advance. > > Frank > -- > ## Dept. of Computer Science, Dresden University of > Technology, Germany ## > ## E-Mail: [EMAIL PROTECTED] > http://os.inf.tu-dresden.de/~fm3 ## > > ATTACHMENT part 2 application/pgp-signature http://mobile.yahoo.com.au - Yahoo! Mobile - Exchange IMs with Messenger friends on your Telstra or Vodafone mobile phone.
Re: Problems with kdemultimedia-kio-plugins
A Dimecres 26 Febrer 2003 20:13, Ralf Nolden va escriure: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Mittwoch, 26. Februar 2003 07:23, Jens Wolfgarten wrote: > > Hi! > > > > I just wanted to upgrade my box with an normal > > > > linux:/home/jens# apt-get -u upgrade > > Reading Package Lists... Done > > Building Dependency Tree... Done > > You might want to run `apt-get -f install' to correct these. > > Sorry, but the following packages have unmet dependencies: > > kdemultimedia: Depends: kdemultimedia-kio-plugins (>= 4:3.1.0-0woody3) > > but it is not installed > > E: Unmet dependencies. Try using -f. > > apt-get remove --purge kio-audiocd > apt-get -f install > Oh, oh. I do : lira:/home/palomo# apt-get remove --purge kdemultimedia kdemultimedia-kio-plugins mpeglib yaf Reading Package Lists... Done Building Dependency Tree... Done Package kdemultimedia-kio-plugins is not installed, so not removed You might want to run `apt-get -f install' to correct these: Sorry, but the following packages have unmet dependencies: libarts1-mpeglib: Depends: mpeglib (>= 4:3.1.0) but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). lira:/home/palomo# apt-get remove --purge kdemultimedia kdemultimedia-kio-plugins mpeglib yaf libarts1-mpeglib Reading Package Lists... Done Building Dependency Tree... Done Package kdemultimedia-kio-plugins is not installed, so not removed The following packages will be REMOVED: kdemultimedia* libarts1-mpeglib* mpeglib* yaf* 0 packages upgraded, 0 newly installed, 4 to remove and 5 not upgraded. 1 packages not fully installed or removed. Need to get 0B of archives. After unpacking 1556kB will be freed. Do you want to continue? [Y/n] Y (Llegint la base de dades ... 119358 fitxers i directoris instal·lats actualment.) Desinstal·lant kdemultimedia ... Desinstal·lant libarts1-mpeglib ... Purgant fitxers de configuració de libarts1-mpeglib ... Desinstal·lant yaf ... Purgant fitxers de configuració de yaf ... Desinstal·lant mpeglib ... Purgant fitxers de configuració de mpeglib ... lira:/home/palomo# apt-get -f install Reading Package Lists... Done Building Dependency Tree... Done 0 packages upgraded, 0 newly installed, 0 to remove and 5 not upgraded. Ok, but if I want: -- lira:/home/palomo# apt-get install kdemultimedia Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: kdemultimedia-kio-plugins libarts1-mpeglib mpeglib The following NEW packages will be installed: kdemultimedia kdemultimedia-kio-plugins libarts1-mpeglib mpeglib 0 packages upgraded, 4 newly installed, 0 to remove and 5 not upgraded. Need to get 0B/504kB of archives. After unpacking 1720kB will be used. Do you want to continue? [Y/n] Y (Llegint la base de dades ... 119317 fitxers i directoris instal·lats actualment.) Desempaquetant kdemultimedia-kio-plugins (de .../kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i386.deb) ... dpkg: error processant /var/cache/apt/archives/kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i386.deb (--unpack): intentant sobreescriure `/usr/lib/kde3/kcm_audiocd.la', que també està en el paquet kio-audiocd dpkg-deb: el subprocés paste fou finalitzat pel senyal (La canonada s'ha trencat) Seleccionant el paquet mpeglib previament no seleccionat. Desempaquetant mpeglib (de .../mpeglib_4%3a3.1.0-0woody3_i386.deb) ... Seleccionant el paquet libarts1-mpeglib previament no seleccionat. Desempaquetant libarts1-mpeglib (de .../libarts1-mpeglib_4%3a3.1.0-0woody3_i386.deb) ... Seleccionant el paquet kdemultimedia previament no seleccionat. Desempaquetant kdemultimedia (de .../kdemultimedia_4%3a3.1.0-0woody3_all.deb) ... S'han trobat errades al processar: /var/cache/apt/archives/kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) lira:/home/palomo# and so? Leo
Re: Upgrade Woody from KDE-2.2.2 to KDE-3.1
A Dimecres 26 Febrer 2003 20:10, Ralf Nolden va escriure: > > I do the same the last week , and I have found differences betweend the > > directories /dist/stable/main/binary-i386 and > > /dist/woody/main/binary-i386. > > > > It's normal? > > No, stable is a symlink to woody. You probably pulled once that version, > once the other directory and in between was my updating of packages :) > Ok, maybe it would be a good idea to put same update in the change log. Did you update daily? Leo
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: Problem processing kdemultimedia-kio-plugins from Ralf's latest update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mittwoch, 26. Februar 2003 05:47, Alexander Antoniades wrote: > Here's the update after retrying to upgrade. I'm assuming this is helpful, > if this isn't please let me know. apt-get remove --purge yaf kio-audiocd apt-get -f install yaf doesn't exist as a package anymore, Chris has probably removed it completely. Ralf > > Sander > output: > (Reading database ... 79159 files and directories currently installed.) > Unpacking kdemultimedia-kio-plugins (from > .../kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i386.deb) ... > dpkg: error processing > /var/cache/apt/archives/kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i386.de >b (--unpack): > trying to overwrite `/usr/lib/kde3/kcm_audiocd.la', which is also in > package kio-audiocd > dpkg-deb: subprocess paste killed by signal (Broken pipe) > Preparing to replace libarts1-audiofile 4:3.1.0-0woody2 (using > .../libarts1-audiofile_4%3a3.1.0-0woody3_i386.deb) ... > Unpacking replacement libarts1-audiofile ... > Preparing to replace mpeglib 4:3.1.0-0woody2 (using > .../mpeglib_4%3a3.1.0-0woody3_i386.deb) ... > Unpacking replacement mpeglib ... > dpkg: error processing > /var/cache/apt/archives/mpeglib_4%3a3.1.0-0woody3_i386.deb (--unpack): > trying to overwrite `/usr/bin/yaf-cdda', which is also in package yaf > dpkg-deb: subprocess paste killed by signal (Broken pipe) > Preparing to replace libarts1-mpeglib 4:3.1.0-0woody2 (using > .../libarts1-mpeglib_4%3a3.1.0-0woody3_i386.deb) ... > Unpacking replacement libarts1-mpeglib ... > Preparing to replace libarts1-xine 4:3.1.0-0woody2 (using > .../libarts1-xine_4%3a3.1.0-0woody3_i386.deb) ... > Unpacking replacement libarts1-xine ... > Preparing to replace noatun 4:3.1.0-0woody2 (using > .../noatun_4%3a3.1.0-0woody3_i386.deb) ... > Unpacking replacement noatun ... > Preparing to replace kdemultimedia 4:3.1.0-0woody2 (using > .../kdemultimedia_4%3a3.1.0-0woody3_all.deb) ... > Unpacking replacement kdemultimedia ... > Errors were encountered while processing: > > /var/cache/apt/archives/kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i386.de >b /var/cache/apt/archives/mpeglib_4%3a3.1.0-0woody3_i386.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) - -- We're not a company, we just produce better code at less costs. - Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+XRJiu0nKi+w1Ky8RAn9MAJsEmOLln/JRFL2VIqzS3D2JVj0ujwCgrDcS C9XzeunxOGF+SSsH/6RTQH8= =4jCy -END PGP SIGNATURE-
Re: May patch these pkg into official?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mittwoch, 26. Februar 2003 06:09, Yun-Ta Tsai wrote: > And how about xft2 and fontconfig? > Because they are together, shall I also file them to xft2 and fontconfig > developers? Or you can contact for me? Please contact them directly and send the patches around. Best is to send all of your patches to all affected development groups because one probably needs to have all patches to verify the overall patch effect. Ralf > > Tim > > On Wednesday 26 February 2003 09:12, Ralf Nolden wrote: > > Tim, > > > > Can you *please* send your patches to [EMAIL PROTECTED] for Qt 3.1.1 > > ASAP, better would be the day you made them. Those are the guys who can > > test-drive them and who will apply them into their packages. It never > > really helps to patch the debian packages if the code doesn't go back, > > Martin and I had to struggle enough to sort out which stuff can go into > > the package and which breaks the API and what not ;-) > > > > Thanks for your contribution though, this is exactly what I would like to > > see more from all these people subscribed - donating a bit of their time > > to make the software better even if it works for them :-) > > > > Ralf - -- We're not a company, we just produce better code at less costs. - Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+XRIWu0nKi+w1Ky8RAnzjAKCpd8raxXSDqzaoQHjjp5FzAKr3eQCbBtGE dS3Yknohys6kQZ/NZQ2TOW4= =mjC3 -END PGP SIGNATURE-
Re: Problems with kdemultimedia-kio-plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mittwoch, 26. Februar 2003 07:23, Jens Wolfgarten wrote: > Hi! > > I just wanted to upgrade my box with an normal > > linux:/home/jens# apt-get -u upgrade > Reading Package Lists... Done > Building Dependency Tree... Done > You might want to run `apt-get -f install' to correct these. > Sorry, but the following packages have unmet dependencies: > kdemultimedia: Depends: kdemultimedia-kio-plugins (>= 4:3.1.0-0woody3) > but it is not installed > E: Unmet dependencies. Try using -f. apt-get remove --purge kio-audiocd apt-get -f install Chris moved around some files as a final touch-up. We're sorry for any inconvenience. Ralf > Paket kio-audiocd ist > dpkg-deb: Unterprozess paste getötet mit Signal (Datenübergabe unterbrochen > (broken pipe)) > Fehler traten auf beim Bearbeiten von: > > /var/cache/apt/archives/kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i386.de >b E: Sub-process /usr/bin/dpkg returned an error code (1) > > What can I do now? > > Thanks > Jens - -- We're not a company, we just produce better code at less costs. - Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+XRHTu0nKi+w1Ky8RAq8YAJ9BoRDoPsEoAE3/h69j1UkJ12zxMgCdGTsc TdhhKMWF4wbEviRLB8a4XHQ= =ilkb -END PGP SIGNATURE-
Re: (automatically) making deb's from cvs head
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mittwoch, 26. Februar 2003 09:13, J. Woch wrote: > Hi list, > > I want to (automatically) generate debian packages from kde cvs, > but since I'm new to packaging I don't even know, where to start. > Any hints? Yes. Forget about it. Orth has been doing debs from HEAD so use these if you like. It is a horrible amount of work to fix problems with the packaging because files get moved around all of the time. Ralf > > Thanks, > Jens - -- We're not a company, we just produce better code at less costs. - Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+XRFru0nKi+w1Ky8RAlT3AKCq6JQqxrRXU8+KB0J/BV5Ahfz1XACgktMd sCjTPRGQrIUb7v7UNgNFzik= =HaA0 -END PGP SIGNATURE-
Re: Upgrade Woody from KDE-2.2.2 to KDE-3.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mittwoch, 26. Februar 2003 10:24, Leopold Palomo Avellaneda wrote: > Questions to Ralf: > > I do the same the last week , and I have found differences betweend the > directories /dist/stable/main/binary-i386 and /dist/woody/main/binary-i386. > > It's normal? No, stable is a symlink to woody. You probably pulled once that version, once the other directory and in between was my updating of packages :) Ralf > > Regards, > > Leo - -- We're not a company, we just produce better code at less costs. - Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+XREsu0nKi+w1Ky8RAjL0AJ0SCJNmLZyfPJ0AXoC9A0d00QwKiACfexUN R8r8ssNBI5C80i7cyIQmINY= =V49x -END PGP SIGNATURE-
Re: Rethinking Qt headers (should the header packages be recombined?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mittwoch, 26. Februar 2003 15:11, Martin Loschwitz wrote: > On Thu, Feb 27, 2003 at 12:16:44AM +1100, Ben Burton wrote: > 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.) Almost all of KDE CVS should be working without the compat-headers, at least BRANCH does now and HEAD will follow as soon as we go on packaging HEAD again. It's simply doable by runnning fixincludes from kdesdk in the source directory to make apps/packages compile. This is a job that is too easy for users, packagers and developers without having to recompile everything, just run fixincludes, if you only want to compile an app, you're fine, if you're a packager make a diff and send it upstream. That was the intention of the compat-headers package because it will improve any app that has been made using Qt in its source base, and thus will help the quality of free software in general. > 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 :) Ben, I know that it's been a bit troublesome but OTOH we could have just used libqt3-compat-headers and do nothing in KDE CVS. Instead, we used fixincludes to fix the BRANCH so that it doesn't depend on the package. Getting rid of these compat headers is task #1 to get better quality sourcecode working with Qt 3, packagers will have some work with Qt 3 packages as well to make them all pick up libqt-mt correctly also. The main reason is the long-term goal, not the short term "it doesn't compile for me, I had to read the README.Debian" thing. There are several really cool things now like that qmake works perfect for any given Qt package made with qmake (and there are a lot popping up recently already, altough qmake sucks for make install). And we can improve the software packages. Which means, the next version of Debian is prepared for anything that is going beyond Qt 3 as best as it can be, and also the packages that debian contains. The reason to strip the compat-headers out is to only give programmers exactly those files that they're supposed to be using, not files that they shouldn't be using at all. And compiling and packaging isn't the only thing that Qt is intended to be good for, it's mainly for developers developing new software :) So, please let's stay with the packages now. The experience of the whole restructured thing is very very new to most people, developers, packagers and users. If it hadn't been such a mess it would have been easier for them now but unfortunately that wasn't the case. It had to be done sooner or later and I'm glad we're finished with that, waiting longer would have been a crime against the quality of debian and free software :) Ralf PS: I didn't take the time to write a lengthy README.Debian for Qt to explain everything for people not to read it. So if you don't know what to do if you hit a problem with the packages, RTFM :) > > Anyway, let's see what Ralf thinks about this issue. > > > Ben. :) - -- We're not a company, we just produce better code at less costs. - Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+XRCou0nKi+w1Ky8RAtIZAJ0Z8v+xFZtuNii4/563BrnSZIC1sACfT5Lk PzKtLb71A3fvs0D6Gg2p4B8= =geGi -END PGP SIGNATURE-
unsubscribe
unsubscribe
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
Rethinking Qt headers (should the header packages be recombined?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (If you don't want to read this entire email, feel free to jump straight down to [SUMMARY]). Hi. So we've had a little time with the new Qt header structure (package libqt3-headers containing the primary Qt headers and package libqt3-compat-headers containing legacy headers for compatibility purposes), and I'm not entirely sure this is being done correctly. The situation as it stands is this: various Qt headers have been deprecated, but are still used throughout a variety of Qt apps (including the current KDE release and a large number of third-party KDE apps). The upstream Qt still provides these deprecated headers, which simply #include the new headers that replace them. 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. 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. 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. On the other hand, say a user *does* have libqt3-compat-headers installed. In this case they see no benefit from the package split at all, since everything builds smoothly, legacy headers or no. [SUMMARY] I do applaud the effort to remove legacy headers from current Qt code. However, I don't think the debian package management system is the correct tool with which to do it. At the least it will cause confusion among users (as it already seems to be doing AFAICT), and to gain full benefit from this package split, you'd have to remember to uninstall libqt3-compat-headers every time you want to test a new source tree for legacy headers. 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). So on reflection I'd be much happier if all the Qt headers were combined back into the libqt3-headers package, or alternatively if libqt3-dev and libqt3-mt-dev can be made to depend on libqt3-compat-headers. Do other people have thoughts on this? Ben. :) - -- Ben Burton [EMAIL PROTECTED] Public Key: finger [EMAIL PROTECTED] I like to think of Linux development as sort of a modified IETF style: rough consensus and running code, with a sprinkle of holy penguin pee when Linus thinks it's ready to ship. - Seen on slashdot -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+XL5AMQNuxza4YcERAgpNAJ9x027KIV1UH5NtiZQP7DpwvkmggwCfddny EQ4eKKck0EnMtckRCkic3y0= =zLCt -END PGP SIGNATURE-
Re: mouse bad configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 26 Feb 2003 07:15, Martin wrote: > Hi: I try to install debian woody in an AMD duron 750 with a genius > netmouse pro with a ps/2 plug. > when I was prompted, I choose netmouse/ps2 but when KDE starts up > the mouse cursor seems to like the under left corner of the screen > -it does move just a little an then goes back- (and do some sort of > strange things, like open aplications that I don't want to). > So I think that I've made a bad choice when selecting the mouse > type. If any of you knows the way to reconfigure the mouse I'll be > very gratefull if you tell me what command to run. dpkg-reconfigure xserver-xfree86 should be the command to run. Just accept the defaults for all of the answers except for the mouse ones (which you'll want to change). You might try the PS/2 option (or imPS/2 if you have a wheel on your mouse). Regards, Paul Cupis - -- [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+XJSZIzuKV+SHX/kRAiosAJ40/imyi84BM8vMQ9ERV9qJSqJm2ACeJLGK 0aCywS+ctfVs/z7uf5rBMpQ= =WHdL -END PGP SIGNATURE-
Re: Upgrade Woody from KDE-2.2.2 to KDE-3.1
A Dimecres 26 Febrer 2003 02:00, Ralf Nolden va escriure: > > > > On his site, he only suggests this if you've installed any of the interum > > KDE stuff. I've only ever had the Official Debian KDE2.2.2, therefore it > > 'should upgrade cleanly. > > It should, but it may not do it cleanly and you'll run into conflicts Sure you will have conflicts. > > me. I don't want to remove it first, as I use it on a regular basis and > > need it for my desktop. > > You'll get a 3.1 for it, so what do you want more ? :-) > I updated my box from 3.0.3 to 3.1 (Ralf packages) the last week. More or less it was ok. But I can recommend you one thing for your case I have done before an wget -k -m --no-parent http://ktown.kde.org/~nolden/kde/dists/stable/main/binary-i386/ so, I can do a CD mirror of ktown, and after I do a apt-cdrom. I do this, because if something is wrong you can update, or restore without a dialup. Questions to Ralf: I do the same the last week , and I have found differences betweend the directories /dist/stable/main/binary-i386 and /dist/woody/main/binary-i386. It's normal? Regards, Leo
Re: KDE 3.1-woody: krec doesn't work
On Tuesday 25 February 2003 14:25, Frank Mehnert wrote: > I wonder if _anyone_ has success in using krec with your (Ralfs) debs under > Woody? Everything else other than krec works very well for me. PLEASE!!! Could someone who installed Ralf's debs on Woody please try to start krec? Thanks in advance. Frank -- ## Dept. of Computer Science, Dresden University of Technology, Germany ## ## E-Mail: [EMAIL PROTECTED]http://os.inf.tu-dresden.de/~fm3 ## pgppBTFuexiGK.pgp Description: signature
Re: unsubcribe
On Tue, Feb 25, 2003 at 01:00:15PM -0400, Derek Broughton wrote: > From: "Kaupo" <[EMAIL PROTECTED]> > > > > unsubcribe > > aARGH! How can you filter out this sort of stuff if people can't even spell > unsubscribe! > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > Duh? Well, I guess you can't expect people who can't read to be able to > write... The best thing to do with these people is to beat them over the head with a wooden spoon! Isn't there a way to make these emails come in a daily digest? So many come through, and it would be nice to just give a daily summary of all the emails, rather than right when they're emailed, just like other mailing lists. Rene -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
(automatically) making deb's from cvs head
Hi list, I want to (automatically) generate debian packages from kde cvs, but since I'm new to packaging I don't even know, where to start. Any hints? Thanks, Jens
mouse bad configuration
Hi: I try to install debian woody in an AMD duron 750 with a genius netmouse pro with a ps/2 plug. when I was prompted, I choose netmouse/ps2 but when KDE starts up the mouse cursor seems to like the under left corner of the screen -it does move just a little an then goes back- (and do some sort of strange things, like open aplications that I don't want to). So I think that I've made a bad choice when selecting the mouse type. If any of you knows the way to reconfigure the mouse I'll be very gratefull if you tell me what command to run. Thanks in advance. Martin Nigoul.
Problems with kdemultimedia-kio-plugins
Hi! I just wanted to upgrade my box with an normal linux:/home/jens# apt-get -u upgrade Reading Package Lists... Done Building Dependency Tree... Done You might want to run `apt-get -f install' to correct these. Sorry, but the following packages have unmet dependencies: kdemultimedia: Depends: kdemultimedia-kio-plugins (>= 4:3.1.0-0woody3) but it is not installed E: Unmet dependencies. Try using -f. Then I run: linux:/home/jens# apt-get install -f Reading Package Lists... Done Building Dependency Tree... Done Correcting dependencies... Done The following extra packages will be installed: kdemultimedia-kio-plugins The following NEW packages will be installed: kdemultimedia-kio-plugins 0 packages upgraded, 1 newly installed, 0 to remove and 1 not upgraded. 33 packages not fully installed or removed. Need to get 0B/62.8kB of archives. After unpacking 229kB will be used. Do you want to continue? [Y/n] y (Lese Datenbank ... 79469 Dateien und Verzeichnisse sind derzeit installiert.) Entpacke kdemultimedia-kio-plugins (aus .../kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i386.deb) ... dpkg: Fehler beim Bearbeiten von /var/cache/apt/archives/kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i386.deb (--unpack): versuche »/usr/lib/kde3/kcm_audiocd.la« zu überschreiben, welches auch in Paket kio-audiocd ist dpkg-deb: Unterprozess paste getötet mit Signal (Datenübergabe unterbrochen (broken pipe)) Fehler traten auf beim Bearbeiten von: /var/cache/apt/archives/kdemultimedia-kio-plugins_4%3a3.1.0-0woody3_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) What can I do now? Thanks Jens
