The received wisdom seems to be "Only care about upgrades with stride <=
2", meaning, FC5 to F7 should work, but FC1 to F7 is madness. Is this
written down anywhere, or just tribal knowledge?
I ask because there's a fair bit of cruft in the X packages to handle
things like Obsoletes: XFree86. We haven't shipped that since FC2, so
it's hard to still care.
I also don't know how closely this is tied to RHEL construction. So
far, RHELs have been issued every other Fedora, so that might be the
source of the "stride 2" idea. Maybe that won't be true in the future?
Who knows. And if it isn't true, maybe that's just Red Hat's cross to
I don't see this in any of the packaging docs in a brief search, so if
we could get this written down that'd be helpful.
Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC
in #fedora-meeting on irc.freenode.org:
/topic FESCo meeting -- Any objection to this week's report from FPC at
/topic FESCO-Meeting -- MISC -- Feature Polict Draft -
/topic FESCO-Meeting -- MISC -- Opening FESCo election vote to more
/topic FESCO-Meeting -- MISC -- Merge Reviews for F8 target - all
/topic FESCO-Meeting -- MISC -- Package Database - abadger1999
/topic FESCO-meeting -- Statically link libuu (uulib-static) into
klibido -- tibbs --
/topic FESCo meeting -- Free discussion around Fedora
You want something to be discussed? Send a note to the list in reply to
this mail and I'll add it to the schedule (I can't promise we will get
to it tomorrow, but we'll most likely will if we don't run out of time).
You can also propose topics in the meeting while it is in the "Free
discussion around Fedora" phase.
If your name/nick is on above list please update the status on the
Extras schedule pages in the wiki ahead of the meeting. That way all the
other FESCo members and interested contributors know what up ahead of
the meeting. And we will avoid long delays in the meeting -- those often
arise if someone describes the recent happenings on a topic directly in
the meeting while all the others have to wait for his slow typing...
Brian Pepple <bpepple(a)fedoraproject.org>
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
I'd like to ask some questions about terminal emulators and utmp.
In /var/run/utmp file is stored information about who is currently
using the system. The file is writable only for group utmp, so there
has to be a mechanism that will allow terminal emulators to add
entries to the file.
A library called libutempter (used by xterm and konsole) allows to
modify the file only to processes that have group utempter. It used to
work without setgid, but the utempter binary used by the library is
hidden in a directory with permissions "drwx--x--- root utempter"
The problem is that setgid binaries have some environment variables
like LD_LIBRARY_PATH and TMPDIR removed. I got bugs #229360 #243069
reported for xterm. Unfortunately I can't fix it unless utempter is
accessible without setgid. Do we really need to protect the file from
Gnome-terminal, on the other hand, uses gnome-pty-helper binary that
has utmp setgid. The binary is not hidden and every application can
make entries in the utmp file.
To have some consistency, either gnome-pty-helper needs to be also
made accessible only to the utempter group and gnome-terminal is made
setgid or utemper is made accessible to everyone and xterm drops setgid.
Which path are we going to follow? Comments?
I haven't been active on this mailing list since 2004 or so, so let
me (re-)introduce myself.
I'm Lennert Buytenhek, and I live in the Netherlands. As far as
open source contributions go (other things I've done probably aren't
very interesting), in the past I have written an ext2 resizer (called
ext2resize), contributed ext2 support to PartEd, rewrote the bridging
support in Linux 2.3.something, hacked on User Mode Linux, and a
bunch of other stuff, and these days, among other things, I am
occasionally seen hacking on ARM Linux kernel Things.
Recently, I produced an unofficial (but-seems-to-work-all-right) port
of FC6 to the ARM architecture (after having ported FC2/3/4 to ARM in
The current set of diffs[*][**] is available for inspection here:
I'm posting here because I would really really like to get the relevant
diffs merged back into Fedora. I believe that ARM is well-supported in
the various upstream projects that Fedora packages, and so this should
be a relatively painless process (if you look at the diffs referenced
above, most diffs are actually only spec file changes to cope with the
addition of a new architecture.)
I'll follow up with a mail with thoughts about secondary architectures.
[*] Some of which were produced by Russell King (ARM Linux kernel
maintainer) or Ralph Siemsen (Netwinder project.)
[**] NB: not necessarily the same set that we'll end up submitting
We would have a first open meeting of the Fedora I18n Project
on IRC next week:
Place: #fedora-i18n on Freenode
Time: 2007-07-02 06:00 UTC 
- desktop input method install defaults and configuration
- i18n comps
- renaming of fonts-* to reflect upstream projects
- plans for next meeting
- open discussion
 $ date -d "2007-07-02 06:00 UTC" or
Probably we will do the next meeting at a different time which will make
it easier for people in different timezones to join.
Recap and full IRC transcript found here:
Please make corrections and clarifications to the wiki page.
== Fedora 5 EOL ==
* Fedora 5 goes EOL end of this month, not very far away.
Decision: jkeating will create a wiki page to track the various tasks
releng needs to accomplish to shut down Fedora 5 updates. Various tasks
will be assigned to various releng folks and an announcement will be
sent regarding the tasks and timing of the shutdown.
== Automatic promotion of updates ==
* FESCo couldn't agree on anything so they approved the general
concept of doing automatic promotion of upgrades. It's up to releng and
QA to create a framework around how it should work.
=== Agreed upon Constraints ===
* autopromotion of updates default to off, checkbox can be clicked to
turn it on, delay defaults to 7 days.
* Ability for (at least) other maintainers to block or ''stop'' an
update is a pre-requisite to enabling auto-promotion functionality in
our update system.