Re: F36 Change: ostree native containers / CoreOS layering (System-Wide Change proposal)
On Tue, Nov 23, 2021, at 12:18 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/OstreeNativeContainer > > == Summary == > > Enhance the (rpm-)ostree stack to natively support OCI/Docker > containers as a transport and delivery mechanism for operating system > content. > > This is the basis of > https://github.com/coreos/enhancements/blob/main/os/coreos-layering.md > > > == Owner == > * Name: [[User:walters| Colin Walters]] > * Email: walt...@verbum.org > > > == Detailed Description == > > Having the Fedora ecosystem (from users to release engineering) > maintain tooling that operates on all three of "container images", > RPMs, and OSTree updates is a maintenance burden. > > This proposes that: > > * The ostree stack is enhanced to support > encapsulating/unencapsulating ostree commits as OCI/Docker images > (DONE) > * rpm-ostree is updated to consume this, while still supporting all > its current features (e.g. per-machine package layering) (DONE) > * We ship e.g. `quay.io/fedora/coreos:stable` and > `quay.io/fedora/silverblue:36` etc. > * We support '''deriving''' new user custom images from these images > * We enhance this tooling to > [https://github.com/ostreedev/ostree-rs-ext/issues/69 support > chunking] > > For more details, please see: > > * [https://github.com/coreos/enhancements/blob/main/os/coreos-layering.md > CoreOS layering enhancement] > * [https://coreos.github.io/rpm-ostree/container/ rpm-ostree container docs] > * [https://github.com/ostreedev/ostree-rs-ext/ ostree-rs-ext project] > > Note that significant effort has been invested in ensuring > compatibility between what exists in ostree today and OCI/Docker > container image "encapsulation". For example, we will continue to > reuse the GPG signature infrastructure on OSTree commits that exists > today - the ostree tooling knows how to verify the signature *inside* > the container image. In the future, we will also likely invest in > container-native signatures. > > > == Benefit to Fedora == > > * Stronger focus on Docker/OCI as transport for operating system and > applications > * New ability to easily create derived operating system images "server side" > * More benefit from e.g. work on container deltas Will things be slower than native ostree? I've got no problem with the capability being added, but I do wonder, Why not rojig, aka native RPMs plus a special metadata RPM, aka jigdo for ostree? We've already got great RPM infrastructure. Plus we could get rid of countme.timer and instead ride the rpm-md connection like the RPM-based variants do. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)
On Mon, May 17, 2021, at 6:05 AM, Karel Zak wrote:
> On Thu, Apr 01, 2021 at 02:22:31PM -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/SmallerContainerBase
> >
> > == Summary ==
> > This change proposes to remove 3 packages (sssd-client, util-linux,
> > shadow-utils) from the Container Base Image (including the minimal
> > image). The Fedora Base Image is still quite large compared to other
> > distributions and the tools offered by these packages are not
> > essential in base image.
>
> I do not understand how do you want to use any system without for example
> mount(8), umount(8), ... ;-)
>
> > The installed size of each package is :
> >
> > {| class="wikitable"
> > |-
> > ! Package !! Installed Size
> > |-
> > | util-linux || 13018140
>
> My plan is to create more sub-packages from util-linux and create
> util-linux-core where will be essential tools like mount, losetup,
> blkid, lsblk, findmnt, etc.
>
> The change will be backwardly compatible. The classic util-linux.rpm
> will depend on this small util-linux-core package , so for all
> use-cases where is hardcoded util-linux we will not see a change. For
> use-cases where minimal installation is important will be possible to
> use alone util-linux-core.
>
> I also plan to move some less often used tools, like
>
> mcookie
> mesg
> raw
> isosize
> namei
> hardlink
I often use hardlink during container build to make the image smaller by
hardlinking the identical files within.
> fincore
> wall
> readprofile
> ctrlaltdel
> fsck.cramfs
> fsck.minix
> mkfs.cramfs
> mkfs.minix
> fdformat
>
> to util-linux-optional package.
>
> Does it make sense?
>
I'm fine with all of them except hardlink being moved to an -optional package.
V/r,
James Cassell
___
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: Proposal to fail builds if RPATH is found in Fedora 35
On Fri, Mar 26, 2021, at 2:06 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Mar 26, 2021 at 06:51:56PM +0100, Miro Hrončok wrote: > > On 26. 03. 21 18:24, Charalampos Stratakis wrote: > > >python2.7churchyard cstratak torsava vstinner > > > > I was curious. The error is: > > > > 0001: file '/usr/lib64/python2.7/lib-dynload/pyexpat.so' contains a > > standard > > rpath '/usr/lib64' in [/usr/lib64] > > > > And the cause is... our own patch > > > > https://src.fedoraproject.org/rpms/python2.7/blob/rawhide/f/00187-add-RPATH-to-pyexpat.patch > > > > For reasons I don't understand, the bugzilla referenced from the > > patch is private. It is a RHEL 6.2 bugzilla from 2012 that could be > > summarized as: > > > > "If the user sets $LD_LIBRARY_PATH to a directory with > > broken/incompatible libraries, Python breaks." > > I'd vote for treating this as the wrong solution in the wrong place. > If you set LD_LIBRARY_PATH, you get to keep both pieces if anything goes > wrong. > Agreed. /me glares at SCL for LD_LIBRARY_PATH brokenness V/r, James Cassell ___ 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: selinux-policy package versioning change
On Tue, Mar 30, 2021, at 3:56 PM, Zdenek Pytela wrote: > > > On Mon, Mar 29, 2021 at 10:45 PM justina colmena ~biz > wrote: > > I'm still a little bit confused about the SELinux targeted policy > > "development" process versus the actual "roll-out," implementation, and > > deployment not only to Fedora on the deskop, but to various distributions > > of > > "CentOS" or commercial installations of Red Hat Enterprise Linux (RHEL) "in > > the cloud" especially on OpenVZ or other shared-kernel virtualization > > technologies as the case may be for businesses and end users who might > > otherwise benefit from SELinux Mandatory Access Control policies built in > > to > > the Linux kernel. > Most of the development happens in the rawhide github branch and > selected commits subsequently go to stable Fedora releases as well as > to Centos Stream and RHEL. There is no package difference between > various Fedora editions and spins for the same version. Would the RHEL 9 package have version 34 under this scheme? V/r, James Cassell ___ 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: ELN SIG First Meeting
On Sat, Mar 13, 2021, at 8:09 PM, Troy Dawson wrote: > On Mon, Mar 1, 2021 at 11:49 AM Davide Cavalca via devel > wrote: > > > > On Mon, 2021-03-01 at 09:26 -0500, Stephen Gallagher wrote: > > > I'd like to encourage anyone interested in this meeting to submit > > > agenda topics by replying to this email. Currently the agenda > > > > One thing I'd be interested in exploring is the feasibility of > > extending ELN to cover EPEL as well. This would make it easier to keep > > EPEL consistent between major releases (as packages would get branched > > automatically). It would also make it possible to test the combined ELN > > + EPEL snapshot and find potential issues early on in the process. > > > > Sorry for coming late to the discussion. I took a week off and all > sorts of things happened while I was gone. > > I believe Kevin and Smooge, and possibly even you Davide got this > backwards. And I think if we do this right, this can be a thing. > > When we started ELN, one of the major promises was that it wouldn't > interfere with regular Fedora work. That your average Fedora packager > that didn't care about ELN, could continue to not care about ELN and > nothing would change. > I believe we (ELN SIG) should extend the same courtesy to EPEL and the > EPEL community and packagers. > > The email discussion went in the direction of all the work that EPEL > would need to do to create an ELN EPEL. But we (ELN SIG) shouldn't > have expected that. We should have expected to do all the work. > > So, if we flip this around, where everything is on ELN, how would that work. > > We create a new Fedora target and tag: eln-extra (so people do NOT > confuse it with real EPEL) > eln-extra-build inherits from itself and eln-build > If a package is built against the eln-extra target, and it is > successful, it gets tagged with the eln-extra tag. > There is a daily (or some other time period) repo creation. No > images, just a repo, like epel. > There is a list of packages, similar to the list of packages used to > create the ELN list, on some github/gitlab/pagure repo. If you put a > package on that list, you associate your name with that package. > Just like ELN, when a package on the eln-extra list gets built in > rawhide, it get's built in eln-extra. In fact, it would be best if we > just altered the ELN trigger/periodic scripts to look at this list > along with the regular ELN list. > > What are people's thoughts on this? > No extra work on EPEL. > If someone, or some company wants to test ELN and need packages not in > ELN, they can add the packages to the list, with their name/company > associated with that package. > It would get built, put in the repo, and they can then run their ELN > test with the package they need. > This is exactly how it should be done! Otherwise, have a list of packages to exclude and include everything else. V/r, James Cassell ___ 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: restic update and src.fedoraproject.org and Self Introduction
On Tue, Feb 16, 2021, at 8:06 PM, Kevin Anderson wrote: [...] > The issue is that when I attempt to push over HTTPS I get an > authentication failure. I have tried with an API key as well as with > my FAS password using my FAS username (kanderson) for both. Is it > expected that I can't push, even to a fork, if I am not a part of a > packagers group? re-clone the repo using `fedpkg clone --anonymous`, then `git remote add fork `, then you can follow the prompts when you attempt to push to your fork. (it'll get you to open a browser and sign-in there) V/r, James Cassell ___ 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 34 Change: Enable systemd-oomd by default for all variants(System-Wide Change)
On Tue, Dec 22, 2020, at 10:45 AM, Michael Catanzaro wrote: > Each gnome-terminal tab runs in its own cgroup: > > │ │ │ ├─app-org.gnome.Terminal.slice > │ │ │ │ > ├─vte-spawn-1d1d5519-71d2-4035-929a-8a9ae5bc3822.scope > │ │ │ │ │ ├─7848 bash > │ │ │ │ │ └─7889 less /etc/hosts > │ │ │ │ > ├─vte-spawn-03fe4cc9-0400-4723-ac9b-e929b850ca02.scope > │ │ │ │ │ ├─7892 bash > │ │ │ │ │ ├─7927 systemd-cgls > │ │ │ │ │ └─7928 less > │ │ │ │ └─gnome-terminal-server.service > │ │ │ │ └─7843 /usr/libexec/gnome-terminal-server > > Firefox does this too. WebKit doesn't, but it won't be hard to fix. Not > sure about Chrome. Point is, apps have all the tools they need to use > cgroups to ensure out-of-control subprocesses don't cause the main > process to be killed, and our important default apps (Firefox and > gnome-terminal) actually do this. > It's there a way to make bash launch each command in a separate cgroup? I've usually got my various terminal apps in the background of a single bash session. It sounds like if any of them gets killed by oomd, they all would be killed. Glad to hear gnome-terminal separates tabs. Any idea if tilix does the same? V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
nt based. I think this magic number "signature" should vary based on the items that cause the format to change. What happens if you try to use a transcoded RPM on a non-compatible system? > > === Notes === > > # The headers are preserved bit for bit during transcoding. This > preserves signatures. The signatures cover the main header blob, and > the main header blob ensures the integrity of data in two ways: > ## Each file with content has a digest. Originally this was md5, but > today it’s usually sha256. In normal RPM this is only used to verify > the integrity of files, e.g. rpm -V. With CoW we use this > as a content key. > ## There is/are one or two digests (PAYLOADDIGEST and > PAYLOADDIGESTALT) covering the payload archive > (compressed cpio). The header value is preserved, but transcoded RPMs > do not preserve the original structure so RPM’s pre-installation > verification (controlled by %_pkgverify_level will fail. > dnf-plugin-cow disables this check in dnf because it > verifies the whole file digest which is captured during > download/transcoding. The second one is likely used for delta rpm. > # This is untested, and possibly incompatible with delta RPM (drpm). > The process for reconstructing an rpm to install from a delta is > expensive from both a CPU and I/O perspective, while only providing > marginal benefits on download size. It is expected that having delta > rpm enabled (which is the default) will be handled gracefully. https://github.com/rpm-software-management/rpm/pull/880 added DIGESTALT, apparently to help reduce this CPU usage problem. I don't know if it's actually used by anything, but it is much newer than I'd have guessed (2019 October). > # Disk space requirements are expected to be marginally higher than > before: all new packages or updates will consume their installed size > before installation instead of about half their size (regular rpms > with payloads still cost space). > # rpm-plugin-reflink will fall back to simple file > copying when the destination path is not on the same > filesystem/subvolume. A common example is /boot and/or > /boot/efi. > # The system will still work on other filesystem types, but will > ''always'' fall back to simple copying. This is expected to be > slightly slower than not enabling CoW because the source for copying > will be the decompressed data. Any testing to see the speed impact? > # For systems that enable transparent filesystem compression: every > file will continue to be decompressed from the original rpm, and then > transparently re-compressed by the filesystem. There is no effective > change here. There is a future project to investigate alternate > distribution mechanics to provide parallel versions of file content > pre-compressed in a filesystem specific format, reducing both CPU > costs and I/O. It is expected that this will result in slightly higher > network utilization because filesystem compression is purposely > restricted to allow random I/O. > # Current implementation of dnf-plugin-cow is in Python, > but it looks possible to implement this in libdnf instead > which would make it work in packagekit. > > === Performance Metrics === > > Ballpark performance difference is about half the duration for file > download+install time. A lot of rpms are very small, so it’s difficult > to see/measure. Larger RPMs give much clearer signal. > > (Actual numbers/charts will be supplied in Jan 2021) Seems like a very nice optimization! Thanks for working on it! V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
On Thu, Dec 17, 2020, at 2:05 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing > > > == Summary == > This change should enable an opt-in spec file preprocessor in Fedora > infrastructure for the benefit of packagers. The preprocessor allows > some very neat tricks that were impossible before, for example > generate changelog and release automatically from git metadata or pack > the entire dist-git repository into an rpm-source tarball (effectively > allowing unpacked repos to live in DistGit). > I'm skeptical. If it does pass, I'd insist on having the non-processed spec and any required supporting files in the SRPM. Does this relate in any way to the magic done by rdopkg dist-git <-> source-git translation? Their approach seems very good to me, but might not exactly overlap here. V/r, James Cassell ___ 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: Summary/Minutes for today's FESCo meeting (2020-12-16)
On Thu, Dec 17, 2020, at 6:32 AM, Miroslav Suchý wrote: > Dne 16. 12. 20 v 16:47 Fabio Valentini napsal(a): > > * #2519 F34 Change: GitRepos-master-to-main (decathorpe, 15:09:57) > > * AGREED: APPROVED (+6, 0, -0) (decathorpe, 15:27:51) > > > /me saving you time to read the log for **what** was actually approved: > > 15:19:05 Proposal: Approve proposal to rename branch names > from "master" to "main" except in dist-git-like > repositories with branches matching fedora releases, where "rawhide" is > preferred. > 15:19:43 Where the new default branch will be "rawhide", > create symbolic refs from "main" to "rawhide". > Thanks for clarifying! V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Wed, Dec 9, 2020, at 1:44 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > > == Summary == > > For Nodejs, Fedora should only package: > * The interpreter, development headers/libraries, and the assorted > tools to manage project-level installations (NPM, yarn, etc.). > * Packages that provide binaries that users would want to use in their shell. > * compiled/binary nodejs modules (for now) > Better title would have been, "bundle all nodejs dependencies into binary packages requiring them". It feels contrary to the Minimization Objective. Is there really no better solution? Can modularity help here? Better packaging macros? How will licensing of dependencies be verified? What happens when a project adds new dependencies? V/r, James Cassell ___ 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: Rawhide Repo needs downgradeable packages
On Tue, Dec 8, 2020, at 6:34 PM, Kevin Kofler via devel wrote: > Vít Ondruch wrote: > > As a workaround, if you use `keepcache=True` in dnf.conf, you'd have > > copies of everything you previously installed on your system. > > I still don't understand why this is not the default. Even for stable > releases, because without it, you can easily obtain only the ancient GA > version of the package, which is usually not what you want to downgrade to. > > That said, will "dnf downgrade" offer you cached versions that are no longer > in the repos? Last I checked, it only offered me whatever was still in the > repos, and I had to dig up the cached RPMs manually. > Check out the fedora-repos-archive package. You'll love it! (I certainly do!) V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change proposal: Stratis 2.2.0 (Self-Contained Change)
On Wed, Nov 4, 2020, at 1:12 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Stratis_2.2.0 > > Stratis 2.2.0 now places Stratis filesystem symlinks in /dev/stratis, > rather than /stratis. Stratis creates and maintains the symlinks by > means of udev rules, rather than directly via stratisd as previously. > The /stratis directory is neither created nor used by stratisd 2.2.0. > Thank you! The top level directory had previously made stratis a non-starter for me. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 is available now!
Latest still points to 32, but you can say 33 explicitly and get GA bits. On Tue, Oct 27, 2020, at 11:15 AM, Stanislav Ochotnicky wrote: > On Tue 27 Oct 2020 09:57:40 AM -04 Matthew Miller wrote: > > I'm happy to announce that Fedora 33 is here. Thank you to the > > thousands of people who worked on this release in some way, and to all > > of our community. Fedora 33 is made of bits, but the Fedora Project is > > made of people, and you are all awesome. > > > > Read the official announcement at: > > > > * https://fedoramagazine.org/announcing-fedora-33/ > > > > or just go ahead and grab it from: > > > > * https://getfedora.org/ > > Seems that container images have not been updated yet? > > $ podman run --pull always -it registry.fedoraproject.org/fedora:latest > Trying to pull registry.fedoraproject.org/fedora:latest... > Getting image source signatures > Copying blob 22cef3226003 [--] 0.0b / 0.0b > Copying config e6b57c0d9f done > Writing manifest to image destination > Storing signatures > [root@fb0f4ab6985f /]# cat /etc/fedora-release > Fedora release 32 (Thirty Two) > > > -- > Stanislav Ochotnicky > Software Engineer, Red Hat Product Security DevOps > > PGP: F434 2286 27DC 7D9B 2B64 0866 BCBD 752E 7B08 7241 > ___ > 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: mock, febootstrap, building chroots a.k.a. debootstrap
On Tue, Oct 6, 2020, at 5:42 PM, Daniel Pocock wrote: > > > Hi all, > > I came across febootstrap[1] but it doesn't look like it has been > updated[2] for some time. What is the currently recommended method for > creating a chroot, is it mock or are there alternatives? > yum/dnf handles this natively: yum install --releasever=/ --installroot=/mnt/sysimage bash mypackage > Here is the problem I'm trying to solve: on the Talos II (ppc64) host, > most things run well enough using packages from Fedora 32 or Debian > stable. Sometimes it is necessary to run something from rawhide or > Debian sid in a chroot. > > As an example, I was able to run the latest version of Thunderbird in a > chroot. I'm sure other people will have things like this too. > > In the ideal case, I would like to mix-and-match across distributions > too, for example: > > - create a Debian sid chroot with debootstrap and use it from Fedora 32 > > - create a Fedora 33 or rawhide chroot (with mock?) and use it from Debian > > I create the chroots as Btrfs subvolumes, this gives the opportunity to > create snapshots too. > > After testing this a bit, I'd like to document it some more for other > people on the platform too. I noticed some people losing time trying to > compile things when they could potentially use upcoming versions of the > packages. Any feedback would be very welcome. > The "fastest to get started" way to solve getting these chroots is to pull a container image and extract that. V/r, James Cassell > Regards, > > Daniel > > 1. > https://rwmj.wordpress.com/2009/03/19/febootstrap-fedora-equivalent-of-debootstrap/ > 2. https://src.fedoraproject.org/rpms/febootstrap ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)
On Tue, Sep 8, 2020, at 11:28 AM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
>
> == Summary ==
> Remove support for SELinux runtime disable so that the LSM hooks can
> be hardened via read-only-after-initialization protections.
>
> Migrate users to using ''selinux=0'' if they want to disable SELinux.
>
I like the proposal. A few thoughts and questions, though:
1. I think systems with SELINUX=disabled without selinux=0 should hard fail
very loudly. I've found certain real-time use cases require SELinux to be
disabled to meet the real time guarantees. (Permissive doesn't help because
it's a timing issue, not permission issue.)
2. Does this affect resetting the root password with init=/bin/bash and using
`/sbin/load_policy -i` to avoid a relabel?
3. Generally, forcing things to be cmdline options would benefit from a generic
way to configure and manage them, such as using drop-in snippets. Ideally this
would work the same way across BIOS and UEFI systems. It's difficult to
programmatically manipulate GRUB_CMDLINE_LINUX, which is the current standard
configuration method.
Thanks for putting the security-enhancing proposal forward!
V/r,
James Cassell
> == Owner ==
> * Name: [[User:plautrba| Petr Lautrbach]]
> * Email: plaut...@redhat.com
> * Name: [[User:omos| Ondrej Mosnacek]]
> * Email: omosn...@redhat.com
>
>
> == Detailed Description ==
> Support for SELinux runtime disable via ''/etc/selinux/config'' was
> originally developed to make it easier for Linux distributions to
> support architectures where adding parameters to the kernel command
> line was difficult.
> Unfortunately, supporting runtime disable meant we had to make some
> security trade-offs when it comes to the kernel LSM hooks.
>
> Marking the kernel LSM hooks as read only provides some very nice
> security benefits, but it does mean that we can no longer disable
> SELinux at runtime.
> Toggling between enforcing and permissive mode while booted will
> remain unaffected and it will still be possible to disable SELinux by
> adding ''selinux=0'' to the kernel command line via the boot loader
> (GRUB).
>
> System with ''SELINUX=disabled'' in ''/etc/selinux/config'' will come
> up with ''/sys/fs/selinuxfs'' unmounted,
> userspace will detect SELinux as disabled. Internally SELinux will be
> enabled but not initialized so that there will be no SELinux checks
> applied.
>
> NOTE: Runtime disable is considered deprecated by upstream, and using
> it will become increasingly painful (e.g. sleeping/blocking) through
> future kernel releases until eventually it is removed completely.
> Current kernel reports the following message during runtime disable:
> ''SELinux: Runtime disable is deprecated, use selinux=0 on the kernel
> cmdline''
>
> Additional info:
>
> * https://lwn.net/Articles/666550
> *
> https://lore.kernel.org/selinux/159110207843.57260.5661475689740939480.stgit@chester/
> *
> https://lore.kernel.org/selinux/157836784986.560897.13893922675143903084.stgit@chester/#t
>
> == Benefit to Fedora ==
> Marking the LSM hooks as read-only provides extra security hardening
> against certain attacks, e.g. in case an attacker gains ability to
> write to random kernel memory locations, with support for disable
> SELinux runtime (''CONFIG_SECURITY_SELINUX_DISABLE=y'') they have a
> bigger chance to turn off (parts of) SELinux permission checking.
>
> == Scope ==
> * Proposal owners:
> ** Make sure the kernel is built with
> ''CONFIG_SECURITY_SELINUX_DISABLE'' disabled.
> ** Make sure the relevant documentation is updated in a way that
> ''selinux=0'' on kernel command line is the preferred way to disable
> SELinux.
> ***
> https://docs.fedoraproject.org/en-US/quick-docs/changing-selinux-states-and-modes/
> *** ''selinux(8)'' man page
> ** Make sure [https://github.com/rhinstaller/anaconda/ the installer]
> uses the kernel command line instead of ''/etc/selinux/config'' to
> disable SELinux.
> ** Optional:
> [https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/facts/system/selinux.py
> ''selinux'' Ansible module] should warn that SELinux needs to be
> disabled using ''selinux=0''.
> ** Optional: [https://github.com/linux-system-roles/selinux
> linux-system-roles.selinux] should disable SELinux using
> ''selinux=0''.
>
> * Other developers: N/A
> * Release engineering: https://pagure.io/releng/issue/9742
> * Policies and guidelines: N/A
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> Users should not be directly affected by this change.
>
> == How To Test ==
> # Install a kernel built with ''CONFIG_SECURITY_SELINUX_DISABLE'
[EPEL-devel] Re: Continuing playground discussion
On Fri, Aug 28, 2020, at 6:11 PM, Troy Dawson wrote: > On Thu, Aug 27, 2020 at 2:10 PM Troy Dawson wrote: > > > > On Sat, Aug 22, 2020 at 11:12 AM kevin wrote: > > > > > > On Sat, Aug 22, 2020 at 02:50:39PM -0300, Pablo Sebastián Greco wrote: > > > > > > > > On 21/8/20 19:06, Troy Dawson wrote: > > > > > > > > C) Drop playground. Say it was an interesting experiment and we > > > > > learned stuff, but shut it down. > > > > > (and clean up the package.cfg files as part of shutting it down) > > > > > > > > > > D) > > > > > 1 - Manual builds only. No package.cfg files. No automatic builds. > > > > > 2 - Assume playground depends on epel8. > > > > > 3 - Use CentOS 8 Stream to build against. > > > > > > > > > > I am leaning towards option D. > > > > > We've already got all the playground infrastructure setup. I don't > > > > > want to waste that. So, although I said option C in the meeting, that > > > > > doesn't mean I want it, I was just stating it was an option. > > > > I like option D too, looks like a more polished version of option B > > > > > > Do we have any data here? > > > > > > Are stream changes breaking epel packages so that they need rebuilds > > > often? > > > > > > It will mean that if someone wants to use playground to test some large > > > change in epel, they will have to find people who also enable stream to > > > test it most likely? > > > > > > Do we know that many/any people are consuming stream all the time? > > > > > > We also don't have much way to say 'if you enable epel8-playground you > > > have to enable stream repos also'. > > > > > > I guess I don't think the yummy to trouble ratio is good enough here to > > > justify the trouble of enabling stream. Can you expand on why this is > > > good/what it gets us? > > > > > > > Pros for building against stream: > > - We would have a way to test EPEL packages that matter against the > > not yet released RHEL version. > > -- How often would this matter? > > -- It's hard to say. There might not be a single EPEL package needing > > this for the entire RHEL 8.3 release. > > -- I know for the 8.2 release, I would have liked it so I would have > > had a place to let others test my updated KDE. > > --- But I found a work around, so I didn't have to have it. > > > > Cons for building against stream: > > - I think you've hit on a big thing. For those wanting a major > > change, but don't care about stream, then playground becomes useless. > > -- So this cuts down on the usefulness of playground. Packagers who > > want a major change in their package, and are working on stream. > > - HERE IS THE BIGGEST CON AGAINST USING STREAM > > -- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes > > out. At some point after that, it switches to being based off RHEL9. > > --- This means that infrastructure is going to have to switch > > everything back to being built off RHEL. > > --- We will have to re-document things. > > --- More confusion if we had go the CentOS Stream route. > > > > Troy > > At the EPEL Steering Committee Meeting, this was discussed again. > I believe we all agree that having -playground build off Stream isn't > a good thing. > But we are also concerned about possible library changes in RHEL8 that > might affect EPEL8 packages, and having something based off Stream > would be good. > Here is the proposal. > Note: A) was re-written with better wording than above. > > A) epel8-playground > 1 - Manual builds only. No package.cfg files. No automatic builds. > 2 - Assume playground depends on epel8. > 3 - Built off RHEL8 and CentOS Devel, just like epel8 is built. > > E) epel8-next > 1 - Manual builds only. No package.cfg files. No automatic builds. > 2 - Assume -next depends on epel. > 3 - Built off CentOS Stream. > 4 - Has a limited lifetime that corresponds with the CentOS Stream / > RHEL lifetime. > -- In other words, after CentOS Stream switches from RHEL8 to RHEL9, > then epel8-next get's archived. > > If people are wondering about the name, it was decided to use -next > instead of -stream, due to the overuse of 'stream' among other > reasons. > > Thoughts? Sounds like the perfect solution to me! V/r, James Cassell ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: Proposed Modular Policy for Fedora ELN
; Fedora, we have tested them and they failed. Hence I don't understand what's > more there to test. > > OTOH, why don't just let the ELN SIG do this if it doesn't affect > "Fedora > proper"? Because I think it does. Since the beginning of the ELN > project, it has > been said that it ships Fedora rawhide content, built differently. Yet > if we > ship the default modular streams content in Fedora ELN and the > nonmodular > defaults in Fedora Rawhide, suddenly we ship different things, unless > we have > technical means to ensure the content is synchronized. > I'd propose that any default module stream in ELN should have its packages built only from the "master" branch in dist-git, and should not have any separate branch. This is the item that I did not see in the proposed policy, and a necessary addition, in my opinion. Perhaps with an exception process for software that requires older bulid deps, but even in that case, they should be added as compat packages if at all possible. > When the ELN proposal was discussed, several package maintainers (both from > Fedora and RHEL) proposed to have an eln branch. It received a big NO because > the content would diverge and keeping it in sync would be (close to) > impossible. > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/44MCFHOFORTPNJFGK6JJ6YMAHFUT7QG3/ > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WRJNM7I5TFQ5TEBOUKKH757K5ME3I47F/ > ..and many times more... > > Fedora ELN should not be a fork. Yet (some of the) default content of > Fedora ELN > would be built from modules, which packages built from different > branches. > Has the objective been changed? Is having separate branches for Fedora > and > Fedora ELN no longer a big NO? What changed? > > I am worried about the divergence between Fedora and Fedora ELN. I am > worried > about certain maintainers only maintaining their modules without > upgrading > packages in rawhide -- and a need of a large volunteer-driven effort to > backport > improvements and fixes from modules to nonmodular packages: From Fedora > ELN to > Fedora. This seems wrong to me, as I've always considered Fedora to be > the > upstream of RHEL (and by extension of Fedora ELN) rather than > downstream. > Similarly, I'd argue that ELN shouldn't have default content that isn't also available by default in Fedora. this would likely be solved by my suggestion above for default modules to use only the master branch. > When I expressed this concern in the "RHEL 9 and modularity" thread, > the > discussion went nowhere: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PQX75DGRIICQLG5KBOY4HTOFFYZVWP6K/ > > (and replies) > > > I believe that allowing default modular streams in any Fedora project > is a bad > thing to do before the technology sees large design-level changes. I > believe > that RHEL completely ignoring Fedora's feedback is a very sad thing to > happen. I > believe that having default modular streams in ELN will negatively > affect > general Fedora packagers. But I realize that this is juts one person's > opinion. > At FESCo, I try to represent the opinion of Fedora package maintainers, > not just > my own. Hence I am sharing my concerns here to hear feedback from > others. > I appreciate your efforts here! Thanks for raising the concerns. They echo my own. V/r, James Cassell ___ 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: Proposed Modular Policy for Fedora ELN
As general feedback, the footnotes make it hard to read the rendered version of the document, forcing me to scroll up and down. More comments below. On Wed, Aug 5, 2020, at 3:36 PM, Stephen Gallagher wrote: > * If a stream of a module has build-time-only components, all such > components *MUST* be marked as `buildonly: True` in the module > metadata to avoid shipping them to users and polluting their > repository. > Can these be directed to a disabled-by-default build-dep repo of some kind for those trying to do local builds? Do these "non-shipped" packages shadow non-modular versions of the same packages? > == Requirements for Default Streams I'd propose an alternative to Default Streams. Any package part of a default stream should instead be auto-built in a given release where the stream is marked as default. Pushes to the dist-git branch for that release would be blocked by all but the auto build bot, and all changes should be made to the stream branch. The stream marked "default" for the particular module would be enabled as a buildroot override, including build only packages, for such automated non-modular rebuilds of streams marked "default". This would obviate the need of stream transition, except in cases if inter-module deps. Even given the status quo, I'd argue that streams enabled by nature of being Default rather than being explicitly enabled, should not shadow non-modular packages. As-is today, third party repos are marking themselves as module_hotfixes to skip the shadowing issues. > * Default streams are not permitted in Fedora or EPEL 8. Fedora ELN > permits defaults streams that adhere to the policy below. Say EPEL, don't mention version. > * Default streams *MUST NOT* provide a binary RPM with the same > package name as an RPM in a default stream in the same release except "default stream of another module" > in the case of a transition from one to the other.footnote:[In this > situation, whichever has the highest NEVRA would win the depsolving > and could break the other module.] V/r, James Cassell ___ 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-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
On Sun, Jul 12, 2020, at 4:07 PM, Kevin Fenzi wrote: > On Sun, Jul 05, 2020 at 02:15:23PM +0200, Nicolas Mailhot via devel wrote: > > Le mercredi 01 juillet 2020 à 12:27 +0200, Dominik 'Rathann' > > Mierzejewski a écrit : > > > > > > > To get beautiful changelogs, you also need to add > > > > > > > > > > > > %buildsys_name Your name > > > > %buildsys_email Your email > > > > > > > > > > > > in ~/.rpmmacros > > > > > > What about having one macro called %buildsys_packager instead of two? > > > You're always using them together, anyway. It'd be similar to the > > > existing %packager macro, too. > > > > This is now done in the latest code refresh and in the test copr > > https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/bc4e6a79355f3a2b73abeea7e5c0e1f53b09579e?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump > > https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/ > > > > I fleshed out the change page a little too > > https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping > > So I finally carved out a few minutes to look at this, but... > > https://copr-dist-git.fedorainfracloud.org/cgit/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/sil-charis-fonts.git > seems to not exist? Is that some copr issue? > I've been unable to clone COPR dist-git for quite some time. Seems it's broken from outside COPR itself... V/r, James Cassell ___ 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: PSA: dnf autoremove cleans fedora-repos-modular
On Thu, Jul 9, 2020, at 10:36 AM, John M. Harris Jr wrote: > On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote: > > DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on > > a system upgrade, because we want that package to be prensented on the > > system. However I worry that DNF does not possess a capability for doing > > it. (Except of injecting that command into some externally executed > > script.) > > Unless I'm mistaken, it should only be present if the user manually installed > it, and opted into modularity, right? > The agreement by FESCo was to have it as an optional component, but installed by default, IIUC. It should be added to the relevant comps groups, but I think 'yum upgrade' needs to also learn about upgrading groups. (Side note, this is another example of where the 'yumdb' command would come in handy if there were a dnf equivalent; I wouldn't have been able to do those sqlite queries myself.) V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Tue, Jul 7, 2020, at 12:30 PM, Adam Williamson wrote: > On Mon, 2020-07-06 at 20:06 -0600, Chris Murphy wrote: > > On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen wrote: > > > > > > On Wed, 1 Jul 2020 14:24:37 -0400, you wrote: > > > > > > > On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew J?drzejewski-Szmek > > > > wrote: > > > > > Making btrfs opt-in for F33 and (assuming the result go well) opt-out > > > > > for F34 > > > > > could be good option. I know technically it is already opt-in, but > > > > > it's not > > > > > very visible or popular. We could make the btrfs option more > > > > > prominent and > > > > > ask people to pick it if they are ready to handle potential fallout. > > > > > > > > I'm leaning towards recommending this as well. I feel like we don't have > > > > good data to make a decision on -- the work that Red Hat did previously > > > > when > > > > making a decision was 1) years ago and 2) server-focused, and the > > > > Facebook > > > > production usage is encouraging but also not the same use case. I'm > > > > particularly concerned about metadata corruption fragility as noted in > > > > the > > > > Usenix paper. (It'd be nice if we could do something about that!) > > > > > > So if one has a spare partition to play with btrfs, is there an easy > > > way to install a second copy of Fedora without having the /boot/efi/ > > > entries overwrite the existing Fedora installation? Or fix it to have > > > 2 separate entries after the fact? > > > > > > It's possible but has challenges. Separate ESP's you'll need to either > > (a) use the firmware's built-in boot manager to choose what will > > probably appear to be identically named Fedora's > > No, you have to rename the first one before doing the second install. > anaconda explicitly deletes any existing efibootmgr entry named > "Fedora" before creating a new one. Any idea if this process is documented? I typically install on a laptop, with the "encrypt my data" option. I can confirm that the only way to successfully have 2 side-by-side Fedora installs with UEFI, using only Anaconda to set it up, is to have 2 separate physical disks, and choose which physical disk to boot by hitting F12 at machine power on. Any attempts to share /boot result in at least one of the installs being broken. Any attempts to share /boot/efi breaks at least fedora-by-fedora installs. Adding a separate /boot/efi partition for the second Fedora install makes the resulting system usable on the new Fedora install, but there is no obvious way to boot into the older Fedora install. If you unlock the disks within Anaconda for the existing Fedora install, grub gets boot entries for that install, but they are non-functional. (No password is prompted for unlocking the disk, indefinite hang.) What /does/ seem to work is having RHEL and Fedora side-by-side on the same disk, as long as each has its own /boot and /boot/efi partitions. Generally, I'd like the fedora-by-fedora parallel installs to work better because that's how I'm best able to participate in the Test Matrix. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Wed, Jul 1, 2020, at 9:43 PM, Neal Gompa wrote: > On Wed, Jul 1, 2020 at 9:27 PM James Cassell > wrote: > > > > > > On Wed, Jul 1, 2020, at 9:03 PM, Przemek Klosowski via devel wrote: > > > On 7/1/20 3:50 PM, Josef Bacik wrote: > > > > This sounds like a "wtf, why are you doing this btrfs?" sort of thing, > > > > but this is just the reality of using checksums. It's a checksum, not > > > > ECC. > > > > > > Yes, exactly---why isn't it ECC? Wouldn't it work better, especially in > > > the context of faulty hardware? > > > > > > I do realize it would require changing the on-disk format, and maybe > > > slow the critical path... > > > > > > > Or maybe make all metadata raid 1, even on single disk set up? > > > > Not that isn't interesting, but what would be the mirror target on a > single disk setup? > The idea is that the second copy of metadata on the same disk might be readable in case the first copy has a checksum error, in case of fault hardware. I haven't tried it, but I'd gladly give up a little space for more robustness, especially if btrfs is sensitive to metadata corruption by the hardware. If btrfs demands a separate device for raid1 metadata, I wonder if a small 1G partition could be dedicated for purely mirrored metadata use. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Wed, Jul 1, 2020, at 9:03 PM, Przemek Klosowski via devel wrote: > On 7/1/20 3:50 PM, Josef Bacik wrote: > > This sounds like a "wtf, why are you doing this btrfs?" sort of thing, > > but this is just the reality of using checksums. It's a checksum, not > > ECC. > > Yes, exactly---why isn't it ECC? Wouldn't it work better, especially in > the context of faulty hardware? > > I do realize it would require changing the on-disk format, and maybe > slow the critical path... > Or maybe make all metadata raid 1, even on single disk set up? V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Mon, Jun 29, 2020, at 6:57 PM, Markus Larsson wrote: > On Mon, 2020-06-29 at 18:51 -0400, James Cassell wrote: > > On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote: > > > Why not Stratis? > > > > Stratis cannot be used to build the root filesystem. (It's been > > answered elsewhere in the thread.) > > Are we sure? > https://github.com/stratis-storage/stratisd/issues/635 > While it might not be super there yet it seems it is technically > working (I may be wrong I have done 0 tests). > But given how new that is and that tolling around it isn't there it > pretty far from being a viable default. > Indeed, a comment there says, "Yes this should work for root fs. No write up has been done other than what is mentioned in this issue already." So the stratis folks say it's possible. I'd say it's safe to say there's no Anaconda installer support for it (yet?), though... Once upon a time, I opened a Red Hat case asking how to use stratis for boot and they provided nothing useful. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Tue, Jun 30, 2020, at 10:18 AM, Steven Whitehouse wrote: > I know it has been rather confined to Red Hat internally, however that > was not the intention, and in fact I would like to strongly encourage > community involvement. There is an upstream mailing list, which > currently has almost no traffic: springfi...@sourceware.org so please > do join and ask questions, if anybody is interested in finding out more. > Indeed, this is the first I've heard of "Project Springfield" -- it looks like the list only had a couple of messages at its start in 2018 and nothing since. https://springfield-project.github.io/ The "subscribe" link is broken... it should probably point to https://sourceware.org/mailman/listinfo/springfield I'd send a pull request, but I couldn't find the github repo associated with the page. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote: > Why not Stratis? Stratis cannot be used to build the root filesystem. (It's been answered elsewhere in the thread.) V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
On Thu, Jun 25, 2020, at 4:03 PM, Neal Gompa wrote:
> On Thu, Jun 25, 2020 at 3:41 PM Ian McInerney
> wrote:
> >>
> >> ...snip...
> >> == Scope ==
> >> * Proposal owners:
> >> ** Modify comps to include nano Fedora wide.
> >> ** Create a new subpackage of nano, called
> >> nano-editor.
> >> ** nano-editor to include
> >> /usr/lib/environment.d/10-nano.conf, which sets
> >> $EDITOR to nano.
> >>
> >> With this approach, if nano is uninstalled, the
> >> configuration will be removed with it. At the same time, installing
> >> nano on its own won't install the conf.
> >>
> >
> > Are you sure this will work? I just ran a test, and putting a new config
> > file inside /usr/lib/environment.d only works for Gnome, and doesn't work
> > for Mate, Cinnamon or SSH (tested by opening a terminal in the respective
> > session and examining the environment variables). From what I gather in
> > [1], systemd is not a standard way of interacting with the user's
> > environment variables, and only Gnome has decided to use it. So this method
> > of implementing this change seems to be making the default editor for Gnome
> > be nano and not changing the defaults for anyone else.
> >
>
> We might want to do this as a profile.d snippet for all the major
> shells: bash/ksh, zsh, csh, and fish. That should work basically
> everywhere, afaik.
>
I'd be -1 on the change, but if it's going to happen anyway, it should
absolutely be done via an /etc/profile.d entry. Most likely would be
sufficient to have /etc/profile.d/nano.{sh,csh} to cover most or all the shells
out there, IIUC. I'd have never looked for this in /usr/lib/environment.d --
in fact, today is the first time I'd heard of this directory!
V/r,
James Cassell
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL 9 and modularity
On Wed, Jun 24, 2020, at 3:37 AM, Petr Pisar wrote: > On Wed, Jun 24, 2020 at 06:51:36AM +, Zbigniew Jędrzejewski-Szmek wrote: > > Yes. Putting the "stream identification" into the package name is the > > most natural solution, and has been floated various times. > > This already happens. But not in Fedora. In RHEL, modular packages have > Modularitylabel RPM tag that carries the module name and stream. > It's too bad this isn't exposed in `rpm -qi` output. Is there a way to query the Modularitylabel RPM tag on an installed system? V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
On Tue, Jun 16, 2020, at 9:16 AM, Kevin Kofler wrote:
> Michael Catanzaro wrote:
> > Kevin, the goal is to *simply* these packages:
> >
> > mkdir -p %{_target_platform}
> > pushd %{_target_platform}
> > %cmake
> > popd
> >
> > It's four lines. We get to simplify it down to one line. Proposal
> > owners are provenpackagers and say they will try to fix affected
> > packages. Fine by me?
>
> In the real world, it will end up as:
>
> %if 0%{?fedora} > 32 || 0%{?rhel} > 8
> %cmake
> %else
> mkdir %{_target_platform}
> pushd %{_target_platform}
> %cmake ..
> popd
> %endif
>
If you're doing this, might I suggest reversing the condition so the new way is
in the "else" part, hence "default"? I've run into issues rebuilding packages
because there was such a condition from a decade ago and I didn't have %fedora
defined because I was trying to build it for another distro. (Common issue
amongst the ruby packages.)
V/r,
James Cassell
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package
On Tue, Jun 16, 2020, at 5:57 AM, Vít Ondruch wrote: > > Dne 16. 06. 20 v 11:04 Miro Hrončok napsal(a): > > On 16. 06. 20 10:03, Panu Matilainen wrote: > >> Yeah it's a hard dependency of fedora-release-common. I suppose one > >> possibility would be adding a recommends on fedora-repos-modular to > >> fedora-release-common, but weak dependencies have an annoying > >> tendency to creep back in when you're not looking, a kickstart/comps > >> defaults are nicer in that regard. > > > > I was originally thinking that fedora-repos should recommend > > fedora-repos-modular, but due to the annoying nature of getting > > recommends back on every upgrade of the related package I abandoned > > the idea. > > > > Relevant dnf bugzilla: > > https://bugzilla.redhat.com/show_bug.cgi?id=1699672 > > > > Not mentioned that weak dependencies are disabled in Mock. > I can't decide whether that's a bug or a feature... V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages
On Mon, Jun 15, 2020, at 6:07 PM, Kevin Fenzi wrote: > On Mon, Jun 15, 2020 at 03:47:33PM -0400, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages > > ...snip... Please not using mechanism. Make it easy to opt out, or better yet opt-in. Probably better to just advertise `yum list extras` which has existed since at least Fedora 12. > > > If the user wants to preserve the package (e.g., because it moved to > > Copr), he simply uninstalls and protects the installation of > > fedora-retired-packages. But that will be an informed decision. > > How is this discoverable? It's already really unclear that > fedora-obsolete-packages should be excluded if you want to keep obsolete > packages. :( > Agreed. We should kill the auto destruct on this package. It makes it very confusing why something it's being removed. Or at least make it obvious in the output why things are being removed. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sun, Jun 7, 2020, at 9:30 PM, David Kaufmann wrote: > On Sun, Jun 07, 2020 at 05:25:15PM -0600, Chris Murphy wrote: > > >> At 150% memory usage assuming a 2:1 compression ratio this would mean: > >> - disk swap: > >> has to write 4G to disk initially, and for reading swap another 4G > >> (12G total traffic - 4G initial, 4G swapping out and 4G swapping in) > >> - zram, assuming 4G zram swap: > >> has to write 8G to zram initially, and for reading the data swap 16G > >> (24G total traffic - 8G initial, 8G swapping out and 8G swapping in) > > > > swap contains anonymous pages, so I'm not sure what you mean by > > initial. Whether these pages are internet or typed in or come from > > persistent storage - it's a wash between disk or zram swap so it can > > be ignored. > > I was calculating it from the viewpoint of data, e.g. paging out a > certain amount of data, and paging it in again. "Initial" would be the > amount of data when paging in. > What is definitely different is that I thought of 1 or 2 processes > eating away memory, but not of many thrashing swap. For those it is > definitely not possible to recover from it once thrashing has started. > > > Also I don't understand any of your math,how you start with a 4G zram > > swap but have 8G. I think you're confused. The cap of 4GiB is the > > device size. The actual amount of RAM it uses will be less due to > > compression. The zram device size is not the amount of memory used. > > And in no case is there a preallocation of memory unless the zram > > device is used. It is easy to get confused, by the way. That was my > > default state for days upon first stumbling on this. > > I assumed a 2:1 compression rate, so the zram swap holds 8G of data in a > 4G zram device. I've calculated with filling the zram device to the > max, so it will use the full 4G. (the 4G limit was arbitrarily chosen) > A 4G zram device is 4G apparent size. The amount of memory it takes will vary based on the compression, but in no case take more than 4G memory. The max uncompressed data that can be put in a 4G zram device is 4G of data. V/r, James Cassell ___ 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: Does the installer detects when a distro have already created BLS?
On Sun, May 24, 2020, at 9:39 PM, Chris Murphy wrote: > On Sun, May 24, 2020 at 6:42 PM Paul Dufresne via devel > wrote: > > > > Le 20-05-24 à 19 h 34, Naheem Zaffar a écrit : > > > The change record for this states that we are not following the BLS at > > > https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ but > > > the proposed update at > > > https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ . > > > > Thanks for remembering me this alternative specification! > > > > That said, Fedora does not seems to follow this alternative spec, > > because we use: > > > > $BOOT/loader directory, and not $BOOT/org/freedesktop/bls directory as > > indicated in this standard. > > > > The point is that as the $BOOT is shared among distributions, there must > > be a way to detect if it is already there, to be able to re-use it. For > > that, the specification (whatever the exact version if chosen) must be > > relatively well followed. > > Yep. > > But an additional difficulty to fully implementing the spec is so far > upstream GRUB don't want to follow it. So that means Fedora has to > carry patches for GRUB to support it. And it's just yet another of > 100+ patches Fedora carries for GRUB, and makes it difficult for the > Fedora and RH boot teams. The resources so far implement some of the > parts of BLS that help make things better on Fedora, but it's not a > complete implementation. Drop-in snippets to add new kernels is crash > safe, worst case the previous kernel is booted and you just reinstall > the kernel; but writing out a new grub.cfg or modifying it, wasn't > ever crash safe. Also, modifying the snippets is easier, they're just > a few lines and fairly self-describing compared to what users often > did, which was wade neck deep into editing grub.cfg. Or the Rube > Goldberg machine that is editing /etc/default/grub, running a script > (grub-mkconfig), which then runs 20 other scripts to create a > configuration file that is actually a script. > Even so, isn't the canonical way of persistently updating kernel args, still, to edit /etc/default/grub and run the script? (If not, are there docs for the new way?) V/r, James Cassell ___ 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: Does the installer detects when a distro have already created BLS?
On Sun, May 24, 2020, at 7:06 PM, Paul Dufresne via devel wrote: > Well... I will try to repeat more clearly my claim: > > If Fedora want to pretend to implement the Boot Loader Specification, > it must, on a new disk formatted in GPT, end up with an entry in fstab > for an ESP partition mounted on /boot: > > "These directories are defined below the placeholder file system $BOOT. > This placeholder file system shall be determined during installation > time, and an fstab entry for it shall be created mounting it to /boot." > > ... > > "if the OS is installed on a disk with GPT disk label, and no ESP > partition exists yet, a new suitably sized (let's say 500MB) ESP should > be created and should be used as $BOOT" > > This is the rule you are supposed end up to follow for an empty GPT partition. > > And for now, the installer seems to make you define a specific > /boot/efi that it make ESP. To follow BLS, it should be /boot that is > the ESP partition... and I see no point to define an other /boot/efi > partition to be mounted on /boot. > I agree with your assessment and am also confused about the discrepancy between BLS documentation and Fedora's implementation. V/r, James Cassell > ... > > "`$BOOT` must be a VFAT (16 or 32) file system. Other file system types > should not be used. Applications accessing `$BOOT` should hence not > assume that fancier file system features such as symlinks, hardlinks, > access control or case sensitivity are supported." > > > ___ 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: Re-Launching the Java SIG
On Wed, May 13, 2020, at 5:04 PM, Ty Young wrote: > > On 5/13/20 12:04 PM, Robbie Harwood wrote: > > Ty Young writes: > > > >> On 5/12/20 5:55 AM, Felix Schwarz wrote: > >>> Am 12.05.20 um 12:32 schrieb Ty Young: > >>> > >>>> Right, I figured it was some Fedora policy and not up to you. I > >>>> suppose I should have been more clear there. Sorry for any > >>>> confusion, it was aimed at the Fedora project as a whole as this is > >>>> a Fedora issue. > >>> This is not a Fedora issue but a consequence of Fedora's core > >>> values. You not agree with it but "building from source" is so > >>> fundamental that it does not make sense to even start a discussion > >>> about it on fedora-devel. > >>> > >>> I suggest you read up on the rationale behind that policy (which is > >>> why I linked the policy document in the first place). > >>> > >>> I understand that missing components/features due to the source > >>> requirement are annoying but Fedora (and other distros) decided to > >>> take the "high road" here and actually fix stuff instead of shipping > >>> whatever upstream came up with. > >> As someone who has been burned due to Fedora's goody little two shoes > >> policies, I'd kindly ask that Fedora take a hike and not package the > >> software at all. > > This is not "being excellent to each other". Let's keep in mind that we > > are all here for the same reason (caring about Fedora), and that this > > makes us colleagues - even when we disagree. > > > Neither was the threat and intimidation by higher ups at Red Hat or > Fedora, which very few people on this seem to care about despite > constantly bringing up the CoC. Selective enforcement probably isn't > "being excellent to each other" either. > > > Anyway, I'm just asking that Fedora not repeat what Debian did. While I > find it to be a bit paranoid, I understand the concerns regarding > someone sneaking in malware into pre-build binaries. I'm just asking > Fedora not package the software at all in that case, or any software > that depends on that software if possible. People who want to support > Linux by writing software shouldn't be bothered with bug reports from > issues they never created to begin with. > Is your position that Fedora should not package any software where the Upstream provides binaries? If so, that would seem to defeat the purpose of a Linux distribution, IMHO. V/r, James Cassell ___ 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: CPE Weekly: 2020-05-11
On Mon, May 11, 2020, at 4:40 AM, Aoife Moloney wrote: > # CPE Weekly: 2020-05-11 > --- > title: CPE Weekly status email > tags: CPE Weekly, email > --- [snip] > > Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ > On my mobile device, this URL shows status from March. Am I doing it wrong? V/r, James Cassell ___ 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 pagure confusion wrt EPEL
On Mon, May 4, 2020, at 7:35 PM, Michael Schwendt wrote: > > This incident turns into a growingly unpleasant experience for me. > > I've asked you to clean up the mess in bugzilla and reassign the EPEL > > packages properly, because I am not responsible for those packages. > > You've not done that. I've had to do it myself. Team work doesn't mean > > that you assign tickets to me, which have been neglected/ignored for > > almost five years. This isn't a hot-potato-dropping contest. > > Can this stop, please? > > Again somebody has used a script to assign bugzilla EPEL tickets to me > again, although I am not responsible for the EPEL packages and have never > been responsible for them. > > I feel offended. > > Whoever is behind this, *please* stop! > > Example: > https://bugzilla.redhat.com/show_bug.cgi?id=1293581 > Looks like some automation, not attributed to a person: Fedora Admin user for bugzilla script actions 2020-05-04 17:04:23 UTC Assignee extras-orphan bugs.michael I'm sure someone knows... V/r James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Node.js 14.x by default
On Mon, May 4, 2020, at 5:39 AM, Miro Hrončok wrote: > On 04. 05. 20 10:51, Petr Pisar wrote: > > On Sat, May 02, 2020 at 02:01:43AM +0200, Miro Hrončok wrote: > >> On 01. 05. 20 22:21, Ben Cotton wrote: > >>> == Detailed Description == > >>> Fedora 33 will ship with the latest LTS version of Node.js by default. > >>> This will either be the `nodejs:14` module stream or else replicated > >>> to the non-modular repository, depending on the status of other > >>> release engineering work around supporting modular content in the > >>> non-modular buildroots. > >> Since default modular streams are banned, > > Indeed? I thought that they are not banned, they only need a FESCo approval. > > Indeed: > > https://pagure.io/fesco/issue/2341#comment-628267 > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5DIMII3GR6YT7JJ4XII6AF2JSI24ZTLV/ > > Should we be more loud about his? > It's a welcome change, and I hadn't heard about it. An announcement seems appropriate. V/r, James Cassell ___ 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: CPE WEeekly: 2020-05-02
On Sun, May 3, 2020, at 1:40 PM, Aoife Moloney wrote: > # CPE Weekly: 2020-05-02 > --- > title: CPE Weekly status email > tags: CPE Weekly, email > --- > > > > > Background: > The Community Platform Engineering group is the Red Hat team combining > IT and release engineering from Fedora and CentOS.Check out our teams > info here https://docs.fedoraproject.org/en-US/cpe/ > > > ## GitForge Updates > * We are tracking our progress here (nothing new added yet, fyi) > https://fedoraproject.org/wiki/Git_forge_update > * We are still doing a technical deep-dive with our own team on what > we need from GitLab and will have a technical plan developed and > publically available in the coming weeks - thanks again for your > patience, this will take some time to map out. > * Fedora have also released a blog post > https://communityblog.fedoraproject.org/fedora-council-and-the-git-forge/and > * And the council are tracking the community issues in this ticket > https://pagure.io/Fedora-Council/tickets/issue/292 > * We are looking at ways to engage closer with the community too so I > will have an *optional* office hours slot on #fedora-meeting @ > 1400-1500 UTC every Thursday. Feel free to stop by and say hi! We can > talk about Gitforge, or not :) > > > ## Releases!! > * F32 released! Congrats to all those who helped make this such an > awesome release :) > * Lenovo are releasing Fedora as a standard desktop offering! > * CentOS 7.8.2003 was released for x86_64, aarch64,ppc64, ppc64le and > armhfp architectures, including Cloud images (on > https://cloud.centos.org)! > > > > > > ### Data Centre Move > * Communishift is still out, est back online 11th May. > * Full amended schedule will be published week ending 8th May to > hackmd & will be sent to the devel & infra lists. > * Connectivity is now in place in IAD2 and should be in place in > RDU-CC over the weekend. > * In particular, a HUGE shout out to Stephen Smoogen who has been > working all the hours in every day for the last few weeks/months to > get this phase of the move operatoinal for the Fedora infrastructure - > we would not be able to do this without you Smooge :) > * This is literally a two man team of Kevin Fenzi and Stephen Smoogen, > who are carrying the weight of this infrastructure on their shoulders > and are invaluable to the success of this multi-team and multi-month > project, so thank you both. > * Given the pressures on the Infra folks, a general ask for patience > if your ticket / request / ping takes a little bit longer to reply to > > > > ### AAA Replacement > * The team will work with openSUSE to deploy FreeIPA + Noggin to > deploy it in their infra before we do! > * This is really exciting and the team are looking forward to seeing > how the solution works in another infrastructure! > * You can view the teams current, completed and backlog work here > https://github.com/orgs/fedora-infra/projects/6 > > > > ### Sustaining Team > * The team are using this dashboard to track their work > https://github.com/fedora-infra/mbbox/projects/1 > > * Mbbox Upgrade > * Zuul CI set up is done > * Koji-hub TLS support added to CR > * Set up ReadTheDocs documentation - webhook missing for automatic build > * Identity container for testing > * Koji-builder CRD PR rebase - SSL authentication with koji-hub > * Refactor molecule test suite to share tests > > > > > > > > ## CentOS Updates > > ### CentOS CI > * OpenShift upgrade > * OpenStack to OpenNebula migration scripts > * Ansible playbooks to manage the creation and bootstrapping of > bare metal nodes with RHCOS > * Packaging work (fixing dependencies) > * Updated ci-user list on efforts we are putting for CI Infrastructure > > ### CentOS > * CentOS 7.8.2003 was released for x86_64, aarch64,ppc64, ppc64le and > armhfp architectures. Including Cloud images (on > https://cloud.centos.org) - > https://blog.centos.org/2020/04/release-centos-linux-7-2003/ > > > ### CentOS Stream > * Congratulations to Brian Stinson on his excellent session of Ask The > Expert, facilitated by Rich Bowen during Red Hat Summit - we hope you > caught it, it was really good! > * Using CentOS Stream in the CentOS QA group to prep for 8.2 > > > > > As always, feedback is welcome, and we will continue to look at ways > to improve the delivery and readability of this weekly report. > > > Have a great week ahead! > > Aoife > > > Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ > Still out of date. V/r, James Cassell ___ 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+Lenovo
On Fri, May 1, 2020, at 8:48 AM, Alexander Ploumistos wrote: > On Fri, May 1, 2020 at 2:38 PM James Cassell > wrote: > > > > > > On Fri, May 1, 2020, at 8:07 AM, Alexander Ploumistos wrote: > > > One thing that I'd like to see, is linux support for the "energy > > > manager" features - it's pretty much the only reason I've allowed > > > > This "just works" on F32 for me using the tlp package to set charge > > thresholds. The only thing acpi_call is needed for is recalibration, which > > I don't do often. > > I had read this disclaimer on tlp's website, so I never gave it a try: > > * Battery charge thresholds, discharge and recalibration are currently > only supported for IBM/Lenovo ThinkPads > * Any other Lenovo laptop models including IdeaPads and all other > laptop brands are not supported > > Are you using it on a non-ThinkPad model? > I'm using a ThinkPad. V/r, James Cassell ___ 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+Lenovo
On Fri, May 1, 2020, at 8:07 AM, Alexander Ploumistos wrote: > Hi Mark, > > And welcome aboard. > I've been using a tweaked Legion Y520-15IKBN for a year and a half now > and I'm a happy camper. I can't say that I understand hardware > vendors' marketing decisions, like putting a heftier price tag on a > "professional" machine, whereas a "gaming" laptop with the same specs > costs almost 1000€ less, but this particular Legion model line is > pretty inconspicuous, so you can work anywhere, without people > staring. > > One thing that I'd like to see, is linux support for the "energy > manager" features - it's pretty much the only reason I've allowed This "just works" on F32 for me using the tlp package to set charge thresholds. The only thing acpi_call is needed for is recalibration, which I don't do often. V/r, James Cassell > windows to take up space on my laptops and I know I'm not the only > one. I think that someone had written a kernel module that somehow > managed to communicate with the battery controller, but since it's out > of tree and we get quite a lot of kernel updates in Fedora, it's no > fun rebuilding everything every 2-3 days. Is that something that's > pretty standard among different model lines? > > Oh and another thing, which is a peeve with laptop keyboards in > general. I make full use of pretty much every key on a standard > keyboard and I usually map the compose key to scroll lock, which I use > a lot. Whenever I have to move to a laptop, I feel like someone has > chopped off one of my limbs and seeing dedicated keys for things like > recording and streaming one's gaming session drive me mad. About a > decade and a half ago, there were distributions that offered a > rudimentary UI to do key remapping, but along the way, as linux went > through different methods to manage input devices, that sort of thing > was dropped. Now that evdev seems to be with us for the foreseeable > future, is there any chance you might consider such a feature, perhaps > in collaboration with GNOME? Even if it's something buried under 15 > menus in Tweaks, I'd be happy. > > Best regards ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [External] Re: Fedora+Lenovo
On Fri, May 1, 2020, at 7:25 AM, Solomon Peachy wrote: > On Fri, May 01, 2020 at 03:36:09AM +, Mark Pearson wrote: > > I'm also quite fond of my AMD T495. It's a platform that has given me > > minimal headaches > > Yeah, one of those is my daily driver. > > My only real complaint has to do with the placement of the "PrtSc" key. > I accidentally take several screenshots every day.. Otherwise it's a > great machine to run Fedora on. > Agreed. I really want that key to be the menu key, with Fn to be PrtSc. (And overall, bring back the ThinkPad 25 keyboard, but that'll never happen.) V/r, James Cassell ___ 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: Block discard on more things
On Tue, Apr 28, 2020, at 6:51 PM, Chris Adams wrote: > Now that Fedora 32 has fstrim.timer enabled by default... how about > discards for the things that fstrim doesn't get? Two main things I know > of: > > - swap: Do discard at swapon time by setting "discard=once" in > /etc/fstab would be somewhat similar to the periodic fstrim call. I > don't know how much impact the "discard=pages" option might have (the > man page says it is asynchronous, but it might make low-memory > situations worse). > Seems reasonable. > - logical volumes: Set "issue_discards = 1" in /etc/lvm/lvm.conf so that > removed LVs get discarded. > Could foreclose data recovery in case LV was removed entirely, so I'd leave it to fstrim.timer on the eventual filesystem. V/r, James Cassell ___ 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: CPE Weekly: 2020-04-26
On Sun, Apr 26, 2020, at 11:12 PM, Kevin Fenzi wrote: > On Sun, Apr 26, 2020 at 08:47:51PM -0400, James Cassell wrote: > > > > What's Kojira? > > Its a process run by koji (The fedora buildsystem) that manages > buildroots. It keeps track of the buildroots that need regerenation, > makes sure not too many are regenerated at once and deleting old > builroot repos when they are no longer needed. > > If you build foo and need it in the buildroot to build bar, kojira is > the thing that notices foo built and that the buildroot needs updating, > fires off that update process (when resources are available for it). > Cool. Thanks for the explanation! (I'd never heard of it before.) V/r, James Cassell ___ 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: CPE Weekly: 2020-04-26
On Sun, Apr 26, 2020, at 1:13 PM, Aoife Moloney wrote: > # CPE Weekly: 2020-04-26 > --- > title: CPE Weekly status email > tags: CPE Weekly, email > --- > > > > > Background: > The Community Platform Engineering group is the Red Hat team combining > IT and release engineering from Fedora and CentOS.Check out our teams > info here https://docs.fedoraproject.org/en-US/cpe/ > > > ## GitForge Updates > * We will be tracking our progress here > https://fedoraproject.org/wiki/Git_forge_update > * Please be aware this does not contain any new information, as we > don't have any to share yet. > * However once we have more information for you, we will be posting it > to the above link, and with the URL in the weekly emails for quick > access. > * We are currently doing a technical deep-dive with our own team on > what we need from GitLab > * We are also still engaging with Fedora Council who are tracking the > Fedora Communities needs here > https://pagure.io/Fedora-Council/tickets/issue/292 > * And we are looking at ways to engage closer with the CentOS > community too to share information as and when we have it > * Public Q sessions are still being discussed to allow for open > conversations in public forums too as we move through this journey, so > thank you for your patience with us. > > > > ## Fedora Updates > * F32 release is a Go! > * Estimated release date is April 28th - well done to everyone involved! > > > > > > ### Data Centre Move > * Due to Covid-19 restrictions at each datacentre, we have > unfortunately experienced a delay during the initial move. > * The need to push out our dates by 2-3 weeks was made necessary on > Thursday 23rd April, following meetings with Red Hat IT on network > connectivity status and estimate connection times for our team to > access the new datacentre. > * We will need to adjust our outage schedule and move schedule to > properly reflect the new dates of services being turned off and > reduced, and the full amended schedule will be published to hackmd, > with emails sent to the devel-announce & infra lists next week (week > ending 1st May) > * We will also include links to the updated move schedule and service > impact schedule in next weeks CPE Weekly > * Please be aware that CommuniShift is now down indefinitely until > earliest May 8th. > > > ### AAA Replacement > * The team have begun phase two of the project and you can view their > board for more technical information on their work here > https://github.com/orgs/fedora-infra/projects/6 > * They are doing amazing work :) > > > > > ### CI/CD > > * Monitor-gating is now running in production and has already caught a > couple of issues with bodhi (both in stg and in prod)! > * Rpmautospec > * In review as a Fedora package: > https://bugzilla.redhat.com/show_bug.cgi?id=1816124 > * Work progressing on Koji tagging plugin (post-build), full use > case support for bumping releases > * Plan is still to get it deployed in staging > > > > > > > > ### Sustaining Team > * Mbbox Upgrade > * Some progress on CRD for koji-builder and koji-hub components > * Bodhi 5.2.2 released > * Some issues with celery tasks, however rawhide monitoring super useful. > * Compose tracker enhancement > * Focusing on tagging issues, and having the ability to ping maintainers > > Odcs-backend-releng01 provision to enable testing in Fedora Minimal Compose > > * Infra > * The daily standup the team has has helped a lot with managing > infra tickets - they are down to 99 tickets! > * Mass update of stg and prod > * Please note you may experience some Kojira slowness What's Kojira? > * New review-stats application deployed - > (https://fedoraproject.org/PackageReviewStatus/) > > > > > > > ## CentOS Updates > > ### CentOS > * ppc64le and aarch64, 8 and 8-stream nodes now available in cico for > tenants to checkout. -- Email sent to ci-user list > * New signing for SIGs (through https://cbs.centos.org) live on 25th April > 2020 > > > > > > > > ### CentOS Stream > * Summit Videos took our attention this week > * We have a booth, so don't forget to register your attendance! > https://www.redhat.com/en/summit > * Qt5.12 pushed in response to an internal request > * NetworkManager re-imported > > > > > > > > > > > > > > > As always, feedback is welcome, and we will continue to look at ways > to improve the delivery and readability of this weekly report. > > > Have a great week ahead! > > Aoife >
Re: dropping NSS DBM format support in F33+
On Sat, Apr 25, 2020, at 6:21 AM, Ondrej Mosnacek wrote: > On Fri, Apr 24, 2020 at 11:12 PM Ondrej Mosnacek wrote: > > On Fri, Apr 24, 2020 at 8:50 PM Ondrej Mosnacek wrote: > > > On Wed, Apr 22, 2020 at 10:12 AM Daiki Ueno > > > wrote: > > > > Hello, > > > > > > > > I am not sure if this deserves a Fedora Change proposal, so I'd like to > > > > hear any opinions first before proceeding with the process. > > > > > > > > NSS (the crypto library used by Firefox) historically supports 2 > > > > database formats: SQLite and DBM. The latter is considered legacy and > > > > we switched the default database format to SQLite in F28[1]. Since then > > > > I presume most of the applications have switched to the new format. > > > > Therefore we are planning to phase out the support of DBM, targetting > > > > F33+. > > > > > > > > Please let me know if there is any concern. > > > > > > It seems this broke the kernel build. I did some scratch build today > > > to test some patches, but it failed with this: > > > > > > + /usr/bin/pesign -c 'Red Hat Test Certificate' --certdir > > > /etc/pki/pesign-rh-test -i arch/x86/boot/bzImage -o vmlinuz.signed -s > > > pesign: Could not initialize nss. > > > NSS says "The certificate/key database is in an old, unsupported > > > format." errno says "No such file or directory" > > > error: Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build) > > > RPM build errors: > > > Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build) > > > Child return code was: 1 > > > > Probably related: https://github.com/rhboot/pesign/issues/34 > > I filed a bug against pesign here: > https://bugzilla.redhat.com/show_bug.cgi?id=1827902 > Shouldn't https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql have prevented such bugs? I.e., why didn't the default change get picked up automatically here? V/r, James Cassell ___ 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: Previous awesome background images
On Mon, Apr 20, 2020, at 12:46 PM, Máirín Duffy wrote: > > On 17. 04. 20 16:07, Kamil Paral wrote: > > https://blog.linuxgrrl.com/2018/03/06/fedora-28s-desktop-background-design/ > > > > I am sad we haven't followed the pattern. (However I don't know the > > reasoning > > for stopping that.) > > That's not true, we didn't stop the pattern. F32 is G for Goffman. F > was Fresnel. E was Elion. So on. If you dig through the tickets you'll > fimd the inspiration. > OMG, Secret Fedora Release Names! Did not realize it was a thing. Very cool! V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Thu, Apr 16, 2020, at 9:26 AM, Florian Weimer wrote: > * Zbigniew Jędrzejewski-Szmek: > > > On Thu, Apr 16, 2020 at 12:53:48PM +0200, Florian Weimer wrote: > >> * Lennart Poettering: > >> > >> > On Mi, 15.04.20 16:30, Lennart Poettering (mzerq...@0pointer.de) wrote: > >> > > >> >> On Mi, 15.04.20 15:50, Florian Weimer (fwei...@redhat.com) wrote: > >> >> > >> >> > * Lennart Poettering: > >> >> > > >> >> > > 1. If /etc/resolv.conf is a regular file, resolved will *consume* it > >> >> > >for DNS configuration, and never change it or modify it or > >> >> > > replace > >> >> > >it. If this mode is selected arbitrary other programs that do DNS > >> >> > >will talk directly to the provided DNS servers, and resolved is > >> >> > > out > >> >> > >of the loop. > >> >> > > >> >> > > In mode #1 resolved neither manages /etc/resolv.conf nor inserts > >> >> > > itself into DNS resolution in any way. > >> >> > > >> >> > What will nss_resolve do in this case? Nothing? > >> >> > >> >> The nss_resolve module is just a wrapper around resolved's bus > >> >> API. And the bus API uses resolved's own DNS resolution code. And > >> >> resolved is smart enough to automatically become a *consumer* of > >> >> /etc/nsswitch.conf (instead of a *manager* of it) if it is a regular > >> >> file instead of a symlink to resolved's own files in /run. > >> > > >> > Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf. > >> > >> So if /etc/resolv.conf comes from somewhere else, then nss_resolve will > >> still forward queries to the daemon, which contacts the upstream server > >> on nss_resolve's behave (possibly with some caching), and eventually > >> return the data to the application? > > > > nss-resolve is enabled/disabled through nsswitch.conf. It always talks to > > systemd-resolved using local IPC. It doesn't care about /etc/resolv.conf > > in any way. > > > > What Lennart wrote above applies to systemd-resolved and to things > > which look at /etc/resolv.conf for some reason. If nss-resolve is enabled, > > then only things which do not use nss at all would fall into this category. > > > >> Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch the > >> data? > > > > nss_resolve fails with UNAVAIL when systemd-resolved is not running. > > So yeah, we use want to use nss_dns as a fallback for that case. I'm not > > sure if that is what you are asking about. > > Let me rephrase: > > If /etc/resolv.conf is a regular file, will systemd-resolved deactivate > itself? Or use the name server configuration found there instead? > Based on earlier replies in the thread, resolved will use the nameservers from the file. There's no mention of it disabling itself. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Wed, Apr 15, 2020, at 1:27 PM, Daniel Walsh wrote:
> On 4/15/20 10:07, Lennart Poettering wrote:
> > On Di, 14.04.20 15:57, James Cassell (fedoraproj...@cyberpear.com) wrote:
> >
> >> On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
> >>> https://fedoraproject.org/wiki/Changes/systemd-resolved
> >>>
> >>> == Summary ==
> >>>
> >>> Enable systemd-resolved by default. glibc will perform name resolution
> >>> using nss-resolve rather than nss-dns.
> >>>
> >>> == Owner ==
> >>> * Name: [[User:catanzaro| Michael Catanzaro]]
> >>> * Email:
> >>>
> >>> == Detailed Description ==
> >>>
> >>> We will enable systemd-resolved by default.
> >> Does this require systemd to be running? How does this affect DNS
> >> resolution on a Fedora 33 container?
> > Depends.
> >
> > If a container manager copies in /etc/resolv.conf from the host into
> > the container on container *start*, it might be wise to copy in
> > /run/systemd/resolve/resolv.conf instead of /etc/resolv.conf, if it
> > exists. That file in /run contains the currently up-to-date upstream
> > DNS info literally.
>
> Containers copy the /etc/resolv.conf. /etc/hosts on creation, that way
> they can modify it internally,
>
> It looks like podman will just follow the link. I setup this simple test
>
> # ls -l /etc/resolv.conf
> lrwxrwxrwx. 1 root root 16 Apr 15 13:25 /etc/resolv.conf -> /run/resolv.conf
> # cat /etc/resolv.conf
> # Generated by NetworkManager
> search redhat.com
> nameserver 10.5.30.160
> nameserver 10.11.5.19
> nameserver 192.168.1.1
> # podman run fedora cat /etc/resolv.conf
> search redhat.com
> nameserver 10.5.30.160
> nameserver 10.11.5.19
> nameserver 192.168.1.1
>
> So as long as the
>
> /run/systemd/resolve/resolv.conf
>
> file is properly formated, our container engines will just work.
>
I think there's some existing black magic to handle the case when resolv.conf
references 127.0.0.1... maybe it already also works for 127.0.0.53. Otherwise,
maybe it could be patched to handle 127.0.0.0/8 in the same way. Then no
special casing for resolved would be needed.
V/r,
James Cassell
> >
> > If a container builder copies in /etc/resolv.conf during build time,
> > it probably should insert something like 8.8.8.8 as DNS servers there,
> > also replacing whatever is there.
> >
> > Note that the logic in systemd and resolved is very defensive: if
> > /etc/resolv.conf is not a symlink to
> > /run/systemd/resolve/{stub-,}resolv.conf then resolved will consume
> > /etc/resolv.conf instead of managing it (see other mail), hence a
> > container mgr/builder that wants to direct DNS traffic somewhere
> > should just override the file to whatever it wants, and things will
> > just work, regarldess if resolved runs in the container or not, and
> > resolved -- if used -- will honour whatever the container mgr/builder
> > put there.
> >
> > Lennart
> >
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/systemd-resolved > > == Summary == > > Enable systemd-resolved by default. glibc will perform name resolution > using nss-resolve rather than nss-dns. > > == Owner == > * Name: [[User:catanzaro| Michael Catanzaro]] > * Email: > > == Detailed Description == > > We will enable systemd-resolved by default. > Does this require systemd to be running? How does this affect DNS resolution on a Fedora 33 container? V/r James Cassell ___ 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: git-core deps under f32
On Thu, Apr 9, 2020, at 10:11 PM, Todd Zullinger wrote: > I wrote: > > clime wrote: > >> It seems the f32's git-core got many more deps for some reason, even > >> such as dbus-broker or systemd. > [...] > > I'll try to poke a bit in the next few days as I can make > > some time. I had not noticed the inflated depchain. Thank > > you for pointing it out. > > I was curious, so I looked at this tonight. The git-core > requires are the same on f31 and f32: > > $ diff -qs \ > <(rpm -qp --requires git-core-2.25.2-1.fc31.x86_64.rpm 2>/dev/null) \ > <(rpm -qp --requires git-core-2.26.0-1.fc32.x86_64.rpm 2>/dev/null) > Files /dev/fd/63 and /dev/fd/62 are identical > > Checking each of those deps, openssh-clients grew a dep on > libfido2, which in turn requires u2f-hidraw-policy that is > provided by systemd. That looks like the main chain which > leads to the additional packages installed in a mock chroot. > > In a fedora 32 container (and most "regular" installs), > systemd is already present, so the change should have very > little impact outside of mock or other targets which are > smaller than the default fedora 32 container image. > > I don't think that git-core should drop openssh-clients and > it seems pretty reasonable for openssh-clients to require > libfido2 to enable two factor authentication. > > Does that sound alright to you as well, clime? > Sounds like libfido2 should be a Recommend rather than Require unless openssh-clients is not functional without it. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Introduce module Obsoletes and EOL
On Thu, Apr 9, 2020, at 10:00 AM, Petr Pisar wrote: > On Thu, Apr 09, 2020 at 12:05:07PM +, Zbigniew Jędrzejewski-Szmek wrote: > > if the module EOL is before a given Fedora version goes EOL, it should > > never be proposed for installation in that Fedora version. In other words, > > if foo:3.15 stream has EOL of 1/4/2020, it should be shown in > > 'dnf module list' in F<=31, but not F>=32. > > > I think you wanted to write F<=30. F30 ends in 2020-04. > > Isn't "dnf" stage too late? Should it be filtered sooner? E.g. enforced by > Bodhi? Current Bodhi prevents from pushing updates into EOL-ed Fedoras. > > Or it could be prevented from building in MBS. When MBS expands platform:[] to > all supported Fedoras, it could also take other stream's EOL into account. Not > only platform EOL. It could save Koji resources. > > > > My understanding of current policy is that it would not be permitted > > > to have such a module in current fedora. It could only be included > > > in a version of fedora where it will receive updates for the entire > > > life cycle of that Fedora version. > > > > Exactly. The question is whether this happens like this, or not. > > I scanned https://docs.fedoraproject.org/en-US/modularity, but I don't see > > any mention of that. > > > While your approach simplifies the decisions a user should do, it also > prevents from providing streams that have a shorter life than Fedora. E.g. > non-LTS Java only has a life span for 6 months. How should be delivered these > "rapidly" developed projects? > The non-LTS java is provided in the java-openjdk-latest package which always has the latest java. It is not a module, last I checked. Same story for Firefox, IIUC. V/r, James Cassell ___ 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
[EPEL-devel] Re: EPEL8 conflict policy
On Wed, Apr 8, 2020, at 9:20 PM, Orion Poplawski wrote: > There does not appear to be an explicit conflict policy for EPEL8: > > https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F > > I got a report against python3-s3transfer and python3-botocore > conflicting with the CentOS 8 HighAvailability repo. No idea if this is > an issue or not: https://bugzilla.redhat.com/show_bug.cgi?id=1821630 > > It looks like we have avoided conflicts with the "ha" repos in the past, > and I can enable the rhel-8-for-x86_64-highavailability-rpms repo on my > RHEL8 developer license machine so it does seem available to everyone. > It's not available to everyone. It's a paid add-on. My understanding is that EPEL avoids conflicting only with the BaseOS, AppStream, and CodeReady Linux Builder repositories. c.f., ansible, which is more widely available than HA, but also carried in EPEL. V/r, James Cassell ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020, at 2:42 PM, Josh Boyer wrote: > On Tue, Apr 7, 2020 at 2:27 PM Stephen Gallagher wrote: > > > > On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa wrote: > > > > > This definitely solves the issue I've been thinking of. I'm not sure I > > > > > understand why we want to disconnect the ELN version from the upcoming > > > > > RHEL version, even in the DistTag? It seems to be a weird hoop to > > > > > separate when we all know this is about building the next RHEL major, > > > > > and we all know what the next version is, and we all know the > > > > > timelines. > > > > > > > > Don't get me wrong, I am not trying to hide the fact that we are > > > > building RHEL type of packages. > > > > > > > > But > > > > 1) aligning those versions is a more complex task than it looks. > > > > > > > > Historically we had this %rhel macro to map to next release version > > > > working, because we were building Fedora content for RHEL only during > > > > the specific phase of RHEL development, where this number is known and > > > > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And > > > > it is not that clear when exactly the jump of this version will > > > > happen. Because of the continuity the mapping between eln packages and > > > > RHEL packages is less obvious: It depends on which phase internal RHEL > > > > development is. but more to that, it can depend on which phase the > > > > development of a specific package is, as some packages can diverge > > > > from upstream earlier than others. > > > > > > > > So this eln to rhel mapping is a more complicated topic, then mapping > > > > EPEL to RHEL for example. And we probably will have to rethink it > > > > several times in the next couple of years. > > > > > > > > 2) we may need to bump version of the eln buildroot much more often > > > > than RHEL does major releases. > > > > > > > > As it comes from the use cases and the problem you have described, we > > > > want to actively experiment with the buildroot setup. So it makes > > > > sense to track it through versioning. > > > > > > > > > > Makes some sense to me. I'm a bit skeptical, but the reasoning makes > > > sense. With that adjustment, at least from my perspective I think this > > > is okay. > > > > The other piece of it is that there's a UX/psychological piece to it. > > If we call it .eln9.1.0, people are quite likely to skim over the 'n' > > and confuse themselves into thinking it's a RHEL 9.1.0 package. That > > way lies a support nightmare. We absolutely agree with your assessment > > that the dist tag needs to be versioned (see my earlier mail), but we > > want to disambiguate it so it doesn't look like a real RHEL package. > > (I'm debating starting with a higher number like 100 so it doesn't get > > confused with Fedora or RHEL versions that we're likely to see any day > > soon.) > > I appreciate the amount of thought that went into that. It's not > something most people even consider, and I think your concerns are > well founded. Thanks for thinking that through! > eln9.100.0 makes the relation to RHEL cycle obvious without looking like a RHEL tag. Is dot allowed here? Do we need eln9_100_1? V/r, James Cassell ___ 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: CPE Weekly: 2020-04-04
On Mon, Apr 6, 2020, at 1:48 PM, Stephen John Smoogen wrote: > > > On Mon, 6 Apr 2020 at 13:34, Robbie Harwood wrote: > > Aoife Moloney writes: > > > > > * We found a password, we do not know whose it is, but we have turned > > > it into the lost and found. > > > > I'm sorry, what? Can you explain what this is and what it means? > > > > This was something I slipped in to see if anyone was going to read any > part of things on the move or if everyone else was going to fixate on > the other parts. Thank you for reading past the first set of > paragraphs. > I'd assumed it was a joke. Or that maybe you found a file called "password" somewhere. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Introduce module Obsoletes and EOL
On Mon, Apr 6, 2020, at 12:05 PM, Petr Pisar wrote: > On Mon, Apr 06, 2020 at 03:02:02PM +, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Mar 31, 2020 at 12:13:16PM +0200, Daniel Mach wrote: [snip] > > > Setting eol_date to the future allows informing a user about > > > upcoming obsoleting event so they can eventually migrate manually. > > > > For some context (RHEL...) time-based obsoletes make plenty of sense. > > But in Fedora we established a policy that obsoletion and other > > significant stream changes happen at "release boundary", which for > > each user is whenever they choose to upgrade, so not time-based. > > > That's a great motivation, but this is not how it works in the real world. > > A packager asks for a branch and sets an end-of-life date. The date is > enforced to align with a Fedora cadence. I.e. 4th and 10th month of a year. > The > packager builds a module from that branch for _all_ Fedoras and pushes the > builds to the stable repositories. Once the end-of-life day comes, the > packager stops maintaining the stream. That day there is exactly one Fedora > release that also reached the end of life. But all the newer Fedora releases > are still supported, but the stream there is not. You have an unsupported > stream in a supported Fedora release. > > That's the outcome of decoupling a stream life cycle from a Fedora life cycle. > My understanding of current policy is that it would not be permitted to have such a module in current fedora. It could only be included in a version of fedora where it will receive updates for the entire life cycle of that Fedora version. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
On Sun, Mar 29, 2020, at 11:47 PM, Neal Gompa wrote: > On Sat, Mar 28, 2020 at 4:12 PM Aoife Moloney wrote: > > > > ### Other Updates > > > > GitForge Decision > > * After evaluating over 300 user stories from multiple stakeholders we > > have aligned on a decision for the Gitforge that CPE will operate for > > the coming years. We are opting for Gitlab for our dist git and > > project hosting and will continue to run pagure.io with community > > assistance. > > * Check out our GitForge decision on the Fedora Community blog > > https://communityblog.fedoraproject.org/ > > * And at the CentOS blog page > > https://blog.centos.org/2020/03/git-forge-decision/ > > * Keep an eye out for mails in the coming months to the devel lists as > > we plan transitions and next steps with GitLab > > * We would like to express our sincere thank you to all who > > contributed requirements to us! > > > > > > I'm going to start with the delivery of this decision sucked. If I > hadn't been alerted to look for this by other folks due to my advocacy > and community building work around Pagure, I would *not* have known > that the decision had been made. This is in contrast to the *big deal* > that was made about starting this "decision process". I don't know if Indeed, it seems like the lead got buried. I, too, had missed the announcement. I guess I'll make more effort to read these weekly status updates. > there were folks counting on nobody noticing this or not, but this is > not a good way to deliver effectively a major decision like this. I > also absolutely *refuse* to deal with the fact that this thread was > split into three mailing lists. All three are connected to this > thread, and I will take responses from all of them and follow them > accordingly. > > Enough about that, let's talk about the actual decision. Thanks for your comprehensive response here and for all the work you've done to drive Pagure forward. V/r, James Cassell > > So, you're going with GitLab. It's interesting to note that the > particulars about going to GitLab are not even figured out. It is > curious that "SAAS" is mentioned very prominently. That made me a bit > more curious, so I looked at the "final" feature requirements. > Needless to say, I was extremely disappointed. > > To put it bluntly, there are *zero* free and open source solutions > that satisfy your needs. From this, I understood why you said GitLab > and SaaS. You want GitLab Ultimate, the proprietary solution that > includes several extra features on top to satisfy the following > requirements (quoted from your blog post): > > > * There is a need for CentOS Stream to integrate with a kernel workflow > > that is an automated bot driven merging solution (merge trains). This > > allows for richer CI capabilities and minimizes the need for human > > interaction > > * Gitlab allows for project planning capability which could make multiple > > trackers such as Taiga redundant, allowing for the planning and tracking to > > reside within the repo. It would enrich the current ticket based solution > > that Pagure has evolved into for some groups > > These two requirements *alone* automatically force us to GitLab > Enterprise Ultimate Edition, as there is no other solution available > that satisfies those requirements in one product. Merge trains *is* a > feature of Pagure when combined with Zuul, but GitLab's project > planning features do not exist in *any* FOSS product, including GitLab > CE (or GitLab Core as they call it now). > > There are mentions of other work that CPE team wants to do to better > improve Fedora. Okay, sure. I even agree with some of them. And the > time bomb that is FAS is definitely worth the attention (note that I > am somewhat involved in the development of the Fedora AAA solution and > am also working on trying to develop a community around it so it > doesn't implode like virtually every other project under the Fedora > umbrella, more on *that* a bit later). > > However, nobody has given me or anyone else in the Pagure community > (which yes, is more than Pierre-Yves, thank you very much!) any > concrete details of deficiencies they'd see that is not satisfiable by > the community within a year before now. I've spent a little over a day > analyzing the user stories and thinking about the gaps between Pagure > and what the community wants, and I want to give some perspective here > for some of these. I'm happy to accept refutations and other details > to further enhance the color of these stories, of course. > > > 5 > > As a RH Developer > > I need the ability to
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote: > > Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a): > > Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a): > >> [snip] > >> We can come up with guidelines, for example: > >> > >> 1) Try to find a way to resolve the issue without any conditionals first. > >> > >> There should be a reason why package X needs a dependency Y in Fedora > >> and there should be a reason why it is a required dependency and not a > >> recommended one. So why in that case downstream wants it differently? > >> The first approach is just to talk through it. I can assume cases > >> where downstream adds a dependency, as well as Fedora package removing > >> them. > >> > >> Note that bloated dependency trees is a common problem for all binary > >> distributions, it is not an "EL-thing" and we can work on that > >> together. > >> > >> Nicolas has pointed out to another reason why we would get > >> EL-conditionals: the outdated rpm stack in RHEL. But we don't have > >> this problem with ELN, as we are building Rawhide, and rpm stack is > >> going to be the Rawhide rpm stack as well. > >> > >> 2) Minimize and isolate the conditional, and track the reason. > >> > >> As ELN SIG we need to have a place where we collect known reasons for > >> such conditionals. The overall goal is to reduce this set, not to grow > >> indefinitely. As Stephen said we expect it to be about couple of > >> hundred packages. We will be able to track each one of them. (We have > >> rpminspect to run package diffs for us). > >> > >> 3) In complex cases - bring it to community and FESCo. > >> > >> We don't know what those complex cases might be, one of the goals is > >> to find them. So we keep it as an option to bring individual case to a > >> wider audience. To ask for help and to decide on it. > >> > > It seems there are missing real life examples of what we sometimes do in > > RHEL, so please see attached patch. This patch is coming from RHEL > > version of the espeak-ng. Now somebody tell me what it does for what > > purpose and which scenario from the above three should be applied here. > > > > > > Vít > > > > And here is another example for the curious. > Both of these examples have to do with docs generation and trying to reduce dependencies for that process. "Process the man page using kramdown and remove the ronn dependency." (So you don't have to open the attachments yourself.) V/r, James Cassell ___ 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: co-maintainer wanted for fuse-sshfs in EPEL8
On Sun, Mar 8, 2020, at 12:38 PM, Dusty Mabe wrote: > Thanks Vascom, > > I'm not the maintainer so I can't add you, but I'll copy the > maintainer here as well, just to see if he'll see it. In case he > doesn't can you reply to the comment over in the BZ as well? See > https://bugzilla.redhat.com/show_bug.cgi?id=1758884#c4 > > When we get you added as a co-maintainer we'll then need > to add a epel8 branch and build against it. > It's already shipped in the codeready-builder-for-rhel-8-x86_64-rpms repo on RHEL 8, and PowerTools on CentOS. V/r, James Cassell > Thanks so much! > Dusty > > On 3/8/20 12:33 PM, Vascom wrote: > > You can add me as comaintainer. > > FAS name: vascom > > > > вс, 8 мар. 2020 г., 19:32 Dusty Mabe > <mailto:du...@dustymabe.com>>: > > > > The current maintainer of fuse-sshfs is looking for a co-maintainer for > > it > > in epel8. It's currently not in EPEL 8 so if you go from RHEL or CentOS > > 7->8 > > you'll lose it. I have users of vagrant-sshfs who would like to have it > > there. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1758884#c4 > > > > Anybody interested? > > > > Dusty > > ___ 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: Ideas and proposal for removing changelog and release fields from spec file
On Tue, Feb 25, 2020, at 2:53 PM, Matthew Miller wrote: > On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote: > > So these are the results of our current investigations, we are very much > > eager > > to get your feedback on them and even more eager if you have ideas on how to > > approach/solve some of the challenges mentioned here. > > This all sounds great. I'd also love for there to be a standard way of > tagging specific git commit log messages as meant for user consumption, and > use that to prepopulate the bodhi release notes field (with an eventual eye > towards making this the single source of Fedora package change information). > Indeed, it is unfortunate that the Bodhi info for EOL releases is currently lost. V/r, James Cassell ___ 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: Cross-arch dependencies for plugins (NSS and others)
On Mon, Feb 24, 2020, at 4:51 PM, Florian Weimer wrote: > * James Cassell: > > > On Mon, Feb 24, 2020, at 1:11 PM, Florian Weimer wrote: > >> Sometimes, users run into problems because they install nss_nis on > >> x86_64 and want to use 32-bit applications, but those do not work > >> correctly because nss_nis.i686 is not installed. I think we have an > >> opportunity here to improve the system administrator experience with > >> reasonable effort. > >> > >> If we add this to nss_nis.spec: > >> > >> %ifarch x86_64 > >> Recommends: (nss_nis(x86-32) if glibc(x86-32)) > >> %endif > > > > What about also adding > > > > %ifarch i686 > > Supplements: (glibc(x86-32) if (nss_nis(x86-64)) > > %endif > > > > (Untested) > > Does this have the same non-ideal behavior regarding late installation > of glibc.i686? > I believe the combo of the two will avoid the late install issue, and also avoid modifying any other SPEC. Again, not tested. > > I'd greatly prefer to avoid hard deps where they aren't absolutely > > necessary. > > Recommends: isn't a hard dependency? > Recommends is weak. I was referring to another message in the thread that suggested using Depends: V/r, James Cassell ___ 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: Cross-arch dependencies for plugins (NSS and others)
On Mon, Feb 24, 2020, at 1:11 PM, Florian Weimer wrote: > Sometimes, users run into problems because they install nss_nis on > x86_64 and want to use 32-bit applications, but those do not work > correctly because nss_nis.i686 is not installed. I think we have an > opportunity here to improve the system administrator experience with > reasonable effort. > > If we add this to nss_nis.spec: > > %ifarch x86_64 > Recommends: (nss_nis(x86-32) if glibc(x86-32)) > %endif What about also adding %ifarch i686 Supplements: (glibc(x86-32) if (nss_nis(x86-64)) %endif (Untested) I'd greatly prefer to avoid hard deps where they aren't absolutely necessary. V/r, James Cassell > > then when the user installs nss_nis after glibc.i686, they will get both > packages, as expected. > > Unfortunately, it does not work if nss_nis.x86_64 is installed first. > Is there a way to fix this aspect? > > What would be a good way to abstract this into some RPM macro, so that > we can apply this to other plugins as well? > > Thanks, > Florian ___ 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 32 Mass Branching
On Tue, Feb 11, 2020, at 2:37 PM, Miro Hrončok wrote: > On 11. 02. 20 19:36, Adam Williamson wrote: > > On Mon, 2020-02-10 at 20:05 -0500, Mohan Boddu wrote: > >> Hello All, > >> > >> Fedora 32 will be branched from rawhide on February 10th 2020 which is > >> tomorrow as per the Fedora 32 schedule[1]. The process takes about a > >> day and everything should be ready by February 11th 2020. You can > >> still be able to build packages normally until then, but after the > >> mass branching rawhide and F32 will be separated. > >> > >> We will send another email once the branching is done. > > > > Were we not planning to do this only when Rawhide is actually working? > > It currently has numerous near-showstopper bugs... > > The plan is to have a f32 freeze until the first working branched compose. > > https://fedoraproject.org/wiki/Changes/Freeze_after_branching_until_compose_is_ready > I'm probably misunderstanding, but I thought rawhide would be frozen until there were a successful f32 compose, to avoid mirror manager sending requests for f32 to f33 content. V/r, James Cassell ___ 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
[EPEL-devel] Re: Removing baseurl= from default repo files
On Mon, Feb 10, 2020, at 1:36 PM, Stephen John Smoogen wrote: > > For the longest time, the Fedora Project has included a baseurl= line > in its configs as an alternative to the basic metalink= line. EPEL has > followed along, and I expect a lot of users have some sort of > sed/awk/ed script which looks for a #baseurl and does something with > it. > > The upstream configs in Fedora's repo files are changing to only have > the metalink= line in them, and a couple of Pull Requests to make the > changes to the EPEL config files have been placed. > > https://src.fedoraproject.org/rpms/epel-release/pull-request/6 > https://src.fedoraproject.org/rpms/epel-release/pull-request/7 > > I am announcing the change here so that people can be aware before this > starts to show up in EPEL in the next month or so. > This will definitely break a bunch of scripts. Can we at least change it to point to example.com if the server load is too great? I use this to point to local mirrors when mirror manager is not an option. V/r, James Cassell ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: Packaging of Ansible collections
L On Mon, Feb 10, 2020, at 10:33 AM, Bill Nottingham wrote: > Igor Gnatenko (ignatenkobr...@fedoraproject.org) said: > > Hello, > > > > Did anybody had an experience of packaging Ansible collections into an RPM? > > > > I guess if would be enough to put the files somewhere under > > /usr/share/ansible, but not sure. Also I'm not sure what download URL could > > be used. > > What is the goal of downstream collection packaging here - what collections > are you looking to package and why? > Same reason as openshift-ansible or ceph-ansible or ansible-freeipa, or any pip-installable package. Unfortunately, ansible is kicking all the community modules out of core, so things like ini_file won't work without the appropriate collection installed. V/r, James Cassell ___ 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: Proxies for Copr repositories
On Tue, Feb 4, 2020, at 8:58 AM, Miroslav Suchý wrote: > Dne 04. 02. 20 v 13:18 Till Hofmann napsal(a): > > Does COPR itself also use the CDN for builds? I usually build dependency > > Yes. Since today. > > > chains, and since this morning, I see a lot of build failures due to a > > newly built package not being available. One example: > > - The newly built dependency: > > https://copr.fedorainfracloud.org/coprs/thofmann/ros/build/1220759/ > > - failed build, it cannot find the previously built package: > > https://copr.fedorainfracloud.org/coprs/thofmann/ros/build/1220790/ > > I find the hard way, that repodata was cached too aggressively (with TTL > 86400). > > repodata are now sent with > Cache-Control: no-cache > and log files (*log) with: > Cache-Control: no-store > > and it seems to fix this issue. > Hopefully that was only set for the repomd.xml so that the remaining repodata can be cached. (The other files have unique names.) V/r, James Cassell ___ 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: RFC: Python minimization in Fedora
On Thu, Jan 16, 2020, at 5:16 AM, Zbigniew Jędrzejewski-Szmek wrote: > > A quick benchmark: > $ time python3 -c 'import importlib as i, pydoc_data.topics as t; > [i.reload(t) for _ in range(1)]' > python3 -c 4.16s user 0.45s system 99% cpu 4.646 total [...] > sudo rm /usr/lib64/python3.7/pydoc_data/__pycache__/topics.cpython-37.* > > $ time python3 -c 'import importlib as i, pydoc_data.topics as t; > [i.reload(t) for _ in range(1000)]' > python3 -c 13.73s user 0.46s system 96% cpu 14.728 total [...] > But the effect of having *some* .pyc file is not. For this file (which > is 600+kb), the difference is 147.28/4.646 ≈ 30 times. So we clearly > need to keep the possibility of installing .pyc files, at least optionally. > Thanks for doing these benchmarks! I think you misplaced a decimal in the analysis, though; it's closer to 3 times performance difference, not 30 times. (Unless I missed something.) V/r, James Cassell ___ 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 32 System-Wide Change proposal: Drop Optical Media Release Criterion
On Fri, Dec 13, 2019, at 6:02 AM, Miro Hrončok wrote: > On 12. 12. 19 21:37, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion > > > > = Drop Optical Media Release Criterion = > > > > == Summary == > > Proposal to make all Fedora optical media non-blocking. This means > > we'd stop blocking on bugs found during the installation of Fedora > > from optical media (like CDs and DVDs). This doesn't mean that > > installation from optical media would stop working, just that the > > Fedora Release wouldn't be blocked on any issues that can pop up in > > Fedora installation using this method. Installation from USB devices > > will remain blocking. > > Juts a random idea, not very thought-out: > > Could we keep optical media bugs reported by users as blocking, but not > require > it during validation testing? > I'm against the change as- is, but I could support this. I use optical media extensively for reasons beyond my control. It's also useful for virtual CD on hardware via IPMI/iDRAC, depending on the vendor. I'll try to get back to help fill out the test matrix as I had done years ago. > > aka: Fedora QE would no longer have to verify optical media works. > but: If a tester finds an optical media bug, it is still blocking. > +1 V/r, James Cassell ___ 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
Suspend-to-Disk vs Suspend-to-RAM (was: Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default)
(New thread since this is unrelated to the original subject.) On Fri, Dec 6, 2019, at 9:44 PM, John M. Harris Jr wrote: > On Friday, December 6, 2019 11:22:34 AM MST Chris Murphy wrote: > > On Fri, Dec 6, 2019 at 7:46 AM John M. Harris Jr > > wrote: [...] > It's simply false to say that hibernation is not supported. Not only is it > supported, there's a big button for it in the major DEs. I have not tested > GNOME, but I'd be willing to be it's there, unless something has changed with > the shutdown menu since the version of GNOME 3 used in RHEL 7. Please do let > me know if GNOME is missing that button in Fedora, so that I may open a > feature request on behalf of GNOME users in Fedora. I couldn't find the hibernate button in Gnome, but I'm still on F29. Suspend is unreliable on my system, so I manually type `sudo systemctl hibernate` when I need to put my laptop in the bag, and it's very reliable in my 2018 ThinkPad. (Apparently, it's hard to get the button to hibernate w/in Gnome Shell: https://askubuntu.com/questions/61138/how-can-i-hibernate-from-gnome-shell ) > > It doesn't work out of the box with sufficient consistency or > > predictability to consider it supported or supportable. You'll find > > myriad upstream and downstream bug reports about hibernation that > > languish indefinitely. Some do get fixed. Whether it works depends on > > make/model, the firmware revision, and kernel version. > > See above. It works out of box. I will take that further to say that it works > consistently, so long as you don't select a different kernel image to resume. > On some hardware, you would be correct that hibernation does not work, but > that is not the case with most systems, and is irrelevant of the degree to > which Fedora supports it, which is that the option is available for use in > the > major DEs and on the command line. My experience is that hibernate is more reliable than suspend. Just this afternoon, I performed a suspend-to-ram, and during the 6 or so hours since then, the system dropped from 51% charge to 11% charge... it seems like something is not being put in its lowest possible power state. With hibernate, the system does not drain the battery while not in active use. Indeed, the primary hibernate issue I've seen is when a newer kernel has been installed and I accidentally boot into that one instead of the one that was hibernated... Seems like this should be easy to fix by having the hibernate process auto-select the current kernel as default for the next boot. The other issue is that the machine sometimes does not poweroff on its own upon hibernation. This seems to happen when I have or just had an external display attached prior to hibernation. I know to make sure the machine is off before putting it in my bag, and the four-second poweroff works fine in this case. It always boots up to just where I left off when I get to my destination. > > > The only time it wouldn't work seems to be in one of those special UEFI + > > > Secure Boot cases. > > > > It's not special. It happens to be the default firmware and > > configuration of most new x86_64 hardware, and the default policy upon > > installation by Fedora. > > That is simply not the case. While most new consumer x86_64 hardware comes > with UEFI on by default, unless it came with Windows installed, Secure Boot > is > normally disabled. This reflects my experience. When buying a Dell tower workstation with RHEL pre-installed, Secure Boot was turned off in the BIOS out-of-the box. > > And that means hibernation is not presently possible by default on those > > systems. > > Simply because somebody decided to disable the feature, as a "security" > measure. > Indeed, I did turn off Secure Boot on my ThinkPad where hibernate is rock solid but suspend quickly drains the battery. > > There is no agreement by distributions how to handle hibernation image > > signing that upstream will accept and Fedora isn't likely to carry out of > > tree patches for such a thing. > > There's no need to sign the hibernation image to begin with. That is an > arbitrary requirement that has been thrown in for absolutely no reason that I > can think of. You're not booting from the hibernation image. It doesn't need > to be signed to comply with the absurd requirements of "Secure Boot". > Disabling hibernation seems like an unreasonable loss of functionality in exchange for Secure Boot to me. How hard would it be to standardize on a signature/verification method? Is this a signature we could delegate to a TPM? Is it more palatable to enable it for MOK-signed kernels/modules, kind of like can be done for proprietary drivers? (Not sure if any nVidia d
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Fri, Dec 6, 2019, at 11:40 AM, John M. Harris Jr wrote: > Are you suggesting "translating", for lack of a better term, the passphrase > between all available keyboard layouts? That would decrease the effective > security of your system considerably.. > I'd suggest "translating" the password between the default layout and all layouts selected in anaconda. Just recently, I found that the initramfs honored my anaconda key layout, but the rescue initramfs did not. I'd expect that in the common case, this would eat one extra luks slot, and could save a lot of head ache without meaningfully reducing security. V/r, James Cassell ___ 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: dnf unable to download source due to rpmfusion-free-source
On Tue, Nov 12, 2019, at 7:50 PM, Adam Williamson wrote: > On Mon, 2019-11-11 at 12:07 +0100, Kevin Kofler wrote: > > Samuel Sieb wrote: > > > > > On 11/10/19 1:52 PM, Neal Becker wrote: > > > > Well it does work if you do > > > > > > > > dnf --disablerepo=rpmfusion-free,rpmfusion-nonfree download -- > > > > enablerepo=rawhide --source mercurial > > > > > > > > But that is not exactly obvious, so I think it's something dnf could > > > > handle better (I hesitate to call it a bug). > > > > > > Wow, that is very non-obvious. > > > > How is it non-obvious? --source enables the source repositories > > corresponding to the binary repositories you have enabled, so if you don't > > want it to enable rpmfusion-free-source, you have to disable the > > rpmfusion-free (not rpmfusion-free-source) repository. Sounds quite obvious > > to me. > > But the user's intent is clear and the code almost certainly *could* > interpret it, it just doesn't right now. All it has to do is (re- > )consider the repo(s) that were disabled via user config *after* the > "infer the source repos to enable from the enabled binary repos" flow > has happened. I'd call it a bug, or at least a reasonable feature > request. I agree it's s feature request. It's a case of "I recognize the correct answer when it's shown to me"... after seeing this thread, it's obvious that/why/how it works, but I wouldn't have necessarily thought of it myself. V/r, James Cassell ___ 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: Modularity: The Official Complaint Thread
On Tue, Nov 12, 2019, at 3:35 PM, Stephen Gallagher wrote: > On Tue, Nov 12, 2019 at 12:40 PM Stephen John Smoogen > wrote: > > > > On Tue, 12 Nov 2019 at 12:26, Aleksandra Fedorova > > wrote: > > > Again I fail to see the _technical_ difference between the ursine rpm > > > package and a package which was built as a part of default stream. It > > > is the same rpm spec from the same dist-git sources, which is built by > > > the same rpmbuild command. Thus I think it is a process/policy > > > difference, which we should resolve. > > > > Do you view provides/requires/conflicts in an RPM spec and their > > equivalent in modules to be technical or policy differences. If wrote > > a policy which says I built X and X-devel but only want to ship X in > > the module.. is that a policy difference or a technical one? > > The technology allows you to do this. The policy can restrict this. Of > course, this particular example can be true of a non-modular RPM too; > you don't *have* to build the X-devel subpackage. > > > If the > > policy says I can't even install a newer X/X-devel that I built with > > NEVR because modules always win and it isn't a module.. is that a > > technical difference or a policy one? > > > > That would be a technical difference. Your statement, however, is not > entirely true. You can trivially override it by using RPM instead of > DNF to update it. Or you can run `createrepo_c` and then add > `module_hotfix = 1` to the repo file you add to DNF. > I've been following the discussion, and this compels me to jump in. If you're installing things using RPM rather than DNF, you're bypassing the DNF database, and that's completely broken in my opinion. I've been teaching folks that you should only ever use YUM/DNF to perform package transactions, except for very special cases such as `rpm --setugids` or other very special RPM commands. I also can't (with clear conscience) start teaching folks to run createrepo_c just to install an updated RPM. (Side note: you still can't properly query the DNF database like you can with the YUM database; this is still broken from the YUM->DNF transition.) V/r, James Cassell ___ 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: Something wrong with kernel-headers on fedora 30?
On Thu, Nov 7, 2019, at 3:46 PM, James Cassell wrote: > > On Thu, Nov 7, 2019, at 2:50 PM, Laura Abbott wrote: > > On 11/7/19 1:31 PM, James Cassell wrote: > > > > > > On Thu, Nov 7, 2019, at 1:23 PM, Joseph D. Wagner wrote: > > >> I am on kernel 5.3.8 but I still have > > >> kernel-headers-5.3.6-200.fc30.x86_64, which hasn't updated. > > >> > > >> Is there a reason a new kernel-headers package hasn't been generated for > > >> the newer versions? Has it be superseded by another package? If so, > > >> then dependencies on glibc-headers need to be fixed. > > >> > > > > > > I've also been confused why kernel-headers is a separate SRPM... > > > > > > > The short answer is that kernel-headers doesn't need to be rebuilt > > each time. > > > > The longer answer is that we split it out to solve an issue > > where kernel-headers were being built unnecessarily and triggering > > rebuilds when they shouldn't. That problem is now being solved > > another way but it's also useful to be able to build kernel-headers > > independently so that if we don't want to build a kernel but do > > want the headers we can easily do so. > > > > kernel-headers is related to the userspace API and is not tied > > to a particular kernel version. If the userspace API doesn't > > change there's no need to rebuild. Is there a problem you're > > seeing by not having an updated kernel-headers? > > > > I compile my own patched kernel with a higher EVR than the packaged > kernel, but the kernel-headers package seems to pull in the kernel of > the same version despite my having a later one installed. > I should clarify that I'm doing a `fedpkg mockbuild` so the packaging should be identical to the shipped kernel. > Thanks for taking a look and explaining! > > > V/r, > James Cassell > ___ 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: Something wrong with kernel-headers on fedora 30?
On Thu, Nov 7, 2019, at 2:50 PM, Laura Abbott wrote: > On 11/7/19 1:31 PM, James Cassell wrote: > > > > On Thu, Nov 7, 2019, at 1:23 PM, Joseph D. Wagner wrote: > >> I am on kernel 5.3.8 but I still have > >> kernel-headers-5.3.6-200.fc30.x86_64, which hasn't updated. > >> > >> Is there a reason a new kernel-headers package hasn't been generated for > >> the newer versions? Has it be superseded by another package? If so, > >> then dependencies on glibc-headers need to be fixed. > >> > > > > I've also been confused why kernel-headers is a separate SRPM... > > > > The short answer is that kernel-headers doesn't need to be rebuilt > each time. > > The longer answer is that we split it out to solve an issue > where kernel-headers were being built unnecessarily and triggering > rebuilds when they shouldn't. That problem is now being solved > another way but it's also useful to be able to build kernel-headers > independently so that if we don't want to build a kernel but do > want the headers we can easily do so. > > kernel-headers is related to the userspace API and is not tied > to a particular kernel version. If the userspace API doesn't > change there's no need to rebuild. Is there a problem you're > seeing by not having an updated kernel-headers? > I compile my own patched kernel with a higher EVR than the packaged kernel, but the kernel-headers package seems to pull in the kernel of the same version despite my having a later one installed. Thanks for taking a look and explaining! V/r, James Cassell ___ 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: Something wrong with kernel-headers on fedora 30?
On Thu, Nov 7, 2019, at 1:23 PM, Joseph D. Wagner wrote: > I am on kernel 5.3.8 but I still have > kernel-headers-5.3.6-200.fc30.x86_64, which hasn't updated. > > Is there a reason a new kernel-headers package hasn't been generated for > the newer versions? Has it be superseded by another package? If so, > then dependencies on glibc-headers need to be fixed. > I've also been confused why kernel-headers is a separate SRPM... V/r, James Cassell ___ 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: ask.fedoraproject.org - redirects?
On Sat, Nov 2, 2019, at 2:02 PM, Kevin Kofler wrote: > James Cassell wrote: > > When I asked, the answer was that it costs money to do custom redirects, > > and the old site is going away "soon" so it would be overcome by events > > sooner or later. > > This just shows how bad an idea it is to rely on third-party-hosted > services. If this were self-hosted Free Software on Fedora Infrastructure > (e.g., a self-hosted version of Discourse), changing the error page would be > a relatively small patch and cost absolutely nothing. > To be fair, the error page does (now) suggest the old site, but it's not a redirect. Most users may be able to figure it out; I'm not convinced search engines will. > So why does Fedora let commercial third parties host critical project > infrastructure on the fedoraproject.org domain? > The argument I've seen is limited community resources to do the work. (For this reason, there's push to only self-host core competencies, and even whispers of stopping Pagure development.) V/r, James Cassell ___ 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: ask.fedoraproject.org - redirects?
On Fri, Nov 1, 2019, at 5:58 PM, Tim Jackson wrote: > I realise this is not exactly news, but when replacing Ask Fedora, was there > a > reason to break all the links on the entire web to existing solutions, rather > than just putting the new system on a different domain? Or, failing that, at > least adding (conditional) redirects and/or links to the "old" site? > > It seems like finally as Fedora was building up a body of useful "ask"-type > content and get traction on search engines (= searching for things not only > leading to results about Ubuntu), we wiped the slate clean. > > As it is now, whenever I (as a Fedora user) search for something, I still > frequently end up at a dead end on a 404 page on ask.fedoraproject.org. There > isn't even a *link* to the corresponding page on askbot.fedoraproject.org - > surely that, at least, is something we could do? (yes, I realise one just has > to add "bot" to the hostname, but that's not the point - not everyone will > either realise that, or bother, and it's trivial to do when generating the > error page) > When I asked, the answer was that it costs money to do custom redirects, and the old site is going away "soon" so it would be overcome by events sooner or later. V/r, James Cassell ___ 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: Minimization Objective report
On Mon, Sep 30, 2019, at 9:16 AM, Petr Pisar wrote: > On 2019-09-27, Matthew Miller wrote: > > On Wed, Sep 25, 2019 at 05:52:31PM +0200, Adam Samalik wrote: > >> == pcre -> pcre2 == > >> Moving grep (one of the last packages using pcre) to pcre2. [4] > > > > Is this a perfectly drop-in compatible replacement from a user point of > > view? > > > The user that executes "grep -P"? Not many changes. Usually a corner > cases that have a different performance or exhibit bug fixes. > As a frequent user of `grep -P`, I'd like to know whether there is any loss of functionality with the switch. Otherwise, I'm a huge fan of the minimization objective; I hope to make it to the (recently cancelled) meetings when they happen. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to use repo files in Anaconda environment
On Tue, Sep 17, 2019, at 9:09 AM, jkone...@redhat.com wrote: > Hello everyone, > > We (the Anaconda installer team) want to solve multiple problems by one > solution and we want > > *YOUR FEEDBACK!* > > > In short we are proposing to use custom repo files when configuring > Anaconda for image creation instead of adding even more complexity to > the kickstart repo command. For more details see the link below. > > Purpose of this mail is to give everyone interested in the topic a > place to discuss our proposal to find out if we didn't miss something > or better case, if you agree with it :). It could be that this is not > applicable for Lorax / Pungi / live-cd tool in that case please write a > response to the document. > In general, I'd prefer to extend the ks repo command. My main concern is that the original-ks.cfg or anaconda-ks.cfg might no longer provide a complete description of how a particular system was installed, so it'd like that info exposed on the installed system somehow. As for implementation, perhaps base64 zlib compressed. repo passed as a cmdline arg would be useful to avoid having to create updates.img. Could also be done as --repofilecontent for the repo command. I think it's already possible to place a .repo file from ks %pre? V/r, James Cassell > You can read details here: > > https://hackmd.io/@prJIqOTeSxC-W0RNGKIGbQ/ByzIz3kIH/edit > > Please, all the relevant comments should stay in the document if > possible. If that solution won't work because of higher traffic then we > will find a better solution but the point is to have everything on one > place. > > Have a great day everyone, > Jirka ___ 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 Workstation and disabled by default firewall
On Wed, Aug 28, 2019, at 8:59 PM, John Harris wrote: > On Wednesday, August 28, 2019 1:35:32 PM MST Colin Walters wrote: > > FWIW, > > > > For Fedora CoreOS we don't enable a firewall by default; see > > https://github.com/coreos/fedora-coreos-tracker/issues/26 > > > > (Neither for that matter does Fedora Cloud: > > https://pagure.io/fedora-kickstarts/blob/master/f/fedora-cloud-base.ks#_36) > > Yikes! I suppose we should discuss these as well. Those are, in my opinion, > much more serious, as they COMPLETELY shut off the firewall. Especially for > what those systems are designed for, this is very concerning.. > This seems to be a common theme with cloud images. I believe the assumption is that each cloud has its own Access Control policies that serve the function of a firewall. I always end up building my own cloud images with a firewall, partly for this reason. I would tend to agree that Fedora Core OS should have a firewall, if only to well-define which ports are required; but I have not been active there. V/r, James Cassell ___ 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: HEADS UP: DynamicBuildRequires are available
On Mon, Jun 17, 2019, at 9:28 PM, Igor Gnatenko wrote: > Hi folks, > > as of today, builders have been updated (thanks to Kevin) and > DynamicBuildRequires finally work in Rawhide. > > Change Page: https://fedoraproject.org/wiki/Changes/DynamicBuildRequires > Example of real build: > https://koji.fedoraproject.org/koji/buildinfo?buildID=1286391 Here's the related commit https://src.fedoraproject.org/rpms/rust-grep/c/0a403fe91cdcab17a37928f34e7a600fe2901ca3 ___ 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
[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy
On Thu, May 30, 2019, at 6:57 PM, Stephen Gallagher wrote: > On Thu, May 30, 2019 at 4:25 PM James Cassell > wrote: > > > > > > > > > Historical composes are intended to be frozen and unchanging, but this > > > > approach leaves open the possibility of tagging other builds into > > > > epel8-8.Y and regenerating the compose if the need arises. It will > > > > need to be communicated that these repositories will not receive > > > > updates and are intended to be only a snapshot of the past that is > > > > known to work with a particular RHEL 8.Y base. > > > > > > > This will be very helpful, especially if the epel-release .repo file honors > > the $releasever variable. > > > Can you explain what behavior you see here? I can't really parse from > your reply what you think/expect to have happen here, and I'd like to > make sure we address it properly. The use case is preventing updates past a minor version without explicit administrator action. We're able to do this by forcing the $releasever yum variable to be 7.50 (for RHEL) or 7.5.1804 (for CentOS). It would be convenient to keep this approach working by using the yum var in the repo file, with requisite symlinks in place on the mirrors. The repo file as is today would likely work for this purpose (but I don't have it in front of me to verify.) V/r, James Cassell ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy
On Thu, May 30, 2019, at 3:18 PM, Kevin Fenzi wrote: > > As discussed in the EPEL SIG meeting yesterday, I've written up my > > thoughts on how to handle epel8 branches. > [...] > > > > When the time comes where an incompatible change needs to land, they > > must be coordinated to land on an approved schedule. The exact > > mechanism of scheduling and coordinating this is out of scope for this > > document and will be decided on by the EPEL Steering Committee. > > Yeah, but we should probibly try and figure it out. > > I guess there is: > A. Right after the new minor release comes out > B. Right after the new minor release comes out for CentOS > C. Some arbitrary time after the new minor release comes out. > I'd be in favor of B. [...] > > # Historical Composes > > Since major changes may occur at RHEL 8.Y releases, we want to support > > allowing our users to lock onto a repository that matches that > > release. For this, we will generate historical composes, which will > > match the stable package set of the prior minor release once the new > > minor release comes out. > > > > At 00:00 UTC of the day following a new RHEL 8.Y release, an updated > > epel-release package will be pushed, updating the %dist tag to the new > > .epel8_Y value. All new builds will thus have the new dist tag. A > > script will be run at this time to apply a new Koji tag (epel8-8.Y) to > > the latest build of a package with one of the following tags: [ > > epel8-stable, epel8-stable-pending ]. A compose of the epel8.Y > > repository will be created at this time from all packages currently > > tagged as epel8-8.Y. > > So, we will also have to unpush/obsolete/close all pending bodhi updates > right? Since things will need rebuilding with the new dist tag for the > new minor. I'd say just cancel any karma, reset the timer, then let them go out as-is once/if they again pass the bodhi process. > > > > Historical composes are intended to be frozen and unchanging, but this > > approach leaves open the possibility of tagging other builds into > > epel8-8.Y and regenerating the compose if the need arises. It will > > need to be communicated that these repositories will not receive > > updates and are intended to be only a snapshot of the past that is > > known to work with a particular RHEL 8.Y base. > This will be very helpful, especially if the epel-release .repo file honors the $releasever variable. V/r, James Cassell ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Wed, May 29, 2019, at 4:20 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression > > = Switch RPMs to zstd compression = > [...] > == Benefit to Fedora == > * Faster installations/upgrades of user systems > * Faster koji builds (installations in build roots) > * Faster container builds > * Lower bandwidth on mirrors if we choose the highest compression level > Would this help with drpms similar to how it helps with faster yum repo metadata downloads? My biggest problem with drpms is the slow rebuild speed which is usually slower than my download bandwidth. It would be a big win if zstd helps here. V/r, James Cassell ___ 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: dropping autogenerated dependency on pkg-config
On Tue, Apr 30, 2019, at 10:14 PM, Neal Gompa wrote: > > Second, do you not even know that Mock passes --nodeps to rpmbuild > because the rpmdb in the chroot isn't necessarily compatible with rpm > in the chroot? We currently don't allow rpmbuild to evaluate > dependencies at all. We may change this if Koji switches to producing > bootstrap chroots before producing the build chroot. So right now, > that lookup is not even happening. > Awesome! I love learning how these things work! Thanks for sharing! V/r, James Cassell ___ 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: dnf crashes make fedpkg / mock unusable
On Sun, Mar 31, 2019, at 11:02 AM, Fabio Valentini wrote: > On Sun, Mar 31, 2019 at 4:04 PM Fabio Valentini wrote: > > > > Hi everybody, > > > > Since about one or two days, I am completely unable to build any > > packages with fedpkg locally, and even running dnf on the host system > > is really crashy. > > > > It looks like dnf crashes while it's refreshing repository metadata. > > ABRT won't let me report the issue due to "low informational value" of > > the backtrace, but it looks like SEGFAULT in libcurl: > > > > Program terminated with signal SIGSEGV, Segmentation fault. > > #0 0x7fad55077f22 in ?? () from /lib64/libcurl.so.4 > > (...) > > > > However, there's not been any recent curl update for f29 AFAICT. I > > tried cleaning up the dnf cache, but it doesn't help. > > Does anybody have an idea what's causing this? I'm unable to work on > > my packages until I can solve this > > I've found the issue - it's the recent update to librepo that causes this > issue: > https://bodhi.fedoraproject.org/updates/FEDORA-2019-7fbfa37585 > Downgrading to librepo 1.9.5 makes the crashes go away. > See also https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/message/4UAQQI7BTHBHGPOKJZT2P2XNWJKR7JNP/ V/r, James Cassell ___ 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: System-Wide Change proposal: DNF UUID
On Tue, Jan 8, 2019, at 11:15 AM, Stephen Gallagher wrote: > On Tue, Jan 8, 2019 at 10:50 AM Matthew Miller > wrote: > > > > On Tue, Jan 08, 2019 at 04:22:39PM +0100, Lennart Poettering wrote: > > > > The additional information could be > > > > 10.5.124.209 - - [31/Dec/2018:09:07:21 +] "GET > > > > /metalink?repo=fedora-28=x86_64== > > > > HTTP/1.1" 200 62200 "-" "dnf/2.7.5" > > > If all you want to do is count, then it should be entirely sufficient > > > to do it like this: > > >GET /metalink?repo=fedora-28=x86_64==1 > > > HTTP/1.1 > > > the first time within each one-week window and a simple > > >GET /metalink?repo=fedora-28=x86_64= HTTP/1.1 > > > all other times. > > > Then, sum up how many "countme=1" GET requests we get per week, and > > > you have a good count, without tracking individual clients, without > > > inventing new uuids¹. > > > > I do like this idea! > > > > And, if there's not an associated UUID, it's more comfortable to do > > "countme=2" the second week and onward -- this would make it easy to > > distinguish systems which are short-lived. (Or "countme=new" and > > "countme=ongoing" or something?) > > > > H. How comfortable would people be with reporting an incrementing count > > *every* week (again, without a UUID attached)? That'd give a new axis into > > the data which I can imagine being quite useful. > > > > > I like this idea and I think it's generally less likely to set off > alarm bells about privacy. I do think we probably want to avoid an > *incrementing* count, though to avoid questions around using > time-of-install as a vector into identifying the owner. So the > "new-vs-ongoing" differentiator seems reasonable to me. I *would* > suggest that we probably want to have it send "countme=new" every time > it tries to reach the mirrorlink until the first time it gets a proper > response. After that, sending "countme=ongoing" once a week would be > good additional information. I'd propose countme=new the first time, then countme=thirty or the original version of fedora that was installed on this machine, so you could also track upgrades over time vs new installs. V/r, James Cassell ___ 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
[EPEL-devel] Re: Fedora project login
On Wed, Jan 2, 2019, at 1:31 PM, Kevin Fenzi wrote: > On 1/2/19 12:44 AM, Michael A. Peters wrote: > > Hello, > > > > Extremely BAD experience trying to log in at > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9a4a06731c > > Sorry to hear it. ;( > > > First I couldn't remember my username but I could remember my password > > and the VERY BROKEN DESIGN does not allow me to request it send me a > > reminder of my username. > > > > Finally figured out my username and it sent me a password reset. > > > > Reset password, and it would not let me log in. > > > > Attempted several times. > > > > Figuring I entered it wrong and did the reset again. > > > > Tried the password the way it was in my password manager and it said I > > couldn't reset it to an old password. > > > > So regenerated new password - but with that also could not log in. > > Can you expand on that? What did it do? You got a username/password > dialog? It said password incorrect? or any other messages/errors? > Here's my experience: Go to https://bodhi.fedoraproject.org Click "Login" Dialog pops up asking for user/pass Click Cancel Page comes up for FAS log in Put Fedora Account System credentials Click "Log In" Get redirected back to bodhi, logged in. Typing my FAS credentials into the first pop up dialog just shows the dialog again and does not log me in. V/r, James Cassell > kevin > > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: F-14 Branched report: 20100828 changes
On Sat, 28 Aug 2010 11:00:07 -0400, Branched Report rawh...@fedoraproject.org wrote: Removed package: pastebin-0.60-6.fc12 Why has this been removed? -- James Cassell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 yum in kvm or vmware guests
On Thu, 06 May 2010 09:02:06 +0200, Matthias Runge mru...@matthias-runge.de wrote: On 05/05/10 23:40, Warren Togami wrote: (10/12): samba-3.5.2-60.fc13.x86_64.rpm (71%) 73% [- ] 0.0 B/s | 3.7 MB 3340883129410265958989882401668816722716705737932:48 ETA Anyone else seeing this kind of behavior with F-13 yum within kvm or vmware guests? It seems to happen consistently here in the middle of downloading multiple packages where I need to kill yum and try again. Warren Hi, did mention it on some VirtualBoxes running F13. I did not dive into this, so I don't know, how to reproduce. Sometimes, I need to kill yum several times and try again. Matthias I've seen this after I've put my phiscial machine on Suspend, while yum was downloading. After waking back up, it just stays like that until I kill it and start again. -- James Cassell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
