Re: .iso conflict, discussion of resolution
Am Saturday 30 August 2003 08:06 schrieb Chris Cheney: > Stephan, > > Would it be possible to get the two desktop filesi mentioned below merged > into kdelibs so that arson and k3b are easily installable at the same time? > I can do the commit myself if you approve. > Approved. Greetings, Stephan -- "SCO doesn't have enough understanding of the case to be able to lie convincingly. Indeed they have so little understanding that it's difficult to accuse them of lying." - Greg Lehey
Re: kpilot -- help sought
John Goerzen wrote: > > I have sent an e-mail to the author. > > Stephan Kulow <[EMAIL PROTECTED]> writes: > > > Looking at the diffs, I'm quite confused. kpilot ships with Makefiles, > > config.logand config.status? I would strongly advise to remove them > > from the orig sources, since they definitly do not belong there. > > Yes. Also, the make distclean does not remove the Makefiles. Not all > of the Makefiles get re-built from the .in files. .deps directories > are generated and left lying about, and the config.* files are not > removed by make distclean. Well, if kpilot uses automake (it seems to, since you have .deps dirs :), it should remove all of them besides .deps. Try to run automake --include-deps, this should remove the .deps from the beginnig. This should have been done by the upstream author, but per- haps he have missed it (or hasn't thought about debian packages ;-) > > Further, I had to edit every single Makefile.in to find the KDE libs > in /usr/X11R6/lib and the includes in /usr/include/kde. I can't hardly believe this. But since I haven't seen the Makefiles my- self, I can't say. > > > Then it would be perhaps not a very bad idea to remove *.moc and .deps > > while making distclean (I don't know, why they are not removed) > > I have no idea what a .moc is. .deps I can deduce :-) .moc is usualy the suffix for the output of the moc preprocessor used by qt and KDE. > > > I can't say, if kpilot's configure already support it, but my later > > versions of KDE configure support --with-install-root, so you just > > can call "configure --with-install-root=$PWD/debian/tmp" without > > patching configure or something else. > > Yes, it appears to be there. The question is: will it work? :-) Well, if kpilot doesn't used hardcoded paths out of the Makefile: yes. > > Also I am having difficulty in coaxing it to link with the system's > shared libpisock library instead of it's own, but I will leave that go > at the moment I think. > It may be a patched version. But I can't say. If it's not, add a LIBPISOCK variable, that is set to the static version by default and replaced by a -lpisock in your case. And this change can go into the upstream sources I guess. :) Greets, Stephan -- There are 3 kinds of people: those who can count & those who can't. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kpilot -- help sought
John Goerzen wrote: > > Hi, > > I've just uploaded kpilot to Incoming on master. This is a fairly > small program but required a LOT of hacks to Makefiles to get it to > Debianize. I would be greatly appreciative if someone familiar with > KDE would be able to review the diffs and see if I made any mistakes. > Or, better yet, if there is a way to do it that requires less Makefile > hacking, that would be good. > Hi! Looking at the diffs, I'm quite confused. kpilot ships with Makefiles, config.logand config.status? I would strongly advise to remove them from the orig sources, since they definitly do not belong there. Then it would be perhaps not a very bad idea to remove *.moc and .deps while making distclean (I don't know, why they are not removed) I can't say, if kpilot's configure already support it, but my later versions of KDE configure support --with-install-root, so you just can call "configure --with-install-root=$PWD/debian/tmp" without patching configure or something else. Hope this helps. Greets, Stephan -- Am billigsten ist Zahnersatz in Schweden, denn da kostet die Krone nur rund 'ne Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: deb + tar + bzip2 suggestion
> > I think it would be a good idea to teach tar to unpack bzip2 files via > the -z option, just as if it would be gzip. Alternativly one could > teach gzip to use bzip2 for .bz2 archives or teach dpkg to distinguish > between the two. > > The main advantage would be that one could use tar.bz2 for deb > packages without altering dpkg and thereby save a lot of space. > > Whats the general opinion about this and is maybe somebody already > working on it? > I think, you could save some space, but the installation time of Debian would increase dramaticly. I wouldn't like to see this. While it would be a big plus for ftp users, it would be a big minus for CD users. BTW: tar can handle bz2 files. you can use --use-compress-program=bzip2. Greets, Stephan -- Stephan Kulow ([EMAIL PROTECTED]) Student of medical CS Medical University of Luebeck (MFCH) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
