Re: RFS: flightgear, fgfs-base and simgear (updated packages) and 16 new flightgear related packages (attempt three)
On Thu, 16 Sep 2010, Chris Baines wrote: > I am looking for a sponsor or many sponsors for my new and updated > FlightGear related packages. I have included a summary of all the > information in one email to make it easier to read and understand. > > The updated packages are "flightgear", "fgfs-base" and "simgear", all > moving to the 2.0.0-1 version. > > They build these binary packages: > flightgear - Flight Gear Flight Simulator > fgfs-base - Flight Gear Flight Simulator - base files > fgfs-base-models - Flight Gear Flight Simulator - base model files > simgear-dev - Simulator Construction Gear -- development files > simgear2.0.0 - Simulator Construction Gear -- shared libraries > > The new packages are,"fgfs-scenery-w130n30" that provides the default > FlightGear Scenery, "fgrun", graphical FlightGear Launcher, "fgo", > graphical FlightGear Launcher and packages > for the FlightGear Aircraft Models, of which there are 13, named > fgfs-aircraft-X where X is the name of the aircraft. That's a lot of packages, and they don't look like they'd be very big. Is there a reason for not packaging them all in a single larger flightgear-data arch-all package (source packages can now have several .orig tarballs, so that shouldn't be a driving reason to have multiple binary packages anymore)? > I would be glad if someone uploaded these packages for me. This is the > third time I have submitted this request, I understand completely how > complex all these packages are, and thus probably why no one has yet > sponsored them, but is there another approach I could pursue to get them > in to Debian, as would hate to see my work go to waste? It is past the first release cut date, it will probably help if you offer some good convincing reasons why you should get a freeze exception to replace the old flightgear packages with the new ones, and check it with the release team. If you do get a freeze exception, it would be easier to find a sponsor, I think. It is pointless to add new versions to unstable right now if they're not going to be allowed in squeeze. OTOH, you CAN target the packages to experimental (and provide backports through backports.debian.org when squeeze is released). Offering to do that is might also help getting a sponsor. There is certainly no reason to waste the effort you put on the packaging. I am sorry I cannot offer to be your sponsor at this time, I don't have enough time to check packages (and it would be better to get someone that plays flightgear, if possible). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100917005911.ga20...@khazad-dum.debian.net
Re: RFS: flightgear, fgfs-base and simgear (updated packages) and 16 new flightgear related packages (attempt three)
Dear mentors, I am looking for a sponsor or many sponsors for my new and updated FlightGear related packages. I have included a summary of all the information in one email to make it easier to read and understand. The updated packages are "flightgear", "fgfs-base" and "simgear", all moving to the 2.0.0-1 version. They build these binary packages: flightgear - Flight Gear Flight Simulator fgfs-base - Flight Gear Flight Simulator - base files fgfs-base-models - Flight Gear Flight Simulator - base model files simgear-dev - Simulator Construction Gear -- development files simgear2.0.0 - Simulator Construction Gear -- shared libraries The new packages are,"fgfs-scenery-w130n30" that provides the default FlightGear Scenery, "fgrun", graphical FlightGear Launcher, "fgo", graphical FlightGear Launcher and packages for the FlightGear Aircraft Models, of which there are 13, named fgfs-aircraft-X where X is the name of the aircraft. All these packages appear to be lintian clean. You can find these packages on the Debian Mentors website by following this link http://mentors.debian.net/cgi-bin/sponsor-pkglist?maintainer=cbaines8% 40gmail.com I would be glad if someone uploaded these packages for me. This is the third time I have submitted this request, I understand completely how complex all these packages are, and thus probably why no one has yet sponsored them, but is there another approach I could pursue to get them in to Debian, as would hate to see my work go to waste? Kind regards Christopher Baines On Tue, 2010-08-31 at 16:55 +0100, Chris Baines wrote: > Dear mentors, > > I am looking for a sponsor or many sponsors for my new and updated > FlightGear related packages. I have included a summary of all the > information in one email to make it easier to read and understand. > > The updated packages are "flightgear", "fgfs-base" and "simgear", all > moving to the 2.0.0-1 version. > > They build these binary packages: > flightgear - Flight Gear Flight Simulator > fgfs-base - Flight Gear Flight Simulator - base files > fgfs-base-models - Flight Gear Flight Simulator - base model files > simgear-dev - Simulator Construction Gear -- development files > simgear2.0.0 - Simulator Construction Gear -- shared libraries > > The new packages are,"fgfs-scenery-w130n30" that provides the default > FlightGear Scenery, "fgrun", graphical FlightGear Launcher, "fgo", > graphical FlightGear Launcher and packages > for the FlightGear Aircraft Models, of which there are 13, named > fgfs-aircraft-X where X is the name of the aircraft. > > All these packages appear to be lintian clean. > > You can find these packages on the Debian Mentors website by following > this link > http://mentors.debian.net/cgi-bin/sponsor-pkglist?maintainer=cbaines8% > 40gmail.com > > I would be glad if someone uploaded these packages for me. > > Kind regards > Christopher Baines > > On Tue, 2010-08-17 at 16:14 +0100, Chris Baines wrote: > > Dear mentors, > > > > I am looking for a sponsor or many sponsors for my new and updated > > FlightGear related packages. I have included a summary of all the > > information in one email to make it easier to read and understand. > > > > The updated packages are "flightgear", "fgfs-base" and "simgear", all > > moving to the 2.0.0-1 version. I have however previously sent a seperate > > RFS message for simgear. > > > > They build these binary packages: > > flightgear - Flight Gear Flight Simulator > > fgfs-base - Flight Gear Flight Simulator - base files > > fgfs-base-models - Flight Gear Flight Simulator - base model files > > simgear-dev - Simulator Construction Gear -- development files > > simgear2.0.0 - Simulator Construction Gear -- shared libraries > > > > The new packages are,"fgfs-scenery-w130n30" that provides the default > > FlightGear Scenery, "fgrun", graphical FlightGear Launcher and packages > > for the FlightGear Aircraft Models, of which there are 13, named > > fgfs-aircraft-X where X is the name of the aircraft. > > > > All these packages appear to be lintian clean. > > > > The package can be found on mentors.debian.net: > > - URL: http://mentors.debian.net/debian/pool/main/f/flightgear > > - URL: http://mentors.debian.net/debian/pool/main/f/fgfs-base > > - URL: http://mentors.debian.net/debian/pool/main/s/simgear > > - URL: http://mentors.debian.net/debian/pool/main/f/fgrun > > - URL: http://mentors.debian.net/debian/pool/main/f/fgfs-scenery-w130n30 > > - URL:http://mentors.debian.net/debian/pool/main/f/fgfs-aircraft-777-200 > > - URL: http://mentors.debian.net/debian/pool/main/f/fgfs-aircraft-a6m2 > > - URL: http://mentors.debian.net/debian/pool/main/f/fgfs-aircraft-b1900d > > - URL: http://mentors.debian.net/debian/pool/main/f/fgfs-aircraft-bo105 > > - URL: http://mentors.debian.net/debian/pool/main/f/fgfs-aircraft-c172p > > - URL: > > http://mentors.debian.net/debian/pool/main/f/fgfs-aircraft-citationx > > - URL: http://mentors.debian.net/debian/pool/main/f/fgfs-airc
Re: Advice on an interesting package
Goswin von Brederlow writes: > I'm afraid not, other than have libopensync1 change the library name so > it has libopensync1.so or something. Please no! Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6b13k10@chillida.ipv6.sieglitzhof.net
Re: Doubts in Sigar packaging
On Thu, 16 Sep 2010 19:00:27 +1000 Matthew Palmer wrote: > > > On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: > > > > Why won't you just use `git --describe`? > > > > It produces nice version numbers of the format > > > > -- > > > > (or just when you're packaging a release) > > git --describe is, as far as I can tell, useless for the purpose stated at > the beginning of the thread. Did you miss the bit? I think that makes it ideal provided each release is tagged with its version number. -- TH * http://www.realh.co.uk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100916124447.6a26f...@realh.co.uk
Re: Doubts in Sigar packaging
On Thu, Sep 16, 2010 at 09:59:43AM +0200, Adam Borowski wrote: > On Thu, Sep 16, 2010 at 03:22:31PM +1000, Matthew Palmer wrote: > > On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: > > > Why won't you just use `git --describe`? > > > It produces nice version numbers of the format > > > -- > > > (or just when you're packaging a release) > > > > > > The "start of hash" is a way to disambiguate in the case of multiple > > > branches based on the same release that happen to have the same number > > > of commits past that it; it will be the minimal repo-wide unambiguous > > > hash not shorter than (by default) 7 characters. > > > > You cannot use hashes in your version strings, because you can't assume that > > the "later" version is going to sort after the "earlier" version. If > > - isn't sufficiently unique, you're stuffed. > > You can't compare unversioned branches to other branches anyway. If you > move from one branch to another, you need to label that manually. > > Git's scheme provides enough versioning to handle anything that can be done > in automated way. Indeed, packaging multiple branches stemming from the > same tag may give versions that are not sufficiently sortable, but there's no > way to tell which branch is the "lesser" and which is the "greater" one > without human intervention. So what does this have to do with producing a suffix to put on an upstream version for a Debian package? > > Using a tag, however, is a possibility I hadn't considered. If you merge > > from upstream at relevant points and then tag in your repo, you could use > > 0.x.y~ as the upstream version. Again, README.source would need to > > document this convention, but you can control the content of the tag to make > > it monotonically increasing. > > This would be bad, as your tags won't say anything about the version you > package. Without a mapping between your tags and particular commits, > there's no way to tell what upstream source you refer to. Can't you tell git to retrieve a tag (and all commits therefrom) from a remote repository? If not, what *is* the point of a git tag? > > If it is ambiguous, you can always put that sort of information in the > > Debian > > changelog, or perhaps README.source. > > git --describe doesn't have that pesky requirement. git --describe is, as far as I can tell, useless for the purpose stated at the beginning of the thread. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100916090027.ga4...@hezmatt.org
Re: Doubts in Sigar packaging
On Thu, Sep 16, 2010 at 03:22:31PM +1000, Matthew Palmer wrote: > On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: > > Why won't you just use `git --describe`? > > It produces nice version numbers of the format > > -- > > (or just when you're packaging a release) > > > > The "start of hash" is a way to disambiguate in the case of multiple > > branches based on the same release that happen to have the same number > > of commits past that it; it will be the minimal repo-wide unambiguous > > hash not shorter than (by default) 7 characters. > > You cannot use hashes in your version strings, because you can't assume that > the "later" version is going to sort after the "earlier" version. If > - isn't sufficiently unique, you're stuffed. You can't compare unversioned branches to other branches anyway. If you move from one branch to another, you need to label that manually. Git's scheme provides enough versioning to handle anything that can be done in automated way. Indeed, packaging multiple branches stemming from the same tag may give versions that are not sufficiently sortable, but there's no way to tell which branch is the "lesser" and which is the "greater" one without human intervention. The hash prefix is there just to catch cases where you have some unofficial or cherry-picked patches, or the branch is not exactly what the reader expects. > Using a tag, however, is a possibility I hadn't considered. If you merge > from upstream at relevant points and then tag in your repo, you could use > 0.x.y~ as the upstream version. Again, README.source would need to > document this convention, but you can control the content of the tag to make > it monotonically increasing. This would be bad, as your tags won't say anything about the version you package. Without a mapping between your tags and particular commits, there's no way to tell what upstream source you refer to. > If it is ambiguous, you can always put that sort of information in the Debian > changelog, or perhaps README.source. git --describe doesn't have that pesky requirement. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100916075943.ga16...@angband.pl
