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
currently default error policy for printers in Fedora is "Stop printer" on
any error which is a really bad default. I have run across this issue LOTS
of times with regular Fedora desktop users who don't get why has their
printer stopped working, there is no UI queue to warn users, there is no
easy way to "Start printer" with one click after it has been stopped. It is
just a big mess.
Even worse, previous versions of Gnome control panel (if I remember
correctly) had option to change default error policy, now that option is
removed and you can get to it only by installing system-config-printers
tool, something regular users have no idea about even exists, and it is not
installed by default.
There are too many examples which are simple user errors but result in
priner going offline (stopped) and this is really bad, because after any
small error users can't print any more.
For example: user trying to print while he/she is not at home so his/hers
printer is not available, user trying to print but has forgot to connect
usb priner cable, user trying to print but haven't turned it on, user
printing to wifi printer but while connected to different wifi network...
Any of these actions is simple uses error but results in permanently
disabling of priner (Stops printer) and users can't print even when they
resolve issue that was stopping them from accessing the printer.
Now Fedora is what is stopping them from printing.
Who is responsible for user experience of Fedora desktop? To whom should I
point this issue to?
I'm sure those that need to know, know, but for those that haven't heard
Mozilla's official Firefox build will enforce addons to contain a Mozilla signature
without any runtime option to disable the check.
Initially this prevents Fedora packaged addons since they are unsigned. The Mozilla
signing process takes time and can't be part of a package building process.
Is Fedora going to get authorization to build Firefox with a runtime disable option?
= Proposed Self Contained Change: RPM MPI Requires Provides =
Change owner(s): Sandro Mani <manisandro at gmail dot com>
Have the rpm-build find-provides and find-requires scripts encode the MPI compiler name in the provides string of a binary to distinguish otherwise identical provides between packages $foo, $foo-openmpi and $foo-mpich.
== Detailed Description ==
Currently, the packages libfoo, libfoo-openmpi and libfoo-mpich providing the library libfoo.so all have a provides string of i.e.
While yum used a shortest-package-name rule to choose which package to pick, dnf does not have any rules, and seems to just pick the first match it comes across. Currently the only solution would be to filter the provides from the -openmpi, -mpich packages and add explicit Requires: where needed. I'd like to propose to extend the provides string in such way that it also encodes the MPI implementation, i.e.:
$ rpm -qp --provides libfoo
$ rpm -qp --provides libfoo-mpich
$ rpm -qp --provides libfoo-openmpi
To this end, I'm proposing to adapt the find-requires and find-provides scripts as (or similarly to):
Discussion of these changes are tracked in bug #1232504.
This change is intended to coordinate the rebuild of all MPI related packages to ensure all such packages consistently use the new provides format.
== Scope ==
* Proposal owners:
- Work on find-provides and find-requires based on feedback.
- As soon as updated find-provides and find-requires shipped with rpm-build, do a mass-rebuild of all MPI packages.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
devel-announce mailing list
Over the last few months (since Fedora 22 beta's release), I've been using
Btrfs as my daily driver filesystem across a multitude of machines. After
Fedora 22 released, I tried it with RAID 5 and RAID 6 enabled on a few
machines with fantastic success (there aren't even any scary warnings about
being experimental anymore!).
Admittedly, my tests have been specific to my needs (media center storage,
workstations, laptops with SSDs, etc.), but it appears to work really well
Also, with kernel 4.1 imported into rawhide, we've now got performance
improvements for large (>20TB) filesystems (though it's been plenty fast
for my 48TB array).
As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs becoming
the default in Fedora 23
At this point, I'm personally convinced that it is certainly ready and
doable for F23.
Perhaps other guys with more experience on this stuff could chime in with
feedback/information/etc, but it feels like we should start the process to
get everything ready for Btrfs being default in Fedora 23.
The question now is: as a distribution, where are we on this? The tools
seem to work, the filesystem appears stable, and I've not been able to
cause the filesystem to corrupt itself with any kind of user error or cause
it to keel over. So, what's left?
真実はいつも一つ！/ Always, there's only one truth!
I opened https://bugzilla.redhat.com/show_bug.cgi?id=1221923
about this too but thought it would be good to ask here.
F22 currently has llvm-3.5.0 (F23 is now on 3.6.0):
I believe there is a newer 3.5.2 bugfix release -
would it make sense to make a F22 update for that?
Is there any expected risk with doing that?
Anyway for F23 I probably have to make a llvm35 package
again for building ghc-7.10 on armv7 (and ideally aarch64).
3.5.0 has a critical bug that breaks ghc, so it would
be based on 3.5.2 anyway.