dh_install not finding files from orig source (was: Latest upstream versions of files)
Ben Finney [EMAIL PROTECTED] writes:
There is no suggestion for the best way to make this happen, though.
Ideally I'd like it to be a simple process for someone else to
generate the upstream-source tarball automatically from the online
files, and get the same result as when I do it.
My current progress on this is now online at
URL:http://mentors.debian.net/debian/pool/main/l/lojban-common.
The 'debian/get-orig-source' program is working fine, creating an
archive tarball of the original upstream files, named correctly as
'lojban-common_1.5.orig.tar.gz'. This is now the command run by the
'get-orig-source' target in 'debian/rules'.
However, I'm not having any luck building the binary package. I'm
constructing, via the 'install' target in 'debian/rules', a
'debian/lojban-common.install' file:
=
.PHONY: install
install: build
cut -d ' ' -f 3 ${SHA1SUMS_FILE} \
| sed -e 's_$$_\tusr/share/lojban_' \
debian/${PACKAGE_NAME}.install
dh install
=
This does indeed create the 'debian/lojban-common.install' file
correctly. But 'dh_install' doesn't seem to use it properly; it's
complaining about a file path that I don't understand.
=
$ bzr-buildpackage --build-dir ../build-area/
Building using working tree
Preparing the build area: ../build-area/
Looking for ../tarballs/lojban-common_1.5.orig.tar.gz to use as upstream source
Exporting to ../build-area/lojban-common-1.5
Building the package in ../build-area/lojban-common-1.5, using
dpkg-buildpackage -rfakeroot -D -si
dpkg-buildpackage: set CFLAGS to default value: -g -O2
dpkg-buildpackage: set CPPFLAGS to default value:
dpkg-buildpackage: set LDFLAGS to default value:
dpkg-buildpackage: set FFLAGS to default value: -g -O2
dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
dpkg-buildpackage: source package lojban-common
dpkg-buildpackage: source version 1.5-1
dpkg-buildpackage: source changed by Ben Finney [EMAIL PROTECTED]
dpkg-buildpackage: host architecture powerpc
fakeroot debian/rules clean
dh clean
dh_testdir
dh_auto_clean
dh_clean
dpkg-source -b lojban-common-1.5
dpkg-source: info: using source format `1.0'
dpkg-source: info: building lojban-common using existing
lojban-common_1.5.orig.tar.gz
dpkg-source: info: building lojban-common in lojban-common_1.5-1.diff.gz
dpkg-source: warning: ignoring deletion of file NORALUJV.txt
dpkg-source: warning: ignoring deletion of file cmavo.txt
dpkg-source: warning: ignoring deletion of file lujvo.txt
dpkg-source: warning: ignoring deletion of file rafsi.txt
dpkg-source: warning: ignoring deletion of file gismu.txt
dpkg-source: info: building lojban-common in lojban-common_1.5-1.dsc
debian/rules build
make: Nothing to be done for `build'.
fakeroot debian/rules binary
cut -d ' ' -f 3 debian/upstream.sha1sums \
| sed -e 's_$_\tusr/share/lojban_' \
debian/lojban-common.install
dh install
dh_testdir
dh_auto_configure
dh_auto_build
dh_auto_test
dh_testroot
dh_prep
dh_installdirs
dh_auto_install
dh_install
cp: cannot stat `debian/tmp/cmavo.txt': No such file or directory
dh_install: command returned error code 256
make: *** [install] Error 1
dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status
2
bzr: ERROR: The build failed.
=
Why is 'dh_install' looking for the file 'debian/tmp/cmavo.txt', when
that's not mentioned in the 'lojban-common.install' file?
I'd appreciate feedback from people downloading my source package and
finding where I've gone wrong.
--
\ For my birthday I got a humidifier and a de-humidifier. I put |
`\ them in the same room and let them fight it out. -- Steven |
_o__) Wright |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Which 64 bit cpu assembler to use ?
Star Liu wrote: I'm very happy to find more answers here, so i try to discuss it more :) As was mentioned earlier in the thread, this isn't a very good place to discuss this. AFAIK know the debian-mentors list is a place for people who want to learn about _contributing_to_ Debian, it isn't a place to discuss _developing_on_ Debian. first, i think maybe it's necessory for me to post this topic here, for i'm a newbie, have few knowledge on linux, so i heavily depend on the debian system. if i ask questions at other places, they may not use debian, then their solution may not apply for me, or hard to apply for my poor knowledge. Please consider using debian-user for your future Debian-related questions. i made some thinking on nasm, yasm and gas, finally i think it's a very bad thing for nasm and yasm to come out, for they don't provide much more improvement for gas, just some non-important syntax change, so i choose gas as my assembler, and it's very convinient to programming x86_64 assembly by gas and gcc. i think it's necessory for a real software developer to know assembly in order to know clearly about how software works, i have been a microsoft platform software developer for years, and tired to be a slave of ms, so i jump to assembly now. :) Personally I don't consider intimate knowledge of assembly language extremely important in order to be a good programmer. It does aid in understanding how a computer works, on a very basic level, but I'm not sure I'd suggest anyone do that on a CPU used in a modern desktop computer. I'd pick an older and (arguably) simpler CPU, something like an m68k or maybe a mips. I have to admit I don't know what AMD64 assembly is like though. thanks for your suggestions, hope i will get more help here next time i encounter difficulties. :) On Sun, Jun 22, 2008 at 12:51 PM, Jack T Mudge III [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Saturday 21 June 2008 09:14:31 pm Star Liu wrote: Greetings! I'm a newbie in assembly language programming, for I worked as a C# programmer on microsoft platform in the past years, but now I want to know clearly how operating system and softwares are executed, so I begin to learn assembly language programming, I have learned some 32 bit asm coding, and want to move to 64 bit coding. Is there any good toturial to follow? and which assembler should I use? (I have a amd64 etch installed for this task) Thanks! This is a bit off-topic for this board -- this board is for debian package sponsorship, and discussion related to maintaining debian packages. http://linuxquestions.org has a forum about programming. Maybe ask there for anything else you want to know (instead of being off-topic here) However, I'll give you a couple pointers to get you started: - nasm and yasm seem to be the assemblers available in Debian right now. - get an emulator (I use Bochs), you won't have to reboot and you'll be able to use a debugger. - Look up http://www.linuxassembly.org/ (assembly programming in linux) and http://www.osdever.net/ (all about writing operating systems) - Jack Mudge [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- - Buddha Debian GNU/Linux MSN/aMSN: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus Haskell is an even 'redder' pill than Lisp or Scheme. -- PaulPotts signature.asc Description: OpenPGP digital signature
Re: dh_install not finding files from orig source (was: Latest upstream versions of files)
Ben Finney wrote: dh_install cp: cannot stat `debian/tmp/cmavo.txt': No such file or directory dh_install: command returned error code 256 make: *** [install] Error 1 dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2 bzr: ERROR: The build failed. = Why is 'dh_install' looking for the file 'debian/tmp/cmavo.txt', when that's not mentioned in the 'lojban-common.install' file? From debhelper compatibility level 7 on, if --sourcedir is not specified, dh_install will install files from debian/tmp if the directory contains the files. Otherwise, it will install files from the current directory. -- see shy jo signature.asc Description: Digital signature
Re: RFS: bluemindo
On Tue, Jun 24, 2008 at 10:09:55PM +0200, Vincent Bernat wrote: OoO Pendant le journal télévisé du mardi 24 juin 2008, vers 20:24, Thibaut GIRKA [EMAIL PROTECTED] disait : I'll see about CDBS. In case, I can sponsor CDBS packages and give tips about solving issues with CDBS. Don't drop CDBS just because other developers do not like it. Thats not what have been said. I referred to a thread on debian-mentors about CDBS where advantages and disadvantages are communicated and I told him that using CDBS keeps him away from learning important facts about packaging. I also told him that he might think about not using CDBS. That there are sponsors who don't like to sponsor CDBS packages was just an additional hint, because there are quiet a lot people that don't like to sponsor CDBS packages and somewhere in the future he might search for a sponsor and you might not be around. Best Regards, Patrick -- 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.
A good way to fix this would be to switch to automake, there *FLAGS are only touched by people building the source, any special flags needed (such as -D) are added to AM_*FLAGS or foo_*flags. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: syx
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 24 Jun 2008 17:25:41 +0200
Jeffrey Ratcliffe [EMAIL PROTECTED] wrote:
2008/6/21 Luca Bruno [EMAIL PROTECTED]:
I am looking for a sponsor for my package syx.
* Package name: syx
Version : 0.1.7-1
Upstream Author : Luca Bruno [EMAIL PROTECTED]
* URL : http://syx.googlecode.com
* License : MIT license
Section : interpreters
IANADD, and am reviewing the package as part of the NM process. My AM
may upload the package for you if he is happy with it.
Thanks very much.
- Important: syx FTBFS in my up-to-date sid chroot:
mv doc/reference/html/extras doc/reference
rm -rf doc/reference/{html,latex,rtf,xml}
mkdir doc/reference/html
mkdir: cannot create directory `doc/reference/html': File exists
make: *** [clean] Error 1
How is it possible? The doc/reference/html is deleted just before doing mkdir.
It doesn't happen here to me.
I could put mkdir -p but it's very strange though.
- Minor: why these entries in the changelog when this is the initial release?:
* Lintian #DEBHELPER# warning has been fixed
* libsyx0 now suggests syx-doc and syx-gtk. Was recommending syx-gtk
I updated the -1 package instead of uploading -2 or -3. A developer suggested
me that.
Should I clean the changelog or should I create new versions?
- --
http://syx.googlecode.com - Smalltalk YX
http://lethalman.blogspot.com - Thoughts about computer technologies
http://www.ammazzatecitutti.org - Ammazzateci tutti
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIYmNOw9Qj+8Kak3ERAld4AJ4iVfCYvIqGZy91NSRCPQX+fnYMgwCfZtgI
aJRbBbQZOZ0Dhm0vd/+7ezc=
=zKvA
-END PGP SIGNATURE-
Some license issues (Was Re: RFS: unionfs-fuse)
Hello, Mentors with some experience ith license issues may want to chip in here! On Mon, 23 Jun 2008, Bernd Schubert wrote: - Please comply with section 4.2 of the Maintainer's guide I tried my best to fulfill these reqirements dget http://mentors.debian.net/debian/pool/main/u/unionfs-fuse/unionfs-fuse_0.20-2.dsc The general consensus is that the debian/copyright file should contain details about the copyright for each file that is included not just the primary files. I have enclosed a sample debian/copyright file for your package. You might wish to edit it before including it. Another point is that I am not very clear on the compatability of the CPL license (used in elfhash*) with the BSD code. It _seems_ to be OK and so I would upload your package, but it would be nice if you have a reference (URL or e-mail) readily available to clarify this. Regards, Kapil. -- This package was debianized by Bernd Schubert [EMAIL PROTECTED] on Wed, 12 Sep 2007 19:22:07 +0200. It was downloaded from http://podgorny.cz/moin/UnionFsFuse The brief summary of the copyright information for the files in this package is given below. The summary is followed by the detailed license texts. Files: debian/* Authors: Bernd Schubert [EMAIL PROTECTED] Copyright: Copyright 2008, Bernd Schubert [EMAIL PROTECTED] License: Modified BSD 3-Clause Files: hashtable*.[ch] Authors: Christopher Clark Copyright: Copyright 2002, 2004, Christopher Clark License: Modified BSD 3-Clause Files: elfhash.[ch] Authors: Arash Partow Copyright: Copyright 2002, Arash Partow Licence: Common Public Licences (CPL) Version 1.0 or most recent Files: cow_utils.[ch] Authors: OpenBSD developers Bernd Schubert [EMAIL PROTECTED] Copyright: Copyright 1991, 1993, 1994, The Regents of the University of California. License: Original BSD 3-Clause Files: * Authors: Radek Podgorny Maxim Konushikhin [EMAIL PROTECTED] R. Ramkumar [EMAIL PROTECTED] John Cobb [EMAIL PROTECTED] Bernd Schubert [EMAIL PROTECTED] Samuel Gelineau [EMAIL PROTECTED] Mattias Wadman [EMAIL PROTECTED] Lucas C. Villa Real [EMAIL PROTECTED] Copyright: Copyright 2008, Radek Podgorny, Bernd Schubert License: Modified BSD 3-Clause The detailed License Texts == Original BSD 3-Clause: -- The Original BSD 3-Clause licence can be found in the file /usr/share/common-licenses/BSD on a Debian system. Modified BSD 3-Clause: -- (taken from LICENSE file in source package) Copyright author_names specific to each file as detailed above All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of the original author; nor the names of any contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Common Public License - (taken from http://www.opensource.org/licenses/cpl1.0.txt) THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS COMMON PUBLIC LICENSE (AGREEMENT). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT. 1. DEFINITIONS Contribution means: a) in the case of the initial Contributor, the initial code and documentation distributed under this Agreement, and b) in the case of each subsequent Contributor: i) changes to the Program, and ii) additions to the Program; where such changes and/or additions to the Program originate from and are distributed by that particular Contributor. A Contribution 'originates' from a Contributor if it was added to the Program by such Contributor itself or anyone acting on such Contributor's behalf. Contributions do not include additions to the
Re: dh_install not finding files from orig source
Joey Hess [EMAIL PROTECTED] writes: Ben Finney wrote: dh_install cp: cannot stat `debian/tmp/cmavo.txt': No such file or directory dh_install: command returned error code 256 make: *** [install] Error 1 dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2 bzr: ERROR: The build failed. = Why is 'dh_install' looking for the file 'debian/tmp/cmavo.txt', when that's not mentioned in the 'lojban-common.install' file? From debhelper compatibility level 7 on, if --sourcedir is not specified, dh_install will install files from debian/tmp if the directory contains the files. Otherwise, it will install files from the current directory. Thanks, I wasn't aware of that change. However, that doesn't solve the mystery. If the above is an accurate description of behaviour, 'dh_install' shouldn't be exiting with an error if the file doesn't exist in 'debian/tmp'; it should only attempt to install from there if the directory contains the files. Why, then, is it exiting with a No such file or directory error trying to read the file from 'debian/tmp'? Feel free (anyone!) to use the online source package URL:http://mentors.debian.net/debian/pool/main/l/lojban-common/ to try it for yourself and see if you can explain what's going wrong better than I. -- \My doctor told me to stop having intimate dinners for four. | `\Unless there are three other people. -- Orson Welles | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: syx
2008/6/25 Luca Bruno [EMAIL PROTECTED]:
rm -rf doc/reference/{html,latex,rtf,xml}
mkdir doc/reference/html
mkdir: cannot create directory `doc/reference/html': File exists
make: *** [clean] Error 1
How is it possible? The doc/reference/html is deleted just before doing
mkdir. It doesn't happen here to me.
I could put mkdir -p but it's very strange though.
I assume that
rm -rf doc/reference/{html,latex,rtf,xml}
is a bashism, as replacing it with
rm -rf doc/reference/html
rm -rf doc/reference/latex
rm -rf doc/reference/rtf
rm -rf doc/reference/xml
sorts at least that out.
You should build the package in a pbuilder. There is quite a good
explanation[1]. Having set things up, I build the package with
sudo DIST=sid pdebuild
which with the above change now FTBFS with:
/tmp/buildd/syx-0.1.7/missing: line 54: makeinfo: command not found
WARNING: `makeinfo' is missing on your system. You should only need it if
you modified a `.texi' or `.texinfo' file, or any other file
indirectly affecting the aspect of the manual. The spurious
call might also be the consequence of using a buggy `make' (AIX,
DU, IRIX). You might want to install the `Texinfo' package or
the `GNU make' package. Grab either from any GNU archive site.
make[2]: *** [manual/syx.html] Error 1
which probably means that you should add Texinfo to the build-depends.
I updated the -1 package instead of uploading -2 or -3. A developer suggested
me that.
Should I clean the changelog or should I create new versions?
The first version uploaded to Debian should be -1. The changelog
should contain packaging changes to the previous version, plus any
bugs closed, so the only line necessary should be
* Initial release (Closes: #457782)
Regards
Jeff
[1] https://wiki.ubuntu.com/PbuilderHowto
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: RFS: bluemindo
Hi, your package now builds fince twice in a row. Well done! As I said here are my further comments: - Important: You install an extra-license file which causes a lintian warning. Refer to Policy Manual, section 12.5 for details. Please always check your package against a recent lintian from unstable. - debian/rules: Hm. You use CDBS, but you don't use python-distutils. You may want to change that. Otherwise you need to handle some things yourself. See [5] for some informations. - debian/copyright: - Please don't throw copyright and license informations together. If you have parts in the source tarball that are not licensed the same way as the main program itself, then I recommend you to open another License block with an additional (for ...) that states which file is meant. BTW. what do you think about this [1] format? - (C) has no legal meaning. You have to replace it with ©. - debian/menu: So far so good. What about providing an icon? See [2] for some information. - debian/README.source: You should rename it to .source instead of .Source because thats its filename according to policy. Otherwise its incomplete. It needs to document at a bare minimum: 1) Creating a fully-patched source, 2) Modifying the source and save those modifications to let them be applied during building 3) Remove applied modifications. See [3] for the mail originally sent by Russ. - debian/watch: Is still missing. For now you could use the watch file I've constructed for you. Or do you see complications with this? See below, I've cited the relevant parts of my previous mail at the end of this mail. - debian/compat: You use compat level 6. Do you really use any features from it? Because it has been said, that one should better use the highest supported version in a stable release, to make it easier for backports. See [4] for informations. - debian/docs: Please include the upstream changelog so that it gets installed compressed to /usr/shared/doc/$pkg/changelog.gz - debian/patches/*: You said that you think your patches speak for themselves. I disagree. There is no description what they do and the file name is not making it more obvious. You should better that by adding comments (if that is supported by simple patchsys) or by at least renaming the patches to something more meaningful. - debian/control: - Build-Depends seem to be wrong, given the python policy. See [5] - Same as above for Depends - BTW. are you sure that the Recommends are adequate? Consider that it should contain everything which the program at a whole does not neccesarily depend on, but provides functionality that is usually wanted by its users (recommends are installed by default usually) - Description needs some overhaul. See [6] and [7]. Please also check it for spelling or grammar errors. Thats it for now. More comments could follow in the next round. Best Regards, Patrick [1] http://wiki.debian.org/Proposals/CopyrightFormat [2] file:///usr/share/doc/menu/html/ch3.html#s3.7 [3] http://lwn.net/Articles/280471/ [4] http://lists.debian.org/debian-devel/2008/02/msg00184.html [5] http://wiki.debian.org/DebianPython/NewPolicy [6] http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-pkg-synopsis [7] http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-pkg-desc On Tue, Jun 24, 2008 at 09:40:56PM +0200, Patrick Schoenfeld wrote: Well, but it is fixable. Your upstream seem to have all his files in http://www.codingteam.net/upload/ with a not so fixed filename in the form, for example, 77133a-bluemindo-0.2.1.tar.gz. I suspect this beeing a hash or something, but it doesn't matter. You can let that match and then add a filenamemangle. An example which works: version=3 opts=filenamemangle=s/.*-(.*)/$1/ \ http://www.codingteam.net/upload/.*bluemindo-(.*).tar.gz -- 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.
В Wed, 25 Jun 2008 13:24:17 +0900, Charles Plessy написа: [ I had not looked at the `proda' package, sorry. ] OTHERFLAGS = -DVERSION=\1.00\ CXXFLAGS = -g -W -Wall -pedantic $(OTHERFLAGS) Use CPPFLAGS for this -- of course the recipes should be properly written in order to have some effect. The Debian build system overrides CXXFLAGS and $(OTHERFLAGS) is never passed to the compiler. Yes and no, see '(make)Environment'. If you define (or inherit from the environment) CXXFLAGS in debian/rules, and you do in the build target `$(MAKE) CXXFLAGS=$(CXXFLAGS)', and upstream's makefile defines it to something different, then of course your CXXFLAGS will be used as it is passed to all sub-`make' invocations and all assignments in the upstream makefile(s) are ignored. authoritative documentation that explains that CXXFLAGS (and others) should be expected to be changed to local values by the user. The Automake manual, or the GNU Coding Standards. CFLAGS, CXXFLAGS, CPPFLAGS, LDFLAGS, etc. are user variables so any build system that does not respect the user's choice is kind of buggy. At least for packages using the GNU build system. IOW, you should be able to define all of these variables from within debian/rules and upstream's build system should obey your choice. See '(automake-1.10)Flag Variables Ordering'. My problem is that I do not know the contents of the implicit rule building the .o files from the .h files, You can use `make -p' and examine make's internal database. nor how I can tell to make to add $(OTHERFLAGS) to this implicite rule. You cannot if the built-in make rules are used, since make doesn't know anything about that variable and it's not in the recipe. But you can do ut with CPPFLAGS. Something like this: CPPFLAGS = -DVERSION=\1.00\ CXXFLAGS = -g -W -Wall -pedantic proda : $(OBJECTS) $(CXX) $(CXXFLAGS) $(CPPFLAGS) -lm $(OBJECTS) -o proda Even if you don't put $(CPPFLAGS) in the recipe, all the individual objects will be built with -DVERSION=..., which is probably what you want. Hope that helps. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: v86d
*push* There is a new version (0.1.5-1) on mentors :) http://mentors.workaround.org/debian/pool/main/v/v86d/v86d_0.1.5-1.dsc TIA Evgeni On Wed, 2 Apr 2008 22:49:36 +0200 Evgeni Golov wrote: Dear mentors, I am looking for a sponsor for my package v86d. It is needed by the uvesafb kernel module to create a userspace framebuffer (e.g. when you want a 1400x1050 framebuffer, but vesafb does not support it). * Package name: v86d Version : 0.1.3-1 Upstream Author : Michał Januszewski [EMAIL PROTECTED] * URL : http://dev.gentoo.org/~spock/projects/uvesafb/ * License : GPL-2 Section : utils It builds these binary packages: v86d - daemon to run x86 code in an emulated environment Long description: v86d provides a backend for kernel drivers that need to execute x86 BIOS code. The code is executed in a controlled environment and the results are passed back to the kernel via the netlink interface. . v86d is needed by the uvesafb kernel module. . This package is built against glibc, as Debian's klibc does not have proper uvesafb support yet. The package appears to be lintian clean. The upload would fix these bugs: 473176 The package can be found on mentors.debian.net: - URL: http://mentors.workaround.org/debian/pool/main/v/v86d - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.workaround.org/debian/pool/main/v/v86d/v86d_0.1.3-1.dsc I would be glad if someone uploaded this package for me. Kind regards Evgeni Golov -- 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.
Le Wed, Jun 25, 2008 at 11:06:09AM +, Yavor Doganov a écrit :
OTHERFLAGS = -DVERSION=\1.00\
CXXFLAGS = -g -W -Wall -pedantic $(OTHERFLAGS)
Use CPPFLAGS for this -- of course the recipes should be properly written
in order to have some effect.
authoritative documentation that explains that CXXFLAGS (and others)
should be expected to be changed to local values by the user.
The Automake manual, or the GNU Coding Standards. CFLAGS, CXXFLAGS,
CPPFLAGS, LDFLAGS, etc. are user variables so any build system that
does not respect the user's choice is kind of buggy. At least for
packages using the GNU build system. IOW, you should be able to define
all of these variables from within debian/rules and upstream's build
system should obey your choice.
Thanks Yavor and everybody else for your answers.
I have added the following paragraph in http://wiki.debian.org/GettingPackaged
Some {{{make}}} variables are reserved to the user, and the
[http://www.gnu.org/software/libtool/manual/automake/User-Variables.html#User-Variables
Automake manual] and the
[http://www.gnu.org/prep/standards/standards.html#Command-Variables GNU coding
standards] advise to never use them for switches that are required for proper
compilation of the package. When a Debian binary package is built, variables
such as {{{CFLAGS}}}, {{{CXXFLAGS}}}, {{{CPPFLAGS}}},... are set in the
environnement and override the ones in the {{{Makefile}}}. We of course
strongly recommend to follow the above advice.
For Proda, if I pass -DVERSION=\1.00\ through CPPFLAGS, it indeeds
solves my problem. But what can I propose upstream that fits the best
practices that I just added to the wiki? If CPPFLAGS is set in the
Makefile, it could be overriden, but if it is set to
-DVERSION=\1.00\ from debian/rules, then this is one more think that
one can forget to update when a new upstream version is released...
Have a nice day,
--
Charles
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: isoqlog (updated package - 2nd attempt)
Dear mentors, I am looking for a sponsor for the new version 2.2.1-2 of my package isoqlog. It builds these binary packages: isoqlog- Mail Transport Agent log analysis program The package appears to be lintian clean. The upload would fix these bugs: 474127 (ITA) This is the changelog: isoqlog (2.2.1-2) unstable; urgency=low * New maintainer, thanks to Murat Demirten for the prior work on isoqlog (Closes: #474127) * Updated to standards version 3.8.0 + Added Homepage field * Added watch file * Update to debhelper level 5 * debian/rules: + added dh_makeshlibs -a + removed unneeded (and commented) dh_* + Added debconf-updatepo to the clean target * debian/po/templates.pot: added my email in Report-Msgid-Bugs-To field -- Giuseppe Iuculano [EMAIL PROTECTED] Tue, 24 Jun 2008 12:41:15 +0200 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/i/isoqlog - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/i/isoqlog/isoqlog_2.2.1-2.dsc I would be glad if someone uploaded this package for me. Kind regards Giuseppe Iuculano signature.asc Description: OpenPGP digital signature
Re: RFS: syx
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 25 Jun 2008 12:36:09 +0200
Jeffrey Ratcliffe [EMAIL PROTECTED] wrote:
I assume that
rm -rf doc/reference/{html,latex,rtf,xml}
is a bashism, as replacing it with
rm -rf doc/reference/html
rm -rf doc/reference/latex
rm -rf doc/reference/rtf
rm -rf doc/reference/xml
sorts at least that out.
Done.
You should build the package in a pbuilder. There is quite a good
explanation[1]. Having set things up, I build the package with
sudo DIST=sid pdebuild
Thanks for the hint. I'm beginning using that.
which with the above change now FTBFS with:
/tmp/buildd/syx-0.1.7/missing: line 54: makeinfo: command not found
WARNING: `makeinfo' is missing on your system. You should only need it if
you modified a `.texi' or `.texinfo' file, or any other file
indirectly affecting the aspect of the manual. The spurious
call might also be the consequence of using a buggy `make' (AIX,
DU, IRIX). You might want to install the `Texinfo' package or
the `GNU make' package. Grab either from any GNU archive site.
make[2]: *** [manual/syx.html] Error 1
which probably means that you should add Texinfo to the build-depends.
I've added texinfo and texlive. Texlive is needed for texi2dvi which can't run
without it.
I updated the -1 package instead of uploading -2 or -3. A developer
suggested me that.
Should I clean the changelog or should I create new versions?
The first version uploaded to Debian should be -1. The changelog
should contain packaging changes to the previous version, plus any
bugs closed, so the only line necessary should be
* Initial release (Closes: #457782)
Regards
I uploaded the -1 version again and removed the further changelog entries.
Thanks very much.
- --
http://syx.googlecode.com - Smalltalk YX
http://lethalman.blogspot.com - Thoughts about computer technologies
http://www.ammazzatecitutti.org - Ammazzateci tutti
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIYrryw9Qj+8Kak3ERAl24AJ4iwZJ0VyM1nWWkQ7YmmYFsGCDkTgCfZ/6J
zccqkXBbivxBy5i7esc0iCc=
=5bGg
-END PGP SIGNATURE-
Re: dh_install not finding files from orig source
Ben Finney wrote: Why, then, is it exiting with a No such file or directory error trying to read the file from 'debian/tmp'? Because of implementation details. It's easiest to check if the source is in . , and if not stuff the path in debian/tmp into the list of things to install, which later fails if it's not present. -- see shy jo signature.asc Description: Digital signature
Re: Problem with implicit rule for .o files and overriding of CXXFLAGS.
В Wed, 25 Jun 2008 23:14:44 +0900, Charles Plessy написа:
When a Debian binary package is
built, variables such as {{{CFLAGS}}}, {{{CXXFLAGS}}},
{{{CPPFLAGS}}},... are set in the environnement and override the ones
in the {{{Makefile}}}.
That's not entirely true and not entirely false. It's closer to being
false, though. Environment variables do not override the ones explicitly
set in the makefile (or on the command line), unless you do `make -e'.
If CFLAGS is set in the environment (f.i. by dpkg-buildpackage), and
you don't do any special handling in debian/rules, and it is defined
explicitly in upstream's makefile, the latter will be in effect.
If upstream's makefile does not define the variable, but instead has
rules with commands including $(CFLAGS), the value set by
dpkg-buildpackage will be used.
If you define
CFLAGS = ...
in debian/rules, this is a make variable, not an environment variable,
and it won't propagate to sub-make.
However, if you do
$(MAKE) CFLAGS=$(CFLAGS)
that value will be used for the build and will override upstream's value,
because variables defined on the command line override variables defined
in the makefile.
This is why it's very wrong to define CFLAGS directly in Makefile.am,
because the user cannot do
./configure CFLAGS=...
to override the value. And the user is always right.
So the right thing to do depends on the package and/or the build system
in question. As these things vary wildly and it seems new inventions
in this area is a vogue, I don't think that you can generalize and give a
common recipe that will work for all cases.
For Proda, if I pass -DVERSION=\1.00\ through CPPFLAGS, it
indeeds solves my problem.
Good.
But what can I propose upstream that fits the best practices that I
just added to the wiki?
I just downloaded 1.0-4 and the Makefile looks OK to me (apart from using
the variable for C++ compiler flags for preprocessor flags). Of
course it's not portable, but that is another story. With this define
in CPPFLAGS the behaviour is predictable and sane.
If CPPFLAGS is set in the Makefile, it could be overriden, but if it
is set to -DVERSION=\1.00\ from debian/rules, then this is one
more think that one can forget to update when a new upstream version
is released...
But this flag is upstream's and not a Debian modification, right? If
so, you just have to modify your 02-fix_CXXFLAGS.patch until upstream
does the right thing in a new release. Then you can just drop the
patch.
So If i were you I that patch would be only:
- OTHERFLAGS = -DVERSION=\1.00\
+ CPPFLAGS = -DVERSION=\1.00\
OTHERFLAGS will expand to the empty string, so it's harmless.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: syx
2008/6/25 Luca Bruno [EMAIL PROTECTED]: I uploaded the -1 version again and removed the further changelog entries. It builds now, but you have some warnings to fix: dpkg-shlibdeps: warning: symbol syx_interp_enter_context used by debian/syx-gtk/usr/lib/syx/gtk/libsyx-gtk.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: debian/syx-gtk/usr/lib/syx/gtk/libsyx-gtk.so.0.0.0 shouldn't be linked with libgthread-2.0.so.0 (it uses none of its symbols). Now running lintian... W: syx source: out-of-date-standards-version 3.7.3 (current is 3.8.0) W: syx-x11: postinst-has-useless-call-to-ldconfig W: syx-x11: postrm-has-useless-call-to-ldconfig W: syx-readline: postinst-has-useless-call-to-ldconfig W: syx-readline: postrm-has-useless-call-to-ldconfig W: syx-gtk: postinst-has-useless-call-to-ldconfig W: syx-gtk: postrm-has-useless-call-to-ldconfig W: libsyx0: package-contains-empty-directory usr/lib/syx/ Finished running lintian. Regards Jeff -- 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.
On Wednesday 25 June 2008, Yavor Doganov wrote: --cut-- Hi, If you define CFLAGS = ... in debian/rules, this is a make variable, not an environment variable, and it won't propagate to sub-make. However, if you do $(MAKE) CFLAGS=$(CFLAGS) that value will be used for the build and will override upstream's value, because variables defined on the command line override variables defined in the makefile. This is true, unless the `override' directive is used in the makefile to override variables set with a command line argument. override var = val (for recursively expanded variables) override var := val (for simply expanded variables) override var += val (to append more chars to a variable set via cmd-line) -- pub key ID 0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- 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.
Георги Данчев wrote: This is true, unless the `override' directive is used in the makefile to override variables set with a command line argument. Sure, make gives you plenty of rope to hang yourself, to abuse the users of your program, or to come up with something absolutely adorable. I didn't mention this special case deliberately, as it is very rare for these variables (for a good reason). Also, I haven't seen a Debian package that does this: build-stamp: $(MAKE) -e -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some license issues (Was Re: RFS: unionfs-fuse)
On Wed, 2008-06-25 at 14:02 +0530, Kapil Hari Paranjape wrote: I have enclosed a sample debian/copyright file for your package. You might wish to edit it before including it. This looks like it's supposed to be the machine-readable format, but it doesn't seem to comply with that spec. The License option is referring to arbitrary names of things given later in the file. I think you want License: Other with the license text below that section. See here: http://wiki.debian.org/Proposals/CopyrightFormat#head-133d3ff18d9a3119d48e96f0c8aca4a37391769f If I'm off-base here, please let me know, as I'm trying to do a machine-readable copyright file for my package right now and I'd like to do it correctly. Richard signature.asc Description: This is a digitally signed message part
Re: Problem with implicit rule for .o files and overriding of CXXFLAGS.
On Wednesday 25 June 2008, Yavor Doganov wrote: Георги Данчев wrote: This is true, unless the `override' directive is used in the makefile to override variables set with a command line argument. Sure, make gives you plenty of rope to hang yourself, to abuse the users of your program, or to come up with something absolutely adorable. I didn't mention this special case deliberately, as it is very rare for these variables (for a good reason). Also, I haven't seen a Debian package that does this: build-stamp: $(MAKE) -e Agreed. I should have mentioned that. -- pub key ID 0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: poco (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.3.2+dfsg1-2 of my package poco. It builds these binary packages: libpoco5-dev - Development files for POCO - The C++ Portable Components libpocodata5 - The C++ Portable Components Data library libpocodata5-dbg - The C++ Portable Components Data library, debug version libpocofoundation5 - The C++ Portable Components Foundation library libpocofoundation5-dbg - The C++ Portable Components Foundation library, debug version libpoconet5 - The C++ Portable Components Network library libpoconet5-dbg - The C++ Portable Components Network library, debug version libpoconetssl5 - The C++ Portable Components Network library with SSL libpoconetssl5-dbg - The C++ Portable Components Network library with SSL, dbg version libpocoodbc5 - The C++ Portable Components ODBC library libpocoodbc5-dbg - The C++ Portable Components ODBC library, debug version libpocosqlite5 - The C++ Portable Components SQLite library libpocosqlite5-dbg - The C++ Portable Components SQLite library, debug version libpocoutil5 - The C++ Portable Components Util library libpocoutil5-dbg - The C++ Portable Components Util library, debug version libpocoxml5 - The C++ Portable Components XML library libpocoxml5-dbg - The C++ Portable Components XML library, debug version The package appears to be lintian clean. The upload would fix these bugs: 487392, 487394, 487934 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/poco - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/poco/poco_1.3.2+dfsg1-2.dsc I would be glad if someone uploaded this package for me. Kind regards, -- Krzysztof Burghardt [EMAIL PROTECTED] http://www.burghardt.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some license issues (Was Re: RFS: unionfs-fuse)
Hello Kapil, hello Radek! On Wednesday 25 June 2008, Kapil Hari Paranjape wrote: Hello, Mentors with some experience ith license issues may want to chip in here! On Mon, 23 Jun 2008, Bernd Schubert wrote: - Please comply with section 4.2 of the Maintainer's guide I tried my best to fulfill these reqirements dget http://mentors.debian.net/debian/pool/main/u/unionfs-fuse/unionfs-fuse_0. 20-2.dsc The general consensus is that the debian/copyright file should contain details about the copyright for each file that is included not just the primary files. I have enclosed a sample debian/copyright file for your package. You might wish to edit it before including it. Kapil, many many thanks for your help for creating a suitable copyright file. Radek, is the attached file o.k. for you? Another point is that I am not very clear on the compatability of the CPL license (used in elfhash*) with the BSD code. It _seems_ to be OK and so I would upload your package, but it would be nice if you have a reference (URL or e-mail) readily available to clarify this. I'm not absolutely sure, but referring to http://www.ibm.com/developerworks/library/os-cplfaq.html in paragraph 12, CPL and BSD are NOT compatible. So I just rewrote the elfhash function from scratch. Well, the mathmatical lines are still the same, but this is given by the algorithm, of course. http://podgorny.cz/~bernd/hg/hgwebdir.cgi/radek-trunk-bernd-merge/rev/668c2b0ae4d0 Going to upload a another version when Radek thinks it is fine. Thanks, Bernd This package was debianized by Bernd Schubert [EMAIL PROTECTED] on Wed, 12 Sep 2007 19:22:07 +0200. It was downloaded from http://podgorny.cz/moin/UnionFsFuse The brief summary of the copyright information for the files in this package is given below. The summary is followed by the detailed license texts. Files: debian/* Authors: Bernd Schubert [EMAIL PROTECTED] Copyright: Copyright 2008, Bernd Schubert [EMAIL PROTECTED] License: Modified BSD 3-Clause Files: hashtable*.[ch] Authors: Christopher Clark Copyright: Copyright 2002, 2004, Christopher Clark License: Modified BSD 3-Clause Files: elfhash.[ch] Authors: Arash Partow Copyright: Copyright 2002, Arash Partow Licence: Common Public Licences (CPL) Version 1.0 or most recent Files: cow_utils.[ch] Authors: OpenBSD developers Bernd Schubert [EMAIL PROTECTED] Copyright: Copyright 1991, 1993, 1994, The Regents of the University of California. License: Original BSD 3-Clause Files: * Authors: Radek Podgorny Maxim Konushikhin [EMAIL PROTECTED] R. Ramkumar [EMAIL PROTECTED] John Cobb [EMAIL PROTECTED] Bernd Schubert [EMAIL PROTECTED] Samuel Gelineau [EMAIL PROTECTED] Mattias Wadman [EMAIL PROTECTED] Lucas C. Villa Real [EMAIL PROTECTED] Copyright: Copyright 2008, Radek Podgorny, Bernd Schubert License: Modified BSD 3-Clause The detailed License Texts == Original BSD 3-Clause: -- The Original BSD 3-Clause licence can be found in the file /usr/share/common-licenses/BSD on a Debian system. Modified BSD 3-Clause: -- (taken from LICENSE file in source package) Copyright author_names specific to each file as detailed above All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of the original author; nor the names of any contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Common Public License - (taken from http://www.opensource.org/licenses/cpl1.0.txt) THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS COMMON PUBLIC LICENSE (AGREEMENT). ANY USE, REPRODUCTION OR
Re: RFS: poco (updated package)
On Wednesday 25 June 2008, Krzysztof Burghardt wrote: Dear mentors, Hello, I am looking for a sponsor for the new version 1.3.2+dfsg1-2 of my package poco. It builds these binary packages: libpoco5-dev - Development files for POCO - The C++ Portable Components libpocodata5 - The C++ Portable Components Data library libpocodata5-dbg - The C++ Portable Components Data library, debug version libpocofoundation5 - The C++ Portable Components Foundation library libpocofoundation5-dbg - The C++ Portable Components Foundation library, debug version libpoconet5 - The C++ Portable Components Network library libpoconet5-dbg - The C++ Portable Components Network library, debug version libpoconetssl5 - The C++ Portable Components Network library with SSL libpoconetssl5-dbg - The C++ Portable Components Network library with SSL, dbg version libpocoodbc5 - The C++ Portable Components ODBC library libpocoodbc5-dbg - The C++ Portable Components ODBC library, debug version libpocosqlite5 - The C++ Portable Components SQLite library libpocosqlite5-dbg - The C++ Portable Components SQLite library, debug version libpocoutil5 - The C++ Portable Components Util library libpocoutil5-dbg - The C++ Portable Components Util library, debug version libpocoxml5 - The C++ Portable Components XML library libpocoxml5-dbg - The C++ Portable Components XML library, debug version The package appears to be lintian clean. The upload would fix these bugs: 487392, 487394, 487934 An excellent bug handling as well as prompt post-NMU reaction! So, uploaded and thanks for your work (no need to thank me back as well as to CC me, since, I'm subscribed to -mentors ;-) -- pub key ID 0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
RFS: clamfs (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.9.1-3 of my package clamfs. It builds these binary packages: clamfs - An user-space anti-virus protected file system The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/clamfs - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/clamfs/clamfs_0.9.1-3.dsc I would be glad if someone uploaded this package for me. Kind regards, -- Krzysztof Burghardt [EMAIL PROTECTED] http://www.burghardt.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: bindfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I'm looking for sponsor :) * Package name: bindfs Version : 1.6.1 Upstream Author : Martin Pärtel [EMAIL PROTECTED] * URL : http://code.google.com/p/bindfs/ * License : GPLv2 (parts have GPLv2+) Programming Lang: C Description : Mirror or overlay a local directory with altered permissions bindfs is a FUSE filesystem for mirroring a directory to another directory, similarly to mount --bind. The permissions of the mirrored directory can be altered in various ways. Some things bindfs can be used for: - - Making a directory read-only. - - Making all executables non-executable. - - Sharing a directory with a list of users (or groups). - - Modifying permission bits using rules with chmod-like syntax. - - Changing the permissions with which files are created. The package is lintian ivI-clean. The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/b/bindfs - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/b/bindfs/bindfs_1.6.1-3.dsc I would be glad if someone uploaded this package for me. Kind regards Eugene V. Lyubimkin - -- Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIYrT1chorMMFUmYwRArK0AKCPf+P50hxhWDSY/NU+k5hwUlxLgQCeLgvX mtHWH+XZYu38IpaoUj+QiVQ= =DvgI -END PGP SIGNATURE- -- 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.
Charles Plessy [EMAIL PROTECTED] writes: while working on an update to the `proda' package, I realised that a compilation option, DVERSION=\1.00\, was discarded during the build of the Debian binary package. The reason is very simple: OTHERFLAGS = -DVERSION=\1.00\ CXXFLAGS = -g -W -Wall -pedantic $(OTHERFLAGS) Why can't you simply change = to +=, thereby appending these flags to whatever is supplied by the user? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: pidgin-privacy-please
Dear mentors, I am looking for a sponsor for my package pidgin-privacy-please. * Package name: pidgin-privacy-please Version : 0.5.0-3 Upstream Author : Stefan Ott [EMAIL PROTECTED] * URL : http://pidgin-privacy-please.googlecode.com/ * License : GPL Section : net It builds these binary packages: pidgin-privacy-please - A pidgin plugin for enhanced privacy The package appears to be lintian clean. The upload would fix these bugs: 440413, 474303 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pidgin-privacy-please - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pidgin-privacy-please/pidgin-privacy-please_0.5.0-3.dsc I would be glad if someone uploaded this package for me. Kind regards Stefan Ott -- 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.
Le Wed, Jun 25, 2008 at 03:09:28PM +, Yavor Doganov a écrit :
?? Wed, 25 Jun 2008 23:14:44 +0900, Charles Plessy :
When a Debian binary package is
built, variables such as {{{CFLAGS}}}, {{{CXXFLAGS}}},
{{{CPPFLAGS}}},... are set in the environnement and override the ones
in the {{{Makefile}}}.
That's not entirely true and not entirely false. It's closer to being
false, though. Environment variables do not override the ones explicitly
set in the makefile (or on the command line), unless you do `make -e'.
Thanks for the clarification. Would the following be better?
When a Debian binary package is built, variables such as {{{CFLAGS}}},
{{{CXXFLAGS}}}, {{{CPPFLAGS}}},... are set by the Debian building system
to override the ones in the {{{Makefile}}}.
So If i were you I that patch would be only:
- OTHERFLAGS = -DVERSION=\1.00\
+ CPPFLAGS = -DVERSION=\1.00\
Adopted!
Have a nice day,
--
Charles
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pidgin-privacy-please
On Thu, Jun 26, 2008 at 8:22 AM, Stefan Ott [EMAIL PROTECTED] wrote: I am looking for a sponsor for my package pidgin-privacy-please. The upstream website says this requires pidgin itself to be patched, has the Debian pidgin package integrated that patch? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pidgin-privacy-please
On Thu, 2008-06-26 at 09:52 +0800, Paul Wise wrote: On Thu, Jun 26, 2008 at 8:22 AM, Stefan Ott [EMAIL PROTECTED] wrote: I am looking for a sponsor for my package pidgin-privacy-please. The upstream website says this requires pidgin itself to be patched, has the Debian pidgin package integrated that patch? Last I checked, no. Here's the comment from the p-p-p upstream README [0]: Since version 2.3.0, pidgin includes the auth-signals patch, thus you'll only need to apply the patch for blocked-signals. If you choose not to apply that patch, pidgin-privacy-please won't be able to send auto-replies when a message has been blocked. While I'm not against the idea of those signals, sending an auto-reply when a message is blocked seems pretty counter-intuitive to me. Richard [0] http://code.google.com/p/pidgin-privacy-please/wiki/ReadMe signature.asc Description: This is a digitally signed message part
