On Thu, Oct 30, 2003 at 01:30:40PM +0100, Sven Luther wrote: > On Wed, Oct 29, 2003 at 01:41:53PM -0500, Branden Robinson wrote: > > On Wed, Oct 29, 2003 at 09:18:56AM +0100, Sven Luther wrote: > > > If i go ahead, and send you a patch against 0pre1v4, will you apply it ? > > > > You should know better than to ask for this sort of commitment. I will > > do my best to look it over, but I will not promise to apply a patch > > sight unseen. That would be a stupid policy and a betrayal of my > > efforts to release high-quality packages. > > I understand, but really this is a very orthogonal issue to the rest of > the packages. The actual patch is already commited in the 4.3.0 upstream > branch, and was posted on debian-x (where i am taking this discussion > BTW) almost 6 month ago if i remember well, and is also in Daniel's > tree. It just adds a bunch of : > > InstallDriverSDKNonExecFile(renderproto.h,$(DRIVERSDKINCLUDEDIR)) > > in the Imakefiles which were previously missing, and the > InstallDriverSDKNonExecFile macro only gets called during the make > install.sdk target. This may be conflict with other Imakefile > modifications patches, but only on the patch application level, not on > actual functionality. And as said, it is already in the 4.3.0 bugfix > branch upstream, which you claim to have synced to in a previous > changelog entry, if i remember correctly. Everything you've said here is correct: $(MAKE) install.sdk, should just do what we need, at this juncture. I also had a tree containing this stuff at people/daniel/sdk - I can't remember whether I merged the debian/control stuff or not. Sven, I apologise for this - I've dropped the ball, and forgot to let you know. Unfortunately, I have way more study to do than time, and am starting to fall asleep in the middle of the day. I'm sorry for leaving you in the lurcH. > > > This will include the stuff i already commited to the upstream 4.3.0 > > > bugfix branch, and doesn't in any way influence stuff not related to > > > the SDK (it is just a bunch of SDK related Imakefile fixes). The > > > second part is the needed modification to build a xfree86-driver-sdk > > > package containing a single tarball of the SDK to be unpacked wherever > > > you want. > > > > Debian packages that just ship tarballs to be "unpacked wherever you > > want" seem pretty nasty to me. If the best distribution format for > > something is a .tar.gz, then I don't see why we should ship it as a > > .deb instead. Nevertheless I will attempt to discern whether that's > > really the best approach in this particular case. > > Well, upstream installs it in /usr/X11R6/lib/Server or something such, > and the real use of this package is only to build driver packages with > patches applied or driver packages from CVS or third party driver > sources. I plan to do such a package nextly, altough i don't know if it > will be in time for the sarge release, but this is not important. > > It is thus analog to the foo-source packages, that are used for kernel > modules, or even to the kernel-source package, that is used by the > kernel-patch-xxx-<port> to build port kernel-images too, so i think it > should do ok. > > The user/driver packages just unpacks the tarball, > patches/copies/modifies the driver sources, and launches compilation. > This should provide a nice xfree86-drivers package, which will > divert/whatever the xfree86 drivers and install cleanly. > > I have not yet gone to the practical consideration of that, either i > provide the debian directory in the xfree86-sdk packages directly, or in > the separate package. Maybe i will do it in the separate package for > now, and merge it back later one once we have more experience in it. > > The alternative is naturally to keep everything in > /usr/X11R6/lib/Server, but this will be messy once you build/clean it > multiple times, and you need root privilege anyway, and if you just copy > the stuff, you may as well tarball it. I think there's a small misunderstanding: apparently you need a clean copy of the tree every time you build a new driver. > > > I have not seen you make a single comment on this subject, and my > > > patches went unanswered, beside of your mention that Daniel is working > > > on them. Mea culpa, I only [VAC]ed to -private. Let this be a notice: don't expect any work on any of my previously-claimed TODO items until late December, possibly January. It's open slather on them now. > > DanielS seemed to care about the issue, so I delegated it to him. Why > > should I micromanage something I have delegated? Is it your impression > > that he has lost interest? If so, then the task needs to be reassigned. It needs to be reassigned because I'm on [VAC] and am only here answering an important mail I got an SMS about; I won't have the time until around Dec 15th. > > He did make a commit the other day that I don't fully understand yet, > > telling people to "look for stuff in the attic". I nuked the contents of people/daniel; the "attic" is a CVSism for the place where deleted files go to die. The deleted work included some SDK stuff, and the tree with the Synaptics driver. > > > And you believe in making things more difficult for the DD, so as to > > > separate the elite from the rest, or maybe those that have paid debian > > > jobs from the others ? > > > > I expect people who want me to do something to do a little better than > > issuing a list of demands. The vast majority of my work on XFree86 is > > unpaid volunteer time, so I really don't know what you hope to achieve > > by casting vague asperions about "paid Debian jobs" and "elites". > > Well, you are discriminating the quality of the debian developer by the > amount of time they can pass on reading mailing list. You and me clearly > can do a lot of reading, but this is not the case for everyone, and > there is no true reason for making it hard on them on purpose. Speaking of this, if there's any part of this discussion you really want me to see, CC it to me. I only saw this because it rolled in just as I was watching for the aforementioned message I was SMSed about to arrive. Cheers, Daniel-on-study-exam-and-holiday-VAC -- Daniel Stone <daniel@fooishbar.org> http://www.debian.org - http://www.kde.org - http://www.freedesktop.org "What's next? People turning up on my doorstep, observing that the lack of doorbell is likely to confuse people and hence removing my front door?" -- David Woodhouse on usability efforts, Advogato
Attachment:
pgpg5QZvL1sMd.pgp
Description: PGP signature