Re: RFS: FSlint - File System lint
Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: Can you please invest in some empty lines between your text and the text you quote? This is hardly readable. Thanks. >> >> > especially if a package maintainer is the upstream. >> >> This isn't an argument for inclusion of the debian directory (will you >> >> release a new upstream version just because you need to change a >> >> build-depends and trigger a rebuild on the Debian buildds?). >> > yikes... pardon my ignorance if it is not so... quick look at dev-ref >> > didn't allow me to find a statement that boost in debian revision >> > doesn't cause triggering of buildd. >> > you are saying that increment in debian revision doesn't trigger buildd? >> > >...< >> Of course a change in the debian revision will also trigger the >> buildds. > that is good that we agree... so what was about your statement:? Well, if the package you uploaded as debian-native has a packaging error, or just needs to be adapted to newer Debian requirements, you have two choices: Either release a new upstream version, which has has no changes relevant for anybody except the Debian buildds. This will confuse your non-Debian users. Or switch from Debian native to non-native packaging - better do that in the first place. If you've packaged it as non-native from the start, we end up in the situation described below: >> >> release a new upstream version just because you need to change a >> >> build-depends and trigger a rebuild on the Debian buildds?). > >> In the -1 debian revision, you'd have a non-native package with an empty >> diff.gz file (don't even know whether dpkg-source will accept that). > that is ok to my knowledge It is okay, but it's confusing by itself. >> In the -1 version, > -1 version? may be you meant debian revision? may be -2? Sorry, yes, I meant debian revision -2. >> you would have a diff.gz file that contains only a diff against >> debian/control and debian/changelog. Now this would be very >> confusing. Especially if there is a bug in the packaging and you are >> currently not available: A possible NMUer would be very confused. > can you describe what is confusing in that? I don't really see it... you > don't operate on diff.gz directly anyways -- you are operating on > extracted (and may be even patched) source, so you have all the files. I often operate on diff.gz files. It's easy to look into them, just "less ...diff.gz", and you can check whether the copyright file is okay, whether it uses dpatch, cdbs, whatever, whether a particular patch has been applied, and so on. > Usually you are inspecting .diff to catch what was done wrong, or if > there was garbage sucked in, or to extract relevant patch. If .diff.gz > was missing debian/ it is obvious (to me) that debian is within > orig.tar.gz due to the definition of diff.gz If the diff.gz is missing a Debian directory, the first thing I'd suspect would be that something went badly wrong. After finding out that the directory is in the orig.tar.gz, I'd go on checking in the copyright file whether any repackaging is described. If I find no information about that, I'd think about two possibilities: Either the debian directory is in the orig.tar.gz file, or the packages didn't document their repackaging. For both cases, the best approach would be to file a bug... >> > First of all *any debian package is written especially for Debian*, >> > so there is a bit of tautology. Package itself is not a software or >> > documentation, it is a packaging material (ie debian/) accompanying >> > the content. >> "package" in this context is also the name for software here. And for >> sure a package is *not* just the packaging material; a Debian source >> package consists of tar.gz and dsc or orig.tar.gz, diff.gz and dsc, >> and a binary package is a deb file. > ok - let me make an analogy to describe what I meant: "this book > containing fairy tales from around the world was written especially for > our kindergarden"... And you expect that the kindergarden in the neighborhood will not be interested, never? And you also expect that the people working there will never get a different opinion how a fairy tale book should look like? If the people working with the newest group of younger children try out something new (i.e., Debian policy is changed for the next release), shouldn't the book be still the same for the ones working with the older groups? >> How can the Debian policy "forbid" something that upstream is doing? > :-) Good questions with simple answer: it can't. That is why over and > over again everyone advices upstreams to place /debian directory aside > of orig.tar.gz. And lest don't get into the loop describing why it is > bad... ooo - actually it might be worth to compose a wiki page where > people can add to pros/cons... I've never read a pro, except "I'm both upstream and Debian maintainer, and it's convenient for me", which is a short-sighted argument. Regards, Frank -- Frank Küster S
Re: RFS: FSlint - File System lint
> >> > especially if a package maintainer is the upstream. > >> This isn't an argument for inclusion of the debian directory (will you > >> release a new upstream version just because you need to change a > >> build-depends and trigger a rebuild on the Debian buildds?). > > yikes... pardon my ignorance if it is not so... quick look at dev-ref > > didn't allow me to find a statement that boost in debian revision > > doesn't cause triggering of buildd. > > you are saying that increment in debian revision doesn't trigger buildd? > > >...< > Of course a change in the debian revision will also trigger the > buildds. that is good that we agree... so what was about your statement:? > >> release a new upstream version just because you need to change a > >> build-depends and trigger a rebuild on the Debian buildds?). > In the -1 debian revision, you'd have a non-native package with an empty > diff.gz file (don't even know whether dpkg-source will accept that). that is ok to my knowledge > In the -1 version, -1 version? may be you meant debian revision? may be -2? > you would have a diff.gz file that contains only a diff against > debian/control and debian/changelog. Now this would be very > confusing. Especially if there is a bug in the packaging and you are > currently not available: A possible NMUer would be very confused. can you describe what is confusing in that? I don't really see it... you don't operate on diff.gz directly anyways -- you are operating on extracted (and may be even patched) source, so you have all the files. Usually you are inspecting .diff to catch what was done wrong, or if there was garbage sucked in, or to extract relevant patch. If .diff.gz was missing debian/ it is obvious (to me) that debian is within orig.tar.gz due to the definition of diff.gz > > First of all *any debian package is written especially for Debian*, > > so there is a bit of tautology. Package itself is not a software or > > documentation, it is a packaging material (ie debian/) accompanying > > the content. > "package" in this context is also the name for software here. And for > sure a package is *not* just the packaging material; a Debian source > package consists of tar.gz and dsc or orig.tar.gz, diff.gz and dsc, > and a binary package is a deb file. ok - let me make an analogy to describe what I meant: "this book containing fairy tales from around the world was written especially for our kindergarden"... > > Cleaner statement may be something like "i.e. if the packaged > > material (e.g. software, images, documentation) is intended to be > > used primarily on a Debian-based system and useless on the other > > systems". That seems to be cleaner. > Submit this as a wishlist bug to the policy. indeed, I think that at least mentioning the confusion which comes once so often, it might be useful to at least trigger the change (I bet others can come up with better statement than mine) > >> > I think that policy/dev-ref is not clear on that at the moment, that > >> > is why relevant questions come up from time to time. > >> Yes, but the answers given are always the same: Try to avoid a > >> debian/ directory in the upstream sources. It's in the archives. > > yeap - I saw most of those. And I saw the arguments. And I agree that > > having split debian/ helps in few cases. But the same question arises > > over and over. May be it is the time to fix the policy to make it > > explicit to avoid the debates. > How can the Debian policy "forbid" something that upstream is doing? :-) Good questions with simple answer: it can't. That is why over and over again everyone advices upstreams to place /debian directory aside of orig.tar.gz. And lest don't get into the loop describing why it is bad... ooo - actually it might be worth to compose a wiki page where people can add to pros/cons... -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: >> > especially if a package maintainer is the upstream. >> This isn't an argument for inclusion of the debian directory (will you >> release a new upstream version just because you need to change a >> build-depends and trigger a rebuild on the Debian buildds?). > yikes... pardon my ignorance if it is not so... quick look at dev-ref > didn't allow me to find a statement that boost in debian revision > doesn't cause triggering of buildd. > > you are saying that increment in debian revision doesn't trigger buildd? > So if I fix a security bug and increment debian revision, that doesn't > penetrate to other architectures? > > if buildd is triggered by deb revision increment as well -- there is no > difference between boosting of the upstream version or only deb > revision... Of course a change in the debian revision will also trigger the buildds. But this situation is exactly the problem I was referring to: In the -1 debian revision, you'd have a non-native package with an empty diff.gz file (don't even know whether dpkg-source will accept that). In the -1 version, you would have a diff.gz file that contains only a diff against debian/control and debian/changelog. Now this would be very confusing. Especially if there is a bug in the packaging and you are currently not available: A possible NMUer would be very confused. >> , >> | Native Debian packages (i.e., packages which have been written >> | especially for Debian) whose version numbers include dates should >> | always use the "MMDD" format. >> ` [...] > If you cited it to > characterize what native package is, then we can debate on the meaning > of "packages which have been written especially for Debian". Yes, I cited it because of this. > First of all *any debian package is written especially for Debian*, > so there is a bit of tautology. Package itself is not a software or > documentation, it is a packaging material (ie debian/) accompanying the > content. "package" in this context is also the name for software here. And for sure a package is *not* just the packaging material; a Debian source package consists of tar.gz and dsc or orig.tar.gz, diff.gz and dsc, and a binary package is a deb file. > Cleaner statement may be something like "i.e. if the packaged material > (e.g. software, images, documentation) is intended to be used primarily > on a Debian-based system and useless on the other systems". That seems > to be cleaner. Submit this as a wishlist bug to the policy. >> > I think that policy/dev-ref is not clear on that at the moment, that >> > is why relevant questions come up from time to time. >> Yes, but the answers given are always the same: Try to avoid a >> debian/ directory in the upstream sources. It's in the archives. > yeap - I saw most of those. And I saw the arguments. And I agree that > having split debian/ helps in few cases. But the same question arises > over and over. May be it is the time to fix the policy to make it > explicit to avoid the debates. How can the Debian policy "forbid" something that upstream is doing? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: FSlint - File System lint
Yaroslav Halchenko wrote: > if buildd is triggered by deb revision increment as well -- there is no > difference between boosting of the upstream version or only deb > revision... There are a few benefits of only a debian revision boost. First, you only upload a small diff instead of the full package. And second, because when using debian revisions I can know who made the changes, and what I should expect from it (although that's what the changelog is there for, but anyway). -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
Christoph Haas wrote: > On Tue, May 23, 2006 at 10:07:04AM +0100, Pádraig Brady wrote: > >>Christoph Haas wrote: >> >>>On Mon, May 22, 2006 at 04:15:09PM +0100, Pádraig Brady wrote: >> >>cool, So I'll need to register my signature as a Debian Developer. >>I'll figure out how to do this thanks. > > > Uhm, you would need to become a Debian developer to be able to upload. > That means you would need to go through the so called "new maintainers > process" - see http://nm.debian.org. Although you are surely free to do > that I'm not sure whether you want to invest the time (~6 months). Interesting. Becomming a fedora developer was a much quicker process (2 weeks), though I aggree with the longer filtering process TBH. I'll go the sponsorship route for now, thanks. > > If you don't want to become a Debian developer or don't find a Debian > developer who is willing to maintain the package you could use > "sponsoring". Anyone (or you) maintains the package and then looks for a > Debian developer to upload the package on their behalf. That process is > called "sponsoring". You will still be listed as the maintainer of the > package. Just that a Debian developer checks your package prior to > uploading it. If you find a reliable sponsor that is hardly a barrier. > > >>>However the package is not yet in perfect shape. Run "lintian" on the >>>final package (lintian -i *deb) to see some obvious problems. >> >>Right, I'll lintian it and also read up on debian packaging policies. > > > Be patient. The policy is large. :) no worries. >>>Just in case there is a misunderstanding. You usually don't need to care >>>for a Debian package. It's okay to have someone who is familiar with >>>Debian to deal with all the policy and procedures. Here I assume that >>>you are personally interested in maintaining the Debian package. Just to >>>let you know there are surely volunteers in the Debian project so you >>>can concentrate on developing the actual (upstream) software. >> >>Sure. It would be better if someone stepped up, >>but in my experience I think it will be faster if I do everything myself. > > > I'll take a close look at your software. I can imagine that I'll become > the Debian maintainer of it unless you like to do that yourself. That > way you don't need to worry about the Debian-specific issues. Sweet! I have a few bug fixes queued, and also the lintian stuff etc. So I'll release 2.16 in a week or so and we can go from there. thanks, Pádraig. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
> > especially if a package maintainer is the upstream. > This isn't an argument for inclusion of the debian directory (will you > release a new upstream version just because you need to change a > build-depends and trigger a rebuild on the Debian buildds?). yikes... pardon my ignorance if it is not so... quick look at dev-ref didn't allow me to find a statement that boost in debian revision doesn't cause triggering of buildd. you are saying that increment in debian revision doesn't trigger buildd? So if I fix a security bug and increment debian revision, that doesn't penetrate to other architectures? if buildd is triggered by deb revision increment as well -- there is no difference between boosting of the upstream version or only deb revision... > > And also I don't see any strict requirement > > (although I understand that it is desired) to don't use native > > versioning schema for not-only-for-debian packages. > I don't see this written out specifically, either, but I think this is > implied. For example, 3.2.1 talks about native packages: > , > | Native Debian packages (i.e., packages which have been written > | especially for Debian) whose version numbers include dates should > | always use the "MMDD" format. > ` well -- that is only for the "Version numbers based on dates" and from the same section "In general, Debian packages should use the same version numbers as the upstream sources". If you cited it to characterize what native package is, then we can debate on the meaning of "packages which have been written especially for Debian". First of all *any debian package is written especially for Debian*, so there is a bit of tautology. Package itself is not a software or documentation, it is a packaging material (ie debian/) accompanying the content. Cleaner statement may be something like "i.e. if the packaged material (e.g. software, images, documentation) is intended to be used primarily on a Debian-based system and useless on the other systems". That seems to be cleaner. > > I think that policy/dev-ref is not clear on that at the moment, that > > is why relevant questions come up from time to time. > Yes, but the answers given are always the same: Try to avoid a > debian/ directory in the upstream sources. It's in the archives. yeap - I saw most of those. And I saw the arguments. And I agree that having split debian/ helps in few cases. But the same question arises over and over. May be it is the time to fix the policy to make it explicit to avoid the debates. -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpffhsmpWBX7.pgp Description: PGP signature
Re: RFS: FSlint - File System lint
Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: > So I don't see anything which requires debian/ directory to be absent > from the orig.tar.gz You are right, there is no such "law". But still it's a bad idea. > especially if a package maintainer is the upstream. This isn't an argument for inclusion of the debian directory (will you release a new upstream version just because you need to change a build-depends and trigger a rebuild on the Debian buildds?). > And also I don't see any strict requirement > (although I understand that it is desired) to don't use native > versioning schema for not-only-for-debian packages. I don't see this written out specifically, either, but I think this is implied. For example, 3.2.1 talks about native packages: , | Native Debian packages (i.e., packages which have been written | especially for Debian) whose version numbers include dates should | always use the "MMDD" format. ` > I think that policy/dev-ref is not clear on that at the moment, that is > why relevant questions come up from time to time. Yes, but the answers given are always the same: Try to avoid a debian/ directory in the upstream sources. It's in the archives. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: FSlint - File System lint
> > > You need to remove debian/ directory form fslint_2.15.orig.tar.gz file in > > > order to produce non Debian native package! > > Could you please point me where it is *required* (to address "need > > to") that upstream sourced do not include debian/? > > I fully understand, that > from http://www.debian.org/doc/maint-guide/footnotes.en.html#f5 > | Some people argue that, even for Debian specific packages, it is still > | better practice to package the contents of the debian/ directory > | residing in the diff.gz file, rather than in the orig.tar.gz file. Nice addendum to the pieces I've collected ;-) Thanks That implies also to use debian revisions for "native" debian specific packages. -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgp0324ILNOp8.pgp Description: PGP signature
Re: RFS: FSlint - File System lint
> > developer's signature on the package to be accepted in the official > > repositories - just a security measure. > cool, So I'll need to register my signature as a Debian Developer. > I'll figure out how to do this thanks. (Un)fortunately becoming a debian developer is a long term step, for now you should seek for a sponsor for your packages Please have a look at http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#sponsored_packages for how to do that and register your request at http://sponsors.debian.net/ -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpdkAuEaHmcP.pgp Description: PGP signature
Re: RFS: FSlint - File System lint
On Tue, May 23, 2006 at 10:07:04AM +0100, Pádraig Brady wrote: > Christoph Haas wrote: > > On Mon, May 22, 2006 at 04:15:09PM +0100, Pádraig Brady wrote: > cool, So I'll need to register my signature as a Debian Developer. > I'll figure out how to do this thanks. Uhm, you would need to become a Debian developer to be able to upload. That means you would need to go through the so called "new maintainers process" - see http://nm.debian.org. Although you are surely free to do that I'm not sure whether you want to invest the time (~6 months). If you don't want to become a Debian developer or don't find a Debian developer who is willing to maintain the package you could use "sponsoring". Anyone (or you) maintains the package and then looks for a Debian developer to upload the package on their behalf. That process is called "sponsoring". You will still be listed as the maintainer of the package. Just that a Debian developer checks your package prior to uploading it. If you find a reliable sponsor that is hardly a barrier. > > However the package is not yet in perfect shape. Run "lintian" on the > > final package (lintian -i *deb) to see some obvious problems. > > Right, I'll lintian it and also read up on debian packaging policies. Be patient. The policy is large. :) > > Just in case there is a misunderstanding. You usually don't need to care > > for a Debian package. It's okay to have someone who is familiar with > > Debian to deal with all the policy and procedures. Here I assume that > > you are personally interested in maintaining the Debian package. Just to > > let you know there are surely volunteers in the Debian project so you > > can concentrate on developing the actual (upstream) software. > > Sure. It would be better if someone stepped up, > but in my experience I think it will be faster if I do everything myself. I'll take a close look at your software. I can imagine that I'll become the Debian maintainer of it unless you like to do that yourself. That way you don't need to worry about the Debian-specific issues. Kindly Christoph -- ~ ~ ".signature" [Modified] 1 line --100%--1,48 All signature.asc Description: Digital signature
Re: RFS: FSlint - File System lint
Christoph Haas wrote: > On Mon, May 22, 2006 at 04:15:09PM +0100, Pádraig Brady wrote: > >>Justin Pryzby wrote: >> >On Mon, May 22, 2006 at 12:06:33PM +0100, P?draig Brady wrote: As far as I can see you want me to provide: fslint_2.15-1.dsc fslint_2.15-1.orig.tar.gz fslint_2.15-1.diff.gz >>> >>>Yea, this is the "source package". You could have an empty .diff.gz >> >>Done. The following "source package" was built with: >>dpkg-source -b fslint-2.15 fslint_2.15.orig.tar.gz >> >>http://www.pixelbeat.org/fslint/debian/ > > > Much better! Thanks. > > >>I'm confused as to why it didn't ask me to sign it. > > > Depends on how you built the package. Usually I run "debuild" which will > try to sign the package afterwards. Signing the package is important if > the package gets uploaded to Debian because you need a Debian > developer's signature on the package to be accepted in the official > repositories - just a security measure. cool, So I'll need to register my signature as a Debian Developer. I'll figure out how to do this thanks. > However the package is not yet in perfect shape. Run "lintian" on the > final package (lintian -i *deb) to see some obvious problems. Right, I'll lintian it and also read up on debian packaging policies. > Just in case there is a misunderstanding. You usually don't need to care > for a Debian package. It's okay to have someone who is familiar with > Debian to deal with all the policy and procedures. Here I assume that > you are personally interested in maintaining the Debian package. Just to > let you know there are surely volunteers in the Debian project so you > can concentrate on developing the actual (upstream) software. Sure. It would be better if someone stepped up, but in my experience I think it will be faster if I do everything myself. thanks, Pádraig. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
Yaroslav Halchenko ([EMAIL PROTECTED]): > > You need to remove debian/ directory form fslint_2.15.orig.tar.gz file in > > order to produce non Debian native package! > > Could you please point me where it is *required* (to address "need > to") that upstream sourced do not include debian/? > I fully understand, that from http://www.debian.org/doc/maint-guide/footnotes.en.html#f5 | Some people argue that, even for Debian specific packages, it is still | better practice to package the contents of the debian/ directory | residing in the diff.gz file, rather than in the orig.tar.gz file. but it's not a "must". Sorry, my mistake -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp6BbkfKrePu.pgp Description: PGP signature
Re: RFS: FSlint - File System lint
Sorry to intrude but I wanted to clarify a bit (although there had been a lengthy thread on native packages not that long ago) > You need to remove debian/ directory form fslint_2.15.orig.tar.gz file in > order to produce non Debian native package! Could you please point me where it is *required* (to address "need to") that upstream sourced do not include debian/? I fully understand, that having no debian in upstream source is handy for any dpatch-oriented DD, since with dpatch you wouldn't be able to patch most debian/ files Otherwise, there is no harm at all for upstream to provide any debian/ infrastructure -- any change can be easily absorbed into .diff. Inconvenience arises also in a conflict within debian/changelog entries, so manual interaction might be necessary on each uupdate NMU can happen for native packaging as well and versioning scheme is there, so I don't see much of a problem there. And if we go through the policy we can find next excerpts which do not rule out possibility for upstream to have debian/ directory and for upstream author to be a debian maintainer as well. so talking about native packaging: Policy C.3: > | ... or the Debian maintainer is the same as the upstream maintainer > | - the format is slightly different:... and further from C as well: "This is a unified context diff (diff -u) giving the changes which are required to turn the original source into the Debian source." So if original source already includes everything to be a Debian source, and requires only minor tuning, (or not at all), then only those minor changes (at least Debian/changelog entry with proper maintainer information) need to be in .diff.gz. So I don't see anything which requires debian/ directory to be absent from the orig.tar.gz especially if a package maintainer is the upstream. And also I don't see any strict requirement (although I understand that it is desired) to don't use native versioning schema for not-only-for-debian packages. I think that policy/dev-ref is not clear on that at the moment, that is why relevant questions come up from time to time. -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpz19KkZJsSo.pgp Description: PGP signature
Re: RFS: FSlint - File System lint
You need to remove debian/ directory form fslint_2.15.orig.tar.gz file in order to produce non Debian native package! -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgphPDgEBRFRd.pgp Description: PGP signature
Re: RFS: FSlint - File System lint
On Mon, May 22, 2006 at 04:15:09PM +0100, Pádraig Brady wrote: > Justin Pryzby wrote: > >>>On Mon, May 22, 2006 at 12:06:33PM +0100, P?draig Brady wrote: > >>As far as I can see you want me to provide: > >> > >>fslint_2.15-1.dsc > >>fslint_2.15-1.orig.tar.gz > >>fslint_2.15-1.diff.gz > > > > Yea, this is the "source package". You could have an empty .diff.gz > > Done. The following "source package" was built with: > dpkg-source -b fslint-2.15 fslint_2.15.orig.tar.gz > > http://www.pixelbeat.org/fslint/debian/ Much better! Thanks. > I'm confused as to why it didn't ask me to sign it. Depends on how you built the package. Usually I run "debuild" which will try to sign the package afterwards. Signing the package is important if the package gets uploaded to Debian because you need a Debian developer's signature on the package to be accepted in the official repositories - just a security measure. However the package is not yet in perfect shape. Run "lintian" on the final package (lintian -i *deb) to see some obvious problems. Just in case there is a misunderstanding. You usually don't need to care for a Debian package. It's okay to have someone who is familiar with Debian to deal with all the policy and procedures. Here I assume that you are personally interested in maintaining the Debian package. Just to let you know there are surely volunteers in the Debian project so you can concentrate on developing the actual (upstream) software. Kindly Christoph -- ~ ~ ".signature" [Modified] 1 line --100%--1,48 All signature.asc Description: Digital signature
Re: RFS: FSlint - File System lint
Pádraig Brady <[EMAIL PROTECTED]> wrote: > Done. The following "source package" was built with: > dpkg-source -b fslint-2.15 fslint_2.15.orig.tar.gz [...] > I'm confused as to why it didn't ask me to sign it. I don't know if that's expected (I usually use 'debuild' to build my source packages), but you can always sign the .dsc and .changes files afterwards with 'debsign'. Actually, this is generally better because then, you only type your GPG passphrase when the packages are really ready, *after* doing all your tests (which usually causes several package builds for the incremental fixes, and therefore several times where you would type you GPG passphrase for no good reason in the end, if not building with a "don't sign" setting). NB : to tell debuild not to sign by default, I have: DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc" in ~/.devscripts. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
Justin Pryzby wrote: >>>On Mon, May 22, 2006 at 12:06:33PM +0100, P?draig Brady wrote: >>As far as I can see you want me to provide: >> >>fslint_2.15-1.dsc >>fslint_2.15-1.orig.tar.gz >>fslint_2.15-1.diff.gz > > Yea, this is the "source package". You could have an empty .diff.gz Done. The following "source package" was built with: dpkg-source -b fslint-2.15 fslint_2.15.orig.tar.gz http://www.pixelbeat.org/fslint/debian/ I'm confused as to why it didn't ask me to sign it. thanks, Pádraig. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
Hi there. On May 22 2006, Pádraig Brady wrote: > Christoph Haas wrote: > > I see now. You are the actual developer of fslint. Usually there is > > the (upstream) developer and a Debian developer is doing the > > packaging work. If the upstream provides a debian/ package that has > > caused a lot of trouble for me. > > OK I can remove the upstream one when it gets integrated > in case there is any confusion. As you are the upstream maintainer of the program, you can maintain the debian directory in a separate portion of your CVS/Subversion/etc repository. > OK. I presume one can have a blank debian directory? Or even an non-existent one, that gets integrated when you checkout your debian directory from the repository. > What do I need to do exactly? As far as I can see you want me to provide: > > fslint_2.15-1.dsc > fslint_2.15-1.orig.tar.gz > fslint_2.15-1.diff.gz Yes, this is "the right way" for non-native Debian packages. Regards, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
Rogério Brito wrote: > Hi, Pádraig. > > On May 22 2006, Pádraig Brady wrote: > >>Description: A toolkit to find redundant disk usage >> FSlint is a toolkit to find redundant disk usage, like duplicate files >> for example. It includes a GUI as well as a command line interface. > > > This is a class of tools that interest me quite a lot. > > Would you, please, care to explain in the long description how it > differs from fdupes (which is what I have been using for eliminating > duplicate files)? First of all, fslint is a suite of tools. As well as duplicate files, it can be used to find temporary files, help clean unused packages, troublesome filenames, ... OK taking a quick look at fdupes: fdupes is CLI only fslint has both CLI and (GTK) GUI http://www.pixelbeat.org/fslint/FSlint-2.08-pt_BR.png fdupes is implemented in C fslint is shell (CLI) and python (GUI) fslint is FAST and scalable: $ time ./findup --gui /usr/share/doc > /dev/null real0m1.829s $ time ./fdupes -q -r /usr/share/doc > /dev/null real0m6.981s I have found nothing as fast as fslint for finding duplicates. fslint can merge duplicates using hardlinks. Note this isn't a trivial addition to fdupes. fslint has very sophisticated hardlink processing, which I verified fdupes does not handle. This is required in the case where one wants to incrementally merge using hardlinks multiple trees. fdupes hasn't been updated in 4 years (since June 2002) fslint is updated actively: http://www.pixelbeat.org/fslint/NEWS.html cheers, Pádraig. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
On Mon, May 22, 2006 at 12:41:04PM +0100, P?draig Brady wrote: > Christoph Haas wrote: > > Hi, P?draig... > > > > you accidentally replies personally to me instead of sending a followup > > to the mailing list. > > sorry. > > > On Mon, May 22, 2006 at 12:06:33PM +0100, P?draig Brady wrote: > > > >>build from the extracted tarball directly with: > >> > >>dpkg-buildpackage -rfakeroot -tc > >> > >>How should I create this source package? > > > > > > I see now. You are the actual developer of fslint. Usually there is the > > (upstream) developer and a Debian developer is doing the packaging work. > > If the upstream provides a debian/ package that has caused a lot of > > trouble for me. > > OK I can remove the upstream one when it gets integrated > in case there is any confusion. > > > Usually there is just the upstream tarball and someone > > maintains the debian/ directory seperately. That way you can always see > > what special things have been done in the Debian package because a > > seperate diff.gz lists them. > > OK. I presume one can have a blank debian directory? Do you mean an empty .diff, or an empty directory in the sourceball, with the files created in the .diff? dpkg-source knows to create ./debian/, so it doesn't have to be in the sourceball. > > If you like to maintain the package yourself that'll probably not be a > > problem either. Just not very common. > > I can do that. Even though I'm a debian newbie > the package is quite standard. > > What do I need to do exactly? > As far as I can see you want me to provide: > > fslint_2.15-1.dsc > fslint_2.15-1.orig.tar.gz > fslint_2.15-1.diff.gz Yea, this is the "source package". You could have an empty .diff.gz, or maintain the Debian patch as a separate project. IMO it is only useful to separate "the changes that Debian made", and when there same person wrote the diff.gz as the upstream source, there's no distinction. So the only arguments for having debian/ in the .diff.gz and not in the sourceball are: . more conventional . not confusing other people using other distributions . allowing new Debian revisions without bumping the version for the non-Debian source Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
Hi, Pádraig. On May 22 2006, Pádraig Brady wrote: > Description: A toolkit to find redundant disk usage > FSlint is a toolkit to find redundant disk usage, like duplicate files > for example. It includes a GUI as well as a command line interface. This is a class of tools that interest me quite a lot. Would you, please, care to explain in the long description how it differs from fdupes (which is what I have been using for eliminating duplicate files)? Thanks for your efforts, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
Christoph Haas wrote: > Hi, Pádraig... > > you accidentally replies personally to me instead of sending a followup > to the mailing list. sorry. > On Mon, May 22, 2006 at 12:06:33PM +0100, Pádraig Brady wrote: > >>build from the extracted tarball directly with: >> >>dpkg-buildpackage -rfakeroot -tc >> >>How should I create this source package? > > > I see now. You are the actual developer of fslint. Usually there is the > (upstream) developer and a Debian developer is doing the packaging work. > If the upstream provides a debian/ package that has caused a lot of > trouble for me. OK I can remove the upstream one when it gets integrated in case there is any confusion. > Usually there is just the upstream tarball and someone > maintains the debian/ directory seperately. That way you can always see > what special things have been done in the Debian package because a > seperate diff.gz lists them. OK. I presume one can have a blank debian directory? > If you like to maintain the package yourself that'll probably not be a > problem either. Just not very common. I can do that. Even though I'm a debian newbie the package is quite standard. What do I need to do exactly? As far as I can see you want me to provide: fslint_2.15-1.dsc fslint_2.15-1.orig.tar.gz fslint_2.15-1.diff.gz thank you, Pádraig. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
On Mon, May 22, 2006 at 09:48:59AM +0100, Pádraig Brady wrote: > I sent an RFS for FSlint 3 months ago. > Since then, I have released 2.15 with fixes for lots > of debian packaging comments from Justin Pryzby. > > So is it ready for inclusion? > > homepage: http://www.pixelbeat.org/fslint/ > source: http://www.pixelbeat.org/fslint/FSlint-2.15.tar.gz > deb: http://www.pixelbeat.org/fslint/fslint_2.15-1_all.deb Where can your source package be found? Kindly Christoph -- ~ ~ ".signature" [Modified] 1 line --100%--1,48 All signature.asc Description: Digital signature
Re: RFS: FSlint - File System lint
Justin Pryzby wrote:
>On Mon, Feb 27, 2006 at 04:47:31PM -0500, pryzbyj wrote:
>
>>On Mon, Feb 27, 2006 at 05:04:30PM +, P??draig Brady wrote:
>>
>>>Hi,
>>>
>>>I've been maintaining FSlint for a few years now
>>>and it has proved quite popular. There have even
>>>been (buggy) thirdparty debian packages floating around.
>>>In the latest version (2.14) I have created a debian package,
>>>and it would be create if someone could sponsor this
>>>package for inclusion in debian.
>
>This package is really quite neat. I've read through much of the
>code, (lots of pretty-small bashscripts), and I must say that I'm
>inspired. I especially like this "find duplicates" pipeline (my own
>implementation here):
Cheers. Hopefully we'll get 2.15 into debian soon.
I'm working on your comments and also I have a bug fix
I'd like to get done.
>
> find . -type f -print0 |xargs -r0 md5sum |sort |sed -re
's/(\S*)\s*(\S*)/\2\t\1/' |uniq -df1 --all-=sep |sed -e 's/\t\S*$//;'
Note throwing away unique file sizes first is a huge optimization.
I also sort by inodes (or path is nearly as good),
which reduces disk seeking a lot.
>
>Does anyone know a prettier way of switching the md5sum output than
>this sedscript?? (Has to deal with special pathnames, of course!)
My method is more robust BTW (try path names with spaces)
sed -e 's/\(^.\{32\}\)..\(.*\)/\2 \1/'
Note I think uniq will get key support (like sort) at some stage.
Also debian has a specific patch for -W to compare only
the first N fields. However this is not standard and
has just been removed I understand.
>
>Or a way of optimizing the files removed? (Probably to maximize the
>level of directories which have no normal files anywhere within them
>after removal).
Never thought of that. Hmm...
Pádraig.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
On Mon, Feb 27, 2006 at 04:47:31PM -0500, pryzbyj wrote: > On Mon, Feb 27, 2006 at 05:04:30PM +, P??draig Brady wrote: > > Hi, > > > > I've been maintaining FSlint for a few years now > > and it has proved quite popular. There have even > > been (buggy) thirdparty debian packages floating around. > > In the latest version (2.14) I have created a debian package, > > and it would be create if someone could sponsor this > > package for inclusion in debian. This package is really quite neat. I've read through much of the code, (lots of pretty-small bashscripts), and I must say that I'm inspired. I especially like this "find duplicates" pipeline (my own implementation here): find . -type f -print0 |xargs -r0 md5sum |sort |sed -re 's/(\S*)\s*(\S*)/\2\t\1/' |uniq -df1 --all-=sep |sed -e 's/\t\S*$//;' Does anyone know a prettier way of switching the md5sum output than this sedscript?? (Has to deal with special pathnames, of course!) Or a way of optimizing the files removed? (Probably to maximize the level of directories which have no normal files anywhere within them after removal). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
On Tue, Feb 28, 2006 at 04:34:45PM +, P?draig Brady wrote: > Justin Pryzby wrote: > >On Mon, Feb 27, 2006 at 05:04:30PM +, P??draig Brady wrote: > > > >>Hi, > >> > >>I've been maintaining FSlint for a few years now > >>and it has proved quite popular. There have even > >>been (buggy) thirdparty debian packages floating around. > >>In the latest version (2.14) I have created a debian package, > >>and it would be create if someone could sponsor this > >>package for inclusion in debian. Oops; policy 3.5 recommends to not depend without versions on essential packages such as bash: http://www.us.debian.org/doc/debian-policy/ch-binary.html#s3.5 |Packages are not required to declare any dependencies they have on |other packages which are marked Essential (see below), and should not |do so unless they depend on a particular version of that package. Do you have an ITP filed? You should, and close it in the changelog. -$(MAKE) -C po clean This is evil; see bug #325372. You run perl substitution in the install target; why not create an install target which allows this generality? Uncomment watchfile lines. dpkg-buildpackage -rfakeroot is preferable to fakeroot dpkg-buildpackage (doc/FAQ) Please include a more detailed license statement, in the source files, in the README, and perhaps in "COPYING" or "LICENSE". All the bash scripts should probably be using set -e. Why not use some incarnation of tmpfile rather than TMP/unused_and_referenced_libs ? counter=counter+1 #use bash arithmetic for speed What?! All for now Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FSlint - File System lint
On Mon, Feb 27, 2006 at 05:04:30PM +, P??draig Brady wrote: > Hi, > > I've been maintaining FSlint for a few years now > and it has proved quite popular. There have even > been (buggy) thirdparty debian packages floating around. > In the latest version (2.14) I have created a debian package, > and it would be create if someone could sponsor this > package for inclusion in debian. You might separate the source package into a .orig.tar.gz and a .diff.gz (or might not). You might want to consider adding doc/* to the call to dh_install doc, rather than in a separate file. Please add the years of development to the copyright file. Remove the comments from the watchfile. Long description suggestion: replace "duplicate files for e.g." with "for example, duplicate files.". As for the scripts themselves, you are using #!/bin/sh, but bash-specific features such as: [ .. == .. ] should be just [ .. = .. ] . foo bar; "bar" is not guaranteed to be passed as $1 Test your scripts with posh or dash, or change them to use #!/bin/bash Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
