(I'm not sure this will get through to the list, as I am not subscribed, so I am Cc:ing you.) You wrote:
4. Enlist some 'official' distribution maintainers (at the minimum RedHat, Suse, Mandrake, Debian)
Please also include FreeBSD, and feel free to contact me for FreeBSD-related issues, especially concerning this kind of "official" distribution maintainers. Many contributors (including myself) have been providing patches to improve portability or support FreeBSD-specific features which differ from GNU/Linux and the port should be in a decent shape. Thanks, Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
On November 6, 2002 04:10 am, Gerald Pfeifer wrote:
You wrote:
4. Enlist some 'official' distribution maintainers (at the minimum RedHat, Suse, Mandrake, Debian)
Please also include FreeBSD, and feel free to contact me for FreeBSD-related issues, especially concerning this kind of "official" distribution maintainers.
This refers to binary packages. I thought FreeBSD usually download source, is it customary in *BSD world to expect precompiled binaries? -- Dimi.
On Wed, 6 Nov 2002, Dimitrie O. Paun wrote:
This refers to binary packages. I thought FreeBSD usually download source, is it customary in *BSD world to expect precompiled binaries?
Yeah, at least FreeBSD is that user friendly. ;-) ftp://ftp.freebsd.org/pub/FreeBSD/branches/4.0-stable/packages/emulators/wine-2002.08.04.tgz ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-4.7-release/emulators/wine-2002.08.04.tgz (Yes, I know this is not completely up-to-date, but this is mainly due to the way all the packages are built for releases.) Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
On Wed, Nov 06, 2002 at 10:10:59AM +0100, Gerald Pfeifer wrote:
You wrote:
4. Enlist some 'official' distribution maintainers (at the minimum RedHat, Suse, Mandrake, Debian) ... Many contributors (including myself) have been providing patches to improve portability or support FreeBSD-specific features which differ from GNU/Linux and the port should be in a decent shape.
How about providing a distributions directory where the (in)official maintainers for the distributions can just check in whatever they want once they are found/named? cvs allows to give someone write permissions for just a sub-tree, so that might me a comfortable way for the maintainers to provide easy and up to date spec, dep, whatever files/patches for their distros? Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
On November 6, 2002 01:59 pm, Joerg Mayer wrote:
How about providing a distributions directory where the (in)official maintainers for the distributions can just check in whatever they want once they are found/named?
Let's just first find them, that's the hard part. We can figure out where to put the binaries, once we have them around.... :) *That* is not a big problem. -- Dimi.
Dimitrie O. Paun a écrit:
On November 6, 2002 01:59 pm, Joerg Mayer wrote:
How about providing a distributions directory where the (in)official maintainers for the distributions can just check in whatever they want once they are found/named?
Let's just first find them, that's the hard part. We can figure out where to put the binaries, once we have them around.... :) *That* is not a big problem.
I can take the position for RedHat (at least for 8.0). My base system is stock, so there shouldn't be libs problems (at least for those following the official updates). Should the starting point be the latest RH packaged Wine (including their own patches), or start fresh with pristine 20021031? Vincent
On November 7, 2002 10:42 am, Vincent Béron wrote:
I can take the position for RedHat (at least for 8.0). My base system is stock, so there shouldn't be libs problems (at least for those following the official updates).
OK, you're on. BTW, if you compile *C* code on RH8, is it OK on 7.x? I think it should, it's just the C++ ABI that changed, right?
Should the starting point be the latest RH packaged Wine (including their own patches), or start fresh with pristine 20021031?
What patches do they have??? -- Dimi.
Dimitrie O. Paun a écrit:
On November 7, 2002 10:42 am, Vincent Béron wrote:
I can take the position for RedHat (at least for 8.0). My base system is stock, so there shouldn't be libs problems (at least for those following the official updates).
OK, you're on. BTW, if you compile *C* code on RH8, is it OK on 7.x? I think it should, it's just the C++ ABI that changed, right?
Just to be sure: there's no C++ code in Wine at all? If not, yes, it should be ok. But I'll test it anyway :) Just in case, I also have another box with RH 7.1 (I can update it to 7.3), so I could provide both (7.x and 8.0) if needed.
Should the starting point be the latest RH packaged Wine (including their own patches), or start fresh with pristine 20021031?
What patches do they have???
IIRC, it was mostly in the launcher scripts, but I could be wrong. Wait a sec, I'll check exactly what. Vincent
Vincent Béron a écrit:
Dimitrie O. Paun a écrit:
Should the starting point be the latest RH packaged Wine (including their own patches), or start fresh with pristine 20021031?
What patches do they have???
IIRC, it was mostly in the launcher scripts, but I could be wrong. Wait a sec, I'll check exactly what.
- Copying a global config if none exists in $HOME/.wine - Add a destdir to Make.rules.in (for RPM build) - Some modifications to wineshelllink for RH specific things - Bypass winesetup in winelauncher, copy default instead (RH doesn't ship winesetup) - Don't check for __libc_fork in configure.ac (to work on both glibc 2.2 and 2.3?) - Add XSUB.h in winetest.c (fix 'my_perl unknown' error) So, some of them I'll keep, and some not. Then there's where everything is packaged. For that I'll follow what they have now, unless it's not reasonable. Vincent
On November 7, 2002 11:11 am, Vincent Béron wrote:
- Copying a global config if none exists in $HOME/.wine
Hm. Don't know what to think about this one.
- Add a destdir to Make.rules.in (for RPM build)
I thought we don't need one.
- Some modifications to wineshelllink for RH specific things - Bypass winesetup in winelauncher, copy default instead (RH doesn't ship winesetup)
- Don't check for __libc_fork in configure.ac (to work on both glibc 2.2 and 2.3?)
Shouldn't we do something in the base distribution, so we don't require this hack?
- Add XSUB.h in winetest.c (fix 'my_perl unknown' error)
Is this for the Perl test framework? I thought we'll get rid of it.
So, some of them I'll keep, and some not. Then there's where everything is packaged. For that I'll follow what they have now, unless it's not reasonable.
Sounds good. However, if our packages are different from the 'official' RH ones, how are we going to name them? They should be named differently, right? Maybe -w1, -w2, etc. -- Dimi.
On Thu, Nov 07, 2002 at 10:33:50AM -0500, Dimitrie O. Paun wrote:
On November 6, 2002 01:59 pm, Joerg Mayer wrote:
How about providing a distributions directory where the (in)official maintainers for the distributions can just check in whatever they want once they are found/named?
Let's just first find them, that's the hard part. We can figure out where to put the binaries, once we have them around.... :) *That* is not a big problem. I'd suggest a top-level directory like distrib/ or package/. Hmm, or is there some kind of "standard" on naming such directories to be used by the various package scripts ?
Andreas Mohr a écrit:
On Thu, Nov 07, 2002 at 10:33:50AM -0500, Dimitrie O. Paun wrote:
On November 6, 2002 01:59 pm, Joerg Mayer wrote:
How about providing a distributions directory where the (in)official maintainers for the distributions can just check in whatever they want once they are found/named?
Let's just first find them, that's the hard part. We can figure out where to put the binaries, once we have them around.... :) *That* is not a big problem.
I'd suggest a top-level directory like distrib/ or package/. Hmm, or is there some kind of "standard" on naming such directories to be used by the various package scripts ?
Quite a few projects have a debian/ top-level directory. For others, I don't think there's is; I have seen .spec (for RPM) files (or .spec.in) in the root of the project a few times. Vincent
On November 7, 2002 11:08 am, Andreas Mohr wrote:
I'd suggest a top-level directory like distrib/ or package/. Hmm, or is there some kind of "standard" on naming such directories to be used by the various package scripts ?
I don't think this is important, all we need is for Alexandre to let them know where he wants the packages placed (via ftp in a dir, via email, etc.) The important part is to have a process in place like KDE: 1. Alexandre tags the release 2. Creates the source tarballs 3. Notifies the package maintainers 4. Binary package get built 5. Website gets updated with links to src and bins 6. Alexandre sends out the public announcement This may be too complicated for the snapshots we're doing now, but for 0.9/1.0/1.x it's definitely needed IMO to avoid the rush of users to the site, only to find it not updated, without binaries, etc. -- Dimi.
On Thu, Nov 07, 2002 at 11:30:40AM -0500, Dimitrie O. Paun wrote:
I don't think this is important, all we need is for Alexandre to let them know where he wants the packages placed (via ftp in a dir, via email, etc.)
I think there is some misunderstanding as to what I intended with my remark: Maintaining a package for a distro includes a spec file, specific patches (e.g. to paths, configure, makefiles, other build tools specific stuff), Icons, desktop files etc Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
On November 7, 2002 12:03 pm, Joerg Mayer wrote:
I think there is some misunderstanding as to what I intended with my remark: Maintaining a package for a distro includes a spec file, specific patches (e.g. to paths, configure, makefiles, other build tools specific stuff), Icons, desktop files etc
I see. For various reasons, it has been decided some time ago that this should be handled by the packagers themselves, and it should NOT be in the tree. -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
On November 7, 2002 12:03 pm, Joerg Mayer wrote:
I think there is some misunderstanding as to what I intended with my remark: Maintaining a package for a distro includes a spec file, specific patches (e.g. to paths, configure, makefiles, other build tools specific stuff), Icons, desktop files etc
I see. For various reasons, it has been decided some time ago that this should be handled by the packagers themselves, and it should NOT be in the tree.
The spec files etc. should not be in the tree, that's right, but packagers shouldn't need any specific patches to configure or makefiles; if they need that either they are doing something wrong, or there is something broken in Wine that should be fixed. -- Alexandre Julliard julliard(a)winehq.com
On Thu, Nov 07, 2002 at 09:30:10AM -0800, Alexandre Julliard wrote:
The spec files etc. should not be in the tree, that's right
Why shouldn't thy be in the tree? Actually, I prefer to install Software (including self compiled sw) via rpm - it makes it much more comfortable to switch versions and you can be sure that there are no old versions lying around after an update - so I'd be happy if there was a file called suse-8.1.spec or so that I could use to build an rpm from the wine package. ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
On Thu, Nov 07, 2002 at 01:41:43PM -0500, Dimitrie O. Paun wrote:
To avoid proliferation of badly built packages.
Hello? Iff the spec file is bad, then I'd rather fix it then hide it somewhere. I think I've heard that arguement before - was it one for open source perhaps? ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
On November 7, 2002 01:50 pm, Joerg Mayer wrote:
Hello? Iff the spec file is bad, then I'd rather fix it then hide it somewhere. I think I've heard that arguement before - was it one for open source perhaps?
Well, I will not go into this debate, but there are problems in naming packages, etc. If we do have binary packages maintainers, what is the problem? Anyway, don't try to convince me, I can't put them in the tree. :) -- Dimi.
On Thu, Nov 07, 2002 at 07:24:18PM +0100, Joerg Mayer wrote:
On Thu, Nov 07, 2002 at 09:30:10AM -0800, Alexandre Julliard wrote:
The spec files etc. should not be in the tree, that's right
Why shouldn't thy be in the tree? Actually, I prefer to install Software (including self compiled sw) via rpm - it makes it much more comfortable to switch versions and you can be sure that there are no old versions lying around after an update - so I'd be happy if there was a file called suse-8.1.spec or so that I could use to build an rpm from the wine package.
Actually you could download ftp://ftp.suse.com/pub/people/meissner/wine/8.1/wine-*.src.rpm, unpack it, drop in a new tarball and rebuild ... Or just use my monthly builds ;) Ciao, Marcus
On 7 Nov 2002, Alexandre Julliard wrote:
packagers shouldn't need any specific patches to configure or makefiles; if they need that either they are doing something wrong, or there is something broken in Wine that should be fixed.
I mostly agree with you, and you'll notice that the FreeBSD port of Wine at http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/wine/files/ has reduced significantly in size ever since I assumed maintainership, but some issues are not so easy, though erhaps we can resolve them together: --- Make.rules.in.orig Fri Oct 4 06:42:42 2002 +++ Make.rules.in Tue Oct 8 09:46:22 2002 @@ -25,7 +25,7 @@ SHELL = /bin/sh CC = @CC@ CPP = @CPP@ CFLAGS = @CFLAGS@ $(EXTRACFLAGS) -OPTIONS = @OPTIONS@ -D_REENTRANT +OPTIONS = @OPTIONS@ -D_REENTRANT -D_THREAD_SAFE LIBS = @LIBS@ YACC = @YACC@ LEX = @LEX@ Will you accept this if I submit it as a patch or is it wrong? (If so, why?) --- documentation/samples/config Thu Jan 11 01:57:36 2001 +++ documentation/samples/config Sat Jan 13 15:29:39 2001 @@ -146,7 +146,7 @@ WINE REGISTRY Version 2 [serialports] -"Com1" = "/dev/ttyS0" -"Com2" = "/dev/ttyS1" -"Com3" = "/dev/ttyS2" +"Com1" = "/dev/ttyd0" +"Com2" = "/dev/ttyd1" +"Com3" = "/dev/ttyd2" "Com4" = "/dev/modem" How shall we deal with this? --- Makefile.in.orig Fri Aug 2 21:34:21 2002 +++ Makefile.in Mon Aug 5 13:10:16 2002 @@ -91,18 +91,6 @@ install-lib:: $(INSTALLLIBSUBDIRS:%=%/__ install-dev:: $(INSTALLDEVSUBDIRS:%=%/__install__) install-aclocal install:: install-aclocal - -$(LDCONFIG) - @if test -n "`LANG=C $(LDD) $(bindir)/wine|grep not.found`"; \ - then \ - echo "*************************************************" ; \ - echo "*************************************************" ; \ - echo "The installed Wine libraries will not be found!" ; \ - echo "You can either:" ; \ - echo " Add the line '$(libdir)' to /etc/ld.so.conf" ; \ - echo ' export LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(libdir)' ; \ - echo "*************************************************" ; \ - echo "*************************************************" ; \ - fi FreeBSD does not have /etc/ld.so.conf, so this message is not correct there; in fact, no system I am aware of (except my GNU/Linux boxes) has that file. (Apart from that, the FreeBSD port system takes care of invoking LDCONFIG by itself, and calling LDCONFIG as above would remove the entire configuration on most installations.) Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
participants (7)
-
Alexandre Julliard -
Andreas Mohr -
Dimitrie O. Paun -
Gerald Pfeifer -
Joerg Mayer -
Marcus Meissner -
Vincent Béron