Re: mentors.debian.net rejects orig.tar."bz2"
Christoph Haas wrote: > On Mon, Dec 17, 2007 at 05:40:44PM +0100, Patrick Winnertz wrote: >> Am Montag, 17. Dezember 2007 16:29:40 schrieb Hideki Yamane: >> > Hi, >> > >> > I've uploaded package to mentors.debian.net but it failed because >> > mentors rejects its orig.tar.bz2 file. >> > >> > It says "You just uploaded a diff file >> > (ttf-vlgothic_20071215-1.diff.gz) without an upstream tarball (should >> > have been 'ttf-vlgothic_20071215.orig.tar.gz')." I did it as >> > ttf-vlgothic_20071215.orig.tar.bz2. >> Debian uses only .tar.bz2 ... please repackage it with a .orig.tar.gz > > If Debian used .tar.bz2 why whould Hideki repackage the tarball as > orig.tar.gz? > > I believe I recently read something about dpkg-buildpackage supporting > orig.tar.bz2 now. If that's true then I'll have to fix > mentors.debian.net. Can somebody give us a hint? The dpkg changelog says (2005-06-11): * debian/control ([dpkg-dev]Recommends): Recommend bzip2, it's not an absolute dependency until bz2 packages are supported by katie and policy. And indeed policy does not mention bz2, and speaks of orig.tar.gz all over the place. I guess this means bz2 is not supported yet, even though dpkg handles it. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net rejects orig.tar."bz2"
Russ Allbery wrote: > Felipe Sateler <[EMAIL PROTECTED]> writes: > >> The dpkg changelog says (2005-06-11): >> >> * debian/control ([dpkg-dev]Recommends): Recommend bzip2, it's >> not an absolute dependency until bz2 packages are supported by >> katie and policy. >> >> And indeed policy does not mention bz2, and speaks of orig.tar.gz all >> over the place. I guess this means bz2 is not supported yet, even though >> dpkg handles it. > > This may just be Policy lagging behind dpkg. If someone wants to > investigate this, please start by checking with ftp-master and asking if > dak supports .bz2 and if they're willing to accept such packages in the > archive. If so, we should change Policy. According to [1], bz2 is not usable, the regex used to validate files is "(.+)_(.+?)\.(orig\.tar\.gz|diff\.gz|tar\.gz|dsc)$". However I don't know if that is what is indeed running on ftp-master (although the log includes pretty recent changes, such as the DM uploads). I think I'll file a wishlist... should it be against ftp.debian.org? There doesn't seem to be one filed already. [1] http://ftp-master.debian.org/bzr/ftpmaster-dak/ -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-ntp] - where does /etc/default/ntpdate come from?
D. Pathirana wrote: > I've been trying to figure out how the installation process of the > package "ntpdate" works. After installation the configuration file > "/etc/default/ntpdate" is created. But: I can not find any evidence of > it being used throughout the whole debian directory in the source-package. > > Actually there IS THE file in "debian/ntpdate.default" but is never > refered in the rules file or elsewhere. > > I believe it has something to do with .default suffix but I was not able > to find any docs about what and how it is going on. So where does the > magic happen? man dh_installinit: If a file named debian/package.default exists, then it is installed into etc/default/package in the package build directory, with "package" replaced by the package name. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dblatex (updated package): 2nd try
Leo "costela" Antunes wrote: > Andreas Hoenen wrote: > >> I have just uploaded dblatex 0.2.8-2 to mentors.debian.net [1]. >> Regarding the new lintian warning 'spelling-error-in-changelog' I have >> opened a bug report [2]. >> >> [1] dget >> [http://mentors.debian.net/debian/pool/main/d/dblatex/dblatex_0.2.8-2.dsc > > Now there's just one last minor problem: since you closed some bugs on > 0.2.8-1 which never got uploaded, you would have to close them manually > as the automatic bug handling wouldn't be triggered for them. This can be triggered with the -v option to dpkg-buildpackage -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using symbols files
David Paleino wrote: > Hi all, > one of my packages, libopenraw, has just been uploaded to NEW. My sponsor > (lucab, thanks Luca!) noted that I should've read [1] and [2], to write proper > symbols files. > Unfortunately, I've not been able to fully understand how to implement this. > > Can anyone give some help? That would be appreciated :p > The thing is that very few packages are using this right now, and I remember someone asking in debian-devel for early adopters to write a set of guidelines, but nothing has come out yet. I should note that apparently it takes some work to get the new dependencies working, and that currently only packages with *lots* of reverse dependencies (such as glibc) have it implemented. I personally wouldn't bother for a new library. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
parallel building without make
Recently dpkg-buildpackage got the option to build in parallel via the -j option. This means that debian/rules is called with that option set, and sets parallel=n in DEB_BUILD_OPTIONS. The problem is that for build systems not using make (eg, scons), this option is not inherited. Of course, one could parse DEB_BUILD_OPTIONS and find if parallel=n is set and then call the build system with the equivalent option. However this means that, although one specified n threads of execution, there can be more than n threads concurrently. Consider this case: build: build-indep build-arch build-arch: scons -j$(NTHREADS) buildProgram build-indep: scons -j$(NTHREADS) buildDocumentation Where NTHREADS is calculated from DEB_BUILD_OPTIONS. If I call dpkg-buildpackage with -j2, I will get build-arch and build-indep running concurrently, which means I will actually get 4 scons threads running instead of the intended 2. What should I do? I see 3 options: 1- Don't use the -j flag in scons 2- Use the -j flag and potentially use more threads than specified 3- Use the -j flag with a lower number (eg, NTHREADS/2). Any opinions? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: parallel building without make
Lucas Nussbaum wrote: > On 29/01/08 at 17:23 -0300, Felipe Sateler wrote: >> Recently dpkg-buildpackage got the option to build in parallel via the -j >> option. This means that debian/rules is called with that option set, and sets >> parallel=n in DEB_BUILD_OPTIONS. >> The problem is that for build systems not using make (eg, scons), this option >> is not inherited. Of course, one could parse DEB_BUILD_OPTIONS and find if >> parallel=n is set and then call the build system with the equivalent option. >> However this means that, although one specified n threads of execution, there >> can be more than n threads concurrently. Consider this case: >> >> build: build-indep build-arch >> build-arch: >> scons -j$(NTHREADS) buildProgram >> build-indep: >> scons -j$(NTHREADS) buildDocumentation >> >> Where NTHREADS is calculated from DEB_BUILD_OPTIONS. If I call >> dpkg-buildpackage with -j2, I will get build-arch and build-indep running >> concurrently, which means I will actually get 4 scons threads running instead >> of the intended 2. >> >> What should I do? I see 3 options: >> 1- Don't use the -j flag in scons >> 2- Use the -j flag and potentially use more threads than specified >> 3- Use the -j flag with a lower number (eg, NTHREADS/2). >> >> Any opinions? > > Don't use dpkg-buildpackage -j. Only set DEB_BUILD_OPTIONS="parallel=n", > so build-arch and build-indep are not run in parallel, but you still get > several scons threads. OK. But it makes me wonder what is the real use for -j in dpkg-buildpackage, then. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Install files with debhelper or make install?
Jörg Sommer wrote: > Hallo Don, > > Don Armstrong <[EMAIL PROTECTED]> wrote: >> On Sat, 08 Mar 2008, Jörg Sommer wrote: >>> Don Armstrong <[EMAIL PROTECTED]> wrote: >>> > That's why you generally fail your build if there are files in tmp >>> > which do not get installed. >>> >>> In which of your packages you do so? >> >> All of mine are simple enough not to need it, but --fail-missing is >> the option to dh_install. > > But I want to use dh_installman, dh_installexamples and the linke. I > don't want to do a big dh_install run. The goal is to use the helper > scripts to take the advantage of them. Then use package.manpages, package.examples and the like. What's the problem with that? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Install files with debhelper or make install?
Jörg Sommer wrote: > Hi Felipe, > > Felipe Sateler <[EMAIL PROTECTED]> wrote: >> Jörg Sommer wrote: >>> Don Armstrong <[EMAIL PROTECTED]> wrote: >>>> On Sat, 08 Mar 2008, Jörg Sommer wrote: >>>>> Don Armstrong <[EMAIL PROTECTED]> wrote: >>>>> > That's why you generally fail your build if there are files in tmp >>>>> > which do not get installed. >>>>> >>>>> In which of your packages you do so? >>>> >>>> All of mine are simple enough not to need it, but --fail-missing is >>>> the option to dh_install. >>> >>> But I want to use dh_installman, dh_installexamples and the linke. I >>> don't want to do a big dh_install run. The goal is to use the helper >>> scripts to take the advantage of them. >> >> Then use package.manpages, package.examples and the like. What's the problem >> with that? > > Does dh_install run dh_installman for the files in dh_install? I didn't > know this. I though dh_install installs only the files in package.install. It does. But if you leave the manpage out of package.install, put it in package.manpages and add a call to dh_installman you should have your problem solved. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed for packaging a library
Helmut Grohne wrote: > Hi Georgi, > >> Why is my library architecture-dependent? How can I make it >> architecture-independent, assuming the source code doesn't care about the >> architecture (I don't think a printf should be a problem)? > > Your library will be compiled to a binary blob and this binary blob is > architecture dependant. But Georgi was asking why the pkgconfig file was arch dependent, not the library. I'd say that in pretty much all non-trivial libraries the pc file is system-dependant, so I would go with /usr/lib by default even if in your case the pkgconfig file is trivial. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VCS repository on Alioth projects with unrelated packages (was: Proposed new package, bugs-everywhere_0.0.193-1.1)
Ben Finney wrote: > "Sandro Tosi" <[EMAIL PROTECTED]> writes: > >> If this is as python app (and you'd like to follow this path) > > It is implemented in Python, and I'm interested in the PAPT; thanks > for the invite. > >> the repository it's already on Alioth, and it's called PAPT[1] ;) > > Unfortunately (as made clear > in a conversation earlier this evening), the PAPT won't allow packages > to use any VCS but their chosen repository, which is currently a > Subversion back-end. > > Since my VCS preference, and that of my upstream, is Bazaar, this > makes PAPT more of a burden than I was looking for. Alioth was > attractive for this package largely *because* it provides hosted > Bazaar repositories. You may want to consider using collab-maint instead of creating a new project. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging without Makefile
Dominik George wrote: > Hello mentors, > > I am just packaging my Pidgin Last.fm Plugin for Debian and am wondering how > to get a .changes file. The problem is that the plugin consists of a single > perl script which is copied to /usr/lib/pidgin. You may want to consider adding the script to an existing package, such as pidgin-plugin-pack instead of building a package for only a perl script. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
Ben Finney wrote: > What would be the best way to keep such a directory in place, but > exclude the directory from the Debian source and binary packages? dpkg-source -i"regexp"? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
Ben Finney wrote:
> Felipe Sateler <[EMAIL PROTECTED]> writes:
>
>> Ben Finney wrote:
>>
>> > What would be the best way to keep such a directory in place, but
>> > exclude the directory from the Debian source and binary packages?
>>
>> dpkg-source -i"regexp"?
>
> Thanks. That looks like the right functionality, indeed.
>
> However:
>
> =
> $ man dpkg-source
> [...]
>-i[regexp]
> You may specify a perl regular expression to match files
> you want filtered out of the list of files for the diff.
> [...] There can only be one active regexp, of multiple
> -i options only the last one will take effect.
> [...]
>
> $ dpkg-source --help
> [...]
> -i[] filter out files to ignore diffs of
> (defaults to:
> '(?:^|/).*~$|(?:^|/)\.#.*$|(?:^|/)\..*\.swp$
(?:^|/),,.*(?:$|/.*$)|(?:^|/)(?:DEADJOE|\.cvsignore|\.arch-inventory
\.bzrignore|\.gitignore)$|(?:^|/)(?:CVS|RCS|\.deps|\{arch\}|\.arch-ids|\.svn
\.hg|_darcs|\.git|\.shelf|_MTN|\.bzr(?:\.backup|tags)?)(?:$|/.*$)').
> [...]
> =
>
> Yikes. So, in order to filter out an additional pattern, I can't just
> say "ignore this pattern as well as the defaults". I have to construct
> a *single* regexp that contains the default pattern *plus* mine, and
> forever diverge from any future changes to the default regexp.
>
> Am I reading it wrong, or is this dpkg-source option really that
> awful?
Apparently it is. Note though that most of that regex is to match stuff you
won't use (eg, every VCS in common use, you probably use only one).
BTW, why are there files useful to you but not other developers?
--
Felipe Sateler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tesseract-ocr: missing-dependency-on-libc
Cyril Brulebois wrote: > You could try and use LDFLAGS to pass -Wl,--as-needed (linker flags). > But since it could break silently some parts of your build, it shouldn't > be used without -Wl,-z,defs which will help spot possible missing -l$foo > options in intermediate objects (if any). You can pass LDFLAGS to the > ./configure script. Can -Wl,--as-needed really break anything that can be detected by -Wl,-z,defs? As I understood from some discussion at -devel, it can't create problems with C code, it only creates problems on some obscure situations involving C++ constructors/destructors. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libtorrent-rasterbar and qBittorrent
Cristian Greco wrote: > Dear mentors, > > I am looking for a sponsor for my packages "libtorrent-rasterbar" and You may want to contact the btg guys. They have been providing deb packages for both btg and libtorrent for a while (I made the first few releases). BTW, embedded code copies are a bad thing. You should try to contact Simon Richter (asio's maintainer) to update debian's asio version. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libtorrent-rasterbar and qBittorrent
Cristian Greco wrote: > On Thu, May 08, 2008 at 01:52:37PM -0400, Felipe Sateler wrote: > >> You may want to contact the btg guys. They have been providing deb packages >> for both btg and libtorrent for a while (I made the first few releases). > > Hi Felipe, > do you remember me? I wrote you when starting work with this package. Doh, yes. I somehow got confused and thought you were someone completely different. > As > you suggested me some days ago, I contacted Roman Rybalko, the guy who > currently packages libtorrent and btg. He provided me with some advices, > and then I looked at your past works on this library. This package is > the result of my work merged with yours experience. Oh, ok. But you seem to have started the package from scratch? The changelog at least suggests that. > >> BTW, embedded code copies are a bad thing. You should try to contact Simon >> Richter (asio's maintainer) to update debian's asio version. > > The main problem here is that Asio 1.0.0 gets included with Boost > 1.35.0, which package is still unreleased and there is a discussion > about versioning and problems with probably broken rdepends [1]. > > Should we consider upgrading Asio to latest version anyway? boost1.35 is already on NEW. But I can't see asio in there. Maybe it's bundled in some package there? http://ftp-master.debian.org/new/boost1.35_1.35.0-1.html -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libtorrent-rasterbar and qBittorrent
Cristian Greco wrote: >> boost1.35 is already on NEW. But I can't see asio in there. Maybe it's >> bundled in some package there? >> http://ftp-master.debian.org/new/boost1.35_1.35.0-1.html > > I see the Asio header files are listed in libboost1.35-dev. That package > depends on new, versioned, -dev packages and conflicts with libboost-dev. > I think libtorrent-rasterbar can then build-depends on libboost1.35-dev > and other non-versioned -dev packages from boost 1.34, am I right? I don't think so. Loading more than one version of a library is asking for trouble, I think (although asio is not a library per se, AFAIK). If you build depend on libboost1.35, then I think you should use the other boost libraries at 1.35. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402462: Would like libtorrent-rasterbar
Jose Luis Rivas Contreras wrote: > Sorry, I don't think that "libtorrent-rakshasa is used by only one > client" is argument enough to get it a name change. I'm wondering if libtorrent-rakshasa even needs a shared library, given that the only person using it is rakshasa. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402462: Would like libtorrent-rasterbar
Jose Luis Rivas Contreras wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Felipe Sateler wrote: >> Jose Luis Rivas Contreras wrote: >> >>> Sorry, I don't think that "libtorrent-rakshasa is used by only one >>> client" is argument enough to get it a name change. >> >> I'm wondering if libtorrent-rakshasa even needs a shared library, given that >> the only person using it is rakshasa. >> > > Ok, lets make things funnier and easier to explain with your same phrase: > > "I'm wondering if $X even needs a $Y, given that the > only person/package using it is $Z." > > Now let's try with: > X="zorp-doc";Y="package";Z="zorp" > X="widelands-data";Y="data package";Z="widelands" > X="deluge-torrent-common";Y="common package";Z="deluge-torrent" > > Please, don't make me continue :) The thing is you just named 3 cases were they are useful for unrelated reasons (namely, saving mirror space via an arch: all package), while you didn't provide the reason for libtorrent. Maybe I was unclear. What I meant is that perhaps, given that libtorrent is only used by rtorrent, it should be shipped as /usr/lib/rtorrent/libtorrent.so. I don't know if this is possible, but I really do wonder if it useful to install it under /usr/lib/. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402462: Would like libtorrent-rasterbar
Jose Luis Rivas Contreras wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Felipe Sateler wrote: > [some text missing] >> >> The thing is you just named 3 cases were they are useful for unrelated >> reasons (namely, saving mirror space via an arch: all package), while you >> didn't provide the reason for libtorrent. >> >> Maybe I was unclear. What I meant is that perhaps, given that libtorrent is >> only used by rtorrent, it should be shipped as >> /usr/lib/rtorrent/libtorrent.so. I don't know if this is possible, but I >> really do wonder if it useful to install it under /usr/lib/. >> > > Because LibTorrent is _not_ part of the rtorrent upstream tarball. Well, there's one reason to ship it separately then :). I thought libtorrent was part of the rtorrent source. > They're shipped individually for practical purposes (if someone wants, > in some moment, to only use the library and not the client). Besides, > there are normally more (a lot more) uploads of libtorrent than > rtorrent, most of the changes are made in the library (talking about > patches made to upstream and stuff). More reason then to keep them separate. > > Installing LibTorrent in /usr/lib is as useful as installing it in > rtorrent, only that making the last one would imply actually changing > the actual scheme. Don't know what for, _really_. There's another reason > that just "Cause rtorrent is the only one using it right now"? (Which, > BTW, is not true [1][2][3][4][5] are other examples of software using > LibTorrent-Rakshasa) Ok then. I was not aware of that other software. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Compiling with -mtune?
Hi. Csound, a package I maintain, supports enabling a set of gcc optimizations via a build option. Code generated with those options can be significantly faster (I've seen improvements of over 2x). However, this option means adding a -mtune option to gcc. Obviously, the only sane option for a debian package is -mtune=generic (which is apparently only available on x86 and amd64). However I read in the info pages for gcc: > Produce code optimized for the most common IA32/AMD64/EM64T processors. Does this mean that setting -mtune=generic is the same as setting -mtune to the most popular processor? If so, can/should I use that option? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compiling with -mtune?
Neil Williams wrote: > On Thu, 2008-05-22 at 01:12 -0400, Felipe Sateler wrote: >> Hi. Csound, a package I maintain, supports enabling a set of gcc >> optimizations via a build option. Code generated with those options can be >> significantly faster (I've seen improvements of over 2x). However, this >> option means adding a -mtune option to gcc. Obviously, the only sane option >> for a debian package is -mtune=generic (which is apparently only available on >> x86 and amd64). However I read in the info pages for gcc: >> >> > Produce code optimized for the most common IA32/AMD64/EM64T processors. >> >> Does this mean that setting -mtune=generic is the same as setting -mtune to >> the most popular processor? If so, can/should I use that option? > > Only for the supported architectures or you'll get a build failure on > ARM, powerpc, mips, sparc etc. Of course. I already noted that it was only available on x86 and amd64. > > To check the arch, always test against the HOST architecture. Native > builds set HOST == BUILD but if the package is ever cross-built, your > debian/rules must allow building an ARM package on amd64 (HOST=ARM, > BUILD=amd64) and *NOT* enable -mtune. > > DEB_HOST_ARCH_CPU=... -qDEB_HOST_ARCH_CPU) > > This holds true for any architecture-specific checks in any package - > always, always check the HOST value - BUILD is almost always the wrong > variable to use. I think csound is unlikely to be cross-built. Sound synthesis is a pretty cpu-intensive task. If I enable it then I should only enable it on the appropriate environments. However there is still the question: is it reasonable to enable this option on supported archs? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compiling with -mtune?
Neil Williams wrote: > On Thu, 2008-05-22 at 12:42 -0400, Felipe Sateler wrote: >> Neil Williams wrote: >> >> > To check the arch, always test against the HOST architecture. Native >> > builds set HOST == BUILD but if the package is ever cross-built, your >> > debian/rules must allow building an ARM package on amd64 (HOST=ARM, >> > BUILD=amd64) and *NOT* enable -mtune. >> > >> > DEB_HOST_ARCH_CPU=... -qDEB_HOST_ARCH_CPU) >> > >> > This holds true for any architecture-specific checks in any package - >> > always, always check the HOST value - BUILD is almost always the wrong >> > variable to use. > >> I think csound is unlikely to be cross-built. Sound synthesis is a pretty >> cpu-intensive task. > > :-) don't think that cross-building is only for low resource units. > > I suppose csound may also require a lot of RAM. Not really. It would depend on the use, of course, but normally it doesn't. > It is still possible > that an arch could be sufficiently powerful to *run* csound but not > capable of building gcc for itself. (I would be surprised if running > csound is quite as much workload as compiling gcc.) Indeed, running csound is a lot less resource-intensive than compiling a large application (such as csound itself). The problem is that (AFAICS), csound on an emdebian-targeted device will probably be most useful as a realtime sound generator, which is problematic because now you not only have a lot of work to do, but you need to do it fast (or else the sound will clip and stutter). Many pieces fail to run in realtime on fast amd64 machines. > >> If I enable it then I should only enable it on the >> appropriate environments. However there is still the question: is it >> reasonable to enable this option on supported archs? > > Yes. OK then. I will enable it on x86 and amd64. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compiling with -mtune?
Neil Williams wrote: > This holds true for any architecture-specific checks in any package - > always, always check the HOST value - BUILD is almost always the wrong > variable to use. What if I'm checking for build-dependencies? For example, csound can use alsa, which isn't present on non linux archs. Should I test for HOST or BUILD? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dealing with get-orig-source and md5sum
David Paleino wrote:
> Hello mentors,
> I'm packaging a svn snapshot of a Mono assembly, for which no released tarball
> is present.
> As per Policy 3.8.0, I wrote in debian/README.Debian-source how to get a
> tarball to start the build, i.e. "./debian/rules get-orig-source".
>
> This is my get-orig-source target (please tell me if and how it can be
> improved), with some variables defined in the very beginning of the makefile:
>
> ---8<---
> VERSION=$(shell parsechangelog | grep ^Version | awk -F": " '{print $$2}' |
> cut -d"-" -f1) REV=$(shell echo $(VERSION) | awk -F"~svn" '{print $$2}')
> GOS_TMP=$(CURDIR)/get-orig-source-tmp
AFAIK, get-orig-source shouldn't rely on other files to do it's job. I have
always hardcoded the version or date to make the checkout from, to ensure that
only debian/rules is used, and that it can be used from anywhere
(eg, ../src/package/debian/rules get-orig-source).
>
> [..]
>
> get-orig-source:
> rm -rf $(GOS_TMP) && mkdir $(GOS_TMP)
> svn co -r $(REV) svn://anonsvn.mono-project.com/source/trunk/Mono.Nat
> $(GOS_TMP)/mono-nat-sharp-$(VERSION)
You can use svn export and skip the next instruction.
> find $(GOS_TMP)/mono-nat-sharp-$(VERSION)
> -name ".svn" -type d | xargs rm -rf
> cd $(GOS_TMP) && tar zcf
> mono-nat-sharp_$(VERSION).orig.tar.gz mono-nat-sharp-$(VERSION)/ mv
> $(GOS_TMP)/mono-nat-sharp_$(VERSION).orig.tar.gz $(CURDIR)/../ rm -rf
> $(GOS_TMP) echo "The original source tarball is located at $(CURDIR)/../ ."
Policy 4.9 says it should be left at the current directory.
> --->8---
>
> Now, the fact is that the resulting tarball has very different md5sums at
> each run -- and I found no way to have the same exact md5sum of the
> .orig.tar.gz that would be uploaded to Debian:
>
> $ date -R
> Thu, 19 Jun 2008 23:12:36 +0200
> $ debian/rules get-orig-source &>/dev/null
> $ md5sum ../mono-nat-sharp_0.1~svn106158.orig.tar.gz
> 2826da659bb5a5ab5867c8ca11b6f7fe ../mono-nat-sharp_0.1~svn106158.orig.tar.gz
> $ debian/rules get-orig-source &>/dev/null
> $ md5sum ../mono-nat-sharp_0.1~svn106158.orig.tar.gz
> 54db2bdb1131f7b3e5a1a73d495bd737 ../mono-nat-sharp_0.1~svn106158.orig.tar.gz
> $ date -R
> Thu, 19 Jun 2008 23:13:06 +0200
> $
>
> I thought that this could be related to timestamps -- but I found no option in
> `man tar` to remove timestamps from archived files (I thought that, removing
> timestamps, the files would have been all the same).
> I can also confirm that the files in the archives are always the same (checked
> with `tar -tf` and diffing the lists).
>
> What can I do here?
AFAIK the problem is not tar, but gzip. If I read correctly man gzip, your
solution would be to use tar first, and then gzip -9n.
--
Felipe Sateler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dealing with get-orig-source and md5sum
David Paleino wrote: > On Fri, 20 Jun 2008 09:29:37 +0200, David Paleino wrote: > >> On Fri, 20 Jun 2008 09:24:09 +0200, David Paleino wrote: >> >> > On Thu, 19 Jun 2008 20:05:31 -0400, Felipe Sateler wrote: >> > >> > > David Paleino wrote: >> > > >> > > > Now, the fact is that the resulting tarball has very different md5sums >> > > > at each run -- and I found no way to have the same exact md5sum of the >> > > > .orig.tar.gz that would be uploaded to Debian: >> > > > >> > > > [..] >> > > > >> > > > I thought that this could be related to timestamps -- but I found no >> > > > option in `man tar` to remove timestamps from archived files (I thought >> > > > that, removing timestamps, the files would have been all the same). >> > > > I can also confirm that the files in the archives are always the same >> > > > (checked with `tar -tf` and diffing the lists). >> > > > >> > > > What can I do here? >> > > >> > > AFAIK the problem is not tar, but gzip. If I read correctly man gzip, >> > > your solution would be to use tar first, and then gzip -9n. >> > >> > -n... I'll try that, thanks :) >> >> Great, it worked :) > > No, it didn't... I md5sum'ed the same file before... :( > > I'm open to other suggestions, I was thinking a bit about this, and apparently this is a not-so-trivial problem. Maybe you can try pristine-tar which attempts to do this. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with implicit rule for .o files and overriding of CXXFLAGS.
George Danchev wrote:
> On Monday 07 July 2008 16:39:14 Charles Plessy wrote:
>> Le Sun, Jul 06, 2008 at 09:34:33PM +0300, Yavor Doganov a écrit :
>> > Charles Plessy wrote:
>
> Hello,
>
>> > > When a Debian binary package is built, environment variables such as
>> > > {{{CFLAGS}}} and {{{CXXFLAGS}}} are set by {{{dpkg-buildpackage}}}
>> > > and may override the corresponding variables in the
>> > > {{{Makefile}}}.
>> >
>> > The matter is more complex in general; add here the well known fact
>> > that a truckload of upstream makefiles/build systems is broken.
>>
>> Well, this is why I tried to write something in the wiki page that is
>> supposed to be something to read for upstream maintainers. But I am not
>> a C programmer, I do not think I can improve what I wrote any further.
>
> It is not that much related to the C programming language, nor to the GNU
> implementation for it (compiler, linker, standard library), nor with any
> other GNU programming language implementation (like the ones for C++ or Ada),
> it is the GNU build system (autotools, make) which adds the complexity.
FWIW, in this case the problem was "clever" use of (i think standard) make and
implicit rules. Using the gnu build system would have actually avoided this
issue, as automake puts flags in other variables and doesn't rely on implicit
rules.
--
Felipe Sateler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Determining native or non-native package inside pbuilder
Ben Finney wrote: > "Paul Wise" <[EMAIL PROTECTED]> writes: > >> On Sun, Sep 7, 2008 at 3:33 PM, Ben Finney <[EMAIL PROTECTED]> >> wrote: >> > "Paul Wise" <[EMAIL PROTECTED]> writes: >> > >> >> Usually this warning is produced because of an incorrectly named >> >> orig.tar.gz - foo-1.2.orig.tar.gz (bad) vs foo_1.2.orig.tar.gz (good). >> >> Perhaps that is the issue? >> > >> > Perhaps. But as far as I know, I have no control over the name of the >> > tarball; it's generated automatically as part of 'pdebuild'. >> > >> > What do I need to do so that the correct tarball name (i.e. correctly >> > indicating native or non-native) is used when I run 'pdebuild'? >> >> A native tar.gz (rather than a non-native orig.tar.gz) is only >> generated automatically when you don't have an orig.tar.gz file. I >> suggest removing all tar.gz files below your source directory and >> doing something like this in the source directory: >> >> wget -O ../foo_1.2.3.orig.tar.gz http://foo.bar.com/foo-1.2.3.tar.gz > > Should I expect it to be found at '../tarballs/foo_1.2.3.orig.tar.gz'? > That's where 'dpkg-buildpackage' and other tools seem to expect it. dpkg-buildpackage expects it to be in ../foo_*. svn-buildpackage is the only one that uses ../tarballs AFAIK. > > Is 'pbuilder' different in this regard? I'd rather not have the same > file needing to appear at multiple places just to get the Debian tools > working in concert. pbuilder requires whatever you use as a builder. The default is dpkg-buildpackage, so it will expect the orig in .. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What is the best method to update only some binary packages
Osamu Aoki wrote: > Hi, > > Suppose source foo_1.0.tar.gz produces: > foo-updated_1.0_all.deb > foo-static_1.0_all.deb > > Then with next source foo_1.1.tar.gz with updated contents will produce > now with normal build script: > foo-updated_1.1_all.deb (updated from foo-updated_1.0_all.deb) > foo-static_1.1_all.deb (same as foo-static_1.0_all.deb) > > Then What is the best way to make update archive to have: > foo-updated_1.1_all.deb > foo-static_1.0_all.deb > > This way user will not be forced to download same package again. > > Any suggestion for debian/rules ? or pointer to good example. You can't really do this, AFAIK. You can break the source into 2 separate source packages that each build one package. That way you only update the foo-updated package. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What is the best method to update only some binary packages
El 02/10/08 12:51 Osamu Aoki escribió: > On Thu, Oct 02, 2008 at 12:10:16PM -0400, Felipe Sateler wrote: > > Osamu Aoki wrote: > > > Any suggestion for debian/rules ? or pointer to good example. > > > > You can't really do this, AFAIK. You can break the source into 2 > > separate source packages that each build one package. That way you > > only update the foo-updated package. > > from maint-guide: > > # dh_gencontrol > # up to date versions, using the default value of 1.2* in debian/changelog: > DH_OPTIONS="-p$(name)" dh_gencontrol > DH_OPTIONS="-p$(name)-fr" dh_gencontrol > DH_OPTIONS="-p$(name)-ja" dh_gencontrol > DH_OPTIONS="-p$(name)-pl" dh_gencontrol > DH_OPTIONS="-p$(name)-it" dh_gencontrol > DH_OPTIONS="-p$(name)-zh" dh_gencontrol > DH_OPTIONS="-p$(name)-ko" dh_gencontrol > DH_OPTIONS="-p$(name)-de" dh_gencontrol > DH_OPTIONS="-p$(name)-es" dh_gencontrol > DH_OPTIONS="-p$(name)-pt" dh_gencontrol > DH_OPTIONS="-p$(name)-ru" dh_gencontrol > # out of date versions: > # If no change from old version, > # upload with the same version to prevent updating. > #DH_OPTIONS="-p$(name)-XX -u"-v1.X.Y-Z"" dh_gencontrol Will dak accept such a package? I doubt so. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Building package,
Luca Bruno wrote: > On Thu, Oct 02, 2008 at 03:03:40PM -0500, =?ISO-8859-1?Q?El=EDas_A._M._ wrote: >> Hi, > > Hi I'm not a developer but I try to suggest you. > >> Somebody know why when I build the package, show me: >> dpkg-shlibdeps: warning: debian/pack/usr/games/pack shouldn't be linked with >> libpthread.so.0 (it uses none of its symbols). >> > > Your package is linking against libpthread and it might not be used. If your > program uses it, then ignore the warning. If your program doesn't really use > it, add --as-needed in the LDFLAGS in your debian/rules. When (for some reason) -pthread is passed to gcc, the -Wl,--as-needed flag won't unlink it (newlines added for clarity): % gcc -o test test.c % objdump -p test | grep NEEDED NEEDED libc.so.6 % gcc -pthread -o test test.c % objdump -p test | grep NEEDED NEEDED libpthread.so.0 NEEDED libc.so.6 % gcc -lpthread -o test test.c % objdump -p test | grep NEEDED NEEDED libpthread.so.0 NEEDED libc.so.6 % gcc -Wl,--as-needed -lpthread -o test test.c % objdump -p test | grep NEEDED NEEDED libc.so.6 % gcc -Wl,--as-needed -pthread -o test test.c % objdump -p test | grep NEEDED NEEDED libpthread.so.0 NEEDED libc.so.6 % -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: airoscript
Daniel Moerner wrote: > Incidentally, this makefile seems to > have some problems with it (it has an empty clean: target, and no > .PHONY even though some rules don't create files with their names, > like the clean: target). And why would that be a problem? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: airoscript
Daniel Moerner wrote: > On Thu, Oct 9, 2008 at 10:24 PM, Felipe Sateler <[EMAIL PROTECTED]> wrote: >> Daniel Moerner wrote: >> >>> Incidentally, this makefile seems to >>> have some problems with it (it has an empty clean: target, and no >>> .PHONY even though some rules don't create files with their names, >>> like the clean: target). >> >> And why would that be a problem? >> > > I was under the impression that it's always good practice to have a > .PHONY target in case there accidentally happens to be a file with the > name of a target, like clean, in the working directory. Ah, that seems sensible (although I'd argue that a file called 'clean' in a source tarball is broken). Reading the make info page I find that if you define the targets as .PHONY, then it can optimize a bit, so if your Makefile is large you could get some speed improvement. > > As far as an empty clean target in the Makefile goes, if you're adding > a Makefile to the .diff.gz, and you have the choice to call make clean > or not call it in debian/rules, it just seems like extraneous cruft to > include a makefile with a clean target that does nothing just so you > can run make clean in debian/rules. I was asking about the .PHONY issue. I agree with this point. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libmsn
Pau Garcia i Quiles wrote: > Please note I did not just unpackage and repackage it again but I also > renamed the directory from 4.0-beta1 to 4.0~beta1 because: > > $ dpkg --compare-versions 4.0-beta1 gt 4.0; echo $? > 0 > > $ dpkg --compare-versions 4.0~beta1 gt 4.0; echo $? > 1 > > Should I rename the directory in the .orig.tar and make > tamper-checking more difficult, or not rename the directory in the > .orig.tar and make tamper-checking easier? Don't rename. dpkg-source takes care of that. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: Kompile - KDE automatic installer for source packages
Hello, I am searching for a sponsor to upload this package. I have uploaded the sources to mentors.debian.net. Any comments (and sponsors ;)) welcome. * Package name: kompile Version : 0.2 Upstream Author : Tommaso Frazzetto <[EMAIL PROTECTED]> * URL : http://www.kde-apps.org/content/show.php?content=30223 * License : GPL Description : KDE automatic installer for source packages Kompile is a KDE interface for automatic execution of configuration, compilation and installation of source tarballs. It adds a KDE service menu so as to right click a source tarball and automatically install or remove a package. -- Felipe Sateler pgp5Z5TbOKKyq.pgp Description: PGP signature
RFS: kompile -- KDE automatic installer for source packages
Hello, I am searching for a sponsor for this package. I updated this package to go through the c2a transition. The package source is available from debian.mentors.net. * Package name: kompile Version : 0.2 Upstream Author : Tommaso Frazzetto <[EMAIL PROTECTED]> * URL : http://www.kde-apps.org/content/show.php?content=30223 * License : GPL Description : KDE automatic installer for source packages Kompile is a KDE interface for automatic execution of configuration, compilation and installation of source tarballs. It adds a KDE service menu so as to right click a source tarball and automatically install or remove a package. ITP: #338092 -- Felipe Sateler pgp7Sd7CJyqh0.pgp Description: PGP signature
Removing an ITP
Hello. Some time ago I filed an ITP[1] for the package kompile, and later on I asked for sponsor, but got no response. Since there is apparently no interest in that package (with mine decreasing too), I'd like to remove/close the ITP bug. How do I do this? Or it is not my responsability to do this? 1: http://bugs.debian.org/338092 -- Felipe Sateler pgpquSJJlTToc.pgp Description: PGP signature
Attempting to adopt two packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For a while now, I've been interested in the checkinstall package. I see that the current maintainer (Matt Hope) is apparently MIA, and that installwatch (which currently is shipped with checkinstall now, anyway) was orphaned recently. So I'd like to adopt these two packages, and have already done some work on them. However, I have some questions: 1) What is the proper way to handle hijacking of packages? I have tried to contact Matt, but so far I haven't received any response (mail was sent on 11/01/06). I do know I have to file an ITA bug to each package, but I haven't yet (I'd rather be sure what to do before doing it). 2) It seems to me that now, since installwatch and checkinstall come bundled and that they are small packages (each package is 23 and 64 KB respectively), it makes sense to merge this two packages. Does it? If it is, how is this to be done? 3) Actually, the source packages need merging anyway. Do the changelogs need merging? How is that done? Any help with this questions is greatly appreciated. - -- Felipe Sateler -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEEeMK19K8LkCXFHcRAsdZAKCfBWXFCH5l1ONWqxkYtnMpkGETzACfRV4n JcZdFe+LSilWc/YmHgr6jmU= =eEK7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempting to adopt two packages
Done some work, now I might be ready. Justin Pryzby wrote: > On Fri, Mar 10, 2006 at 05:35:15PM -0300, Felipe Sateler wrote: >> contact Matt, but so far I haven't received any response (mail was sent >> on 11/01/06). I do know I have to file an ITA bug to each package, but I > In the case of installwatch, you should retitle the 'O'rphan bug > instead: http://packages.qa.debian.org/installwatch => #347469 > What you want to happen, is that anyone who has either of installwatch > or checkinstall now, ends up with the new version of whatever the new > packagename will be. Do it by setting > > Package: foo > Replaces: bar > Conflicts: bar > > The overloaded combination of Conflicts+Replaces means "this is the > new name for package bar", so it will cause files in bar but not foo > to be removed. Done this too. However, I can't install it via dpkg, only through apt. dpkg argues that it can't uninstall installwatch because checkinstall needs it. Duh! I guess this isn't much of a concern, really. > Note that if there were conffiles in bar which you wanted to become > owned by package foo, and you wanted to change the contents of that > conffile too, you would have to do extra work in preinst (but this > doesn't appear to be the case). No, it isn't. Installwatch had no conffiles. >> 3) Actually, the source packages need merging anyway. Do the >> changelogs need merging? How is that done? > Copying the changelog for package "bar" to a new file > changelog-bar-old is probably the cleanest way. Copied them > You might consider requesting uploads as an NMUs initially, though if > it were a QA-owned package this would be a "QA upload" rather than an > NMU. Ok, I'll do that when I'm ready. However, I've got a new question. Package directories (such as /usr/doc/ or /usr/lib/) are to be named after the Debian package or the real package? Note that although checkinstall and installwatch come together, they are still two separate packages (one includes the other). So the question really is: documentation for _both_ installwatch and checkinstall go into /usr/share/doc/checkinstall, or I make a new directory /usr/share/installwatch? The installwatch library (which is not intended to be shared) goes into /usr/lib/installwatch or /usr/lib/checkinstall? So far, I've favored Debian package names. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempting to adopt two packages
Justin Pryzby wrote: >> However, I can't install it via dpkg, only through apt. >> dpkg argues that it can't uninstall installwatch because checkinstall >> needs it. > But checkinstall doesn't need it, right? You should probably drop > that Depends .. You want to have Replaces+Conflicts, though. You > probably also want to add Provides, or a dummy package with the name > of the old Debian package which is now included in the new package, to > force the new package to be installed. I don't depend on installwatch. The older checkinstall needs it. So basically this is a "feature" of dpkg: checkinstall depends on installwatch. Now, checkinstall replaces+conflicts installwatch (I tried adding provides also, but it didn't work either), but dpkg refuses to upgrade because the checkinstall version _currently_ installed depends on installwatch, which has to be uninstalled in order to upgrade checkinstall. So dpkg won't look very far in time, as probably was intended, to keep it simple. > /usr/doc/ is now a policy violation; documentation must live in > /usr/share/doc/. That was a typo. I am placing stuff in /usr/share/doc. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: checkinstall - installation tracker
I have more or less made ready a new package for checkinstall and installwatch (which are now only one package). The new packages are available through debian.mentors.net [1] Major differences from previous packages: 1) Merged installwatch and checkinstall. 2) Re-Debianized the package. Reasons: merging of the packages, and because the original checkinstall debian/rules bypassed the checkinstall Makefile, because it wasn't very good. My approach was rewriting the makefile (changes sent upstream), and only doing additional work in debian/rules. [1] http://mentors.debian.net/debian/pool/main/c/checkinstall/ -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: checkinstall - installation tracker
Justin Pryzby wrote: > Your first Closes entry isn't terminated with a closing/right > parenthesis; not that it really matters. Fixed > You need to include the years of copyright (if available). Put copyright 2002-2006 > Your rules file is set up as if you produced both -arch and -indep > packages, but that isn't the case. In particular, you don't need > DH_OPTIONS at all. That must be because originally I was producing 2 packages. Deleted the extra stuff. > "useless use of cat" in the install target; you should probably just > rely on the debhelper tools to do everything like: > creating links > compressing files > creating directories > installing files Fixed manpage installation. However, I can't use dh_installdocs, because using it on installwatch's documentation would overwrite the checkinstall files. I would have to rename the files in the source (the same reason dh_install doesn't help). > You have sed commands, which aren't necessarily bad, but you could > probably just include the changes in the .diff.gz. Some are actually needed (installwatch has a hack to detect if it has been installed). I used sed scripts because I didn't want to modify the original source files (specially on the configuration file). Deleted them, and modified the source. > binary depends on build and install, but install already depends on > build. I don't know why the template is like this; I'm filing a bug > now.. Done. > Your modified makefile might use install -s to install the library, > rather than cp. Done. > BTW, did you ever figure out why dpkg wasn't allowing you to directly > install the new package? No. However, I've been playing a bit, and dpkg -B causes the package to install. Reuploaded the package. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question about CFLAGS modifiers to ./configure
Bernhard R. Link wrote: > Another problem your build log shows: > > grep -n rpath ../gnash_0.0.20060328-1_i386.build: > 194:checking for rpath... yes > [...] > 591: [...] -Wl,--rpath -Wl,/home/inniyah/gnash/gnash/libbase/.libs [...] > [...] > 748: [...] -Wl,--rpath -Wl,/home/inniyah/gnash/gnash/libbase/.libs > -Wl,--rpath -Wl,/home/inniyah/gnash/gnash/libgeometry/.libs [...] You probably can solve this by passing --disable-rpath to ./configure. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: checkinstall
Apparently my package is good enough, since it didn't get any more comments in my RFC thread [1]. I tried one last time to contact Matt Hope (previous checkinstall maintainer), and gave him a week to answer, but he didn't answer. So, I now request for a sponsor to upload the checkinstall package now [2]. Of course, any suggestions/fixes/comments are greatly appreciated. [1] http://lists.debian.org/debian-mentors/2006/03/msg00348.html [2] http://mentors.debian.net/debian/pool/main/c/checkinstall/ -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: checkinstall
Thijs Kinkhorst wrote: > The package looks fine, builds fine, good work. The only think I'd > change is to remove the README.Debian file. That contains information > that's already known: all Debian packages put their config under /etc. Done. I had put it in there because the original package installed it in /usr/lib/checkinstall/, so I considered it worth noting. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: checkinstall
Frank Küster wrote: > If the place for configuration is mentioned anywhere in the upstream > documentation, this is the place to indicate the Debian-specific > placement. Mmmh, so I put again the file, plus a note on where locales are installed (which again upstream installed in a strange location). PS: Please don't CC me, I read the list. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: checkinstall
Thijs Kinkhorst wrote: > On Thu, 2006-04-06 at 12:52 -0400, Felipe Sateler wrote: >> Frank Küster wrote: >> > If the place for configuration is mentioned anywhere in the upstream >> > documentation, this is the place to indicate the Debian-specific >> > placement. [snip] > I think that Frank meant to say that if the documentation mentions some > place for configuration files, then you should change that part of the > documentation instead of providing a separate file. I don't think so. AFAIK the package should modify the original files as little as possible. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: checkinstall
Thijs Kinkhorst wrote: > For this specific case: it's definately good to modify upstream to change > things that are Debian specific. You probably change the config file path > in the source, for example. If you do that, why shouldn't you patch the > documentation aswell? What use is it to provide incorrect information to > the end user only to correct it in some other file? Mmmh... Makes a lot of sense if you put it that way. However, I'm still a bit doubtful, since the purpose for README.Debian is to note Debian specific things about the package, meanwhile README et al are supposed to be upstream's documentation. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: checkinstall
All right, I changed the documentation to point to the actual places. However, I am doubtful if I should remove the README.Debian, since people who had worked with checkinstall (upstream, not Debian's package) previously might get confused if they don't find the configuration or the locales. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: checkinstall
Thijs Kinkhorst wrote: > I doubt it. Debian users are used to find their configuration > under /etc, because all packages do that. Even, users of any LSB/FHS > compliant distro expect that. I can't think of a reason why someone > would think that for "checkinstall" this would be different than for any > of the thousands of other packages in Debian. I'd think that too, but since checkinstall *does* install the files in such places, a person that had been using checkinstall downloaded from upstream would expect to find the files in the same places. OTOH, such a user might be very unlikely. So, README.Debian is gone, and the package has ben reuploaded. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: checkinstall
Justin Pryzby wrote: > The accepted practice is to have a symlink in /usr (or wherever) which > points to the relevant path in /etc. That way, the program doesn't > have to be hacked, if thats complicated, and users can edit whichever > path they want (assuming their editor doesn't break the link). But the symlink would be located at /usr/local, which can't be written by packages. > This is even mentioned in policy. Where is that mentioned? I can't find it. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: checkinstall
Justin Pryzby wrote: >> Where is that mentioned? I can't find it. > 10.7.2. Quote: If your package creates or uses configuration files outside of /etc, and it is not feasible to modify the package to use /etc directly, put the files in /etc and create symbolic links to those files from the location that the package requires. But the thing is I modified the package, and there is no need to create useless files/symlinks. As I also modified the documentation to point to the real places, I see no reason to create the symlinks. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: checkinstall
After some discussion on the package[1], I modified a few bits of it, so I am re-asking for sponsors. As I said last time, any suggestions/comments/critics are greatly appreciated. The package is at http://mentors.debian.net/debian/pool/main/c/checkinstall/ [1] http://lists.debian.org/debian-mentors/2006/04/msg00031.html -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keeping previous changelogs
I had the same problem with a package nyself. What I did was put the old ones in the format changelog-.Debian.old. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: checkinstall
Re posting my request, since I haven't got any sponsors yet. The package is available from mentors.debian.net. The package has a few modifications (since last request) to close some bugs. I should probably note that this version fixes various RC bugs, and hopefully I can fix all of them so checkinstall gets into etch. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
Yaroslav Halchenko wrote: > if buildd is triggered by deb revision increment as well -- there is no > difference between boosting of the upstream version or only deb > revision... There are a few benefits of only a debian revision boost. First, you only upload a small diff instead of the full package. And second, because when using debian revisions I can know who made the changes, and what I should expect from it (although that's what the changelog is there for, but anyway). -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On the trail of Linux "DLL Hell"...
Which command are you using to install libsvn-javahl? Maybe the program you are using is trying to install/remove "pending" packages (that is, packages the program thinks are scheduled for installation/removal). I've seen aptitude doing this thing at times. Also, the debian policy probably won't help you much in this issue: the policy is more geared towards package creation and maintainance, not general usage of a debian system. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xboard
Alexander L. Belikoff wrote: > Hello Florian - > > Thank you for pointing the problems out. The only excuse is that this is > my very first attempt to contribute to the Debian project and I hope > future ones will be more successful. :-) I didn't know I had to check > the unstable in order to get the most recent version, so I ended up with > version 4.2.6 without all the patches. Debian development should be done in an unstable (sid) environment, since all packages go to unstable, and then propagate to testing. If your box has debian stable, you could set up a chroot in which you install sid, and work in there. > I am still willing to take over the package maintenance. If that's ok, > what should be my next step? I can obviously take 4.2.7-4 from unstable > and release it as 4.2.7-5 with updated Maintainer's header. Is that the > right way to go? It is. However, just updating the Maintainer field is no reason to upload a package. Check the BTS for any bugs you can fix, and when you have a reason to upload (such as some bugfixes, enhancements or new upstream releases), ask for sponsorship. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: checkinstall
Hello there. I'm re-requesting a sponsor for package checkinstall (actually
this new package contains also installwatch). This package updates
checkinstall from version 1.5.3 to 1.6.0, and fixes several bugs, some of
them RC. For those not aware of what checkinstall is, from the package
description:
| CheckInstall keeps track of all the files created or
| modified by your installation script ("make install"
| "make install_modules", "setup", etc), builds a
| standard binary package and installs it in your
| system giving you the ability to uninstall it with your
| distribution's standard package management utilities.
--
Felipe Sateler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: checkinstall
Forgot to add that the packages are in mentors.debian.net: http://m.d.n/debian/pool/main/c/checkinstall/checkinstall_1.6.0-1.diff.gz http://m.d.n/debian/pool/main/c/checkinstall/checkinstall_1.6.0-1.dsc http://m.d.n/debian/pool/main/c/checkinstall/checkinstall_1.6.0.orig.tar.gz -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: checkinstall
Kari Pahula wrote: > Looks good. Just two things: > > I don't quite understand why you're closing #354389 in > debian/changelog. That bug is closed already, and I'm not sure how > it'd be explained by "New upstream version". Hmm, when I added the entry it was not fixed. Anyway, this bug was fixed upstream in the new version (actually, as you can see from the bug, it was by installwatch, but I merged installwatch and checkinstall), so that's why it's explained by "New upstream". Will remove this entry now. > Why is it Architecture: any and not all? Because although checkinstall itself is arch: all, my package includes installwatch, which is arch: any. I have uploaded a new package, with #354389 removed, and a new fix on #298152. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: checkinstall
Dear mentors, I am looking for a sponsor for the new version 1.6.0-2 of my package "checkinstall". It builds these binary packages: checkinstall - installation tracker The package is lintian clean. The upload would fix these bugs: 367935, 374648 The package can be found on mentors.debian.net at http://mentors.debian.net/debian/pool/main/c/checkinstall Or just "apt-get source checkinstall" if your sources.list contains: deb-src http://mentors.debian.net/debian unstable main contrib non-free I would be glad if someone uploaded this package for me. Kind regards -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[IGNORE] Re: RFS: checkinstall
Oops. That was meant for the drafts folder. Please ignore this post. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: zeroinstall-injector
Thomas Leonard wrote: > But, there also seems to be python-support (dh_pysupport) and > python-central. Would using one of these make my package more likely to be > accepted? I'm not keen on using python-central because most of the apt-get > failures I've had recently with other packages seem to be due to it. That is because python has gone through a transition recently. Please refer to the python policy: http://www.debian.org/doc/packaging-manuals/python-policy/ -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: zeroinstall-injector
Felipe Sateler wrote: > Thomas Leonard wrote: > >> But, there also seems to be python-support (dh_pysupport) and >> python-central. Would using one of these make my package more likely to >> be accepted? I'm not keen on using python-central because most of the >> apt-get failures I've had recently with other packages seem to be due to >> it. > > That is because python has gone through a transition recently. Please > refer to the python policy: > http://www.debian.org/doc/packaging-manuals/python-policy/ > Also, read http://wiki.debian.org/DebianPython/NewPolicy -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binary-or-shlib-defines-rpath documentation
Charles Fry wrote: > I finally found some pseudo-official documentation on this: > >http://wiki.debian.org/RpathIssue > > which confirms what you said: > >"Currently, the only valid use of this feature in Debian is to add >non-standard library path (like /usr/lib/) to libraries that >are only intended to be used by the executables (or other libraries) >within the package." Shouldn't those cases be fixed via LD_LIBRARY_PATH? > cheers, > Charles > -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bugs done, but not closed?
Hi. I was reviewing the bug page for checkinstall, which I maintain, and came across a few bugs[1] that are marked as fixed and done, but they are still listed as outstanding. I am a bit confused. All of these bugs were closed by another person by uploading another package. I think this must be related... do I need to acknowledge the closing or something like that? [1] 356864, 354389, 360564 -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs done, but not closed?
Sorry for the late reply, but the last 2 weeks have been chaos around here. Neil Williams wrote: > On 02/11/06 19:24:07, Felipe Sateler wrote: >> Hi. I was reviewing the bug page for checkinstall, which I maintain, >> and came across a few bugs[1] that are marked as fixed and done, but >> they are still listed as outstanding. > > Where? > http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=checkinstall > lists each of the bug numbers you specified under resolved: > Two under Resolved bugs -- Grave functionality bugs (3 bugs) > One under Resolved bugs -- Important bugs (5 bugs) Indeed I see the same now. Maybe the bts was updated and somehow the behaviour got corrected? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how remove leading / at dh_install ?
Thibaut Paumard wrote: > I believe the Right Thing (TM) to do is > ./configure --prefix=/usr > make > DESTDIR=$(DESTDIR) make install I'd say it is make DESTDIR=$(DESTIR) install -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
Warren Turkal wrote: >> Version of your package results in a lintian warning, because your >> version string is not like it should be in Debian. Your version should >> be foo-x.x.x (another .x is for NMUs). > > I want the package to be sorted before a real -1 release in the debian > archive so that folks installing the pre packages don't have to worry > about manually removing the pre packages to get the real ones. I will > collapse the pre packages into one changelog entry for the -1 release. You can use the ~ suffix, as in 3.6.2-beta4~pre1. These versions will evaluate lower than 3.6.2-beta4. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: liblinux-kernelsort-perl | Simple sorting library for kernel version strings
Daniel Baumann wrote: > someone somewhen decided that this is bestpractise and documented the > two leading spaces in the developers reference. roumors has it, that it > is required for some automatic tools. APT frontends reformat the description to fit in wherever they are printing it. The double space (si supposed to) prevent line breaking, so the URL will appear in one line. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: btg and libtorrent-rasterbar
Dear mentors, I am looking for a sponsor for my packages "btg" and "libtorrent-rasterbar". The library is needed for btg. libtorrent-rasterbar is lintian clean, but btg isn't (upstream included CVS directories in the tarball, should be corrected for next release). * Package name: libtorrent-rasterbar Version : 0.11-1 Upstream Author : Arvid Norberg * URL : http://www.rasterbar.com/products/libtorrent/index.html * License : BSD Section : libs It builds these binary packages: libtorrent-rasterbar-dev - bittorrent client library (development files) libtorrent-rasterbar0 - bittorrent client library The upload would fix these bugs: 402462 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libtorrent-rasterbar - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libtorrent-rasterbar/libtorrent-rasterbar_0.11-1.dsc === * Package name: btg Version : 0.9.0-1 Upstream Author : Michael Wojciechowski * URL : http://btg.berlios.de/ * License : Mainly GPL Section : net It builds these binary packages: btg-cli- command line interface to the btg daemon btg-common - BitTorrent client (common files) btg-daemon - daemon for downloading BitTorrent streams btg-gui- GUI interface to the btg daemon btg-www- web interface to the btg daemon libbtgclient0 - common files for the btg interfaces libbtgcore0 - Core library for BTG The upload would fix these bugs: 402466 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/btg - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/btg/btg_0.9.0-1.dsc I would be glad if someone uploaded these packages for me. Kind regards Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: libtorrent-rasterbar
Dear mentors, I am looking for a sponsor for my package "libtorrent-rasterbar". * Package name: libtorrent-rasterbar Version : 0.11-1 Upstream Author : Arvid Norberg * URL : http://www.rasterbar.com/products/libtorrent/index.html * License : BSD Section : libs It builds these binary packages: libtorrent-rasterbar-dev - bittorrent client library (development files) libtorrent-rasterbar0 - bittorrent client library The package is lintian clean. The upload would fix these bugs: 402462 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libtorrent-rasterbar - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libtorrent-rasterbar/libtorrent-rasterbar_0.11-1.dsc I would be glad if someone uploaded this package for me. Kind regards Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: btg
Dear mentors, I am looking for a sponsor for my package "btg". Note that this package requires libtorrent-rasterbar, for which I have just posted an RFS (link missing because it hasn't appeared on lists.d.o yet) * Package name: btg Version : 0.9.5-1 Upstream Author : Michael Wojciechowski * URL : http://btg.berlios.de/ * License : GPL (parts are LGPL and BSD) Section : net It builds these binary packages: btg-cli- command line interface to the BTG daemon btg-common - common files for BTG btg-daemon - daemon for downloading BitTorrent streams btg-gui- GUI interface to the BTG daemon btg-www- web interface to the BTG daemon libbtgclient0 - common files for the BTG interfaces libbtgcore0 - core library for BTG The package is lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/btg - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/btg/btg_0.9.5-1.dsc I would be glad if someone uploaded this package for me. Kind regards Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libtorrent-rasterbar
On Thursday 10 May 2007 04:06:56 Adam Cécile (Le_Vert) wrote:
> Hi,
>
> You may conflict with the other libtorrent devel package, as you both
> claim to provide /usr/include/libtorrent.
>
> However, at runtime both lib may be used as they don't use the same
> major version.
True. I changed the control file. A new version is up at the same location.
The diff will be different, though since it appears that I installed a new
version of autotools-dev, and config.{guess,sub} were updated.
--
Felipe Sateler
RFS: libtorrent-rasterbar
Dear mentors, I am looking for a sponsor for my package "libtorrent-rasterbar". * Package name: libtorrent-rasterbar Version : 0.11-1 Upstream Author : Arvid Norberg * URL : http://www.rasterbar.com/products/libtorrent/index.html * License : BSD Section : libs It builds these binary packages: libtorrent-rasterbar-dev - bittorrent client library (development files) libtorrent-rasterbar0 - bittorrent client library The package is lintian clean. The upload would fix these bugs: 402462 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libtorrent-rasterbar - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libtorrent-rasterbar/libtorrent-rasterbar_0.11-1.dsc I would be glad if someone uploaded this package for me. This library package is needed by BTG, which I am currently packaging too (and own the ITP). BTG can be also found in mentors.debian.net Kind regards Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
shared libraries and _REENTRANT
Policy 10.2 says we must compile shared libraries with -D_REENTRANT: > You must specify the gcc option -D_REENTRANT when building a library > (either static or shared) to make the library compatible with > LinuxThreads. However, LinuxThreads has been superseeded by NPTL. Is this still necessary? Also, when a library ships a .pc file, should it include the option in its CPPFLAGS? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared libraries and _REENTRANT
Felipe Sateler wrote: > Policy 10.2 says we must compile shared libraries with -D_REENTRANT: > >> You must specify the gcc option -D_REENTRANT when building a library >> (either static or shared) to make the library compatible with >> LinuxThreads. > > However, LinuxThreads has been superseeded by NPTL. Is this still > necessary? Some googling shows that _REENTRANT is necessary for POSIX threading, so it should be still needed. However, I can't seem to find an answer for the other question: > Also, when a library ships a .pc file, should it include the > option in its CPPFLAGS? > -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared libraries and _REENTRANT
Michael Kerrisk wrote: > Yes, as far as I've ever known (but my knowledge of requirements on early > Linux is thin), "cc -pthread" is sufficient, since it is equivalent to > "cc -lpthread -D_REENTRANT" But the library uses Boost::Thread. I guess -pthread is not implied (although libpthread should be linked anyways). -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Man pages and UTF-8
Ben Finney wrote:
> (Assuming, of course, that I'm correct in saying lenny is supposed to
> support UTF-8 throughout, and that failure to do so is a bug.)
Can somebody else confirm this? A few days ago I saw
that /usr/share/dict/{wspanish,wamerican} are ISO-8859 (which means they
can't be cat'ted in a UTF-8 terminal, and I would like to know if this is a
bug.
--
Felipe Sateler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: advice on maintainting packages on alioth ?
Thomas Jollans wrote: > Hello mentors, > > In future, I would like to maintain my packages in Mercurial (or git) > repositories. It seams the best place for these to be would be alioth, but > I'm not sure where is the best place -- should I rather request a private > sub-directory or apply for collab-maint membership and upload packages > there ? I have some doubts about collab-maint though: Maintenance is > unlikely to be collaborative, and I'm not in NM, which pretty much takes > care of the point of collab-maint as outlined on the wiki [1]. Also, I'm > not sure how readily private hg/git sub-directories are granted to > non-DDs. AFAIK, collab-maint does not have git/hg repos. It only has a svn one. If the package is unlikely to have co-maintainers, then I think it would be overkill to ask for a dedicated project. You may have more luck with any related projects (ie, if it is a perl app, asking the pkg-perl group). -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using boost headers
Carlo Segre wrote: > Upstream prefers to > continue distribution in the tarball and it would avoid having to > continually patch the configuration scripts. Maybe you could convince upstream of providing a --with-system-boost option to use either the provided copy or the external ones. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gconf-cleaner - GConf database cleaner
Rogério Brito wrote: > On Aug 10 2007, Julien Valroff wrote: >> Le vendredi 10 août 2007 à 17:32 +1000, Paul Wise a écrit : >> > That was probably CDBS, not dh_installdocs. I don't think it is a bug, >> > because not everyone lists the upstream authors in the copyright file. >> >> You are right, but shouldn't they list them in the copyright file? ;-) > > Paul is right here. Not everybody lists the upstream authors in the > copyright file. This is a bug in the packages. Not necessarily so. If the number of authors is large, there is no point in copying AUTHORS into debian/copyright. Some packages of mine say in debian/copyright: Upstream Authors: Main Author and others. For details, see the AUTHORS file provided. This way, you have automatic update of the authors when updating to a new upstream version. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gconf-cleaner - GConf database cleaner
Rogério Brito wrote: > On Aug 09 2007, Paul Wise wrote: >> Some minor issues: >> >> AUTHORS file doesn't need to be installed (debian/copyright covers it) > > Actually, some times it doesn't. You can see for yourself in the > xine-lib that I have one contribution of a deinterlacing algorithm and > some PowerPC porting, but there is no mention of it in Debian's > packages. This is a bug in the xine-lib package because it doesn't ship the AUTHORS file, even though copyright references it. Filed as #438677. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_install and python version
Alexandre Rossi wrote: > > However, I'm not quite sure about this "--install-lib > usr/lib/python$*" because : > - it's nowhere to be seen in example packages Read the Debian Python policy[1], it may clear some things up. > - I must harcode "usr/lib/python2.4/..." in debian/package.install > files, this means that my package will FTBS when python2.5 becomes the > default. Not true: you can put usr/lib/python*/... in package.install > > Shipping private modules clears the problem out (using "--install-lib > usr/share/sourcepackagename" and moving the private extension using > dh_install), but I see only advantages in shipping public modules for > the default python version. > > My next idea is to preprocess new debian/package.install.in files into > package.install files to match the python version. Is that not too > hacky? Indeed it is hacky. Check the debian python policy for how to do this. [1] http://www.debian.org/doc/packaging-manuals/python-policy/ -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to patch a patch
Mihamina (R12y) Rakotomandimby wrote:
> Hi,
> There is a list of softwares already debian packaged.
> The packager has applied a patch on them.
> I need to modify again the patched part.
> So, I need to "patch the patch".
> I guess in real world I wont patch the patch, but what is the easy way
> to do so?
> I know a bit using dpatch (or is there a replacement for it? I dont
> remember) but then,...
> Thank you for your indications.
It seems the package is using dpatch. If so, do the following:
- get the source
- copy it (pkg-vers and pkg-vers.orig)
- cd into pkg-vers
- dpatch-edit-patch
- do your thing
- exit dpatch
- cd .. ; diff -u pkg-vers{.orig,}/debian/patches/.dpatch
Another option is to apply the patch in both directories, do your change in
one of them, and then diff.
--
Felipe Sateler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian .packlist warning and debian/rules modification
Justin Pryzby wrote: > Hi, > > The debhelper tools (dh_install) used to use debian/tmp but now > (depending on DH_COMPAT) use debian/$package. So this is a small-ish > lintian bug. But debian/tmp also happens to be where dh_make defaults to install (make DESTDIR=$(CURDIR)/debian/tmp), and then copy/move files over debian/$package with dh_install. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kopete-otr 0.6-1
Raphael Geissert wrote: > * calling debian/rules deletes the autom4te.cache directory; so > running dpkg-buildpackage twice will modify the .diff.gz. You should > contact upstream and ask him/them to provide a clean tarball No, it won't. dpkg-source -b will skip missing files, and is current practice on avoiding generated files on the diff.gz. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ario
Michal Čihař wrote: > Hi > > On Tue, 11 Sep 2007 22:22:03 +0200 > "Marc Pavot" <[EMAIL PROTECTED]> wrote: > >> > - consider using system libmpd instead of bundled src/libmpdclient.[ch] >> libmp is different from libmpdclient. libmpd is a higler level library >> based on libmpdclient but Ario doesn't use libmpd. > > It provides libmpdclient.h and there are no problems to make code use > it. I did such switch in mpdscribble, but it's your choice whether to > use it. I can't seem to find it right now, but somewhere it is written that binary packages should not link with package provided libraries, but use the system one. This is done because then it is easier to correct bugs related to the original library (no need to search for packages that link with hidden copies). -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
Patrick Schoenfeld wrote: > Justin Pryzby schrieb: >>> It would be a pro to take this into the policy, wouldn't it? >> >> It is 9.3.2: >> >> | [...] > > No, it isn't. Yes, it is. You can dissect the paragraph in 3 ideas: - Behave sensibly when invoked with 'start' and already running - Behave sensibly when invoked with 'stop' and not running - Don't kill unfortunately named user processes. 2 and 3 are separated because of the comma before the 'and'. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
Patrick Schoenfeld wrote: > Because exiting with zero or non-zero has absolutely nothing to > do with "behaving sensibly". Actually returning a non-zero exit code is > the right thing to do, cause the action to stop a process _did_ fail, > because the process has not been running. Not really. It also depends on how you see it: if I ask some process to stop, I don't care if it was running or not. All I care is that it does end up stopped. I see it like this: stop: pre-requisites: none post-conditions: the service is stopped, or an error is reported -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autoconfigurable package: how to build two configurations?
Raphael Geissert wrote: > On 23/09/2007, Steve M. Robbins <[EMAIL PROTECTED]> wrote: >> Hello, >> >> Are there any examples of a package that builds two binary packages, >> each from a distinct run of "configure"? > > You first have to configure, build, install one of the packages and > then configure, build, install the second one; and in the same target > create the binary .deb. Actually, you could use different build directories: configure: configure-a configure-b configure-a: dh_testdir mkdir build-a cd build-a && ../configure --flags touch $@ configure-b: dh_testdir mkdir build-b cd build-b && ../configure --otherflags touch $@ build: build-a build-b build-a: configure-a cd build-a && make build-b: configure-b cd build-b && make etc etc. This way you don't need to erase one version to build the other. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: High-volume Debian mailing lists (was: RFS: xmms-pulse)
David Paleino wrote: > Il giorno Thu, 27 Sep 2007 18:50:13 +0200 > Ben Finney <[EMAIL PROTECTED]> ha scritto: >> >> I can also post to each group, and my messages are sent to the mailing >> list with my From field in the header. > > Can you? I can't, seems like linux.debian.* is read-only Are you sure you are using gmane? linux.debian.* sounds like google groups -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS/RFC: sketch - 3D line drawings from scene descriptions
Bernd Zeimetz wrote: > * sketch_0.2.27-1.diff.gz contains diffs to several files outside of the > debian directory. Ship proper patches for that, too, and make sure your > clean target really reverts all changes by the build process The diff.gz doesn't need to be confined to debian/. Although it is cleaner, if the package is small, and the changes aren't that many, it doesn't make much difference, and the overhead of using dpatch/quilt/other patch system seems too much. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package-name-doesnt-match-sonames
Neil Williams wrote: > On Sun, 14 Oct 2007 23:10:52 -0200 > Eriberto <[EMAIL PROTECTED]> wrote: > >> Hi mentors! >> >> I am packaging a tool to translate words (KTranslator). I fixed some > > Your most important comment is right at the end: > >> The libs are specifics to this program. > > In which case, the libs MUST NOT be in /usr/lib/ but in /usr/lib/foo - > in your case probably /usr/lib/ktranslator/. Then lintian won't bother > you. You aren't building a library package, you are building an > application that uses some private libraries. Don't make them public, > ensure that the private libraries STAY private. But then one must define RPATH to allow the binary to find the library, right? How does one ensure that the RPATH doesn't point to /usr/lib? Usually to avoid rpath one would pass --disable-rpath to configure, but this can no longer be done, right? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package-name-doesnt-match-sonames
Neil Williams wrote: > On Mon, 15 Oct 2007 13:40:43 -0300 > Felipe Sateler <[EMAIL PROTECTED]> wrote: > >> > >> >> The libs are specifics to this program. >> > >> > In which case, the libs MUST NOT be in /usr/lib/ but in /usr/lib/foo - >> > in your case probably /usr/lib/ktranslator/. Then lintian won't bother >> > you. You aren't building a library package, you are building an >> > application that uses some private libraries. Don't make them public, >> > ensure that the private libraries STAY private. >> >> But then one must define RPATH to allow the binary to find the library, >> right? > > That isn't a problem for private libraries. I know. > >> How does one ensure that the RPATH doesn't point to /usr/lib? > > Why would it? You set the libraries as private in the autotools and > they get installed in a private location using rpath. Because for some reason (broken am/ac scripts?), some autotools-based projects define an RPATH to /usr/lib when not called explicitly with --disable-rpath. But since I need an RPATH, I can't pass that flag to configure. > >> Usually to avoid rpath one would pass --disable-rpath to configure, but >> this can no longer be done, right? > > pkglib > vs > lib Aha, I had never seen this. Very useful indeed. I wonder how it reacts to the --disable-rpath flag, though (testing right now). > > prefixes in the Makefile.am. > > GnuCash is a great one for private libraries, it has dozens and dozens. > Take a look at that source. All these use an rpath and none need to be > concerned about /usr/lib, only /usr/lib/gnucash/foo/ I'll check it out. > > Then compare with libqof1 which has public libraries with SONAME > and a package name that matches the SONAME etc. I know how libraries with versioned SONAMEs work. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: csound
Hi mentors, I am looking for comments on the package csound. Csound is a sound and music synthesis system. Drawing from over 450 signal processing modules, it can be used to model virtually any synthesizer or multi-effect processor. This new version (as compared to Debian's version) contains a large number of improvements, including: * New opcodes/reworked opcodes * New frontends * A C API for creating programs * Several bindings for the C API (C++, lua, java, tcl, python) * tclsh and wish interfaces * LADSPA plugin generator * CSoundAC, and Algorithmic Composition library * PureData csoundapi~ opcode. The package has been taken over from Hans Fugal with his blessing. There is one lintian warning but it is taken care of, so please ignore it (config.log is deleted at clean). You can find the source package at mentors: - URL: http://mentors.debian.net/debian/pool/main/c/csound - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/csound/csound_5.07.0.dfsg-1.dsc -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: csound
Felipe Sateler wrote: > Hi mentors, > > I am looking for comments on the package csound. I forgot to add: current scons in unstable is broken[1], so you need an older version such as [2]. [1] http://bugs.debian.org/444204 [2] Version 0.97.0d20070809-1 at http://snapshot.debian.net/archive/2007/08/11/debian/pool/main/s/scons/ -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
It might be interesting to have an additional "seeking comments" tag. Sometimes the package is not really ready for sponsorship, or the usual sponsor is too busy right now, and all I really care is for comments on the package rather than an actual upload. This is useful when working with a package you don't have experience with: the first library, the first multi-binary package, a relatively complex package. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
