Bug#428311: Packages awaiting sponsorship (fsvs)
On Sunday 09 December 2007 22:18:40 Matthew Johnson wrote: Well, I don't mind either way who sponsors. Mario's suggestions are all good ones and what I would do in my own packages I just wouldn't necessarily call them show stoppers. I think it makes sense for Mario to sponsor the package, then, since he had more things he wanted dealt with prior to inclusion. Mario, I've uploaded an updated package for 1.1.11: http://mentors.debian.net/debian/pool/main/f/fsvs It addresses the concerns you raised, and also fixes a confusing whitespace bug in the documentation and online help. Gentlemen, thanks again for taking an interest and being willing to invest your time. Ciao, Sheldon. -- Sheldon Hearn IT Director Clue Technologies (PTY) Ltd Web:http://www.clue.co.za/ Mail: [EMAIL PROTECTED] Office: +27-21-913-8840 Mobile: +27-83-564-3276 Timezone: SAST (+0200) signature.asc Description: This is a digitally signed message part.
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sunday 09 December 2007 Sheldon Hearn wrote: On Sunday 09 December 2007 21:39:01 Sheldon Hearn wrote: The debian/changelog can then also be reduced... Ah btw, what was the technical reason to run autoconf? I was about to say I don't remember, it was so long ago and then took a long. I don't think I run autoconf during the build? Ah, I see now, it's run in the configure target in the upstream Makefile. Philipp, do you know off-hand why we have to run autoconf in the build? That's for the case that someone got the sources from svn, and just tries to run make - or when configure.in has changed. -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!
Bug#428311: Packages awaiting sponsorship (fsvs)
On Monday 10 December 2007 10:55:58 Philipp Marek wrote: Philipp, do you know off-hand why we have to run autoconf in the build? That's for the case that someone got the sources from svn, and just tries to run make - or when configure.in has changed. I remember now. It's because you don't provide src/Makefile, only src/Makefile.in. So I left the autoconf run in the configure target. Ciao, Sheldon. -- Sheldon Hearn IT Director Clue Technologies (PTY) Ltd Web:http://www.clue.co.za/ Mail: [EMAIL PROTECTED] Office: +27-21-913-8840 Mobile: +27-83-564-3276 Timezone: SAST (+0200) signature.asc Description: This is a digitally signed message part.
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sunday 09 December 2007 Matthew Johnson wrote: Hi, I noticed your RFS and would be happy to sponsor the package. It looks in pretty good shape, I'm just trying it out here. How much do you use it? had any problems? (I have an ulterior motive, I'm wondering about using it in a production system). If that would be considered a Good Thing(TM), I'd like to take the debian/ subdirectory on board, ie. put it along the sources. The vict^H^H^H^Hvolunteer could even have commit access :-) Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sun Dec 09 09:59, Philipp Marek wrote: On Sunday 09 December 2007 Matthew Johnson wrote: Hi, I noticed your RFS and would be happy to sponsor the package. It looks in pretty good shape, I'm just trying it out here. How much do you use it? had any problems? (I have an ulterior motive, I'm wondering about using it in a production system). If that would be considered a Good Thing(TM), I'd like to take the debian/ subdirectory on board, ie. put it along the sources. The vict^H^H^H^Hvolunteer could even have commit access :-) It's usually considered good practice to keep the debian packaging separate from the upstream source; our source distribution provides: - an orig.tar.gz, which is the upstream tarball verbatim (if possible) - a diff.gz which is any debian patches and the contents of the debian/ directory. However, we would certainly like to work closely with you as upstream. Sheldon is the maintainer, so it's up to him where he keeps the debian packaging, if he'd like to keep it in your VCS so you can both work in it, that's absolutely fine, but I'd suggest having it separate to the upstream source, so that both can be released independently. It's nice to have a responsive upstream maintainer (-: Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sun Dec 09 16:11, Philipp Marek wrote: On Sunday 09 December 2007 Matthew Johnson wrote: However, we would certainly like to work closely with you as upstream. Sheldon is the maintainer, so it's up to him where he keeps the debian packaging, if he'd like to keep it in your VCS so you can both work in it, that's absolutely fine, but I'd suggest having it separate to the upstream source, so that both can be released independently. That I don't understand ... how does the release cycle depend on where the debian data is? Debian releases won't coincide exactly with upstream releases. We need to do integration tests after you release and may well release more frequent debian revisions than upstream releases to either fix bugs ahead of your release cycle or change things which are unrelated to anything outside debian. This is particularly true when fsvs becomes part of a stable debian release. If there are any security or other critical bugs, fixes to these will be backported to the version in stable, we don't use new upstream releases to fix stable. These bugs will be fixed in the debian diff and the upstream tarball will remain the same. This allows us to more easily audit that the changes to the stable distribution are the minimum possible to fix the bug. Even the packages which I am both upstream and maintainer for I keep the upstream sources separate from the debian packaging. What my question aims at: I already have a make-release script; if there'd be something like change version number in debian/... (and/or something else), it would be no more work - and the debian package could be easier kept up-to-date. I'm not averse to something like that (actually you have to add a new changelog entry), but you don't want to have to make a new upstream release every time something changes in the debian packaging, so they would have to be structured in such a way that they are released separately. For reference, we have a lot of tools to make this easier such as svn-buildpackage. This will automatically get the upstream tarball from a different directory and integrate the debian dir in svn with it to create the debian source package and then build it. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sunday 09 December 2007 Matthew Johnson wrote: However, we would certainly like to work closely with you as upstream. Sheldon is the maintainer, so it's up to him where he keeps the debian packaging, if he'd like to keep it in your VCS so you can both work in it, that's absolutely fine, but I'd suggest having it separate to the upstream source, so that both can be released independently. That I don't understand ... how does the release cycle depend on where the debian data is? What my question aims at: I already have a make-release script; if there'd be something like change version number in debian/... (and/or something else), it would be no more work - and the debian package could be easier kept up-to-date. It's nice to have a responsive upstream maintainer (-: No worries :-) You're welcome. Of course I'm interested in getting my package used! Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sunday 09 December 2007 Matthew Johnson wrote: Debian releases won't coincide exactly with upstream releases. ... The only thing I'd ask for would be to take the current version, and the changed description (no longer aims for ... it is, I decided :-) before uploading that in main. Thank you! Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sun Dec 09 16:46, Philipp Marek wrote: On Sunday 09 December 2007 Matthew Johnson wrote: Debian releases won't coincide exactly with upstream releases. ... The only thing I'd ask for would be to take the current version, and the changed description (no longer aims for ... it is, I decided :-) before uploading that in main. Sheldon, if you change the description and check everything still works with 1.1.11, then send me a new source package I'll upload it. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sunday 09 December 2007 18:41:27 Matthew Johnson wrote: Sheldon, if you change the description and check everything still works with 1.1.11, then send me a new source package I'll upload it. It never rains, it pours. :-) We now have two people offering to sponsor the package: Mario and Matthew. Matthew, Mario had some criticisms for my package, so I've copied you in. I've also copied in the author, who's taken an interest in the effort Here some technical/cosmetical comments about your package: Ok, the config.* files are ugly but you can't do a lot against them, I recommend you to read /usr/share/doc/autotools-dev/README.Debian.gz. It was that document that led me to believe I should update config.sub and config.guess from /usr/share/misc. Did I do the wrong thing? Making changes by hand outside of debian/ is also ugly, as you did for the Makefile. There are two clean solutions: 1) Just use the few distclean statements in debian/rules byhand instead uf calling make distclean. 2) Write a patch (maybe dpatch, quilt) and apply it during build time. I'll go with the patch approach. I prefer patches over the debian-specific approach, because they serve as candidates for upstream inclusion. :-) The debian/changelog can then also be reduced... Ah btw, what was the technical reason to run autoconf? I was about to say I don't remember, it was so long ago and then took a long. I don't think I run autoconf during the build? In the debian/rules file you could remove the lines which are commented out from the template. Great, will do. If you fix those issues, you have me as a sponsor... Just ask when you're ready. So _this_ is a first for me. I'm used to my packages (all two of them) rotting away on mentors.debian.net, so I'm not sure how to handle the situation where _two_ DDs offer to sponsor. Do you guys play a round of rock, paper, scissors? :-) While that's happening, I'll address Mario and Philipp's concerns, take the new package for a spin and upload it to mentors.debian.net if I don't run into problems. Philipp, sorry I haven't made any progress on the doc front. Regrettably, I don't think I'll have time for it for the next couple of weeks. Also, just to manage your expectations, the package will feature in unstable, then testing, but won't make it down to stable until the next major release. But I'll be happy to supply stable backports for you to make available for download from Tigris. Ciao, Sheldon. signature.asc Description: This is a digitally signed message part.
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sunday 09 December 2007 21:39:01 Sheldon Hearn wrote: The debian/changelog can then also be reduced... Ah btw, what was the technical reason to run autoconf? I was about to say I don't remember, it was so long ago and then took a long. I don't think I run autoconf during the build? Ah, I see now, it's run in the configure target in the upstream Makefile. Philipp, do you know off-hand why we have to run autoconf in the build? Ciao, Sheldon. -- Sheldon Hearn IT Director Clue Technologies (PTY) Ltd Web:http://www.clue.co.za/ Mail: [EMAIL PROTECTED] Office: +27-21-913-8840 Mobile: +27-83-564-3276 Timezone: SAST (+0200) signature.asc Description: This is a digitally signed message part.
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sun Dec 09 21:39, Sheldon Hearn wrote: On Sunday 09 December 2007 18:41:27 Matthew Johnson wrote: Sheldon, if you change the description and check everything still works with 1.1.11, then send me a new source package I'll upload it. It never rains, it pours. :-) We now have two people offering to sponsor the package: Mario and Matthew. Matthew, Mario had some criticisms for my package, so I've copied you in. I've also copied in the author, who's taken an interest in the effort Well, I don't mind either way who sponsors. Mario's suggestions are all good ones and what I would do in my own packages I just wouldn't necessarily call them show stoppers. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sunday 09 December 2007 22:18:40 Matthew Johnson wrote: Well, I don't mind either way who sponsors. Mario's suggestions are all good ones and what I would do in my own packages I just wouldn't necessarily call them show stoppers. I think I've found a problem with the documentation that confuses the crap out of new users. I suspect doxygen is introducing extraneous whitespace into ignore pattern examples. Philipp and I will work on it and I'll upload once that issue's resolved. Other than that, the new package for 1.1.11 works for me. Ciao, Sheldon. -- Sheldon Hearn IT Director Clue Technologies (PTY) Ltd Web:http://www.clue.co.za/ Mail: [EMAIL PROTECTED] Office: +27-21-913-8840 Mobile: +27-83-564-3276 Timezone: SAST (+0200) signature.asc Description: This is a digitally signed message part.
Bug#428311: Packages awaiting sponsorship (fsvs)
Hi, I noticed your RFS and would be happy to sponsor the package. It looks in pretty good shape, I'm just trying it out here. How much do you use it? had any problems? (I have an ulterior motive, I'm wondering about using it in a production system). Matt -- Matthew Johnson signature.asc Description: Digital signature
