On Thu, Apr 03, 2003 at 03:44:28PM +0200, Sven Luther scrawled:
> On Thu, Apr 03, 2003 at 11:21:36PM +1000, Daniel Stone wrote:
> > I've already got SPARC under control - it's ported, and there's a box
> > with a porter already I can use to build the debs. Right now, hppa, sh3,
> > sh4, m68k, mips, mipsel, *bsd-*, and maybe another I've forgotten, are
> > completely un-ported. s390 is in the process of porting.
>
> Mmm, i have a m68k machine, it is a 68040@40Mhz only though, and it will
> take ages to build X on such a box. I can do it though if it is needed,
> i have to revive the box first though, and see if i have enough disk
> space. I could try an NFS mount on a serial null modem link though.
If you'd like, that'd be great.
> > Except that it will be uninstallable and unbuildable for
> > everything/everyone that doesn't have 4.3. If you look at my
> > xlibs.shlibs, you'll notice that I've already done all the necessary
> > work here.
>
> And ? What is the problem with that ? They are unbuildable because your
> package are not in the archive. They are uninstallable on people not
> using 4.3, but that is ok, since if you don't run 4.3, it would be
> meaningless to use them ... A, i suppose you mean the problem for
> package which can be built with or without 4.3 support ?
*sigh*. Imagine this.
Qt has a compile-time ./configure check for Xrandr. If it finds it, it
enables a few Xrandr related features, and links with Xrandr.
Qt gets built with 4.3 and uploaded. Now you have to have 4.3 to run any
Qt app.
Seeing as the Qt guys have accepted a patch to do stuff with Xrandr for
3.2, that's really not at all far-fetched.
> > End result: people with 4.2.1 get shut out.
>
> Why, if a package cannot build with 4.2.1, then a user running 4.2.1
> can take no benefit from it, and as thus has no need to install it. That
> said, i guess you are speaking about packages that can support either
> 4.3 or 4.2.1, and if we enable the 4.3 features, they would not work in
> with 4.2.1. This would be problematic, yes, but are there many such
> packages.
Again, note the difference between "can't build with 4.2.1" and "is
better when built with 4.3".
Yes, that's what I'm speaking about, and there's a few of those.
> > The only thing I do with bugs is what you see with my BTS handling,
> > which is clearly visible through the BTS itself. Everything myself and
> > Branden do is visible through our changelogs; mine are certainly quite
> > verbose.
>
> Err, i was just saying that the result of the control@bugs.debian.org
> were rather anoying, and maybe much more spamlike than any discution
> between you and Branden on the subject of the XFree86 packages.
*shrug*.
> > Considering there are only three of us actually doing Debian X
> > development, it would be quite a small list, really. As I said,
> > discussion is not the problem. The problem is that there are only three
> > people out there who are willing to/have actually done the work
> > required. That's not a large number, when you consider the demands of
> > XFree86 packaging.
>
> Yes, but if people have a chance to lurk in in such conversation, they
> may see that they actually can do things, and step in and help. The idea
> is the same overall, was one of the debian developper requisite not to
> first lurk on debian-devel for a time, and then start more active work.
> Sure you might get your share of trolls and misguided users though, but
> a read-only list or a regular digest posting may help out with this.
People: You *can* actually do things!
Jump in the BTS and help.
> > The "development model" you cite isn't closed at all. Hell, jump on IRC
> > and you'll see half of it in public. My mails to Branden are generally
>
> Not everyone is on IRC, and even if he is, not every one is there at the
> same time you are.
I run my IRC client in screen(1).
> > large, running through large swathes of patches, asking his opinion on
> > them, and every now and then, posing a few questions on how to do
> > something or rather, as well as a bit of personal communication.
> >
> > I assure you it would bore you to tears. Really.
>
> Yes, probably, but then i can just skip it if need be, and come to it
> later one if needed.
So it's more work for all of us, for no advantage?
> > Fair enough. However, if he was quite inexperienced at the time,
> > pointing him in the right direction is more productive than shutting him
> > out altogether.
>
> I also don't know of the details more than what was aired in the xforum
> list. I don't think it was just inexperience either, but i really cannot
> say.
I know Mike well enough to say that there's absolutely no way it
would've been motivated out of either malice or desire to get RedHat
ahead.
> > Well, you're saying that we have the best quality packages, and that
> > they're very good. I agree with this.
> >
> > However, you're also saying that we should focus on unreleased CVS
> > source, instead of what's in sid. This would drag our packaging down
> > quite badly, by not having the released stuff, guaranteed good quality.
> >
> > You see what I'm getting at?
>
> Yes and no. the problem is that we are not working with the last
> released version and trying to make it stable, ported, etc, but the one
> before that, and released more than a year ago.
Yes, but you keep missing my point.
Say we said "righto, 4.2.1 sucks, let's work on porting 4.3". For
however many months, 4.3 would be in progress porting (as it was, FWIW),
and 4.2.1 would languish in sid, unmaintained.
So, because of this porting, the version we have in sid becomes
unmaintained and bugs don't get fixed. So, we never have any good
packages, because .0-1 packages aren't likely to be the most stable
packages anyone's ever come up with.
> > They're not really problems as such, more just seeking Branden's opinion
> > on things. As I'm going to hand over to him, there's no point in me
> > doing things the way I like it, if it's just going to be more work for
> > him. It's almost entirely consisted of deciding when to start work on
> > splitting some packages, and which patches to merge and which to delay.
> > Trust me, uninteresting.
>
> But suppose i am going to do 4.3.99 packages or whatever tomorrow, i
> will most probably go and ask Branden the exact same questions, will i
> not ?
Well, if you use my 4.3 packages as a basis for 4.3.99 you probably
won't need to, no.
> > Porting - m68k, hppa, mips, mipsel, {free,net}bsd-*. Merging Michel
> > Daenzer's radeon-ddc patch - it doesn't apply at all cleanly.
>
> I think Mark (from upstream) will be looking at Michel's patches, and it
> will no more be needed at upstream. Why does Michel's patch not apply
> cleanly ? Because he diffed them against his DRI build or something such ?
As he said earlier, it was against .99.2 or such, so doesn't apply to
4.3.0 with 31,000 lines of patches against it already.
> BTW, the *BSD ports should work relatively ok, should they not, many of
> the X upstream use *BSD as developpment plateform.
Well, I've had to pull back patches from both HEAD and branch which is
apparently essential to get *BSD working.
--
Daniel Stone <dstone@trinity.unimelb.edu.au>
Developer, Trinity College, University of Melbourne
Attachment:
pgp8AC3n86udr.pgp
Description: PGP signature