Static system level uid/gid's reservations in Fedora/RHEL - how to handle situation?
by Ondřej Vašík
Hello,
at the moment static system level uid/gid's are handled by setup package
and /usr/share/doc/setup-*/uidgid file. There is threshold of system
uid/gid's - it's uid/gid 100. Another way to reserve "static" uid/gid
reservation is http://fedoraproject.org/wiki/PackageUserRegistry ...
usable only for Fedora and only semi-static (as base id could be easily
changed).
As we are running out of the free uid/gid's in uidgid reservation file
(no free gid's in fact at the moment), it has to be solved somehow...
there are quite often requests for uidgid reservations as it increases
security in many cases...
What's the best way to handle that situation? One possibility is to
increase the threshold of system level id's (to 200? 300?), another is
to check current reservation and clean long-term unused reservations (I
doubt there are many such cases, so it's only temporary solution). Other
could be sharing groups (as static uid's are still available), but
that's not always good solution.
Any other idea or some prefered solution?
Greetings,
Ondřej Vašík
14 years, 11 months
Maintainer Responsibility Policy
by Brian Pepple
Hi all,
I'm looking for some feedback on what I've got so far for the Maintainer
Responsibility Policy.
http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
--
== Maintainer Responsibility Policy ==
=== How long to maintain? ===
13 months from initial release.
=== Belong to the appropriate low-traffic mailing list ===
* Package maintainers will receive important announcements through
the moderated fedora-devel-announce mailing list. Maintainers
will be automatically subscribed to this list. Everyone that is
a primary maintainer of a package in Fedora is also strongly
encouraged to subscribe to the fedora-devel list, though this is
not mandatory.
* http://www.redhat.com/mailman/listinfo/fedora-devel-announce
* http://www.redhat.com/mailman/listinfo/fedora-devel-list
=== Manage security issues ===
* Package maintainer should handle security issues quickly, and if
they need help they should contact the Security Response Team.
* http://fedoraproject.org/wiki/Security/ResponseTeam
=== Deal with reported bugs in a timely manner ====
* 'Nuff said.
=== Maintain stability for users ===
* Package maintainers should limit updates within a single Fedora
release to those which do not require special user action. Many
users update automatically, and if their applications stop
working from no action of their own then they will be upset.
This goes doubly for services which may break overnight.
=== Track dependency issues in a timely manner ===
* In the development tree, and to a small degree in the release
trees as well, updates to packages may cause other packages to
have broken dependencies. Maintainers will be alerted when this
happens, and should work to rebuild their packages with all due
haste. Broken dependencies may leave end user systems in a state
where no updates will be applied. In order to keep the
distribution in a reasonable state, someone will step in and
rebuild packages that have had dependency issues for some time,
but package maintainers should not rely on these rebuilds.
=== Notify others of changes that may affect their packages ===
* Some packages are depended upon by others; in this case, changes
to one package may cause issues for others. Maintainers should
be aware of the effects that changes to their packages may have,
and should alert to the fedora-devel-announce mailing list of
updates which contain ABI or API changes which may cause
dependency problems for other packages. The announcement should
occur a week before the packages update, so all maintainers
affected are notified. The announcement should include the
following information:
* Nature of the change.
* Branches (devel, F9, etc.) which will be affected by the
change.
* Expected date of the change.
* List of packages which are affected by the change.
Generally, this is merely the list of packages which
depend directly on the package which is being updated,
and can be found with "repoquery --whatrequires package"
where "package" is the package being updated.
* If your package upgrade breaks other packages in Rawhide, you
should try to help fix the packages affected. For example, when
Python-2.5 was integrated into Rawhide, Jeremy Katz at least
fixed the important packages and queued a rebuild for all the
other packages affected.
=== Miscellaneous Items ===
* Maintainers need to maintain an upgrade path for their
packages.
* F(current-1) -> F(current) -> Rawhide
* Packages should be pushed to the Rawhide branch first. If it
builds and works fine for a few days, then it can be pushed to
F(current). If there is a good reason to push it to
F(current-1), it should be done after a few days of being in
F(current).
---
Thanks,
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
14 years, 11 months
Multilib/multiarch debuginfo
by Jussi Lehtola
Hi,
is there any way to get i386 debuginfo packages on x86_64 for e.g.
libraries that are available also in 32-bit mode?
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
14 years, 12 months
Problem with build-id and cycling the free pascal compiler
by Joost van der Sluis
Building the free pascal compiler (package fpc) fails due to a
build-id/ld problem.
The compiler builds itself, using an older version of the compiler. Then
the compiler which is just build is used to build the same compiler
again. This iterative process continues until the generated binary and
the compiler-binary are the same. (It's called cylcling a compiler, most
compilers who can compile themselves use this technique)
But on F11/rawhide the two binaries never become the same, because they
all get a different build-id. On F10 this problen never occured, though.
According to the ld-manpage the build-id is the same when all the
object-files are exactly the same. But I think that isn't the case. I
tried --build-id=md5 and --build-id=sha1, both fail.
Any ideas how to fix this? Adding --build-id=none is a solution, but
then the rpm contains a binary without build-id.
Any other ideas? Is this maybe a ld-bug, or is it intentional?
Joost.
15 years
Ibus - Sorry
by Steven James Drinnan
Sorry pressed send in error.
But I missed it first because it is not included by default in the live
CD. Maybe something to consider?
Steven
15 years
Things to do this week instead of arguing about mixers
by Eric Sandeen
Now that we have ext4 as the new default filesystem, it'd be nice if we
can get more applications to take advantage of some of the features.
One big feature that has already been brought up on the list[1] is file
preallocation, which allows an application to pre-allocate blocks it
knows that it will eventually write into, thereby making sure it won't
run out of space, and also generally getting a more efficient/contiguous
file layout.
Only a few applications are taking advantage of this so far, in part
because it's new.[2] The transmission bittorrent client is using it,
but only if you tweak a configfile in (IMHO) non-obvious ways.
So it'd be great to help more applications take advantage of this, and
evangelize the interface a bit, and maybe do it in a semi-organized
fashion. First a bit of background on what this interface is:
Filesystems which can flag ranges of blocks as allocated but not
initialized can preallocate those blocks to a file very quickly, without
needing to write 0s or do any actual file data IO to perform the
allocation. When read, they return 0 because they are flagged as
uninitialized.
ext4 (as well as btrfs, ocfs2, and xfs) has an ->fallocate inode
operation which is the hook to this fast preallocation interface. The
low-level interface is via a syscall, but this is unlikely what we'd
like the applications to use directly. There are 2 other paths to the
interface:
posix_fallocate(3):
int posix_fallocate(int fd, off_t offset, off_t len);
This has existed for some time, but recent glibc will call the efficient
syscall if the underlying filesystem supports it. It will fall back to
essentially writing 0s to the file if not (or if on older glibc), and
this may not be desired behavior; preallocating 10G could take a very
long time this way.
fallocate(2):
long fallocate(int fd, int mode, loff_t offset, loff_t len);
This is directly wired to the syscall, so only succeeds on filesystems
that support it. It also takes a FALLOC_FL_KEEP_SIZE mode argument,
which allows one to allocate blocks without updating the file size if
desired (blocks can then be allocated past EOF). This call is only
wired up in very recent glibc, but it is available in F11.
So, tasks I see to be done, to get this started:
* Come up with some template autoconf magic to make it easy for
apps to detect fallocate() at build time, and some example
code on how to use it
- Should it fall back to posix_fallocate if fallocate is absent?
* Decide on some consistent buildt-time, run-time, and
configuration behavior when enabling this
- should build time use posix_fallocate if only it is available?
- config enabled == use fallocate whenever the fs supports it?
- config enabled == fall back to posix_fallocate or not?
- I'd be happy enough with exclusively using fallocate()
* Come up with a list of apps which could benefit:
- all torrent clients?
- rsync? (some patches have floated before)
- rpm? (file installation and/or db files?)
- databases?
- file downloaders?
- virt image tools?
- ____ ?
* Work with Fedora package maintainers and/or upstream to get this
hooked up where appropriate
* (Make a wiki page or a tracker bug to follow all this?)
Whaddya say? Anyone want to help with this?
Thanks,
-Eric
[1]https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00110.html
[2]https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02078.html
15 years
Abandon "Default Desktop"
by "Jóhann B. Guðmundsson"
In the resent discussion regarding "audio" and to further enhance the
project and to
allow all desktop environment projects to play on a fair ground
regardless if they are old
grown and known projects or new and emerging one and thus being able to
compete on a fair
ground amongst them self's in the form of live spins and to prevent any
misunderstanding that
an issue regarding one desktop environments might be present and or
affect all of them and thus
have negative impact on all the desktop environments we currently ship.
I propose that we stop referring to and ship a "Default desktop" but
instead will start
referring to their project name instead.
AFAIK what would be required to accomplish this is change all
documentation and filenames to refer to Gnome desktop instead of Default
desktop, Fedora desktop or just Desktop and make minor changes to Anaconda.
We probably would want to create a new Wiki page that would have a brief
description and a download link to their live spin.
The desktop environments spins along with all other spins should be
under the projects total control unless they're content violates
Fedoraproject in any way or form.
This requires the Fedora Board and or FESCO to neither enhance or hinder
a projects growth/content/decision on the projects corresponding spin.
I hope the community can keep this discussion strictly on the
professional notes and finally will reach consciousness regarding my
proposal.
Best regards
JBG
15 years
File conflicts: nss-softokn-freebl and nss
by Debarshi Ray
While yum installing gcc-c++ over a Fedora 11 Beta x86_64
installation, I got this:
Transaction Check Error:
file /lib64/libfreebl3.so from install of
nss-softokn-freebl-3.12.2.99.3-7.fc11.x86_64 conflicts with file from
package nss-3.12.2.0-4.fc11.x86_64
Happy hacking,
Debarshi
--
One reason that life is complex is that it has a real part and an
imaginary part.
-- Andrew Koenig
15 years
The Great Pulseaudio Mixer Debate: a modest (productive) proposal
by Adam Williamson
So, in the spirit of light rather than heat, here's my proposal, again,
rescued from the depths of the flamefest, with some actual work
attached.
g-v-c is clearly intending to be an abstracted and simplified volume
control app / applet to cover the most common use cases in a friendly
way. Great.
It's clear, though, that some users have needs beyond this, which are
likely only going to be satisfied in a sensible way by access direct to
the ALSA mixer elements. Bastien and Lennart don't want some kind of
hack to expose these via g-v-c, and I'd tend to agree, that's clearly
not what it's designed for.
So my proposal is that we include by default an alternative GUI app
which allows direct access to the mixer channels. This won't be an
applet or anything else persistent, just an application that you can
choose to run if you need that level of access. Basically the same as
Lennart's "just use alsamixer" suggestion, only a GUI app that will be
more discoverable and easier for most people to use (it's a bit tricky
to figure out 'alsamixer -c0 -Vcapture', for instance).
At first I suggested including the XFCE mixer for this purpose, but now
that feels a bit awkward. It's really part of XFCE, its menu entry is
just named 'Mixer' and renaming it to something appropriate for GNOME
might not be appropriate for XFCE. And it has a slightly odd interface
rather than the 'immediate screenful o' sliders' that people are used to
from the old g-v-c.
So I suggest what we should do is resurrect gnome-alsamixer. It's still
technically part of GNOME - it's even got moved to the new GNOME git.
Other distributions still package it (Debian, for e.g.) It's even had a
few commits within the last year or so. It was more or less deprecated
in favour of g-v-c, but now we have a case where it may make sense to
have two clearly differentiated apps, and gnome-alsamixer is the obvious
choice.
I just pulled the latest code out of git and threw together a package
(based on the spec from Mandriva, since I had it lying around). It
builds and works fine - you get the kind of interface most people will
be expected, a tabbed window with each of your available output devices
on a tab, and the typical 'bunch o' sliders' layout for each device. In
the package I've added a menu entry with the name "Advanced Volume
Control" and the comment "Full hardware access volume control
application".
The package is available here:
http://adamwill.fedorapeople.org/gnome-alsamixer/ (the SRPM, spec file,
and an x86-64 build for current Rawhide). Please take a look at it if
you're interested.
Just to reinforce this, gnome-alsamixer shouldn't interfere with Pulse
or g-v-c at all; it doesn't run persistently, it doesn't mess anything
up in gconf or anywhere else that would affect those. All it does is let
you poke the raw mixer elements, just like alsamixer only graphically.
I know the GNOME folks are generally opposed to having two apps that do
'the same thing', but it's very clear from the long threads on this list
and elsewhere that g-v-c really doesn't do the things that many people
need it to do as of yet. If we ship with just g-v-c as a graphical
'mixer' available by default we will wind up telling many many people to
drop to a console and use alsamixer - and annoying a lot more people who
don't ask, find the release notes, or figure out how to use alsamixer on
their own. I really don't see how providing an alternative graphical
mixer app is worse than that.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
15 years
