Fedora infrastructure is trying to reach the FAS user anishpatil.
There is a gmail email associated to this account but apparently it is not enough
to contact this person.
Does someone know how to contact anishpatil?
If we do not manage to contact anish, we will have to de-activate the account
(which can then be re-activated by logging in FAS and changing the flag) and we
will also have to figure out what to do with the packages this user is the PoC
Thanks for your help,
-- for the Infrastructure team
As yum has been replaced by dnf, there is a question for me: will
yumdownloader (installed by yum-utils.rpm) be replaced by something like
dnfdownloader (installed for example by (a new) dnf-utils.rpm)?
Fedora release 22 (Twenty Two)
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>
Planned Outage: Taskotron - 2015-04-23 18:00:00 UTC
There will be an outage starting at 2015-04-23 18:00:00 UTC, which will
last approximately 3 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d '2015-04-23 18:00:00 UTC'
Reason for outage
Taskotron production currently runs on Fedora 20 machines and with that
EOL date coming up, we need to redeploy those machines to a newer
Fedora release. There are also new features which will be put into
production during this redeployment.
The outage may take as little as an hour but from the upgrades in the
dev and stg Taskotron environments, 2-3 hours seems more likely.
Ask Fedora - http://ask.fedoraproject.org/
Badges - https://badges.fedoraproject.org/
BFO - http://boot.fedoraproject.org/
Blockerbugs - https://qa.fedoraproject.org/blockerbugs/
Bodhi - https://admin.fedoraproject.org/updates/
Buildsystem - http://koji.fedoraproject.org/
GIT / Source Control - pkgs.fedoraproject.org
Darkserver - https://darkserver.fedoraproject.org/
DNS - ns-sb01.fedoraproject.org, ns02.fedoraproject.org,
Docs - http://docs.fedoraproject.org/
Elections - https://admin.fedoraproject.org/voting
Fedmsg busmon - http://apps.fedoraproject.org/busmon
Fedora Account System - https://admin.fedoraproject.org/accounts/
Fedora Community - https://admin.fedoraproject.org/community/
Fedora Calendar - https://apps.fedoraproject.org/calendar/
Fedora Hosted - https://fedorahosted.org/
Fedora OpenID - https://id.fedoraproject.org/
Fedora People - http://fedorapeople.org/
Main Website - http://fedoraproject.org/
Mirror List - https://mirrors.fedoraproject.org/
Mirror Manager - https://admin.fedoraproject.org/mirrormanager/
Package Database - https://admin.fedoraproject.org/pkgdb/
Spins - http://spins.fedoraproject.org/
Start - http://start.fedoraproject.org/
Torrent - http://torrent.fedoraproject.org/
Wiki - http://fedoraproject.org/wiki/
Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
comments to the ticket for this outage above.
test-announce mailing list
I recently opened a bug with glibc because persistent programs (like Thunderbird, etc) don't seem to handle roaming onto different networks very well.
Or rather, they rely on libresolv which opens /etc/resolv.conf at startup and then ignores changes to the file for the rest of the time the process it is linked to is running.
This might have been fine for desktop tower computers in the 1980's (though even then we had PPP and dynamic network settings), but we're in the era of pervasive laptops with internet connections and you're settings are going to be volatile. Period.
It's naive of a vital library like libresolv to assume either that (1) the process it's running in is going to be short-lived or (2) that the network isn't dynamic and that nameserver settings (and the default domain and domain search path, i.e. basically everything in /etc/resolv.conf) isn't going to change. (For those who've never looked too closely, /etc/resolv.conf gets rewritten by ISC's dhclient when new DHCP settings are received which includes a domain name, domain search path, or server addresses.)
Here's the bug I've opened:
If you go back through the previous glibc bugs, you'll find:
from 2005 which was closed out as "RESOLVED, WONTFIX" with the text:
There is a solution, already implemented.
Use nscd and nscd -i hosts in the script that rewrites your resolv.conf
(or nsswitch.conf etc.).
Problem with that is that no one seems to have gravitated towards this solution, and I don't blame them. It adds an extra layer of complexity and makes debugging issues that much more murky.
A simpler fix is to grab mtime from stat()ing _PATH_RESCONF each time through res_query() and see if it's changed since the last time. Perhaps caching the inode # also and checking that, since an older version of the file might have been renamed as /etc/resolv.conf.
Or one could use inotify(), but that's a whole lot less portable.
One obvious pitfall is multi-threading: it's a possibility that res_init() got called by the main thread before additional worker threads got created, in which case calling res_init subsequent times becomes a little more hairy.
I suspect that bug #18279 might come to the same fate as #984, but I hope not: the network and the way that we use it have both evolved these last 10 years, and let's hope that the way the glibc maintainers view both has also changed.
Please add yourself to this bug and if the glibc folks try to argue for closing it, perhaps someone out there has a more compelling argument than I do.