Reproducible builds/bootstrap
by Pablo Greco
I'm starting to work on a project to make Fedora fully reproducible and bootstrappable from scratch.
I know it is a long term plan and still working on the steps, but it would be good to know the current status, if there is an internal interest in this, if someone is already working (or planning to).
Thanks for the info.
Pablo
3 years, 6 months
F34 Change proposal: DNS Over TLS (System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DNS_Over_TLS
== Summary ==
Fedora will attempt to use DNS over TLS (DoT) if supported by
configured DNS servers.
== Owner ==
* Name: [[User:catanzaro|Michael Catanzaro]]
* Email: <mcatanzaro(a)redhat.com>
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: <zbyszek(a)in.waw.pl>
== Detailed Description ==
We will build systemd with `-Ddefault-dns-over-tls=opportunistic` to
protect DNS queries against passive network attackers. An active
network attacker can trivially subvert this protection, but we cannot
make DoT mandatory because other operating systems do not do so and
many (or most?) DNS servers do not support it. DoT will only be used
if the configured DNS server supports it and if it is not blocked by
an active network attacker.
Note that DoT is different from DNS over HTTPS (DoH). In particular,
DoT is not an anti-censorship tool like DoH. It does not look like
regular HTTPS traffic, and it can be blocked by network administrators
if desired, so it should not be a problem for corporate networks.
== Benefit to Fedora ==
DNS queries are encrypted and private by default, if the user's ISP
supports DoT. Most probably don't, but users who manually configure a
custom DNS server (e.g. Cloudflare or Google) will automatically
benefit from DNS over TLS.
== Scope ==
* Proposal owners: change meson flags in systemd.spec
* Other developers: N/A (nothing should be required)
* Release engineering: [https://pagure.io/releng/issue/9772 #9772] (a
check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A (nothing should be required)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: Nope
== Upgrade/compatibility impact ==
DoT will be enabled automatically on upgrade to F34. If DoT is
unsupported, systemd-resolved will fall back to unencrypted DNS, so
there should be no compatibility impact.
== How To Test ==
Load any website in a web browser. If you succeed, then name
resolution probably works.
Try using `resolvectl query fedoraproject.org` to see that resolvectl
still works.
Bonus points: set your DNS server to 1.1.1.1 or 8.8.8.8, then use
Wireshark to see if your DNS is really encrypted or not.
== User Experience ==
Users should not notice any difference in behavior.
== Dependencies ==
No dependencies.
== Contingency Plan ==
* Contingency mechanism: revert the change
* Contingency deadline: can be done at any time, before F34 beta
freeze would be best
* Blocks release? No
* Blocks product? No
== Documentation ==
See the section `DNSOverTLS=` in the manpage `resolved.conf(5)`
== Release Notes ==
systemd-resolved now enables DNS over TLS (DoT) support by default, in
opportunistic mode. DoT will be used only if supported by your DNS
server, and provides only best-effort encryption to protect against
passive network observers. For compatibility with existing DNS
servers, systemd-resolved will fall back to unencrypted DNS if DoT
does not appear to be supported, reducing the security benefit. If you
wish to manually configure systemd-resolved to prevent fallback to
unencrypted DNS, set `DNSOverTLS=yes` in `/etc/systemd/resolved.conf`.
Note that DoT is different than DNS over HTTPS (DoH) in that it does
not use HTTPS and is therefore easy to distinguish from HTTPS traffic.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 6 months
Fedora 33 System-Wide Change proposal: systemd-resolved
by Ben Cotton
https://fedoraproject.org/wiki/Changes/systemd-resolved
== Summary ==
Enable systemd-resolved by default. glibc will perform name resolution
using nss-resolve rather than nss-dns.
== Owner ==
* Name: [[User:catanzaro| Michael Catanzaro]]
* Email: <mcatanzaro(a)redhat.com>
== Detailed Description ==
We will enable systemd-resolved by default.
# We will change the
[https://src.fedoraproject.org/rpms/fedora-release/blob/f4cc5b6ce095bb4233...
fedora-release presets] to enable systemd-resolved instead of disable
it.
# systemd-libs currently has
[https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8e...
a %post scriplet] to enable nss-myhostname and nss-systemd by either
(a) modifying authselect's user-nsswitch.conf template, if authselect
is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We
will work with the systemd maintainers to enable nss-resolve here as
well.
# We will work with the authselect maintainers to update authselect's
minimal and nis profiles to enforce nss-resolve. These profiles modify
the hosts line of /etc/resolv.conf. (By default, Fedora uses
authselect's sssd profile, which does not modify the hosts line and
therefore does not have this problem.)
# We will remove our downstream patch to systemd that prevents systemd
from symlinking /etc/resolv.conf to
/run/systemd/resolve/stub-resolv.conf on new installs. For system
upgrades, a systemd-libs %post scriptlet will be used to reassign the
symlink during upgrade. Upon detecting this symlink, NetworkManager
will automatically enable its systemd-resolved support and configure
split DNS as appropriate.
systemd-resolved has been enabled by default in Ubuntu since Ubuntu
16.10, but please note we are doing this differently than Ubuntu has.
Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional
nss-dns provided by glibc upstream, so glibc on Ubuntu continues to
read /etc/resolv.conf, as is traditional. This extra step is not
useful and not recommended by upstream. We want to follow upstream
recommendations in using nss-resolve instead.
If you do not wish to use systemd-resolved, then manual intervention
will be required to disable it:
* Modify /etc/authselect/user-nsswitch.conf and remove `resolve
[!UNAVAIL=return]` from the hosts line. Run `authselect
apply-changes`. (If you have disabled authselect, then edit
/etc/nsswitch.conf directly.)
* Disable and stop systemd-resolved.service.
* Restart the NetworkManager service. NetworkManager will then create
a traditional /etc/resolv.conf. (If you are not using NetworkManager,
you may create your own /etc/resolv.conf.)
== Benefit to Fedora ==
=== Standardization ===
Fedora will continue its history of enabling new systemd-provided
services whenever it makes sense to do so. Standardizing on upstream
systemd services is beneficial to the broader Linux ecosystem in
addition to Fedora, since standardizing reduces behavior differences
between different Linux distributions. Sadly, Fedora is no longer
leading in this area. Ubuntu has enabled systemd-resolved by default
since Ubuntu 16.10, so by the time Fedora 33 is released, we will be
three years behind Ubuntu here.
=== resolvectl ===
`resolvectl` has several useful functions (e.g. `resolvectl status` or
`resolvectl query`) that will be enabled out-of-the-box.
=== Caching ===
systemd-resolved caches DNS queries for a short while. This can
[https://gitlab.gnome.org/GNOME/glib/-/merge_requests/682#note_441846
dramatically] improve performance for applications that do not already
manually cache their own DNS results. (Generally, only web browsers
bother with manually caching DNS results.)
=== Split DNS ===
When systemd-resolved is enabled, users who use multiple VPNs at the
same time will notice that DNS requests are now sent to the correct
DNS server by default. Previously, this scenario would result in
embarrassing "DNS leaks" and, depending on the order that the VPN
connections were established, possible failure to resolve private
resources. These scenarios will now work properly. For example,
consider the scenario of Distrustful Denise, who (quite reasonably)
does not trust her ISP. Denise uses a public VPN service,
public-vpn.example.com, to hide her internet activity from her ISP,
but she also needs to use her employer's corporate VPN,
corporation.example.com, in order to access internal company resources
while working from home. Using the Network panel in System Settings,
Denise has configured her employer's VPN to "use this connection only
for resources on its network." Distrustful Denise expects that her
employer's VPN will receive all traffic for corporation.example.com,
and no other traffic. And while this mostly works in Fedora 32, she
discovers that it does not work properly for DNS:
* If Denise connects to public-vpn.example.com first and
corporation.example.com second, she is unable to access internal
company resources. All DNS requests are sent to
public-vpn.example.com's DNS server, so she is unable to resolve names
for internal company websites.
* If Denise connects to corporation.example.com first and
public-vpn.example.com second, then she is able to access internal
company resources. However, it only works because ''all'' her DNS
requests are sent to corporation.example.com's DNS server. Sadly for
Distrustful Denise, her employer discovers that she has been making
some embarrassing DNS requests that she had expected to go through
public-vpn.example.com instead.
Whichever VPN Denise connects to first receives all DNS requests
because glibc's nss-dns module is not smart enough to split the
requests. /etc/resolv.conf is just a list of DNS servers to try in
order, and NetworkManager has no plausible way to decide which to list
first, because both ways are broken, so it just prefers whichever was
connected first. And if one server fails to respond, then the next
server in the list will be tried, likely resulting in a DNS leak. In
contrast, when systemd-resolved is enabled, it will send each DNS
request only to the correct DNS server. The DNS server that will be
used for each tun interface can be inspected using the resolvectl
tool.
Migrating away from /etc/resolv.conf will also avoid an annoying
footgun with this legacy file: only the first three listed nameservers
are respected. All further nameservers are silently ignored.
NetworkManager adds a warning comment when writing more than three
nameservers to this file, but it cannot do any better than that.
=== DNS over TLS ===
systemd-resolved supports DNS over TLS (different from DNS over
HTTPS). Although this feature will not initially be enabled by
default, using systemd-resolved will enable us to turn on DNS over TLS
in a future Fedora release, providing improved security if the user's
DNS server supports DNS over TLS.
== Scope ==
* Proposal owners: We will update Fedora presets to enable
systemd-resolved by default.
* Other developers: This change requires coordination with the systemd
and authselect maintainers.
* Release engineering: [https://pagure.io/releng/issue/9367 #9367]
* Policies and guidelines: none required
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
systemd-resolved will be enabled automatically when upgrading to
Fedora 33. After upgrade, /etc/resolv.conf will be managed by systemd
and symlinked to /run/systemd/resolve/stub-resolv.conf. '''glibc will
no longer look at /etc/resolv.conf when performing name resolution.'''
Instead, glibc will communicate directly with systemd-resolved via
nss-resolve. systemd adds a large warning comment to the top of
/etc/resolv.conf to warn system administrators that changes to this
file will be ignored; however, scripts that edit this file manually
will break. Because this file is usually managed by NetworkManager,
impact to Fedora users will be limited to users who have manually
disabled NetworkManager; such users are expected to be experienced
system administrators who should be comfortable adapting to the change
(or disabling systemd-resolved).
Any applications that bypass glibc and read /etc/resolv.conf directly
will still work because /etc/resolv.conf will point to
systemd-resolved's stub resolver running on 127.0.0.53. Nevertheless,
/etc/resolv.conf is provided only for compatibility purposes, and
applications should prefer to use either glibc or the systemd-resolved
D-Bus API instead; see systemd-resolved(8) for details.
In short, '''applications that read /etc/resolv.conf will continue to
work as before.''' Applications that write to it will no longer work
as expected, but this only previously worked if NetworkManager is
disabled, a non-default configuration. It remains possible to disable
systemd-resolved if desired. Otherwise, any custom system
administration scripts that manage /etc/resolv.conf will need to be
updated.
=== DNSSEC ===
systemd-resolved's DNSSEC support is known to cause compatibility
problems with certain network access points. Per recommendation from
the systemd developers, we will change the default value of this
setting in Fedora from the upstream default `DNSSEC=allow-downgrade`
to `DNSSEC=no` by building systemd with the build option
`-Ddefault-dnssec=no`. The upstream default attempts to use DNSSEC if
it is working, but automatically disable it otherwise, allowing
man-in-the-middle attackers to disable DNSSEC. Sadly, even the
allow-downgrade setting suffers known compatibility problems. Because
Fedora is not prepared to handle an influx of DNSSEC-related bug
reports, we will disable this feature altogether. We anticipate that
enabling DNSSEC by default will not be possible in the foreseeable
future, or perhaps ever. Instead, enabling DNS over TLS (when
supported by the DNS server) seems likely in the near future.
=== Multicast DNS ===
systemd-resolved's multicast DNS support conflicts with Avahi. Per
recommendation from the systemd developers, we will change the default
value of this setting in Fedora from the upstream default
`MulticastDNS=yes` to `MulticastDNS=resolve`. Multicast DNS resolving
will be enabled, but responding will be disabled. This will require
adding a new systemd build option to control the default value of the
MulticastDNS setting, similar to the existing `default-dnssec` and
`default-dns-over-tls` build options.
== How To Test ==
Load any website in a web browser. If you succeed, then name
resolution probably works.
Try using `resolvectl status` and, for example, `resolvectl query
fedoraproject.org`, to see how they work and sanity-check their
output.
Users who use multiple VPNs at the same time are encouraged to test
DNS in a multiple VPN scenario, to ensure that DNS requests are sent
to the expected DNS server.
== User Experience ==
See the Benefit to Fedora section, above, for direct benefits to users
who use multiple VPNs at the same time.
Users will be able to use the resolvectl tool and the functionality it provides.
/etc/resolv.conf will now be managed by systemd rather than by
NetworkManager. As before, this file must not be modified directly
when it is managed.
== Dependencies ==
In Fedora, /etc/nsswitch.conf is managed by authselect. By default,
authselect uses the sssd profile to generate configuration compatible
with sssd. In this mode of operation, it does not modify the hosts
line in /etc/nsswitch.conf. This is also true if using the winbind
profile instead of the sssd profile. However, authselect's minimal and
nis profiles do modify the hosts line. These authselect profiles must
be updated to enable nss-resolved. If you are using authselect in one
of these modes, it will not be possible to cleanly disable
systemd-resolved because the hosts line in /etc/nsswitch.conf will be
clobbered whenever 'authselect apply-changes' is run. If you wish to
disable systemd-resolved and you are using authselect in one of these
modes, then you should stop using authselect. This is not expected to
cause many problems because virtually all Fedora users will be using
the default sssd profile.
We do not need to directly make any changes to the /etc/nsswitch.conf
shipped by glibc. Changes will be applied in the systemd-libs %post
scriptlet.
== Contingency Plan ==
The contingency plan, in the unlikely event of unexpected problems, is
simply to revert any changes and not enable systemd-resolved.
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
* systemd-resolved is documented in several manpages: resolvectl(1),
resolved.conf(5), nss-resolve(8), systemd-resolved(8).
* [https://wiki.archlinux.org/index.php/Systemd-resolved Arch Wiki
documentation]
* [https://wiki.gnome.org/Projects/NetworkManager/DNS NetworkManager
DNS documentation]
== Release Notes ==
systemd-resolved is now enabled by default. systemd-resolved provides
a system-level DNS cache that can substantially improve performance
for applications that do not cache their own DNS results, allows
correct handling of split DNS scenarios such as when multiple VPNs are
in use, and will allow Fedora to enable DNS over TLS in the future.
/etc/resolv.conf will now be managed by systemd-resolved rather than
by NetworkManager. /etc/resolv.conf will no longer be read when
performing name resolution using glibc; however, it is still provided
for compatibility with applications that manually read this file to
perform name resolution. Writing to /etc/resolv.conf will no longer
work as expected.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 6 months
F34 Change proposal: Debug Info Standardization (from DWZ to
-fdebug-types-section) (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DebugInfoStandardization
== Summary ==
Fedora 18 implemented [[Features/DwarfCompressor]]. As the format did
not get widespread and the tool is not much maintained it became
burden to make existing debugging tools compatible with Fedora debug
info.
== Owner ==
* Name: [[User:jankratochvil| Jan Kratochvil ]]
* Email: jan.kratochvil(a)redhat.com
== Detailed Description ==
Debug info files *.debug contained in *-debuginfo.rpm are very big in
general (x86_64 Fedora 32 distribution has debug/ directory of 82GB
while all its other files are only 75GB). There exist several methods
how to make the *-debuginfo.rpms at least a bit smaller. Fedora 18
started using DWZ tool (from [[Features/DwarfCompressor]]) while
[https://gcc.gnu.org/pipermail/gcc-patches/2008-August/246281.html
Google implemented] the same goal in a different way called
-fdebug-types-section.
Almost nobody uses existing Fedora DWZ (only Fedora/CentOS/RHEL and
SuSE OSes) and so its support is missing in tools like
[https://lldb.llvm.org/ LLDB],
[[llvm-dwarfdumphttps://llvm.org/docs/CommandGuide/llvm-dwarfdump.html|llvm-dwarfdump]]
or binutils readelf. -fdebug-types-section is used internally by
Google (produced by clang). Debian does not store any debug info
archives. Ubuntu uses neither -fdebug-types-section nor DWZ.
* DWZ advantage: On the whole Fedora distro it saves 3.3% (5GB of the
157GB distribution size)
** If the 3.3% size increase is a concern I can implement a different
optimization ([https://whova.com/embedded/session/llvm_202010/1193947/
talk (2)]) as a GCC post-processing phase which would require no
changes in any DWARF consumers.
* DWZ disadvantage: DWZ has currently less support across consumers
(LLDB, llvm-dwarfdump, binutils readelf)
* DWZ disadvantage: DWZ requires 8x times more complicated (LoC count)
support in consumers than -fdebug-types-section.
* DWZ disadvantage: DWZ cannot update LLVM .debug_names index which
can be generated only by clang (it cannot be regenerated later for
DWZ-compressed file)
* DWZ disadvantage: DWZ DWARF-5 support is a work-in-progress. DWZ has
been blocking DWARF-5 for Fedora for 3.5 years and only after I have
now proposed to drop DWZ Mark Wielaard has started porting DWZ to
DWARF-5. It can be expected next DWARF extensions will remain
unsupported again. Even currently there is no plan to support DWARF-5
features used by clang which may need -fdebug-types-section for
clang-built binaries or no size optimization of clang-built debug info
at all.
* DWZ disadvantage: Compilation (linking) requires for C++ up to 2x as
big disk space (as DWZ is processing files after linker and DWZ is
incompatible with -fdebug-types-section)
* DWZ disadvantage: Compilation (linking) is slower
This proposed DWARF format was originally submitted already for Fedora
18 as [[Features/DebugTypesSections]].
== Benefit to Fedora ==
* Better compatibility with existing debugging and tracing tools,
primarily [https://lldb.llvm.org/ LLDB].
* Less resource-intensive rebuilds of C++ packages (in disk space,
memory requirements and compilation time).
== Scope ==
* Proposal owners: It affects all packages generating *-debuginfo.rpm,
that is compiled (not scripted) languages.
* Other developers: Report any possible debuginfo incompatibility (unexpected).
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed)
* Policies and guidelines: All the needed changes should be done in
[https://src.fedoraproject.org/rpms/redhat-rpm-config
redhat-rpm-config]. The [https://src.fedoraproject.org/rpms/dwz dwz
package] can be then retired.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: The size differences are only for
*-debuginfo.rpm which is outside of scope of the listed objectives.
== Upgrade/compatibility impact ==
As *-debuginfo.rpm have to exactly match NVRA of its binary package
the compatibility is not relevant. Existing tools supporting DWZ will
still support the DWZ file format in packages which have not been
rebuilt.
== How To Test ==
The change will update
[https://src.fedoraproject.org/rpms/redhat-rpm-config
redhat-rpm-config] by
[https://people.redhat.com/jkratoch/redhat-rpm-config-fdebug-types-section...
an -fdebug-types-section patch].
Then one can use rpmbuild to rebuild a package. For mock use
-a|--addrepo with modified redhat-rpm-config.rpm (with increased
NVRA). For packages already rebuilt in Koji nothing is needed.
Test programs like lldb and gdb if they still can print source code,
function parameters, variables etc.
One should also verify integrated testsuites of tools like clang,
lldb, gcc, binutils, gdb, elfutils or rpm are not regressing with the
-fdebug-types-section option.
One can also compare *.debug files built with/without DWZ and/or
-fdebug-types-section using
[https://src.fedoraproject.org/rpms/libabigail libabigail] utility
dwdiff but that will be rather done by the change owner.
== User Experience ==
No user visible change. This affects what tools can developers use.
== Dependencies ==
none
== Contingency Plan ==
* Contingency mechanism: Revert the change in
[https://src.fedoraproject.org/rpms/redhat-rpm-config
redhat-rpm-config]. Fedora can continue using DWZ, just some
debugging/tracing tools will stay incompatible.
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? N/A
== Documentation ==
* [http://www.dwarfstd.org/doc/DWARF5.pdf DWARF-5] E.2 Using Type Units
* [https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-fdebug-ty...
GCC -fdebug-types-section]
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 6 months
readelf seems broken in F33
by Steve Grubb
Hello,
I was doing some binary analysis of files in F33 and have run across something odd.
readelf -s /usr/sbin/auditd | grep GLIBC
produces a lot of output like:
182: 0000000000000000 0 FUNC GLOBAL DEFAULT UND [...](a)GLIBC_2.2.5 (3)
184: 0000000000000000 0 FUNC GLOBAL DEFAULT UND [...](a)GLIBC_2.2.5 (3)
185: 0000000000000000 0 FUNC GLOBAL DEFAULT UND [...](a)GLIBC_2.2.5 (3)
186: 0000000000000000 0 FUNC GLOBAL DEFAULT UND [...](a)GLIBC_2.2.5 (3)
187: 0000000000000000 0 FUNC GLOBAL DEFAULT UND [...](a)GLIBC_2.3.2 (2)
191: 0000000000000000 0 FUNC GLOBAL DEFAULT UND alarm(a)GLIBC_2.2.5 (3)
194: 0000000000000000 0 FUNC GLOBAL DEFAULT UND [...](a)GLIBC_2.2.5 (3)
195: 0000000000000000 0 FUNC GLOBAL DEFAULT UND close(a)GLIBC_2.2.5 (3)
197: 0000000000000000 0 FUNC GLOBAL DEFAULT UND [...](a)GLIBC_2.2.5 (3)
It's missing a lot of symbols. Is this something with readelf or an odd
effect of the LTO changes?
-Steve
3 years, 6 months
Orphaning openbabel
by Dominik 'Rathann' Mierzejewski
Hi everyone,
I've finally admitted to myself that I have no time to take good care
of openbabel:
https://src.fedoraproject.org/rpms/openbabel
It has one FTBFS bug in rawhide (related to cmake macro changes)
and two requests to update. One in Fedora to move to the recent 3.x
series and one for EPEL to update from 2.3 to 2.4.
It has 9 consumers in Fedora:
avogadro
avogadro2
chemtool
ghemical
gnome-chemistry-utils
IQmol
kalzium
molsketch
xdrawchem
Hopefully, one of their maintainers (Bcc'd) or someone from SciTech SIG
(Cc'd) can pick this up.
I'll orphan it in a few days if nobody responds here with their
FAS ID.
Regards,
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
3 years, 6 months
Orphaning vdr-skinsoppalusikka and the status of my packages (looking
for co-maintainers for Finnish spell checking)
by Ville-Pekka Vainio
Hi all,
As some of you may have noticed, I have been away from Fedora
packaging for quite a while. I've been hoping to find the time for
packaging work, but it hasn't happened. In hindsight, I should have
let the project know earlier.
I have now orphaned vdr-skinsoppalusikka, because I don't have a
working VDR installation anymore. If someone has the ability, my user
(vpv) can be dropped from the packages vdr, vdr-epgsearch, vdr-femon
and vdr-osdteletext.
My main interest in Fedora packaging used to be Finnish spell
checking. The spell checking stack, consisting of libreoffice-voikko,
libvoikko, voikko-fi and foma (as a dependency) went through quite
major changes in 2017-2019. The vocabulary package voikko-fi requires
foma to build. I managed to get the foma package reviewed and into
Fedora in 2018. It was automatically orphaned and then retired due to
FTBFS (https://src.fedoraproject.org/rpms/foma). The code has now been
fixed in Github (https://github.com/mhulden/foma) and it should build,
but I haven't tried it yet. If I get it to build, I might ask for it
to be added back. It seems like I'll be able to work on packaging for
a few days a year, so don't expect any miracles.
Once foma is built, voikko-fi can be built. Even though it shares some
history with the previous vocabulary package malaga-suomi-voikko, it
probably needs a new review. Then libvoikko could be updated to use
the new vocabulary. If anyone is interested in working on these, I
would be happy to get co-maintainers.
I'm willing to stay as a co-maintainer of gpodder and
python-mygpoclient. I code Python at $DAYJOB so I might be able to
help.
Best regards,
Ville-Pekka Vainio (vpv)
3 years, 6 months
paranoid md raid1 -> Btrfs migration tools?
by Daniel Pocock
Are there any tools in Fedora to help people migrate an md RAID1 array
to btrfs, with data verification checks?
For example
1) check for differences between source file sectors on each source drive
2) for each file, if the file format has a checksum, check it somehow
and alert on failures
The new emphasis on Btrfs is interesting but it is not much help if
people copy in files that are already spoiled. If people can still
recover a good copy from their md array then it is a good idea to do so.
I could imagine using kpartx to script a solution to (1) above, skipping
over the md headers. Some kind of shim may be needed to fool the kernel
to see a different UUID for each source volume so they can be mounted
simultaneously without md.
Regards,
Daniel
3 years, 6 months
