[Debian GNUstep maintainers] RFS: GNUstep packages
Gürkan Sengün
gurkan at linuks.mine.nu
Fri Dec 9 11:34:30 UTC 2005
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
More information about the pkg-GNUstep-maintainers
mailing list