On Sun, 20 Jun 2004 23:13:11 +0200, Ivan wrote:
> A user recently accidentally tried the Mandrake RPM on Red Hat and it wouldn't
> even run notepad.
> I build with no patches, no special stuff, just configure/make depend/make/make
> install
Yes, that's why we've written tools like apbuild, written
> I've tried binary wine packages on a few occasions
> and *always* had major problems. Wine, and more importantly the things
A user recently accidentally tried the Mandrake RPM on Red Hat and it wouldn't
even run notepad.
I build with no patches, no special stuff, just configure/make depend/make
On Sat, Jun 19, 2004 at 03:01:31PM -0400, Geoff Thorpe wrote:
> On June 19, 2004 01:37 pm, Alexandre Julliard wrote:
> > > way towards cutting the number of non-developers building from source
> > > down to zero.
> >
> > I don't see why that should be a goal at all. You guys need to get rid
> > of
On Sun, 20 Jun 2004 04:02:12 +0200, Ivan wrote:
> I have no idea, but X11drv doesn't initialize properly. This has been reported
> by users, I don't have x.org myself.
OK, that sounds like a bug in Wine rather than anything packaging related.
We should track it down and fix it.
More likely it's s
> Why is that?
Adam Schreiber may know as slackware he build 2 binaries for slack users using
xfree86 and x.org, you can reach him at shipssadam -at - clemson.edu
Ivan.
> Why is that?
I have no idea, but X11drv doesn't initialize properly. This has been reported
by users, I don't have x.org myself.
Ivan.
> Maybe, but for example Mandrake users won't get wine listed in the "remove
> software" utility, and that will be confusing
> Solving that problem is a desktop issue, I've done a bit of work on it but
nothing has got into mainstream yet.
OK, but in the mean time I still don't see how one binary c
On June 19, 2004 03:24 pm, Mike Hearn wrote:
> On Sat, 19 Jun 2004 15:01:31 -0400, Geoff Thorpe wrote:
> > Excellent, I'm glad this was said. One only has to look at the swing
> > away from binary-distributions as a case in point - people *want* to
> > eliminate unknown layers of patches, packaging
On Sun, 20 Jun 2004 00:35:06 +0200, Ivan wrote:
> About building one binary of wine for all distros, it's interesting to notice
> that one the same distro you need different binaries depending on if you're
> using xfree86 or x.org.
Why is that?
On Sun, 2004-06-20 at 01:02 +0200, Ivan wrote:
> And why shouldn't we have the wine programs in the menu?
We should but that's not a packaging problem, that's a matter of waiting
for XDG menus to become prevalent then teaching wineshelllink how to use
libxslt and apply transforms to the menu defin
> Anyway, Wine doesn't have any menu
> integration.
And why shouldn't we have the wine programs in the menu?
> Compiling it as i586 or i686 should be fine, very few people use
> processors old enough to barf on it
Sure.
> That's what apbuild solves. It lets you compile for glibc 2.2 on a 2.3
> sy
On Sun, 2004-06-20 at 00:12 +0200, Ivan wrote:
> This isn't easy to do, and it means you have to A) Leave out some features (mime
> types, menus, that most distros handle in a different way) or B) package
> menu/mime stuff for all distros, meaning the user downloads a big binary but
> will only nee
About building one binary of wine for all distros, it's interesting to notice
that one the same distro you need different binaries depending on if you're
using xfree86 or x.org.
Ivan.
> (a) and (b) can be solved by WineHQ providing its own distro-neutral, run
> anywhere binary packages.
This isn't easy to do, and it means you have to A) Leave out some features (mime
types, menus, that most distros handle in a different way) or B) package
menu/mime stuff for all distros, meaning
On Sat, 19 Jun 2004 15:01:31 -0400, Geoff Thorpe wrote:
> Excellent, I'm glad this was said. One only has to look at the swing away
> from binary-distributions as a case in point - people *want* to eliminate
> unknown layers of patches, packaging, and divergence from the "real"
> thing.
The on
On June 19, 2004 01:37 pm, Alexandre Julliard wrote:
> > way towards cutting the number of non-developers building from source
> > down to zero.
>
> I don't see why that should be a goal at all. You guys need to get rid
> of the mindset that building from source is some 1337 thing that mere
> morta
Mike Hearn <[EMAIL PROTECTED]> writes:
> Is there a reason that can't be dlopened too? relaytool makes it much less
> hassle to write dlopened code.
libicu can't be dlopened thanks to their idiotic versioning scheme.
>> f) They want to try a patch that someone sent them.
>
> How often does that
On Sat, Jun 19, 2004 at 10:37:54AM -0700, Alexandre Julliard wrote:
> users build without having to fight the autoconf tools. It's for the
> same reason that we have wineinstall. Of course I'm all for improving
> the binary packages, but it doesn't avoid the need to also support
> source builds.
S
On Sat, 19 Jun 2004 10:37:54 -0700, Alexandre Julliard wrote:
> d) They need something that isn't part of the standard packages (for
>instance BiDi support).
Is there a reason that can't be dlopened too? relaytool makes it much less
hassle to write dlopened code.
> e) They want to report a c
Mike Hearn <[EMAIL PROTECTED]> writes:
> a) There is no binary package for their distribution. How common is this?
> I don't know but I've encountered a startling number of newbies that use
> off-the-wall distros like Ark/College Linux etc.
>
> b) There is but it's out of date or broken. This is w
On Sat, 2004-06-19 at 09:54 -0400, Dimitrie O. Paun wrote:
> I don't think we're doing too badly with the current packages -- over
> 85% of people go for them. Having a distro-neutral binary packages
> would be good, and it may shave off another 5% or so of the people
> who do go for source downloa
> (a) and (b) can be solved by WineHQ providing its own distro-neutral, run
> anywhere binary packages. This isn't hard as Wine is generally excellent
> at running on different peoples machines from the same binaries - after
> all, CodeWeavers need it. I think a nice installer for correctly built
>
On Fri, 18 Jun 2004 17:05:49 -0700, Alexandre Julliard wrote:
> Maybe Linux users in general know how to run configure (though I doubt
> that), but that's definitely not true for Wine users IMO; most of them
> come straight from Windows, and Wine is often the first time ever they
> build something
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Well, as I've tried to explain, when I see stuff like this,
> I'm always left with lingering questions: if I run the
> standard method (configure;make) that I like, I'm wondering
> wether I've missed something important. Are the bugs I'm
> seeing ca
> configure or LD_LIBRARY_PATH or whatever. Maybe you don't have
> clueless users asking you how to build Wine, but I get quite a bit of
> them; and being able to tell them "just run tools/wineinstall" saves
> me a lot of grief.
That's a fair argument, and I can understand that. If it saves you
ti
> I want to be able to say to a user who reported a bug "please try latest CVS
> and confirm that it is fixed" without having to tell them about
> configure or LD_LIBRARY_PATH or whatever
If they've reported a bug, and you've told them to try the CVS, then it's not a
configuration problem, so confi
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> I don't think we should do that. First of all, none of the problems
> mentioned are wine specific, and I don't think we need to try to
> fix them like that. Second, as I have already argued, it seems most
> of our builders from source are already p
> wineinstall is not out of date, it still works fine, I don't see any
> reason to remove it from the doc.
I see no reason to leave it, it's now as if it did anything essential for wine.
Usually things are first removed from wine, and then from the documentation,
this causes an afoul lot of confus
On Fri, Jun 18, 2004 at 07:26:23PM -0400, Vincent Béron wrote:
> Le ven 18/06/2004 à 17:44, Alexandre Julliard a écrit :
> > That's easy, they will complain about the thing wineinstall takes care
> > of, like not having write access to the build tree, conflicts with the
> > installed rpm, missing l
Le ven 18/06/2004 à 17:44, Alexandre Julliard a écrit :
> "Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
>
> > Let's remove it and see if people complain, and why they complain.
> > We are likely to find real problems that need fixing anyway.
>
> That's easy, they will complain about the thing wi
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Let's remove it and see if people complain, and why they complain.
> We are likely to find real problems that need fixing anyway.
That's easy, they will complain about the thing wineinstall takes care
of, like not having write access to the build t
On Fri, Jun 18, 2004 at 12:22:10PM -0700, Alexandre Julliard wrote:
> I don't see why we have to remove it at all. We have to remove most of
> its contents, sure, but even if all it does is wrap "configure;make"
> with some user-friendly messages it has some value IMO.
To be honest, I would be ver
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> It's true, wineinstall works OK, but AFAIK we've decided to remove
> it sooner rather then later, and I guess now it's a good enough time
> (given that it doesn't do anything interesting anymore). So looking into
> the future, wineinstall is depreca
On Fri, Jun 18, 2004 at 11:26:33AM -0700, Alexandre Julliard wrote:
> wineinstall is not out of date, it still works fine, I don't see any
> reason to remove it from the doc.
It's true, wineinstall works OK, but AFAIK we've decided to remove
it sooner rather then later, and I guess now it's a good
"Ivan" <[EMAIL PROTECTED]> writes:
> This patch has been written thinking that a) it's better to have no doc than an
> out of date one and b) most of the stuff that's commented out can be easily
> re-written before the next release (I have school holidays until september so I
> have lots of time t
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Since these are internal use only, let's not document them
> for external people, it will just cause problems.
I disagree, it's much better to have documentation stating that they
are internal than not to have any documentation at all.
--
Alexand
36 matches
Mail list logo
