Replacing a single file with Replaces:
In the policy manual, section 7.5.1 "Overwriting files in other packages" it says: "However, if the overwriting package declares that it Replaces the one containing the file being overwritten, then dpkg will replace the file from the old package with that from the new. The file will no longer be listed as `owned' by the old package. " I read that to mean that you can actually replace a single file from a package, in another package. But I can't get that to work. If I put "Replaces:" and the package name which I want to replace a file in, dpkg still aborts and says that the file exists in multiple packages. How to get this feature to work, to replace a single file in a package from within another package? -- Karolina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Replacing a single file with Replaces:
tisdagen den 12 november 2002 11.09 skrev Andrea Mennucc: > can you post a copy of your debian/control file? I have to come back with this and construct an example. -- Karolina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What does dpkg-source mean with this?
When I run this, I get the following error messages. What does it mean? Which file(s) are already existing? $ dpkg-source -b noteedit-2.0.16 noteedit_2.0.16.orig.tar.gz dpkg-source: building noteedit using existing noteedit_2.0.16.orig.tar.gz tar: noteedit-2.0.16/doc/noteedit/afterCombine.png: Cannot open: File exists tar: noteedit-2.0.16/doc/noteedit/afterCombine.png: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/water1.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/water2.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey1.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey2.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey3.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey4.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey5.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/water1.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/water2.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey1.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey2.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey3.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey4.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey5.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/noteedit.desktop: Cannot open: File exists tar: noteedit-2.0.16/noteedit/resources/breve.ppm: Cannot open: File exists tar: noteedit-2.0.16/noteedit/resources/breve.xbm: Cannot open: File exists tar: noteedit-2.0.16/noteedit/resources/breve_grey.ppm: Cannot open: File exists tar: noteedit-2.0.16/noteedit/resources/breve_red.ppm: Cannot open: File exists tar: noteedit-2.0.16/INSTALL: Cannot open: File exists tar: Error exit delayed from previous errors dpkg-source: failure: tar -xkf - gave error exit status 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What does dpkg-source mean with this?
tisdagen den 12 november 2002 21.28 skrev Roger Leigh: > It looks like all the files are pre-existing. Try running dpkg-source > -b from another directory or renaming the noteedit-2.0.16 directory? That might be the problem, so please bear me with some questions so that I get this very clear to me: When you take a tar file from somewhere and make a debian package of it, should it be unchanged from upstream or can it be modified? For example, should (in this case) noteedit_2.0.16.orig.tar.gz extract to noteedit, noteedit-2.0.16 or noteedit-2.0.16.orig? Does it matter? Can the source tar file be called noteedit-2.0.16.tar or should it be renamed to noteedit_2.0.16.orig.tar If there is an old debian directory in the upstreams tar file, for some old debian version. Should that be removed? If there are bin-files or *.o files or similar in the upstreams tar file. Should they be removed? In KDE applications, normally a "make -f Makefile.cvs" (or similar) is done before the upstreams tar file is packed. But often that is done with another version of automake than debian is using. Often an old automake1.4 or something. If some changes are needed to the *.am files, that will create problems due to automake incompatibilites. If no changes to the *.am files is needed, it might work even with incompatible versions, since automake is never called, but it might create trouble if something is changed. One solution is to make a "make -f Makefile.cvs" before building it on debian, but then the diffs with all the Makefile.in files etc. will become huge. Can that be done before packing the *.orig.tar file, to avoid rebuilding problems and making the diffs small? Many questions, but it is things that I have been wondering about. -- Karolina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What to do with wrong files from upstreams
tisdagen den 12 november 2002 21.28 skrev Roger Leigh: > It looks like all the files are pre-existing. Try running dpkg-source > -b from another directory or renaming the noteedit-2.0.16 directory? ... And then yet another question. When I get the following error message: In file included from knat_toolbar.cpp:18: knat.moc:17: #error "This file was generated using the moc from 3.0.5. It" knat.moc:18: #error "cannot be used with the include files from this version of Qt." knat.moc:19: #error "(The moc has changed too much.)" Oobviously I need to rebuild the *.moc files that comes from upstreams that are not deleted by "make distclean". Sometimes that goes automatically by the Makefile if the moc file is removed. How should I handle this gracefully? Delete the *.moc files from the *.orig.tar file, delete them in the debian/rules files, delete them in the "clean" rule or something else? -- Karolina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do with wrong files from upstreams
Wednesday 13 November 2002 22.30 skrev Roger Leigh: > The `clean' rule is run before the build (by dpkg-buildpackage), so I > would do > > find . -name '*.moc' | xargs rm -f > > to remove the .moc files. If they can easily be regenerated, I would > ask upstream to remove them from the tarball (but I'm not a Qt/KDE > expert). Make sure you Build-Depend on libqt-dev (which provides > moc)! So I guess this is the best thing to do in this case, and as you say, ask upstream to remove the files that are regenerated in the makefile. -- Karolina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What does dpkg-source mean with this?
Wednesday 13 November 2002 12.18 skrev Paul Cupis: > It can be modified. It should be unchanged. Being unchanged has beneifts > including but not limited to allowing users to verify the original tgz with > upstream and clearly showing (in the diff.gz) what changes were made during > packaging. If these changes can be sent upstream for inclusion in a later > release of the software, geat. Ok, I understand. Unmodified if possible, even if dpkg-source complains. > It doesn't matter. dpkg-source will extract the tgz to a correctly named > directory. It appears that it does not do that in the noteedit case, since it tries to extract over the build-directory. So something else is wrong. > It should be called noteedit_2.0.16.orig.tar.gz, per the packaging manual. Meaning the only modification is to change the name? > I would be inclined to leave it in the orig.tar.gz, but either patch it or > remove in the build process (in the clean target?). I'm don't have the > details of how to best do this handy, but iirc, this is the recommended > solution. The problem is that the diff file becomes hard to understand, and you can't use the same diff file on a later version of the program, but have to unpack the version matching the diff file first, save the debian dir, and then unpack the version you want to build, remove the patches to the debian dir from the diff file, and apply the patches (if any). Therefore I actually prefer a clean debian dir in the tar file when the patch file is made. Of if somehow the debian files in the diff file can just completely replace the old ones with some diff option. If it is possible to make debian-source to understand that. > Not by you? Bug upstream about it, i think. Again, this is related to > having a pristine upstream orig.tar.gz if possible (but this is not > essential). So if there are any, I should just leave them and remove them in the clean target. -- Karolina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to include a binary file
How do I include a binary file like a .png file in the diff? I need to include a PNG file with the application icon, which is not supplied in the upstreams tar. -- Karolina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to include a binary file
tisdagen den 3 december 2002 09.32 skrev Karolina Lindqvist: > How do I include a binary file like a .png file in the diff? > I need to include a PNG file with the application icon, which is not > supplied in the upstreams tar. Sorry for that, that question was just answered recently. -- Karolina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Missing files in /etc
I have a problem with files in /etc As I understand, they are marked as "conffiles". The problem is if such a file is missing, it won't be reinstalled. How to tell the package system that this file should be reinstalled if it is deleted? i.e. The file is essential, and can't be missing. This has happened a few times, when upgrading packages, possibly from an eariler version. So I at least thought about a check, saying "file XXX is missing, it is an essential file, reinstall by doing YYY', or something like that. Only that I don't know what to tell apt-get to reinstall such files. And then, if another file should not be reinstalled, only the essential ones, how to deal with that? There does not appear to be any option to apt-get that does a --force-confmiss When doing a dpkg -i --force-confmiss /u/apt/archives/libkdecore-data_4%3a3.1.0+rc6+kl-1_all.deb I got the following messages: Configuration file `/etc/kde3/colors/Web', does not exist on system. Installing new config file as you request. Configuration file `/etc/kde3/language.codes', does not exist on system. Installing new config file as you request. Configuration file `/etc/kde3/system.kdeglobals', does not exist on system. Installing new config file as you request. That is clearly unacceptable. I wonder how many users of my packages that have missing files, and get unexpected errors due to that. I have gotten bug reports from more than one person regarding missing files. So I want some system so that this does not happen unless intentional. Karolina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Missing files in /etc
onsdagen den 8 januari 2003 18.57 skrev Raphael Hertzog: > apt-get -o dpkg::options::="--force-confmiss" > > You can put it once for all in a file in /etc/apt/apt.conf.d/. > Check man apt.conf for details. That is the individual solution when the trouble is there. But is there no way to make the package so that the trouble does not occur, or at least is warned for? Karolina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Missing files in /etc
fredagen den 10 januari 2003 16.49 skrev Bob Hilliard: > Policy prohibits overriding conffiles that have been changed by > the admin. Deleting a file is considered changing it. One must > assume that the admin deleted the file for a reason. Debian does not > prevent users from shooting themselves in the foot. However, I > believe the new conffile will be installed as .dpkg-dist. The problem is that those files sometimes tend to disappear by themselves in some instances when upgrading. I don't know what circumstances. Maybe due to bugs in the packages? Maybe aborted upgrades? It is a reoccuring thing on the debian-kde list that someone has one of the essential files missing. And as the problem occur often enough, I was thinking about somehow safeguarding that it can't happen. If there are no mechanism that can prohibit this behaviour, the only thing I can think about is a shell-script in a postinst file that checks for the essential files. Or in preinst, that checks for this file, and somehow tell dpkg to install it, if I could just figure out what that could be. Does that sound like a good idea? Karolina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Missing files in /etc
fredagen den 10 januari 2003 20.06 skrev Stephen Gran: > I've seen this behavior occasionally on some of my boxes, and I wonder > if the problem is that the newer version of a pckage has a conffile that > the older version doesn't have. Hmmm . . not very clear. Like this: > > package-foo_1.2 conffiles: file1 > file2 > > package-foo_2.0 conffiles: file1 > file2 > file3 > > Does dpkg interpret the (missing) state of file3 as appropriate? I > haven't had the chance to investigate. I would think that the intended > behavior is no, but I've seen this come up on various lists and here, so > I wonder. I just got a report of a file in etc missing in one of my packages. It was a mistake, and I put it in. Installing it, replacing the old package, installed the file, so I think that answers that question. If a new file comes as a conffile, that was not in the previous version of the same package, it gets installed. Still I don't understand the circumstances for which a file is not installed, when upgrading. It should not happen, but it does occasionally. The new KDE, when it goes to SID, will have a potential to get this error since it has a very essential file in /etc. Let's see if anyone will get this problem when upgrading. If not, it is a very rare thing. Karolina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to debug apt-get dependencies
The subject line says it all. I have a condition where apt-get refuses to upgrade. How can I figure out exactly what apt-get does not like: Here follows my example run. The reason I use a versioned install is just because otherwise apt-get just refuses to consider the upgrade. This is a problem I have gotten before and found it quite hard to figure out the reason, and is never sure if I really got the right solution. There must be a way to figure out exactly what goes wrong. First: shakti:~# dpkg --compare-versions '4:3.1.0++kl-1' '>' '4:3.1.0+rc6+kl-3'; echo "$?" 0 Ok, version 4:3.1.0++kl-1 is the greater version. Now: shakti:~# apt-get install -t unstable libkdecore4 Reading Package Lists... Done Building Dependency Tree... Done Sorry, libkdecore4 is already the newest version. Done 0 packages upgraded, 0 newly installed, 0 to remove and 58 not upgraded. Ooops. already the newest version? But what about the following, and the compare-version above: shakti:~# apt-cache show libkdecore4 | grep Version Version: 4:3.1.0++kl-1 Version: 4:3.1.0+rc6+kl-3 shakti:~# Let's try this: shakti:~# apt-get install -t unstable libkdecore4=4:3.1.0++kl-1 Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: Sorry, but the following packages have unmet dependencies: libkdecore4: Depends: libdcop4 (>= 4:3.1.0++kl) but 4:3.1.0+rc6+kl-3 is to be installed Depends: libkdefx4 (>= 4:3.1.0++kl) but 4:3.1.0+rc6+kl-3 is to be installed Depends: kdeinit4 (= 4:3.1.0++kl-1) but 4:3.1.0+rc6+kl-3 is to be installed Depends: libkdecore-data but it is not going to be installed E: Sorry, broken packages Note here that all those missing packages are existing, and according to the dpkg compare-version above, have higher version numbers. apt-get is doing the wrong thing above. Why is it not updating those packages shown, libdcop4, libkdefx4 and kdeinit4, when there are newer version available that will satisfy the dependencies? the full output of the run follows in the end Karolina shakti:~# apt-get install -t unstable libkdecore4=4:3.1.0++kl-1 Reading Package Lists... Done Building Dependency Tree... Done Starting Starting 2 Investigating libkdecore4 Package libkdecore4 has broken dep on libdcop4 Considering libdcop4 2082 as a solution to libkdecore4 11796 Package libkdecore4 has broken dep on libkdefx4 Considering libkdefx4 2079 as a solution to libkdecore4 11796 Package libkdecore4 has broken dep on kdeinit4 Considering kdeinit4 1024 as a solution to libkdecore4 11796 Investigating libkdecore-data Package libkdecore-data has broken dep on libkdecore4 Considering libkdecore4 11796 as a solution to libkdecore-data 285 Removing libkdecore-data rather than change libkdecore4 Investigating kdelibs4 Package kdelibs4 has broken dep on libkdecore4 Considering libkdecore4 11796 as a solution to kdelibs4 3 Removing kdelibs4 rather than change libkdecore4 Investigating kdelibs-dev Package kdelibs-dev has broken dep on libkdecore4 Considering libkdecore4 11796 as a solution to kdelibs-dev 3 Removing kdelibs-dev rather than change libkdecore4 Investigating ksms Package ksms has broken dep on kdelibs4 Considering kdelibs4 3 as a solution to ksms 0 Removing ksms rather than change kdelibs4 Investigating kio-locate Package kio-locate has broken dep on kdelibs4 Considering kdelibs4 3 as a solution to kio-locate 0 Removing kio-locate rather than change kdelibs4 Investigating libkdegames-dev Package libkdegames-dev has broken dep on kdelibs-dev Considering kdelibs-dev 3 as a solution to libkdegames-dev 0 Removing libkdegames-dev rather than change kdelibs-dev Investigating libkscan-dev Package libkscan-dev has broken dep on kdelibs-dev Considering kdelibs-dev 3 as a solution to libkscan-dev 0 Removing libkscan-dev rather than change kdelibs-dev Investigating kickpim Package kickpim has broken dep on kdelibs4 Considering kdelibs4 3 as a solution to kickpim 0 Removing kickpim rather than change kdelibs4 Investigating koffice-dev Package koffice-dev has broken dep on kdelibs-dev Considering kdelibs-dev 3 as a solution to koffice-dev 0 Removing koffice-dev rather than change kdelibs-dev Investigating libkdecore4 Package libkdecore4 has broken dep on libdcop4 Considering libdcop4 2082 as a solution to libkdecore4 11796 Package libkdecore4 has broken dep on libkdefx4 Considering libkdefx4 2079 as a solution to libkdecore4 11796 Package libkdecore4 has broken dep on kdeinit4 Considering kdeinit4 1024 as a solution to libkdecore4 11796 Package libk
Looking for a sponsor
I have been inofficially packing KDE 3.1 since several months. I have also packed a number of KDE 3.1 applications (47 different right now) together with it. (But that is fast packing, without bug fixing, except for making them build) Now KDE 3.1 is going to make it into SID, so I was thinking that I maybe can pack a couple of applications for KDE 3.1. Just a one or two, or something, or whatever is needed. But as I am not a debian developer, I need some sponsor. I guess someone who uses KDE. I have really no preference of which KDE application(s) to pack, just as long as I don't have to rewrite it, and I at least understand how to use it and thus can test it. Any takers or suggestions? Karolina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for a sponsor
fredagen den 31 januari 2003 14.03 skrev Russell Coker: > On Thu, 30 Jan 2003 20:04, Karolina Lindqvist wrote: > > Any takers or suggestions? > > I'll sponsor you if no-one else does, particularly if you take kdm. Thank you. Unfortunately kdm is part of KDE, and can't be separated. That is, it is already claimed. Otherwise I would not mind. Karolina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Replacing a single file with Replaces:
In the policy manual, section 7.5.1 "Overwriting files in other packages" it says: "However, if the overwriting package declares that it Replaces the one containing the file being overwritten, then dpkg will replace the file from the old package with that from the new. The file will no longer be listed as `owned' by the old package. " I read that to mean that you can actually replace a single file from a package, in another package. But I can't get that to work. If I put "Replaces:" and the package name which I want to replace a file in, dpkg still aborts and says that the file exists in multiple packages. How to get this feature to work, to replace a single file in a package from within another package? -- Karolina
Re: Replacing a single file with Replaces:
tisdagen den 12 november 2002 11.09 skrev Andrea Mennucc: > can you post a copy of your debian/control file? I have to come back with this and construct an example. -- Karolina
What does dpkg-source mean with this?
When I run this, I get the following error messages. What does it mean? Which file(s) are already existing? $ dpkg-source -b noteedit-2.0.16 noteedit_2.0.16.orig.tar.gz dpkg-source: building noteedit using existing noteedit_2.0.16.orig.tar.gz tar: noteedit-2.0.16/doc/noteedit/afterCombine.png: Cannot open: File exists tar: noteedit-2.0.16/doc/noteedit/afterCombine.png: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/water1.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/water2.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey1.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey2.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey3.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey4.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey5.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/water1.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/water2.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey1.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey2.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey3.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey4.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/lyrics/whiskey5.txt: Cannot open: File exists tar: noteedit-2.0.16/noteedit/noteedit.desktop: Cannot open: File exists tar: noteedit-2.0.16/noteedit/resources/breve.ppm: Cannot open: File exists tar: noteedit-2.0.16/noteedit/resources/breve.xbm: Cannot open: File exists tar: noteedit-2.0.16/noteedit/resources/breve_grey.ppm: Cannot open: File exists tar: noteedit-2.0.16/noteedit/resources/breve_red.ppm: Cannot open: File exists tar: noteedit-2.0.16/INSTALL: Cannot open: File exists tar: Error exit delayed from previous errors dpkg-source: failure: tar -xkf - gave error exit status 2
Re: What does dpkg-source mean with this?
tisdagen den 12 november 2002 21.28 skrev Roger Leigh: > It looks like all the files are pre-existing. Try running dpkg-source > -b from another directory or renaming the noteedit-2.0.16 directory? That might be the problem, so please bear me with some questions so that I get this very clear to me: When you take a tar file from somewhere and make a debian package of it, should it be unchanged from upstream or can it be modified? For example, should (in this case) noteedit_2.0.16.orig.tar.gz extract to noteedit, noteedit-2.0.16 or noteedit-2.0.16.orig? Does it matter? Can the source tar file be called noteedit-2.0.16.tar or should it be renamed to noteedit_2.0.16.orig.tar If there is an old debian directory in the upstreams tar file, for some old debian version. Should that be removed? If there are bin-files or *.o files or similar in the upstreams tar file. Should they be removed? In KDE applications, normally a "make -f Makefile.cvs" (or similar) is done before the upstreams tar file is packed. But often that is done with another version of automake than debian is using. Often an old automake1.4 or something. If some changes are needed to the *.am files, that will create problems due to automake incompatibilites. If no changes to the *.am files is needed, it might work even with incompatible versions, since automake is never called, but it might create trouble if something is changed. One solution is to make a "make -f Makefile.cvs" before building it on debian, but then the diffs with all the Makefile.in files etc. will become huge. Can that be done before packing the *.orig.tar file, to avoid rebuilding problems and making the diffs small? Many questions, but it is things that I have been wondering about. -- Karolina
What to do with wrong files from upstreams
tisdagen den 12 november 2002 21.28 skrev Roger Leigh: > It looks like all the files are pre-existing. Try running dpkg-source > -b from another directory or renaming the noteedit-2.0.16 directory? ... And then yet another question. When I get the following error message: In file included from knat_toolbar.cpp:18: knat.moc:17: #error "This file was generated using the moc from 3.0.5. It" knat.moc:18: #error "cannot be used with the include files from this version of Qt." knat.moc:19: #error "(The moc has changed too much.)" Oobviously I need to rebuild the *.moc files that comes from upstreams that are not deleted by "make distclean". Sometimes that goes automatically by the Makefile if the moc file is removed. How should I handle this gracefully? Delete the *.moc files from the *.orig.tar file, delete them in the debian/rules files, delete them in the "clean" rule or something else? -- Karolina
Re: What to do with wrong files from upstreams
Wednesday 13 November 2002 22.30 skrev Roger Leigh: > The `clean' rule is run before the build (by dpkg-buildpackage), so I > would do > > find . -name '*.moc' | xargs rm -f > > to remove the .moc files. If they can easily be regenerated, I would > ask upstream to remove them from the tarball (but I'm not a Qt/KDE > expert). Make sure you Build-Depend on libqt-dev (which provides > moc)! So I guess this is the best thing to do in this case, and as you say, ask upstream to remove the files that are regenerated in the makefile. -- Karolina
Re: What does dpkg-source mean with this?
Wednesday 13 November 2002 12.18 skrev Paul Cupis: > It can be modified. It should be unchanged. Being unchanged has beneifts > including but not limited to allowing users to verify the original tgz with > upstream and clearly showing (in the diff.gz) what changes were made during > packaging. If these changes can be sent upstream for inclusion in a later > release of the software, geat. Ok, I understand. Unmodified if possible, even if dpkg-source complains. > It doesn't matter. dpkg-source will extract the tgz to a correctly named > directory. It appears that it does not do that in the noteedit case, since it tries to extract over the build-directory. So something else is wrong. > It should be called noteedit_2.0.16.orig.tar.gz, per the packaging manual. Meaning the only modification is to change the name? > I would be inclined to leave it in the orig.tar.gz, but either patch it or > remove in the build process (in the clean target?). I'm don't have the > details of how to best do this handy, but iirc, this is the recommended > solution. The problem is that the diff file becomes hard to understand, and you can't use the same diff file on a later version of the program, but have to unpack the version matching the diff file first, save the debian dir, and then unpack the version you want to build, remove the patches to the debian dir from the diff file, and apply the patches (if any). Therefore I actually prefer a clean debian dir in the tar file when the patch file is made. Of if somehow the debian files in the diff file can just completely replace the old ones with some diff option. If it is possible to make debian-source to understand that. > Not by you? Bug upstream about it, i think. Again, this is related to > having a pristine upstream orig.tar.gz if possible (but this is not > essential). So if there are any, I should just leave them and remove them in the clean target. -- Karolina
How to include a binary file
How do I include a binary file like a .png file in the diff? I need to include a PNG file with the application icon, which is not supplied in the upstreams tar. -- Karolina
Re: How to include a binary file
tisdagen den 3 december 2002 09.32 skrev Karolina Lindqvist: > How do I include a binary file like a .png file in the diff? > I need to include a PNG file with the application icon, which is not > supplied in the upstreams tar. Sorry for that, that question was just answered recently. -- Karolina
Missing files in /etc
I have a problem with files in /etc As I understand, they are marked as "conffiles". The problem is if such a file is missing, it won't be reinstalled. How to tell the package system that this file should be reinstalled if it is deleted? i.e. The file is essential, and can't be missing. This has happened a few times, when upgrading packages, possibly from an eariler version. So I at least thought about a check, saying "file XXX is missing, it is an essential file, reinstall by doing YYY', or something like that. Only that I don't know what to tell apt-get to reinstall such files. And then, if another file should not be reinstalled, only the essential ones, how to deal with that? There does not appear to be any option to apt-get that does a --force-confmiss When doing a dpkg -i --force-confmiss /u/apt/archives/libkdecore-data_4%3a3.1.0+rc6+kl-1_all.deb I got the following messages: Configuration file `/etc/kde3/colors/Web', does not exist on system. Installing new config file as you request. Configuration file `/etc/kde3/language.codes', does not exist on system. Installing new config file as you request. Configuration file `/etc/kde3/system.kdeglobals', does not exist on system. Installing new config file as you request. That is clearly unacceptable. I wonder how many users of my packages that have missing files, and get unexpected errors due to that. I have gotten bug reports from more than one person regarding missing files. So I want some system so that this does not happen unless intentional. Karolina
Re: Missing files in /etc
onsdagen den 8 januari 2003 18.57 skrev Raphael Hertzog: > apt-get -o dpkg::options::="--force-confmiss" > > You can put it once for all in a file in /etc/apt/apt.conf.d/. > Check man apt.conf for details. That is the individual solution when the trouble is there. But is there no way to make the package so that the trouble does not occur, or at least is warned for? Karolina
Re: Missing files in /etc
fredagen den 10 januari 2003 16.49 skrev Bob Hilliard: > Policy prohibits overriding conffiles that have been changed by > the admin. Deleting a file is considered changing it. One must > assume that the admin deleted the file for a reason. Debian does not > prevent users from shooting themselves in the foot. However, I > believe the new conffile will be installed as .dpkg-dist. The problem is that those files sometimes tend to disappear by themselves in some instances when upgrading. I don't know what circumstances. Maybe due to bugs in the packages? Maybe aborted upgrades? It is a reoccuring thing on the debian-kde list that someone has one of the essential files missing. And as the problem occur often enough, I was thinking about somehow safeguarding that it can't happen. If there are no mechanism that can prohibit this behaviour, the only thing I can think about is a shell-script in a postinst file that checks for the essential files. Or in preinst, that checks for this file, and somehow tell dpkg to install it, if I could just figure out what that could be. Does that sound like a good idea? Karolina
Re: Missing files in /etc
fredagen den 10 januari 2003 20.06 skrev Stephen Gran: > I've seen this behavior occasionally on some of my boxes, and I wonder > if the problem is that the newer version of a pckage has a conffile that > the older version doesn't have. Hmmm . . not very clear. Like this: > > package-foo_1.2 conffiles: file1 > file2 > > package-foo_2.0 conffiles: file1 > file2 > file3 > > Does dpkg interpret the (missing) state of file3 as appropriate? I > haven't had the chance to investigate. I would think that the intended > behavior is no, but I've seen this come up on various lists and here, so > I wonder. I just got a report of a file in etc missing in one of my packages. It was a mistake, and I put it in. Installing it, replacing the old package, installed the file, so I think that answers that question. If a new file comes as a conffile, that was not in the previous version of the same package, it gets installed. Still I don't understand the circumstances for which a file is not installed, when upgrading. It should not happen, but it does occasionally. The new KDE, when it goes to SID, will have a potential to get this error since it has a very essential file in /etc. Let's see if anyone will get this problem when upgrading. If not, it is a very rare thing. Karolina
How to debug apt-get dependencies
The subject line says it all. I have a condition where apt-get refuses to upgrade. How can I figure out exactly what apt-get does not like: Here follows my example run. The reason I use a versioned install is just because otherwise apt-get just refuses to consider the upgrade. This is a problem I have gotten before and found it quite hard to figure out the reason, and is never sure if I really got the right solution. There must be a way to figure out exactly what goes wrong. First: shakti:~# dpkg --compare-versions '4:3.1.0++kl-1' '>' '4:3.1.0+rc6+kl-3'; echo "$?" 0 Ok, version 4:3.1.0++kl-1 is the greater version. Now: shakti:~# apt-get install -t unstable libkdecore4 Reading Package Lists... Done Building Dependency Tree... Done Sorry, libkdecore4 is already the newest version. Done 0 packages upgraded, 0 newly installed, 0 to remove and 58 not upgraded. Ooops. already the newest version? But what about the following, and the compare-version above: shakti:~# apt-cache show libkdecore4 | grep Version Version: 4:3.1.0++kl-1 Version: 4:3.1.0+rc6+kl-3 shakti:~# Let's try this: shakti:~# apt-get install -t unstable libkdecore4=4:3.1.0++kl-1 Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: Sorry, but the following packages have unmet dependencies: libkdecore4: Depends: libdcop4 (>= 4:3.1.0++kl) but 4:3.1.0+rc6+kl-3 is to be installed Depends: libkdefx4 (>= 4:3.1.0++kl) but 4:3.1.0+rc6+kl-3 is to be installed Depends: kdeinit4 (= 4:3.1.0++kl-1) but 4:3.1.0+rc6+kl-3 is to be installed Depends: libkdecore-data but it is not going to be installed E: Sorry, broken packages Note here that all those missing packages are existing, and according to the dpkg compare-version above, have higher version numbers. apt-get is doing the wrong thing above. Why is it not updating those packages shown, libdcop4, libkdefx4 and kdeinit4, when there are newer version available that will satisfy the dependencies? the full output of the run follows in the end Karolina shakti:~# apt-get install -t unstable libkdecore4=4:3.1.0++kl-1 Reading Package Lists... Done Building Dependency Tree... Done Starting Starting 2 Investigating libkdecore4 Package libkdecore4 has broken dep on libdcop4 Considering libdcop4 2082 as a solution to libkdecore4 11796 Package libkdecore4 has broken dep on libkdefx4 Considering libkdefx4 2079 as a solution to libkdecore4 11796 Package libkdecore4 has broken dep on kdeinit4 Considering kdeinit4 1024 as a solution to libkdecore4 11796 Investigating libkdecore-data Package libkdecore-data has broken dep on libkdecore4 Considering libkdecore4 11796 as a solution to libkdecore-data 285 Removing libkdecore-data rather than change libkdecore4 Investigating kdelibs4 Package kdelibs4 has broken dep on libkdecore4 Considering libkdecore4 11796 as a solution to kdelibs4 3 Removing kdelibs4 rather than change libkdecore4 Investigating kdelibs-dev Package kdelibs-dev has broken dep on libkdecore4 Considering libkdecore4 11796 as a solution to kdelibs-dev 3 Removing kdelibs-dev rather than change libkdecore4 Investigating ksms Package ksms has broken dep on kdelibs4 Considering kdelibs4 3 as a solution to ksms 0 Removing ksms rather than change kdelibs4 Investigating kio-locate Package kio-locate has broken dep on kdelibs4 Considering kdelibs4 3 as a solution to kio-locate 0 Removing kio-locate rather than change kdelibs4 Investigating libkdegames-dev Package libkdegames-dev has broken dep on kdelibs-dev Considering kdelibs-dev 3 as a solution to libkdegames-dev 0 Removing libkdegames-dev rather than change kdelibs-dev Investigating libkscan-dev Package libkscan-dev has broken dep on kdelibs-dev Considering kdelibs-dev 3 as a solution to libkscan-dev 0 Removing libkscan-dev rather than change kdelibs-dev Investigating kickpim Package kickpim has broken dep on kdelibs4 Considering kdelibs4 3 as a solution to kickpim 0 Removing kickpim rather than change kdelibs4 Investigating koffice-dev Package koffice-dev has broken dep on kdelibs-dev Considering kdelibs-dev 3 as a solution to koffice-dev 0 Removing koffice-dev rather than change kdelibs-dev Investigating libkdecore4 Package libkdecore4 has broken dep on libdcop4 Considering libdcop4 2082 as a solution to libkdecore4 11796 Package libkdecore4 has broken dep on libkdefx4 Considering libkdefx4 2079 as a solution to libkdecore4 11796 Package libkdecore4 has broken dep on kdeinit4 Considering kdeinit4 1024 as a solution to libkdecore4 11796 Package libk
Looking for a sponsor
I have been inofficially packing KDE 3.1 since several months. I have also packed a number of KDE 3.1 applications (47 different right now) together with it. (But that is fast packing, without bug fixing, except for making them build) Now KDE 3.1 is going to make it into SID, so I was thinking that I maybe can pack a couple of applications for KDE 3.1. Just a one or two, or something, or whatever is needed. But as I am not a debian developer, I need some sponsor. I guess someone who uses KDE. I have really no preference of which KDE application(s) to pack, just as long as I don't have to rewrite it, and I at least understand how to use it and thus can test it. Any takers or suggestions? Karolina
Re: Looking for a sponsor
fredagen den 31 januari 2003 14.03 skrev Russell Coker: > On Thu, 30 Jan 2003 20:04, Karolina Lindqvist wrote: > > Any takers or suggestions? > > I'll sponsor you if no-one else does, particularly if you take kdm. Thank you. Unfortunately kdm is part of KDE, and can't be separated. That is, it is already claimed. Otherwise I would not mind. Karolina
