A day or so ago, I flipped the switch and killed off the 586 specific
kernel, by making the 686 kernel bootable on older machines.
Turns out it isn't that easy however.
Rpm will refuse to install the 686 kernel a 586, because it checks
sudo rpm -ivh kernel-2.6.21-1.3228.fc8.i686.rpm
Preparing... ########################################### [100%]
package kernel-2.6.21-1.3228.fc8 is intended for a i686 architecture
(Oddly, the 586 kernel uname is reporting itself as 686 already,
which I don't quite understand..
Linux equinox 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:11:19 EDT 2007 i686 i686 i386 GNU/Linux)
Anyway.. To 'solve' this, I think I'm going to have to make the 686
kernel package an 'i386' package.
Does anyone see anything flawed with this approach?
(Modulo problems with yum doing exactarch matches and upgrades being
more of a nightmare than usual).
I have nearly completed a set of VTP packages for Fedora.
To get VTP packaged and into the official Fedora distribution I have
also packaged Mini, quikgrid and minizip (replacing the unzip library
distributed with VTP).
If anyone is interested in testing let me know and I'll post the srpms
for Mini, quikgrid and minizip along with the current VTP patch that I'm
O U T A G E R E P O R T F O R M
Elapsed Time of Incident:
Package builders / update tool / koji web services
The koji.fedoraproject.org server is experiencing very high load. Attempts to
login and address the load issue are under way.
Continue investigating process issues with httpd (if that proves to be the
culprit once more).
Release Engineer: Fedora
Fedora-devel-announce mailing list
I would like to consider a case where both Linux and Windows computers
are in use, but mail servers are completely Linux-oriented (f.e.,
dovecot + postfix on Fedora hosts).
In such a heterogeneous environment, to provide unique
authorisation/authentication mechanism, either "OpenLDAP + Samba NT" or
"AD + msSFU" solutions are used. It provides uniform accounts and
passwords, independent of whether users use Linux or Windows on their
There is one circumstance which can spoil this fine solution a bit. When
a windows user creates its mail account (in OE or similar), he/she is
compelled to specify login and password "manually". When sometimes the
uniform password will be changed (either by Ctrl-Alt-Del from the
desktop, or by a system admin), this "manual" specification in the local
mail settings will not be changed automatically. The user then is
compelled to change its password there too; or sysadmin should use
different, seldom-changed account/password set just for mail subsystem...
All modern windows mail programs provide an "SPA" option (secure
password authentication). Using it, the mail program just uses the
current desktop's login/password. This way the situation described above
can be effectively avoided. But "SPA" uses NTLM (and spnego?)
authentication mechanism, which is not supported properly now neither by
dovecot or by postfix (it seems that another MTA and imap servers do not
support it properly as well).
Yes, I know that both postfix and dovecot actually "supports" NTLM now.
But dovecot uses NTLM against a local database only, it cannot
authenticate users against the windows domain. Postfix (and other MTA)
could use cyrus-sasl library, which has a "ntlm" plugin (capable to do
domain auth), but the actual blocker here is the dovecot issues.
Since the postfix and friends can do SMTP auth against a dovecot-auth
daemon, the solution seems to be focused in dovecot package only. By
adding of proper NTLM support to dovecot-auth, we can use "SPA" on
windows desktops and can forget about manual filling of login/password form.
Samba team strongly recommends to use "ntlm_auth" helper binary and
"winbind" daemon (both from the "samba-common" package), which provides
a stable way to do "NTLM" and "GSS-SPNEGO" auth types against a windows
domain. This way Squid and recently Apache do NTLM now. Hence I think
about adding of "ntlm_auth + winbind" support for Dovecot.
Before I shall begin it, I would like to ask:
- Is this issue a corner case or not?
- Are there some another solution for the support of "SPA against
domain" by Linux MTA/pop/imap servers in Fedora?
- Perhaps someone has already made something of it? At least partially?
- Is the solution proposed the best way to solve the issue (for
corporate systems etc.)?
A recent discussion in EPEL about whether README.Fedora would be
confusing to EPEL users has brought into forefront what I consider a
good packaging guideline for Fedora to follow which is to avoid using
the "Fedora" name as much as possible in package names and files with
exceptions like "Fedora directory server" and recommend using generic
names wherever possible.
This would certainly help in being a better upstream for distribution
and other efforts that are based on Fedora including RHEL, EPEL or OLPC.
In this specific instance I believe the guidelines should be mandating
for the discussion.
On Mon, 25 Jun 2007 13:34:30 -0400, Eric Tanguy (tanguy) wrote:
> Author: tanguy
> Update of /cvs/extras/rpms/libupnp/FC-6
> +* Wed Jun 13 2007 Eric Tanguy <eric.tanguy(a)univ-nantes.fr> - 1.6.0-1
> +- Update to version 1.6.0
Blacklisted for now together with ushare.
It breaks dependencies in several packages.
Run "repoquery --whatrequires libupnp.so.2", use rpmdev-diff, announce
such ABI breakage on fedora-maintainers list, and if such a version
upgrade is really necessary, coordinate rebuilds appropriately.
I've several times been asked to upgrade OpenSceneGraph to
OpenSceneGraph-2.0 (on rawhide and may-be FC7)
So far, there remain a couple of details unclear to me, I'd like to see
* OpenSceneGraph-2.0 is completely incompatible to OpenSceneGraph-1.x!
* Packaging, features and all SONAME have changed!
* Is there anybody out there who is actively using (esp. developing for)
* Is there anybody out there who is actively using Producer or who has a
package which depends on (OSG-1's) Producer
(OpenSceneGraph-2 has dropped Producer).
Should you answer to any of the questions above with "yes", please speak
According to FESCo's Election Policy _ the upcoming FESCo election
was supposed to use a variation of range voting _. However, with the
Fedora Project Board implementing a new voting method (approval
voting_) for the first time and the two elections being held so close
together several contributors and FESCo members would like to use the
same method to elect FESCo as used to elect the Board. This change
would be aimed at reducing confusion over changing the voting method
twice in such a short time.
FESCo is going to vote on this on Thursday to make sure there is enough
time to implement whatever decision is made. If you feel strongly that
this is the wrong decision, please speak up before the Thursday Meeting