[Debian GNUstep maintainers] RFS: GNUstep packages

[Gürkan Sengün]

Hi,

> I have taken over maintainership of the GNUstep core packages
> (gnustep-make, gnustep-base, gnustep-gui, gnustep-back, gnustep-ppd) --
> at least until Eric Heintzmann has more free time again.  I am also
> planning on taking over some other GNUstep packages that have been
> orphaned (e.g. renaissance, pdfkit and its replacement popplerkit).  And
> so I will need a sponsor for these.
> 
> Testing packages for the core packages can be found at:
> http://www.uhoreg.ca/programming/debian/gnustep/

i have test built them on gnu/kfreebsd with the following problems:

check the build logs and packages if you want:

http://gnu.ethz.ch/gnustep-debian-test-build/

- building went fine
- renaissance had a Warning at least
- gnustep-back depends on dpslib which it shouldn't, afaik
  we only support gnustep backart backend
  please document antaialiasing defaults in README.Debian,
  check http://www.linuks.mine.nu/gnustep-settings/
- why do you conflict libgmp?
- it's not the latest gnustep tarballs ->
  i've prepared gorm.app but it won't work with this
  current version: http://gnu.ethz.ch/debian/gorm/
- can you make a tool, say gnustep-fhs on|off that undoes
  what fsdh_gnustep does? or at least log fsdh_gnustep stuff
  in a way it can be undone?
- it didn't really work for me, but maybe that's a problem of 
  my parallel cvs installation into /, with also /etc/GNUstep/GNUstep.conf
  that i didn't allow to be replaced...

also some other packages need a later version of gnustep...

> The packages there are not quite ready for upload yet.  The big change
> for GNUstep is that, as per discussion on debian-policy and
> pkg-gnustep-maintainers, we have moved some files around in order to
> comply with the FHS.  The packages are being tested by the other GNUstep
> Debian maintainers, and if no bugs are found, I will create the final
> versions.  But I figured I would post my RFS now anyways.

myon on irc.gnu.org (see cc:) is willing to help with sponsoring, please
contact him directly. he asks if it makes sense to put this to experimental...

> And I would like to propose that, for Frameworks, we follow a scheme
> like that: a foo.framework that depends on the lib and -dev packages,
> and then lib and -dev packages, as you would regularly do for library
> packages in Debian.

sounds fine to me.

> My plan for now:
> - figure out the best way to maintain an apt repository on alioth (does
>   anyone want to use architectures other than i386 for the repository?)
> - send out a mail to debian-policy to make sure all objections have been
>   answered
> - find a sponsor
> - package very latest upstream (just a ..1 release, and the changes
>   don't seem to make a difference for Debian, but nice to have the very
>   latest anyways)
> - if no blocker bugs found, create the final Debian packages (repackage
>   without the "hc" version, and clean up the changelogs), and coordinate
>   with debian-release for the transition

sounds fine to me as well.

cheers,
Gürkan