Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide

[Przemek Klosowski via devel]

On 5/2/24 16:28, Adam Williamson wrote:

On Thu, 2024-05-02 at 15:41 -0400, Przemek Klosowski via devel wrote:

On 5/2/24 14:34, Gary Buhrmaster wrote:

While I follow the philosophy of updating
regularly, there are likely some who install Fnn, and
never update, and then would expect an update to
Fnn+2 to work without issue(s).
--

The CLI update strongly suggests doing 'dnf update --refresh' before
system-upgrade. It doesn't require it though.

I always thought it's an odd workflow; why doesn't it just force it?
While it might take a long while to complete on a stale system, it's
recommended anyway, isn't it?

I would actually hugely prefer we amend that to say `dnf --refresh
offline-upgrade download; dnf offline-upgrade reboot` or so. It's a
footgun as it stands.


Even though my personal feet are unscathed by great many online 
upgrades, I agree it's a low-probability but high-potential-for-damage 
event. Having said that, in the case of system upgrade, a lot of 
problems of online upgrades (IPC  and ABI incompatibilities, etc)  are 
not very relevant---the system will instantly reboot for the upgrade, right?


The bottom line is I am old-school and hate rebooting and the associated 
loss of 'state', but OTOH most important user-oriented applications save 
and restore state already.  It's just feels inelegant and ad-hoc, but 
may be the price of progress.


I wonder if this means that ostree / CoreOS / Silverblue are the only 
way out of this conundrum.


--
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide

[Przemek Klosowski via devel]

On 5/2/24 14:34, Gary Buhrmaster wrote:

While I follow the philosophy of updating
regularly, there are likely some who install Fnn, and
never update, and then would expect an update to
Fnn+2 to work without issue(s).
--


The CLI update strongly suggests doing 'dnf update --refresh' before 
system-upgrade. It doesn't require it though.


I always thought it's an odd workflow; why doesn't it just force it? 
While it might take a long while to complete on a stale system, it's 
recommended anyway, isn't it?


On an updated system it's fairly quick turnaround; I usually lose more 
time by sitting with an unanswered, unnoticed prompt.

--
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Przemek Klosowski via devel]

On 4/3/24 17:49, Kevin Kofler via devel wrote:


And is there a statistical evaluation of that data somewhere? Downloading
350 MiB (!) of raw CSV data does not sound to me like a convenient way to
work with it.


It's messy, but interesting. Here's the architecture data for the last 3 
or so years:


from top to bottom, x86_64 aarch64 ppc64le s390x armhfp i386 arm 
powerpc64 riscv64


so you can see the decline of armhfp and i386.

I don't know what to make of the relatively large population of ppc64le 
and s390x; I think maybe IBM is eating their own dogfood and using it in 
some internal datacenters?


I am pleased to see RISC-V showing up within last year!


sqlite -csv :memory:

.import totals.csv t

select date(round(julianday(week_end)/30)*30) as Tx, count(os_arch) 
filter (where os_arch like "x86_64") as x86_64, count(os_arch) filter 
(where os_arch like "aarch64") as aarch64, count(os_arch) filter (where 
os_arch like "ppc64le") as ppc64le, count(os_arch) filter (where os_arch 
like "s390x") as s390x, count(os_arch) filter (where os_arch like 
"armhfp") as armhfp, count(os_arch) filter (where os_arch like "i386") 
as i386,count(os_arch) filter (where os_arch like "arm") as arm, 
count(os_arch) filter (where os_arch like "powerpc64") as powerpc64, 
count(os_arch) filter (where os_arch like "riscv64") as riscv64 from t 
group by tx



--
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Przemek Klosowski via devel]

On 4/3/24 14:56, Adam Williamson wrote:

If you have two equally good options and you already picked one, you should
stick with it, not just switch between them every so often for the sake
of it. If Plasma were demonstrably, markedly and uncontroversially
*superior*  to GNOME (please don't take this as an excuse to start a
holy war, I am positing for the sake of this post that neither of the
two is demonstrably, markedly and uncontroversially better than the
other), the case would be different.


Absolutely!!

    "What's worse than a bad general?"

    "Two good generals!"

I have used both Gnome and KDE, and settled on Gnome, not because I 
didn't like KDE but simply because I don't have to think about how to 
perform basic actions. If someone persuaded me that KDE become much 
better, I would switch, but I definitely would not want to download a 
new version of Fedora to install on my new computer, and find myself 
switched.

--
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Switch to DNF5 (system-wide)

[Przemek Klosowski via devel]

On 4/3/24 06:36, Aoife Moloney wrote:

the dnf-automatic command will be obsoleted.


https://dnf5.readthedocs.io/en/latest/changes.html does not say anything 
about automatic updates, and


https://packages.fedoraproject.org/pkgs/dnf5/dnf5-plugin-automatic/

simply suggests that dns update be executed from systemd timers or cron 
jobs.



dns-automatic provided a simple interface to a setup-and-forget 
automatic updates; will DNF5 leave it to be set up by hand?


I am asking because systemd timers have surprising behavior for 
suspendable systems, which leads to problems if updates are scheduled 
for off-hours.


My experience is that even |WakeSystem=true does not make them reliable, 
but I am not sure how to debug this (because the system is suspended, heh).

|

--
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: AVX extensions not detected properly on a Zen 2 CPU?

[Przemek Klosowski via devel]

Nevermind, my mistake---I have
dl_hwcap2=0x0

On 8/28/23 14:27, Przemek Klosowski via devel wrote:

On 8/28/23 09:15, Florian Weimer wrote:

* Julian Sikorski:

I have noticed the following message in my kernel log today after I
attempted to decrypt my veracrypt external hard drive:

[20542.328594] AVX2 instructions are not detected.
[20542.382731] AVX or AES-NI instructions are not detected.
...

$ ld.so --list-diagnostics
dl_dst_lib="lib64"
dl_hwcap=0x2
dl_hwcap_important=0x6
dl_hwcap2=0x2
dl_hwcaps_subdirs="x86-64-v4:x86-64-v3:x86-64-v2"
dl_hwcaps_subdirs_active=0x6

That indicates that userspace has access to AVX2 CPU capabilities.
So this must some kernel thing.  Sorry, no idea what is going on.



I have the same ld.so output, but my CPU (Intel Core i7-3770) reports 
only AVX in /proc/cpuinfo (no avx2).



flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe 
syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl 
xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor 
ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic 
popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm 
cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority 
ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear 
flush_l1d

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: AVX extensions not detected properly on a Zen 2 CPU?

[Przemek Klosowski via devel]

On 8/28/23 09:15, Florian Weimer wrote:

* Julian Sikorski:

I have noticed the following message in my kernel log today after I
attempted to decrypt my veracrypt external hard drive:

[20542.328594] AVX2 instructions are not detected.
[20542.382731] AVX or AES-NI instructions are not detected.
...

$ ld.so --list-diagnostics
dl_dst_lib="lib64"
dl_hwcap=0x2
dl_hwcap_important=0x6
dl_hwcap2=0x2
dl_hwcaps_subdirs="x86-64-v4:x86-64-v3:x86-64-v2"
dl_hwcaps_subdirs_active=0x6

That indicates that userspace has access to AVX2 CPU capabilities.
So this must some kernel thing.  Sorry, no idea what is going on.



I have the same ld.so output, but my CPU (Intel Core i7-3770) reports 
only AVX in /proc/cpuinfo (no avx2).



flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx 
est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti 
ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep 
erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Donate 1 minute of your time to test upgrades from F38 to F39

[Przemek Klosowski via devel]

On 8/26/23 00:51, Solomon Peachy via devel wrote:


I have twenty-year-old perl scripts that still work just fine, but in my
experience, even couple-years-old python code most likely won't.


I love both perl and python, but have to say that perl stability is 
partly due to the fact that its development stalled at some point so 
that the current perl is 5.34  and Perl 5.0 was released in 1994.


I feel that this stasis is not necessarily so bad---not that perl is 
perfect, but it just works so well for short targeted data manipulation. 
Reminds me of the well know quote(1) : "If you don't want your 
environment/language to develop and improve, you have no heart;  if you 
insist on it constantly changing, you have no brain".


The downside of course is that perl is not getting much in the way of 
new tech like machine learning, AI/LLM, etc, and is not a good match for 
large projects because of too much of duck typing.



(1) "If you're not a liberal when you're 20, you have no heart. If 
you're not a conservative when you're 40, you have no head"---it's 
widely mis-attributed to Winston Churchill but he didn't use it apparently.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Potential (security) issue for beginners/non-experts when release is End Of Life: Fedora doesn’t consider the behavior of beginners/non-experts sufficiently

[Przemek Klosowski via devel]

On 8/15/23 09:51, Stephen Smoogen wrote:
Each of these groups have 'farms' of several hundred of each type of 
phone which get continual updates and they have a long certification 
process to make sure that they reach 'all the phones updated without 
problems and ran N hours without issues afterwards'. This is part of 
the reason it can take months for a release from The OS manufacturer 
(aka Android) to get pushed out to fleets of phones. It is fairly 
'expensive' work with lots of little issues having to be tracked down 
and passed. [Because even when you 'built the phone' you find out that 
N% of that batch still acts slightly different from the rest on this 
update.]


In the desktop/computer mode this is just outside of anything that I 
think a volunteer oriented organization could try to make work at scale.
I do see your point that there's too much variability in the hardware 
and software setup to be able to exhaustively test all the upgrade 
paths, but Adam W. and his group do such excellent job of testing that I 
think statistically a failed update is a black swan. It would be nice to 
know the actual failure numbers, but we'd need some telemetry for that 
:).  Maybe the technical challenge that would solve this is rollback of 
failed updates. OStree arguably has an advantage here over file-based 
updates.


For what it's worth I personally was blessed with simple upgrade 
problems, fixed by temporarily deleting a bunch of large packages like 
KiCAD 3D models RPM, etc.  I was always able to upgrade, so my anecdata 
makes me trust Fedora updates. In fact, the main challenge I encountered 
is the accidental persistence of various 'experimental' UI and OS 
settings I did over time that result in a behavior different from a 
fresh install---I sometimes wish there was an interactive, granular 
'restore factory defaults' option that would let me keep some settings 
and revert others.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Potential (security) issue for beginners/non-experts when release is End Of Life: Fedora doesn’t consider the behavior of beginners/non-experts sufficiently

[Przemek Klosowski via devel]

On 8/13/23 16:57, Kevin Kofler via devel wrote:

look at SUPPORT_END in /etc/os-release and nag more frequently.

Highly recommend other Fedora editions consider similar notifications.

I don't think more nagging is going to help. It is just going to be
considered yet another annoying nag to ignore or click away. Like it or not,
non-technical users are NEVER going to upgrade to a new operating system
release. Not now, not 10 years from now. Until their computer physically
breaks down, at least. There is just nothing you can do about it.


I believe this is overly pessimistic: people tend to upgrade their 
Android and iOS devices and applications, because the update process is 
low-friction and well tested so that people tend to trust it.


I have personally had multiple Fedora upgrade issues due to lack of 
space in the root filesystem, so maybe Fedora is not yet at a point 
where we can unconditionally launch into upgrading, but it's a technical 
issue that can be corrected.


We already have SUPPORT_END so I think it makes sense to use it.
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

[przemek klosowski via devel]

On 7/12/23 19:21, Demi Marie Obenour wrote:


1. The GDPR and similar regulations are 100% clear that consent must
be opt-*in*.  Opt-*out*, as is proposed here, is not consent.
Therefore, this change is proposing collecting telemetry *without
user’s consent*.


I seems to me that there are two slightly different understanding of 
'opt-in':


1. data collection is happening automatically, but there is a way to
   'opt-out' and turn it off.
2. the user is asked for permission, and the default answer is
   preselected as 'yes'

I think GDPR prohibits the first option, but the second one must be 
allowed because it's like pretty much all GDPR-compliant implementations 
i've seen


I understand that Michael's Telemetry proposal uses the second method.

Perhaps a criticism of the opt-out approach (even in the second form) 
results from people believing that the consent at the installation time 
is not fully informed---that somehow people don't understand the 
ramifications and amount of data being shared. This is actually makes sense.


Such concern could be mitigated by scheduling a system notification 
after several weeks or months, with a rough summary of the collected 
data ( 'we shared X anonymized reports about Y,Z and W'), and offering a 
link to a telemetry consent dialog.
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

[Przemek Klosowski via devel]

On 7/12/23 16:34, Jeremy Newton wrote:

I know that I would personally always opt out on principle, and would vote for 
opt-in or dropping the proposal. I am under the impression that most Fedora 
users are in the same boat as me.


For the record, my personal opinion is that an opt-out is an acceptable 
option. I believe that Fedora has been hampered in the past by lack of 
reliable usage stats: we had difficult discussions about support for 
i686/python2/Qt3/etc where we just didn't know where the Fedora users 
were. Therefore, I personally think it is a good idea to allow 
collecting such stats, because I trust Fedora organization to keep such 
information to itself.


First of all, I just don't see that large data brokers would be 
interested in Python3 adoption data, and secondly I hope that Fedora 
organization would have the integrity (and the whistleblowers:) to 
protect that info even if there was a temptation to let it out.


Regarding the opt-in vs opt-out, someone made a claim that opt-out is 
not compliant with GDPR, which doesn't sound right. Every GDPR widget I 
have seen so far essentially asks if I agree with data collection, and 
offers me an opportunity to opt out of everything but essential cookies, 
which seems equivalent to the 'opt-out' mechanism that Michael proposes.


One missing piece might be for Fedora organization to commit to a policy 
of protecting such data collections, by publishing a legally sound 
declaration about its intentions and practices. Currently, we have this


    https://docs.fedoraproject.org/en-US/legal/privacy/

which in my 'not-a-lawyer' view seems to be targeted to the web 
collection and may be US-centric, so maybe it could use some legal 
wordsmithing.


Again, all this is my personal opinion.

p
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SecureBoot certificates

[przemek klosowski via devel]

On 6/14/23 09:29, stan via devel wrote:

On Tue, 13 Jun 2023 11:05:53 -0400
"Chris Murphy"  wrote:


OK I tried this again and discover shim is signed twice.

It has been awhile since I built a local kernel that I signed, but even
a locally built kernel was signed twice when using rpmbuild.  I assume
that somewhere in the build plumbing there are two certificates and two
sign procedures.


If that's the case, one of those places is using an expired certificate. 
I would have thought that signing tools would refuse to sign with an 
invalid cert?


Maybe the build tools take an existing blob, signed way back when with 
that expired cert, and re-sign it with a current cert?

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SecureBoot certificates

[przemek klosowski via devel]

I also have a recently updated F38 with shim-x64-15.6-2.x86_64. The 
BOOTX64.EFI file has two certificates


  Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, 
CN=Microsoft Windows UEFI Driver Publisher
  Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, 
CN=Microsoft Corporation UEFI CA 2011


The first one's validity is
    Not Before: Sep  9 19:40:20 2021 GMT
    Not After : Sep  1 19:40:20 2022 GMT

and the second's:
    Not Before: Jun 27 21:22:45 2011 GMT
    Not After : Jun 27 21:32:45 2026 GMT

Are these certs for different purpose, or is the second one supposed to 
supersede the previous one?


On 5/31/23 09:57, Steve Grubb wrote:

On Tuesday, May 30, 2023 10:00:53 PM EDT Chris Murphy wrote:

On Fri, May 26, 2023, at 10:20 AM, Steve Grubb wrote:

sbattach --detach signature  /boot/efi/EFI/BOOT/BOOTX64.EFI
openssl pkcs7 -inform DER -in signature -text -print_certs >
shim-certs.txt>
 Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,

CN=Microsoft Corporation UEFI CA 2011

 Validity
 
 Not Before: Sep  9 19:40:20 2021 GMT

 Not After : Sep  1 19:40:20 2022 GMT

What version of shim do you have installed? What edition/spin are you
using?

This is plain old F38. The shim is shim-x64-15.6-2.x86_64


I have shim-x64-15.6-2.x86_64 and it's reporting

 Not Before: Jun 27 21:22:45 2011 GMT
 Not After : Jun 27 21:32:45 2026 GMT

A possible explanation is rpm-ostree derivatives may show a current version
grub and shim, but those are not copied to the EFI System partition.
That's the job of bootupd but I'm not sure if that's fully implemented yet
in Fedora.

Appearantly not. But rpm -qf  /boot/efi/EFI/BOOT/BOOTX64.EFI shows it is owned
by the shim. locate BOOTX64.EFI only shows one location, the previously
mentioned path.

I understand that certificate validation cannot take time and date into
account during boot because you have no idea if the system clock is accurate
until the whole OS can run a NTP sync. But I am just surprised my system has
binaries with expired signatures.

-Steve

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

[przemek klosowski via devel]

On 4/11/23 22:08, Jeff Law wrote:

On 4/11/23 19:14, przemek klosowski via devel wrote:
The situation in the RISC-V universe is even more complicated because 
of all the extensions


...
Whatever standard scheme Fedora uses for x86 will hopefully be very 
useful for RiSC-V era that is apparently coming, with Linux-capable 
SBC boards like VisionFive ($65)  and Pine64 ($70 and $8 (!) ox64) 
just becoming available, and a lot of activity on the horizon.
Rather than trying to track all the individual extensions and 
combinations thereof, I would suggest focusing on RVI defined 
profiles. Essentially they provide a set of mandatory features the 
architecture must support (to be compliant with the profile).


That may rule out certain processors, but it ultimately provides a 
higher performing baseline architecture for systems that are 
(hopefully) going to be good performing parts rather than embedded 
focused parts.


Yes, good point, but there's already a number of profiles even though 
they are barely out of the gate:


https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc

I of course agree with you that it makes sense to focus support on a 
small number of existing platforms with good reputation and performance 
(for instance both VisionFive and Pine64 are based on StarFive JH7110 SoC).


Still, it would be neat if there was a good technical solution for 
subarchitecture diversity because there will be more of it in the 
future. Jim Keller, the prolific CPU designer who worked on DEC Alpha, 
AMD K7 and Zen, Intel, Tesla, and Apple, has an interesting talk where 
he justifies going to RISC-V architecture because it is so much easier 
to extend it for high performance on specific tasks:


https://youtu.be/yHrdEcsr9V0?t=297

Currently we have a wide variety of approaches, from recompiling for the 
specific subarchitecture a la Arch to runtime codepath selection in fat 
binaries, so I'm glad that people are thinking about the relative merits 
of those and trying to figure out if there's a common best approach.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

[przemek klosowski via devel]

On 4/4/23 10:28, Dan Čermák wrote:

Chris Adams  writes:


Yeah, it'd be back to the i386/i586/i686 days... which was a bit of a
PITA sometimes.  But cramming multiple architectures of core libraries
into a single RPM would be bad for disk space, image size, downloads,
etc.

But something that didn't exist in the i386/i686 days is containers -
whether base images like for podman or full things like Flatpaks.
Before going too deep into multi-level architectures, that should be
taken into account.

Afaik at least container runtimes do not support really support x86_64
subarchitectures: https://github.com/containers/podman/discussions/15256


The situation in the RISC-V universe is even more complicated because of 
all the extensions


https://en.wikichip.org/wiki/risc-v/standard_extensions

It'll be challenging to write and package software that is portable 
between all those variants---the fat binaries are just not practical due 
to combinatorial complexity, so it'll have to be either install-time or 
link-time configuration.


Whatever standard scheme Fedora uses for x86 will hopefully be very 
useful for RiSC-V era that is apparently coming, with Linux-capable SBC 
boards like VisionFive ($65)  and Pine64 ($70 and $8 (!) ox64) just 
becoming available, and a lot of activity on the horizon.


https://www.reddit.com/r/RISCV/comments/11wdk2i/riscv_linux_sbcs_how_are_we_doing/
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Porting Fedora for the LoongArch architecture.

[Przemek Klosowski via devel]

On 1/11/23 01:24, Peter Robinson wrote:

Also before becoming a main Fedora architecture the infrastructure
team will need to be able to source enterprise grade hardware that can
be racked in a datacentre and remotely managed. There's likely some
other requirements the infrastructure team has here.


The Registrer claims that China is banning exports of Loongson hardware

https://www.theregister.com/2022/12/15/china_loongson_chip_export_ban/

I have no additional information, just reporting what I saw on the Internet.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

[przemek klosowski via devel]

Andrii,

copilot to pilot, you are responding to Jakub Jelinek's points, not 
Neal's. Jakub is a compiler/toolchain engineer with considerable 
experience, so when he talks about compiler technology involved in 
tracing execution flow, I am inclined to believe him.


I understand that your experience lies in running (and 
tracing/profiling) production applications, but please consider that 
your viewpoint may be biased by your experience with existing frame 
pointer-based instrumentation. This means that you just know from 
experience when your results are solid and when you have to be careful 
because of e.g. a particular application's large number of small 
prolog/epilog-dominated functions or complex and intensive flow of 
memory allocations. Jakub is saying that DWARF is a superior technology 
that provide the frame pointer information more reliably, so the real 
issue is that frame pointer based infrastructure is already here and 
DWARF handling requires more development. I haven't heard anyone 
question the solidity of the DWARF approach outlined by Jakub and other 
people involved with the toolchain, so I think it is reasonable to 
expect that it will get implemented.


Are you actually against using the DWARF approach for technical reasons, 
or is your argument based on the practical consideration of what's 
available right now?



Very Respectfully

p.k.


On 12/6/22 12:46, Andrii Nakryiko wrote:

On Tue, Dec 06, 2022 at 08:13:51AM -0500, Neal Gompa wrote:

That is nonsense.  Even with -fno-omit-frame-pointers, you can't rely
on frame pointers, they are not accurate in function prologues and epilogues
and they are total garbage e.g. in a lot of functions written in assembly.

First of all, 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%2Ffesco%2Fissue%2F2817data=05%7C01%7Cprzemek.klosowski%40nist.gov%7Ca591777f6c0249b566ff08dad7b1d043%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C638059455959276624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=UB%2FsGNKWZQRvJiPPB7wmPwHXvtSFkMCZ0nltpyQmAl0%3Dreserved=0
 is first and foremost about enabling low-overhead **profiling** of applications (periodic 
in background or on-demand requested by users explicitly), not debugging use cases. For 
debugging use cases GDB might be perfectly adequate to rely only on DWARF information. But 
-fno-omit-frame-pointers is to enable profiling **production workloads** as they happen, 
because very often reproducibility of results is impossible without understanding the issue 
in the first place, which is what frame pointers are needed for. Even more often you don't 
even realize that application is doing something suboptimal unless you profile it 
continuously, as it handles *real workload*.

Now, about prologues/epilogues. What percentage of useful workload is spent in 
those? Tiny fraction of a percent at best? Even if we don't get accurate stack 
trace in such cases it doesn't matter in the grand scheme of things.

As for hand-written assembly functions. I looked at strcmp, memcpy and similar 
very frequent and hot functions in glibc. Yes, they don't save %rbp and don't 
maintain frame pointers. But they also don't use %rbp register at all, which 
means **they don't clobber it**. So if we take stack trace while such function 
is executing, we'll still get non-broken stack trace all the way up to the root 
parent function, we just won't have leaf-level function in stack traces. That's 
much better and more useful than completely broken stack and allows to reason 
very well about application performance. Also, almost all fpu-related routines 
under sysdeps/x86_64/fpu/multiarch/svml*.S that are using %rbp, are also 
properly maintaining frame pointers:

There is a very good reason why Meta enabled -fno-omit-frame-pointers across 
all its internal software 5 years ago and never looked back. We rely on frame 
pointers being available across millions of machines to drive performance 
improvements and investigations saving millions of dollars of real 
non-hypothetical savings. Google, Netflix, Apple, etc -- all enable frame 
pointers due to sheer usefulness of them in practice, either for performance 
profiling and/or better real-time introspection of their workloads.

So much for the "nonsense". I realize that not everyone have experience with 
tracing production workloads and generally working in profiling area, but I expect people 
to keep an open mind and not use double standards when thinking about implications of 
system-wide changes like this one or frame pointers one.


The only reliable way to get backtraces is DWARF info or something derived
from it, that is for code emitted by the compilers (with the default
-fasynchronous-unwind-tables) accurate for all instructions and for
hand written assembly one has at least a way to describe that through
.cfi_* directives.

As has been written multiple times, for profiling there 

Re: Inactive packagers to be removed after the F37 release

[Przemek Klosowski via devel]

On 9/14/22 03:51, Vitaly Zaitsev via devel wrote:

On 13/09/2022 23:50, Demi Marie Obenour wrote:

Another option is a TPM-based authenticator.  Would this be acceptable?


No. TPM 2.0 chip is a *proprietary* black box. Some of them have known 
critical security vulnerabilities[1]. 


OK, but so is every onther secure processor (yubikeys, finians, etc). At 
least TPM2 is ubiquitous, and watched/tested widely, and being improved 
as a result. The vulnerability you refer to was due to not encrypting 
LPC traffic between the motherboard and the TPM chip, which was 
apparently due to the implementation being lazy rather than a TPM 
deficiency. Traffic encryption is a standard protocol feature, and is 
increasingly being used.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Donate 1 minute of your time to test upgrades from F36 to F37

[przemek klosowski via devel]

On 9/12/22 08:59, Miroslav Suchý wrote:


Do you want to make Fedora 37 better? Please spend 1 minute of your 
time and try to run:


# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'

dnf --releasever=37 --setopt=module_platform_id=platform:f37 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \

--assumeno distro-sync


conflict due to

 elementary-planner-1:3.0.7-1.fc37.x86_64 requires 
libedataserver-1.2.so.26()(64bit), but none of the providers can be installed

https://bugzilla.redhat.com/show_bug.cgi?id=2126527
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Przemek Klosowski via devel]

On 6/30/22 10:23, Michael Catanzaro wrote:
I take a pretty dim view towards arguments about "Flathub is 
untrusted" and "Flathub packaging is poor" since proponents of these 
arguments conveniently ignore the fact that traditional RPMs are 
totally unsandboxed. [...]


Opponents of Flatpak have had seven years since Flatpak launched to 
figure out an alternative model to make apps safe using firejail or 
bwrap or whatever, but nobody ever seriously did, and at this point 
the endgame has arrived with a *commanding* lead in favor of Flatpak. 
So it's time to move on. 


There are two separate issues: sandboxing and library 
duplication/lifecycle management. I agree that sandboxing is desirable, 
but I don't think we should give up on the shared libraries, because of 
their savings of memory and storage, and because of their better 
security profile.


I see how RPM-driven flatpaks can actually mitigate the security 
issue--presumably any vulnerability fixes/updates to system libraries 
also end up in the rebuilt flatpaks, so they would not rot in place. 
Still, the library/runtime duplication bothers me and I hope that there 
will be some technical solution to it.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Firefox Langpacks Subpackage (System-Wide Change)

[przemek klosowski via devel]

How about a middle ground, by splitting langpacks into several larger 
groups (roman-alphabet+arabic+far-eastern?, asian+european?). 
This way we wouldn't have to constantly twiddle with new packages and 
keep the number of packages sane.


p


On 6/30/22 06:32, Jens-Ulrik Petersen wrote:
On Thu, Jun 30, 2022 at 2:27 AM Vitaly Zaitsev via devel 
 wrote:


On 29/06/2022 19:00, Vipul Siddharth wrote:
> Firefox langpacks, which have been bundled in the Fedora firefox
base
> package until now, will be moved to a firefox-langpacks subpackage.

+1. It might be better to split it even more:
firefox-langpack-%{lang}
and depend on the system-wide language (just like spelling
dictionaries).

Users will be able to install only the required locales.


Right, I am aware of that.

One problem is that the number of firefox langpacks changes somewhat 
over releases,
so Martin was hesitant to take this approach in the past.  Probably 
still applies.
So the proposed approach seems like a reasonable compromise and step 
forward.


(I have pondered if we could decide on a set of core firefox langpacks 
which are "guaranteed" to exist
and so hopefully could be safely subpackaged - but this makes the 
handling more complicated

and delicate - it would have to be done very carefully in langpacks.)

Jens

___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report 
it:https://pagure.io/fedora-infrastructure___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Debuginfo on F36

[przemek klosowski via devel]

On 5/18/22 23:57, Jerry James wrote:

On Wed, May 18, 2022 at 9:41 PM Jerry James  wrote:

I just updated my home machine to F36.  Now, when I try to debug a
Fedora-built package after installing the appropriate debuginfo
packages with dnf, I get:

(No debugging symbols found in .gnu_debugdata for [path to ELF object])

for every library.  Is debuginfod the only supported way to get usable
debuginfo now?  I thought it was an optional convenience feature.  I
would rather manage the debuginfo with dnf.

Some experimentation shows that there is some magic threshold at play
here.  After I installed debuginfo for a bunch of libraries I am *not*
interested in, GDB started loading debuginfo for the one of interest.
So is there some kind of dependency between debuginfo packages that
must be satisfied before the debuginfo can be used?  I never
encountered this on F35, so I'm not sure what the rules are now.


I think gdb starts loading debuginfo in background, and it takes a while 
so you started seeing it after a delay.


I am not sure how to check the progress of this background retrieval; I 
don't remember any messages even while in gdb



___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How much free space in /var is required for upgrades?

[przemek klosowski via devel]

I had issues with this for several releases now, although I never got a 
broken upgrade like you're reporting: every time so far I got a message 
'you need additional 4GB on /' before the actual upgrade started. It 
would be sad if the free space estimation code didn't work and allowed 
broken, half-upgraded systems!!


Unfortunately, I believe that the current upgrade workflow requires a 
root disk three times the total installed package size: each package is 
there as the original version, the RPM of the upgrade in the cache 
directory, and as a new image before the old one is purged.


There's an install-time option --destdir to store the new release RPM 
collection on a separate volume, but it used to not work.


https://bugzilla.redhat.com/show_bug.cgi?id=1513823

I see that it is marked as resolved, but I vaguely remember having 
problems with it still.


I just got used to deleting few largest packages (wine-core kicad 
FlightGear :) and reinstalling them after the upgrade. I actually 
benefited from this discipline: I used to have a ton of debuginfo/source 
packages that are no longer necessary, and this forced me to look into 
and delete them.


On 5/13/22 14:54, Jason L Tibbitts III wrote:

So I went to do a dnf system-upgrade from F35 to F36 on a test machine,
as part of my usual testing.  In the middle of the process, it appears
that /var filled up and that left the system in an unfortunate state.
Surprisingly (to me) it did boot with a random mix of F35 and F36
packages and even though it's a throwaway test box, I wanted to play
around with fixing it a bit and trying to understand why it ran out of
space instead of just reinstalling.

Turns out that "dnf --releasever 36 --nogpgcheck remove --duplicates"
was able to effectively everything in the system, and while running this
/var filled up again.  When that happened, dnf couldn't even be aborted;
I had to kill -9.  The culprit is the write-ahead log,
/var/lib/rpm/rpmdb.sqlite-wal.  I resized /var and reran, and by the end
of the process had grown to over 9GB:

-rw-r--r--. 1 root root 9124576392 May 13 13:11 rpmdb.sqlite-wal

Of course it immediately went to 0 once the transaction completed,
though rpmdb.sqlite went from:

-rw-r--r--. 1 root root 281739264 May 11 14:24 rpmdb.sqlite

to

-rw-r--r--. 1 root root 730648576 May 13 13:15 rpmdb.sqlite

which seems... odd for what's effectively just reinstalling the existing
package set.

Anyway, obviously the solution is to make sure that /var is "big enough"
before you do a system upgrade.  And we do have warnings about
filesystems being too small, but nothing about needing an extra 10GB for
this.  Certainly my case might be somewhat pathological and it was good
that in the end I was able to get the system back into a useful state
without wiping it.  But in the end I wonder:

1) Is it really expected that the wal file will grow to that size?

2) Is there anything to be done to reduce the size of the log?

3) Is there any better way to handle a lack of space in /var during an
RPM transaction?

4) Can we estimate how large the file will grow, and refuse to start a
system upgrade if there is not enough space?  Certainly we already do
this to some degree, but it seems that the estimate of the required
space is a bit too small.

  - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=05%7C01%7Cprzemek.klosowski%40nist.gov%7Cd6fef0708ded409a2c0008da3512152b%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637880649029987411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=bQ6JeyOsZ3DL%2B0qW077BKfkYciUicGcoTBJKt0kYNtg%3Dreserved=0
List Guidelines: 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=05%7C01%7Cprzemek.klosowski%40nist.gov%7Cd6fef0708ded409a2c0008da3512152b%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637880649029987411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=oYtihVLX1JB5uOAS4k57fiW9a2b3LJnNvMRdtgd7ziE%3Dreserved=0
List Archives: 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedoraproject.org%2Farchives%2Flist%2Fdevel%40lists.fedoraproject.orgdata=05%7C01%7Cprzemek.klosowski%40nist.gov%7Cd6fef0708ded409a2c0008da3512152b%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637880649029987411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=KfK7qrPSeyT2D%2FjI40DWG%2B%2FoU6z7AO1cSnG60oKNCCw%3Dreserved=0
Do not reply to spam on the list, report it: 

Re: Need advice on NET_ADMIN capability on a binary (iotop-c)

[przemek klosowski via devel]

On 2/22/22 12:14, Boian Bonev wrote:

Hi Dan,

Thanks for the suggestion - I like that way because it gives full 
control to

the admin together with the responsibility and does not implicitly do
unexpected things. It is also a clean approach both from user 
experience and

packaging point of view, so I will go for that way.


> This is not really an answer to the security question, but if that 
remains
> unresolved, you could also introduce a sub package to iotop-c, that 
would
> contain a transaction file trigger on the binary and add the 
capability. Thus
> user would be able to opt into having iotop-c with the added 
capability even

> after upgrades, as long as the sub package is installed.

It's a clever idea but I've never seen packaging used this way. I think 
you're saying that the default installation of iotop-c would have 
limited capability, and installing the second package would anoint iotop 
with the full set of privileges.


Using packaging for this is clever but unintuitive; do we really want to 
start it as a new trend? Traditionally, stuff like that was mentioned in 
release notes and done as an adiministrative commandline action. Is 
there a precedent for using packaging this way?

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: More is not Less

[przemek klosowski via devel]

On 2/13/22 22:08, Todd Zullinger wrote:

Ron Olson wrote:

Sorry if I missed something, but under Rawhide I
discovered when I tried to “more somefile.txt” I got
“less” behavior, while Fedora 35 still runs more like, uh,
more.

I'm not quite sure what "less" behavior you mean, so I'm
only guessing.


FWIW 'less' clears the screen so I sometimes use 'more' when I want some 
text (e.g. a tutorial example from a man page) to remain visible on the 
screen after I quit reading the man page.


OTOH, you can get the non-clearing behavior by doing 'less -X', so maybe

alias more='less -X'

is a workaround.
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fwd: conditional require (RPM dependency solving puzzle)

[przemek klosowski via devel]

On 2/1/22 12:54, Miro Hrončok wrote:
Thanks to Steven, Stephen and Miro for finding this solution. Still, 
having to add flags and deleting the existing doc package is not 
completely gruntling---it works, but it's not automatic and, for the 
future, I am curious if there's another way.


Sorry for flogging this fine stallion, but I believe that 'dnf update 
kicad kicad-doc' would have worked (I did check that updating 
kicad-doc followed by updating kicad works). Isn't there some 
combination of Required/Obsoletes/Conflicts/??? to coax dnf to 
upgrade both packages instead of deleting kicad-doc?


This should work without --allowerasing once the packages are actually 
in a repository. "dnf update kicad" will see the newer version of 
kicad-doc and it will update both at the same time. 
This is after enabling Steven's COPR 
copr:copr.fedorainfracloud.org:group_kicad:kicad , which contains kicad, 
kicad-doc and kicad-packages3d. Are you saying that it would make a 
difference when they are in the main Fedora - Updates repo?___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fwd: conditional require (RPM dependency solving puzzle)

[przemek klosowski via devel]

rpm -q -conflicts kicad-6.0.1-4.fc35.x86_64.rpm
kicad-doc < 1:6.0.1-4.fc35 

...

When I add the '--best --allowerasing' flags, then I get the 
desired result:


# dnf update kicad-6.0.1-4.fc35.x86_64.rpm --best --allowerasing
Last metadata expiration check: 0:43:04 ago on Mon 31 Jan 2022 
05:06:19 PM EST.

Dependencies resolved.
 

  Package    Architecture    Version Repository 
Size
 


Upgrading:
  kicad  x86_64  1:6.0.1-4.fc35 
@commandline   90 M

Removing dependent packages:
  kicad-doc  noarch  1:5.1.12-1.fc35 
@updates  111 M


Thanks to Steven, Stephen and Miro for finding this solution. Still, 
having to add flags and deleting the existing doc package is not 
completely gruntling---it works, but it's not automatic and, for the 
future, I am curious if there's another way.


Sorry for flogging this fine stallion, but I believe that 'dnf update 
kicad kicad-doc' would have worked (I did check that updating kicad-doc 
followed by updating kicad works). Isn't there some combination of 
Required/Obsoletes/Conflicts/??? to coax dnf to upgrade both packages 
instead of deleting kicad-doc?


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

conditional require

[przemek klosowski via devel]

During recent major version update, some files were moved from 
-doc to , and as a result updates of  fail 
due to a file conflict. Manual update of -doc resolves this, of 
course.


A simple solution would be to declare that 

Required: package-doc >= 6.0.0

but that would force the install of the docs package if it wasn't 
already there.


Is there a way to declare a dependency only if the other package is 
present/installed? Would


Obsoletes: package-doc < 6.0.0

be the right thing to do?
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: new systemd in rawhide

[przemek klosowski via devel]

On 12/10/21 09:13, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Dec 10, 2021 at 10:40:33AM +0100, Vitaly Zaitsev via devel wrote:
   What happens if these libraries are not installed an cannot be dl-opened?
The functionality that requires those libraries will not be available.


This is quite clever, +1.

It occurred to me that a downside might be in mysterious functionality 
variances in case of latent bugs. Say, something happens to libpcre2 
(file gets damaged, or ABI incompatibility creeps in, etc) so that 
suddenly 'journalctl --grep' stops working. How would one find out about 
the cause? From reading the journalctl code, it seems to me that 
pcre2-dlopen.c:dlopen_pcre2() is called when --grep is used, and it logs 
the failure, which I think addresses my concern.


So the apps using this technique would have to be written carefully, to 
only dlopen() (and therefore also print possible error messages) when 
the optional functionality is called for, right? If the dlopen()s were 
just shotgunned at the startup, it could result in a lot of chatter.


If this technique became widely used, as it probably should, maybe there 
ought to be a common way of finding out what is and isn't available. For 
instance, the apps could have a special common option, like 'journalctl 
--capabilities' returning


...

libpcre2 loaded, --grep enabled

libfancy NOT loaded, --FANCY disabled

..

Or, there could be a system-wide status matrix of executables vs 
libraries, listing the outcome of recent dlopen()s, so that a query like 
'capabilites journalctl' would return the status above (except that such 
general utility would not in general be able to print what app 
functionality is tied to the particular library)


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[przemek klosowski via devel]

On 12/9/21 10:15, Vitaly Zaitsev via devel wrote:

On 09/12/2021 15:32, Lennart Poettering wrote:

TPM2 chip you'll get much weaker security guarantees


https://arstechnica.com/gadgets/2021/08/how-to-go-from-stolen-pc-to-network-intrusion-in-30-minutes/


The Lenovo TPM implementation exploited here did not use TPM traffic 
encryption so the attackers simply eavesdropped on the traffic to the 
TPM during the boot.  As the article says, the TPM2 standard specifies 
traffic encryption that would have prevented that attack.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[przemek klosowski via devel]

On 12/7/21 10:39, Zbigniew Jędrzejewski-Szmek wrote:


  If available, use
the TPM2 to additionally tie the password to local hardware. If the
user is removed, also remove that password from that storage.

During boot, if it is necessary to authenticate before the root file
system has been mounted, allow admin users to log in using the credentials
that were stored previously.

Is this being worked on? Do you have any references?

Latest systemd versions have been getting some support for the low-level
parts, i.e. the low-level encrypted-secret storage. But we're missing the
upper parts, i.e. how to actually use and update the passwords. I didn't
even mention this, because we don't have a comprehensive story yet.


A scenario that wasn't mentioned here yet is using a disk from a failed 
system: either moving it to another system, or even simply accessing the 
data. If the credentials (including the LUKS encryption key/password) 
are protected by TPM2, it may effectively prevent any further access. It 
would be useful if any such new scheme avoided that.


In enterprise system, there usually is a backup decryption key, 
accessible to the enterprise admins. I am not sure what would be 
appropriate for single-user systems: some sort of install-time rescue 
passphrase [1] perhaps, that the user would write down and safely store [2]?


[1] https://xkcd.com/936/

[2] conveniently stored next to the rubber hose so that the attackers 
could forgo its use and type the rescue passphrase themselves. 
https://xkcd.com/538/
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unowned system directories

[przemek klosowski via devel]

On 11/23/21 22:13, Steve Grubb wrote:

```
$ rpm -qf /var/cache
filesystem-3.14-7.fc35.x86_64

  ```

Top level ownership is not good enough because we have to be able to
determine what is in use now vs what I can delete.



For this particular one, I always assumed that I can delete anything in 
/var/cache. I think the current recommendation for PackageKit hogging / 
space is still


rm -rf /var/cache/PackageKit
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Unit Names in Systemd Messages (Self-Contained Change proposal)

[przemek klosowski via devel]

On 11/17/21 13:49, Matthew Miller wrote:

Finished systemd-modules-load.service - Load Kernel Modules.
Finished systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in 
/dev.
Starting systemd-sysctl.service - Apply Kernel Variables...
[...]
Would something like

Started  Journal Service (systemd-journald.service).
Finished Load Kernel Modules (systemd-modules-load.service).
Finished Create Static Device Nodes in /dev (systemd-tmpfiles-setup-dev.service)
etc.

be possible?
I find Matthew's version much easier to read and comprehend, especially 
when it comes as a wall of startup text.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Introduction: nedia, a Silverblue fan

[przemek klosowski via devel]

Kia ora to you, and welcome to Fedora!

I hope you find something interesting to contribute in.

p

On 10/27/21 23:30, Aiden Langley wrote:

Kia ora koutou,

I'm nedia, I live in NZ & I've been knocking about the matrix/irc for a few days now. 
I'll be 28 on the 30th, I've been using Fedora for about a year, Linux for about 3-4 
(Ubuntu & Antergos), & have been doing software dev for about 5-6 years.

I started my career w/ Java, then spent some time w/ PHP on some legacy 
spaghetti, wrote a cool CLI that interfaced w/ AWS EC2 instances to run data 
conversions and had a lot of fun with it, and I've dabbled in some Rust, C#, 
Python and more JavaScript than I'd like to admit. Keen to write something in 
Go one day.

https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwowhub.co.nz%2Fdata=04%7C01%7Cprzemek.klosowski%40nist.gov%7C7025d32558d449f8f6ac08d999c3812c%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637709887232061405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=oMBt8wN4QxqHp1cx%2FGlh2HgpXwXfOCs8hUg2pq38O80%3Dreserved=0
 is what keeps me occupied at the moment, I  contract / volunteer at a not for profit, charge 
enough to pay my bills but my work is mostly kōha (a gift \ given free of charge.) I could 
potentially spend a lot of time on Fedora related projects, my weekends are v open & I give 
the Whakaoranga Whanau about 24 hours a week. I have tourettes so sometimes I need days to 
myself to recoup mentally.

I'm currently using Silverblue, I'm enamored by the ideas - immutability is 
huge to me now. I get anxiety whenever I use another distro, knowing one false 
step might lead to a re-install. I'm a tinkerer so it happens a fair bit.

I'm also running Rawhide, since Silverblue affords me an extra layer of 
security, it seemed like it was the perfect fit for running some potentially 
unstable software.

An area that seems like it could use some work from what I've observed is 
`rpm-ostree`, being able to upgrade packages for testing e.g. `sudo dnf upgrade 
--enablerepo=updates-testing --advisory=FEDORA-2021-992e409289` & group 
installs are missing at the moment. I wanted to be able to run a 2nd DE in case of 
bugs, but would have to install each package individually as it stands so I settle 
for just rebasing when the time comes. Is `rpm-ostree module` intended to be the 
new `group`?

Anyway, v interested in Silverblue and putting myself in a position to test & 
contribute to the above, so if anybody would like to sponsor / point me in the 
right direction, that would be much appreciated.

Cheers,
*nedia*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=04%7C01%7Cprzemek.klosowski%40nist.gov%7C7025d32558d449f8f6ac08d999c3812c%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637709887232061405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5y2U6lGEbT3d%2BNJTAIHKZsb9kX81MIVxamCXghck4Jo%3Dreserved=0
List Guidelines: 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=04%7C01%7Cprzemek.klosowski%40nist.gov%7C7025d32558d449f8f6ac08d999c3812c%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637709887232061405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=lf24U63zSdKy8fxkZ9VtgCfFcK8Yf0paAsZFGSdm7A4%3Dreserved=0
List Archives: 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedoraproject.org%2Farchives%2Flist%2Fdevel%40lists.fedoraproject.orgdata=04%7C01%7Cprzemek.klosowski%40nist.gov%7C7025d32558d449f8f6ac08d999c3812c%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637709887232061405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2vc9mwUgvKMNbUYRU8kj4Y0KTfXoUpvUU6iLFcJUCdA%3Dreserved=0
Do not reply to spam on the list, report it: 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%2Ffedora-infrastructuredata=04%7C01%7Cprzemek.klosowski%40nist.gov%7C7025d32558d449f8f6ac08d999c3812c%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637709887232061405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wTIOARwqQs%2Fgr8GfNdVZ4JcRIwuSbBOcasxpVHG8saI%3Dreserved=0

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Re: Fedora minimum hardware requirements

[przemek klosowski via devel]

On 10/14/21 18:30, Peter Boy wrote:

A default installation of Fedora Server Edition occupies about 2.2 GiB of 
storage and consumes 505 MiB of Ram. An absolute minimum might be 2 G RAM and 5 
G storage


This pretty much would require a reinstall on upgrade, because during 
the regular upgrade the root filesystem needs to contain the old 
packages, the new RPMS and the space to install them before the old ones 
are deleted, i.e. the root FS needs to be at least 3x the installed size.


It's OK in many cases, but we should warn people.



___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Donate 1 minute of your time to test upgrades from F34 to F35

[przemek klosowski via devel]

This is F34 with 5041 packages. I think people alrady reported 
arduino-core and gnuradio, I reported the gqrx libboost/boost_thread  issue


https://bugzilla.redhat.com/show_bug.cgi?id=2002104

On 9/7/21 12:14 PM, Miroslav Suchý wrote:
Do you want to make Fedora 35 better? Please spend 1 minute of your 
time and try to run:


sudo dnf module reset '*'

sudo dnf --releasever=35 --setopt=module_platform_id=platform:f35 
--enablerepo=updates-testing --enablerepo=updates-testing-modular 
distro-sync




Error:

 Problem 1: package arduino-core-1:1.8.13-5.fc34.noarch requires 
mvn(org.ow2.asm:asm-all), but none of the providers can be installed
  - objectweb-asm-8.0.1-2.fc34.noarch does not belong to a distupgrade 
repository

  - problem with installed package arduino-core-1:1.8.13-5.fc34.noarch
 Problem 2: problem with installed package gnuradio-3.9.0.0-5.fc34.x86_64
  - package gnuradio-3.9.2.0-5.fc35.x86_64 requires 
libcodec2.so.0.9()(64bit), but none of the providers can be installed
  - gnuradio-3.9.0.0-5.fc34.x86_64 does not belong to a distupgrade 
repository

  - codec2-0.9.2-7.fc34.x86_64 does not belong to a distupgrade repository
 Problem 3: problem with installed package gqrx-2.14.4-1.fc34.x86_64
  - package gqrx-2.14.4-5.fc35.x86_64 requires 
libboost_thread.so.1.75.0()(64bit), but none of the providers can be 
installed

  - gqrx-2.14.4-1.fc34.x86_64 does not belong to a distupgrade repository
  - boost-thread-1.75.0-4.fc34.x86_64 does not belong to a distupgrade 
repository
 Problem 4: package gnuradio-3.9.2.0-5.fc35.x86_64 requires 
libcodec2.so.0.9()(64bit), but none of the providers can be installed
  - cannot install both codec2-1.0.0-1.fc35.2.x86_64 and 
codec2-0.9.2-7.fc34.x86_64
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-analog.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-audio.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-blocks.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-channels.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-digital.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-fec.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-fft.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-filter.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-network.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-pmt.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-qtgui.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-runtime.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-soapy.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-trellis.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-uhd.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-video-sdl.so.3.9.2()(64bit), but none of the providers can 
be installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-vocoder.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-wavelet.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
libgnuradio-zeromq.so.3.9.2()(64bit), but none of the providers can be 
installed
  - package gnuradio-devel-3.9.2.0-5.fc35.x86_64 requires 
gnuradio(x86-64) = 3.9.2.0-5.fc35, but none of the providers can be 
installed
  - package freedv-1.6.0-1.fc35.x86_64 requires 
libcodec2.so.1.0()(64bit), but none of the providers can be installed

  - problem with installed package gnuradio-devel-3.9.0.0-5.fc34.x86_64
  - problem with installed package freedv-1.4-6.fc34.x86_64
  - gnuradio-devel-3.9.0.0-5.fc34.x86_64 does not belong to a 
distupgrade repository

  - freedv-1.4-6.fc34.x86_64 does not belong to a distupgrade repository
 Problem 5: cannot install both 

Re: Schedule for Monday's FESCo Meeting (2021-08-23)

[przemek klosowski via devel]

On 8/25/21 4:54 AM, Alexander Sosedkin wrote:

It's not ideal if one obsolete website forces downgrading the security
potentially for all the connections. I hope 5) is addressing that.

That's something apps and only apps can handle.


Well, but if the system policy says that TLS1.0 is banned, the only way 
for the app to downgrade would be if it had its own TLS stack, right?


I do realize that the current policy mechanism is not designed for 
narrow deviations, I am just pointing out that it's not ideal because in 
practice people downgrade because they need narrow deviations for 
specific connections, and as you well know, relaxing the rules for all 
connections opens the door to downgrade attacks even on the connections 
that are capable of TLS2.0.


I am asking if there is another way, for instance by having a 
per-interface policies, and setting up the relaxed rules for an 
interface that routes traffic to this one deficient remote endpoint.


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Schedule for Monday's FESCo Meeting (2021-08-23)

[przemek klosowski via devel]

On 8/23/21 5:49 AM, Alexander Sosedkin wrote:

Sure. Crypto-policies are there to give you control of what's enabled,
ideally what's enabled by default.

1) There's a blanket `update-crypto-policies --set LEGACY`
2) There's a possibility to reenable disabled algorithms with custom policies,
allowing to go even lower than LEGACY (which you
shouldn't really do on public networks, but who's there to stop you)
3) (F35+) There's a possibility to reenable algorithms per backends,
say, for NSS, Java or krb5 only
4) (In an ideal world) crypto-policies settings should act as defaults,
meaning apps should be able to further modify them,
   offer weaker methods with a warning, etc
It's not ideal if one obsolete website forces downgrading the security 
potentially for all the connections. I hope 5) is addressing that.

5) There are total per-backend opt-out mechanisms / procedures
What is the 'backend' in this context? Since the protocol downgrades are 
required by obsolete endpoints to which we're trying to connect, you're 
suggesting 'per IP' or 'per-subnet' opt-out, right? Does it require 
creating separate network interfaces and custom routes?


4 is what broke it here (gnutls currently uses hard-denylisting),
but, in general, you still have all the other ways.
They aren't something we can recommend to all openconnect users,
but we've compromised on not-hard-disabling DTLS 0.9 specifically
until we fix 4 more thoroughly.

If an administrator of the specific host wants to modify or bypass
crypto-policies, it's entirely within their power to do so
and nobody intends (or is able to, for that matters) hinder that.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: systemd-oomd blows away the gnome-shell desktop session

[przemek klosowski via devel]

On 7/27/21 10:04 PM, Aleksei Bavshin wrote:

IIRC, gnome-terminal supposed to put each tab into a new cgroup.


which would address David's problem of losing his desktop session---but 
is still a bad experience, because you'd be running the compile (or some 
other memory-intensive process) in a tab, and the tab will simply 
disappear if OOM happened. This is confusing if you're not paying close 
attention, and unfriendly because the entire context of that shell 
session is lost --- I think even the shell command history is not saved.


What should happen of course is the memory hog should get killed if it 
must, back to the shell prompt.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)

[przemek klosowski via devel]

On 7/9/21 11:48 AM, Ben Cotton wrote:

On Fri, Jul 9, 2021 at 11:45 AM Ben Cotton  wrote:

== Upgrade/compatibility impact ==
SHA-1 algorithm will not be supported in sqlite. Instead SHA-3
algorithm can be used.

== User Experience ==
Users won't be able to use SHA-1 algorithm with sqlite. Instead, they
can use SHA-3 algorithm, or any other supported algorithm.


So what's the story for people who are currently using SHA-1? Is there
an upgrade path for their DBs? Will stuff just stop working?

sqlite uses SHA for checksumming the entire databases and tables (with 
the .sha3sum CLI command), and also provides it as a SQL function, 
presumably to store hashes in SQL tables. As far as I know, it hasn't 
provided the SHA1 version for a while: sqlite-3.34.1-2.fc34 seems to 
only provide the sha3 256-bit versions.


I think that people who used SHA1 must have developed workarounds already.

Having said that, I personally didn't use SHA in sqlite so I may be 
missing something.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Collecting data from Fedora user community

[przemek klosowski via devel]

We had several discussions recently that could use some real-world data 
on e.g.:


- x86_64-v2 prevalence

- GUILE usage in make/gdb

- count of systems with UEFI/GPT vs BIOS/MBR

- debugd server usage

- etc

The common thread is that some sort of measurement would help figuring 
out the best technical solution for the Fedora community, but such 
measurement would require transmitting and collecting data in the Fedora 
infrastructure.  Such telemetry is usually criticized from two related 
angles: a general objection to online telemetry, and a practical 
argument about the complicated legal ramifications of online data 
collection in multiple jurisdictions. Stephen recently responded with an 
eloquent argument why it's very hard to come up with an acceptable 
collection scheme (see below).


This problem is of course not unique to Fedora---everyone is in the same 
boat of finding a middle ground between anonymity and indiscriminate 
data collection. I think most people would agree that data-driven 
decisions are better than gut feeling-based ones, so it is to our 
benefit to control and possibly allow _some_ data to be used for that 
purpose.


Few days ago I attended a talk by a practicing data scientist working 
with social data where the privacy issues are even more important: some 
of the data can literally have life-altering consequences to people 
covered by the collection. I asked him about the best practices and 
guidelines for responsible data collection, and he directed me to this 
presentation:


https://the-engine-room.github.io/responsible-data-handbook/pages/slides.html

My personal take-aways from reading this material are:

- we're not alone in this---other people have thought through these 
issues and came up with workable ideas


- it helps to keep things in perspectivethe data about people's 
computers is less consequential than e.g data about their ethnicity or 
politics


- there are legal requirements for Consent (notice/disclosure): they are 
workable, though


- it matters how the data is used: publishing full logs vs. using the 
aggregated data for internal improvement


Anyway, this is my personal, uneducated take on it. Hope it is helpful.


On 6/18/21 9:39 AM, Stephen John Smoogen wrote:

On Fri, 18 Jun 2021 at 01:51, Gerd Hoffmann  wrote:

   Hi,


The problems with this is that we are taking a fairly fuzzy data set
and making it much easier to track individual users in ways seen as
problematic by various laws and regulations.

Well, depends on how you store the data.  You can store one record per
machine (with all properties in there), or you can store one record per
property per machine.

With the latter you basically kill query on subgroups (like "how many
x86_64-v3 machines use UEFI?") because that grouping information is gone
if you store each end every little piece of information in its own
record.  But it'll also much harder to do fingerprinting on such a data
base ...

Standard disclaimer: IANAL.


The problem with IANAL, is that we all come up with great solutions
which seem to match the single document we read. However the law is an
interpreted language where every court is a slightly different
architecture and has different libraries which have to be slowly
interpreted and patched at a top level. This means that you end up
with finding out that the document and 2500 years of law rulings have
to be interpreted together.

The way things are interpreted currently, it doesn't matter that you
stored it differently.. it matters that you collected it... mainly
because there is a long history of people finding ways to de-anonymize
data, people lying about anonymizing it, and people somehow collecting
the data in the middle. Because of that you end up having to delete
all the data when someone asks to be deleted because you can't prove
this record/count was their system or not.

In general we computer people like to dive in and just collect data
and go about doing analysis. The various privacy laws are written to
make us do a LOT of hard work before we start doing that. You end up
spending a lot of time with lawyers versed in European, Brazilian, and
various other countries laws/regulations/past history to figure out
what you can collect, how you can collect it, how you are going to
delete it, how you are going to inform people that things are
happening, and having clear processes that are followed. Then you can
start writing the code.. while doing that you have to review the code
to make sure it is still meeting current rulings.  [Doing it another
way ends up with you writing code and either finding you have to
delete it all or waiting months for an approval before rolling it
out.]


___
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: 

Re: x86_64-v2 in Fedora

[przemek klosowski via devel]

On 6/17/21 4:44 AM, Vitaly Zaitsev via devel wrote:

On 16.06.2021 22:22, Matthew Miller wrote:

Well, that's certainly A Position. I don't think it's anything nearly so
absolute, though, and depends on what, who, how, why, and a host of 
other
things. And "it can help us answer questions like this for our 
community" is

a pretty non-evil "why".


Built-in system level keylogger in one well-known operating system 
also helps its developers?


You are arguing a 'slippery slope' of increasingly intrusive telemetry, 
but we should judge each thing on its own merits. Yes, a keylogger is a 
bad idea--but it does not follow that keeping track of the hardware 
configurations, or logging software failures is also super-bad. If the 
benefits outweigh costs, the tradeoff is worth considering---this is 
true of software just as well as of, say, vaccines.


The problem with 'slippery slope' arguments is that they themselves can 
be abused to say that no change is possible because it could be taken 
too far and lead to abuse.


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package maintainer docs: Package Retirement: `git rm` all files in the other branches

[przemek klosowski via devel]

On 6/16/21 6:26 PM, Kevin Kofler via devel wrote:

Otto Urpelainen wrote:

Also, if the intent is to get rid of the package completely, should not
adding it to fedora-obsolete-packages be required as well?

Why? Adding working packages to fedora-obsolete-packages forces removing
them from users' machines just because they are no longer in the repository.
That is a major disservice to the users. fedora-obsolete-packages makes
sense to use only when having the package still present actually breaks
something (and I personally think that it is unhelpful even in that case,
that is really what dnf --allowerasing is for, at least when we are talking
about package-level conflicts).


This is correct from the strict OS packaging point of view, but I think 
we should be concerned about the accumulation of detritus: packages that 
broke over time and simply do not work any more, for example like this one


https://bugzilla.redhat.com/show_bug.cgi?id=1490074

If unchecked, they make the system look like the FTP archives of last 
century---strewn with broken, unmaintained stuff.


Of course new installs would not get these packages, only the old, 
upgraded releases, so it only affects the people who update a lot.


Unfortunately, the tooling to clean it up is not that nice: the 
%{RELEASE} RPM querytag is noisy so it needs to be touched up


rpm -qa --queryformat "%{release}\n" | perl -ne 'next unless /(fc\d+)/; 
print "$1\n"'  | sort  | uniq -c | sort -n


  1 fc28
  2 fc30
  3 fc29
 14 fc31
 15 fc32
 33 fc33
   4895 fc34

I sometimes run this on my systems and investigate why do I still have 
FC2x package. Usually it is just some abandonware; in this case,


rpm -qa | grep fc2

    glibc-arm-linux-gnu-2.27-4.fc29.x86_64
    emacs-verilog-mode-531-13.fc29.noarch
    emacs-php-mode-1.18.2-2.fc28.noarch
    emacs-mew-6.8-2.fc29.x86_64

I think quietly deleting this stuff would be a little harsh, but maybe 
it should be flagged in some way or at least easier to find and clean up?


BTW, I remember a discussion about obsolete gpg-pubkeys being a security 
hole; again, cleaning them up would make sense. They are not included in 
the list above---their %{release} sadly doesn't include the fedora 
version; it is only informally (?) mentioned in the %{PACKAGER} and 
%{SUMMARY} tags, making it hard to automate.


So, I'd like to at least propose that gpg-pubkeys packages have the 
Fedora version they pertain to in their %{RELEASE} tag.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[przemek klosowski via devel]

On 6/16/21 12:09 PM, Florian Weimer wrote

I'm missing something---I get identicaloutput on my v3 Core i7-4810MQ

Why do you expect different output?


Stephen was showing off his 'oldest' system and I assumed that it was 
some Penryn-era relic, so I expected a <= v1 result. One cohort of 
people in this discussion argue that even the oldest systems are quite 
capable, and another cohort argues the opposite by showing off their 
'black beauty' (CarTalk(TM)) antiques that they are loathe to retire. I 
mistook Stephen for the latter :)


In my limited understanding of HWCAPs, it run-time switches between 
different code paths for differently capable exec environments---and 
misreading Stephen's post made me wonder if it somehow emulates the 
newer ones, which didn't make sense.


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[przemek klosowski via devel]

On 6/16/21 8:45 AM, Stephen John Smoogen wrote:

oh cool. this even works on CentOS and RHEL systems:
```
smooge@xanadu ~]$ podman run fedora:latest /lib64/ld-linux-x86-64.so.2 
--help

...
Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

Legacy HWCAP subdirectories under library search path directories:
  haswell (AT_PLATFORM; supported, searched)
  tls (supported, searched)
  avx512_1
  x86_64 (supported, searched)
[smooge@xanadu ~]$ uname -a
Linux xanadu.int.smoogespace.com 
 
4.18.0-305.0.1.el8.x86_64 #1 SMP Fri May 28 11:04:28 UTC 2021 x86_64 
x86_64 x86_64 GNU/Linux

```
from my oldest system.


I'm missing something---I get identicaloutput on my v3 Core i7-4810MQ

Is this supposed to run HWCAP and show the result, or just show the 
HWCAP configuration and possible choices?


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)

[przemek klosowski via devel]

On 5/25/21 5:04 PM, Peter Boy wrote:

So the same model works totally fine for both desktop and server.

I myself lack the exact technical knowledge, but (all?) server and file system 
experts I hear consider just that a gross misconception.


I think you and Neal talk about two different things. The BTRFS 
proponents claim that the subvolume technology allows you to have 
flexible partitioning, so that you can dynamically create whatever 
partition layout is appropriate for your situation. Nobody is claiming 
that desktop partition scheme ('model') should be forced onto servers.


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: When is pappl going to be good enough to replace cups?

[przemek klosowski via devel]

There are so many moving pieces here that it's hard to get a handle on 
this. I had trouble seeing local network printers so I tried following 
the advice Zdenek published [1], but I ran into a nest of issues: 
printing depending on avahi, which fails quietly and is hard to debug.


Specifically, I did *avahi-browse -avrt*  which just returns with
avahi_service_browser_new() failed: Invalid service type

This seems to be related to a bug where some devices are sending 
non-compliant data to avahi: https://github.com/lathiat/avahi/issues/212 
but we're already far away from the print subsystem.. I tried running 
avahi-browser under gdb but between the missing and not-autoloading 
debuginfo packages, and the callback-style structure, I wasn't able to 
catch it receiving the data that causes the problem.


I guess my point here is that we have a complex, interdependent system, 
and when it fails, it is fairly opaque. At this point I am not sure what 
to do: is the root cause here the avahi bug? I am willing to spend the 
effort getting to the bottom of it but I can't figure out where to start.





On 5/24/21 1:42 PM, Stephen John Smoogen wrote:
I have had very bad luck in setting up new network printers over the 
last 4 years. I can get all of them to print from Windows and Mac, 
but every one of them from HP, Brother, and some other brands could 
not print anything from Linux. They were all 'Linux ready' but were 
doing it via either Google Print or a set of proprietary software 
blobs to be put on the computer. [They even came with ipp filters but 
they called the blobs]. I have a Brother MFC-27100W in my office 
which I print to via my wife's Mac because of this.


I have written some basic info about how to find out whether your 
printer supports driverless [1] and how to setup it [2]. If you have 
at least F33 and have the device in your LAN, you can use temp queues 
for sure, otherwise you need to create a permanent queue via lpadmin:


$ lpadmin -p  -v  -m everywhere -E


If you still experience the issue, do feel free to file a bug for cups 
in bugzilla and I can look into it further.



[1] 
https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_find_out_whether_my_printer_is_capable_of_driverless_printing.3F


[2] 
https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_setup_CUPS_temporary_queues_with_network_printer



___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Drop the the "Allow SSH root login with password" option from the installer GUI (Self-Contained Change proposal)

[przemek klosowski via devel]

On 5/15/21 11:53 AM, Ralf Corsepius wrote:

Creating a non-root user account, possibly with admin rights (all
possible from within Anaconda) would seem like a safer option for
accasional/emergency password based access to such machines over SSH.


I don't see, how this would any safer than directly using "root". 
in many environments such user account is federated 
(kerberos/AD/NIS/whatever), so it can be managed more easily than a 
bunch of roots. Plus there's some accountability as to who did what.
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RPM name collisions

[przemek klosowski via devel]

On 5/7/21 12:08 PM, Adam Williamson wrote:

Really? I mean, third party repos have been around forever. It's not
like they're a new thing. I'm not really opposing any sensible
improvements here, I'm just not seeing the same clear story as you are
here? Why do you think there are going to be a lot more third party
repos used in future?


I'm not saying things are horrible now--just that the trend is slightly 
alarming ("We have to know where we are but even more importantly, where 
we're heading"). Realistically, there's so much already in 
fedora/updates/rpmfusion that it's hard to maintain it at level (java:), 
so we'll probably be using third-party repos because they are better 
than curl|bash :). I think it's cool that MS is publishing their 
software via RPM repos.


I looked at my own system and saw that I have 12 active repos, and 50 
total (as shown by repolist --all, including all the 
debuginfo/source/testing/etc) I had RoCm for OpenCL, someone's repo for 
Atom, Microsoft when I was checking out PowerShell and VSCode, an old 
cisco-h264 from when I needed it  for video. The system works very 
well---I was getting updates automagically, and whatnot. But there's 
also breakage: h264 and atom repos disappeared, so I disabled them out 
of extra caution.


Bottom line for this conversation is:  I am glad to see that the DNF 
team is thinking about those issues.


Maybe I'm getting it all wrong worrying about RPM because the future 
third-party software will ship in containers or flatpaks, but as of now 
I am not a fan of those.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RPM name collisions

[przemek klosowski via devel]

On 5/5/21 2:29 AM, Adam Williamson wrote:


  If a third party wants to do
something nefarious and can convince you to "install a repository" in
some way, that means that at minimum they convinced you to drop an
arbitrary file in /etc/yum.repos.d . What they probably did was
convince you to install a package containing the repo definition, as
that's the way most third party repos deploy. Well, that package could
do*absolutely anything else at all*  on your system with root
privileges, because that's how packaging works.


Right, of course, but there are more possibilities between 'completely 
trustable repo' and 'totally evil repo'. We used to control the repos in 
the set likely to be used by most Fedora users, and managed them 
consistently. I assume that in the future there will be more repo 
diversity with all kinds of rules and little leverage to make them 
consistent, which would inevitably end up in confusion.


Essentially, now the package names are in a global name space, which, as 
we remember from the programming languages history, tends to be problematic.


I liked Daniel Mach's ideas about vendor-lock and how it might actually 
be a way to re-implement modularity. I think they would create implicit 
namespaces that would mitigate the above concerns.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: how to ignore fedora's rawhide repo in the kickstarts file?

[przemek klosowski via devel]

so fedora-live-base.ks includes fedora-repo.ks which by default has 
fedora-repo-rawhide.ks uncommented (and fedora-repo-not-rawhide.ks 
commented out). I think the only way would be to edit that file. Of 
course you can edit it programmatically, or via some sort of symlink 
swapping


ln -sf /usr/share/spin-kickstarts/fedora-repo{,-not-rawhide}.ks

What are your goals and/or requirements here---not having to modify the 
RPM-owned directory?


On 5/4/21 6:15 PM, Globe Trotter via devel wrote:

Ny kickstart file has the following:

%include /usr/share/spin-kickstarts/fedora-live-base.ks
%include /usr/share/spin-kickstarts/fedora-live-minimization.ks

But I have noticed that it wants to go into the rawhide repo. That is because 
/usr/share/spin-kickstarts/fedora-live-base.ks has fedora-repo-rawhide.ks as 
the repo by default. Now, I know that I can comment it out but I dont want to 
do this everytime. Is it possible to require the repo to be set at 
fedora-repo-not-rawhide.ks by default without modifying the system file?

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

RPM name collisions

[przemek klosowski via devel]

Few weeks ago we had an announcement of a Python supply chain hack where 
people supplied libraries with names matching some private library 
names, which took precedence and overrode those private libraries, 
giving the hackers control.


Now, the name collisions are built-in into RPM, because that's how 
updates work: the original package is in 'fedora' and the updates are 
in, well, 'updates'.  This is fine as long as we control all 
repositories, but the recent trend is to loosen up and increase the 
repository set: rpmfusion, ROCm, packages-microsoft-com-prod are likely 
to be used because they contain useful software. I am all for including 
them, but since we have no control over them, necessarily, maybe we 
should rethink the consequences for the end users.


Specifically, for example, Microsoft likes to keep multiple versions 
online: for instance  aadlogin has nearly 30 versions from 
1.0.00485001-1 to 1.0.015280001-1. As long as this is their exclusive 
package, this is fine---but sometimes it gets more complicated than 
that. For instance, there's aspnetcore-runtime, which is in Fedora, but 
also has nearly 70 versions in MS repo (they cover aspnetcore-runtime 
versions from 2.1 to 5.0; just the 3.1 variants amount just to 18 or so 
packages, that intersect with Fedora ones:


...

aspnetcore-runtime-3.1.x86_64    3.1.12-1 packages-microsoft-com-prod
aspnetcore-runtime-3.1.x86_64    3.1.13-1 packages-microsoft-com-prod
aspnetcore-runtime-3.1.x86_64    3.1.13-2.fc34 fedora
aspnetcore-runtime-3.1.x86_64    3.1.14-1 packages-microsoft-com-prod
aspnetcore-runtime-3.1.x86_64    3.1.14-1.fc34 updates
...

These packages are actually coming from Microsoft, and the versioning 
seems consistent, so I guess there's nothing wrong with this setup 
besides a possibility for confusion as to which one is actually 
installed. But sometimes the versions are much more divergent:


netstandard-targeting-pack-2.1.x86_64  2.1.0-1 packages-microsoft-com-prod
netstandard-targeting-pack-2.1.x86_64  5.0.104-1.fc34 fedora
netstandard-targeting-pack-2.1.x86_64  5.0.202-1.fc34   updates

and here's a really weird one:

hello.x86_64    2.8-1    packages-microsoft-com-prod
hello.x86_64    2.10-5.fc34   fedora

Why would they put it in their repo? I don't expect any harm here, but 
just looking at this this made me think of the Python debacle I 
mentioned earlier.


Is that something we need to worry about? I couldn't think of any new 
rules to impose on repositories, but maybe dnf should have more explicit 
warnings when it sees multiple versions of the same package, or at least 
a way to show such versions.


As it is now, I think it just handles the most current version, but this 
is fragile across separately managed repositories, and doesn't easily 
show all the available versions---in order to collect the data I wrote a 
script that iterates over 'yum repolist' and disables */enables one repo 
at a time.





For completness, here are the remaining strange cases:

openhantek.x86_64  2.06-1.fc31    rpmfusion-nonfree
openhantek.x86_64  3.2-1.fc34 fedora

procdump.x86_64   1.1-207         packages-microsoft-com-prod
procdump.x86_64   1.1.1-3.fc34    fedora
procdump.x86_64   1.1.1-218  packages-microsoft-com-prod
procdump.x86_64   1.1.1-220  packages-microsoft-com-prod
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Another F34 update experience : gtatools-*

[przemek klosowski via devel]

On 4/28/21 6:01 PM, Adam Williamson wrote:


On Wed, 2021-04-28 at 17:42 -0400, przemek klosowski via devel wrote:

Trying to update F33 -> F34 on a development laptop with about 4700
packages. I think it started as F30 and did three Fedora system upgrades.
...

I am getting four errors:
...
The first three can be solved by erasing gtatool-gdal, gtatool-matlab
and rdma-core-34.0-1.fc33.i686. The first two are relatively painless,
but rdma-core forces the removal of the entire Wine installation--I did
it and plan/hope to reinstall Wine after the upgrade.

It's worth trying the upgrade with --allowerasing instead of rolling
your own erasures. It may be able to come up with a strategy that
involves removing less stuff.


In my defense I am a little apprehensive about --allowerasing because I 
have a hole in my pants from being bitten by it years ago and having to 
rescue-install hundreds of packages including RPM :).  Of course I know 
that I don't have to worry about it any more because of protected 
packages---in fact one of my 'rolled-own' erasure pulled systemd and 
triggered the protected package fuse, so I know it works!


However, in this case, --best --allowerasing  trips up the following 
errors, while plain upgrade just skips packages with conflicts ( 
iptables-libs ) and broken dependencies (gst and gwe ).


 Problem 1: problem with installed package gst-0.7.4-2.fc33.noarch
  - cannot install the best update candidate for package 
gst-0.7.4-2.fc33.noarch

  - gst-0.7.4-2.fc33.noarch does not belong to a distupgrade repository
  - nothing provides python3-pyxdg >= 0.27 needed by 
gst-0.7.5-2.fc34.noarch

 Problem 2: problem with installed package gwe-0.15.2-1.fc33.noarch
  - cannot install the best update candidate for package 
gwe-0.15.2-1.fc33.noarch

  - gwe-0.15.2-1.fc33.noarch does not belong to a distupgrade repository
  - nothing provides python3-pyxdg >= 0.27 needed by 
gwe-0.15.3-1.fc34.noarch
 Problem 3: cannot install the best update candidate for package 
iptables-1.8.5-6.fc33.x86_64

  - problem with installed package iptables-1.8.5-6.fc33.x86_64
  - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) 
= 1.8.7-3.fc34, but none of the providers can be installed
  - cannot install the best update candidate for package 
iptables-libs-1.8.5-6.fc33.x86_64
  - cannot install both iptables-libs-1.8.7-3.fc34.x86_64 and 
iptables-libs-1.8.7-6.fc34.x86_64
  - iptables-1.8.5-6.fc33.x86_64 does not belong to a distupgrade 
repository

(try to add '--skip-broken' to skip uninstallable packages)

Indeed adding --best --allowerasing --skip-broken skips those three 
packages again, i.e. behaves like a plain system-upgrade with no options.



In general, if the problem is basically "package X wasn't rebuilt for a
library soname bump", the appropriate step is to file a bug against
package X. For the gtatool stuff, though, it looks to me like it got
orphaned and retired, but has not been specifically obsoleted; we may
need to put it in fedora-obsolete-packages. There were several attempts
to rebuild it between July and November, but they all apparently failed
(well, the last seems to have succeeded but was never tagged and has
been garbage-collected), and now it's been orphaned.


So if they did succeed, wouldn't it make sense to include them? I am a 
reasonably heavy Octave user, and although I actually didn't have to 
load Matlab files recently, I think it is a useful feature. Maybe Orion 
has an opinion about this?

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Another F34 update experience : gtatools-*

[przemek klosowski via devel]

Trying to update F33 -> F34 on a development laptop with about 4700 
packages. I think it started as F30 and did three Fedora system upgrades.


I did the standard

   dnf upgrade --refresh

   dnf system-upgrade --releasever=34 download

I am getting four errors:


 Problem 1: package gtatool-gdal-2.2.3-6.fc33.x86_64 requires 
libgdal.so.27()(64bit), but none of the providers can be installed
  - gdal-libs-3.1.4-2.fc33.x86_64 does not belong to a distupgrade 
repository

  - problem with installed package gtatool-gdal-2.2.3-6.fc33.x86_64
 Problem 2: package gtatool-matlab-2.2.3-6.fc33.x86_64 requires 
libmatio.so.9()(64bit), but none of the providers can be installed

  - matio-1.5.17-4.fc33.x86_64 does not belong to a distupgrade repository
  - problem with installed package gtatool-matlab-2.2.3-6.fc33.x86_64
 Problem 3: rdma-core-34.0-1.fc33.i686 has inferior architecture
  - rdma-core-34.0-1.fc33.x86_64 does not belong to a distupgrade 
repository

  - problem with installed package rdma-core-34.0-1.fc33.i686
 Problem 4: package openexr-libs-2.5.5-1.fc34.x86_64 obsoletes 
OpenEXR-libs < 2.5.3 provided by OpenEXR-libs-2.3.0-8.fc34.x86_64
  - package Field3D-1.7.3-10.fc34.x86_64 requires 
libHalf-2_5.so.25()(64bit), but none of the providers can be installed
  - package Field3D-1.7.3-10.fc34.x86_64 requires 
libImath-2_5.so.25()(64bit), but none of the providers can be installed
  - package gtatool-hdr-2.2.3-6.fc33.x86_64 requires 
libIlmImf-2_3.so.24()(64bit), but none of the providers can be installed

  - problem with installed package Field3D-1.7.3-5.fc33.x86_64
  - OpenEXR-libs-2.3.0-6.fc33.x86_64 does not belong to a distupgrade 
repository

  - Field3D-1.7.3-5.fc33.x86_64 does not belong to a distupgrade repository
  - problem with installed package gtatool-hdr-2.2.3-6.fc33.x86_64

The first three can be solved by erasing gtatool-gdal, gtatool-matlab 
and rdma-core-34.0-1.fc33.i686. The first two are relatively painless, 
but rdma-core forces the removal of the entire Wine installation--I did 
it and plan/hope to reinstall Wine after the upgrade.


The fourth problem looks like requiring removal of OpenEXR-libs, but 
that forces removal of 121 packages including ImageMagick, gimp, 
blender, lyx and texlive, which seemed harsh.


It turns out that it can be solved by removing gtatool-hdr, though! This 
wasn't obvious to me at first sight---I only tried it because of the 
other gtatool-* packages causing problems, prejudicing me slightly.


I haven't reported it in Bugzilla yet---what package should I report it 
against? OpenEXR-libs? gtatool-hdr?


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Default 'fedora' hostname and failing split DNS VPN

[przemek klosowski via devel]

I've been having problems with DNS resolution in F33 as well: I use F5 
VPN (work requirement).


I tried your nsswitch recipe, but got some errors:

   authselect apply-changes
   [error] [/etc/nsswitch.conf] is not a symbolic link!
   [error] [/etc/nsswitch.conf] was not created by authselect!
   [error] Unexpected changes to the configuration were detected.
   [error] Refusing to activate profile unless those changes are
   removed or overwrite is requested.
   Some unexpected changes to the configuration were detected. Use
   'select' command instead.

and the DNS still returns 'Name or service not known'

I've been successfully fixing my problem by running explicit

   sudo resolvectl dns eno1 

   sudo resolvectl domain eno1 


As to the issues with F5, I see that it rewrites /etc/hosts

#F5 Networks Inc. :File modified by VPN process
127.0.0.1   localhost localhost.localdomain localhost4 
localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 
localhost6.localdomain6


12.34.56.78 f5.server.mycompany.com

BTW, why isn't RPM seeing that change?

rpm -qf /etc/hosts
setup-2.13.7-2.fc33.noarch

rpm -q --verify setup
.M...  c /etc/fstab
S.5T.  c /etc/printcap
.MG..  g /var/log/lastlog


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[przemek klosowski via devel]

On 12/29/20 11:26 PM, Samuel Sieb wrote:

More likely what you're really confused about is something that a lot 
of people are not aware of.  Wayland is a protocol, not a program.  I 
believe there's a library, but the final implementation is done in 
each window manager.  The X11 "emulation" is a program called XWayland 
that provides an interface layer between the X11 calls and whatever 
Wayland implementation is currently running. 


Thanks for clarifying; indeed it's the XWayland process that crashes.

I actually support leaving X11 behind---I use wayland myself and I agree 
it's the correct evolutionary path for system graphics.


I piped up in this discussion to point out that Wayland has rough 
spots.  There are many legacy X11 apps still around, some possibly 
buggy. They should not crash XWayland in a way that nukes the entire 
desktop.


Another problem is the reliability of input streams. The mouse behavior 
is realy weird sometimes, as if it was simultaneously losing events and 
getting spurious ones.


I suspect that these issues are marginal enough to not affect the 
majority of users, which is why they aren't seen as urgent, but I think 
they should be addressed for a mainstream Wayland use. I would like to 
help debugging that, but it's a complex system and I wasn't able to find 
reliable information on how to look inside those issues. For instance, I 
understand the separation of layers in X11, and I know how to debug X11 
events using xev and such---but I have no idea how to look into why my 
mouse clicks in Firefox under Wayland are so weird and unpredictable.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[przemek klosowski via devel]

On 12/29/20 5:20 PM, Michael Catanzaro wrote:


I don't think this GNOME bug is in any way related to the topic of 
whether KDE should default to Wayland


So I am confused---I thought it is a problem in Wayland, perhaps in its 
X11 emulation but still Wayland.  Yes, the app is misbehaving, but 
Wayland should be resistant to this 'fuzzing'.


Re, this being the GNOME bug, I think any app with this behavior will 
similarly crash wayland even if it is not GTK app, and regardless 
whether it's running under KDE or Gnome---but I was not able to 
understand the GTK app enough to write a minimal replication.


Perhaps you are implying that when Wayland is the only choice, X11 
applications will be replaced by wayland apps and the X11 emulation will 
be removed form Wayland, so this will no longer be an issue?


I thought I checked that the 'true' X11 server does not crash in this 
scenario,  but I realize now that I am not sure.


BTW, I did report this in Gnome as well 
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/9

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[przemek klosowski via devel]

On 12/28/20 3:51 PM, Gerald B. Cox wrote:

I really don't see we have much of a choice here.  X11 is eventually going away 
and Wayland is the path forward.

...

If you notice issues, please open bugs.


I have an open bz about reliable wayland crashes:

https://bugzilla.redhat.com/show_bug.cgi?id=1539992

Besides being very inconvenient because of course they take the entire 
session with it, such crashes can usually be leveraged to achieve code 
execution, and if the behavior can be triggered by remote data, RCEs. 
Therefore, I would argue it is a serious issue.


Basically, the crash is triggered by excessive resource usage that can 
be seen via xrestop. Unfortunately I was unable to debug the issue: the 
GTK+  forest overwhelmed my capabilities ('callbacks, callbacks, 
everywhere').


This is an old bug currently assigned to gnome-session. Should I 
reassign it to Wayland?

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: drop "Test installation media" from live media

[przemek klosowski via devel]

On 12/17/20 10:04 AM, Marius Schwarz wrote:

Am 17.12.20 um 14:35 schrieb Stephen John Smoogen:
Right, but it's not automatic, and requires an existing known-good 
system, which is the actual 'root of trust' here. This cannot be 
assumed about a flash drive, which is why the automatic image check 
is hard. 


Speaking from Security pov, it's not hard, it's impossible. The 
attacker can sign everything with it's own cert and putting that into 
the image itself. Way easier is it to remove the check for a valid sig 
and always return "true" is asked for a match, as any root kit will do.


In a secure boot environment, the root of trust is the motherboard 
firmware, which has the keys of the next boot step. In Fedora land, this 
next step is the shim, which was signed by Microsoft because their key 
is on practically all existing hardware. As I said, the shim would have 
to be smart enough to securely (TLS) retrieve the signature, and check 
the boot image.


https://docs.fedoraproject.org/en-US/Fedora/18/html-single/UEFI_Secure_Boot_Guide/index.html#sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Keys

In this scenario, the attacker cannot fake the key, because both UEFI 
and the shim will stop the boot if their measurements fail to check out,


I don't know if the UEFI/shim combo can be enhanced to do those things, 
though...

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: drop "Test installation media" from live media

[przemek klosowski via devel]

On 12/16/20 5:38 PM, Kevin Fenzi wrote:

On Wed, Dec 16, 2020 at 04:28:49PM -0500, przemek klosowski via devel wrote:

I was trying to make a point that we don't have a way to check the initial
image: it could be altered to falsely claim to be signed by fedoraproject.

well, we do: https://getfedora.org/security/


Right, but it's not automatic, and requires an existing known-good 
system, which is the actual 'root of trust' here. This cannot be assumed 
about a flash drive, which is why the automatic image check is hard.


I guess it would involve a secure boot into a fedora signed shim that

 * retrieves the checksum over a verified TLS network connection
 * checks the image against that.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: drop "Test installation media" from live media

[przemek klosowski via devel]

On 12/16/20 2:23 PM, Kevin Fenzi wrote:

Yeah, there has to be an anchor for your trust. Right now that is "I
trust the certificate authority that issued fedoraproject.org's cert".


I was trying to make a point that we don't have a way to check the 
initial image: it could be altered to falsely claim to be signed by 
fedoraproject.


The image check, in other words, defends against random corruption, and 
is helpless against targeted hacking. I thought it would be good to have 
a method to assure that it is indeed the same image that fedoracorp.org 
originally signed.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: drop "Test installation media" from live media

[przemek klosowski via devel]

On 12/11/20 1:07 PM, Matthew Miller wrote:

Right now, when you start Fedora live media to install Workstation or KDE or
etc., you get an ugly text prompt which defaults to doing a media test
...
  the most likely failure modes are like this:

1) Doesn't even write properly.
2) Doesn't boot after you created it.
3) Fails hard and it's definitely done
4) Random transient errors


5) I got this image from the internet, and who knows what is in it.

It is an ongoing problem in the Windows world: searches for apps often 
lead to third party sites which add adware (and sometimes malware) to 
the installers.


Of course the media test does not protect against this type of 
abuse---fake sites could modify the test as well as the image. 
Therefore, I actually agree with changing the default---but it sure 
would be nice if there was an option to check it, preferably more 
reliable than the current method.


It always bugged me that in general, RPM nicely protects the system 
integrity by signing/verifying packages but 'qui custodiet ipsos 
custodes': the repo keys are implicitly accepted, both during the 
installation and afterwards, when additional repo package signing keys 
are brought in. This is especially relevant today, with the news about 
the Russians backdooring the supply chain of an important application 
(SolarWinds) that was then widely installed and exploited.


I see the need to self-validate against known-good images/repos, either 
by checking online, or by leveraging the secure boot, somehow, 
Unfortunately I can't think of a foolproof and transparent way of doing 
it. As it is, I always try to google the key IDs/fingerprints and make 
sure that they correspond to legit package signing keys, but it's all so 
manual.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[przemek klosowski via devel]

On 11/17/20 4:24 AM, Lennart Poettering wrote:

dig @9.9.9.9 +nsid heise.de


FWIW, a neat way to look at differences like that is

    watch -d dig @9.9.9.9 +nsid heise.de

I use it often for looking at hotplugs (watch -d lsusb) etc.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Donate 1 minute of your time to test upgrades from F32 to F33

[Przemek Klosowski via devel]

On 10/2/20 3:50 AM, Miroslav Suchý wrote:

Do you want to make Fedora 33 better? Please spend 1 minute of your time and 
try to run:

   sudo dnf --releasever=33 --setopt=module_platform_id=platform:f33 \
 --enablerepo=updates-testing --enablerepo=updates-testing-modular \
 distro-sync


Fedora 33 openh264 (From Cisco) - x86_64 8.9 kB/s | 5.1 kB 00:00
Fedora Modular 33 - x86_64 2.0 MB/s | 3.3 MB 00:01
Fedora Modular 33 - x86_64 - Updates 712  B/s | 257  B 00:00
Fedora Modular 33 - x86_64 - Test Updates 1.3 MB/s | 1.0 MB 00:00
Fedora 33 - x86_64 - Test Updates 4.6 MB/s |  18 MB 00:03
Fedora 33 - x86_64 - Updates 844  B/s | 257  B 00:00
Fedora 33 - x86_64 6.4 MB/s |  65 MB 00:10
RPM Fusion for Fedora 33 - Free - Updates 363  B/s | 257  B 00:00
RPM Fusion for Fedora 33 - Free 969 kB/s | 913 kB 00:00
RPM Fusion for Fedora 33 - Nonfree - Updates 629  B/s | 257  B 00:00
RPM Fusion for Fedora 33 - Nonfree 339 kB/s | 278 kB 00:00
Error:
 Problem 1: problem with installed package mosquitto-1.6.10-1.fc32.x86_64
  - mosquitto-1.6.10-1.fc32.x86_64 does not belong to a distupgrade 
repository
  - nothing provides libwebsockets.so.16()(64bit) needed by 
mosquitto-1.6.12-1.fc33.x86_64
 Problem 2: package collectd-mqtt-5.9.2-2.fc32.x86_64 requires 
collectd(x86-64) = 5.9.2-2.fc32, but none of the providers can be installed
  - collectd-5.9.2-2.fc32.x86_64 does not belong to a distupgrade 
repository

  - problem with installed package collectd-mqtt-5.9.2-2.fc32.x86_64
 Problem 3: package gtatool-pcd-2.2.3-6.fc33.x86_64 requires 
libpcl_common.so.1.9()(64bit), but none of the providers can be installed
  - package gtatool-pcd-2.2.3-6.fc33.x86_64 requires 
libpcl_io.so.1.9()(64bit), but none of the providers can be installed
  - package gtatool-pcd-2.2.3-6.fc33.x86_64 requires 
libpcl_octree.so.1.9()(64bit), but none of the providers can be installed

  - problem with installed package gtatool-pcd-2.2.3-4.fc32.x86_64
  - pcl-1.9.1-6.fc32.x86_64 does not belong to a distupgrade repository
  - gtatool-pcd-2.2.3-4.fc32.x86_64 does not belong to a distupgrade 
repository
 Problem 4: package qgis-3.12.1-4.fc33.x86_64 requires 
libQt5Core.so.5(Qt_5.14.2_PRIVATE_API)(64bit), but none of the providers 
can be installed
  - package qgis-3.12.1-4.fc33.x86_64 requires 
libQt5Sql.so.5(Qt_5.14.2_PRIVATE_API)(64bit), but none of the providers 
can be installed

  - problem with installed package qgis-3.12.1-4.fc32.x86_64
  - qt5-qtbase-5.14.2-5.fc32.x86_64 does not belong to a distupgrade 
repository

  - qgis-3.12.1-4.fc32.x86_64 does not belong to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: EXTERNAL: Re: hundred percent cpu load

[Przemek Klosowski via devel]

On 8/14/20 8:33 AM, Wells, Roger K. via devel wrote:

That was not the cause.
Now when it happens I have only three tasks running at 100% (same ones
as reported earlier).
Everything else, kerneloops, shutdown via power switch, etc, is as before.


Could you repost to the list with more info? I think you're saying that 
after removing sadc you still are 100% CPU with


kworker/6:1+events_freezable
dmesg
systemd-journal

running full tilt. THis probably means that it's the kernel worker threads are 
doing something that causes lots of errors, and all the other processes 
(including sadc that is now gone) are just busy writing those errors.

So, what is kernel doing? what does your system log say? type 'dmesg' or 
'journalctl -e' and look at the end of the data.

Also, the perf toolkit might help as explained in 
https://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu

1.

   Install |perf|:

   |sudo apt-get install linux-tools-common linux-tools-3.11.0-15-generic |

   (The second package must match your kernel version. You can first
   install just |linux-tools-common| and call |perf| to let it tell you
   which package it needs.)

2.

   Record some 10 seconds of backtraces on all your CPUs:

   |sudo perf record -g -a sleep 10 |

3.

   Analyse your recording:

   |sudo perf report |


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: EarlyOOM +ZRAM Only

[Przemek Klosowski via devel]

On 8/14/20 7:33 AM, John M. Harris Jr wrote:

On Wednesday, August 12, 2020 1:16:34 PM MST Przemek Klosowski via devel
wrote:


This is weird---your swap was 100% full, and ram almost full, and yet
killing 4GB VirtualBox didn't seem to free up memory. I suspect some
sort of measurement or reporting error---if these numbers were accurate,
EarlyOOM did have a reason to panic and kill zoom. BTW, zoom taking 721
MiB is crazy.



Are you kidding? The system still had over a quarter of a gigabyte of free
RAM. There's no reason to start killing off processes at that point. That's
tons of free memory. To put that into perspective, that's enough free memory
to store over 1000 average-length novels directly in memory.


When the swap is 100% full, it is not like you have a bunch of processes 
neatly stored in it, and some free memory available---you have a mess of 
partly swapped out processes reading back their pages from swap and 
pushing other processes' RAM pages onto the fragmented swap, when they 
are trying to run.


This is the worst case of disk usage, and as we discussed before, the 
transfer speeds for such traffic will be hundreds/thousands times 
slower---I would expect latencies going into tens of seconds. So, no, I 
am not kidding.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: EXTERNAL: Re: hundred percent cpu load

[Przemek Klosowski via devel]

On 8/13/20 4:12 PM, Wells, Roger K. via devel wrote:

  I'll do something to disable it.


Oh, just thougth I'd mention---what I'd do would be

locate sadc <- hopefully this would return the location of the sadc 
binary, perhaps /var/lib64/sa/sadc


rpm -qf /var/lib64/sa/sadc  <- this will report which package is sadc a 
part of, perhaps sysstat


yum erase sysstat  <- deletes the offending package once and for all.
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: EXTERNAL: Re: hundred percent cpu load

[Przemek Klosowski via devel]

On 8/13/20 4:12 PM, Wells, Roger K. via devel wrote:

So sadc is not part of current Fedora. It may be some artifact from
older Fedoras (e.g. sysstat-11.5.7-4.fc27.x86_64 has
/usr/lib64/sa/sadc) or some custom system activity data collection
software that is locally installed at your site.

Thanks. I'll do something to disable it.  FWIW, this computer has never
run anything but Fedora since day1.


Did you install F32 from scratch, or was it an upgrade from earlier 
versions? If you had F27 on it, upgraded to 28->29->30->31->32, it would 
explain how sadc got on it.


Also, I have a Fedora box but my work installs third party management 
and monitoring software on it that is not part of official Fedora, so 
that would be another avenue for something called sadc to get on your 
Fedora box.


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: hundred percent cpu load

[Przemek Klosowski via devel]

On 8/13/20 2:04 PM, Wells, Roger K. via devel wrote:

After some time, usually hours, the following four tasks in top are
running at 100%:
sadc
kworker/6:1+events_freezable
dmesg
systemd-journal


So sadc is not part of current Fedora. It may be some artifact from 
older Fedoras (e.g. sysstat-11.5.7-4.fc27.x86_64 has /usr/lib64/sa/sadc) 
or some custom system activity data collection software that is locally 
installed at your site.


My guess is it goes bonkers and causes frantic kernel worker thread 
activity, and generates tons of messges, keeping dmesg and journal busy. 
Please look into that, and let us know what you find out.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: EarlyOOM +ZRAM Only

[Przemek Klosowski via devel]

On 8/12/20 2:27 PM, Sergio Belkin wrote:

Hi!
I 've just had a problem using EarlyOOM + ZRAM. I haven't a disk-based 
swap partition.
I was using mainly Zoom (desktop app) + Firefox + VirtualBox (Debian 
with 4GB of RAM), and EarlyOOM killed Zoom in the middle of a call :(


This is weird---your swap was 100% full, and ram almost full, and yet 
killing 4GB VirtualBox didn't seem to free up memory. I suspect some 
sort of measurement or reporting error---if these numbers were accurate, 
EarlyOOM did have a reason to panic and kill zoom. BTW, zoom taking 721 
MiB is crazy.


One possibility that comes to mind is that there's a process not 
mentioned in the log (some system process???) that keeps allocating 
memory as soon as it is freed by EarlyOOM, so killing the processes does 
not result in increasing free memory (the first column).


399 of 15887 MiB ( 2.51%) SIGTERM "Web Content": badness 315, VmRSS 313 MiB
397 of 15887 MiB ( 2.50%) SIGTERM "Web Content": badness 304, VmRSS 80 MiB
379 of 15887 MiB ( 2.39%) SIGTERM "Web Content": badness 303, VmRSS 74 MiB
335 of 15887 MiB ( 2.11%) SIGTERM "Web Content": badness 303, VmRSS 70 MiB
315 of 15887 MiB ( 1.98%) SIGTERM "Web Content": badness 301, VmRSS 27 MiB
288 of 15887 MiB ( 1.81%) SIGTERM "VirtualBoxVM":badness 212, VmRSS 4244 MiB
337 of 15887 MiB ( 2.13%) SIGTERM "zoom":    badness 36, VmRSS 721 MiB

Note how the full log helpfully mentions the actual tresholds for 
SIGTERM: mem 2.52%, swap 10%, Where does 2.52 come from, pray?

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: memory testing

[Przemek Klosowski via devel]

On 7/15/20 1:11 PM, Chris Murphy wrote:

Hi,

While bad RAM is uncommon, it comes up with some regularity to cause
folks a lot of grief. I'm wondering if there's a way to make it easier
to get bad news :-\ In particular there are cases where RAM defects
just don't show up with a few hours of memtest86+, it can take days of
contiguous testing, which is so inconvenient the test itself seems
worse.

Here's what I've got so far:

1. Fedora includes /boot/memtest86+-5.01 on every installation. But this is a 
legacy/BIOS program. [..]
2. The kernel has a built-in memory tester. [..]
3. "memory interface test" used at Google,[..]
4. "multiple concurrent kernel compiles"


There's also 5. memtester, http://pyropus.ca/software/memtester/ ,  
packaged in Fedora. It runs in userland, so obvously isn't as thorough 
but I'd think it has got to better than gcc and other userland 
utilities, because it tries the 'known-tricky' access patterns rather 
than hoping to see them in compiler output.


I remember the beginnings of memtest86+: its predecessor was written at 
the SGI hardware division by folks who understood how e.g specific 
access paterns appear on the physical traces on the memory modules, and 
can lead to crosstalk, but only if you simulataneously and repeatedly 
toggle very specific bits. This type of knowledge was essential to 
writing good tests, and probably also to discovering vulnerabilites like 
rowhammer.


Have you looked at memtester? What do you think of it?

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Przemek Klosowski via devel]

On 7/10/20 5:22 PM, John M. Harris Jr wrote:

Android, actually, is trying to get it right by a) being a platform so
that common security updates are available from the platform owner, and
can be applied to everyone's system and b) having a secure remote update
method.

The problem with implementing systems such as this is obvious.. If the end
user cannot upload their own firmware, because the host has a hardware
mechanism for checking the signature of the firmware, that's not good for the
end user, it's harmful. It would mean they don't actually own the system, the
vendor does.


Yes, but it it's too easy (and can be triggered remotely) it becomes a 
huge problem.


I also want to be able to load alternative firmware---but it has to be 
difficult, e.g. by requiring to disassemble the device and physically 
access the electronics.


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Przemek Klosowski via devel]

On 7/10/20 8:25 AM, Nicolas Mailhot wrote:

Le vendredi 10 juillet 2020 à 08:00 -0400, Przemek Klosowski a écrit :

Not quite---as I said in next sentence that you didn't include in
your quote, secure boot also tries to prevent unauthorized
modifications,

That does not work either, because if your system is remotely
exploitable, it will just be remotely exploited at every boot, and
there will be nothing stored persistently for secure boot to block
(that is actually how some windows malware started to behave once
Microsoft added boot protections).
Except that you can fix the vulnerability, push the update and prevent 
the exploit, even if the vulnerability would somehow be in the boot 
firmware. For the exploit to win it would have to hit the window just 
after the boot, which can be prevented.


The other usual argument is that digital keys are cheap and physical
buttons or locks expensive. Well digital keys are definitely not cheap
once you count all the work to keep digital protections up to date and
bug free, and physical buttons are definitely not expensive. I have one
on every bargain-bin iot plug in my house, to authorise initial
pairing. And those buttons will keep working far after the IOT
manufacturer will have screwed up the software update part.


The marginal cost of a digital key has got to be smaller than the 
marginal cost of the button. At billions of device, that's the only cost 
that matters.


Again, I am a hardware hacker and I hate the locked devices. But I think 
the secure updates have to happen, and it turns out that there is almost 
always a local bypass--JTAG, serial port, whatever. Maybe that is a 
regulatory issue---like a legal requirement that manufacturers need to 
publish a local unlock key/code after (or maybe even before) their 
support schedule ends.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Przemek Klosowski via devel]

On 7/10/20 7:37 AM, Nicolas Mailhot wrote:

Le vendredi 10 juillet 2020 à 07:12 -0400, Przemek Klosowski via devel
a écrit :

My point is that however the updates are being produced, they need a
secure remote update method. It's not realistic to expect end users
to be in the loop

If you remove end users from the loop there is zero zip nada need for
secure boot in the first place. The sole function of secure boot and
DRPM is to prevent end users, present in the update loop, from doing
things the manufacturer disagreees with.

A system, that auto consults a remote update point, over https,
checking the certificate of this remote point, has zero need for secure
boot.

Not quite---as I said in next sentence that you didn't include in your 
quote, secure boot also tries to prevent unauthorized modifications, for 
instance resulting from exploited vulnerabilities. It turns out that 
legitimate owners aren't the only users of IOT :)


Look---I agree this is a complex situation. Secure boot has many 
consequences, and I share your concerns about many of them (walled 
gardens and loss of control over hardware we own). This does not change 
the fact that the current technology is inadequate and needs to evolve.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Przemek Klosowski via devel]

On 7/9/20 2:24 PM, Eric Sandeen wrote:

<50 runs later on btrfs>

16 readonly mounts failed (32% failure rate)
Within the successful mounts, 1 or more files were unreachable in 30 attempts.
Across all 50 attempts, 7720 files were lost.

Is that better than ext4, and will ext4 need fsck just to be able to mount?

<50 runs later on ext4, same strategy>

zero mount failures for ext4.
Within the successful mounts, 1 or more files were unreachable in 2 attempts.
Across all 50 attempts, 48 files were lost.


But for that test to be meaningful, you need to check that the files 
that ext4 recovers are actually what you expect---after all, if the 
metadata is damaged and repaired incorrectly, it could point to some 
random blocks and we'd never know. This is not just theoretical 
concern---I have seen this type of damage in fsck'ed systems, although I 
admit it has been long ago. The type of damage might be tricky---for 
instance part of the file would be correct, but other parts would be 
wrong, or the file would be truncated.


Btrfs will just give up if it screws up. You could see it as good or 
bad---after all, if a disk holding your pictures went bad, maybe it is 
useful to see partially damaged pictures, rather than having the 
filesystem throw up its hands. On the other hand, btrfs being harsh like 
that basically sends the message to 'backup or else', which may be the 
right thing in the end.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Przemek Klosowski via devel]

On 7/10/20 5:06 AM, Nicolas Mailhot wrote:

The problem IOT side is not the security of the
software update chain. The problem is that manufacturers skimp on
software updates in the first place


Yes, that's the situation right now: everyone has a custom firmware tied 
to a short product cycle---so new versions and fixes have to be 
developed separately by everyone. This does not scale, and so it doesn't 
happen most of the time. I think the only long-term solution is a wide 
use of platforms, such as Android or Fedora.


My point is that however the updates are being produced, they need a 
secure remote update method. It's not realistic to expect end users to 
be in the loop---it doesn't scale to the size the IOT is going to be. 
Moreover, without the secure method, any vulnerability can be easily 
converted to persistent breakage.


Android, actually, is trying to get it right by a) being a platform so 
that common security updates are available from the platform owner, and 
can be applied to everyone's system and b) having a secure remote update 
method.


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Przemek Klosowski via devel]

On 7/9/20 10:46 AM, John M. Harris Jr wrote:

"Secure Boot" doesn't make root non-uid 0, and can't keep root from
controlling system devices, even uploading unsigned firmware to peripherals.


While it's true that a completely secure software chain doesn't really 
exist yet, we are slowly going in that direction, because it is just 
inconceivable otherwise in the world with billions of autonomous IOT 
devices---the consequences of a worm-type insecurity that would subvert 
a significant portion of Internet-connected devices are just too scary.


For instance, one possible solution used e.g. for a secure BIOS updates 
is to prevent loading firmware directly, and instead load it into a 
separate flash area. Then, reset the system:


 * existing certified firmware boots and finds the updated firmware
 * new firmware is measured and verified
 * if it passes, the old firmware copies and activates the updated firmware

So you see that you can't subvert this even with UID==0. Same thing for 
controlling system devices---with secure software chain even the 
applications can be certified and controlled. THis is not your or my 
desktop system, of course, but there is a need for systems like this.


When I hear you say that this takes away the ownership of our computers 
from us, I think that it's got to be this way for a large part of those 
billions of systems---as the saying goes, we have to stop thinking of 
computers as pets, and start seeing them as cattle. We can still have 
pets as well, but there has to be a way to herd cattle.


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[Przemek Klosowski via devel]

On 7/9/20 8:44 AM, Kevin Kofler wrote:

Przemek Klosowski via devel wrote:

   * disk access is literally O(1) slower than RAM access

This notation is meaningless. By the definition of the O notation,
O(1)=O(1)=O(k) for any constant k.


Yes, you are right of course, but I just hope that everyone understood 
that was just a shortcut for saying that the speed ratio is somewhere 
between 1e3 and 1e5

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[Przemek Klosowski via devel]

On 7/8/20 12:15 PM, John M. Harris Jr wrote:

I'd rather crash and restart where I left off than have
the computer drag me along trying to save my application.

Sorry, what? Why would your data not be on your system? What about "the modern
way of computing" would move your data from your system to something else? I'd
rather not see software crash, and risk data loss, or have my system "drag me
along".


I am talking about every process that has enough safeguards to be 
effectively idempotent, either because it doesn't use local data or 
saves it often enough to have a reliable, resumeable checkpoints. Here's 
a couple of examples:


 * browsing, because it both displays remote data and because it saves
   the state (tabs and whatnot)
 * make -j 30
 * even emacs editing, because emacs saves the buffers when it's killed

If the computer gets in trouble doing those things, I don't want it to 
do heroics trying to recoverit's OK to abort and retry. I think the 
'modern cloud computing' is, for many reasons, having to be like 
that---resilient to failures and idempotent.



Really, this is starting to sound like it's more of an issue with web
browsers, and less of a problem with our current configurations, without
EarlyOOM needlessly killing things.
[...]
Currently, pages that haven't been used in a while are the ones that would get
swapped out first, which I'm sure we can all agree is the most sane option.
Your GIMP example is accurate, but that'll take a fraction of a second.
Argumentative, Your Honor! It's not just an issue with web 
browsers---you say that yourself few lines further down, it happens with 
every program that uses big data---GIMP with lots of images, FreeCAD 
with a complex geometry, rmaxima with a combinatiorally exploding 
symbolic expression, even your editor where you read in the entire 
/var/log/httpd/access_log against your better judgement. Literally all 
those examples happened to me fairly recently---the system went 
unresponsive, essentially requiring hard reset, whereas the preferred 
outcome would have been to abort those runaway tasks.

One way to think about it is that disk is tens of thousands times slower
than RAM. If you need to use it, your system is commensurably slower.
That's why zram is such a good idea. Swap was always a tradeoff: you
saved $'s not spent on RAM, and paid with your time sitting idle waiting
for the computer.

Well, no. It's not "tens of thousands times slower than RAM". If you need to
use it, you're swapping in a few pages at a time, not the entire contents of
swap. Swap isn't a replacement for RAM. It's an optimization that doesn't
waste RAM needlessly.


I think we both understand what the other person is trying to say, to 
the point where no further explanations are needed. Having said that, 
I'd prefer if you would qualify and augment instead of denying my 
statements. I stand by both of them:


 * disk access is literally O(1) slower than RAM access
 * swap is a cheap substitute for RAM, with the right swap/RAM mix
   determined by cost-benefit considerations

You're right that there's a sweet spot where swap just provides a buffer 
for occasional peak demand---but this entire discussion results from 
complaints about system behavior under heavy swap use, when swap is 
being an inadequate replacement for the needed RAM.


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[Przemek Klosowski via devel]

On 7/6/20 6:49 PM, John M. Harris Jr wrote:

Unless you're actively using all of those tabs (I don't know how you would be,
but it's certainly possible), swap sounds like the perfect solution. Unless
Firefox keeps JS running in there, and it's updating the DOM, these would
likely be able to get swapped out.

Firefox will actually unload tabs that you haven't done anything with in a
while under specific circumstances, but I don't know what those are. You may
notice, for example, that the page "reloads" without network traffic, when
going to a tab you haven't had open in a while. I've seen this on my system
recently.
Take a look at the Task Manager. You will see tabs running even though 
you're not touching that: the pages have elements (ads, animations, etc) 
that run even though the tabs are not visible. True, the browser tries 
to pacify them (turns off sound/video, and whatnot) but they still 
run---and if the JS engine has memory leaks their memory footprint 
increases. You can see the culprits---sort them by "Energy Impact" or 
"Memory" by clicking on the column headers.



More swap doesn't necessarily solve this problem: remember that 1GB/min
is a ballpark HD speed so if you have 10GB swap  that your system is
actually trying to use, you will just sit there for 10 minutes.

I don't really understand how that'd be the case. For that to happen, you'd
have to load all of those into memory, have them swap out, then try to swap
them all back in at the same time.


That's my point---you don't have control over it. Swap algorithm decides 
which pages are evicted from RAM or brought back---if the browser starts 
allocating memory, my FreeCAD might get pushed out, and if I click on 
GIMP window after not using it for an hour it tries to bring it back in.


One way to think about it is that disk is tens of thousands times slower 
than RAM. If you need to use it, your system is commensurably slower. 
That's why zram is such a good idea. Swap was always a tradeoff: you 
saved $'s not spent on RAM, and paid with your time sitting idle waiting 
for the computer.


With the modern way of computing, where your data is mostly NOT on your 
system---so you don't lose it if your application shuts down---I am 
beginning to think that application crashes aren't such a big deal as 
they used to be. I'd rather crash and restart where I left off than have 
the computer drag me along trying to save my application.


Having said that, of course lots of applications ARE local and will lose 
data if crashed, so maybe the cgroup-based approach is the definitive 
solution: hard-limit the memory for cloud apps, to protect the local 
apps from resource exhaustion.


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Przemek Klosowski via devel]

On 7/2/20 4:38 PM, Eric Sandeen wrote:

Running 10 loops on each of btrfs, ext4, and xfs I got results that look
like this (ext4 always creates empty lost+found so it will always find at
least 1 file there)

btrfs
...
== 4 fsck failures, 2 mount failures

ext4
...
== 0 fsck failures, 0 mount failures

xfs
...
== 0 fsck failures, 0 mount failures


Did you check the content of the filesystem, to make sure that the files 
restored by fsck are actually correct?


I think  ext4/xfs may be showing 0 files lost but they may or may not 
contain the pre-damage content, while btrfs would just fess up that it 
lost them if the checksums didn't agree.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[Przemek Klosowski via devel]

On 7/4/20 8:18 PM, John M. Harris Jr wrote:

I've never managed to get one of my own Fedora machines to the point of
OOMing, and, when I have seen others do it, it's a problem that would have
been solved by having more swap space.


I am a tab hoarder so I used to wedge the browser due to memory leaks 
(some live ad pages would blow up into gigabytes of RAM). I think recent 
browser versions are more resistant to that---I haven't locked up in a 
while, although it may be because I also tend to have a Task Manager 
open, sorted by Memory size, and I kill pages that keep growing.


More swap doesn't necessarily solve this problem: remember that 1GB/min 
is a ballpark HD speed so if you have 10GB swap  that your system is 
actually trying to use, you will just sit there for 10 minutes.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Przemek Klosowski via devel]

On 7/1/20 3:50 PM, Josef Bacik wrote:
This sounds like a "wtf, why are you doing this btrfs?" sort of thing, 
but this is just the reality of using checksums.  It's a checksum, not 
ECC. 


Yes, exactly---why isn't it ECC? Wouldn't it work better, especially in 
the context of faulty hardware?


I do realize it would require changing the on-disk format, and maybe 
slow the critical path...

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Przemek Klosowski via devel]

On 6/29/20 7:59 AM, David Kaufmann wrote:

Unfortunately I think this arguing is moot, as the issue seems to have
been decided already anyway. I only remember one change "proposal" to
actually being pulled back in the last year, and I'm really disappointed
about having fake discussions on devel@ whilst the decision has already
been made. There are some where the Change proposal owner actually
considers other options which come up in the discussion, but for a few
of them there is not even an answer, and for some of them the only
Change proposal owner response is "but it is the best option".


I would like to  respectfully disagree---my recollection is that when 
there was a vigorous opposition, the proposals were changed/retracted. 
In this particular case, it feels to me that the responses are mostly in 
favor, so it may be that this proposal is going against your preference, 
but this is good--it's how the system is supposed to work.


I am always always impressed by the discussion's  high caliber and 
information content--I tend to learn a lot. My recollection is that 
proposals are being changed as a result.


I hope you can  see it in a different light--as an opportunity to 
improve, not as an imposition. I am certainly glad that those proposals 
are in our workflow---thanks Ben, and the proposal authors!


Very Respectfully

p.
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Przemek Klosowski via devel]

On 6/29/20 12:38 PM, Przemek Klosowski via devel wrote:

On 6/27/20 11:40 PM, Tom Seewald wrote:
On Sat, Jun 27, 2020 at 7:32 PM Garry T. Williams 



Just a PSA: btrfs raid1 does not have a concept of automatic degraded
mount in the face of a device failure. By default systemd will not
even attempt to mount it if devices are missing.
Is this hopefully seen by upstream as a bug that will be fixed? This 
removes the system availability benefits of raid, and I've never 
heard of another system that would behave like this, whether that's 
zfs, md, or hardware raid.


I agree that it's useful and common for data but booting from degraded 
RAID is not universally supported (I think it depends on the boot 
manager). Having said that, the flip side of it is that automatic 
degraded mount results in a non-redundant system, requiring manual 
intervention to restore proper redundancy, anyway.


Oh, and it occurred to me that people probably use raid for two slightly 
different reasons: data safety and availability. The first group may 
actually prefer (or at least not mind) having to fix the raid before 
proceeding.


The second group presumably needs not just automatic degraded mode, but 
a system that maintains hot spares and automatically deploys them.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Przemek Klosowski via devel]

On 6/27/20 11:40 PM, Tom Seewald wrote:

On Sat, Jun 27, 2020 at 7:32 PM Garry T. Williams 
Is this hopefully seen by upstream as a bug that will be fixed? This removes 
the system availability benefits of raid, and I've never heard of another 
system that would behave like this, whether that's zfs, md, or hardware raid.


I agree that it's useful and common for data but booting from degraded 
RAID is not universally supported (I think it depends on the boot 
manager). Having said that, the flip side of it is that automatic 
degraded mount results in a non-redundant system, requiring manual 
intervention to restore proper redundancy, anyway.


In other words, we still need a mechanism to notify and ensure that the 
raid is rebuilt---too much automation could lead people into false sense 
of security.


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Przemek Klosowski via devel]

On 6/27/20 12:50 PM, John M. Harris Jr wrote:

As an alternative, I would like to recommend we make Emacs the default. Emacs
does not require "specialist knowledge", but is much more powerful once you do
learn how to use it properly. It's also not as hard to use as nano.
I used emacs for 30+ years and have it in my muscle memory but even I 
don't use EDITOR=emacs because 1) startup takes seconds and 2) it leaves 
~ files around by default. Afer thinking about it I believe nano is 
better suited for quick edits.


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Przemek Klosowski via devel]

On 6/26/20 1:43 PM, Neal Gompa wrote:

One issue that I have
seen mentioned as an issue within the last week is still the problem of
running out of space when it still looks like there's space free.  I
didn't read the responses, so not sure of the resolution, but I remember
that being a "thing" with btrfs.  Is that still the case?  What are the
causes, and if so, how can we keep from getting a lot of the same
question on mailing lists/forums/etc.?


Josef gave a fairly detailed answer upthread:


In this reply, he does not specifically address the disk-full issue, but 
I seem to remember that it was resolved. I couldn't however find a 
reference---could someone authoritatively say something one way or another?


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Przemek Klosowski via devel]

On 6/26/20 12:31 PM, Chris Murphy wrote:

That pattern will change with btrfs. There will be fewer of some problems,
more of others, and the messages will be different. fsck.ext4 is
pretty much all we have, all we're used to, and it's a binary
pass/fail. Even though we're talking about edge cases at this level,
those who get unlucky for whatever reason are going to need a
community of user to user support giving them good advice. Will Fedora?


Well said. BTRFS is more complex and will require getting used to.

In case of FS trouble, everyone knows 'fsck' but as Josef wrote

    With btrfs you are just getting started.  You have several built in 
mount options for recovering different failures, all read only.  But you 
have to know that they are there and how to use them.


which is both encouraging and terrifying :)

I remember that two issues that made me apprehensive wrt. BTRFS were its 
handling of the 'disk full' situation, and lack of a staightforward 
'fsck' workflow. I think the first issue has been resolved, and we 
probably just need some docs and scripts that handle file system 
corruption by remounting R/O and printing some suggestions what to do next.




It's also important to talk about what's left on the table*without*
this change. The potential to almost transparently drop in a new file
system that extends the life of user's hardware, eliminates the free
space competition problem between /home and /, and allocates it more
efficiently.  And asks*less*  of day to day users, while inviting
*more*  from those who want to explore more features. On the same file
system.


For what it's worth, this is really needed, and overdue.  I have 
repeatedly failed Fedora OS release upgrades on different machines by 
running out of root fs space. I think the default / is around 50GB, and 
it's too easy to fill: during OS update we need space for three copies 
of each package: the old version, the downloaded new version, and the 
space to install the new version.


Even though technically dnf system-upgrade can --download-dir to a 
location off / it doesn't seem to work with the actual upgrade, so the 
only way I know is to delete largest packages (flightGear*, piglit*, 
KiCAD*, ...) and reinstall them after update.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Przemek Klosowski via devel]

On 6/26/20 10:33 AM, Neil Horman wrote:

If I google how to quit vi, I see a full 10 pages of the answer to the question
documented in detail


The fact that people have to google their way out of such a mundane 
circumstance is in my opinion enough to give this proposal a:


+1

As background, I am well familiar with vi and I rarely change the EDITOR 
to emacs, even though it's my own preference.


There are two  reasons:

 * vi starts instantly and emacs doesn't,

 * emacs leaves the *~ files around, and most contexts in which 'vi' is 
being used is simple enough that my knowledge of vi is sufficient and I 
don't need the backup files.


Nano comes out favorably in both cases, so even though I have never used 
it before I think it's a better choice than both vi and emacs.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: wireguard kmod package

[Przemek Klosowski via devel]

On 6/24/20 6:03 PM, Joe Doss wrote:

On 6/24/20 4:28 PM, Przemek Klosowski via devel wrote:

It was akmod-wireguard (thanks Laura, Alexander, Joe, Leigh and Ian).

This leaves the question: Shouldn't kernel>5.6.0 obsolete 
kmod-wireguard and akmod-wireguard? and maybe replace wireguard with 
wireguard-tools?


Looking at this RPM's change log it looks like they are doing that:

* Tue Apr 14 2020 Nicolas Chauvet  - 0.0.20191219-3
  - Disable wireguard until obsoleted

https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpkgs.rpmfusion.org%2Fcgit%2Ffree%2Fwireguard-kmod.git%2Fcommit%2F%3Fh%3Df31%26id%3D2c0a54bad7eed78c459a5f41ff1f4d71070e626cdata=02%7C01%7Cprzemek.klosowski%40nist.gov%7C72bf9d15a42c41a41ad508d8188a65d0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637286329984886856sdata=wYJ8LNnqzWUrMIR8cHqDsWICFBeYYnzY8PIJsXipNH0%3Dreserved=0 



I think that just prevents the installation of the module---I was 
puzzled why the module is getting created in the first place, and the 
answer was akmod-wireguard.


I argued that newer kernel installs should cause erasing of the 
wireguard-related packages, even though they came from a different 
repository (rpmfusion-free*).



___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: wireguard kmod package

[Przemek Klosowski via devel]

On 6/24/20 4:29 PM, Przemek Klosowski via devel wrote:
I noticed that kmod-wireguard is being updated on F31, even after 
WireGuard became a part of Linux kernel since 5.6.0. Shouldn't 
kernel>5.6.0 obsolete kmod-wireguard? Is it kept and updated because 
it was originally installed via @commandline?


We had a discussion about not removing any obsolete packages recently, 
but I can't think of any reason to keep kmod-wireguard---why is it 
even being updated for new kernel, given that wireguard.ko is in 
kernel-core now? 


It was akmod-wireguard (thanks Laura, Alexander, Joe, Leigh and Ian).

This leaves the question: Shouldn't kernel>5.6.0 obsolete kmod-wireguard 
and akmod-wireguard? and maybe replace wireguard with wireguard-tools?

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: wireguard kmod package

[Przemek Klosowski via devel]

On 6/24/20 4:35 PM, Laura Abbott wrote:



On 6/24/20 4:29 PM, Przemek Klosowski via devel wrote:
I noticed that kmod-wireguard is being updated on F31, even after 
WireGuard became a part of Linux kernel since 5.6.0. Shouldn't 
kernel>5.6.0 obsolete kmod-wireguard? Is it kept and updated because 
it was originally installed via @commandline?


We had a discussion about not removing any obsolete packages 
recently, but I can't think of any reason to keep 
kmod-wireguard---why is it even being updated for new kernel, given 
that wireguard.ko is in kernel-core now?




Can you point to the kmod-wireguard package? Kernel modules are not
allowed to be packaged separately from the kernel in official Fedora
repositories so if there's a kmod-wireguard package it must be from
either a COPR or a 3rd-party repo (unless something has really changed
in the last few months...)


So this is the dnf log from the latest kernel upgrade:

2020-06-18T19:51:13Z DEBUG ---> Package 
kmod-wireguard-5.6.15-200.fc31.x86_64.x86_64 0.0.20191219-3.fc31 will be 
erased
 kmod-wireguard-5.6.15-200.fc31.x86_64 x86_64 0.0.20191219-3.fc31 
@@commandline   325 k

kmod-wireguard-5.6.15-200.fc31.x86_64-0.0.20191219-3.fc31.x86_64
2020-06-18T19:53:50Z DDEBUG Command: dnf -y install --disablerepo=* 
/tmp/akmods.rRSdDv0E/results/kmod-wireguard-5.6.18-200.fc31.x86_64-0.0.20191219-3.fc31.x86_64.rpm 

2020-06-18T19:53:50Z DDEBUG Extra commands: ['-y', 'install', 
'--disablerepo=*', 
'/tmp/akmods.rRSdDv0E/results/kmod-wireguard-5.6.18-200.fc31.x86_64-0.0.20191219-3.fc31.x86_64.rpm']
2020-06-18T19:53:50Z DEBUG ---> Package 
kmod-wireguard-5.6.18-200.fc31.x86_64.x86_64 0.0.20191219-3.fc31 will be 
installed
 kmod-wireguard-5.6.18-200.fc31.x86_64   x86_64 0.0.20191219-3.fc31 
@commandline   97 k


so the repo it's coming from is @commandline, but I am not doing 
it---somehow akmods pulls it in?  my repolist is:


repo id repo name
code Visual Studio Code  (blush)
fedora Fedora 31 - x86_64
fedora-cisco-openh264 Fedora 31 openh264 (From Cisco) - x86_64
fedora-modular Fedora Modular 31 - x86_64
rpmfusion-free RPM Fusion for Fedora 31 - Free
rpmfusion-free-updates RPM Fusion for Fedora 31 - Free - Updates
rpmfusion-nonfree RPM Fusion for Fedora 31 - Nonfree
rpmfusion-nonfree-updates RPM Fusion for Fedora 31 - Nonfree - Updates
updates Fedora 31 - x86_64 - Updates
updates-modular Fedora Modular 31 - x86_64 - Updates
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RHEL 9 and modularity

[Przemek Klosowski via devel]

On 6/24/20 8:56 AM, Petr Pisar wrote:

On Wed, Jun 24, 2020 at 08:14:39AM -0400, Stephen Gallagher wrote:

On Wed, Jun 24, 2020 at 3:38 AM Petr Pisar  wrote:

On Wed, Jun 24, 2020 at 06:51:36AM +, Zbigniew Jędrzejewski-Szmek wrote:

Yes. Putting the "stream identification" into the package name is the
most natural solution, and has been floated various times.

This already happens. But not in Fedora. In RHEL, modular packages have
Modularitylabel RPM tag that carries the module name and stream.


The ModularityLabel RPM tag is also present in Fedora.

Interesting. I checked the first modular package for the first module "dnf
module list" gives in Fedora 33
(ant-0:1.10.5-3.module_f28+4207+d722d224.noarch), and it does not contain the
tag. I did not checked other ones. Thus I wrote that it was not in Fedora.

Now I see that the package was built on Fedora 28 platform. When I check the
latest build in Koji,  ant-1.10.7-2.module_f31+7074+f8e1675d.noarch, the tag
is there.

My apology. Probably the new tag was enabled sometime in between and nobody
cared to rebuild the module after that (although relengs mass-rebuild modules
on branching) and nobody cared to submit to latest build to stable.


FWIW,  other F31 packages with it are:

gimp gimp:2.10:3120191106095052:f636be4b
gimp-libs gimp:2.10:3120191106095052:f636be4b
ninja-build ninja:latest:3120190304180949:f636be4b


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

wireguard kmod package

[Przemek Klosowski via devel]

I noticed that kmod-wireguard is being updated on F31, even after WireGuard became 
a part of Linux kernel since 5.6.0. Shouldn't kernel>5.6.0 obsolete 
kmod-wireguard? Is it kept and updated because it was originally installed via 
@commandline?

We had a discussion about not removing any obsolete packages recently, but I 
can't think of any reason to keep kmod-wireguard---why is it even being updated 
for new kernel, given that wireguard.ko is in kernel-core now?

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Przemek Klosowski via devel]

On 6/24/20 5:51 AM, Vitaly Zaitsev via devel wrote:

On 24.06.2020 04:40, Przemek Klosowski via devel wrote:

Nice, thanks for finding this --- but it also lists all the 
debugsource/debuginfo packages

This is intended, because debug repositories are disabled by default and
these packages does not belongs to any repositories.

You can run `sudo dnf list extras --enablerepo=\*debug` to include them.


dnf list extras --enablerepo=\*debuginfo

Why did you sudo it? It seems to work from a regular account just fine.
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Przemek Klosowski via devel]

On 6/23/20 5:35 AM, Vitaly Zaitsev via devel wrote:

On 23.06.2020 10:39, Miroslav Suchý wrote:

A tool which will give user a list of packages that can/should be removed.

dnf -C list extras


Nice, thanks for finding this --- but it also lists all the 
debugsource/debuginfo packages, and for some reason kmod-wireguard







___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Przemek Klosowski via devel]

On 6/15/20 9:46 PM, Kevin Fenzi wrote:

On Mon, Jun 15, 2020 at 09:05:42PM -0400, Neal Gompa wrote:

So I'm confused here, does anyone know why the animated wallpapers
don't work in KDE Plasma or any other desktop? I personally love
animated wallpapers and I'd like to see this on my KDE Plasma desktop
too...

I think KDE does support some kind of live/dynamic wallpaper, but it's
done in a completely different way from the gnome implementation.
As far as I know there's no standard there.

Xfce has never supported live wallpapers, the code simply does not
exist.
IDK how exactly it works, but I see that for instance 
f31-backgrounds-animated  has  f31-backgrounds-kde  as a weak dependency.

___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Supporting hibernation in Workstation ed., draft 1

[Przemek Klosowski via devel]

On 6/4/20 1:36 AM, John M. Harris Jr wrote:

On Wednesday, June 3, 2020 9:05:22 PM MST Chris Murphy wrote:

UEFI Secure Boot doesn't prevent you from gaining access to firmware
setup. It can cause some options in firmware setup to become
unavailable, e.g. compatibility support modules for presenting a
legacy BIOS. I'm skeptical that pin shorts permit you to gain access
to such things - but if so, it's clearly a vulnerability that should
be reported.

This is by design. Generally, there's a marking on the silkscreen with
something like "PWD" or "PASSWD" to mark it.
I seem to remember reading that resetting the firmware away from secure 
modes also wipes the secure TPM storage, so that you effectively wipe 
the machine to factory-fresh state.


___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org