Re: gnome-randr-applet and Xfree86 4.3.0 ...
On Thu, Apr 03, 2003 at 11:21:36PM +1000, Daniel Stone wrote:
> On Thu, Apr 03, 2003 at 02:33:40PM +0200, Sven Luther scrawled:
> > On Thu, Apr 03, 2003 at 08:10:09PM +1000, Daniel Stone wrote:
> > > i386, powerpc, alpha - these are the architectures I have access to.
> > > sparc and ia64 also usually get built, but I don't have direct access to
> > > them. As I'm not a developer, I can't use d.o machines, either. alpha
> >
> > A, ... i didn't know that, this is rather a surprise, ... I suppose
> > branden's X packages are also built by hand, are they not, or do the
> > autobuilder build them ?
>
> No, autobuilders build them automatically, because they're uploaded to
> sid. If he needs to test building or a patch or such, porters do that,
> however.
>
> > What are your needs for the other arches ? Do we have a status report
> > somewhere or something such ?
>
> Someone to build it, check it builds, send me the output of (cd
> debian/tmp && find ./ -type f | sed -e 's/^..//;'), wait for
> *.files.$(ARCH) files and an updated MANIFEST, build *that*, and see if
> it works. Not a huge amount of work, only if patches are needed for that
> particular architectures.
>
> > > hasn't built lately due to a gzip bug, but aj and asuffield are banging
> > > out a patch on IRC right now.
> >
> > Ok, so 3 arches are building. I have access to a sparc box, altough not
> > all the time, it is currently disconnected from the net and i will have
> > access to it only next week. I also have plans to have access to a mips
> > box, but it only has a small disk.
>
> 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.
> > > Core stuff, sure. But what about something that, say, includes Xrandr
> > > support in a ./configure check? What if that check gets tripped in 4.3
> > > and it then fails in 4.2? There's a lot more scenarios, too, if you
> > > stopped to have a think about it. Sure, libX11 hasn't bumped soname, but
> > > a great deal of other things have.
> >
> > What's the problem with that ? If a library needs Xrandr, then it
> > depends and build depends on xlibs (>> 4.3.0) and no problem shall
> > appear. I have done so by using a shlibs override, but this could even
> > be included in the upstream dpkg-shlibs or whatever the name of the tool
> > is.
>
> 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 ?
> > > Not just that. New APIs. Lots of them.
> >
> > As said, our dependencies and build dependencies can handle that.
>
> 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.
> > > No, it's not public. "Do you think I should apply the IPv6 patch for
> > > -0ds1? Looks quite clean to me and appears to work", (the reply was:
> > > "I'm uneasy about introducing such a radical new feature in -1", FWIW),
> > > isn't interesting to debian-x, it's just spam.
> >
> > And all the bug merging and such are not ?
>
> 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.
> > Seriously, if you don't communicate, it seems as an opaque stuff and
> > don't invite help, not that many people will join i know, but still. If
> > it is too much for debian-x, then maybe a debian-x-4.3.0 or
> > debian-x-devel mailing list ?
>
> 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.
> I'll say it again: what we do *not* need more of is more invective on
> mailing lists. We need more people to check and rediff patches, to try
> and chase down old bugs, to track down user problems, to fix bugs. If
> you want to help, there's a very clear way you can: look in the BTS,
> find a bug, fix it, send the fix to the BTS. If there's no bug filed for
> your problem, file one - "Tags: patch". It's quite simple.
:)))
> 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.
> 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.
> Well, as I said, we don't need more mailing lists, or to have the
> development model changed. In fact, for a team of 3, each working on
> different parts with different aims, and none of us working anything
> near full-time on it, we're doing remarkably well. What *is* needed, on
> the other hand, is packagers, bug sweepers, patch people.
Yes, and thanks for doing it.
> > > I have enough things in my plate, both paid and unpaid, to consume about
> > > four times the time I currently have available. I don't want to take on
> > > the responsibility of yet more upstream stuff.
> >
> > No problem, i didn't think you should, i think it would be the natural
> > place for one of the debian X strike force members though.
>
> Not necessarily; I see packaging and upstream as separate, although our
> porting situation does blur the lines a bit.
Yes.
> > > Although I wasn't there at the time, I've been told that Mike just made
> > > a mistake, not terribly much to it.
> >
> > As i understand it, he commited a bunch of untested stuff the day before
> > the freeze, which broke things, needed work for undoing it, and delayed
> > the release.
>
> 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.
> > > And our packages *are* IMHO the best quality, yes. That's why I don't
> > > want to degrade that reputation by uploading packages I don't feel are
> > > ready, to sid. Or packages that don't run on all our architectures. Your
> > > two goals are conflicting: have the best packages, ergo get commit
> > > access, and pump everything in before it's released.
> >
> > ???
>
> 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.
> > > I'll say it again: hot air on mailing lists isn't in the least helpful.
> > > Contributions are.
> >
> > Sure, but keeping an archive of the problems going on helps one to know
> > in what capacity he can get involved or if there is no need, or
> > whatever.
>
> 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 ?
> > > Want to help?
> >
> > Ok tell me, what do you need help with for the 4.3.0 packages ? I will
> > try to build them this WE, and make myself familiar with the build
> > system, and then we will see. But like said, i don't really have time
> > right now, but this may change.
>
> 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 ?
BTW, the *BSD ports should work relatively ok, should they not, many of
the X upstream use *BSD as developpment plateform.
> That sort of thing. Nothing sexy, I'm afraid. Repetitive, long,
> frustrating, menial, and boring. The stuff that needs to get done.
Yes, sure.
Friendly,
Sven Luther
>
> --
> Daniel Stone <dstone@trinity.unimelb.edu.au>
> Developer, Trinity College, University of Melbourne
Reply to: