Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 49455 - Gentoo X11 packaging lacking most basic Q/A?
Summary: Gentoo X11 packaging lacking most basic Q/A?
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Gentoo X packagers
Depends on:
Reported: 2004-04-29 20:17 UTC by Mork N. Mindy
Modified: 2004-06-23 18:06 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Mork N. Mindy 2004-04-29 20:17:35 UTC
OK, to put it short--emerged x11-base/xorg-x11 and found 'Makefile.orig.rej' in
in '$S/xc'. Failed patch? No. It's *created* by a patch in the patch set inself! Not
only in the latest patch set, but, get this, it's also in the very first patch set.
Does anyone actually review these patches?

Further, xinit implicitely depends on xvt due to a patch apparently "borrowed" from
Redhat that never made sense--just like other breakage coming from RedHat. Mentioned
at least 3 times in Gentoo Bugzilla alone. But still in xorg-x11-6.7.0-patches-0.6.
Does anyone really review X11 patches?

There's plenty other issues with patches I did not fully investigate yet. X11 compatiblility
and Q/A level at a new low?

    -- Mark
Comment 1 Donnie Berkholz (RETIRED) gentoo-dev 2004-05-02 10:17:44 UTC
Yes, they are reviewed as time permits. But you must realize a few things: (1) there are many critical breakages that must be fixed before there is free time to sit around looking for things that may or may not be broken, and (2) we are all volunteers here and don't have infinite amounts of time for Gentoo.

I'm aware of the xvt issue, but as I mentioned above, my time isn't devoted solely to Gentoo -- I've had university finals and various trips around the country to deal with over the past few weeks. In comparison with other breakages  I've had time to work with, it's trivial. As is creation of a .rej file as long as it isn't causing something else to break. Perhaps someone forgot to delete it after manually fixing a patch, I'm not in a situation to examine until later today.

Your apparent negative, skeptical attitude isn't really a motivating factor for volunteers like me. Instead, a positive, helpful attitude toward fixing these issues makes me much happier and more likely to investigate them over the other 100+ bugs open on X-related issues.

Also, I'd like to point out that I intended xorg-x11 to be in ~arch right now (i.e., in testing). Unfortunately AMD64 was forced to prematurely stable it because of a security issue in another package -- not sure whether you're an AMD64 user.

Instead of just telling us about the problem, why don't you take the time to contribute fixes too? It would be greatly appreciated in a community-based distribution such as Gentoo. We can use all the help you can give us.

Thanks for reading that soliloquy. =)
Comment 2 Seemant Kulleen (RETIRED) gentoo-dev 2004-05-02 10:42:05 UTC
Honestly, "Mork", you hide behind an anonymous alias and criticise people.  If you have the time to criticise, you have the time to anonymously help as well.  Grow up, already.
Comment 3 Mork N. Mindy 2004-05-06 18:00:20 UTC
Mr. Seemant,

Please show me where I criticized people. All I did is file a bug report about a Q/A pro-
blem in Gentoo Linux. Not something I'm making up, but something based in reality, something
easily backed up with evidence. A very serious bug as it seems.

Example: xorg-x11-6.7.0-patches-* contains patches against non-existing *.rej and *.orig
files. First appeared in version 0.1, still present in version 0.6. Sorry, but looks
like *no reviewing at all* to me, or how can you miss something as obvious as this? A
simple text editor with text search capability allows to jump from file to file, even
from hunk to hunk, forwards and backwards, by means of a single keypress. More advanced
editors with .patch modes allow for easy post processing, as do tools specifically
designed for that purpose.
Estimated time to fix: < 30 secs.

Example: If, of all the sources available, you decide to go with RedHat patches, please
first divide them into two categories first, (1)those that fix real bugs, (2)those that
only exist to add annoyances nobody asked for. If Mr. H. decides to disable a particular
X server config option because he thinks RedHat users are too stupid to use it pro-
perly -- his business. Most people, however, think of it as a valuable debugging aid.
There is not a single problem report in Gentoo's bug tracker -- yet the patch is blindly
applied in Gentoo, xfree stable and xorg. Sorry, but looks to me nobody really knows
what every single patch is for.

Example: One patch makes the X server look for a free virtual console not below VT7. But
at the same time you still use that horrible "a" runlevel kludge in your xdm script with
all of its shortcomings. To see just one of the problems, type "/etc/init.d/xdm stop".
X will die, restart, die again. Up to 40 secs lost on slower machines.
Sorry, but looks to me you're fighting the same problem with two weapons at the same time,
because nobody really knows what this patch is for. More importantly, both weapons are
unnecessary if X is configured properly and the second one limits users to six virtual
consoles. Xfree stable and xorg.

Example: You're patching xinit so it attempts to start xvt for its default client. But
X11 does not depend on xvt so xvt is not installed on most users' machines. A quick bug-
zilla search reveals you knew about it long before the xorg fork even existed. Yet the
patch is still applied in xorg. Sorry, but looks to me nobody really knows where this is
coming from and how to handle patches, especially considering somebody in bugzilla 
already gave you the answer.
Estimated time to fix: < 30 secs.

Example: xfree installs cursors in /usr/share/cursors/xfree, xorg installs cursors in
/usr/share/cursors/xorg. Two non-standard places so you have to patch every single
ebuild that either installs cursors or needs to know where they are. Means users need
to rebuild all of them every time they switch between xfree and xorg. Means you have to
maintain your own patches for all of these packages forever because these locations are
non-standard and different from what everybody else is using. Means you are breaking
third-party software and force users to patch programs they compile outside of portage.

As you can see, all valid concerns, and I could go on for ever. But since you decided
you WONTFIX it, I don't really know what the point would be. What worries me even more
is most of these concerns already existed last time I tried Gentoo 18 months ago. Looks
like the basic philosophy hasn't change a bit -- when all other people who contribute
to free software do it because it's fun and to further their carreer, in Gentoo it's
still the old "It's free so be happy with what you got and please don't bother us" 

You say you don't feel motivated to fix your own mistakes if you don't like the person
reporting it even if it affects ALL users and it takes less than a minute to fix, but
think of it this way: (1)you expect users to trust Gentoo with their valuable data.
Think what would happen if kernel packagers would show that same attitude. Not that far-
fetched since X servers are running with full root priveleges and one single mistake can
be fatal. More Q/A is definetely in order. (2)many of the "+100" open bugs don't show up
in vanilla X compiled with vanilla gcc/libc. (3)potential contributors don't feel
motivated to do anything getting responses like that, also considering many of the
kludges in Gentoo as a whole are to work around other kludges in ebuilds long gone in
portage, or are just plain wrong and incompatible. Maybe I'll try Gentoo in another 
18 months, maybe not.
Comment 4 Seemant Kulleen (RETIRED) gentoo-dev 2004-05-06 18:11:27 UTC
now, *that* is more like it Mr. N. Mindy
looks like you are capable of reviewing the patches and offering fixes.

your most recent post suggests you're able to do so with civility as well, which is appreciated.
Comment 5 Donnie Berkholz (RETIRED) gentoo-dev 2004-05-06 19:27:28 UTC
You're calling for more QA, which is a good thing. But where's it supposed to come from, seriously? I spend all the time I possibly can working with Gentoo -- I can't pull more out of thin air. 

The answer I see is finding more people. I alluded to this in my previous post, but X recruits are hard to come by, especially those with plenty of free time. You're more than welcome to continue helping out with specific bugs or any other issues you see.

Much of the current patchset is inherited from older versions, and there was a pretty large lack of documentation. I see where you're coming from there and I'm trying to improve that. For example, see the PatchChangeLog in the patch tarball. I'd like to gradually build up a complete list of every patch and its purpose, which would involve auditing all of them as you desire, but again, this is my spare time and there's a limit to it.

I hope that explains some of your concerns, although it doesn't solve them.

I'd really like to see you contributing patches to fix the various issues you see, or at least referring to specific patches by name.

On a side note, your estimates are a little skewed. A change to one patch takes a few steps:
1) Edit the patch
2) Make a new tarball
3) Edit the ebuild appropriately to deal with the new tarball, including any custom patch exclusions
4) Test an unpack to be sure it's working, then follow that up with a full build and test of functionality

That sounds like more than 30 seconds to me.
Comment 6 MaN w1tHoUt SoCkS 2004-05-16 17:27:15 UTC
I can confirm this bug. But the problem is not that there aren't any good
people, or as you call them, X recruits, out there. The problem is Gentoo
is just not attractive enough.

Problem: Professional software developers can't do their development work under
Gentoo. I think very few will reboot into Gentoo after their day to day work
just to try and help squash problems they know in advance will never get fixed.
X is a major factor here--very ancient bugs, like consistant xmodmap or
xresource or ssh-agent handling accross all supported DMs, are constantly ignored.
It "just works" out of the box everywhere else. Meanwhile X11 devs seem to have
plenty of time to make Gentoo more and more incompatible with other Linuxes with
every new X rev. Let me also add binutils and major base system components to
Mork's list.

Problem: People are required to sign away their souls to Gentoo Technologies, Inc. 
just to be allowed to help out for free in their spare time? Tell me if I'm
wrong, but in FreeBSD, Debian, etc., copyright to Gentoo's equivalent of ebuilds
stays with the original writer and their contributors. Professional programmers
often times are not allowed to sign additional contracts.

Problem: <security@g.o> people are asking problem reporters for patches? Now
that's really scary. Everywhere else it's the security team who codes patches
and backports them to all supported versions and passes them to upstream
developers. Very bad PR! and scares away potential new devs.

Problem: How often do you read "99% of our developers dont know how to do X" or
"99.1% of our developers don't even know how Y works" in public forums? Very bad
PR! and cares away potential new devs.

Problem: How often do you read "Does version-(n+1) fix this?" in bugzilla. Heck,
do people writing these comments even do some basic testing? If the problem in
question is caused by the way Gentoo does things then of course it's not fixed
in new versions! Very bad PR! and scares away potential new devs.

Problem: How often do you see ebuild files newer than the last Changelog entry,
or even Manifest? In one case the respective ebuild maintainer even added a
comment in the ebuild asking the person constantly violating policies to stop
doing that. Ebuild is still last modified by that person WITHOUT a Changelog
entry. Gives the impression everybody can mess with everything and get away with
it. Very bad PR! and scares away potential new devs.

I also could go on forever, but I'm tired already. But think about it, if even
some of these problems would not exist, there could be more "X recruits" than
you'll ever need.
Comment 7 Jon Portnoy (RETIRED) gentoo-dev 2004-05-16 18:04:10 UTC
GNU and Debian at least have any volunteers sign copyright over. Many other less prominent projects also do. This is a legal necessity; please see for more information. Nobody has to "sign away their souls" -- you simply have to assign copyright to Gentoo for anything committed to the tree. If your employer has a "sign away souls" contract that gives them intellectual property rights to anything you produce outside of work, please do not submit code; it would put us in a very bad legal position.

Tons of professional software developers work in Gentoo, so frankly I have absolutely no idea what you're talking about. I also have no idea what you're talking about wrt security bugs (where'd that happen?)

Do you really expect every (we have 200+) dev to know everything about every package?

Why do you have an issue with developers asking users if a new version solved their problem or not? We haven't yet figured out mind-reading, unfortunately.

I don't understand where you're coming from on most of those points.
Comment 8 MaN w1tHoUt SoCkS 2004-05-23 16:49:12 UTC
Everybody knows about <>.
But where's the equivalent on <> for example?

It's simple, if a piece of work is licensed under terms of GPL, that piece of
work is GPLed for all eternity. NOBODY can take that away. Not the copyright
holder(s), not anybody else. Nobody but all copyright holders can release the
same or future versions under a different license, but that does not matter as
GPLed version you have will remain GPL forever and you can do whatever you want
with it as permitted by GPL. So why you need copyright? Why you not want dual
copyright? Since you claim you never release signed-over code under a different
license, it simple doesn't make sense. You only limit coders in what they can
(not) do with their own work.
(if that IS what that document is really trying to say, wording is really really
vague and un-scientiffic) (just realised how many Gentoo developers are under age,
hope you got their parents' signature too..wouldn't be much worth without it)

Or from the other side, xfree and some base system components suffer from
acute maintainer shortage. <> is a real goldmine here as well.
Example problem: xmodmap and xdefaults. Never worked in Gentoo in a standard way
but reported as bugs numerous times. Assigned sometimes to kde, sometimes to
xfree. In kde always closed unfixed. Open in xfree in 1 or 2 cases but without
a chance of ever being closed. And a clear indication you have nobody with the
required knowledge/experience to handle a project of this complexity. Experienced
UNIX veterans write complete X11/KDM/whatever init scripts from scratch in
a couple of hours. Known fact is there are tons of correct ebuilds/init scrpts
around, carrying the coder's and/or his employer's copyright. Free to use for
everyone because released under terms of GPL. Not available for Gentoo users
because Gentoo wants everything and in the end gets nothing. (no, I'm not
talking xfree-4.4)

For the rest of your questions: IF a Gentoo patch or ebuild breakage causes
package A to malfunction and the same broken patch is applied to A-(n+1) as
well, how is an update to A-(n+1) suppose to fix it? Only forces users to update
other packages too because packages B and F can't deal with A-(n+1). Oftentimes
caused not by upstream package, but by incompatible Gentoo changes. Now what new
developer is willing to deal with these kinds of artificial problems? Please
read for example freebsd policies, you can learn a lot how to avoid such
problems from there.

For the rest please search <> and gentoo-dev-ml.
Comment 9 Jon Portnoy (RETIRED) gentoo-dev 2004-05-24 10:22:47 UTC
Did you pay any attention to the copyright page?

A developer commits some code to the tree. They own copyright on it. A corporation takes that code and relicenses it under a restrictive license. Now we have to sue -- but we can't! That developer owns copyright on it and they'd have to be the one to sue! Now Gentoo is helpless to defend its GPL-licensed intellectual property.

Now let's imagine companynotnamedSCO sues Gentoo over Gentoo's intellectual property. What if Gentoo doesn't own copyright? Now it's each individual developer getting sued.
Comment 10 MaN w1tHoUt SoCkS 2004-06-06 17:31:38 UTC
Don't really know why I'm still responding. Your problem is missing X11 devs.
I gave the most obvious reasons. But you keep ignoring everything but the
copyright thingy (can I assume you agree with everything else?), 
so here it goes:

First off, I did read the copyright page. But did you? I know you're listed as
one of its authors, but it doesn't say anything at all about Gentoo being sued,
just the opposite case: Gentoo wants to be able to sue parties when using 
Gentoo's own code in violation of the GPL. Interestingly enough this can be 
traced back to public discussions at exactly the same time Zynot used Gentoo's
code unmodified but with replaced copyright headers.

Later it says, and I quote, "it guarantees that the contributed works will 
never be relicensed under a license *materially different* from the GNU General 
Public License". Not accusing anyone of anything, but let's assume I'm 
contributing some code (which I won't because conditions are absolutely unacceptable)
and a later owner of Gentoo decides to relicense it under a license identical
to GPL, but..let's say with the patenting clause removed. Not "materially 
different," but I may end up having to pay license fees just to be able to use
my own work in other projects.

If a piece of work is done during paid company time, it belongs to the company
who paid for it. Everyone else can use it if released under GPL terms, except
Gentoo because Gentoo can't have copyright. It's as simple as that.

As another example, let's take a look at how Gentoo manages licenses. Currently,
all package's licenses are abbreviated to something that fits into a file in
/usr/portage/licenses. That simply will not work other than for projects released
under pure GPL or BSD or other common license terms. Most licenses also contain
attributions to other projects they borrowed some code from. Where is this 
attributions mentioned? Nowhere! Your "academic" license file actually contains
refs to a particular project the license file is pulled from. Others replace
original RCS/CVS headers with that of Gentoo developers. Others explicitely
state that the software and *any* accompanying material may not be distributed
over the Internet, yet you distribute their EULA to all Gentoo users per portage
tree. Clearly in violation of this very EULA. It's simple, a licence is an
agreement between the software publisher and users of their software. That in
99% of the time can't be reduced to something in /usr/portage/licenses.
Believe me, if "companynotnamedSCO" wants to sue me, I'd rather have my own
lawyer handle it. 100% higher chance of winning in these lights.

To gap the bridge to X11, my personal opinion is that Gentoo's X11 folks work
against their users. Too many real bugs closed WONTFIX or INVALID or WORKSFORME
Very bad move in a community driven distribution. Gentoo devs suggesting users
maintain their own overlays isn't helping either. Best example: in a fairly
old version of SuSE linux I can update to new versions of X11 and all
dependencies without breaking anything because all replaced packages are
backwards compatible. To do the same thing in Gentoo, I need my own versions of
xfree-4.2, xfree-4.3, xorg-x11, gcc, glibc, binutils, baselayout, &c to be 
able to use binary packages dependant on X11 on all my systems. Heck, I can't 
even upgrade from -r5 to -r6 without major breakage. Still wondering why previous
contributors are turning their back on Gentoo? According to one of them (yes,
there are other communication channels besides bugzilla and irc), RedHat uses
xvt as a "update-alternatives" target instead of a real program. Well, not
anymore since a long time. But it's still in xorg patches-1.0. As well as those
stupid vt7 kludges and ".orig.diff" and ".orig.rej.diff" files and other things
Mork mentiones. Think about it, people are not switching from RedHat to Gentoo
just because they want to see the same mess all over again.
Comment 11 MaN w1tHoUt SoCkS 2004-06-06 17:32:26 UTC
PS: Your line wrapping is heavily broken, junior. Really hard to read on some
standards compliant browsers. We in the Linux world press return every time we
want to start a new line and don't depend on some fancy CSS.
Comment 12 Jon Portnoy (RETIRED) gentoo-dev 2004-06-07 11:34:19 UTC
I wrote the original copyright page. It was later largely rewritten by Daniel.

Distributing just the terms of the license is not a violation of that license regardless of whether the license counts as accompanying material or not; c.f. fair use.

My lines look just dandy in Mozilla.

If you have a big issue with copyright, please don't contribute. This conversation is pointless when you're stuck on spreading unmitigated ignorance about copyright issues mixed with "you hate users!" and other random ranting. Thanks.
Comment 13 Jon Portnoy (RETIRED) gentoo-dev 2004-06-07 11:41:52 UTC
Additionally, I should note that I've responded to bits of your rants that are relevant to my responsibilities (such as copyright issues). This does not imply agreement with other points, but rather I simply have nothing to say about whether or not there's enough X devs. If the X maintainers feel they need more help, they'll contact me or other recruiters directly.
Comment 14 Seemant Kulleen (RETIRED) gentoo-dev 2004-06-07 11:50:44 UTC
What is it with anonymous trolling on our bugs forum?  If you have an issue, come to talk me on IRC.  From what I see, all you're doing is venting anger and being emotional about something you need not be.  It's simple -- you don't like our copyright agreement, don't submit code to us.  The issue ends there.

For the X11 stuff, show me examples where you believe the X11 team has abused users, and I'll take a look at each case.  Now, this bug will be closed because it's way off topic at this point.
Comment 15 Seemant Kulleen (RETIRED) gentoo-dev 2004-06-07 11:51:44 UTC
and really, why are you being so cowardly as to criticise anonymously?  At least be upfront about it.
Comment 16 Donnie Berkholz (RETIRED) gentoo-dev 2004-06-13 16:55:16 UTC
I've added your initial concerns about .orig and .rej files into xorg-x11 patchset 1.1.
Comment 17 Donnie Berkholz (RETIRED) gentoo-dev 2004-06-23 18:06:21 UTC
Also fixed the xvt thing, now that I think about it.

I'll note again for anyone who reads this, the primary problem here (meaning X) is not a lack of ability, it's a lack of time.