Hi fellow contributors,
Upstream has reported a request for minizip naming change from "minizip" to
"minizip-ng" (minizip-ng is the official name of the upstream package right
now).
As Fedora should match the upstream naming, I believe this change is
necessary.
Another naming change is required
The latter change seems unwise. Packages which now depend on minizip (to be minizip-ng)
will continue to do depend on whatever Provides(minizip); if you rename the zlib
subpackage to minizip, they will depend on the wrong thing.
Cheers,
Marcus
On 28.07.22 10:31, Lukas Javorsky wrote:
Hi fello
On Thu, Jul 28, 2022 at 10:44:14AM +0200, Marcus Müller wrote:
> The latter change seems unwise. Packages which now depend on minizip (to be
> minizip-ng) will continue to do depend on whatever Provides(minizip); if you
> rename the zlib subpackage to minizip, they will depend on the wrong thing.
ah, true, different sonames solves this :)
On 28.07.22 10:52, Daniel P. Berrangé wrote:
On Thu, Jul 28, 2022 at 10:44:14AM +0200, Marcus Müller wrote:
The latter change seems unwise. Packages which now depend on minizip (to be
minizip-ng) will continue to do depend on whatever Provides(minizip)
Also, the idea is to file Bugs for all packages that BuildRequire/Require
the minizip package and let them know about this change and if they should
change theirs requirements.
On Thu, Jul 28, 2022 at 10:57 AM Marcus Müller wrote:
> ah, true, different sonames solves this :)
>
> On 28.07.22 10:5
I've checked the packaging that should be affected by this change on Fedora
Rawhide:
repoquery --whatrequires "*libminizip.so.3*" | pkgname | uniq
R-libSBML
collada-dom
dolphin-emu
dolphin-emu-tool
java-libsbml
keepassxc
libnuml
librasterlite2
libsbml
libspatialite
libxlsxwriter
minizip-devel
perl-
Announcing the creation of a new nightly release validation test event
for Fedora 37 Rawhide 20220728.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki
I don't know where to report this, so I'm doing it here.
The backend server that is hosting admin.fedoraproject.org/accounts/ is
throwing an HTTP 500 SSL handshake error.
This prevents us from using fedora_active_user.py
___
devel mailing list -- devel
On Thu, Jul 28, 2022, at 2:11 AM, Vojtech Trefny wrote:
> On Wed, Jul 27, 2022 at 5:53 PM Chris Murphy wrote:
>>
>>
>>
>> On Wed, Jul 27, 2022, at 11:11 AM, Chris Adams wrote:
>> > Once upon a time, Neal Gompa said:
>> >> My understanding is that Windows preloads are now blank-encrypted.
>> >>
Once upon a time, Vojtech Trefny said:
> This is also what happens if you choose to "decrypt" your BitLocker
> volume in Windows so if it is this case, cryptsetup doesn't support
> it. We intentionally ignored this case mostly because it looked like a
> small corner case (if you choose do decrypt
On Di, 26.07.22 13:37, Neal Gompa (ngomp...@gmail.com) wrote:
> > > As I already mentioned the last time this has come up: Why can we not,
> > > instead of chainloading Windows directly, chainload a systemd-boot
> > > configured to always bootnext to Windows?
> >
> > Pretty sure shim still hard co
On Wed, Jul 27, 2022 at 2:05 PM Lennart Poettering wrote:
>
> On Mi, 27.07.22 16:50, Chris Murphy (li...@colorremedies.com) wrote:
>
> > > I prefer no shim in my computers. I'm using systemd-boot signed by my
> > > own CA.
> >
> > That is not a generic solution we can ship in Fedora. Since each
>
On 22/07/28 12:06PM, Andrew Bauer wrote:
> The backend server that is hosting admin.fedoraproject.org/accounts/ is
> throwing an HTTP 500 SSL handshake error.
I would recommend filing an infra ticket:
https://pagure.io/fedora-infrastructure/new_issue. devel@ is not the
correct place to report iss
Hi all,
I need a name change review, from python-pep621 to
python-pyproject-metadata:
https://bugzilla.redhat.com/show_bug.cgi?id=2111269
I am happy to do a review for you.
--
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.f
V Thu, Jul 28, 2022 at 06:31:55AM -0700, Neal Gompa napsal(a):
> On Wed, Jul 27, 2022 at 2:05 PM Lennart Poettering
> wrote:
> >
> > On Mi, 27.07.22 16:50, Chris Murphy (li...@colorremedies.com) wrote:
> >
> > > > I prefer no shim in my computers. I'm using systemd-boot signed by my
> > > > own C
Sorry for showing up here unannounced.
This is a very strange claim. I'm not speaking in any official capacity but at
least __personally__ being at the Linux Systems Group at MSFT I've never have
encountered any hard requirement on grub.
In any case, I want to point out a few things:
* Some of t
Once upon a time, Lennart Poettering said:
> Given the overlap of the Fedora/RH boot loader folks and the shim
> folks, I think there's definitely an avenue to get systemd-boot signed
> as payload for SHIM, as alternative to Grub. If Fedora wants this, and
> has the man power for it, it should be
On Do, 28.07.22 16:54, Petr Pisar (ppi...@redhat.com) wrote:
> > This sounds pretty awesome, actually. I'd like to see that get
> > implemented...
> >
> Unfortunatelly (complex) file system drivers are not written with safety
> on mind. They rather prefer performance over security. If somebody si
On Do, 28.07.22 10:25, Chris Adams (li...@cmadams.net) wrote:
> Once upon a time, Lennart Poettering said:
> > Given the overlap of the Fedora/RH boot loader folks and the shim
> > folks, I think there's definitely an avenue to get systemd-boot signed
> > as payload for SHIM, as alternative to Gr
The accounts are now on this URL https://accounts.fedoraproject.org/
Michal
On 28. 07. 22 14:06, Andrew Bauer wrote:
I don't know where to report this, so I'm doing it here.
The backend server that is hosting admin.fedoraproject.org/accounts/ is
throwing an HTTP 500 SSL handshake error.
This
On Thu, Jul 28, 2022 at 4:32 AM Lukas Javorsky wrote:
>
> The first step I want to do is to create a Fedora Change, which contains this
> whole process and is well communicated within the community.
>
> This email serves as a heads-up and also opens a possibility for any tips
> that you can give
OK. Happy day, we have maybe come full circle. Here's my attempt at a summary:
* systemd-boot should be evaluated for Secure Boot signing, so that it can be a
viable and testable alternative bootloader to GRUB. Maybe this opens the door
to changing the default bootloader in Fedora down the road
On 26/07/2022 20:05, Chris Murphy wrote:
Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption)
out of the box with the encryption key sealed in the TPM. Two different issues
result:
Microsoft has published a new security bulletin on the current state of
Secure Boot:
h
On Thu, Jul 28, 2022 at 10:40 AM Lennart Poettering
wrote:
> ...
>
> But anyway, I am actually advocating for sticking to VFAT
> everywhere. ext4 drivers in the boot loader only are necessary for the
> upgrade path.
>
>
I'd like to 2nd the motion to try to stick with VFAT in the boot path until
r
On Thu, Jul 28, 2022, at 2:05 PM, Gregory Bartholomew wrote:
>
> Also, this might be a little off-topic, but I've recommend that people use
> systemd-boot when trying to dual-boot Windows before:
> https://ask.fedoraproject.org/t/dual-booting-windows-10-and-fedora-34/14158/2
> The user repor
On Thu, Jul 28, 2022 at 1:34 PM Chris Murphy
wrote:
> Seems to me the only valid type code for a merged ESP+XBOOTLDR is ESP.
> What am I missing?
>
Right. I'd like to use the ESP type code for the merged ESP+XBOOTLDR so
that the firmware will pick it up properly. The only problem is when using
t
On Thu, Jul 28, 2022, at 2:47 PM, Gregory Bartholomew wrote:
> On Thu, Jul 28, 2022 at 1:34 PM Chris Murphy wrote:
>> Seems to me the only valid type code for a merged ESP+XBOOTLDR is ESP. What
>> am I missing?
>
> Right. I'd like to use the ESP type code for the merged ESP+XBOOTLDR so that
>
On Do, 28.07.22 13:05, Gregory Bartholomew (gregory.lee.bartholo...@gmail.com)
wrote:
> VFAT-formatted version of the partition somewhere and perhaps leave the old
> one as a (temporary) failback. Besides the bootloader itself, all that is
> really on the /boot partition is the kernel and initram
On Do, 28.07.22 15:03, Chris Murphy (li...@colorremedies.com) wrote:
> > Right. I'd like to use the ESP type code for the merged ESP+XBOOTLDR so
> > that the firmware will pick it up properly. The only problem is when using
> > the bootctl command to initialize that partition (/boot), it require
Thank you, and done.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https:
On Thu, Jul 28, 2022 at 3:17 PM Lennart Poettering
wrote:
> On Do, 28.07.22 15:03, Chris Murphy (li...@colorremedies.com) wrote:
>
> > > Right. I'd like to use the ESP type code for the merged ESP+XBOOTLDR
> so that the firmware will pick it up properly. The only problem is when
> using the bootc
> Am 28.07.2022 um 22:17 schrieb Lennart Poettering :
>
> One is not really supposed to have multiple ESPs
I have another question regarding multiple ESPs, maybe a bit off-topic. For
software raid we currently have a kind of „off-label use“. Anaconda puts the
ESP on a raid partition (and the
On Thu, 2022-06-09 at 17:05 -0700, Kevin Fenzi wrote:
> Big +1 from me... I think this would be great to enable.
Update here: as the feedback was broadly positive, today I went ahead
and hit the big switch and enabled the *tests* on openQA production.
I did not yet enable *gating*.
So, you will
On Tue, Jul 26, 2022 at 4:07 PM Kevin Kofler via devel
wrote:
>
> Chris Murphy wrote:
> > a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value,
> > so that instead of chainloading the Windows bootloader from GRUB, GRUB
> > will modify the system NVRAM such that the next boot (
On Tue, Jul 26, 2022 at 9:16 PM Kevin Kofler via devel
wrote:
>
> Chris Murphy wrote:
> > Summary: Windows 10/11 increasingly enables Bitlocker (full disk
> > encryption) out of the box with the encryption key sealed in the TPM.
> […]
> > The Bitlocker encryption key is unsealed only if the boot c
35 matches
Mail list logo