PackageMaintainers/Policy/EOL out of date
by Patrice Dumas
Hello,
The page
https://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL
is out of date, pre-merge. I would like to update it, however I cannot
find an explanation of the current scheedule, there is only something
about the releases,
https://fedoraproject.org/wiki/Releases/Schedule
I can't find the description of the EOL. Unless I am wrong, F-N+2 is EOL
one month after the release of F-N, but I don't know exaclty when events
relevant for packagers happen, like when new branches for packages
aren't created anymore, or when the builds are stopped for real happen.
If you give me some information or link to a page explaining the
EOL schedule, I'll update.
--
Pat
15 years, 5 months
Reasons to preseve X on tty7
by Dax Kelson
I would argue strongly that this change should not be made for the
following reasons (in no particular order):
* The default behavior of X on tty7 has been in place since the
beginning (almost a decade and a half).
* Long standing behaviors and defaults should not be changed unless
there is a VERY good reason with a significant upside. Developers should
tread respectfully in such hallowed places.
* This specific Linux behavior is well documented in hundreds of
thousand of publications ranging from college text books, HOWTOs, Linux
books sold in retail stores, blogs, forums, guides, and training
manuals. Making a change invalidates all that published knowledge.
* Fedora (and presumably RHEL6) now behaves differently from all the
major distributions. The axiom about those who ignore history are bound
to repeat holds here. UNIX "distros" did the same thing, introducing
frivolous incompatibilities. This fractures the user community, creating
separate pockets of knowledge and experience for each system.
* The "exception to the rule" (such as this one) dramatically increases
the costs of cross-distribution support. It turns 300-page books into
1000-page books. Similarly one must remember and commit to memory all
the "exceptions" and swap them in and out of your mental working set as
needed.
* Fedora is now inconsistent with itself in regards to where X is
running depending on if you booted to runlevel 3 and used startx or if
you booted to runlevel 5. When your uptime is 3 weeks, how do you
remember which method you used to start the GUI?
* Having tty1 be the user's "primary console" (as mentioned in BZ
465547) is not a worthy goal as desktop (GUI only) users should not and
do not care what tty X is on.
* Experienced users will try CONTROL-ALT-F1 and nothing will happen, the
first thing that comes to mind is "something is broke".
* With the current rawhide behavior, what happens when you combine this
with fast user switching? The first user's desktop is on tty1, and then
is the second desktop is on tty7, and the third on tty8? I tried to test
this in my lab but I suspect video driver problems (radeon) because my
test machine would lock up.
* Having the X server start on tty7 *from the very beginning* would get
one less "flicker" without making an incompatible change.
I support progress, but I hate to see two steps forward and one back. I
understand change is natural but the change should be well reasoned with
implications considered and weighed.
To put my comments in "context" and to show that I'm not just a nutter
with an uniformed opinion, and in a way of introduction, here's a bit
about myself. I've used (typically in production) every single version
of Red Hat and/or Fedora ever created (go Mother's Day!). I started an
ISP and grew it to 10,000 users using (initially) Red Hat 4.2 (not
RHEL), and I was the first person/customer of Red Hat to earn an RHCE
(Feb 1999). I have minor patches in many different projects and several
hundred bugs in bugzilla.redhat.com. I was the official GNOME RPM
maintainer for a few years around the turn of the century creating GNOME
RPMs for several distributions for each new GNOME release.
For the past 9 years I have made a living writing Linux courseware for
multiple Linux distributions and teaching Linux training classes along
with the rest of the dozen full time instructors at Guru Labs, a company
I founded with a college friend of mine. I've sold tens of thousands of
Linux training books. Unfortunately, I don't have the time to
participate on the lists as much as I would like too. However, because
of my daily work I get to observe the low level changes and development
process of many different Linux distributions giving me a broad
perspective.
Our coureware features extensive labs which have thousands of lab steps
that exercise virtually all the major software components and features
thereof. As we update/validate our courseware to work on the latest
Linux distribution versions, our courseware ends up acting like a giant
regression test. We end up patching and/or filing many many bug reports
in many bug trackers.
Uneeded and frivolous incompatibilities between Linux distros are
particularly annoying to me on many levels. One practical reason is the
bloat it causes in our courseware. The LSB is fine for developers who
want to run binaries across multiple distributions, but Linux Sys Admins
deserve something akin to the LSB that provides greater consistency at
the Sys Admin level by removing squashing these frivolous
incompatibilities. This is something that has been brewing in the back
of my mind and I (using Guru Labs funding/resources and other interested
parties) might tackle at some point.
Dax Kelson
Guru Labs
15 years, 5 months
Package Review SIG Meeting Summary 2008-10-23
by Brian Pepple
=== Present ===
* Brian Pepple (bpepple)
* Jon Ciesla (limburgher)
* Rakesh Pandit (chacha_chaudry)
* Kushal Das (kushal)
* Jason Tibbitts (ubertibbs)
* Rex Dieter (rdieter)
== Summary ==
=== Package Review Statistics ===
* bpepple, limburger, and chacha_chaudhry will work on a script to
generate weekly package review statistics.
=== Brain-Storming ===
* The group brain-stormed for a bit on ways to improve
participation in package reviews. Some ideas were:
1. Monthly (or some other time frame) swag drawing for
folks that complete a certain number of reviews in a
month.
2. Advertise better the concept of reviewing at least a
percentage of what they submit.
3. Prioritize the package review queue by the ratio of
reviews done / package submissions.
4. Engaging SIG's to review packages. (Ex. Like how the KDE
sig keeps an eye on kde-related packages)
5. Coordinate some package review days (and do a better job
of it than we have in the past)
6. Hold an IRC workshop (or maybe a trac at FUDCon) on
package reviewing.
=== Future Meetings ===
* Instead of IRC meetings, the group will use the devel-list to
conduct future business.
IRC log can be found at:
http://bpepple.fedorapeople.org/prs/package-review-sig-2008-10-23.html
Later,
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
https://fedoraproject.org/wiki/User:Bpepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
15 years, 5 months
dependencies between {swfdec-mozilla, gnash-plugin} and nspluginwrapper
by Martín Marqués
Yesterday I started to finish configuring some things that were left
behind on my new laptop (amd64), and bumpped up with flash support for
firefox.
The thing is that swfdec didn't work, and gnash neither.
Solution: remove nspluginwrapper.
So I wanted to ask before opening a bug report: shouldn't there be a
dependency on all 3 packages (don't know about others) so that you can
only have one of the 3 packages (al least the plugins:
nspluginwrapper, swfdec-mozilla, gnash-plugin) installed?
--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador
15 years, 5 months
old release bugs handling
by Patrice Dumas
Hello,
When looking at the infra after eol issue, Toshio made me aware that
nothing special is done for bugzilla in eol branches. Maybe it would
be nice to have bugs filled against old branches associated with
another product, such that they are easier to triage, and owner
doesn't get those bugs automatically? As a disclaimer I know nothing
about both the technical issues and the organizational issues involved
by that proposal. The idea could be along (provided it is technically
feasible):
* when a bug is filled against an old release in the current fedora
product, the product is automatically changed to 'fedora EOL'
(or 'fedora Legacy' if that product is to be reused), which means
that they don't necessarily go to the same mail adress than current
releases. Also there is an automatic answer for those bugs, along:
'You are reporting a bug against an unsupported fedora release, you
are urged to upgrade, and retry with the new release'.
* the owner of this product is the owner of one of the old releases,
for example could be the owner of F7 currently. That way, if this
release is orphaned by the maintainer, he won't get bug reports
for the old branch anymore. I would even suggest mass orphaning such
that the default is that the maintainer doesn't get those bugs.
Then people interested in triaging bugs for old releases could be
subscribed to the adress all the product bugs are forwarded to,
such that they can triage the bugs.
Of course this would make more sense in case the infra was left
open for old releases, as there would be people specifically interested
in triaging those bugs and also interested in becoming maintainers
of old branches, but even if the proposal to keep infra open for old
branches is rejected --- and I am almost sure that it will be
rejected --- it could still be something relevant to do.
Thoughts?
PS: tell me if this is better to ask that kind of question on the infra
list.
--
Pat
15 years, 5 months
review-o-matic : Fedora package review helper
by Kushal Das
Hi all,
I am starting a project called review-o-matic which will do reviews of
Fedora packages based on discussions at
https://www.redhat.com/archives/fedora-packaging/2008-October/msg00023.html.
We know of having couple of scripts being used by different people to
do so, but this tool's target is to consolidate those efforts and add
a number of additional features as well. The basic idea is to remove
the grunt work from package reviews.
Wishlist:
Run rpmlint
Build the package in mock
verify the md5sum of upstream source matches what is in the srpm
<your ideas here>
Workflow:
The instance you submit a new review request, this tool will
automatically do the following:
* Download SRPM and SPEC as soon as new package review get submitted.
* Do a review , post it on bugzilla and also keep track to show on own
web front end
* People can upload their SRPS to the system to get a review done by the system.
Kushal
--
http://fedoraproject.org
http://kushaldas.in
15 years, 5 months
undefined symbol: __stack_chk_fail_local
by Douglas Bagnall
I've been working on a package for OLPC that uses pam_sotp, which
Rahul Sundaram packaged for Fedora in order to help OLPC.
http://sundaram.fedorapeople.org/packages/pam_sotp-0.3.3-1.fc9.src.rpm
Unfortunately the installed pam module fails with errors like this:
PAM unable to dlopen(/lib/security/pam_sotp.so): \
/lib/security/pam_sotp.so: undefined symbol: __stack_chk_fail_local
This is related to gcc's fairly recently introduced stack smashing
protection; if it is compiled with CFLAGS="-fno-stack-protector", the
module works fine. But that seems wrong.
How are these symbols ending up undefined? Has anyone met this
problem before? Some googling suggested linking with gcc rather than
ld, but I can't work out how to make the rpm do that.
(This is all Fedora 9, gcc-4.3.0-8.i386).
Douglas Bagnall
15 years, 5 months
Fedora 11: moving to posix file capabilities?
by Panu Matilainen
Hate to interrupt the tty1 vs tty7 debate but...
We have kernel support for storing capabilities on filesystem since 2.6.24
and recent libcap, both in F9 already. I just committed file capability
support to rpm.org HEAD, filling in the final(?) missing piece.
Capability support is not going to be in rpm 4.6.0 but no reason they
can't be pulled into 4.6.1 which is easily in F11 timeframe.
Are we ready to start considering moving away from SUID bits to
capabilities, in Fedora 11 maybe?
- Panu -
15 years, 5 months
Fedora 9 spins beta???
by Pavel Alexeev (aka Pahan-Hubbitus)
On page http://spins.fedoraproject.org/ in section "Fedora 9 spins" all
present torrent files has description with "- **Beta**" suffixes. But
nor section name nor file names has not include "Beta"... Furthermore,
Fedora 9 long time is stable... I assume this is only error in
description? Or we have not stable Fedora 9 spins yet?
Please fix it, who can.
15 years, 5 months
