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
