There will be an outage starting at 2009-07-01 01:00 UTC, which will last
approximately 2 hours.
To convert UTC to your local time, take a look at
date -d '2009-07-01 01:00 UTC'
CVS / Source Control
Reason for Outage:
Final migration step for new cvs server. It will hopefully be offline for
only 30-45 minutes. The additional time is for some further tuning if
needed and some verification steps.
Please join #fedora-admin in irc.freenode.net or respond to this email to
track the status of this outage.
Fedora-devel-announce mailing list
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
With kind regards,
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
I just git a "broken dependencies" notice for a package that I maintain.
The reason is that "pdftk" got retired just the other day.
I may have missed a corresponding post on fedora-devel, but I think a
heads up notice to maintainers of depending packages may be in order
before you retire a package, as a general idea.
You see, unretiring a package is so much more work than changing
As for pdftk: I see 2 failed builds for version 1.45 and none for the
current version 2.02 (which probably breaks the api anyways). What are
the plans? Retire pdftk completely? Start fresh with pdftk2?
pdflabs, the maker of pdftk, provide binary as well as source rpms for
pdftk 2.02, by the way. I might even look into packaging it but don't
want to duplicate any existing efforts.
I just had to setup a new machine, and new ssh keys.
I chose my new id_rsa.pub to upload.
But I get:
git push --verbose
Pushing to ssh://firstname.lastname@example.org/mercurial
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
apitrace 5.0 bundles libbacktrace, which looks like is living within the
gcc sources. libbacktrace is not build as a shared library from the gcc
sources, and not packaged.
Is it feasible to build libbacktrace as a shared library and ship it in
a corresponding package? Or should I rather go for a bundling exception
Some time back there was discussion of being able to rollback yum updates via
btrfs snapshotting. As I recall, it turned out that the default btrfs install
was not setup correctly to make this feasible (I had briefly tested it on my
machine). I haven't heard anything since - this seems like a great idea.
-- Those who don't understand recursion are doomed to repeat it
Currently the #fedora channel on freenode requires some kind of
registration. In my opinion it is pretty difficult to register on
freenode (I have tried but haven't managed). Do you think it would be
possible to drop the registration requirement? It is a pretty big
barrier to newbies and people like me who can't find IRC help easily.
I know there are a lot of bots and spam, but maybe it would be
possible to try and see if it really gets bad?
= Proposed System Wide Change: Glibc locale subpackaging =
* Mike Fabian <mfabian At redhat DOT com>
* Siddhesh Poyarekar <spoyarek AT redhat DOT com>
* Carlos O’Donell <codonell AT redhat DOT com>
This change should make it possible to install or uninstall locales individually.
== Detailed Description ==
Currently the file /usr/lib/locale/locale-archive contains all locales and is thus huge (103MB).
For small systems (and containers) it would be useful to be able to install only a small number of locales.
Recently we made it possible to install a small number of locales by supplying the rpm-macro “_install_langs”, for example
rpm -i -D _install_langs="en:de_DE" glibc-common.rpm
will install all English locales and all German locales which start with “de_DE”,
rpm -i -D _install_langs="en_US.utf8" glibc-common.rpm
will install only the en_US.utf8 locale,
rpm -i -D _install_langs="POSIX" glibc-common.rpm
will install nothing (but the POSIX/C is still available because it is builtin into glibc).
But this approach works only during an Anaconda based install when Anaconda supplies the _install_langs rpm-macro.
When glibc is updated later, the _install_langs macro will not be supplied on the command line during the update and the default value “all” of “_install_langs” from /usr/lib/rpm/macros will be used and all locales come back during an update.
Therefore, this solution is far from perfect.
It should be made possible to install and uninstall locales individually, for example by having a separate package for the locales for each language. Installing such a package would add these locales to locale-archive, uninstalling it would remove them.
Anaconda then needs to be changed to handle such language packages.
== Scope ==
* Proposal owners:
1. Figure out the best approach to to install/uninstall locales
2. Make sure that locales added manually by the user are not destroyed (currently they are lost when glibc is updated)
* Other developers:
Anaconda needs to be made aware of the new approach to handle installation/uninstallation of locales
* Release engineering:
I am not sure whether this has affects release engineering, probably the packages in the install image change when parts are split out of glibc-common.
* Policies and guidelines:
No, this change does not require updates to policies and guidelines.
* Trademark approval: not needed for this Change
devel-announce mailing list