Re: Version number in rules
On Tuesday 06 May 2008, Thijs Kinkhorst wrote: > On Tuesday 6 May 2008 12:45, Sveinung Kvilhaugsvik wrote: > > Is there a way to get the Debian version as a variable in the rules > > file? Is there a standard way to remove the .dsfg from it? If we accept that cdbs could be a sort of a standard and you don't mind having cdbs listed in your build-depends (well, watch out the tradeoffs;-), then: include /usr/share/cdbs/1/rules/utils.mk in debian/rules and you will get $(DEB_NOEPOCH_VERSION) and $(DEB_UPSTREAM_VERSION) also, next to $(DEB_VERSION). If you want the trailing .dfsg chopped off from the latter, you can do it yourself as Thijs already suggested. > The following works well for me. I'm not sure but I don't believe > there's a more 'standard' way. To remove the .dfsg, add some > sed to this line. > > DEB_VERSION := $(shell dpkg-parsechangelog | egrep '^Version:' | cut -f 2 > -d ' ') Nod... That is precisely how cdbs does it for DEB_VERSION in buildvars.mk. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: figtoipe
On Sunday 11 May 2008, Vincent Bernat wrote: > OoO En ce début d'après-midi ensoleillé du dimanche 11 mai 2008, vers > > 15:39, Alexander Bürger <[EMAIL PROTECTED]> disait: > > Dear mentors, > > I am looking for a sponsor for my package "figtoipe". > > Hi Alexander! Hello, > Fill an ITP when working on a package and close it in your changelog. FWIW, lintian 1.23.48 claims that the warning for filing a new ITP can be ignored if the package is a split-off of already existing Debian package. I can only gues about the reasoning behind, but it might be that the ITP reporter in the first place had already been mentioned that `program forbar will also be included'. I'm didn't check if that is the case with ipe's ITP, though, but in any case yet another ITP would be superfluous. [1] checks/changelog-file.desc: this is in the warning tagged `new-package-should-close-itp-bug', Info: "... can be ignored if it is a split of an existing Debian package". -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
On Saturday 24 May 2008, Noah Slater wrote: > On Tue, May 20, 2008 at 02:46:59PM +0100, Noah Slater wrote: > > Done, and re-uploaded to mentors.d.o > > Hey, is there any chance someone could take another look at this please? Hey Noah, I'd rather reply with few questions ;-) -- it seems that the command-option.patch is not applied before building stage causing your help2man call to fail, since the binary knows nothing about --help. What is your idea of how to apply (before building) and unapply (on cleaning) that patch ? The patch looks quite innocent, but did you forward it upstream ? Also, you should build your package in a clean sid environment (see debootstrap and cowbuilder), which helps identification of missed build-dependencies, like help2man for instance. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug #480536 Mailbomb
On Sunday 25 May 2008, Aanjhan R wrote: > Hi Neil! Hi, > On Sun, May 25, 2008 at 1:44 PM, Neil Williams <[EMAIL PROTECTED]> wrote: > > Debian has systems that alert the maintainer to new releases, so Ernesto > > will have had a reminder already from DEHS. Not every upstream release > > needs a "Package the new version" bug report. > > Why not if it contains couple of important bugfixes? Here I disagree with Neil. While DEHS will detect it, having upstream visiting Debian BTS and emphasizing on new features/bugfixes is a good thing! > Well if you had thought hijacking the packaging, becoming a > replacement maintainer was my aim, You are WRONG! I am one of upstream > developers of this project and well I thought it makes things easier > if I could help the maintainers by packaging the software also. My aim > is not to do any of the above you have stated. My aim is just to > enable all users of Debian to get the latest of software (atleast the > ones, which I have had troubles with Debian having old software) and > everybody enjoy using Debian and its based distros. Even becoming a > Debian developer is next to the above statement for me. Having upstream who helps improving Debian is also very cool, so if you find it useful, you can co-maintain the package together with an official DD. > > This has to be a new low for debian-mentors. Sigh. > > I am disappointed with such a remark from the debian "mentors" list > and thanks for making me get better. I will remember not to upload the > .orig to the Debian BTS ever. Thanks for that. Learning by Experience > is always better :-) Misunderstandings happen, so do not feel disappointed, you can still learn something cool from Neil about debian packaging/sponsorship ;-) http://people.debian.org/~codehelp/#sponsor -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug #480536 Mailbomb
On Sunday 25 May 2008, Neil Williams wrote: --cut-- > > > Why not if it contains couple of important bugfixes? > > > > Here I disagree with Neil. While DEHS will detect it, having upstream > > visiting Debian BTS and emphasizing on new features/bugfixes is a good > > thing! > > Actually, I think we agree - the bug report didn't emphasise any new > features or detail any bug fixes so there was no benefit over the DEHS > email IMHO. When a "new upstream release" bug includes details of Debian > bugs (possibly) closed by the new version or important bugs discovered > and fixed upstream that didn't appear as Debian bugs, that I would > consider to be a good thing. True. I just missed to inspect the buglog. > > Having upstream who helps improving Debian is also very cool, so if you > > find it useful, you can co-maintain the package together with an official > > DD. > > True - but I do know of instances where upstream have become more of a > nag than a help. This could be possible, but curable sometimes. If the upstream is sensible enough it shouldn't be a great effort to teach them towards Debian habits/culture. Perhaps I'm extremely lucky having to deal high quality upstreams (a dutch CS professor and hackers from large a telecommunication company, to name a few), but they are of a great help as co-maintainers wrt packaging not so trivial libraries. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vidalia
On Sunday 25 May 2008, Colin Tuckley wrote: --cut-- Hello, > Finally, this is the first ever Debian package for vidalia so it should > have a Debian version of -1. I consider such requirement quite suboptimal. 1) you kill history 2) even not being officially published, this source package is in the wild and it is a bad idea to just reset its versioning (well unless using epoch which would be compeltely unneeded) since these users who built & installed first version of -1 from mentors won't get the updated one from official mirrors. > Unfortunately I don't think mentors will let > you upload a -1 now that you've uploaded a -2 which is unfortunate. If you > have some webspace that you could upload a new -1 package to then please do > that and let us know the URL. Having -1 as the first real Debian version > means that the orig.tar.gz gets automatically uploaded too and so makes the > sponsors job easier. I believe this adds too much hassle and confusion for everybody ;-) Even more to consider: http://people.debian.org/~codehelp/#increment and *reasoning* behind. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vidalia
On Sunday 25 May 2008, David Paleino wrote: > On Sun, 25 May 2008 17:17:04 +0300, George Danchev wrote: > > I consider such requirement quite suboptimal. [..] 2) even > > not being officially published, this source package is in the wild and it > > is a bad idea to just reset its versioning (well unless using epoch which > > would be compeltely unneeded) since these users who built & installed > > first version of -1 from mentors won't get the updated one from official > > mirrors. > > Not true: > > $ apt-cache policy > Package files: > 100 /var/lib/dpkg/status > release a=now > 500 http://ftp.it.debian.org unstable/main Packages > release o=Debian,a=unstable,l=Debian,c=main > origin ftp.it.debian.org > [..] > $ > > > Usually locally installed packages have lower priority than those available > at repositories. > When I propose one of my packages to a sponsor, I usually have it installed > (dpkg -i), and when it gets uploaded, an "apt-get upgrade" replaces it with > the officially available one. > This, of course, if version numbers match. If you locally have -2, and the > repos have -1, it won't be overwritten. > > Try. Thanks, I have tried that long before ;-) I'm sure you prefer apt-get install rather that dpkg -i especially when big and fat dependencies are being involved, so assume most users will feed and use some sort of local apt repos. Try ;-) & see the disconnect ? $ apt-cache policy pkg pkg: Installed: 1.18.1-1 Candidate: 1.18.1-1 Version table: *** 1.18.1-1 0 500 http://ftp.XY.debian.org unstable/main Packages 500 file: ./ Packages 100 /var/lib/dpkg/status -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vidalia
On Sunday 25 May 2008, Colin Tuckley wrote: > George Danchev wrote: > > On Sunday 25 May 2008, Colin Tuckley wrote: > >> Finally, this is the first ever Debian package for vidalia so it should > >> have a Debian version of -1. > > > > I consider such requirement quite suboptimal. 1) you kill history 2) even > > not being officially published, > > Please go and read what I said. This package has *never* been in Debian so > there is *no* history. Uploading it to mentors doesn't really count since > it won't stay there after it's been uploaded to Debian. the timeframe residing on mentors is not guaranteed to be short, plus there are packages which have been residing on a user's public servers for quite some time before being put on mentors, so having versioning preserved would help a lot of users. > > Even more to consider: > > http://people.debian.org/~codehelp/#increment > > and *reasoning* behind. > > Yes, I know about what Neil has said and while I agree with most of his > sponsoring suggestions I disagree with this one. It's more important (in my > opinion) that the package history in the archive doesn't have unexplained > gaps. It's more important (IMO) having packaging information logged for these who read it, i.e. why certain decisions has been made in the past or over the time. Ok fine with me, just my experience doesn't much yours. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gerris/gts: lots of doubts...
On Tuesday 27 May 2008, Ruben Molina wrote: Hi, > How can I know what other packages depends on my library for test them > too? You can use `apt-rdepends -r lib'; where lib is the package with the shared objects other packages depend on, not the -dev one they might build-depend on. But checking these is a tedious and error prone work (consider libc6 for example;-), so you are better off monitoring the ABI and API breakages in library's new releases and watch for upstream bumping the sonames where needed. An exhaustive guide with advices and best practices wrt library packaging could be found at: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ > > A package split? Not that hard - ensure you get the Replaces: and > > possibly Conflicts: correct and then move lines between foo.install and > > bar.install. (You are using debhelper? If not, do so.) > > Thank you! I do it, and it's working now. > > > > Anyway, should I work in this outdated > > > stable? > > > > No. Only work with working packages - both ends. > > OK. I focused my work on the latest snapshots. As I said before, I > tested the new package of libgts with gerris and seems to work properly, > but need testing with other packages depending on gts. I'm still > preparing man pages for this package. > > Thanks again. Thanks for your work. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
On Thursday 29 May 2008, Noah Slater wrote: > Hello, > > Thank you all for the suggestions/comments, etc. Hello, > On Sun, May 25, 2008 at 10:43:19AM +0300, George Danchev wrote: > > I'd rather reply with few questions ;-) -- it seems that the > > command-option.patch is not applied before building stage causing your > > help2man call to fail, since the binary knows nothing about --help. What > > is your idea of how to apply (before building) and unapply (on cleaning) > > that patch? > > In my debian/rules I have the following line: > > include /usr/share/cdbs/1/rules/simple-patchsys.mk > > This should automatically apply and clean the patches. It works on my > system. > > When you debuild it does CDBS not handle patches on your system? > > I am using version 0.4.52 and my package Build-Depends on cdbs (>= 0.4.42). Sure, the CDBS magic is fine, although being magic behind the scene could be dangerous sometimes. It is Debian Policy #4.9 which says: "The binary target must be all that is necessary for the user to build the binary package(s) produced from this source package". A `must', but `fakeroot debian/rules binary' yields: sed "s/@version@/0~20080520/" < lockrun.c > lockrun.sed.c cc lockrun.sed.c -o lockrun cp lockrun debian/lockrun/usr/bin help2man -N -n "a cron job overrun protection utility" ./lockrun > lockrun.1 help2man: can't get `--help' info from ./lockrun make: *** [common-install-prehook-impl] Error 2 Seems like cdbs magic doesn't cope with that, but you can still save the day: clean:: unpatch common-install-prehook-impl:: patch 2) Regenerating source files (the sed line) during the build process could be a weird source of troubles. Next, we end up having one single C file and two ways of modifying it (patch and sed ;-) -- readers won't be impressed by that ;-) If you really need that version substitution I suggest to approach the upstream to introduce a date/version variable which could be rolled by their $VCS of choice or the very developers themselves if no $VCS is being involved. 3) No diff.gz found on mentors - probably a native package done by incident ? 4) You can add a watch file, also. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hwinfo (updated package)
On Saturday 31 May 2008, William Vera wrote: > Dear mentors, Hi, > I am looking for a sponsor for the new version 14.17-1 > of my package "hwinfo". Looks solid. Uploaded. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB signature.asc Description: This is a digitally signed message part.
Re: New Packager question again: can you point me to a not flawed package?
On Sunday 01 June 2008, Russ Allbery wrote: > "Paul Johnson" <[EMAIL PROTECTED]> writes: --cut-- > > If there were 50 patches, some of which others contribute, there might > > be a chance to figure which one blows something up. As long as the > > patches are separate, there's a chance I could back-track and find the > > problem. But it seems like you are saying that you apply those 50 > > patches, and then make one jumbo diff including all changes. > > Only in the final build of the source package after everything has already > been merged. The working object is 50 separate feature branches, each of > which contain only one change, and which I can merge and update > indepedently. The only difference is when one does the merge and what > artifact of the merge one puts into the source package. > > Right now, the Git method is less than ideal for anyone working only on > the source package, since they get the merge artifact without any of the > underlying structure. 3.0 package formats will fix that; in the meantime, > if they have Git, debcheckout will get the actual repository and let them > work on the same thing that I'm working on. True. This is cool and helpful for the DD point of view while working with their $VCS, but might leave users of diff.gz with one single jumbo diff which modifies several upstream files. Please note that these users (which might happen to be the upstream developers of your package) might not even have your $VCS of choice installed or devscripts package to use debcheckout, they might be pure $UNIX users relying on patch, diff and a simple text editor. So, will you generate at some point a series logically separeted quilt patches and store them in debian/patches/ in the final diff.gz which is the canonical way of Debian to distibute changes. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Packager question again: can you point me to a not flawed package?
On Sunday 01 June 2008, Russ Allbery wrote: > George Danchev <[EMAIL PROTECTED]> writes: > > So, will you generate at some point a series logically separeted quilt > > patches and store them in debian/patches/ in the final diff.gz which is > > the canonical way of Debian to distibute changes. > > I'm currently not doing this for a very prosaic reason: I don't have a > simple tool that does it for me, and I'm too busy with other things to > write one. The choice was to stay with quilt or to give this up in > exchange for experimenting with Git, and I decided to take the latter > approach since I really needed to learn Git. I didn't play a lot with git-format-patch, but at least that looks promising. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Packager question again: can you point me to a not flawed package?
On Sunday 01 June 2008, Manoj Srivastava wrote: > On Sat, 31 May 2008 15:19:02 -0500, Paul Johnson <[EMAIL PROTECTED]> said: > > You may recall I was the one who asked yesterday "Why do you encourage > > packagers to open the source code and fool around?" I got answers > > which indicate that the source code generally should not be changed > > directly, and all changes should either be in patches that are stored > > in the debian/patches directory or in the other configuration files > > like "rules". I say "Yes, I agree" I am used to that from RPM > > building. I think you should force people to prove they can build > > packages by applying patches to an original, untouched tarball or > > putting details in a debian directory. > > Err, I don't think even half of my packages follow those > guidelines. I fall in the group of people who use a modern SCM for > development, and not a stacked patch set. I am not going to presume by > telling you that either approach is inferior, though I certain have an > opinion. There should be ways to use both, since you depreciate your diff.gz and it turns to be a useless scratch of bits. Then, again why have diff.gz at all when it is not credible enough ? > I do have a emacs package you can look at for details, if you > wish: http://git.debian.org/git/users/srivasta/debian/vm.git Using a modern SCM is wonderful, but please, get back to the ground, and think of the possible use cases with what Debian has officially released, and if that is what warns a certain level of unification. There are users (let's say within restricted areas) who can't access random DD repos at will, but rely solely on diff.gz supplied by released source CD/DVD media. Please note that development history of changes is not of any help here, but what exactly has been applied (as logically separated changes) to a particular upstream version being released. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
the quality of Debian's diff.gz
need some > net access -- or, with the 3.0 (git) format, have their topic branches > on their DVD. Realistically speaking, do you have any numbers on such > users who must rely on DVD's and can't get someone to burn a DVD for > them? Do you suggest cloning every pkg repo out there and burning that to DVD, then rush over to the company's restricted area passing various identification checks ? It doesn't scale well in my opinion. Realistically speaking there are certain entities (consider some government agencies, but also some companies) who might happen to use Debian in areas where public networks are not allowed, because they are supposed to obey certain policies. And I doubt there is an easy way to gain any hard numbers about such users, since most probably they will pretend they do not exist ;-) > There is a tradeoff. There is correctness of the package , which > is eased by using topic branches (at least, for me), which trumps the > use cases you are talking about. Now, in cases where the branches do > not overlap, there can be a simple conversion to a stacked patch > format; and I'll have no objection to using a tool that can do the > conversion (at the expense of source package size bloat). It sounds pretty fair to me to trade some size for more readability. On Sunday 01 June 2008, Ben Finney wrote: > George Danchev <[EMAIL PROTECTED]> writes: > > Using a modern SCM is wonderful, but please, get back to the ground, > > and think of the possible use cases with what Debian has officially > > released, and if that is what warns a certain level of unification. > > There are users (let's say within restricted areas) who can't access > > random DD repos at will, but rely solely on diff.gz supplied by > > released source CD/DVD media. > > It sounds like you are strongly motivated to contribute to a tool that > will allow developers that track changes in their VCS to automatically > generate the 'debian/patches/' directory that you are so interested in > seeing. Consider "you" as the rest of the world, even non-debian users, since they might want to grab something from these diff.gz, and not to fight with the great number of VCS in use for debian packaging if they bother to find the repos at all. > Stronger motivated than, say, the motivation felt by the VCS-using > developer themselves, who already has a workflow that functions fine. The point is not about VCS-using developers themselves, obviously their workflow is fine for them, it is about the ability of the rest of the world to follow their workflow. Obviously Debian doesn't release yet various pkg-repos. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the quality of Debian's diff.gz
On Sunday 01 June 2008, Ove Kaaven wrote: > George Danchev skrev: > > Very good, but please make these easily visible/readable to the rest via > > diff.gz > > Oh no, not again... This was already flam^H^H^H^Hdebated on > debian-devel. I believe debian-mentors is where new maintainers learn > current best practices, not where *new* practices are developed; for > that, you'd go to debian-devel. I don't see any new practices being developed here, Debian's diff.gz exists from the Debian packaging system's day 1 and abusing it prophesies no good. What I consider a good practice is: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/slow-patch.html see, the PATCHDIR usually called files/ (analog to debian/patches/) from where they will be automatically applied to the upstream code. Please also note, that the whole thing (diffs against the upstream port code included) is also kept in VCS: http://www.freebsd.org/cgi/cvsweb.cgi/ports/ Finally you don't need their VCS to see what has been applied to upstream (ports) source code. > Feel free to join the efforts there. That didn't produced anything meaningful. OTOH it is very easy to suppress useful discussions wrt improvements and quality by simple bureaucratic means (either the list is being awfully wrong, or the reply is a blatant violation of CoC, which was finally fixed recently) and applaud frivolously how Debian rox. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the quality of Debian's diff.gz
On Sunday 01 June 2008, Manoj Srivastava wrote:
> On Sun, 1 Jun 2008 13:37:43 +0300, George Danchev <[EMAIL PROTECTED]> said:
--cut--
> Peer reviewers can either look at the SCM archive (since that is
> how the package is developed), or the divergence bugs, when they get
> filed. I am not sure the diff.gz is the best way for collaborative
> development.
Of course diff.gz is not the best way for collab development, but it is a
pretty decent and cheap way to review how the upstream code has been patched.
Think security and safety wise.
> >> Anything less is not good practice; we should be sending our
> >> divergence upstream.
> >
> > Very good, but please make these easily visible/readable to the rest
> > via diff.gz
>
> Why via the diff.gz? Why is the divergence bug mechanism not
> being considered?
Because people would hardly trust BTS for sourceful changes being applied to a
particular source tree.
> >> > devscripts package to use debcheckout, they might be pure $UNIX
> >> > users relying on patch, diff and a simple text editor. So, will
> >> > you generate at some point a series logically separeted quilt
> >> > patches and store them in debian/patches/ in the final diff.gz
> >> > which is the canonical way of Debian to distibute changes.
> >>
> >> This can only work if the topic branches are non-overlapping; and
> >> that might cover a lot of cases, but not all.
> >>
> >> I am not so sure it is indeed a canonical way of doing things in
> >> Debian. If it is, which canon do you follow?
> >
> > The above sentence of mine says: "diff.gz which is the canonical way
> > of Debian to distibute changes.". A normative document stipulates:
> > "debianisation diff is a unified context diff (diff -u) giving the
> > changes which are required to turn the original source into the Debian
> > source.". The mere request is to make your debianisation diff a good
> > citizen, which should be able to create the logically separated
> > changes to the upstream code clearly identified and documented diff
> > files. Then, the rest of the world can just get that diff.gz from
> > myriad of media *at their will* and try it against whatever
> > orig.tar.gz or local SCM working copy they have.
>
> I think that the diff.gz might not be the best way of
> disseminating the changes to the rest of the community. Distributed
> SCM's are far more powerful than stacked patches, and I want to bring
> my downstream the benefits of a distributed version control system, and
> bring them into the development fold, so to say.
That leads to unification of a single SCM for packaging. I'm not really
hopeful it is possible within Debian, are you ?
> >> > There should be ways to use both, since you depreciate your diff.gz
> >> > and it turns to be a useless scratch of bits. Then, again why have
> >> > diff.gz at all when it is not credible enough ?
> >>
> >> Credible \Cred"i*ble\ (kr[e^]d"[i^]*b'l), a. [L. credibilis, fr.
> >> credere. See {Creed}.] Capable of being credited or believed; worthy
> >> of belief; entitled to confidence; trustworthy.
> >>
> >> I find the diff.gz as credible as anything else. Why would it be less
> >> trustworthy?
> >
> > It is less trustworthy since it applies in a combined fashion multiple
> > changes to the upstream tree, which leaves the bad impression of that
> > whoever created it doesn't have a clear idea of what he was doing.
>
> I think that such a conclusion merely shows the naivete of the
> person reaching that conclusion. The diff.gz represents the integration
> branch, is meant to deliver the sources the package was built with. It
> is not a means for collaborative development, really.
I already said that it is not meant for collab development, but to check if a
certain package could bring your troubles since it was badly patched by
certain contributors, and that package runs happily as supplied by other
distributors.
> >> In any case, as development proceeds, tools change. patch and diff
> >> were great, once upon a time, just like programming in raw Hex was
> >> still in vogue when I started programming.
> >>
> >> >> I do have a emacs package you can look at for details, if you
> >> >> wish:
> >> >> http://git.debian.org/git/users/srivasta/debian/vm.git> >
> >> >
> >> > Using a modern SCM is wonderful, but please, get back to the
> >> > ground,
> >>
> >> I don'
Re: the quality of Debian's diff.gz
On Sunday 01 June 2008, Don Armstrong wrote: > On Sun, 01 Jun 2008, George Danchev wrote: > > Because people would hardly trust BTS for sourceful changes being > > applied to a particular source tree. > > The point of the BTS in this regard is to track the issues that lead > to divergence; as a bonus you get a patch attached. If you don't trust > that the patch attached by the maintainer is actually the patch that > the maintainer is using, how are you going to trust the VCS or even > the diff.gz in the archive is the actual patch that is being used? Because diff.gz along with .orig.tar.gz and .dsc is what you actually feed buildd with, and is actually burnt on Debian offical images. OTOH wrong patch set could be sent to the BTS, erroneous bug manipulations do happen by accident... why yet another player must be added to the patching game, isn't it complicated enough yet for overloaded parties: http://lists.debian.org/debian-devel/2008/05/msg00623.html > Furthermore, linking a divergence to a VCS revision is pretty easy, > and upstreams resolving the divergences will lead to the relevant > patches disappearing anyway. > > > Sure, that sounds pretty good to me, but would probably take decades > > to deploy all debian source packages 3.0 (git) way, since 3.0 > > (quilt) is currently on topic. > > Huh? This isn't an either/or situtation. We can have many SCM/VCS > package formats in Debian. If review of them is something that you > really want to see happen, you can make unified frontends to those > SCM/VCS that reproduce a stack of patches. > > All this takes is someone doing the work; there's nothing inherent in > any of the modern DVCSes that makes this impossible. If these tools are not ready yet, why unreadable diff.gz have been uploaded to the debian archive ? I'm sorry, but doing uncoordinated moves causes a massive disturbance in the trust. I'm utterly disappointed, and will stop at that point. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: poco and poco-doc (updated packages) [3rd try]
On Friday 06 June 2008, Vincent Bernat wrote: > OoO En cette nuit nuageuse du vendredi 06 juin 2008, vers 00:26, > > "Krzysztof Burghardt" <[EMAIL PROTECTED]> disait: > >> As Cyril stated in another post, you must (by policy) put this > >> information in debian/copyright. Sorry to have hinted an outdated > >> information (some translations are not up-to-date, look at the english > >> version of the policy). > > > > Done. > > > > http://mentors.debian.net/debian/pool/main/p/poco/poco_1.3.2+dfsg1-1.dsc > > http://mentors.debian.net/debian/pool/main/p/poco-doc/poco-doc_1.3.2-1.dsc --cut-- > /tmp/buildd/poco-1.3.2+dfsg1/Foundation/include/Poco/HashTable.h:82: error: > 'memset' was not declared in this scope > /tmp/buildd/poco-1.3.2+dfsg1/Foundation/include/Poco/HashTable.h: In member > function 'void Poco::HashTable KeyHashFunction>::resize(Poco::UInt32) [with Key = std::basic_string std::char_traits, std::allocator >, Value = int, > KeyHashFunction = Poco::HashFunction std::char_traits, std::allocator > >]': > src/HashTableTest.cpp:149: instantiated from here > /tmp/buildd/poco-1.3.2+dfsg1/Foundation/include/Poco/HashTable.h:317: > error: 'memset' was not declared in this scope > > It is likely to be a missing include somewhere. Correct; this was fixed in upstream's trunk rev525: http://poco.svn.sourceforge.net/viewvc/poco/poco/trunk/Foundation/include/Poco/HashTable.h?r1=434&r2=525 -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: poco and poco-doc (updated packages) [3rd try]
On Saturday 07 June 2008, Krzysztof Burghardt wrote: > 2008/6/6 Vincent Bernat <[EMAIL PROTECTED]>: > > OoO En cette nuit nuageuse du vendredi 06 juin 2008, vers 00:26, > > > > "Krzysztof Burghardt" <[EMAIL PROTECTED]> disait: > >> http://mentors.debian.net/debian/pool/main/p/poco/poco_1.3.2+dfsg1-1.dsc > >> http://mentors.debian.net/debian/pool/main/p/poco-doc/poco-doc_1.3.2-1.d > >>sc > > > > gcc 4.3 is now the default on amd64 and i386. Therefore, I get an error > > that I did not get previously: > > [...] > > > It is likely to be a missing include somewhere. > > Fixed. Hi Krzysztof, As a user of that package, I'm still reluctant to ship it in a shape where lintian is not happy enough. I've read your reasoning about debug package names you have choosen, but I still don't see a good reason not to have package names end in -dbg, which would keep the package namespace sane enough [1] and brings predictable names for searching on the debian package database; these packages of course would still ship the files as they are considered now: i.e. /usr/lib/debug/usr/lib/libPocoXMLd.so.5, which would help the linkage of projects used it that way. Also, don't forget to gzip -9 changelogs as per policy 12.7. After these are resolved I'd sponsor. [1] that will pass through the NEW queue because of the new binary packages being splitted-off, and I believe that ftpmaster won't be happy with the provided names, so you might need to do it anyway, hence I suggest to avoid the misapproach ;-) -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: poco and poco-doc (updated packages) [3rd try]
On Saturday 07 June 2008, Krzysztof Burghardt wrote: > Hello George, > > 2008/6/7 George Danchev <[EMAIL PROTECTED]>: > >As a user of that package, I'm still reluctant to ship it in a > > shape where lintian is not happy enough. I've read your reasoning about > > debug package names you have choosen, but I still don't see a good reason > > not to have package names end in -dbg, which would keep the package > > namespace sane enough [1] and brings predictable names for searching on > > the debian package database; these packages of course would still ship > > the files as they are considered now: i.e. > > /usr/lib/debug/usr/lib/libPocoXMLd.so.5, which would help the linkage of > > projects used it that way. > > This looks reasonable, but trigger another lintian warrning: > > N: Processing binary package libpocoxml5-dbg (version 1.3.2+dfsg1-1) ... > W: libpocoxml5-dbg: package-name-doesnt-match-sonames libPocoXMLd5 sure, lintian has provided you with oneliner (as copied verbatim from libpkg-guide #3 Naming shared library packages) to determine the correct package name out of the soname, but unfortunately it doesn't seem to be working for object files containing debugging information (I didn't check why, will probably do;-): $ objdump -p usr/lib/debug/usr/lib/libPocoXMLd.so.5 | sed -n -e's/^[[:space:]]*SONAME[[:space:]]*//p' | sed -e's/\([0-9]\)\.so\./\1-/; s/\.so\.//' So, as libpkg-guide suggests in table 5.1 (soname: libfoo.so.4 => pkgname: libfoo4) and lintian asks us to end in -dbg since we install in /usr/lib/debug, therefor the above package should be named as libpocoxmld5-dbg. I'm not sure if lintian is prepared not to take into account the requested -dbg$ to the package name when comparing it to the sonames, but if it keeps emitting package-name-doesnt-match-sonames, shutting it up with an override seems to be in order. > > Also, don't forget to gzip -9 > > changelogs as per policy 12.7. After these are resolved I'd sponsor. > > I'm not sure what problem you have pointed out. Upstream changelog in > installed with dh_installchangelog, its name is changed and its > gziped. I still get changelog-not-compressed-with-max-compression changelog.gz for all the packages despite dh_installchangelogs and dh_compress are called correctly. Will have look into that deeper. [1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html (keep that handy;- ) -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: poco and poco-doc (updated packages) [3rd try]
On Sunday 08 June 2008, Russ Allbery wrote: > George Danchev <[EMAIL PROTECTED]> writes: > > On Saturday 07 June 2008, Krzysztof Burghardt wrote: > >> This looks reasonable, but trigger another lintian warrning: > >> > >> N: Processing binary package libpocoxml5-dbg (version 1.3.2+dfsg1-1) ... > >> W: libpocoxml5-dbg: package-name-doesnt-match-sonames libPocoXMLd5 > > > > sure, lintian has provided you with oneliner (as copied verbatim from > > libpkg-guide #3 Naming shared library packages) to determine the correct > > package name out of the soname, but unfortunately it doesn't seem to be > > working for object files containing debugging information (I didn't > > check why, will probably do;-): > > > > $ objdump -p usr/lib/debug/usr/lib/libPocoXMLd.so.5 | > > sed -n -e's/^[[:space:]]*SONAME[[:space:]]*//p' | > > sed -e's/\([0-9]\)\.so\./\1-/; s/\.so\.//' > > I think there's something more fundamentally wrong here. If this is a > regular shared library, not detached debugging symbols, it's in the wrong > directory. The *only* thing that should be in /usr/lib/debug is detached > debugging symbols. Yes, dh_strip -k was called to split debigging symbols in a separate file (containing the detached debugging symbols) in usr/lib/debug/, in order to avoid binary duplications with things we want debugable, but the above oneliner produces no package name for so generated object file. Turning back to dh_strip --dbg-package=... the above oneliner (as also used internally by lintian I believe ?) produces a package name: objdump -p debian/libpocoxml5-dbg/usr/lib/libPocoXMLd.so.5 | sed -n -e's/^[[:space:]]*SONAME[[:space:]]*//p' | sed -e's/\([0-9]\)\.so\./\1-/; s/\.so\.//' libPocoXMLd5 shared library goes in /usr/lib and as expected lintian complains with: libpocoxml5-dbg: package-name-doesnt-match-sonames libPocoXMLd5 because of the missing 'd' before '5', at least, hence that leads us to a package name as `libpocoxmld5-dbg', is that correct ? > (There's a lintian check for that as well; I'm not > sure why it's not triggering -- maybe I'm misunderstanding what's going > on?) the goal was/is to generated -dbg packages that are using separate (detached) debugging info and stored in /usr/lib/debug/, thus do you reference to check described in #299578 ? > If you're shipping a debugging version of the shared library that's a full > shared library in its own right because building with debugging changes > the library, then yes, you'll need to override a warning about the package > name. But it should be in /usr/lib. Just to make it crystal clear for myself, a package name override is needed because of the ending -dbg only, right ? -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: poco and poco-doc (updated packages) [3rd try]
On Sunday 08 June 2008, George Danchev wrote: --cut-- > Yes, dh_strip -k was called to split debigging symbols in a separate file > (containing the detached debugging symbols) in usr/lib/debug/, in order to > avoid binary duplications with things we want debugable, but the above > oneliner produces no package name for so generated object file. oh, I'm absent-minded - oneliner doesn't output a package name since objdump works on a file with detached debuggin symbols only, i.e. the addon, not the library itself ;-), so forget about it. Other questions still stand. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: poco and poco-doc (updated packages) [3rd try]
On Sunday 08 June 2008, George Danchev wrote:
> On Saturday 07 June 2008, Krzysztof Burghardt wrote:
> > Hello George,
Hi Krzysztof,
--cut--
> So, as libpkg-guide suggests in table 5.1 (soname: libfoo.so.4 => pkgname:
> libfoo4) and lintian asks us to end in -dbg since we install
> in /usr/lib/debug, therefor the above package should be named as
> libpocoxmld5-dbg.
I did rename them to *d5-dbg (libpocoxmld5-dbg) as I proposed earlier, but run
into another "violation of the law" - X vs. X-dbg ;-)
W: libpocoxmld5-dbg: dbg-package-missing-depends libpocoxmld5
N:
N: This package has a name of the form of "X-dbg", indicating it contains
N: detached debugging symbols for the package X. If so, it should depend
N: on the corresponding package, generally with (= ${binary:Version})
N: since the debugging symbols are only useful with the binaries created
N: by the same build.
So I believe that the version 1.3.2+dfsg1-1 you have uploaded to mentors on
07-Jun-2008 22:00 (ah I hate dealing with rewritten changelog history;-) is
basically ok, except that lintian override files should be installed for all
these -dbg packages in /usr/share/lintian/overrides/$pkg-dbg, for instance:
libpocoxmld5-dbg: package-name-doesnt-match-sonames libPocoXMLd5
Rf. file:///usr/share/doc/lintian/lintian.html/ch2.html#s2.4
Another way to solve the soname_d vs. pkgname_without-d-dbg issue is to play
with symlinks, i.e. libPocoXML.so.5->libPocoXMLd.so.5 (or other way around),
but that still does not look clean enough to me, and we can add it anyway
further if needed.
I still get these changelog-not-compressed-with-max-compression changelog.gz
warnings for -dbg packages, but that doesn't warrant a override.
--
pub 4096R/0E4BD0AB 2003-03-18
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: poco and poco-doc (updated packages) [3rd try]
On Monday 09 June 2008, Russ Allbery wrote: > George Danchev <[EMAIL PROTECTED]> writes: > > shared library goes in /usr/lib and as expected lintian complains with: > > libpocoxml5-dbg: package-name-doesnt-match-sonames libPocoXMLd5 > > because of the missing 'd' before '5', at least, hence that leads us to a > > package name as `libpocoxmld5-dbg', is that correct ? > > Oh, I get it, you're shipping *both* detached debugging symbols *and* a > debug version of a library in /usr/lib in the same package. > > No, Lintian will want such a package be named libpocoxmld5 because it has > no way of knowing that shared library is a debugging version of some other > library. You will indeed need an override for this case. Actually it would be smarter do ship only the detached debugging symbols I believe. I can't think of a use case where the debugging version of the shared library would be desperately needed or preferred, or I'm wrong ? > > the goal was/is to generated -dbg packages that are using separate > > (detached) debugging info and stored in /usr/lib/debug/, > > This is not all that you're doing, which is what was confusing me. You're > also shipping a different shared library in the same package, which > happens to be a debugging build of another shared library. > > If the package contained only detached debugging information, Lintian > wouldn't be confused. Nod. By the way I was looking at the lintian-1.24.0/checks/binaries: around row 148; shouldn't expected_name as of name.so.[0-9] also be taken into account ? -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: poco and poco-doc (updated packages) [3rd try]
On Monday 09 June 2008, Krzysztof Burghardt wrote: > 2008/6/8 George Danchev <[EMAIL PROTECTED]>: > > So I believe that the version 1.3.2+dfsg1-1 you have uploaded to mentors > > on 07-Jun-2008 22:00 (ah I hate dealing with rewritten changelog > > history;-) is basically ok, except that lintian override files should be > > installed for all these -dbg packages in > > /usr/share/lintian/overrides/$pkg-dbg, for instance: > > Warnings overwritten. Package updated once again. > > http://mentors.debian.net/debian/pool/main/p/poco/poco_1.3.2+dfsg1-1.dsc > http://mentors.debian.net/debian/pool/main/p/poco-doc/poco-doc_1.3.2-1.dsc Uploaded. That will hang in NEW for a while. Thanks for your work and patience. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: poco and poco-doc (updated packages) [3rd try]
On Monday 09 June 2008, Russ Allbery wrote: > George Danchev <[EMAIL PROTECTED]> writes: > > Actually it would be smarter do ship only the detached debugging symbols > > I believe. I can't think of a use case where the debugging version of > > the shared library would be desperately needed or preferred, or I'm > > wrong ? > > Well, usually the reason why a shared library builds a separate debugging > version is that the code actually changes. In other words, rather than > just having debugging symbols, the functions in the library actually work > differently. Perhaps more checking is done, or more logging, or the like. > > If that isn't the case here and the only difference is that one has > debugging symbols and the other doesn't, then I agree, you should just > ship the detached debugging symbols for the regular library and ignore > (and not package) the d version. Ah sure, that makes sense to me. Thanks. > > Nod. By the way I was looking at the lintian-1.24.0/checks/binaries: > > around row 148; shouldn't expected_name as of name.so.[0-9] also be > > taken into account ? > > I can't figure out what you're getting at. Line 148 is: > > $expected_name =~ s/\.so(\.|\z)//; > > which is one part of the code that mangles a library SONAME into a package > name. This line removes the ".so." part of the SONAME. > Ops, sorry bad row counting. I meant that $expected_name =~ s/([0-9])\.so\./$1-/; won't cope with well with name.so.1 -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: swedish (updated ispell and spell packages)
On Wednesday 11 June 2008, Jeremiah C. Foster wrote: --cut-- Hi, > > The package is still recognized as Debian native, simply because there's > > only a tar.gz, without a diff.gz. It's not sufficient to change the > > version number to 1.4.5-2, you need to create a tarball *without* the > > debian/ directory, call it 1.4.5, add the debian/ directory again and run > > dpkg-source. This way, you will get a diff.gz. > > I don't understand. How do I create a diff.gz? (I know how to use > diff, but what is this a diff of? Two different tarballs?) It is a diff between the original_upstream_source_directory/ and the debianized_tree/ (i.e. upstream_dir/ + debian/ inside). Since you have orig.tar.gz and the debianized tree (upstream_name-x.y + your own debian/ inside) dpkg-source is able to create such diff.gz: dpkg-source -b upstream_namedir-x.y > > > > - Convert debian/copyright to UTF-8 > > > > > > Done. > > > > You converted it to ASCII. Please use UTF-8, use e.g. iconv for that. > > Also, you've removed your own copyright statement for the Debian > > packaging. > > Added my copyright statement back, changed to UTF-8 using > iconv. The `file` command is still saying ASCII however. Since UTF-8 is a superset of ASCII and there are only ASCII characters inside your copyright, therefore file reports ASCII text. However, UTF-8 being a variable length encoding can use more than one (1 to 4 bytes) for each character, depending on the character; for instance had characters like greek letters or german umlauts been in the file (where more than one byte per character is used), `file' wouldn't be reporting ASCII text. > Not sure how > to determine proper encoding. There is no universal method to determine that, that's why iconv has --from-code ;-) In that case, your copyright file is a valid ASCII as well as valid UTF-8. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: s5 - A simple HTML-based presentation system (uploaded package)
On Thursday 12 June 2008, Peter Pentchev wrote: > Dear mentors, > > I am looking for a sponsor for my package "s5". Peter, This package is now uploaded. Thanks for your work [1] on the neat `s5' utility, especially I like the minimalistic requirements for it to run -- a Base System ;-). [1] or better, should I thank the FreeBSD project for contributing packages to Debian ? ;-) -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: python-minimock
On Friday 13 June 2008, Robert Collins wrote: > On Fri, 2008-06-13 at 10:58 +0200, Michal Čihař wrote: > > Hi > > > > On Fri, 13 Jun 2008 18:46:03 +1000 > > > > Ben Finney <[EMAIL PROTECTED]> wrote: > > > Unfortunately they require using a Subversion repository. One of the > > > big advantages of Alioth is that I don't have to use Subversion > > > repositories for my packages :-) > > > > For good reason, because it is most widely known VCS and thus it is > > easy to use for anybody else in the team. But it's up to you if you > > want to join or not... > > I thought CVS still had more users :) Errr, you missed to sense the context, didn't you ;-) CVS is not widely spread for debian packaging anymore, believe me ;-) If we talk in general the only CVS users left are those locked-in CVS because of certain decisions being made in the past towards a CVS-orientation and it is not easy to rebuilt the infrastructure, so consider them some sort of convicts, not happy users ;-) -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: fbreader (updated package)
On Saturday 14 June 2008, Eugene V. Lyubimkin wrote: --cut-- Hi, > One more question about quilt: dpkg-buildpackage stands that fbreader > source is 1.0 source package. Should I correct it to be 3.0-quilt? If yes, > how can I do it? I haven't found any info about it in policy and > devreference. You will need dpkg >= 1.14.18 [1] and follow [2] to check your package how Raphael described. [1] see "New source package formats" at: http://lists.debian.org/debian-devel-announce/2008/04/msg4.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482741 -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: fbreader (updated package)
On Sunday 15 June 2008, Eugene V. Lyubimkin wrote: > George Danchev wrote: > >> One more question about quilt: dpkg-buildpackage stands that fbreader > >> source is 1.0 source package. Should I correct it to be 3.0-quilt? If > >> yes, how can I do it? I haven't found any info about it in policy and > >> devreference. > > > > You will need dpkg >= 1.14.18 [1] and follow [2] to check your package > > how Raphael described. > > > > [1] see "New source package formats" at: > > http://lists.debian.org/debian-devel-announce/2008/04/msg4.html > > [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482741 > > Thanks for links. > > And, another question then: would converted to 3.0-format packages are > acceptable by sponsors and by ftp-masters now? Or It would be better to > wait for lenny release and then introduce such changes? Just check your package for yourself, correct the failures if any, and *wait* patiently until after lenny release, at least ;-) As said above, please reread [1] thoroughly: "Bug #457345 [6] is the wishlist bug tracking the dak modification that will be needed to accept those new source package formats." Rf: dak (the debian archive kit) is not ready yet to accept these new source formats. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gtkwhiteboard (now dfsg compatible)
On Sunday 15 June 2008, Thomas Knott wrote: > Dear mentors, Hi, > I am looking for a sponsor for my package "gtkwhiteboard". It was uploaded > before by José "L. Redrejo" Rodríguez <[EMAIL PROTECTED]> > but got rejected because the upstream source contains a win32-dll without > source. I stripped the dll now, added a README.debian-source and a > (probably bad) get-orig-source.sh to create the dfsg-tarball from the > upstream zip-file. Providing a watch file would be nice, as well as a machine-interpretable debian/copyright: see http://wiki.debian.org/Proposals/CopyrightFormat Just a minor note about your rules:get-orig-source you might find useful. No need to call chmod on get-orig-source.sh to make it executable and then worry to chmod it back to a non-executable in your clean target (which you actually forgot to;-). Just a call like "sh get-orig-source.sh" would do the job. Also, you might want to delete the zip file within debian/ and put the dfsg tarball outside debian/, e.g.: rm -f WiimoteLib.dll gtkwhiteboard-1.3.zip tar -czf ../gtkwhiteboard_1.3+dfsg.orig.tar.gz * --exclude=\.dll You might also want to teach upstream not to distribute ugly object files with their tarball, or at least to distribute them separately. I hope you will find a sponsor. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: rsplib
On Tuesday 17 June 2008, Thomas Dreibholz wrote: > Dear mentors, Hi, the package seems to be in a good shape, but here are some remarks: No need to use the trailing "unstable1" in the version string (2.5.0~beta7-0unstable1) since the package is also supposed to migrate to testing at some point ;-) ... or you have any good reasons to have it that way, I can't think of at the moment ? Too generic names for some binaries are used, like terminal, server, fork, which does not says much about their function and would most probalby cause a filename clash sooner or later (if others do the same), hence a useless package conflict should be declared, which would be at least suboptimal. One option could be to prepend your binaries with rsp-*. For instance, you can consult "apt-file search server | grep bin" to see how other packages avoid the generic names. licensecheck (from devscripts package) reports most of the files being licensed "v3 or later", but dispatcher.[c|h] is "v2 or later" and doesn't have a copyright. The former might not a problem since v3 could be assumed, while the latter is best to be corrected. These were probably overlooked. Since you are also the upstream is should be relatively easy to resolve these ;-) I would gladly sponsor such a well crafted piece of software, but I don't feel appropriate since I'm currently not familiar with Reliable Server Pooling business at all, so I hope you will find sponsor proper. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
On Wednesday 18 June 2008, Noah Slater wrote: --cut-- Hello, and sorry for the late reply, > > Seems like cdbs magic doesn't cope with that, but you can still save the > > day: clean:: unpatch > > common-install-prehook-impl:: patch > > This is a bug in CDBS, I have reported it as #486848: > > http://bugs.debian.org/486848 Sure. > I have added the following line as a temporary workaround: > > binary-arch binary-indep: build Fine. > > 2) Regenerating source files (the sed line) during the build process > > could be a weird source of troubles. Next, we end up having one single C > > file and two ways of modifying it > > This has been changed so that we generate lockrun.sed.c from lockrun.c > instead. > > I don't really see any problems with this method. A possible problem could arise when users of your source package decide to exemine the source code and call fakeroot debian/rules patch, but there is still modification left (no matter how innocent it is) to be done against the C code during the package build time. This is not very consistent behaviour unless s/he realizes to exemine your rules file more closely and issue the sed line themselves. Can you think of a solution where your command-option.patch and sed modification could be applied by the patch target ? It is possible, and consider it a wishlist. OTOH I would be fine if someone upload it the way it is. > > 3) No diff.gz found on mentors - probably a native package done by > > incident ? > > Yes, sorry about that, my mistake. Fixed now. OK. > > 4) You can add a watch file, also. > > The upstream does not use version numbers so a watch file would be > pointless. You are correct, I forgot about that. I believe it would be best to discuss with upstream to provide any decent versioning scheme, which would let you avoid constructing upstream version from the debian version, not that it is bad, it is just not optimal imho ;-) -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: windowlab (QA upload, fixes RC bug)
On Saturday 21 June 2008, Ansgar Burchardt wrote: > Hi, Hi, thanks for hunting RC bugs ;-) > I prepared a QA upload for the latest upstream version of windowlab, a > small and simple windowmanager. > > The upload would close the following bugs: > - 486978 (serious): FTBFS: windowlab.h:37:34: error: >X11/extensions/shape.h: No such file or directory > - 438264 (wishlist): not handling nostrip build option (policy 10.1) Your changes seems to bring improvements..., yet could you please also fix debian/rules so that both the binary-arch (buildd's call `/usr/bin/fakeroot debian/rules binary-arch') and binary-indep targets exist (see Policy 4.9) and so that `fakeroot debian/rules binary' works as well. > I also changed the packaging to use debhelper and quilt instead of cdbs, > and updated the package to conform to the latest version of Debian policy. Did you check with /usr/share/doc/debian-policy/upgrading-checklist.txt.gz since debian/changelog only reads "Bump Standards Version to 3.8.0", but doesn't list the exact changes done to align the package with 3.8.0, or there were no changes needed to comply with 3.8.0; if any please say so, probably by means of sub-bullets ;-) By the way, if you need a more expressive get-orig-source you can borrow some bits from the stealth package for instance. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: windowlab (QA upload, fixes RC bug)
On Saturday 21 June 2008, Ansgar Burchardt wrote:
> Hi!
Hi,
--cut--
> > Your changes seems to bring improvements..., yet could you please also
> > fix debian/rules so that both the binary-arch (buildd's call
> > `/usr/bin/fakeroot debian/rules binary-arch') and binary-indep targets
> > exist (see Policy 4.9) and so that `fakeroot debian/rules binary' works
> > as well.
>
> Done. Thanks for noticing.
Uploaded.
> > > I also changed the packaging to use debhelper and quilt instead of
> > > cdbs, and updated the package to conform to the latest version of
> > > Debian policy.
> >
> > Did you check with
> > /usr/share/doc/debian-policy/upgrading-checklist.txt.gz since
> > debian/changelog only reads "Bump Standards Version to 3.8.0", but
> > doesn't list the exact changes done to align the package with 3.8.0, or
> > there were no changes needed to comply with 3.8.0; if any please say so,
> > probably by means of sub-bullets ;-)
>
> There are several changes: the Homepage field in debian/control, the
> README.source, and the get-orig-source target. These changes are listed in
> the changelog. As two of them are already sub-bullets of other changes, I
> think it isn't a good idea to move them.
Fine.
> > By the way, if you need a more expressive get-orig-source you can borrow
> > some bits from the stealth package for instance.
>
> I added an md5sum check in the get-orig-source target for windowlab.
> The get-orig-source from stealth seems to require to be started in the
> package directory in order to inspect debian/changelog and doesn't leave
> the generated tarball in the current directory, which doesn't seem policy
> compliant, so I did not do this in windowlab.
Yes, it was created after svn-buildpackage default layout
(package/{trunk,tags,branches,tarballs}), but it is probably a good idea not
to occupy the get-orig-source target for that, but use another one instead.
Thanks for the good catch.
> I uploaded an updated package to mentors:
> http://mentors.debian.net/debian/pool/main/w/windowlab/windowlab_1.34-1.dsc
>
> Thanks for the review!
At least the updated package is better than the one currently found in the
archive ;-) As a further improvement you can use something like ucf for
instance to gracefully handle configuration files in /etc/X11/windowlab/.
--
pub 4096R/0E4BD0AB 2003-03-18
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gtkwhiteboard (now dfsg compatible)
On Sunday 22 June 2008, Thomas Knott wrote:
> Am Sonntag, 15. Juni 2008 19:32:50 schrieb George Danchev:
> > Hi,
>
> Hi! Thanks for your suggestions.
Hi,
> > > I am looking for a sponsor for my package "gtkwhiteboard". It was
> > > uploaded before by José "L. Redrejo" Rodríguez
> > > <[EMAIL PROTECTED]> but got rejected because the
> > > upstream source contains a win32-dll without source. I stripped the dll
> > > now, added a README.debian-source and a (probably bad)
> > > get-orig-source.sh to create the dfsg-tarball from the upstream
> > > zip-file.
> >
> > Providing a watch file would be nice, as well as a machine-interpretable
> > debian/copyright: see http://wiki.debian.org/Proposals/CopyrightFormat
>
> Added a watch file and changed the copyright file to the new format.
Sure, these look good to me.
> > Just a minor note about your rules:get-orig-source you might find useful.
> > No need to call chmod on get-orig-source.sh to make it executable and
> > then worry to chmod it back to a non-executable in your clean target
> > (which you actually forgot to;-). Just a call like "sh
> > get-orig-source.sh" would do the job. Also, you might want to delete the
> > zip file within debian/ and put the dfsg tarball outside debian/, e.g.:
> > rm -f WiimoteLib.dll gtkwhiteboard-1.3.zip
> > tar -czf ../gtkwhiteboard_1.3+dfsg.orig.tar.gz * --exclude=\.dll
>
> I tried to implement your suggestions. It seems to work but I am not good
> at scripting stuff.
there are some minor issues & typos ("baord" vs. "board"), but the following
should work better (btw, I also hate scripting and love ada;-).
#!/bin/bash
set -e
VER=1.3 # change that whenever a newer version occurs
NAME=gtkwhiteboard
UPSTREAM=$NAME-$VER
DEBIANED=$NAME\_$VER
LOCATION=http://fuelnatchos.webng.com/gtkwhiteboard
#Create temporary directory
mkdir ./$UPSTREAM && cd ./$UPSTREAM
#Get upstream source
wget $LOCATION/$UPSTREAM.zip
unzip ./$UPSTREAM.zip
#Remove downloaded zip, binary-only file and win32-icon
rm -f $UPSTREAM.zip WiimoteLib.dll gtkwhiteboard.ico
#Repack
cd ..
tar -czf $DEBIANED+dfsg.orig.tar.gz $UPSTREAM --exclude=\.dll
#Move orig.tar.gz outside /debian
mv $DEBIANED+dfsg.orig.tar.gz ../
#Clean up
rm -rf ./$UPSTREAM
--
pub 4096R/0E4BD0AB 2003-03-18
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] : gpg fingerprint in mail's signature ? - Was: Re: RFS: gtkwhiteboard (now dfsg compatible)
On Sunday 22 June 2008, The Fungi wrote: > On Sun, Jun 22, 2008 at 05:41:11PM +0200, Olivier Berger wrote: > > Is there any use in adding your fingerprint to the signature ? ... It > > seems misleading at least, if users think they can trust that... and > > without the public key, it's useless anyway. > > It's assumed that your public key can be commonly found on public > keyservers or by fingering your address. Putting your key > fingerprint in your .sig is *obviously* not equivalent to > cryptographically signing a particular message, but it does help > others identify that they've looked up the correct key for you if > they want to encrypt a response to you. It's only potentially > misleading if someone doesn't understand PKI in the first place, but > then what's the point of avoiding misleading someone about something > they don't know how to use in the first place? ;-) Well yes, people who are unable to make the difference between a cryptographically signed message and such that merely contains a key fingerprint at the end could not be a factor with regard to the originator identification and verification process, since they don't know what to verify anyway and since it is a well known fact that everybody can write a message with any free-form text appended at the end ;-) > I don't know if the > extra 40 characters make my .sig obscenely larger, but if they did I > might shorten it to a key ID instead. In order to shorten my appendix with one line I decided on key ID only instead, which is enough for public key diggers. -- pub key ID 0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] : gpg fingerprint in mail's signature ? - Was: Re: RFS: gtkwhiteboard (now dfsg compatible)
On Monday 23 June 2008, Cyril Brulebois wrote: > George Danchev <[EMAIL PROTECTED]> (22/06/2008): > > In order to shorten my appendix with one line I decided on key ID only > > instead, which is enough for public key diggers. > > Even shorter: Sign your mails. Bleh 3 words 3 failures ;-) is it really so hard to realize that these hints are for people who don't have my public key at hand and want to dig it up somehow. I also disagree that signed mails are shorter, and you would probably that I don't have my secret key at hand any time I post to mailing lists. Can we move on please ... -- pub key ID 0E4BD0AB 2003-03-18 -- 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 -- 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: > Георги Данчев 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 signature.asc Description: This is a digitally signed message part.
Re: RFS: poco (updated package)
On Thursday 26 June 2008, Krzysztof Burghardt wrote: > Hello George, > > 2008/6/25 George Danchev <[EMAIL PROTECTED]>: > > On Wednesday 25 June 2008, Krzysztof Burghardt wrote: > >> I am looking for a sponsor for the new version 1.3.2+dfsg1-2 > >> of my package "poco". > > [...] > > >> 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 ;-) > > I just realized that I forgot to add new patch to patches/00list, so > pacakge is still buggy. Version 1.3.2+dfsg1-3 has this missing line > add. > > http://mentors.debian.net/debian/pool/main/p/poco/poco_1.3.2+dfsg1-3.dsc Ops, I've also missed that. I had a day off, hence the delay, but I'm now checking/building the package once again... will upload soonish. -- pub key ID 0E4BD0AB 2003-03-18 signature.asc Description: This is a digitally signed message part.
Re: RFS: poco (updated package)
On Friday 27 June 2008, George Danchev wrote: > On Thursday 26 June 2008, Krzysztof Burghardt wrote: --cut-- > > I just realized that I forgot to add new patch to patches/00list, so > > pacakge is still buggy. Version 1.3.2+dfsg1-3 has this missing line > > add. > > > > http://mentors.debian.net/debian/pool/main/p/poco/poco_1.3.2+dfsg1-3.dsc > > Ops, I've also missed that. I had a day off, hence the delay, but I'm now > checking/building the package once again... will upload soonish. 1.3.2+dfsg1-3 uploaded. -- pub key ID 0E4BD0AB 2003-03-18 signature.asc Description: This is a digitally signed message part.
Re: RFS: winff
On Monday 30 June 2008, Paul Gevers wrote: > Dear mentors, > > I am looking for a sponsor for my package "winff". This is my first > contribution to Debian. > > * Package name: winff > Version : 0.42-1 > Upstream Author : Matthew Weatherford <[EMAIL PROTECTED]> > * URL : http://www.winff.org > * License : GLP-3 > Section : graphics > > It builds this binary package: > winff - video and audio batch converter using ffmpeg > > The package appears to be lintian clean. > > The upload would fix these bugs: 485481 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/w/winff > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget http://mentors.debian.net/debian/pool/main/w/winff/winff_0.42-1.dsc > > I would be glad if someone would check uploaded this package for me. Hi, Some minor comments: - No need to build-depend on fpc-source or you have a strong reason doing so ? - Need to depend on ffmpeg since AFAICS it is being called by winff runtime. - Vcs-Browser: is not for upstream repo, but for yours, i.e. the VCS repo of your packaging, if any. -- pub key ID 0E4BD0AB 2003-03-18 -- 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 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.
> I can delete it if it is too confusing, however.
Please don't, it is still useful, however I would be thankful if you or Yavor
also add the use cases from the latest discussions, even doing them verbatim.
> Thanks for the explanation anyway, this FLAGS management is a real
> headache…
Yes, it is, and I'm happier with much simpler beasts like icmake for instance.
--
pub 4096R/0E4BD0AB 2003-03-18
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package extraction process (dpkg-source, format 1.0 and 3.0 (quilt))
On Sunday 13 July 2008 13:10:24 Benjamin Mesing wrote: > Hello, Hello, > I am trying to understand the new dpkg-source format 3.0 (quilt). > There are two points in the documentation (man-page) I do not > understand: > * In the section "Building" of the description of 3.0 (quilt) it > is stated: > "The updated debian directory and the list of modified > binaries is then used to regenerate the debian tarball." > Why is it "regenerate" instead of "generate" here? I believe, it > is not uncommon, that no debian tarball exists before. I don't know why regenerate is used, sorry. > * In the same section there is a note: > "Note: dpkg-source expects the source tree to have all patches > applied when you generate the source package. This is not the > case when the source tree has been obtained by unpacking a > source package using the Format: 1.0 for instance." > But unpacking format 1.0 packages does lead to a tree with all > patches applied, doesn't it? Not always, since extracting a non-native package prepared as format 1.0 is done by first unpacking the .orig.tar.gz and then applying the patch in the .diff.gz. Now, you have two kinds of diff.gz - hooligan ones which directly modify upstream files when applied as one fat, monolitic and illogical changeset, and such that create logically separated diffs in debian/patches/ which are then applied build time. > Does this refer to using some > external patch system like dpatch? Not mandatory. Directly citing from #482741: "In this process, if the .diff.gz contains changes to upstream files, dpkg-source will have created a corresponding patch in debian/patches/debian-changes-2.1.0-3 and will have registered that patch in a quilt series (debian/patches/series, it is created if needed). All the patches listed in the "series" file are applied directly during the extraction (dpkg-source -x). quilt itself is used if available (and will thus lead to the creation of the .pc directory), otherwise dpkg-source applies the patches by itself." > I would file a bug report against dpkg-source if you believe my concerns > are justified. Sure, you may still file a bug if you feel the manpage needs improvement. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package extraction process (dpkg-source, format 1.0 and 3.0 (quilt))
On Sunday 13 July 2008 18:30:34 Benjamin Mesing wrote: > > > * In the same section there is a note: > > > "Note: dpkg-source expects the source tree to have all patches > > > applied when you generate the source package. This is not the > > > case when the source tree has been obtained by unpacking a > > > source package using the Format: 1.0 for instance." > > > But unpacking format 1.0 packages does lead to a tree with all > > > patches applied, doesn't it? > > > > Not always, since extracting a non-native package prepared as format 1.0 > > is done by first unpacking the .orig.tar.gz and then applying the patch > > in the .diff.gz. Now, you have two kinds of diff.gz - hooligan ones which > > directly modify upstream files when applied as one fat, monolitic and > > illogical changeset, and such that create logically separated diffs in > > debian/patches/ which are then applied build time. > > So you will not have all patches applied only, if you are using a patch > system like dpatch or quilt - which for format 1.0 had nothing to do > with dpkg-source. This is not mandatory and depends on how you would call dpkg-source (the newer one from dpkg >= 1.14.18), thus I think you are looking for dpkg-source(1). Extract options --skip-patches Do not apply patches at the end of the extraction. --without-quilt Don't use quilt to apply patches but dpkg-source's own code. It won't be possible to use quilt directly on the unpacked directory but it will be free of quilt's temporary files as well. > > > Does this refer to using some > > > external patch system like dpatch? > > > > Not mandatory. Directly citing from #482741: > > "In this process, if the .diff.gz contains changes to upstream files, > > dpkg-source will have created a corresponding patch in > > debian/patches/debian-changes-2.1.0-3 and will have registered that > > patch in a quilt series (debian/patches/series, it is created if needed). > > All the patches listed in the "series" file are applied directly during > > the extraction (dpkg-source -x). quilt itself is used if available (and > > will thus lead to the creation of the .pc directory), otherwise > > dpkg-source applies the patches by itself." > > This is true for the 3.0 format, but not for 1.0, or am I missing > something? Yes, you are correct. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why my program segmentation fault?
Quoting Star Liu <[EMAIL PROTECTED]>:
I wrote a program to copy the memory content of - to a
file, but it says "Segmentation fault", (i use AMD64 lenny, so the
address is long), how could i fix it? thanks!
you should only fclose() if Memory != NULL, so your function would be
better off like this:
void CopyMemoryToFile(char* FilePath, long StartAddress, long OffSet)
{
FILE* Memory;
Memory=fopen (FilePath, "w");
if(Memory!=NULL)
{
void* Start;
Start=StartAddress;
fwrite(Start, 1, OffSet, Memory);
fclose(Memory);
}
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dgtdrv
On Tuesday 15 July 2008 17:59:14 Yavor Doganov wrote: > В Mon, 14 Jul 2008 08:33:52 +1000, Ben Finney написа: > > POSIX is usually treated as an initialism, so should be spelled in > > all-capitals. > > Not necessarily: > > http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/13886/focus=4187 > http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/13916 Sure, but the original inventor of the term does not care and standard entities (ISO/IEC, IEEE and The Open Group) use it consistently uppers case in their docs, so it would be nice to follow their way. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dante - fix RC bugs, adopt, update
On Thursday 17 July 2008 17:47:51 Peter Pentchev wrote: > On Thu, Jul 17, 2008 at 05:19:37PM +0300, Peter Pentchev wrote: > > Hi, > > > > I am looking for a sponsor for the new version 1.1.19.dfsg-1 > > of the "dante" package - I'm adopting it, fixing three RC bugs > > (dante does not currently have a version in testing), updating it > > to the new upstream release, and updating the Debian packaging > > a lot. > > > > It builds these binary packages: > > dante-client - SOCKS wrapper for users behind a firewall > > dante-server - SOCKS (v4 and v5) proxy daemon (danted) > > libdsocksd0 - SOCKS library for internal use by the dante client > > libsocksd0 - SOCKS library for packages built using libsocksd-dev > > libsocksd0-dev - Development files for compiling programs with SOCKS > > support > > > > The package has been tested by lintian on testing and unstable. > > > > The upload would fix these bugs: 232574, 368322 (grave), 466082 (grave), > > and 486756 (ITA). > > > > The package can be found on mentors.debian.net: > > http://mentors.debian.net/debian/pool/main/d/dante/dante_1.1.19.dfsg-1.ds > >c > > > > I would be glad if someone uploaded this package for me, so that dante > > has a chance of making it into Lenny now that the RC bugs are fixed. > > I forgot this in the RFS, but here's the brief part of the changelog > (the 1.1.19.dfsg-1 changelog entry itself also has a file-by-file > breakdown of the changes): > >* New maintainer. Closes: #486756 >* Do not start danted if the config file contains nothing but > the default settings. Closes: #232574, #368322, #466082. >* Use quilt to manage the patches, converting all existing ones. >* Fix some lintian warnings >* Add a watch file and README.source >* Honor DEB_BUILD_OPTIONS >* Separate the dante client library into a package of its own >* Minimize the rules file by using debhelper 7 >* Add the Vcs-Svn and Vcs-Browser source control fields >* Add symbols files for the libraries >* Convert the copyright file the machine-parseable format >* Fix some C compiler warnings, mainly related to printf format strings >* Enable build hardening unless DEB_BUILD_OPTIONS contains "nohardening" >* New upstream version > - remove the sockd/serverconfig.c upstream patch > - doc/README.msproxy was removed >* Install all sample configuration files > >[file-by-file changes snipped] Peter, I just uploaded that package, since it brings notable improvements over the last one found in sid -- thanks for taking care of that! I have one question, though: did you feed upstream with the patches applied to the upstream code, AFAICS they will be interested in all of them, but `rename' ones ? -- pub 4096R/0E4BD0AB 2003-03-18 signature.asc Description: This is a digitally signed message part.
Re: packaging for wine
On Friday 18 July 2008 10:01:01 dmanye wrote: > hello, Hello, > let me explain my "environment". i'm in a university taking care of > computer science department's computer labs. teachers say: "i need for > my course app1, app2 and app3". most apps are windows ones and in most > of the lab sessions teachers use windows. By the way, it might not be relevant, but, I've been a witness of students pushing free software usage to the teacher and OTOH, there are teachers who introduce free software to their students while lecturing (such teachers are also upstream authors and debian package maintainers ;-) > i'm here "the linux guy" in a way similar to asterix. my objective is: > do the linux computer setup as "capable" as possible so that students > can do *all* their practices under linux. sometimes the job is easy > (when teachers ask for office i install openoffice, when they ask for > acroread i install evince|xpdf and so on), but sometimes it's not so > easy: for example, when they ask for pajek > (http://pajek.imfm.si/doku.php) for which i've found no free equivalence > and i've read that runs ok under wine (and the source code is not > published). > > so i spend some of my job time to make possible that a student can > choice between pajek under windows or pajek under wine. and i know that > most of the students will choose the first option. > > this is my position and since this is a flame theme, let me ignore any > other message related with this without constructive ideas. thanks to > paul wise for pointing me to pptview, i think it is the example package > i was looking for. My opinion how to attack the problem (not a flamebait of course): You should probably explain your teacher and fellow students that the usage of any sort of proprietary formats brings you headaches and should be avoided when possible. I'm not sure what pajek is supposed to do, but there are many free software presentation systems out there. I even recently sponsored one - s5, which is a pretty good example for effectiveness, with a few web standards you can have a pretty decent presentation. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: whatsup
On Saturday 19 July 2008 17:04:20 Marc Schoechlin wrote: > Dear mentors, > > I am looking for a sponsor for the new version 0.1.0-1 > of my package "whatsup". Hello, This is an interesting approach, but the package looks unfinished. There are some *.ex files in debian/ which are actually examples you need to adapt for your package or remove them if unneeded. You can also check that your package complies with Debian Python Policy [1], since at least python-suppost is not used as described there and the recent Standards-Version as described by the latest Debian Policy upgrading checklist [2]. [1] http://www.debian.org/doc/packaging-manuals/python-policy/ [2] /usr/share/doc/debian-policy/upgrading-checklist.txt.gz -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: scrot (updated package)
On Sunday 03 August 2008 02:43:24 Ben Finney wrote: > Aníbal Monsalve Salazar <[EMAIL PROTECTED]> writes: > > All other upstream files should be modified with patches. > > Or by some other method that results in the Debian source package > format, with a pristine upstream tarball and all maintainer changes in > the .diff.gz. > > > So, Please put those cahnges in a series of patches in > > debian/patches and build depend on quilt. > > Or use some other method (e.g. a VCS and the corresponding command > foovcs-buildpackage) to track differences from upstream and generate > the changes for the Debian package. This do not exclude the usage of debian/patches. Make sure to understand that. > The "quilt" format is favoured by many, but is certainly not mandatory > nor even "best practice". Using quilt to clearly separate patches does not exclude nor contradicts with the usage of a $VCS. Thus I don't see what are you trying to correct in Anabal's statements. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: scrot (updated package)
On Monday 04 August 2008 02:13:30 Ben Finney wrote: > George Danchev <[EMAIL PROTECTED]> writes: --cut-- > Advice given here needs to be carefully examined for dogma, and a > clear line needs to be maintained between "you should do this" and > "this is one way to do it". I'm guessing here -- Have you ever thought that this could be an advice given by a sponsor who prefers the things the way he asked and at the end he is responsible to fix any potential breakages subsequently found ? Ever thought he wants his life easier? So get back safely to the ground and forget about any dogmas, except the ones found in debian policy. > I'm correcting the false implication that "put the changes in a series > of patches in debian/patches and build depend on quilt" is somehow > mandatory, or even that it's recommended practice. That flies directly in the face of DevRef 6.2.1 Best Packaging Practices. Should I be in dount or I'm better not ;-) > In fact, anything that generates the Debian source format is fine, and > there are perfectly valid ways that don't involve the use of "a series > of patches in debian/patches and build depend on quilt". That's *one* > way, but I disagree that it should be recommended without alternatives > as Anibal's message did. Your alternative as currently being performed leads to deeply hidden and silent changes to the upstream code and is proven as a very bad practice by some recent security disasters. Note that 3.0 (git) will improve the readability and changeset identification (since it brings more information with the surce package itself, but still one should fight the history) but it is not allowed/ready yet. Note, that I'm not against VCS, I'm against their abusage and the distribution of unreadable and sometimes dangerous bits. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: desktop-data-model
On Tuesday 05 August 2008 02:42:59 Robert Collins wrote: > On Mon, 2008-08-04 at 21:29 +0200, Vincent Bernat wrote: > > OoO En ce début de soirée du mercredi 23 juillet 2008, vers 21:37, > > > > Julien Lavergne <[EMAIL PROTECTED]> disait : > > > I am looking for a sponsor for my package "desktop-data-model". > > > > Hi Julien! > > > > You are adding org.freedesktop.od.Engine.service. Put it in debian/ > > directory instead and use debian/rules or *.install files to put it in > > the right place. It is better that your diff.gz only contains changes to > > debian/ directory. > > Urgh, I find this assertion really quite annoying, and seeing it in two > consecutive . Jumping through hoops to keep the diff contained in debian > harms reviewability as much as having arbitrary changes scattered over > the source tree. Urgh, this is quite immature assertion, really. Could you please elaborate how to extract separate changes from your latter (all-in-all) diff.gz (since that is what Debian officially releases) and do you need any hints how to do it with the former diff.gz (I hope you don't)? > Really, we want things to be as clear as possible; and if that means > changes outside the debian directory, then *that is fine*. We're not > just writing meta-data to install software in a debian package (though > that is a fine goal to be aiming for), we're fixing such bugs as needed > to have the software work well on debian (or at least however many bus a > particular DD feels up to fixing :)). Good, but think about the ease of reviewing and human time spent in such a process. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian warning messages
On Wednesday 06 August 2008 01:56:59 Eduardo M KALINOWSKI wrote: > Joey Hess wrote: > > Eduardo M KALINOWSKI wrote: > >> If the policy suggestion that leads to that lintian warning is so > >> unreasonable, it might as well be taken off the policy. > > > > I'm not aware of any such thing in policy > > Then maybe the lintian warning could be removed. Hello Eduardo, While every executable must have a magic number (in that case the shebang), there is nothing wrong for non-executables to strt with a shebang or whatever helps their authors and users to sleep better. And as long as lintian has no chance to know in advance if human meant a particular file to be executable it warns for suspicious false or true positives, thus leaving the final decision to the human body. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: scrot (updated package)
On Saturday 09 August 2008 05:26:33 William Vera wrote: > Thanks everyone for their comments > Nevertheless still a little confused, apparently I do not see any > patch applied, apparently only need add to debian/rules manually > delete those files, am I right? Hello, Your diff.gz brings in a combined fashion several logically separated changes directly applied to the upstream source[1]. An external reader can only guess how many logically separated changes are in there meant by you and how they should be separated. For example you were trying to fix the build system files, spelling in options.c, and probably something else I'm not even sure about. Or, in other words: tell what you were trying to correct, to tell you if your corrections need to be corrected ;-) Therefore, it would be very nice of you if you drop a separete and documented [2] patches for each logical change in debian/patches/, unless an SCM-based dpkg source format is finished and ready to use and upload (like 3.0 (git) for instance). You are touching too many files: patch Makefile.am only, Makefile.in is to be regenerated. All the generated files during the build process should be removed in the debian/rules's clean target. [1] lsdiff -z -x '*/debian/*' ../scrot_0.8-8.diff.gz scrot-0.8/depcomp scrot-0.8/aclocal.m4 scrot-0.8/config.guess scrot-0.8/missing scrot-0.8/ltmain.sh scrot-0.8/Makefile.in scrot-0.8/Makefile.am scrot-0.8/install-sh scrot-0.8/config.sub scrot-0.8/mkinstalldirs scrot-0.8/configure scrot-0.8/src/options.c scrot-0.8/src/Makefile.in scrot-0.8/src/Makefile.am [2] document the idea and the logic behind the patch, rather than the programming language technique being used, since the reader most probably can easily recognize the programming language technique, but that does not hold true for reasoning behind that change. Some reasons are pretty clear and obvious (spelling), others are not (like the fixes of weird and subtle bugs) -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: keytouch (updated package)
On Wednesday 20 August 2008 23:46:52 Bernd Schubert wrote: > Dear mentors, > > I am looking for a sponsor for the new version 2.3.2-2.1 > of "keytouch". Please note, this is an NMU upload for a grave bug. > IMHO this bug is release critical, since it renders the package unusable. Hello Bernd, I'm not quite sure that simply removing a function call in 25_XCloseDisplay.dpatch is the right fix. Not that I'm an Xlib hacker, but AFAICT (reading the manpages) if you call XOpenDisplay, you need to call XCloseDisplay() at some later point, only once of course. Probably there are several reasons for XCloseDisplay() not to return, but at least one of them suggests that there is something wrong with the XRecord context, probably not correctly set ? My googling shows the following example when XCloseDisplay() does not return: http://lists.freedesktop.org/archives/xorg/2005-March/006629.html if you comment out the line of XRecordEnableContextAsync(display, context, callback, 0); then XCloseDisplay() returns just fine. So I guess that this issue should be investigated further, or I'm wrong ? -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: replaceit (#490695)
On Saturday 23 August 2008 21:20:15 Jonathan Wiltshire wrote: > Dear mentors, > > I am looking for a sponsor for my package "replaceit", closing ITP > #490695. Hello, I can't figure out why you want to NMU your own package, perhaps there might be some reason I can't think of right now or it is just an unintentional blunder. Also, you can use the most recent 3.8.0 standards version, and as I can see there are no changes needed to the package, but anyway you can check that with: /usr/share/doc/debian-policy/upgrading-checklist.txt.gz. > I would be grateful if someone uploaded this package for me and would > consider sponsoring me though the new maintainers process. Sponsoring would be best performed by your Application Manager, but sure in case s/he is MIA, I will try to review and upload that package for you. At least it doesn't seem to be beyond my grasp, and I can't promise I would upload large and complex stuff which I don't personally use and understand ;-). However, posting to -mentors mailing list is always a better idea, since you get more peer review. -- pub 4096R/0E4BD0AB 2003-03-18 signature.asc Description: This is a digitally signed message part.
Re: RFS: replaceit (#490695)
On Saturday 23 August 2008 23:08:08 Jonathan Wiltshire wrote: > On Sat, Aug 23, 2008 at 10:28:47PM +0300, George Danchev wrote: > > I can't figure out why you want to NMU your own package, perhaps there > > might be some reason I can't think of right now or it is just an > > unintentional blunder. > > Could you clarify NMU? Ops sorry, NMU = Non-maintainer upload. On my second thoughts it dawned on me that it might be your AM (Application Manager) who asked you to prepare an NMU, and he is now MIA (Missing In Action), but now I realize that you might had issued dch when your name had not been listed in Maintainer or Uploaders fields, therefor `Non-maintainer upload' had been added. Nevermind, you want 1.0.0-2 or 1.0.0-1 in your debian/changelog. On the other hand, there is nothing wrong to upload an NMU of your package for you, but we don't have any good reasons to do so ;-) > > Also, you can use the most recent 3.8.0 standards version, and as I > > can see there are no changes needed to the package, but anyway you can > > check that with: /usr/share/doc/debian-policy/upgrading-checklist.txt.gz. > > I will update to 3.8.0, I hadn't changed that from dh_make. I see, lintian is here to warn. > > Sponsoring would be best performed by your Application Manager, but sure > > in case s/he is MIA, I will try to review and upload that package for > > you. At least it doesn't seem to be beyond my grasp, and I can't promise > > I would upload large and complex stuff which I don't personally use and > > understand ;-). However, posting to -mentors mailing list is always a > > better idea, since you get more peer review. > > As this is my first package I don't yet have a sponsor, and I > understood from the New Maintainers pages that I should already be > involved before applying. You are correct. It is best to be involved before applying. So, correct the standards version and debian revision and I will sponsor. > If this is incorrect should I apply for > maintainers status and get into the system first before sending an RFS? Anyone can send an RFS and gets eventually sponsored, but it is always better if they intend to enter NM (New Maintainers) queue, pass it successfully and take responsibility of their packages at some future point. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: replaceit (#490695)
On Sunday 24 August 2008 00:59:00 Jonathan Wiltshire wrote: > On Sun, Aug 24, 2008 at 12:28:46AM +0300, George Danchev wrote: > > > > Also, you can use the most recent 3.8.0 standards version, and as I > > > > can see there are no changes needed to the package, but anyway you > > > > can check that with: > > > > /usr/share/doc/debian-policy/upgrading-checklist.txt.gz. > > > > > > I will update to 3.8.0, I hadn't changed that from dh_make. > > > > I see, lintian is here to warn. > > It didn't say anything, is it an optional preference? You are probably using an older version of lintian. Since your debian/changelog says you are targeting unstable you should build and lint your packages on unstable. If you don't have unstable at hand, there is an easy way to do that on your stable or testing system, and it is to use cowbuilder tool (from package cowdancer) to prepare (and later update) a clean chroot system of unstable (sid). See examples of cowbuilder(8), but basicaly you need: cowbuilder --create --distribution unstable cowbuilder --login then install the build dependencies of your package and you are ready to perform build/lint/fix/install/deinstall/fix cycles at will. Using a clean chrooted system also brings the benefit that unsatisfied build depends are easily caught, and you are sure that your binaries will not link with any obscure library files laying around you might happen to have locally installed (in /usr/local for example). This is just for future reference, you have nothing to fix now in your package with regard to a clean chroot environment. > > > > Sponsoring would be best performed by your Application Manager, but > > > > sure in case s/he is MIA, I will try to review and upload that > > > > package for you. At least it doesn't seem to be beyond my grasp, and > > > > I can't promise I would upload large and complex stuff which I don't > > > > personally use and understand ;-). However, posting to -mentors > > > > mailing list is always a better idea, since you get more peer review. > > > > > > As this is my first package I don't yet have a sponsor, and I > > > understood from the New Maintainers pages that I should already be > > > involved before applying. > > > > You are correct. It is best to be involved before applying. So, correct > > the standards version and debian revision and I will sponsor. > > Excellent, thank you. It is correct now (there were no changed to be made > to get to standards version 3.8) and is available at > http://mentors.debian.net/debian/pool/main/r/replaceit/replaceit_1.0.0-1.2. >dsc Probably I wasn't clear enough with my previous message, but I now see that I wrote "1.0.0-2 or 1.0.0-1 in your debian/changelog". So, in a package version like A.B.C-X.Y, in the second part (the debian revision) `.Y' is reserved for NMU's, so you want a non-NMU version like A.B.C-X or replaceit_1.0.0-2. Ok, more explanations follows: Why `dch' puts such NMU versions to your debian/changelog ? Because you have different email address in debian/control and debian/changelog (or environment). The fix is simple, put your most recent email from debian/changelog to debian/control, and dch will not consider you anymore as non-maintainer of that package and won't bring NMU (-X.Y) versions in your future changelog entries. You can also combine the last three entries in your debian/chanelog as 1.0.0-2, or just combined them all in a single 1.0.0-1 entry, at your convinience. Usually I don't prefer that since that kills history, and these packages are in the wild, but it is acceptable sometimes. Why lintian does not complain for incorrect NMU, then ? Because what you have prepared it is a perfectly valid NMU ;-) > > > If this is incorrect should I apply for > > > maintainers status and get into the system first before sending an RFS? > > > > Anyone can send an RFS and gets eventually sponsored, but it is always > > better if they intend to enter NM (New Maintainers) queue, pass it > > successfully and take responsibility of their packages at some future > > point. > > Perhaps I have just confused myself, but > http://www.debian.org/devel/join/nm-checklist says this: > > "For the NM process to be the most efficient, Applicants should have > already contributed significantly to Debian. This can be done through > packaging, documentation, Quality Assurance, ..." > > which implies to me that I should already have worked on a few packages > and had them sponsored before applying. That is correct. Another way to get involved and help Debian as a whole (it is not mandatory, but
Re: RFS: replaceit (#490695)
On Sunday 24 August 2008 16:23:55 Jonathan Wiltshire wrote: Hello, > > Probably I wasn't clear enough with my previous message, but I now see > > that I wrote "1.0.0-2 or 1.0.0-1 in your debian/changelog". So, in a > > package version like A.B.C-X.Y, in the second part (the debian revision) > > `.Y' is reserved for NMU's, so you want a non-NMU version like A.B.C-X or > > replaceit_1.0.0-2. > > It's now correct (I think) and available at >http://mentors.debian.net/debian/pool/main/r/replaceit/replaceit_1.0.0-2.dsc. Okay, uploaded, thanks for your patience. This will go through Debian NEW queue [1] which will take some time. I dared to change your last debian/changelog entry (I hope it is ok with you) from: * Incremented version correctly (no longer NMU) to: * Incremented version correctly (no longer non-maintainer version) since lintian was trying to be too smart, but was wrong to complain for: W: replaceit source: changelog-should-not-mention-nmu N: N: The first line of the changelog entry for this package appears to N: indicate it is a non-maintainer upload (by including either that N: string or the string "NMU" and not saying that it's an N: acknowledgement), but the changelog indicates the person making this N: release is one of the maintainers. N: N: If this was intended to be an NMU, do not add yourself as a maintainer N: or uploader. Otherwise, please rephrase your changelog entry to not N: cause confusion. N: not a big deal though, but it was your `NMU' string which made lintian to consider it as an incorrect NMU. That is not your fault of course since it was mentioned in a completely different context. I don't think that lintian needs some more logic to be injected, since a simple rephrase for that changelog entry is completely in order and easy to do. > I think I worked out what happened: I don't have the correct email in > DEBEMAIL so dch used my local address, and I didn't spot it. Exactly. [1] http://ftp-master.debian.org/new.html -- pub 4096R/0E4BD0AB 2003-03-18 signature.asc Description: This is a digitally signed message part.
Re: RFS: replaceit (#490695)
On Sunday 24 August 2008 21:09:06 Jonathan Wiltshire wrote: > On Sun, Aug 24, 2008 at 08:49:21PM +0300, George Danchev wrote: > > Okay, uploaded, thanks for your patience. This will go through Debian NEW > > queue [1] which will take some time. > > Cool, thanks :) Welcome. > I've never reached this stage, obviously - what happens to the package > now that it's in the new queue? It will be reviewed by the ftpmasters, and eventually accepted or rejected. This happens automatically for any uploads which introduce any new binary or source packages. > I notice also that it doesn't have my > ITP bug number listed under 'Closes', is that something I haven't done > correctly? Ops, good catch, and this is my fault. I actually didn't forget to pass the -v option to dpkg-buildpackage giving it the first package version found in the changelog (1.0.0-1) in order to include all the entries in the changes file, but in fact it appeared to just start from that version on, not including it. So, we should close that ITP manually after the package gets approved and enters unstable (sid) via BTS (Bug Tracking System) email interface. So, if you prefer to gain some BTS experience then please do close it for me, otherwise I'll do it for you ;-) -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: replaceit (#490695)
On Sunday 24 August 2008 21:49:34 Jonathan Wiltshire wrote: > On Sun, Aug 24, 2008 at 09:37:01PM +0300, George Danchev wrote: --cut-- > No, that's fine. I'll close it when it goes in (presumably I'll get a > mail when it does?) Yes, we will be mailed about that. > I have another package that's almost ready for feedback. Woud you > prefer to see it or should I advertise an RFS? Not sure what the > protocol is here. Well, basically it is always better to get as much public peer review as you can, so RFS to mentors is the preferred protocol. Also, there is no single person who is ready to sponsor everything; for example I won't sponsor stuff I don't intent to use, don't understand or hate with passion (php, java or web apps) but another sponsor will do. So, to summarize; the more eyes, the better ;-) -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gxemul -- machine emulator for multiple architectures
On Monday 25 August 2008 20:25:15 Jonathan Wiltshire wrote: > Dear mentors, > > I have adopted this package and I am now looking for a sponsor for version > 0.4.6.5-1. > > It has been orphaned under bug number 482067 and I believe this upload > will close it. > > There are various enhancements including an new upstream release. It > appears to be lintian clean. Thanks for adopting it. However, my copy of lintian said that gxemul-doc package should be moved to section `doc'. As a reference how to do that see the declaration of apache2-doc binary package in the debian/control file of apache2 source package. The second half of the job is described in Debian Developer's Reference paragraph 5.7 (you probably know about that, but anyway;-) The rest of the package looks fine to me. So, complete that, and I will sponsor. > I plan to adopt a number of packages with an eventual view to starting > the New Maintainers process, so all your feedback is appreciated even > if you don't wish to sponsor directly. Adopting packages is always nice to see, however, you shouldn't do that just because of your new maintainers process. I believe you know that, but anyway;-). Do in mind that you might happen to spend significant amounts of time while dealing with package's regular problems, which includes BTS (bug tracking system) interaction, discussing possible bugs with your users and dealing with alone or together with the upstream developers. This package is complicated enough and I saw that you have prepared two more packages whos RFS flew by -mentors, so make sure not to exceed your human limits ;-) Another good idea is working in teams (i.e find co-maintainers) which brings natural manpower backup and redundancy, as well as additional skills and expertise. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gxemul -- machine emulator for multiple architectures
On Monday 25 August 2008 22:48:50 Jonathan Wiltshire wrote: > On Mon, Aug 25, 2008 at 09:51:34PM +0300, George Danchev wrote: > > The rest of the package looks fine to me. So, complete that, and I will > > sponsor. > > It is corrected and up at > http://mentors.debian.net/debian/pool/main/g/gxemul > http://mentors.debian.net/debian/pool/main/g/gxemul/gxemul_0.4.6.5-2.dsc Thanks. Uploaded. Please let me know (i.e. CC: me) when you deal with the override file, because of the section change. > > anyway;-). Do in mind that you might happen to spend significant amounts > > of time while dealing with package's regular problems, which includes BTS > > (bug tracking system) interaction, discussing possible bugs with your > > users and dealing with alone or together with the upstream developers. > > This package is complicated enough and I saw that you have prepared two > > more packages whos RFS flew by -mentors, so make sure not to exceed your > > human limits ;-) Another good idea is working in teams (i.e find > > co-maintainers) which brings natural manpower backup and redundancy, as > > well as additional skills and expertise. > > Point taken. There are one or two others on the list that I have an > interest in, but that's about it. As you say, I don't want to overdo > it. Okay. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gxemul -- machine emulator for multiple architectures
On Monday 25 August 2008 23:04:45 Jonathan Wiltshire wrote: > On Mon, Aug 25, 2008 at 04:08:09PM -0300, Maximiliano Curia wrote: > > There is a change in the diff file that modifies the source code. Most > > probably an auto-generated file, anyway, try to avoid such a change. > > It's not something I've touched, I think it's an artifact of upstream's > build process. In that case it is innocent, but in general Maximiliano is right, we shouldn't clutter the diff.gz. I believe it can be removed in the clean rule, then regenerated by the build process when needed; I haven't checked that, though. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I want to contribute to Debian
On Wednesday 27 August 2008 21:14:06 Fabio Balzano wrote: > Hello, I am Fabio Balzano, > I write from Italy, I use debian sinc 1999 > and currentli I am system administrator of different > systems for my customers all debian based. > I also made VOIP systems asterisk based with > custom modifications and c modules. Hello Fabio, thanks for your offer to help improving Debian! > I want to help Debian and > > *I can: > > -write bash scripts > -write python applications > -perl basic level > -c basic level > -write html pages > -translate docs > -try to fix bugs > -VOIP expert (asterisk...) I believe Debian VoIP group would love to get some help maintaining asterisk. > I need some advice where I can start, and where > I can find a contact to receive first job. Well, the most hectic part now is fixing Release Critical bugs [1]. These are mostly things one need to test a bit, reproduce the problem, and find a way to produce a decent fix. You can try to deal with some of these, and send a patch to BTS (bug tracking system) in case of success. [1] http://bugs.debian.org/release-critical/ -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: netmon-applet (updated package)
On Thursday 28 August 2008 17:17:20 Stephan Peijnik wrote: > Dear mentors, > > I am looking for a sponsor for the new version 0.4-12 > of my package "netmon-applet". Hello, here are some comments, you might want to address: 1) debian/copyright lacks important information - linux-data.c is copyrighted by another person, but not mentioned in the copyright file. 2) update upstream URL in debian/copyright, or better convert to machine interpretable copyright format [1] 3) code duplication since linux-data.c has been borrowed from xnetload, which is already in Debian -- anti security, but the impact is in fact very low in that case. Btw, why this package should stay in Debian, when we have xnetload, sharing more or less the same functionality ? 4) changes to the upstream code, which are now applied in a combined fashion by diff.gz are best to be broken up in logical diffs and comunicated upstream. No gain in removing unused variables from gnome-ui.c:netmon_draw(), there are quite some more left, so leave them to upstream to clean as they find fit, some like to leave unused vars as a reminder ;-) [1] http://wiki.debian.org/Proposals/CopyrightFormat -- pub 4096R/0E4BD0AB 2003-03-18 signature.asc Description: This is a digitally signed message part.
Re: RFS: xinha
On Saturday 30 August 2008 04:30:21 Raphael Geissert wrote: Hello, > > * Package name: xinha > > Version : 0.95~rc2-1 > > Version 0.95 has now been released, could you please update the package? > > DD's: can anyone take a look at the package when updated? there are several > packages shipping their own copy of xinha or htmlarea and would be nice to > have just one copy in the whole archive. Do you happen to know which are these packages and if bugs (normal) was filed against them. Sometimes, it is not possible to avoid code dups, since there might be significant incompatible deviations from the original, but sometimes it worth the effort. These should also be identified at: http://wiki.debian.org/EmbeddedCodeCopies -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bindfs (bugfix upload, pre-approved by release team)
On Sunday 31 August 2008 08:30:03 Eugene V. Lyubimkin wrote: > Hi -mentors! > > I am looking for a uploader for the new version 1.8-1 > of my package "bindfs". > > My usual sponsor for this package, Kapil Hari Paranjape, seems to be busy > now. I want for pre-approved by release team upload of new version 1.8-1 of > package to reach testing ASAP, so I am seeking for uploader. > > It builds these binary packages: > bindfs - mirrors or overlays a local directory with altered permissions Okay, I found the release team reaction along with the diff. Could you please remove quilt from build-depends since it is unneeded, and I will sponsor. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: exiftags (updated package)
On Sunday 31 August 2008 08:24:13 Eugene V. Lyubimkin wrote: > Dear mentors, > > I am looking for a sponsor for the new version 1.01-3 > of my package "exiftags". My previous sponsor, Anibal Monsalve Salazar, > seems to be busy for more than week, so I am seeking for uploader or new > usual sponsor for this package. Ok, thanks for fixing an RC. Builds fine per autobuilders (dpkg-buildpackage -B), but fails to build with fakeroot debian/rules binary (as per policy), probalby because of missing binary-arch and binary-indep targets ? Try to fix it, or I'll have a look more closer look tonight... of course sponsors with more time are welcome to beat me on that line ;-) -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: exiftags (updated package)
On Sunday 31 August 2008 10:00:44 Eugene V. Lyubimkin wrote: > George Danchev wrote: > > On Sunday 31 August 2008 08:24:13 Eugene V. Lyubimkin wrote: > >> Dear mentors, > >> > >> I am looking for a sponsor for the new version 1.01-3 > >> of my package "exiftags". My previous sponsor, Anibal Monsalve Salazar, > >> seems to be busy for more than week, so I am seeking for uploader or new > >> usual sponsor for this package. > > > > Ok, thanks for fixing an RC. Builds fine per autobuilders > > (dpkg-buildpackage -B), but fails to build with fakeroot debian/rules > > binary (as per policy), probalby because of missing binary-arch and > > binary-indep targets ? Try to fix it, or I'll have a look more closer > > look tonight... of course sponsors with more time are welcome to beat me > > on that line ;-) > > Builds fine in my pbuilder. binary-arch and binary-indep are defined by > debhelper v7. Eugene, this is not enough, your `binary-arch' should build a binary package to a given architecture, but it fails because it does not depend on `build' target (where policy 4.9. says it should), thus `patch' target was also not being called as well. To fix that you should add: binary-arch: build install -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bindfs (bugfix upload, pre-approved by release team)
On Sunday 31 August 2008 09:49:05 Eugene V. Lyubimkin wrote: > George Danchev wrote: > > On Sunday 31 August 2008 08:30:03 Eugene V. Lyubimkin wrote: > >> Hi -mentors! > >> > >> I am looking for a uploader for the new version 1.8-1 > >> of my package "bindfs". > >> > >> My usual sponsor for this package, Kapil Hari Paranjape, seems to be > >> busy now. I want for pre-approved by release team upload of new version > >> 1.8-1 of package to reach testing ASAP, so I am seeking for uploader. > >> > >> It builds these binary packages: > >> bindfs - mirrors or overlays a local directory with altered > >> permissions > > > > Okay, I found the release team reaction along with the diff. Could you > > please remove quilt from build-depends since it is unneeded, and I will > > sponsor. > > This change is safe for me, but for release team? This change will also > lead to change debian/rules not to use 'patch' and 'unpatch' targets. Yes, it is safe; quilt has no business here as a build-dependency wasting autobuilders and other builders time to install and deinstall. Worst, that might leave a worrisome impression to the reader of any patches not being applied by accident. For the protocol, please, complete that and show them the diff, and CC: to me. Thanks. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: exiftags (updated package)
On Sunday 31 August 2008 20:25:57 Eugene V. Lyubimkin wrote: > George Danchev wrote: > > On Sunday 31 August 2008 10:00:44 Eugene V. Lyubimkin wrote: > >> George Danchev wrote: > >>> Ok, thanks for fixing an RC. Builds fine per autobuilders > >>> (dpkg-buildpackage -B), but fails to build with fakeroot debian/rules > >>> binary (as per policy), probalby because of missing binary-arch and > >>> binary-indep targets ? Try to fix it, or I'll have a look more closer > >>> look tonight... of course sponsors with more time are welcome to beat > >>> me on that line ;-) > >> > >> Builds fine in my pbuilder. binary-arch and binary-indep are defined by > >> debhelper v7. > > > > Eugene, > > this is not enough, your `binary-arch' should build a binary package to > > a given architecture, but it fails because it does not depend on `build' > > target (where policy 4.9. says it should), thus `patch' target was also > > not being called as well. To fix that you should add: binary-arch: build > > install > > George, I might missed something. Both 'dpkg-buildpackage -b' and > 'dpkg-buildpackage -B' work, in both cases patches are applied and binary > packages are built correctly. Where do you got the error? ... you are relying on dpkg-buildpackage to call `build' for you. `build' resp. `patch' were not called as in: $ fakeroot debian/rules binary dh binary-indep dh binary-arch dh_testdir -a dh_auto_configure -a dh_auto_build -a make[1]: Entering directory `/home/danchev/download/debian/exiftags-1.01' cc -o exiftags.o -c exiftags.c [CUT the object files creation] make[1]: Leaving directory `/home/danchev/download/debian/exiftags-1.01' dh_auto_test -a dh_testroot -a dh_prep -a dh_installdirs -a dh_auto_install -a make[1]: Entering directory `/home/danchev/download/debian/exiftags-1.01' cp exiftags exifcom exiftime /home/danchev/download/debian/exiftags-1.01/debian/exiftags/usr/local/bin cp: target `/home/danchev/download/debian/exiftags-1.01/debian/exiftags/usr/local/bin' is not a directory make[1]: *** [install] Error 1 make[1]: Leaving directory `/home/danchev/download/debian/exiftags-1.01' dh_auto_install: command returned error code 512 make: *** [binary-arch] Error 1 -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[uploaded] Re: RFS: exiftags (updated package)
On Sunday 31 August 2008 21:07:55 Eugene V. Lyubimkin wrote: --cut-- > [cut build log] > Ok, thanks, I finally understood you. Fixed, re-uploaded to mentors.d.o. > http://mentors.debian.net/debian/pool/main/e/exiftags/exiftags_1.01-3.dsc. Thanks, uploaded will get to you in several hours. -- pub 4096R/0E4BD0AB 2003-03-18 signature.asc Description: This is a digitally signed message part.
Re: RFS: bindfs (bugfix upload, pre-approved by release team)
On Sunday 31 August 2008 20:50:57 Eugene V. Lyubimkin wrote: --cut-- > Ok. Done, re-uploaded. > http://mentors.debian.net/debian/pool/main/b/bindfs/bindfs_1.8-1.dsc Uploaded. Thanks and sorry for the delay. Please, consider reading that announcement [1] when you request release team to unblock. Basically you don't need to include the full diff, they will regenerate it from the uploaded package, but include the last changelog entry instead. [1] http://lists.debian.org/debian-devel-announce/2008/09/msg0.html -- pub 4096R/0E4BD0AB 2003-03-18 signature.asc Description: This is a digitally signed message part.
Re: Trying to understand patch management - in combination with version control
On Wednesday 03 September 2008 05:04:12 Ben Finney wrote: --cut-- > I'm experimenting with Bazaar's "loom" feature, which allows a single > branch to contain multiple "threads" of development. A loom allows any > of the threads to be advanced, turned into separate patches as needed, > while still having a coherent end result representing the aggregate of > all of them > http://bazaar-vcs.org/Documentation/LoomAsSmarterQuilt>. > > Others might discuss the "rebase" feature of Git, but that method > loses too much intermediate state and prevents sharing the branch with > others. I prefer the "loom" approach in Bazaar. Yeah, rebase being very cool is sometimes abnormally used, so I'm not sure you have choosen the right git counterpart to the bzr's loom feature. It should be compared with topgit instead, which self-maintained source package is a real demonstration (see README.source, README.gz is also very helpful ;-) of how topgit can be used for maintaining your patch queue. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: blam - a simple GNOME feed reader (updated version)
On Thursday 04 September 2008 15:30:32 Carlos Martín Nieto wrote: > Hello mentors, > > I am looking for someone to upload an updated version of blam. This was > already reviewed by Vincent Bernat but it has been over a month since > that (I've been away from my computer and keys), so I'm asking again in > general in case he has lost interest. The issues raised have been fixed. > > The package is lintian-clean and is at > http://cmartin.tk/blam/blam_1.8.6-1.dsc Hello Carlos, what benefits does that package brings over liferea feed reader, which is already in Debian ? -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tmux
On Friday 12 September 2008 13:03:20 Karl Ferdinand Ebert wrote:
> Dear mentors,
>
> I am looking for a sponsor for my package "tmux".
Hello,
Package looks good to me, provided the following:
* control: your Depends line is empty, but your package depends on libncurses5
(at least) run-time. You want Depends: ${shlibs:Depends} in order to give a
chance to dh_shlibdeps (resp. dpkg-shlibdeps) to populate that entry
correctly for you.
* control: improving the long description would also help, since now I'm not
convinced that tmux is better than screen, or it is just YA (yet
another) 'terminal multiplexer'. Put some salt in there, like what is
different or better with tmux and why it is needed, no gambling of course,
since the code is there ;-), which also looks very clean to me.
* copyright: machine interpretable copyright format would also be nice (ask
wiki.debian.org about it)
* adding a watch file would be nice.
--
pub 4096R/0E4BD0AB 2003-03-18
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tmux
On Monday 22 September 2008 22:04:44 Karl Ferdinand Ebert wrote: > Hello, Hello, > there seems to be no interest in my package, but I will continue providing > updates to this list. Below is my proposal of debian/copyright. The package seems to be in a very good shape, but I don't currently have the time to get used to another terminal multiplexor, so I hope you will find a sponsor who intends to use it, thus more willing to upload. > > Format-Specification: > http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=226 > Upstream-Name: tmux > Upstream-Maintainer: Karl Ferdinand Ebert <[EMAIL PROTECTED]> > Upstream-Source: http://sf.net/projects/tmux > Upstream Author: Nicholas Marriott <[EMAIL PROTECTED]> Just a minor note: Upstream-Maintainer is the person who adopted the package upstream because the initial upstream author is no more active or just stopped working on the project. AFAICS, you have not adopted tmux upstream, nor it has been abandoned upstream, therefore Upstream-Maintainer field should be removed. The fact that you are the current debian maintainer of that package has already been declared in debian/control. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: literally '?' in debconf template
On Sunday 28 September 2008 22:08:28 markus schnalke wrote: > Hello mentors, Hi, > lintian reports this warning: > using-question-in-extended-description-in-templates > (see [1]) > > But there is no question where lintian sees one. Instead it's a > literally question mark. The text is: > "You can use wildcard expressions like '*' or '?'." > > How can I solve the situation? > Is there a way to escape the questions mark? > Do I have to override the warning? Well, lintian did his job right to warn you about a possible problem, but it can't sense the context (at least as of yet;-), thus you can safely override his decision. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to install package using apt-get in folder other than /usr
On Monday 29 September 2008 15:55:55 Charles Plessy wrote: Hello, > Le Mon, Sep 29, 2008 at 02:46:00PM +0100, Neil Williams a écrit : > > On Mon, 2008-09-29 at 06:36 -0700, Kruti wrote: > > > i mean when you do apt-get install , all the files of the > > > package are installed in /usr.for eg: packge binary in /usr/bin. > > > but if i want the package n all its files to be installed in a > > > directory other than /usr for eg in XYZ directory thn what should i > > > do...thnks > > > > The package determines the directories, it is not up to you to change it > > unless it is your package (and changes must be compliant with Policy) - > > Hi Neil, > > I guess that Kruti meant that if a foobar package has the following > files: > > /usr/bin/foobar > /usr/share/man/man1/foobar.1 > /etc/foobarrc > (...) > > he would like to install it the files in > > prefix/bin/foobar > prefix/share/man/man1/foobar.1 > prefix/etc/foobarrc (or even $Prefix/.config/foobarrc) > (...) > > and that if foobar depends on bazbaz, then with an appropriate apt-get > command, bazbaz can be installed in the same prefix. > > > While I would also love to have this feature in Debian, it is indeed > offtopic on this list and should better be a wishlist bug of apt-get, > aptitude, or any other frontend to dpkg. If I understand you correctly reading the examples given above, I believe you are looking for --instdir=dir option of dpkg. The above-mentioned frontends could pass it to dpkg if necessary. This could be only useful for any weirds experiments, and in all other cases I prefer chroot'ing to a given directory and install/reinstall at will; cowbuilder is your friend. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: building package with different libs
On Wednesday 29 October 2008 18:09:07 Peter Pentchev wrote:
> On Wed, Oct 29, 2008 at 04:30:25PM +0100, Adeodato Sim?? wrote:
> > * Thorsten Alteholz [Fri, 17 Oct 2008 20:06:09 +0200]:
> > > Hi,
> >
> > Hello,
> >
> > > I need some advice on building packages with different libs.
> > > Assuming that I have software S which needs to be linked against
> > > library L. For whatever reason there are several implementations (L1,
> > > L2, L3) of this library available. Each of them has its advantages and
> > > it would be fine
> > > to build three packages SL1, SL2 and SL3.
> > > Unfortunately L1, L2 and L3 conflict each other. So what would be the
> > > best way to build all three packages from one source package? Is this
> > > possible at all?
> > >
> > > To make this a bit more realistic: It is about package meep-mpi.
> > > Currently it uses libhdf5-serial and there is a requet to build it with
> > > libhdf5-mpich and libhdf5-openmpi. So my Build-Depends: in the source
> > > section needs to contain either libhdf5-serial-dev, libhdf5-mpich-dev
> > > or libhdf5-openmpi-dev. Is it still possible to build package
> > > meep-mpi-hdf5serial, meep-mpi-hdf5mpich and meep-mpi-hdf5openmpi at the
> > > same time?
> >
> > If the different implementations conflict among them, I don't think you
> > can build all three SL{1,2,3} binary packages from the same source
> > package.
>
> Well, actually, you can - just look at the various apache2 packages.
> However, the build mechanism has to be a bit complicated...
Actually if you have a single source package (as mentioned by Thorsten):
* you can not: since your build-depends and build-conflicts are unsatisfiable
and buildd's would give up in the very first stage, before even seeing any
dark magic in debian/rules
* you must not: because of Policy #7.7
Having multiple source packages declaring satisfiable build-depends,
build-conflict, etc. would be a course of action (although ugly because of
dups), but I would certainly check or ask if these L1, L2, L3 libraries
really need to conflict each other in the first place.
--
pub 4096R/0E4BD0AB 2003-03-18
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: poco & poco-doc (updated packages)
On Thursday 30 October 2008 11:33:53 Krzysztof Burghardt wrote: > Dear mentors, Hi, > I am looking for a sponsor for the new version 1.3.3p1-1 > of my package "poco". ... > Also I am looking for a sponsor for the new version 1.3.3-1 > of my package "poco-doc". Both uploaded. Thanks for your work! -- pub 4096R/0E4BD0AB 2003-03-18 signature.asc Description: This is a digitally signed message part.
Re: RFS: cdarch
On Sunday 02 November 2008 13:27:45 Jann Horn wrote: > Dear mentors, > > I am looking for a sponsor for my package "cdarch". Hello, How is that better than mounting image loopback and then engage the whole old unix tool armament in searching files ? -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: cppcheck (3rd attempt)
On Thursday 06 November 2008 17:31:29 Reijo Tomperi wrote: --cut-- > What about the cppcheck package, you didn't give any comments about it, > does that mean it is now perfect? ;) Package looks fine to me, although I can't figure out why xsltproc warns like that [0] when -nonet option were passed to it. [0] xsltproc -''-nonet -''-param man.charmap.use.subset "0" /usr/share/sgml/docbook/stylesheet/xsl/nwalsh/manpages/docbook.xsl debian/cppcheck.1.xml I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd debian/cppcheck.1.xml:62: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"; ]> Let me look at that closer during the weekend and I'll sponsor untill Sunday night. > What should I do now? Just wait for a sponsor volunteer and upload it or > is there something I can or I should do? Let me gabble out a bit: I think cppcheck could be used to test some code generated by tools like bison++ and bisonc++, along with the human-generated code of course. Furthermore, I believe that some of the advices and recommendations given by Scott Meyers [1] could be implemented in cppcheck. Interestingly enough, Meyes first intended to create such a checking tool, but gave up since some of the `rules' were too hard to formalize, there were too many important exceptions to these rules which must be taken into account and it is somehow dangerous to be enforced blindly by a program. So, I'd love to see him proven wrong, at least partially ;-) [1] in "Effective and More Effective C++" -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[uploaded] Re: RFS: cppcheck (4rd attempt)
On Sunday 09 November 2008 21:49:52 Reijo Tomperi wrote: --cut-- > http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.25-4.dsc Package uploaded. Thanks. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: cppcheck (3rd attempt)
On Saturday 08 November 2008 20:47:58 George Danchev wrote: > On Thursday 06 November 2008 17:31:29 Reijo Tomperi wrote: > --cut-- > > > What about the cppcheck package, you didn't give any comments about it, > > does that mean it is now perfect? ;) > > Package looks fine to me, although I can't figure out why xsltproc warns > like that [0] when -nonet option were passed to it. > > [0] xsltproc -''-nonet -''-param > man.charmap.use.subset "0" > /usr/share/sgml/docbook/stylesheet/xsl/nwalsh/manpages/docbook.xsl > debian/cppcheck.1.xml > I/O error : Attempt to load network entity > http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd > debian/cppcheck.1.xml:62: warning: failed to load external > entity "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"; > ]> > > Let me look at that closer during the weekend and I'll sponsor untill > Sunday night. OK, cppcheck should also build-depend on docbook-xml since xsltproc looks for /usr/share/xml/docbook/schema/dtd/4.5/docbookx.dtd (or the above I/O error occurs). You should always check your source package buildability in a clean chroot environment, network connectivity should not be assumed. I use cowbuilder for example. Could you please add docbook-xml build-dependency, or should I do it, but then you should grab so changed source package from debian archive ? -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [uploaded] Re: RFS: cppcheck (4rd attempt)
On Sunday 09 November 2008 22:41:13 Reijo Tomperi wrote: --cut-- > Few questions as I'm still new with all of this: > - In mentors.debian.net I have set the "seeking for sponsor" option to > "yes". Are you now my sponsor for the future updates also? Should I set > the value to "I have found a sponsor"? Or is this sponsoring one time > thing? > > - If you keep sponsoring me in the future releases also, how should I > inform you about updates? In my opinion it is always better to ask for sponsor via public mailing list like @deiban-mentors is, keeping need a sponsor `YES' in mentors webpage, simply because more that one sponsor could review and upload your package. I intend to sponsor cppcheck and I'm subscribed to that mailing list. Expect upstream wishlist bugs soon ;-) I'm still not sure if cppcheck could employ a formal grammar and parser generators (like bisonc++) to implement various checks, but that is a separate mail I intend to throw at you as upstream at some point. > - Should I do something to the bug report: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503730 This in fact is my fault, since I forgot to pass -v option to dpkg-buildpackage in order to include your previous changelog entries. could you please close it manually, otherwise I will close it when pakcage hits unstable. > - Will the package now go to Debian testing? I don't see it yet on my > mirror, but obviously it probably takes time to sync, but will it appear > there after mirrors are updated? Package is now hanging in Debian's NEW queue (since is new package which needs to be approved by ftpmasters /*these are humans*/) http://ftp-master.debian.org/new.html then the package will be passed to autobuilders /*these are daemons*/ to be built on Debian's architectures. http://buildd.debian.org/build.php then comes installation to unstable (sid). > - What will happen to the package now that it is in the testing > (assuming it is there)? Obviously it needs to mature there for some > time, but how does one tell when a package is mature enough and ready to > move on? Residing ten days in unstable without criticals bugs filed would lead to migration to testing, when testing is not frozen as it is now. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: poco (updated package)
On Saturday 15 November 2008 13:16:07 Krzysztof Burghardt wrote: > Dear mentors, > > I am looking for a sponsor for the new version 1.3.3p1-2 > of my package "poco". Package uploaded. Thanks for taking care of these bugs. -- pub 4096R/0E4BD0AB 2003-03-18 signature.asc Description: This is a digitally signed message part.
Re: RFS: new upstream of gxemul 0.4.4.6-1
On Sunday 16 November 2008 19:50:10 Jonathan Wiltshire wrote: Hello, > I am looking for a sponsor for the new version 0.4.6.6-1 > of my package "gxemul". This is a minor new upstream version, the > packaging has basically not changed. Well I believe it has changed enough compared to the version in sid ;-) * slight regression: dpatch was introduced in that revision, but the 01_manhyphens_patch.dpatch is not applied during build. Basically you don't need to call dpatch but include /usr/share/dpatch/dpatch.make instead and call patch and unpatch targets it provides for you. If in doubt you can check with poco source package for example and use it as a reference. * slight improvement: while we are at it, you ca upgrade to debhelper v5 or better yet use v7 and its wonderful command sequencer called dh(1) in order to shorten your debian/rules. I don't insist on v7 though, so use it at your convenience. Fix these and I will sponsor. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please ignore the tslib upload
On Thursday 20 November 2008 11:16:14 Olivier Berger wrote: > Le mercredi 19 novembre 2008 à 21:51 +, Neil Williams a écrit : > > I've no idea what is going on but a version of tslib has been uploaded > > to mentors.debian.net. > > > > I'm the maintainer for tslib and I see no reason for any such upload to > > Debian. Please do not sponsor this upload, do not hijack tslib. > > > > If there are good reasons for an upload, I will do it - but only to > > experimental. > > > > I won't be sponsoring the upload from mentors.debian.net. > > > > Can the upload be removed from mentors.debian.net ? > > Uh... mentors.debian.net is not Debian... so what's wrong with an upload > by someone else than the official maintainer to mentors.debian.net ? > > Of course this may be misleading people, but if it's not flagged as NMU > or something, I can't see any real harm. Well, people should not be mislead by flags or strings appied, but should verify the source package signature instead. Even if you do not trust that signature at all, you can still dissect and inspect the content of that source package (for example: compare it to the version in sid which was presumably signed by a trusted peer) and decide if it brings more good that harm, which should be brought to the attention of the original package maintainer(s). -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: new upstream of gxemul 0.4.4.6-1
On Monday 24 November 2008 00:19:14 Jonathan Wiltshire wrote: > On Mon, Nov 17, 2008 at 08:42:43PM +0200, George Danchev wrote: > > * slight regression: dpatch was introduced in that revision, but the > > 01_manhyphens_patch.dpatch is not applied during build. Basically you > > don't need to call dpatch but include > > /usr/share/dpatch/dpatch.make instead and call patch and unpatch targets > > it provides for you. If in doubt you can check with poco source package > > for example and use it as a reference. > > > > * slight improvement: while we are at it, you ca upgrade to debhelper v5 > > or better yet use v7 and its wonderful command sequencer called dh(1) in > > order to shorten your debian/rules. I don't insist on v7 though, so use > > it at your convenience. > > I /believe/, after a lot of headaches, that this is done now :) > I have taken all the cruft out of debian/rules and replaced it with a > configure target and calls to the patch and unpatch targets, and it > builds now including the patch. Ah, causing headaches was not my intention, indeed ;-) so I'd generally like to know about the troubles you have faced. Now, the package looks well done to me. > If you could take a look and consider sponsoring, the updated dsc is at: > http://mentors.debian.net/debian/pool/main/g/gxemul/gxemul_0.4.6.6-2.dsc Uploaded. I also didn't forget to include both of your entries in the changes file. Thanks for your work! Btw, the author is slowly but steadily progressing at the C++ rewrite, which I consider a very good idea. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gxemul segfault bugfix
On Monday 24 November 2008 17:27:16 Jonathan Wiltshire wrote: Hello, > I am seeking a sponsor for a bugfix in gxemul, George Danchev kindly > sposored last time. This is a patch taken from upstream's CVS pending > it being included in a release, and fixes a segmentation fault if > gxemul is started with invalid parameters. Brilliant! Monitoring upstream's VCS with and taking care of fixing defects also present in current packages is a good idea and generally scores higher in uploader's checklists. > Change: added patch 05_segfault_params.dpatch and included it in > 00list. > Closes: LP #301041 Helping Ubuntu folks is also very nice, and to be honest I was not aware of that LP magic. > Available from: > http://mentors.debian.net/debian/pool/main/g/gxemul/gxemul_0.4.6.6-3.dsc 0.4.6.6-3 package uploaded. Thanks! > I will package seperately for testing-proposed-updates since lenny and > sid are out of sync. I'll be offline next 48-72 hours (unexpected mountaineering ;) and I would be thankful if anyone takes care of uploading package to t-p-u, otherwise I will upload it once get back. Meantime, could you please ask Debian Release Team (debian-release at lists.debian.org) for approval showing them the debdiff for the package found in lenny ? As I see it, if in doubt pointers given by Pabs should help, otherwise please ask for help ;-) > My upload last night is still building, so I don't > know if that causes any problems with uploading this fix. 0.4.6.6-2 is already dinstalled, but that shouldn't matter anyway since buildds and wanna-build will pick the newer one I believe, unless anyone proves me wrong. -- pub 4096R/0E4BD0AB 2003-03-18 signature.asc Description: This is a digitally signed message part.
Re: Bug reports in Ubuntu
On Tuesday 25 November 2008 19:21:46 Paul Wise wrote: > On Tue, Nov 25, 2008 at 7:18 AM, Jonathan Wiltshire > > <[EMAIL PROTECTED]> wrote: > > Do you think it is severe enough to be put forward for lenny? > > I'm not sure. The patch looks straight-forward enough, so perhaps the > release team would approve it. Agreed. I saw Jonathan's message to -release, so we are waiting for release team to advise. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[uploaded] Re: RFS: cppcheck, new upstream version
On Sunday 30 November 2008 22:03:16 Reijo Tomperi wrote: --cut-- > http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.26-1.dsc Uploaded. FYI: Package is still hanging in Debian's new queue. -- pub 4096R/0E4BD0AB 2003-03-18 signature.asc Description: This is a digitally signed message part.
Re: RFS: hexec
On Monday 01 December 2008 16:04:33 Alexander Block wrote: Hi, Hm, interesting approach. Package looks good to me, except that it builds one binary package, not three, which is fine. Adding a watch file would be good idea too, regardless you are both upstream and debian maintainer of that package, because in that case your users (Debian External Health Status - DEHS included) would be able to catch your debian packaging lagging your upstream releases, if any ;-) > It builds these binary packages: > hexec - The hexec tool itself > libhexec-common - Shared library for hexec internal use > libhexec-hook - Shared library that implements the exec hooking These are leftovers, right ? I see no good reason to split two separate runtime library packages if your `application' package (built from the same source package) needs them both to operate as well. Or these are just long forgotten bits from a library/dev split attempt ? If you intend to distibute a) separate runtime `library' packages (the shared library) and b) separate buildtime `development' packages (headers and static library) then it might make any sense to leave your users some options to choose which of these they would need and not bother with the rest, i.e. they might want to build depend on libhook-dev, but not on libfoo-dev (produced from the same source package). That gains you almost nothing, but anyway. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
