On Tue, 07 Aug 2012 12:45:41 -0700
It is about 3-4 openSUSE users that I know about and it is for period
of last few years, which is insignificant, if one would not know:
Due to this issue alone, openSUSE lost quite some number of reports,
and most likely users.
OpenSuse Doesn't want those reports.
If they can't even follow the corporate line in regards to creating
a login, then how are they going to follow open-suse mindthink that further narrows
the fields of what is even ***ALLOWED*** to be reported as a bug without being
For a great example of something that used to work, but no longer does -- except
under some ideal suse-build environment. It's a real bug report for something
that used to work -- bug it now broken, yet the pressure (as documented in the
has been to tell the user that it is their problem and that their valid, current,
suse install the problem -- and is unsupported for a build environment.
I had to fight just to have the bug closed as "WONTFIX" -- the developers wanted
it as INVALID because their build works under their idealized build & test
It used to be products were build to run on released products -- not just
sterile conditions, but this was before openSUSE's Tivoization efforts to turn
into a platform for platform for developing end-user appliances. It's a retreat
general linux-distro model of 1 source working anywhere (including other OS's) to an
opposite and antithetical extreme of it working on virtually no end-user's real
"in-use", production system (clean room build and test only!).
This was most of my latest reply on that bug -- as it well details they
problem(s) in the
in the attitude shift that's caused the problem.
The fact that most users are ok with this this (as indicated by the responder's
comment "this is how the community feels about your bug reports)" is a very
why most users wouldn't be comfortable submitting feedback or bugreports.
(In reply to comment #11)
If it is faulty please provide a patch to enhance the
The purpose of a bug-tracking mechanism is not to force nor beat users into
submission for having submitted a bug. It's not to prove the superiority
of your build process over theirs. It's not to prove to them that your
idealized value of how to run the program works and whatever they are doing is
The point is to get feed back about something that broke for the user --
specifically something that *USED* to work (building samba from RPM) for them.
This is a regression. It used to be those were treated as P1/S1 bugs. Now the
user is abused for not having an approved setup and the user has to try to
explain why they bug report isn't invalid.
It's your build which fails and I don't have
the time nor do I see the value
to the project to debug your failing build.
At one point in time people cared about the projects and products they
shipped on to build in as many configurations (to the point that they build on
DIFFERENT OS's). You only care that your build works on some idealized config
-- which is very different from the attitude of how open source development used
to be done.
It is faulty for your requirements but not for the
requirements we have as an
Open Source Software project.
The Samba project builds on multiple architectures with no were near the
restrictions of the open suse project. Opensuse's version of rpm build is
faulty because it doesn't build -- NOT just in all the places that samba
builds, but because it doesn't even build on "generic" (not specially
machines as does the original script.
Why? because you remove various pieces from samba necessary for it to
build all of itself.
I cannot submit a patch -- because it would be rejected. I have been that route
before -- It's not because I can't submit a patch -- it's because suse only
wants certain things two work.
If you want to swear that you will accept my patch, I can create one -- but I
would bet I'll hear that "users don't want all that other stuff on their
machines (ldb, tdb, docs...etc)... You are creating 'use-only' machines by
design (that don't easily support modification or developers). I can't create a
patch for that as it's a high level decision made about products more than just
samba. It's what stallman calls the 'Tivo-ization' of the product.
I don't care if the bug state stays at wontfix. It demonstrates very
well your unwilling habit to learn and cooperate.
Only if I'd never submitted patches that had been rejected would that
be true. But having done so, because it's not the direction open suse has
decided to take, the bug staying at won't fix is documentation of configurations
that suse doesn't support. It isn't a reflection of your
development abilities. It documentation of an area that Suse no longer supports.
This information is vital if open suse is ever to figure out how their
decisions affect those who try to use all of suse as a development platform and
the effects of their Tivoization program in moving openSuse to be an appliance
development platform rather than a linux development platform.
See also comment #1 to get a picture what our
It shows me very well the picture of a user that says "I got mine", and the
fact that your build, which used to work, no longer works is your problem, and
unless you apologize for wasting our time for having even submitted a case were
something doesn't work, we are gonna ignore you for having a system we no longer
Do you really think their weight counts any more than me than that of a petulant
This note is a perfect example of why it's pointless to worry about people
registering for bugs -- when they will get this type of response to reporting
them. It's called "hypocrisy".
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org