Where are armv7hl, i686 and ppc64le Container tar.xz files?
by Jun Aruga
I am looking for arch container archive files like
"Fedora-Container-Base-30-1.2.aarch64.tar.xz
" for Fedora 30.
I found the x86_64, aarch64 and s390x's archive files in below directory.
But where is the archive file of armv7hl, i686 and ppc64le?
I assume the multi archs except x86_64, aarch64 and s390x existed in
the age of Fedora 24, 25 in below releases directory.
And why below s390x does not have Fedora-Container-Base-*.tar.xz?
https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/
x86_64/
images/
Fedora-Container-Base-30-1.2.x86_64.tar.xz
Fedora-Container-Minimal-Base-30-1.2.x86_64.tar.xz
aarch64/
images/
Fedora-Container-Base-30-1.2.aarch64.tar.xz
Fedora-Container-Minimal-Base-30-1.2.aarch64.tar.xz
https://dl.fedoraproject.org/pub/fedora-secondary/releases/30/Container/
s390x/
images/
Fedora-Container-Minimal-Base-30-1.2.s390x.tar.xz
=> No Fedora-Container-Base-*.tar.xz
Thanks.
--
Jun Aruga / He - His - Him
jaruga(a)redhat.com / IRC: jaruga
1 year, 6 months
F31 Self-Contained Change proposal: Include several modules in the
EFI build of Grub2 for security use-cases
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2
== Summary ==
Include Grub's "verify," "cryptodisk" and "luks" modules (and if
necessary, relevant "gcry" modules) in grubx64.efi of the
'grub2-efi-x64' package.
== Owner ==
* Name: [[User:pjones| Peter Jones]]
* Email: pjones(a)redhat.com
* Name: [[User:javierm| Javier Martinez Canillas]]
* Email: fmartine(a)redhat.com
== Detailed Description ==
Users utilising secure boot functionality on the UEFI platform cannot
insert modules that aren't in grubx64.efi. Paradoxically, this means
that security-conscious users cannot use grub's verify module, or
employ (near) full disk encryption using cryptodisk and luks.
The security benefits of signature verification would reach more users
if Fedora automated it by incorporating the process into
grub2-mkconfig.
For the long-term, to grant flexibility with grub2 modules on secure
boot instances, it may be advisable to sign the .mod files in the
'grub2-efi-x64-modules' package, modify grub2-mkconfig (or -install)
to copy the necessary modules into the EFI partition when required by
the user's configuration and then allow inserting of signed modules in
secure boot instances.
== Benefit to Fedora ==
This change will allow users to gain trust in the integrity of
early-launch code either through verification of signatures
(particularly useful for initramfs, which is particularly vulnerable
to possible offline modification) or encryption of the boot partition.
== Scope ==
* Proposal owners: Modify grub.macros file to include the
above-mentioned modules in the GRUB_MODULES variable.
* Other developers: 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)
== Upgrade/compatibility impact ==
Change only adds modules, so existing users should have no problems.
== How To Test ==
<b>For "verify":</b>
1. Generate a signing key with "gpg --gen-key" and copy it to the EFI partition
2. Add "trust <gpg key>" (but grub may inherit this from shim's MOK)
and "set check_signatures=enforce" to /etc/default/40_custom
3. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
4. Create a file, /tmp/pass, with the key's passphrase, then execute:
for x in $(find /boot -name "*.cfg" -or -name "*.mod" -or -name
"vmlinuz*" -or -name "initramfs*" -or -name "grubenv"); do gpg --batch
--detach-sign --passphrase-fd 0 $x < /tmp/pass; done. Then, shred
/tmp/pass
5. Reboot. If system starts, change is successful
<b>For cryptography modules:</b>
1. Backup boot partition
2. Run cryptsetup luksFormat <boot partition's block device, for
example, /dev/sda2> --type luks1
3. Open luks container and restore backup
4. Add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub
5. Confirm that /etc/fstab has the correct UUID for /boot
6. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
7. Reboot. Grub should ask for the password created in step 2. If
system then starts, change is successful
(If filesystem root is also encrypted, user may be asked for a
password twice. This can be mitigated with a keyfile for filesystem
root, or use of the clevis package, and likely, a tpm.)
== User Experience ==
Users may optionally elect to verify the integrity of boot code either
through verification of digital signatures or encryption of the boot
partition.
== Dependencies ==
Grub2-efi-x64-modules and grub2-tools-* depend on this package, but
require no change.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Revert the
shipped configuration
* Contingency deadline: Beta freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? No
== Documentation ==
https://www.gnu.org/software/grub/manual/grub/html_node/Using-digital-sig...
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system...
== Release Notes ==
Fedora now supports Grub's detached verify and cryptodisk
functionality natively, even on secure boot systems.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
1 year, 7 months
rpmlint: library-not-linked-against-libc (parts of Python stdlib,
after gcc 9)
by Miro Hrončok
I've just spotted these when working on Python 3.8.0a1. This happens on 3.7 as
well since GCC 9:
python3-debug.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37dm-x86_64-linux-gnu.so
python3-debug.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_testimportmultiple.cpython-37dm-x86_64-linux-gnu.so
python3-libs.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37m-x86_64-linux-gnu.so
python3-test.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_testimportmultiple.cpython-37m-x86_64-linux-gnu.so
(Note that there are plenty of other extension modules that do not raise this
error.)
This doesn't happen with latest python3 built prior to the gcc update to 9.
$ rpmlint -I library-not-linked-against-libc
library-not-linked-against-libc:
That isn't helpful either.
I found a similar Debian thing [1] that says:
> It is theoretically possible to have a library which doesn't use any symbols
> from libc...
Do I care? Should I fix something? I honestly have no idea.
[1] https://lintian.debian.org/tags/library-not-linked-against-libc.html
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 7 months
Self Introduction: Gordon Messmer
by Gordon Messmer
Hello,
My name is Gordon Messmer. I've been a long-time user of Red Hat
systems, starting with Red Hat Linux 4.2 in 1997. I've been packaging
software in rpm format for use in business environments for very nearly
as long. I've also been a semi-active member of the Red Hat and Fedora
mailing lists most of those years.
My first contribution will be ansible-bender: a tool that builds
container images using ansible playbooks.
https://bugzilla.redhat.com/show_bug.cgi?id=1714377
1 year, 8 months
Trouble logging into pagure.io
by Arjun Shankar
Hi,
My FAS account is "submachine". I just tried logging into pagure.io, and
while the login succeeded, immediately after, I got a 404 error page with
the error 'No user "submachine" found'. All pagure.io URLs lead to the same
404, so I can't file a pagure issue for this either (which is why I'm
writing to this list after a failed attempt at asking for help on
#fedora-admin).
How can this be fixed?
Best Regards,
Arjun
1 year, 8 months
Orphaning all my packages
by Jens Lody
Dear fellow developers,
I'm no longer able to maintain my packages on Fedora, due to lack of
time and power.
I am maintainer of:
aeskulap,
astyle,
codeblocks,
dvdbackup,
gnome-dvb-daemon,
gnome-shell-extension-openweather,
gnome-shell-extension-panel-osd
All packages build (as far as I know) except for gnome-dvb-daemon which
failed to build on fc30 mass-rebuild.
The two gnome-shell-extensions should be retired in my opinion, because
they are available via extensions.gnome.org (at the moment), but as I
am also upstream maintainer, the will not be continued (at least not by
me).
I'm also upstream maintainer for aeskulap
(https://github.com/jenslody/aeskulap) but will archive the github-repo
sooner or later.
So if somebody is interested in keeping it, she/he should know this and
probably think about becoming upstream.
If anybody is interested in taking one of the projects, please let me
know and send your fas-name, so I can give it to you.
Jens (jenslody)
--
Jens Lody
|\ _,,,---,,_
/,`.-'`' -. ;-;;,_
<|,4- ) )-,_..;\ ( `'-'
'---''(_/--' `-'\_)
1 year, 8 months
glibc-arm-linux-gnu help
by Tom Callaway
A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could
have a packaged arm cross-toolchain that was useful (with glibc, it
cannot build anything in userspace). It worked for a while, but lately,
all builds have been failing with this error:
/usr/bin/arm-linux-gnu-ld: skipping incompatible
/usr/lib/gcc/arm-linux-gnueabi/8/libgcc_eh.a when searching for -lgcc_eh
I've looked at it and poked it quite a bit locally, but I can't seem to
get around that. I could really use some help to get this building
again, ideally, updated to 2.28.
All my work is committed to git, no help will be refused.
Thanks in advance,
~tom
1 year, 8 months
Node.js 12.x Plans for F31+
by Stephen Gallagher
Today, the Node.js upstream released 12.0.0, the next in its line of
long-term support releases. I plan to make this the default version of
Node.js in Fedora 31+, but not immediately. I'm currently working on
getting a modular version of 12.x built for F29, F30 and Rawhide. I'll
get that out to updates-testing this week. I'll send out an update
once it's pushed to updates-testing.
Once that's available, I encourage all NPM packagers in Fedora to
start testing their build and runtime with the 12.x module. I will be
filing a Change Proposal and plan to switch the system interpreter for
Rawhide over to 12.x around the end of May or beginning of June.
The exact timing may depend on the current status of the
modules-in-the-non-modular-buildroot work in Fedora. If that's
available by this time, I will retire the non-modular Node.js
interpreter package and make the 12.x module the default stream for
F31+. If it's not available, I'll continue to do what I've been doing
in F29 and F30; building both the modular and non-modular packages.
If you discover that you own NPM packages that are critical and do not
work with Node.js 12.x, please inform me immediately. We'll talk with
upstream and see what we can do about it.
1 year, 8 months
Intent to drop python2-tornado
by Miro Hrončok
I intend to drop python2-tornado. There are following dependent packages:
- python-httpretty
build time, for Python 2 tests, tests can be disabled
- python-pika
build time, for Python 2 tests, one file can be skipped
- python-urllib3
build time, for Python 2 tests, tests can be disabled
- salt (and salt-{api,cloud,syndic,ssh,master,minion})
runtime, python 3 switch is blocked by a fixable bug
https://github.com/saltstack/salt/issues/51883
salt is not required by anything
- uwsgi-plugin-python2-tornado (from uwsgi)
runtime, but not required by anything
- bup and bup-web
runtime and buildtime, but not required by anything
If anybody wants to package python2-tornado before we drop it, let me know in 3
weeks.
Reasons below:
-------- Forwarded Message --------
Subject: Let's update tornado to 6 and drop python2-torando
Date: Wed, 15 May 2019 16:57:57 +0200
From: Miro Hrončok <mhroncok(a)redhat.com>
Reply-To: Fedora Python SIG <python-devel(a)lists.fedoraproject.org>
Organisation: Red Hat
To: Fedora Python SIG <python-devel(a)lists.fedoraproject.org>,
abompard(a)fedoraproject.org, orion(a)fedoraproject.org, tomspur(a)fedoraproject.org
Hi.
Tornado 6 doesn't support Python 2. Let's update the python-torando package to
Python 3 only. There are several consumers of python2-torando and if their
maintainers are interested, they can package it separately.
$ dnf repoquery --repo=compose{,-source} --whatrequires python2-tornado
bup-0:0.29.2-3.fc30.src
bup-web-0:0.29.2-3.fc30.x86_64
python-httpretty-0:0.9.5-5.fc30.src
python-pika-0:1.0.1-1.fc31.src
python-urllib3-0:1.24.2-1.fc31.src
salt-0:2019.2.0-1.fc31.noarch
uwsgi-plugin-python2-tornado-0:2.0.17.1-10.fc31.x86_64
Note that tornado is often used to test things. We can (and should) just skip
such tests from Python 2 httpretty, pika and urllib3.
Is the plan OK? I'll talk to the dependent packages maintainers, but wanted to
check with torando co-maintainers first.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 8 months