Re: LLVM Packaging Ideas for Fedora 41

[Simon Farnsworth via devel]

On Saturday 27 April 2024 05:34:29 BST Tom Stellard wrote:
> Hi,
> 
> * Build compat packages (e.g. llvm18) as early as possible.  When we package
> a new major release of llvm, we create a compat package so that packages
> that aren't compatible with the new version can still use the old version. 
> In the past, we've waited to introduce the compat packages until the new
> version of LLVM was ready (typically during the Beta Freeze).  However,
> this proved to be an issue this release for packages the were ready to
> switch to the compat packages early in the release cycle, but then had to
> wait for Beta freeze.
> 
> * Switch to python-style compat/main packages.  In order to make the
> packaging more consistent between the main package (e.g. llvm) and the
> compat package (e.g. llvm18), we would retire the un-versioned dist-git for
> llvm, and create a new versioned dist-git for each new release (e.g.
> llvm19, llvm20, llvm21 etc.).  We would then designate one of these as the
> 'main version', and that version would produce binary rpms that look like
> the current main package (i.e. llvm-libs instead of  llvm19-libs). 

As a variant on these two ideas, could the main package "Provides" the compat 
version that it'll become if it's kept around after the main package moves on?

In other words, llvm-libs for LLVM 21 also has a "Provides: llvm21-libs", so 
that as a consumer of LLVM, I can depend on llvm-libs (meaning I don't really 
care which version of LLVM, and I'd like the best you offer, or I can depend on 
llvm21-libs from day 1 if I know that I'm going to need time to move to LLVM 
22.

Then, if you do decide to offer llvm21-libs, you can do so with no-one being 
affected; if you're looking for data on affected packages, you can use dnf 
repoquery to tell you how many packages depend on llvm21-libs as opposed to 
llvm-libs.

> * Invert the order of compat/main packages.  Instead of having the compat
> package be the old version, and the main package be the new version, we
> would have the compat package be newer and the main package be older.  This
> would allow us to introduce a new version of llvm without impacting other
> packages that depend on the main version of LLVM. 

This, I dislike; the unversioned package should, IMO, be the latest supported 
by Fedora version, with older versions provided as compat packages where 
desirable.

> If anyone has any feedback on these ideas we'd like to hear it and are happy
> to discuss these more.
> 
> Thanks,
> Tom
> 
-- 
Simon

--
___
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: Switching XZ for ZSTD?

[Simon Farnsworth via devel]

On Thursday, 4 April 2024 17:20:25 BST Arnie T via devel wrote:
> Hello Stephen,
> 
> > How a decision to drop xz for some other compression library for software
> > would be a fairly slow process. First a person who is willing to do the
> > work would come up with a proposal on why it should be done and how it
> > could be done. They would be expected to also test to see how much
> > trouble this would be (aka find all the packages which use xz and could
> > be changed to another library, which ones couldn't and what the effects
> > would be.) Once that is done, they would make a general proposal to be
> > reviewed by whatever technical committee a distribution has (Fedora has
> > one whose acronym is FESCO, Debian has another or multiple others, etc).
> > This would be reviewed and if accepted it would go as a future release
> > work with a staged plan where some packages are moved in X release, some
> > in X+1, and some final plan for X+2 (or backed out completely for some
> > reason before then). There would be some amount of software which would
> > rely on xz no matter what because either the upstream has no interest in
> > changing or it is meant to use xz period. ...
> > Currently most groups are between 0 and 1. There are a lot of things which
> > need to be looked at before moving off can be looked at as a goal to make
> > sure we aren't making things worse.
> > 
> > I hope the above helps
> 
> Thanks, I understand more of your explanation of how it's done.
> 
> I don't know how much time was needed to decide for example an Arch Distro
> change
> 
> "Now using Zstandard instead of xz for package compression"
> https://archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-com
> pression/ OK, that's my mistake. I thought that moving to open source Linux
> OS Distro like Redhat-related Fedora would result big or important issues
> can be fixed more efficiently than at Microsoft.
> 
That is not a distro-wide change; that's changing one thing from `xz` to 
`zstd`.

Fedora made the same switch back in Fedora 31, and thus doesn't need to do 
anything about package compression right now.

The remaining things are a long tail of various bits and pieces that use `xz` 
for a variety of reasons, and where there needs to be a decision made; fwupd, 
for example, has switched, while the `xz` tool in the repo will probably never 
switch from `xz` to `zstd`.

> I guess I'm learning that even important or wise choices (not saying _this_​
> is) can't be done with taking a long time. Even if they are security
> related issues.
> 
> Thanks one more time for the nice explanation!
> 
> Cheers!
> 
> Arnie



--
___
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: Mounting USB Storage devices with "sync" option ?

[Simon Farnsworth via devel]

On Friday, 2 February 2024 21:47:00 GMT Dominique Martinet wrote:
> So I think Florian is correct in that barriers won't be issued on
> these disks, and if they internally have such a cache it'd probably be
> unsafe...
> 
> Now does the disk itself know that it's in such an enclosure and
> properly behaves as write through?
> I think we'd have a lot more corruptions on our hands if it was
> incorrect here, btrfs in particular is very sensitive to disks that
> lie with barriers but I'm not sure how much it's used on such drivers.
> 
As far as I can tell, having owned such an enclosure in the past, it doesn't 
tell the drive anything - it relies on the fact that SATA drives write back 
fairly aggressively when the command interface is idle, and thus the cache is 
fully written back to the medium when it's idle for a few seconds. If you go 
through the sequence "remove safely", then wait for UI confirmation, then 
unplug the USB port, it'll usually have written back the cache before you 
physically move your hands to the USB cable.

As these enclosures aren't particularly fast (for example, commands must 
complete in issue order, rather than being able to complete out of order as in 
TCQ/NCQ), I suspect most users of them don't use btrfs or xfs on them (I'd 
expect ext4 if Linux-only, FAT32, exFAT or NTFS if shared between OSes); 
they're basically intended to let you have a huge "thumb drive" for machine-
to-machine transfer, and they're fine in that use case.

On the other hand, turning on the "sync" mount option doesn't help with these 
enclosures; if anything, it'll make things worse by increasing the number of 
commands in flight which have to be handled before the drive switches to 
cleaning its cache.
-- 
Simon Farnsworth

--
___
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: Mounting USB Storage devices with "sync" option ?

[Simon Farnsworth via devel]

On Wednesday, 31 January 2024 06:43:00 GMT Abyss Ether via devel wrote:
> I created a simple PoC udev rule to mount USB Storage devices with the "sync
> option. Available here :
> https://github.com/larina3315/personal-stuff/blob/main/linux/10-usb-storage
> .rules 
> Currently, USB Storage devices are mounted without the "sync" option,
> causing their writes to be cached. This causes an issue, especially with
> GUI file managers like GNOME Files, where after a file copy operation, it
> would notify the user that the operation has been completed. If the user
> then tries to unmount the USB Storage device, they get notified that data
> is still being written to disk and that they should not remove the USB
> Storage device from their PC/Laptop/device. 
> This can take a more severe form if the user is using a CLI/GUI utility that
> DOES NOT inform the user that data is still being written, like the 'cp'
> CLI utility, the user might be misled into thinking that all writes have
> finished and plug the USB drive out, at which point data corruption due to
> unfinished writes occur.
 
> This is why, I think functionality should be included in Fedora Linux (or
> atleast in Fedora Workstation and other desktop spins) such that USB
> Storage devices are mounted with the "sync" options by default. --

Coming at the problem in a different direction; the kernel has options to limit 
how much data is in flight to any given device, but the Fedora system doesn't 
set these. See

https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-bdi

for documentation. As per the experiment documented below, if we set per-
device BDI options "sensibly" based on the device's performance, we'd be able 
to reduce the window of surprise for users, without forcing all writes to be 
unbuffered via the "sync" option; instead, we could reduce the buffer to under 
a 
second for removable devices, and thus ensure that the user isn't surprised by 
massive data loss when they remove a device.

As a nice side-effect, these changes would also speed up unmount operations 
from a GUI, since it limits the amount of dirty data to be written back before 
the unmount completes.

The experiment follows:

First, there's global settings:

[sfarnsworth@ USB]$ sysctl vm | grep dirty
sysctl: permission denied on key 'vm.mmap_rnd_bits'
sysctl: permission denied on key 'vm.mmap_rnd_compat_bits'
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 1500
vm.dirtytime_expire_seconds = 43200
sysctl: permission denied on key 'vm.stat_refresh'

This tells me that on my system, we use up to 10% of my total RAM (64 GiB) as 
buffering for writes without even accessing the device, and up to 20% as 
buffering before the kernel will force a process to wait while it writes data 
out to the device.

I just plugged a 4 GiB USB 2.0 stick into my machine, and I get the following 
values:

[sfarnsworth@ /sys/class/bdi/8:0]$ grep . *
max_bytes:7245996032
max_ratio:100
max_ratio_fine:100
min_bytes:0
min_ratio:0
min_ratio_fine:0
grep: power: Is a directory
read_ahead_kb:128
stable_pages_required:0
strict_limit:0

This tells the kernel that it can buffer up to 7 GiB of data (max_bytes), and 
it doesn't need to consider the per-device limit until it's exhausted a global 
dirty limit (strict_limit). The default kernel settings allow you to complete 
your write immediately if you've used not more than 10% of the total buffer.

If I tell dd to write a gigabyte to the device with the dsync flag set to 
ensure that it writes data to the device before returning (although not 
metadata), I can see that the kernel is permitted to buffer a huge amount of 
data in terms of time taken to write everything out:

[sfarnsworth@ USB]$ dd if=/dev/zero of=test bs=$((1024 * 1024)) count=1024 
oflag=dsync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 174.692 s, 6.1 MB/s

I change the mount options to remove "flush", since this is a FAT32 stick, and 
the "flush" option causes the kernel to block on file close until the data is 
fully written:

[sfarnsworth@USB]$ dd if=/dev/zero bs=$((1024 * 1024)) count=1024 of=test
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.664286 s, 1.6 GB/s

This means we've buffered (quite happily) 3 minutes worth of writeback, which 
I'd have to wait for before removing the stick - but dd has already exited, so 
it's not "obvious" to me that I need to wait a long time.

I now change the per-device BDI options for the USB stick, based on what I've 
found out above:

[root@ 8:0]# echo $((10 * 1024 * 1024)) > max_bytes
[root@ 8:0]# echo 1 > strict_limit 
[root@8:0]# pwd && grep . *
/sys/devices/virtual/bdi/8:0
max_bytes:10475956
max_ratio:0
max_ratio_fine:1485
min_bytes:0
min_ratio:0
min_ratio_fine:0
grep: power: Is a directory
read_ahead_kb:128
stable_pages_required:0
strict_limit:1
grep: 

Re: Adding Passim as a Fedora 40 feature?

[Simon Farnsworth via devel]

On Monday, 28 August 2023 22:07:50 BST Richard Hughes wrote:
> On Mon, 28 Aug 2023 at 21:50, Simo Sorce  wrote:
> 
> > It could be improved by using TOFU, so that the window of impersonation
> > is small, but requires clients to cache an association and then has
> > weird failure modes to be dealt with if one of the actors get re-imaged
> > or changes the cert for any reason.
> 
> 
> I was thinking of implementing TOFU; good idea or bad idea?
> 
> Richard.

What identity do you attach the "first use" to, and how do you discover that 
the identify is expected to have a certificate change?

In the SSH use case, the identity is the host name, and if the host name is 
expected to rekey, then the user is told that there's an issue and has to 
manually intervene.

With this use case, I can't see how I tell you that there's been an expected 
rekeying event - nor am I clear on how I'd work out that a change of key is 
expected so that I can tell you to permit a rekey.
-- 
Simon Farnsworth

___
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: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]

[Simon Farnsworth via devel]

On Wednesday, 30 November 2022 17:47:16 GMT Fabio Valentini wrote:
> On Wed, Nov 30, 2022 at 6:21 PM Daniel Alley  wrote:
> > I feel like there is insufficient recognition of the extent to which C
> > libraries do "bundling".  Not "bundling" in the sense of vendoring a
> > whole library, but in the sense of including one-off implementations of
> > basic data structures, configuration parsers, hashing algorithms, etc.  I
> > would love to hear anyone argue that 100 different variations of
> > "sha256.c" across 100 different packages better follows the spirit of the
> > "no bundling" guidelines than a vendored crate named "sha256" with 100x
> > as many eyes on it, and a higher likelihood to actually be updated if a
> > problem is found.
>
> >
> >
> > Many of the tiny, "sprawling" Rust dependencies are like this - not all of
> > them of course, but many.
> 
> But ... none of these "tiny" Rust crates are dynamically linked in
> Fedora anyway - because Rust doesn't really support that?
> So I fail to see your point there, unless you meant to say "C projects
> don't 'bundle', they just often 'copy' some code into their projects"?
> 
I think the point he's making is that developers don't write common 
functionality from scratch, in general. We reuse code from elsewhere.

It's just that in C, I'll copy-and-paste code from the web into my library or 
application, not necessarily even bothering with a full "vendoring", whereas 
in Rust, I'll use the crc crate (say), or the base64 crate, or other simple 
utility crate.

The result is that I have N implementations of common functionality, each with 
its own unique quirks and security risks, in my C binaries; but my C binaries 
have only a small number of dependencies.

In Rust, however, I'm directly reusing the small utility crate, and while I 
may use `cargo vendor` to import the crate's source into my tree, I'm unlikely 
to edit it. The result is that a Rust binary has a larger number of 
dependencies than the equivalent C program, because I'm depending on a crate 
instead of copy-and-pasting the code and "hiding" it from the packager.

This is a challenge for Fedora: how do we cope with a world where instead of 
having a few tens of dependencies, and a lot of copy-and-paste code, we have 
hundreds of dependencies, but no copy-and-paste code?

One answer is to say that Rust is bad for encouraging developers to depend on 
small crates instead of copying-and-pasting  "small" utilities around. Another 
(which you're doing a great job of) is to package up all the dependencies,  so 
that we represent the true dependency tree in RPM. Yet another would be to 
manually decide which dependencies get bundled, and which don't - doing the 
same thing as the C world does to keep its dependency count down.

-- 
Simon Farnsworth

___
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 kTLS issue with TLS-PSK, GnuTLS + Rawhide - how to debug it?

[Simon Farnsworth via devel]

On Friday, 25 November 2022 13:57:26 GMT Richard W.M. Jones wrote:
> Turns out this is fixed in upstream gnutls (not the version in
> Rawhide).  The commit which fixes it is:
> 
> commit 67843b3a8e28e4c74296caea2d1019065c87afb3
> Author: Frantisek Krenzelok 
> Date:   Mon Sep 5 13:05:17 2022 +0200
> 
> KTLS: fallback to default
> 
> If an error occurs during setting of keys either initial or key update
> then fallback to default mode of operation (disable ktls) and let the
> user know
> 
> Signed-off-by: Frantisek Krenzelok 
> 
>  lib/handshake.c|  7 ++-
>  lib/tls13/key_update.c | 23 +++
>  2 files changed, 25 insertions(+), 5 deletions(-)
> 
> With full debugging you can see the message caused by this commit:
> 
> nbdkit: null[1]: debug: gnutls: 4: HSK[0x7fc9e00010a0]: TLS 1.3 set read key
> with cipher suite: GNUTLS_CHACHA20_POLY1305_SHA256
 nbdkit: null[1]: debug:
> gnutls: 13: BUF[HSK]: Emptied buffer
> nbdkit: null[1]: debug: gnutls: 13: BUF[HSK]: Emptied buffer
> nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: Start of epoch
> cleanup
 nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: Epoch #0
> freed nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: Epoch #1
> freed nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: End of epoch
> cleanup nbdkit: null[1]: debug: gnutls: 1: disabling KTLS: failed to set
> keys 
> Is this because kTLS doesn't support PSK?
> 
kTLS doesn't do key management, so it doesn't know the difference between PSK 
and X.509 (it gets the symmetric keys from userspace after the key exchange is 
done).

However, looking at https://gitlab.com/gnutls/gnutls/-/blob/master/lib/system/
ktls.c, GnuTLS only supports using kTLS with GNUTLS_CIPHER_AES_128_GCM and 
GNUTLS_CIPHER_AES_256_GCM cipher suites, while your debugging output shows 
that this connection is using GNUTLS_CHACHA20_POLY1305_SHA256.

As a result, the upstream fix you point to does the right thing because you 
can't use GnuTLS's kTLS support on this connection (at all), and the only 
thing that makes sense is to disable kTLS.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/
include/uapi/linux/tls.h suggests that kTLS has some degree of support for 
ciphers other than the two GnuTLS enables it for, but I don't know enough 
about TLS to know whether enabling all the ciphers current kernels support in 
GnuTLS would enable it to be used for this connection.

-- 
Simon Farnsworth

___
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: Building two conflicting binaries from the same source

[Simon Farnsworth via devel]

On Tuesday, 8 November 2022 09:43:40 GMT Richard W.M. Jones wrote:
> On Fri, Nov 04, 2022 at 01:44:41PM +0100, Petr Menšík wrote:
> 
> > If there are binaries with different build results, I think some
> > code should be refactored out of the binary itself. The common parts
> > can remain, but hardware specific parts should be moved to
> > dynamically loaded *.so files. The correct files should be loaded
> > depending on hardware found on the system. If auto-detection is
> > wrong, manual configuration via configuration file should be used
> > instead.
> 
> 
> I think this is right.  In particular you cannot assume that "the
> hardware" is a thing which remains stable for the lifetime of a Fedora
> install.
> 
> Sure, if you install Fedora on your laptop then the hardware is
> unlikely to change.  But if you install Fedora on a VM then it can be
> moved and booted on a VM with different (virtual) hardware.  And
> there's also the template case where someone prepares a disk image on
> one set of hardware (maybe virtual or physical) and then the disk
> image is used as a template to clone multiple systems from.
> 
> Having autodetection at run time deals with this, having different
> hardware-specific RPMs installed does not.
> 
> Rich.
> 
Even on a laptop or desktop, hardware may change underneath you. For example, 
early Intel Alder Lake CPUs would expose AVX-512 in CPUID if you turned off all 
the Efficiency cores, and just left the Performance cores; a later microcode 
update stopped this working, and force-disabled AVX-512.

There's also been efforts to bring mainframe-style "upgradeable silicon" down 
to the consumer market, like the Intel Upgrade Service[0]. For laptops, this 
has great appeal to manufacturers - you can build a bunch of machines with a 
soldered down Celeron CPU, and upgrade them to Core i3/i5/i7 during pre-sale 
provisioning, allowing you to reduce your stock needs. Once you can do that, 
why not also sell the upgrade keys to people who bought the cheap Celeron, 
making a profit on up-selling them to the i7 later?

[0] https://en.wikipedia.org/wiki/Intel_Upgrade_Service
-- 
Simon Farnsworth

___
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: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Simon Farnsworth via devel]

> On 29 Sep 2022, at 21:37, drago01  wrote:
> 
> 
> 
> On Wednesday, September 28, 2022, Clemens Lang  > wrote:
> Hi,
> 
> Michael J Gruber mailto:m...@fedoraproject.org>> 
> wrote:
> 
> Understanding is helped greatly by communication, though. Legal answers
> such as "We can not" do not further this understanding, and "We can not
> and we can not tell you why" is not much better, but these are the typical
> answer we get, not even with a "sorry, but we can't". Obviously, these
> legal questions are difficult to explain, but it can't be true that each
> such case is under a "gag order”.
> 
> A lawyer at a previous employer told me that explanations of such decisions
> can be used against you in court. Presumably, this also applies here.
> 
> That's sounds overlay paranoid. How can an explanation on why you are *not* 
> doing something be used against you in court? I can get why "we don't think 
> that patent XYZ applies so this is fine to ship" is problematic, but the 
> other way around just doesn't make sense. 

It’s related to additional damages for wilful infringement; if I say “I will 
not ship foo because I cannot get a suitable licence for patent US abc123455”, 
and the owner of that patent then claims I infringe because I ship bar, which 
they claim infringes patent US abc123455, they can also claim that my 
infringement of patent US abc123455 by shipping bar was wilful, because I 
clearly knew of the patent, I had analysed it to determine what it might apply 
to, and I’d decided to ship *bar* anyway, even though I knew or should 
reasonably have known (based on my analysis of why I couldn’t ship foo) that 
bar would put me into infringement.

Unfortunately, this is the flip side of well-meant legislation around wilful 
infringement - it’s simplest for a big US entity like Red Hat to simply say 
“no, and we’re not telling you why” to packages, because then there’s nothing 
to build a claim of wilful infringement around.
— 
Simon Farnsworth___
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: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Simon Farnsworth via devel]

> On 29 Sep 2022, at 12:52, Tommy Nguyen  wrote:
> 
> 
> 
>> On Sep 29, 2022, at 7:36 AM, Kevin Kofler via devel 
>>  wrote:
>> 
>> Neal Gompa wrote:
>>> Unfortunately, we have to be very careful to not provide a complete
>>> codepath to these codecs to avoid legal risks.
>> 
>> Considering that we have been shipping these hardware codec interfaces for 
>> years without any legal trouble, I find this absolutely ridiculous.
>> 
>>   Kevin Kofler
>> ___
>> 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
> 
> Lack of legal action is not evidence of no further legal action. There are 
> multiple possible explanations:
> 
> - they see no point because going after distros would waste time and money 
> and bring bad PR
> - going after Redhat who would assume liability is a different story as 
> they’re a Fortune 500 company
> - they or some other company (through merger or acquisition) may suddenly 
> decide to patent troll
> 
For a really nasty explanation:

- Red Hat would fight back, so they’re only going after downstream distributors 
who won’t fight back, and as part of settling, you sign an NDA so that upstream 
Fedora (us!) never finds out that downstream distributors are being shaken down 
for money.

This would imply that there’s been lots of legal trouble, we’ve just never 
heard of it.
— 
Simon Farnsworth
___
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: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Simon Farnsworth via devel]

> On 28 Sep 2022, at 19:40, Neal Gompa  wrote:
> 
> On Wed, Sep 28, 2022 at 7:48 PM Simon Farnsworth via devel
> mailto:devel@lists.fedoraproject.org>> wrote:
>> 
>>> On 28 Sep 2022, at 14:27, Neal Gompa  wrote:
>>> 
>>> On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher  wrote:
>>>> 
>>>> On 9/28/22 03:50, Tommy Nguyen wrote:
>>>>> This change will only affect AMD, as the intel non-free drivers do not
>>>>> depend on the changes. It is also unclear how this would affect nvidia.
>>>>> There is barely any hardware video acceleration support for nouveau
>>>>> anyway, for which you would install the proprietary driver. Further, as
>>>>> NVIDIA does not expose a vaapi interface, you need to install third
>>>>> party packages to get it to work with Firefox. So AFAICT this will
>>>>> primarily (if not only) affect AMD users.
>>>> 
>>>> So only everybody who specifically purchased a discrete GPU that works
>>>> "out of the box" with Fedora?
>>> 
>>> Well, we don't ship any userspace software that provides the necessary
>>> support code to use those codecs anyway.
>>> 
>> Firefox was able to use VA-API on Intel (at least - I don’t have Radeon 
>> hardware to hand) to accelerate H.264 decode.
>> 
> 
> Intel doesn't use Gallium (Mesa) for VA-API. You need a separate
> driver package for it, which we currently don't ship and the version
> being reviewed will not have these codecs enabled.
> 
To be clear - I wasn’t saying that Intel used Mesa for VA-API; I was saying 
that with Mesa drivers and Radeon hardware, I would expect Firefox’s VA-API 
support to work as well as it does for Intel, but I have not been able to test 
this.

>> And we ship gstreamer1-vaapi which lets any GStreamer using application 
>> (Totem, for example) use hardware acceleration.
> 
> Hmm, I forgot about that. FFmpeg doesn't have it because ffmpeg does
> stupid things when the codec is available but doesn't work. GStreamer
> is probably more intelligent about failing over.
> 
GStreamer elements run code to determine what codecs are supported - the VA-API 
elements use this to avoid claiming to support a codec unless it will work.

I’m not familiar with the current state of FFmpeg - in the dim and distant 
past, it relied on data tables to determine what codecs a given plugin 
supported, rather than running code (hence the VA-API plugins can’t claim no 
codec support when VA-API is unavailable).

— 
Simon Farnsworth___
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: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Simon Farnsworth via devel]

> On 28 Sep 2022, at 14:27, Neal Gompa  wrote:
> 
> On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher  wrote:
>> 
>> On 9/28/22 03:50, Tommy Nguyen wrote:
>>> This change will only affect AMD, as the intel non-free drivers do not
>>> depend on the changes. It is also unclear how this would affect nvidia.
>>> There is barely any hardware video acceleration support for nouveau
>>> anyway, for which you would install the proprietary driver. Further, as
>>> NVIDIA does not expose a vaapi interface, you need to install third
>>> party packages to get it to work with Firefox. So AFAICT this will
>>> primarily (if not only) affect AMD users.
>> 
>> So only everybody who specifically purchased a discrete GPU that works
>> "out of the box" with Fedora?
> 
> Well, we don't ship any userspace software that provides the necessary
> support code to use those codecs anyway.
> 
Firefox was able to use VA-API on Intel (at least - I don’t have Radeon 
hardware to hand) to accelerate H.264 decode.

And we ship gstreamer1-vaapi which lets any GStreamer using application (Totem, 
for example) use hardware acceleration.

— 
Simon Farnsworth
___
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: Suggestion: Use a unified kernel image by default in the future.

[Simon Farnsworth via devel]

On Thursday, 7 July 2022 19:37:16 BST Sharpened Blade via devel wrote:
> If it is really compromised, then you have to assume anything the vm sends
> you is fake. As far as the owner of guest knows, there could not even a a
> real vm, only a ssh shell that looks like it.
 
> In a real situation, the guest owner would send the host owner a "starting
> disk" or ISO. Then the host would tell the trusted cpu to boot a iso that
> sends the signature to the host, and also boot a modified iso in a normal
> hypervisor, and emulate the trusted part of the cpu. When the normal
> hypervisor vm wants the signature, the signature of vm1 is returned. The
> system in the normal hypervisor could also just lie to any connections
> outside the host system, so even if it knows its backdoored, it still test
> the guest owner its not.

This is a solved problem, and you need to read up on how remote attestation 
works in the presence of an attacker to understand fully how it's solved.

The core to the trick is that the CPU prevents the hypervisor from seeing into 
the state that belongs to the guest (measurements, memory content etc), unless 
the guest explicitly tells the CPU to share that memory. It does this using 
cryptographic primitives so that even an attacker who can monitor the DRAM bus 
externally to the CPU cannot see into guest state.

You can thus use key exchange protocols designed to work over a public channel 
(Diffie-Hellman for a simple example) to set up an encrypted channel between 
the 
guest and the remote system such that the hypervisor can only deny service - 
it cannot see into the channel, and thus cannot lie to the guest or its remote 
attestation service.

The same techniques are used in TLS to set up a secure channel between a 
service provider like https://start.fedoraproject.org/ and a user like my 
Fedora laptop

-- 
Simon Farnsworth

___
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: Suggestion: Use a unified kernel image by default in the future.

[Simon Farnsworth via devel]

On Tuesday, 5 July 2022 17:26:40 BST Sharpened Blade via devel wrote:
> How can you know if this interface is not emulated, and you never talk to
> the real cpu

The TDX white papers address how this is meant to work - it's based around the 
same "measurement" concept as TPM measured boot (see https://bootlin.com/blog/
measured-boot-with-a-tpm-2-0-in-u-boot/ for an explanation).

While the VM itself cannot avoid being compromised by the hoster, if you 
emulate the TDX interface, you'll not be able to send the "correct" 
measurements with an Intel signature - the measurements that can be sent have 
either the wrong hash, or the wrong signature (similar applies to AMD's 
version, but with an AMD signature).

In turn, this means that you reduce your trust chain down to the CPU maker, 
because if the VM platform tampers with TDX trust chains, you can observe this 
and refuse to (e.g.) send the VM platform the encryption key it needs to 
unlock private data.

-- 
Simon Farnsworth

___
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: Fedora 37: Add kernel parameters that help prevent local exploits

[Simon Farnsworth via devel]

On Saturday, 21 May 2022 19:31:59 BST Glorious Hellosway via devel wrote:
> For `slab_nomerge`, it can lead to very slight increase of kernel memory.
> `init_on_alloc=1` has a almost no performance impact, it is under 1% and is
> usually within standard error, but there is bug with zfs that can make zfs
> slower. `init_on_free=1` can be measured and is around 7-20% under certain
> workloads, but in some workloads it does not impact performance.
> `randomize_kstack_offset=on` can sometimes increase performance by 1%, or
> decrease it by 1%, but Redis has been noticed to have performance reduced
> by 2%. `pti=on` mitigates meltdown, but has a very big performance impact.

That doesn't answer my core question: why aren't these the defaults in the 
upstream kernel, with the command line options there for turning them off if 
they impact you?

-- 
Simon Farnsworth

___
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: Fedora 37: Add kernel parameters that help prevent local exploits

[Simon Farnsworth via devel]

On Thursday, 19 May 2022 04:15:16 BST Hellosway Here via devel wrote:
> Add `slab_nomerge init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1 pti=on
> randomize_kstack_offset=on vsyscall=none ` as default kernel command line
> arguments. This can help prevent local exploits by making it harder to
> exploit the kernel. I do not think there will be any breakage, I have been
> using these for a long time. The performance impact is minimal, a few of
> these can improve performance. 

A question, then: if these options are helpful to performance and/or security, 
why are they not yet the kernel's  defaults?

If there are tradeoffs that mean that these aren't suitable for general use, 
then Fedora needs to know what those tradeoffs are before it can make the 
decision, while if they're a simple net improvement, then upstream kernel 
developers should be happy to switch the defaults over without requiring a 
kernel argument.

> This can help increase the security of Fedora, while also not causing any
> other problems. Many users do not know what kernel command line arguments
> are, so doing this will help them with the security of their system. This
> does not address every problem, or even most of them, but every little bit
> matters.

If that's the case, why doesn't the upstream kernel switch them over? Is there 
an ABI break caused by some of these? A major performance regression on some 
workloads (if so, which workloads and does Fedora care)? Known bugs that 
upstream hasn't tracked down yet?
-- 
Simon Farnsworth

___
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 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Simon Farnsworth via devel]

On Wednesday, 18 May 2022 15:41:17 BST Vitaly Zaitsev via devel wrote:
> On 18/05/2022 13:47, Dominik 'Rathann' Mierzejewski wrote:
> 
> > Then call it "incorrect". Saying it's a lie implies intent to mislead,
> > while there obviously was none.
> 
> 
> Saying "lie" means "not true".
> 
In English, "lie" means "a statement made by someone knowing it is not true". 
It carries with it the idea that the person making the false statement knew it 
was false, but claimed it was true anyway.

"Incorrect" or "not true" do not carry the implication that the person making 
the statement knew it was false.

-- 
Simon Farnsworth

___
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: DIGLIM (System-Wide Change proposal)

[Simon Farnsworth via devel]

On Sunday, 26 December 2021 11:25:21 GMT Roberto Sassu via devel wrote:
> > From: Dan Čermák [mailto:dan.cer...@cgc-instruments.com]
> > Sent: Sunday, December 26, 2021 7:10 AM
> > Ben Cotton  writes:
> > 
> > *snip*
> > > == Upgrade/compatibility impact ==
> > > The user should ensure that software (not updated) from the old
> > > distribution is packaged and the package header is signed, or he
> > > should create and sign a custom digest list for the software he wishes
> > > to use after the upgrade.
> > 
> > 
> > Uhm, so locally/manually installed software (i.e. not signed by Fedora's
> > signkeys) will silently break when switching to F36? How about 3rd party
> > repositories?
> 
> 
> This is the main point of the feature. It aims to protect the user
> against untracked software spread in the disk, and to make him
> accept the software he wants to run.
> 
> Most likely, initially this process will be manual (there is a tool
> to generate a custom digest list). In the future, DIGLIM can
> be extended (in user space) to recognize the integrity information
> provided by the software developer.
> 
A concrete case:

I use Fedora, a third-party repository, and a private repository for my 
systems. The private repository is unsigned - it's just created via 
createrepo, and contains RPMs I've built with mock locally.

What do I need to do if this feature is accepted, in order to not see any 
impact? If I need to change any of the repositories I use and trust, can you 
point me to step-by-step instructions I need to follow?

-- 
Simon

___
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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[Simon Farnsworth]

> On 20 Jul 2020, at 15:40, Stephen John Smoogen  wrote:
> 
> On Mon, 20 Jul 2020 at 05:04, Kevin Kofler  > wrote:
>> 
>> John M. Harris Jr wrote:
>>> Userspace isn't dead when a system is thrashing. Your software is still
>>> running. If it gets killed, you're most likely going to lose your data.
>> 
>> The thing is, there are various levels of thrashing. In some cases, the
>> system is so busy that you have no chance to bring it back to responsiveness
>> for many minutes, up to hours. (Other than hitting the Reset or Power
>> button, of course.) I have had cases where not even sshd would respond. (The
>> fact that login has been blocking on D-Bus since the introduction of
>> systemd-logind does not help either. Login timeouts are something that was
>> just never happening in the past, now they are common under heavy load.)
>> 
>> That said, I do not see how the EarlyOOM heuristic, which allows, depending
>> on the exact settings, something like 80-90% of swap to be used IN ADDITION
>> to 90+% RAM (and will only start doing anything if BOTH RAM and swap are
>> full) can prevent thrashing in any reliable way. My thrashing scenarios have
>> had much less swap than that used. (I have twice as much swap than RAM, so
>> when the EarlyOOM heuristics trigger, my programs are already trying to use
>> almost 3 times as much RAM as is actually available!)
>> 
> 
> I think the problem is that you are using way too much swap for modern
> systems. The reasons for swap being 2x to 4x real memory was a 1980's
> solution when big RAM systems had 64 MB of ram but a server might need
> 128MB for certain tasks. This was 'reasonable' because the processors
> were slow but could still walk through 128 MB of space 'pretty' fast.
> As RAM got larger this 2x became 'cargo-culted' in various
> documentation and was still reasonable while processor speed went up.
> You could still have a system with 512MB of ram and walk through 1024
> to 2048 GB of swap in similar times as the 128 MB.

Also affected by the way some UNIXes handled commit and fork (the things Linux 
heuristic overcommit was designed to avoid needing excess swap for). In the 
best case, you needed as much swap as RAM, so that a full size process (64 MB 
in your 1980s system) could allocate an extra 64 MB to fork; in the worst case, 
things were using that swap and you needed some multiple just for commit 
accounting.

IIRC, there were also some systems where the available space for committing was 
set to the size of swap - hence the need for 2x RAM. One for matching your RAM 
and allowing you to use it, one for the space consumed during a fork.

Linux's use of overcommit means that this isn't an issue for Fedora, though.
-- 
Simon___
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: Many packages unnecessarily link to libpython

[Simon Farnsworth]

> On 17 May 2020, at 14:48, Simon Farnsworth  wrote:
> 
>> On 15 May 2020, at 19:12, Charalampos Stratakis  wrote:
>> 
>> Hello everyone,
>> 
>> As of Python 3.8, python C extensions modules should not link to libpython, 
>> unless they embed the interpreter in their code. Relevant upstream PR: 
>> https://github.com/python/cpython/pull/12946
>> If your package links to libpython without requiring it, it won't be 
>> possible to use the python3-debug binary with your python C extension, 
>> unless you recompile the extension against it.
>> 
>> On Fedora Rawhide, there are at this point 144 packages linking to 
>> libpython, many of those possibly without any need for it.
>> 
> 
>> python-gstreamer1farnz wtaymans
> 
> python-gstreamer1 links to libpython for writing GStreamer plugins in Python, 
> embedded in a C application.
> 
> I'll need to dig deeper to confirm that only the code for writing plugins in 
> Python is actually linked to libpython, not the code for using GStreamer from 
> Python.

And checked - the code to use GStreamer from Python is not linked to libpython, 
only the code to use Python instead of C to write GStreamer plugins.

> 
>> -- 
>> Regards,
>> 
>> Charalampos Stratakis
>> Software Engineer
>> Python Maintenance Team, Red Hat
> ___
> 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
___
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: Many packages unnecessarily link to libpython

[Simon Farnsworth]

> On 15 May 2020, at 19:12, Charalampos Stratakis  wrote:
> 
> Hello everyone,
> 
> As of Python 3.8, python C extensions modules should not link to libpython, 
> unless they embed the interpreter in their code. Relevant upstream PR: 
> https://github.com/python/cpython/pull/12946
> If your package links to libpython without requiring it, it won't be possible 
> to use the python3-debug binary with your python C extension, unless you 
> recompile the extension against it.
> 
> On Fedora Rawhide, there are at this point 144 packages linking to libpython, 
> many of those possibly without any need for it.
> 

> python-gstreamer1farnz wtaymans

python-gstreamer1 links to libpython for writing GStreamer plugins in Python, 
embedded in a C application.

I'll need to dig deeper to confirm that only the code for writing plugins in 
Python is actually linked to libpython, not the code for using GStreamer from 
Python.

> -- 
> Regards,
> 
> Charalampos Stratakis
> Software Engineer
> Python Maintenance Team, Red Hat
___
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 31 System-Wide Change proposal (late): No i686 Repositories

[Simon Farnsworth]

> On 11 Sep 2019, at 21:03, vvs vvs  wrote:
> 
> Yes, that's understandable. But this is beating of a dead horse.
> 
> But what matters now is that by doing some small investigation i686 users can 
> still get support for their bugs which are common for both platforms. This 
> doesn't require any formalities like SIG or commitments which they can't make 
> and it is always available for anyone who can afford to spend some additional 
> time if such bug affects them bad enough.
> 

That's literally all the x86 SIG was asked to do - get some small investigation 
work going so that between all of them, packages that had i686-unique bugs 
could be fixed in a timely fashion. They couldn't get enough interest going to 
even keep the kernel building for i686 as well as x86-64.

Everything else, including commitments from individuals and the mailing list, 
was secondary to that goal, and was only looked at because the x86 SIG was 
failing to help resolve FTBFS bugs that were blocking S390, x86-64 and other 
arches.

> I think this could work better than previous attempts at keeping x86 SIG 
> alive. Of course nothing prevents some volunteers to do above work on behalf 
> of other users or create mirrors for distribution of i686 packages. But this 
> is not critical to keep things running.

The problem is that you're discussing what the x86 SIG was formed to do - the 
only reason to form a SIG to begin with was so that there was a bit of Fedora 
infrastructure (mailing lists etc) devoted to connecting packagers with 
i686-only problems to people who were willing to try and solve them.

If no-one's willing to actually do anything to fix i686 FTBFS issues, then 
Fedora will drop i686 support eventually. That's all that's happening here - 
no-one wants to do anything to keep i686 alive as an architecture for Fedora, 
so Fedora is dropping i686.
___
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 31 System-Wide Change proposal (late): No i686 Repositories

[Simon Farnsworth]

On 11 Sep 2019, at 16:12, vvs vvs  wrote:
> 
> Even better. That means that you can still get support for x86 but it will 
> require some more work on the user's side. They should just check if that bug 
> is indeed i686 specific.
> 
> I believe that all that argument for the lats three days was completely 
> unnecessary and should be blamed on an utterl failure of communication.

The fundamental thing here is that, when a package fails on S390 but not on 
x86-64, there are motivated people in the S390 SIG who'll help me out with 
what's wrong, explaining the differences between S390 and x86-64 in a useful 
format, and often just fixing it if it's an S390-specific oddity, not a 
straight bug that happens not to manifest on x86-64.

In contrast, the x86 SIG never got enough volunteers to do the same role - if a 
build was an issue on x86 but not x86-64, then they'd not have the available 
manpower to help the package maintainer (often the kernel maintainers, in x86's 
case) fix the build.

Had the x86 SIG been able to identify the root causes of bugs in packages that 
failed on x86, like the kernel, and come up with usable workarounds and/or 
fixes, then Fedora would not be considering dropping x86. As it is, though, it 
appears that nobody cares enough about 32-bit kernels and binaries (although 
some x86-64 people care about 32-bit libraries) to keep i686 builds going.

Fundamentally, this happens in volunteer projects - nobody wants to do the 
work, nobody is willing to pay enough to get someone else to want to do the 
work, so it doesn't happen.

-- 
Simon
___
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: Better interactivity in low-memory situations

[Simon Farnsworth]

> On 10 Aug 2019, at 17:56, Georg Sauthoff  wrote:
> 
> On Fri, Aug 09, 2019 at 03:50:43PM -0600, Chris Murphy wrote:
> [..]
>> Problem and thesis statement:
>> Certain workloads, such as building webkitGTK from source, results in
>> heavy swap usage eventually leading to the system becoming totally
>> unresponsive. Look into switching from disk based swap, to swap on a
>> ZRAM device.
>> 
>> Summary of findings (restated, but basically the same as found at [2]):
>> Test system, Macbook Pro, Intel Core i7-2820QM (4/8 cores), 8GiB RAM,
>> Samsung SSD 840 EVO, Fedora Rawhide Workstation.
>> Test case, build WebKitGTK from source.
> [..]
> 
> To avoid such issues I disable swap on my machines. I really don't see
> the point of having a swap partition if you have 16 or 32 GiB RAM. Even
> with 8 GiB I disable swap.
> 
https://chrisdown.name/2018/01/02/in-defence-of-swap.html 
 is worth a read - 
TL;DR the kernel used (pre 4.0) to be awful about swap, but modern kernels use 
it to avoid paging executable (file-backed) pages in low memory. If any paging 
is needed, lack of swap means that the kernel will page out active code before 
it gets as far as an OOM kill, resulting in a longer time to recover from 
memory contention (regardless of whether there's an OOM kill or the system 
recovers naturally).

Further, a sensible amount of swap (say 2 GiB or so) means that unused 
anonymous pages (e.g. data that's left over from initialization, or data that 
will only be needed when a process exits) can be swapped out and left on disk, 
freeing up valuable RAM for useful work.

Basically, a sane amount of swap is healthy - old advice about large amounts of 
swap is not.

> With - say - 8 GiB the build of a large project might fail (e.g. llvm,
> e.g. during linking) but it then fails fast and I can just restart it
> with `ninja -j2` or something like that.
> 
> Another source of IO related unresponsiveness is buffer bloat - I thus
> apply this configuration on my machines:
> 
>$ cat /etc/sysctl.d/01-disk-bufferbloat.conf
>vm.dirty_background_bytes=107374182
>vm.dirty_bytes=214748364
> 
> Best regards
> Georg
> -- 
> 'Time your programs before making claims about efficiency'
>  (Bjarne Stroustrup, The C++ Programming Language, 4th ed., p. 132, 2013)
> ___
> 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

___
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: F30 Self-Contained Change proposal: MongoDB Removal

[Simon Farnsworth]

> On 31 Jan 2019, at 01:21, John Harris  wrote:
> 
> On Wednesday, January 30, 2019 8:10:13 PM EST Simon Farnsworth wrote:
>> I do if I'm using it to provide a service that could be construed as "making
>> the functionality of the Program … available to third parties as a
>> service", under section 13 of the SSPL. As MongoDB's functionality includes
>> retrieval of documents and document fragments, it's possible to construe
>> the licence as covering anything that involves retrieval of a document or
>> document fragment from a server (so all web applications, for example).
> 
> Yeah, that's not what section 13 actually says.
> 
> If you make the functionality of the Program or a modified version available 
> to third parties as a service, you must make the Service Source Code 
> available 
> via network download to everyone at no charge, under the terms of this 
> License.
> 

What exactly is "the functionality of the Program" in the case of MongoDB? 
Document storage and retrieval are two components of that functionality, and as 
written, it can be construed as meaning that if you provide document retrieval 
or document storage from MongoDB in your service, then you "make the 
functionality of the Program …available to third parties as a service".

I suspect this isn't what they mean, but it's what they've written in their 
licence.

> While the license certainly doesn't require anything that uses MongoDB as a 
> backing store to be free software, you should definitely make that free 
> software under the terms of a license such as the AGPL.
> 

Where are you licensed to practice law? And is this legal advice that I can 
rely on your professional liability insurance for? Note that this statement is 
the exact opposite of one I've had from a real lawyer whose liability insurance 
kicks in if they're wrong - using MongoDB as a backing store could well be 
enough to require you to supply the whole service, including Major Components 
like the Linux kernel, under SSPL. AGPL is unacceptable - the terms say SSPL, 
and AGPL and SSPL are not identical.

>> This may not be what's intended, but it's a reasonable reading of the
>> licence as written, and it could get expensive to argue in court that
>> covering all document retrieval was not intended.
> 
> Perhaps. The easiest option is to just use only free software.
> 
Worse than that - the only option if section 13 kicks in is to use only SSPL 
licensed software, as you have to supply the majority of your source code 
*under the SSPL*. Not just supply source code, but licence it under SSPL terms. 
AGPL may be Free Software, but it's not acceptable here.
>> 
>>> 
>>> 
>>>> I do not have sufficient rights to relicence the Linux kernel under the
>>>> SSPL - it's not GPLv2 compatible - and the Linux kernel is one part of
>>>> a service I might choose to offer using only Free Software from Fedora's
>>>> repos, plus an SSPL licensed component.
>>> 
>>> 
>>> Yeah, none of that matters. See section 1.
>> 
>> 
>> I've read section 1 - Linux implements more than just a "Standard Interface"
>> as per that section (it goes beyond POSIX or any interface specified by an
>> Official Standards Body, and is not specified for a particular programming
>> language). Because of the way section 1 is drafted, "System Libraries" are
>> excluded from section 13, but *not* "Major Components"; the kernel in this
>> case is a major component, and is thus only definitively excluded if it
>> implements a "Standard Interface".
> 
> While I disagree, if you're worried about that just don't use grsecurity and 
> you're fine. Oh, and don't use proprietary kernel modules.
> 
Or xfs, or ext4, or mmap, as they all supply things beyond just Standard 
Interfaces as per the licence. And it's not enough to just release source - you 
are required to supply the source to everything you supply under SSPL terms, 
which means that you must have the rights to relicense all source you're 
supplying under the SSPL.

>> This may be an oversight - they may intend to exclude "Major Components" as
>> well as "System Libraries", but it's not what they've written in the
>> licence text. Only an item "which is not part of that Major Component" or
>> which "serves only to enable use of the work with that Major Component, or
>> to implement a Standard Interface" are excluded from the SSPL's reach.
> 
>> But not according to the text of the SSPL; for MongoDB specifically, the FAQ
>> may act as "estoppel", but it's not part of the licence as written; merely
>> providing doc

Re: F30 Self-Contained Change proposal: MongoDB Removal

[Simon Farnsworth]

Note that I'm not a lawyer of any type - this is a distillation of 
conversations I've had with real lawyers, but you should not take it as legal 
advice. Talk to your own legal people if you need something you can rely on.

> On 30 Jan 2019, at 23:41, John Harris  wrote:
> 
> On Wednesday, January 30, 2019 4:19:13 PM EST Simon Farnsworth wrote:
>> But the SSPL also prevents you from using Free Software with it, unless you
>> have sufficient rights to offer said Free Software under the SSPL, as per
>> section 13 of the SSPL.
> 
> You don't have to relicense software in order to be able to use it.

I do if I'm using it to provide a service that could be construed as "making 
the functionality of the Program … available to third parties as a service", 
under section 13 of the SSPL. As MongoDB's functionality includes retrieval of 
documents and document fragments, it's possible to construe the licence as 
covering anything that involves retrieval of a document or document fragment 
from a server (so all web applications, for example).

This may not be what's intended, but it's a reasonable reading of the licence 
as written, and it could get expensive to argue in court that covering all 
document retrieval was not intended.

> 
>> I do not have sufficient rights to relicence the Linux kernel under the SSPL
>> - it's not GPLv2 compatible - and the Linux kernel is one part of a service
>> I might choose to offer using only Free Software from Fedora's repos, plus
>> an SSPL licensed component.
> 
> Yeah, none of that matters. See section 1.

I've read section 1 - Linux implements more than just a "Standard Interface" as 
per that section (it goes beyond POSIX or any interface specified by an 
Official Standards Body, and is not specified for a particular programming 
language). Because of the way section 1 is drafted, "System Libraries" are 
excluded from section 13, but *not* "Major Components"; the kernel in this case 
is a major component, and is thus only definitively excluded if it implements a 
"Standard Interface".

This may be an oversight - they may intend to exclude "Major Components" as 
well as "System Libraries", but it's not what they've written in the licence 
text. Only an item "which is not part of that Major Component" or which "serves 
only to enable use of the work with that Major Component, or to implement a 
Standard Interface" are excluded from the SSPL's reach.

> 
>> Thus, I'm stuck - I can't use non-SSPL software from Fedora (or, indeed,
>> from the FSF) in combination with SSPL licensed software to provide a
>> service, even if I *also* make the full source of the entire service
>> available, since I'm not making the source available under the SSPL.
> 
> Unless you're providing MongoDB as a service, it doesn't matter, even 
> according to their own FAQ.
> 
But not according to the text of the SSPL; for MongoDB specifically, the FAQ 
may act as "estoppel", but it's not part of the licence as written; merely 
providing document storage or retrieval provides "the functionality of the 
Program … to third parties". If I do that as a service - e.g. pulling out 
billing records from MongoDB - I'm "mak[ing] the functionality of the Program 
or a modified version available to third parties as a service", and I'm covered 
by section 13 and have to distribute all but "System Libraries" as source under 
the SSPL. This *includes* "Major Components", as section 1 doesn't actually 
exclude them.

Again, this may not be what they intended, but it's what the text of the 
licence says, and I would rather not rely on having to claim that what they 
wrote is not what they meant in order to succeed in court.

Given these issues with the drafting of the licence, and the need to rely on 
MongoDB's FAQ to argue that, in the MongoDB case, the FAQ acts as estoppel, I 
can see why Fedora legal would consider the licence non-free. You've made 
claims for it that aren't backed by the actual text of the licence, for example.
-- 
Simon
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30 Self-Contained Change proposal: MongoDB Removal

[Simon Farnsworth]

> On 30 Jan 2019, at 17:06, John Harris  wrote:
> 
> On Tuesday, January 29, 2019 10:28:46 PM EST Neal Gompa wrote:
>> On Tue, Jan 29, 2019 at 5:33 PM John Harris  wrote:
>> 
>>> 
>>> 
>>> On Tuesday, January 29, 2019 5:29:58 AM EST Ben Cotton wrote:
>>> 
 Fedora has determined that the Server Side Public Licensev1 (SSPL) is
 not a Free Software License.
>>> 
>>> 
>>> 
>>> For what reason is SSPL considered non-free? As I see, it's essentially a
>>> GPL incompatible AGPL license.
>>> 
>>> 
>> 
>> 
>> It restricts fields of endeavor and how you can use it. That conflicts
>> with freedom 0 of the Free Software Definition. In addition, no one is
>> sure it's actually possible to comply with the SSPL as worded, since
>> it attempts to convert the licensing of everything that's part of the
>> running system, including things not directly linked to it.
> 
> The ability to use proprietary software in combination with free software is 
> not part of Freedom 0.
> 
But the SSPL also prevents you from using Free Software with it, unless you 
have sufficient rights to offer said Free Software under the SSPL, as per 
section 13 of the SSPL.

I do not have sufficient rights to relicence the Linux kernel under the SSPL - 
it's not GPLv2 compatible - and the Linux kernel is one part of a service I 
might choose to offer using only Free Software from Fedora's repos, plus an 
SSPL licensed component.

Thus, I'm stuck - I can't use non-SSPL software from Fedora (or, indeed, from 
the FSF) in combination with SSPL licensed software to provide a service, even 
if I *also* make the full source of the entire service available, since I'm not 
making the source available under the SSPL.

-- 
Simon
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The glvnd + mesa update for F25

[Simon Farnsworth]

> On 6 Feb 2017, at 22:01, Jan Pokorný <jpoko...@redhat.com> wrote:
> 
> On 06/02/17 15:13 -0500, Christian Schaller wrote:
>> There has been a lot of discussions for the last few years about glvnd on
>> the mesa-devel list and at XDC. This is not Fedora specific technology, but 
>> a change in how Mesa will work everywhere and thus there has not been a lot
>> of discussions about it here on Fedora-devel. But that is true for most 
>> stuff,
>> we do not discuss major new kernel features here that much either as one 
>> example.
> 
> I don't think that's a fair point.  If there was an artificial
> intermediate level put in front of libc that would only be to
> solve issues with some hardware component, and it would be forcibly
> implanted into Fedora unnecessarily for all audience, then it would
> be comparable.
> 
> But even then, I doubt it would happen without questioning such
> aspects.
> 
> Forcing glvnd for all is Fedora specific, as far as I can tell.
> 
Note, however, that glvnd is replacing an existing Mesa indirection layer (used 
to allow one Mesa build to link in the appropriate OpenGL libraries for AMD 
Radeon, Intel iGPUs, Noveau etc at run time) with an indirection layer that can 
also link in other drivers for OpenGL, not just Mesa ones.

In other words, this isn't putting an artificial intermediate layer in front of 
a library - it's replacing one intermediate layer with another that happens to 
allow for more back end implementations than the old one did.

-- 
Simon Farnsworth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Call to retire gstreamer-0.10

[Simon Farnsworth]

> On 7 Dec 2016, at 18:20, Sérgio Basto <ser...@serjux.com> wrote:
> 
> Thanks for reply 
> 
> On Qua, 2016-12-07 at 11:56 -0600, Yaakov Selkowitz wrote:
>> On 2016-12-07 11:49, Sérgio Basto wrote:
>>> 
>>> Hi, like webkit < 3 retirement , you shouldn't repoquery with
>>> --recursive, If I am correct .
>>> 
>>> Again after wxGTK and wxGTK3 be updated all dependencies will be
>>> solved
>>> automatically , also same case for wxPython , If I am correct.
>> Incorrect.  I was talking about gstreamer-python, not wxPython. 
>> Furthermore, wxGTK's gstreamer dependency is already isolated in 
>> wxGTK{,3}-media, so only its reverse dependencies are affected, not 
>> everything that uses wxGTK.
> 
> Yes, I mention wxGTK{,3} because we have other process similar to this
> around webkit [1] 
> 
>>> 
>>> What I mean is: first we should concern in --whatrequires
>>> gstreamer-
>>> 0.10 directly to understand what really is in question .
>> Anything which --whatrequires gstreamer-python is clearly affected as
>> well.
> 
> But for gstreamer-python we don't have gstreamer1-python ? so how we
> can fix the packages that have dependencies on gstreamer-python ? 
> 

We do, however, have python-gstreamer1 in both flavours (Python 2 and Python 
3), which is the extras on top of GI to make it easy to work with.

> As part of a global ideia of maintain packages, should be good have
> specialists in migrating components, in this case gstreamer0 to
> gstreamer1. 
> 
> Also do all migrations (maintain) of all the packages together could be
> more efficient (just an ideia). 
> 
> [1]
> https://bugzilla.redhat.com/show_bug.cgi?id=1375846
> -- 
> Sérgio M. B.
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

-- 
Simon Farnsworth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF and PackageKit background data usage

[Simon Farnsworth]

On 31 Oct 2016, at 11:41, Richard Hughes <hughsi...@gmail.com> wrote:
> 
> On 30 October 2016 at 01:26, Adam Williamson <adamw...@fedoraproject.org> 
> wrote:
>> 1) Both dnf and GNOME Software / PackageKit default to performing
>> fairly data-hungry transactions in the background, out of the box,
>> without telling you about it. GNOME's is particularly bad, as it will
>> happily download available updates in the background, which can be
>> gigabytes worth of data.
> 
> If you're on an "unmetered" connection type...
> 

How does a connection become "unmetered"? It can't just be on interface type, 
as I have metered connections on all interface types, so presumably you use 
some form of web service to distinguish "metered" from "unmetered" based on a 
list of known IP blocks?

Or do you simply assume that all connections are metered until the user says 
otherwise?

-- 
Simon Farnsworth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ZFS on linux

[Simon Farnsworth]

> On 14 Jan 2016, at 11:39, Neal Gompa <ngomp...@gmail.com> wrote:
> 
> On Thu, Jan 14, 2016 at 2:35 PM, Michael Catanzaro <mcatanz...@gnome.org> 
> wrote:
>> On Thu, 2016-01-14 at 20:24 +0100, Reindl Harald wrote:
>>> likely i did much more research than you can even imagine long
>>> before
>>> that thread started
>> 
>> I find this challenging to believe.
>> 
>>> CDDL is incompatible with GPLv2 - period
>> 
>> Did you read the web site at all? The argument is that it can be used
>> as a kernel module without constituting a derived work. Many developers
>> believe this is not a GPL violation. Many believe otherwise. This is a
>> well-known, open controversy. It's to be expected that different sets
>> of lawyers will have different opinions on the risk depending on
>> business requirements and their company's risk profile.
>> 
>> Michael
> 
> As far as I know, that's why the kernel has symbol export feature to
> indicate which ones are covered by the GPL-ness (GPL_ONLY symbol
> export).
> 
The distinction between EXPORT_SYMBOL and EXPORT_SYMBOL_GPL is minimal. The 
theory [1] is that EXPORT_SYMBOL_GPL indicates that the kernel community 
believes that EXPORT_SYMBOL_GPL symbols are so core to Linux that you cannot 
use them without creating a derived work under copyright law. Thus using an 
EXPORT_SYMBOL_GPL symbol from a GPL-incompatible module is deliberate 
infringement, with all that that implies in terms of the legal system; using an 
EXPORT_SYMBOL symbol from a GPL-incompatible module *might* be non-infringing 
(if the work using it is legally separate in terms of copyright law), or might 
be accidental infringement (if you didn't realise what you were doing carried 
legal risk).

In all cases, you need to talk to your copyright expert lawyer about 
distributing GPL-incompatible modules for the Linux kernel. Copyright law has 
some sharp edges, and you can get hurt if you ignore them; for Fedora, Red Hat 
Inc take on that liability, and they'll not want to do anything that puts them 
at risk of harm.

[1] https://lwn.net/Articles/154602/

-- 
Simon Farnsworth
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On running gui applications as root

[Simon Farnsworth]

On Thursday 19 Nov 2015 13:56:32 Andrew Haley wrote:
> On 11/19/2015 01:03 PM, Simon Farnsworth wrote:
> > "sudo -e  /etc/hosts", will ... still work
> 
> Hold on, I think I may not be understanding something.  If "sudo -e
> /etc/hosts" will still work, why won't "sudo emacs /etc/hosts" ?
> 
> Andrew.

"sudo -e" creates a temporary file owned by you containing the file contents, 
then has your editor access it; when your editor exits, the temporary file's 
contents replace the original file.

"sudo emacs" runs emacs as a new user; AIUI, in the current Wayland security 
model, emacs running as another user cannot access the Wayland server, because 
it's not the same user.

-- 
Simon Farnsworth
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Simon Farnsworth]

On Thursday 19 Nov 2015 12:48:50 Andrew Haley wrote:
> On 11/18/2015 06:49 PM, Adam Jackson wrote:
 
> > Phrased another way: no, it's not *your computer* we're talking about
> > here. The computer in question rightfully belongs to someone else; we
> > are here discussing how to be responsible for the code they allow us to
> > run on it.
> 
> That is a reasonable point for view.  However, the point of Free
> Software is freedom; and the ability to shoot oneself in the foot is
> part of that freedom.  One of the greatest advantage of Free Software
> from my point of view is that people can choose.  And I know that I am
> not alone in chooing to use (and to write) Free Software for that
> reason: freedom is not just about strict licence compliance.
> 
> Five years or so ago I publicly defended Wayland because I was assured
> that things would continue to work after the transition.  Being able
> to edit files with emacs is an essential part of that "continuing to
> work."
> 
I don't see how a lack of access to the GUI when running as root will prevent 
Emacs from editing root-owned files.

TRAMP (if you wish to stay inside emacs) and "sudo -e" (if you'd rather work 
outside emacs) both provide mechanisms (that I use today under X11) for emacs 
to edit root-only files while the vast bulk of emacs runs as my user ID.

Put another way: "sudo emacs /etc/hosts" will break under Wayland. "sudo -e 
/etc/hosts", "emacsclient /sudo::/etc/hosts" and "emacs /sudo::/etc/hosts" 
will all still work as they do today, as will "emacs --eval (find-file 
/sudo::/etc/hosts)"

-- 
Simon Farnsworth
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Secure boot and packaging third-party kernel modules

[Simon Farnsworth]

On Friday 29 May 2015 15:24:24 David Sommerseth wrote:
 
 On 28/05/15 23:03, David Smith wrote:
snip
  But really the best solution here is to get the mhvtl kernel module
  upstream.
 
 Agreed, but I'm not sure how keen upstream kernel developers are to
 carry a driver for virtual tape devices.  I've asked mhvtl upstream if
 that has been considered, but currently I'm not convinced that will
 happen any time soon.
 
As a different route, if upstream are still active, have they considered
using LIO's TCMU interface[1]?

Combine this with tcm_loop to provide local access to the LIO SCSI targets,
and it looks to provide the same featureset as mhvtl's kernel module, using
existing kernel infrastructure. Note that I've not dived in deep enough to
confirm that LIO is a competent solution here, but it looks like it provides
the features mhvtl needs.

[1] https://www.kernel.org/doc/Documentation/target/tcmu-design.txt

--
Just a thought,

Simon Farnsworth


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again

[Simon Farnsworth]

On Monday 27 April 2015 14:36:53 Chris Murphy wrote:
 On Mon, Apr 27, 2015 at 10:52 AM, Simon Farnsworth si...@farnz.org.uk wrote:
 
  Windows doesn't work fine with RTC in local time, unless you have one and
  only one Windows install on the system. If you (say) dual-boot Windows 95
  and Windows NT 4.0 (I've done this in a work environment), and boot back and
  forth between them on a DST change flag day, then both OSes expect to change
  the RTC to reflect current local time. You then have to pull the RTC time
  back to reality manually, as it's now out by one hour.
 
 The point is that systemd gets fussy when RTC is in local time even if
 it's a single boot system. I don't know what the full consequence of
 its complaint is, but it complains nevertheless (via timedatectl)
 basically saying it's unsupported.

The full consequence on the complaint from timedatectl is that if you aren't
careful around DST change time, you will either face no DST adjustment, or
DST adjustment applied twice. If you're lucky, it just works (as it has for
me when running RTC in local time), but why shouldn't systemd warn you that
you've got to be lucky?

This is exactly the same problem you face when you multiboot Windows on a
BIOS system, FWIW. I've not looked to see if the problem still exists in an
EFI world.

 Windows 95 and NT are completely different lineages and never
 supported dual-boot. Maybe Windows 95 followed by 98, or Windows NT
 3.5 followed by 4.0 would have; just as it's possible to dual boot
 Windows 7 followed by 8.

Same issues happened on the machines that triple-booted Windows 95, 98 and
Me, only worse as they got adjusted three times on DST change, not just
twice.

The machine that dual-booted Windows 2000 Server and Windows 2000
Workstation also had the same issue, as did a later system that dual-booted
Windows 2000 Workstation and Windows XP. Note that these two systems were
dual-booting on a single disk, and Windows still couldn't get it
right. Microsoft's advice was to manually check the clock on the first boot
of each OS after a DST change.

  IOW, Windows works with RTC in local time if (and only if) it's the one and
  only OS on the system that writes to the RTC. Fedora also writes to the RTC,
  and thus we have to somehow co-ordinate changes with Windows in such a way
  that DST adjustments only get applied once
 
 If there's evidence of another system present, maybe don't change the
 RTC? Just use it as a guide absent an Internet connect, and with one
 chrony can set system time without changing the RTC which only causes
 problems.
 
 Apple's boot camp package patches Windows to deal with this problem, FWIW.

 
 ; I've not looked at UEFI to find
  out whether UEFI solves this.
 
 It's solved there, I have no idea if this is honored by the kernel or
 systemd though.
 http://wiki.phoenix.com/wiki/index.php/EFI_TIME

Can you check that? If it's solved on EFI systems, then this becomes largely
a historic artefact - we aim to trust EFI, and BIOS boot users need to apply
the same caution they've always had to apply around a DST change.

 
 
  snip
   We could try to build an infrastructure to store tz information, and
   rebuild initramfses, etc, or we can just rip of the bandaid. This is a
   game of whack-a-mole which accelerates are systems get more dynamic
   and mobile that we cannot really hope to win.
 
  Hindsight being 20/20, obviously around 13 years ago Linux (and
  friends) should have agreed to not fight the RTC being in local time
  on multiboot systems, in particular dual boot ones with Windows.
  Windows figures out what timezone the RTC is in by reading the
  registry entry 
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
  which a Linux OS service could also defer to by default rather than
  the adversarial relationship that's been chosen.
 
  Which registry entry 
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation?
  The one in my Windows 95 install, or the one in my Windows NT 4.0 install?
 
 Seeing as Microsoft doesn't support either one of those for something
 like 20 years now, I'd say neither but still possible to infer another
 OS is already present and to leave the RTC alone and just adapt to a
 local setting and time service rather than insisting on changing the
 clock.

And if the other OS isn't Windows? What if it's FreeBSD, or OpenBSD, or
VxWorks, or QNX, all of which default to UTC in the RTC? What about Android?

  Come to that, how is Linux supposed to find and read the registry, given
  that it may not be allowed by administrator policy to mount the filesystem
  that contains the registry? In the worst case, you dual boot the way I did
  at work, where the machine's disk is in a cold swap caddy, and you cannot
  physically get at the disk.
 
 If it seems like a mono OS installation, then its reasonable for the
 OS to assume it can assume complete ownership of the RTC.

So now I've got different behaviour depending

Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again

[Simon Farnsworth]

On Monday 27 April 2015 10:39:40 Chris Murphy wrote:
 On Mon, Apr 27, 2015 at 6:54 AM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  On Sun, Apr 26, 2015 at 11:47:18PM -0600, Chris Murphy wrote:
  Time in UTC is just as absurd and arbitrary as time in a local
  timezone,
  No, it's not. This has been written about many times, but in short:
 
 None of what you wrote explains a.) Why RTC in local works fine on
 Windows; b.) why two users in this thread, including the original
 poster, had problems with a stable timezone set.

Windows doesn't work fine with RTC in local time, unless you have one and
only one Windows install on the system. If you (say) dual-boot Windows 95
and Windows NT 4.0 (I've done this in a work environment), and boot back and
forth between them on a DST change flag day, then both OSes expect to change
the RTC to reflect current local time. You then have to pull the RTC time
back to reality manually, as it's now out by one hour.

IOW, Windows works with RTC in local time if (and only if) it's the one and
only OS on the system that writes to the RTC. Fedora also writes to the RTC,
and thus we have to somehow co-ordinate changes with Windows in such a way
that DST adjustments only get applied once; I've not looked at UEFI to find
out whether UEFI solves this.

snip
  We could try to build an infrastructure to store tz information, and
  rebuild initramfses, etc, or we can just rip of the bandaid. This is a
  game of whack-a-mole which accelerates are systems get more dynamic
  and mobile that we cannot really hope to win.
 
 Hindsight being 20/20, obviously around 13 years ago Linux (and
 friends) should have agreed to not fight the RTC being in local time
 on multiboot systems, in particular dual boot ones with Windows.
 Windows figures out what timezone the RTC is in by reading the
 registry entry 
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
 which a Linux OS service could also defer to by default rather than
 the adversarial relationship that's been chosen.
 
Which registry entry 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation?
The one in my Windows 95 install, or the one in my Windows NT 4.0 install?

Come to that, how is Linux supposed to find and read the registry, given
that it may not be allowed by administrator policy to mount the filesystem
that contains the registry? In the worst case, you dual boot the way I did
at work, where the machine's disk is in a cold swap caddy, and you cannot
physically get at the disk.

--
Simon Farnsworth


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Unretiring cx18-firmware, if anyone else still wants it in the distro

[Simon Farnsworth]

Hello all,

I've got the misfortune of maintaining a small number of systems that use
the cx18 driver for their HVR-1600 cards; I'm just in the process of
bringing these systems up to Fedora 21, and have discovered that
cx18-firmware was retired.

As I'm going to have to maintain the package for work purposes, I'm
volunteering to maintain it in Fedora for F21 and later. If anyone's
interested in having it available in Fedora, the review request is at:

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

-- 
Simon Farnsworth


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unretiring cx18-firmware, if anyone else still wants it in the distro

[Simon Farnsworth]

On Wednesday 18 March 2015 13:56:07 Josh Boyer wrote:
 On Wed, Mar 18, 2015 at 1:34 PM, Simon Farnsworth si...@farnz.org.uk wrote:
  Hello all,
 
  I've got the misfortune of maintaining a small number of systems that use
  the cx18 driver for their HVR-1600 cards; I'm just in the process of
  bringing these systems up to Fedora 21, and have discovered that
  cx18-firmware was retired.
 
  As I'm going to have to maintain the package for work purposes, I'm
  volunteering to maintain it in Fedora for F21 and later. If anyone's
  interested in having it available in Fedora, the review request is at:
 
  https://bugzilla.redhat.com/show_bug.cgi?id=1203379
 
 These files are included in the upstream linux-firmware git repo.
 
 [jwboyer@lando linux-firmware]$ git log v4l-cx23418-*
 commit a699eb6997f21d4fc88526754824e90417749db6
 Author: Mauro Carvalho Chehab mche...@redhat.com
 Date:   Fri Apr 3 07:33:20 2009 -0300
 
 Add firmwares for three Conexant chipsets for cx18, cx23885 and cx23840
 
 Add firmwares for those V4L/DVB devices:
 CX23418 PCI Broadcast A/V with MPEG encoder
 CX25843 sideport Broadcast A/V decoder
 CX23885 PCI Express Broadcast A/V decoder
 
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 
 
 It would probably make a lot more sense just to get them included in
 the Fedora linux-firmware package.
 
That sounds like a very good idea to me. I've filed
https://bugzilla.redhat.com/show_bug.cgi?id=1203385 for the attention of the
linux-firmware maintainers.

--
Simon Farnsworth


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Self Introduction

[Simon Farnsworth]

Hi Ales,

I've put https://bugzilla.redhat.com/show_bug.cgi?id=1034341 up for review - 
I've not had time yet to go and review other people's packages.

Upstream know I'm doing this; they've taken a patch from me already that fell 
out of the review, to fix the FSF's address in their files.

Simon

On Wednesday 27 November 2013 05:19:36 Ales Ledvinka wrote:
 Hello,
 
 This might be the starting point:
 
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join
 
 - Original Message -
 From: Simon Farnsworth si...@farnz.org.uk
 To: devel@lists.fedoraproject.org
 Sent: Monday, November 25, 2013 5:28:21 PM
 Subject: Self Introduction
 
 Hello all,
 
 My employer, ONELAN, have been using Fedora as a baseline Linux system for 
our 
 products for a while now, and I've just hit a situation where no-one's 
 packaging gstreamer1-python, but we're going to start depending on it.
 
 Rather than just keep my packaging work to myself, I'm volunteering to 
 maintain this package within Fedora, so that everyone can benefit from it, 
 including ONELAN (who will hopefully see the quality of the package improve 
as 
 I learn from you guys).
 
 


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Self Introduction

[Simon Farnsworth]

Hello all,

My employer, ONELAN, have been using Fedora as a baseline Linux system for our 
products for a while now, and I've just hit a situation where no-one's 
packaging gstreamer1-python, but we're going to start depending on it.

Rather than just keep my packaging work to myself, I'm volunteering to 
maintain this package within Fedora, so that everyone can benefit from it, 
including ONELAN (who will hopefully see the quality of the package improve as 
I learn from you guys).

-- 
Simon Farnsworth

signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct