[EPEL-devel] Re: python311-dnf for el8 and el9
Thanks for the replies. I studied the implementation in python3.11-rpm, and I used that same technique to package python3.11-dnf for EPEL 8 and 9. https://copr.fedorainfracloud.org/coprs/ktdreyer/python3.11/ There's a tight dependency on libdnf in RHEL 8.8 and 9.2. I'll have to see how difficult this is to keep in sync with those RHEL packages. Also, thanks Troy for recently packaging python3.11-gpg for EPEL 9. I'd originally ported the python3-gpg 1.15.1 version from RHEL 9, but yours is newer (1.22.0), so I deleted my version. - Ken On Sun, Oct 8, 2023 at 11:01 AM Miro Hrončok wrote: > > On 05. 10. 23 21:52, Ken Dreyer wrote: > > Hi folks, > > > > I have some Python apps that "import dnf". I wanted to run these on > > the parallel Python versions in RHEL 8 and 9, but there's no > > python311-dnf library available. > > > > I haven't looked into this yet. Has anyone else looked at it? > > > > I think I'll need something like > > https://src.fedoraproject.org/rpms/python3-rpm/c/966f38637a7f51376e57b7aeb19a872986a39b8a > > , but for a "python3-dnf" package? > > > > (By the way, thanks Python team for python3.11 in RHEL 8 and 9. That > > is helpful for moving workloads across RHEL versions and helping the > > Python ecosystem move forward. And thank you Miro for python311-rpm!) > > Hello. > > Packaging python3.11-dnf for EPEL 8 and 9 should be trivial, > but it's not a single package. > > $ repoquery -q --repo=c9s-baseos --requires python3-dnf --latest=1 | grep > python > /usr/bin/python3.9 > python(abi) = 3.9 > python3-gpg > python3-hawkey >= 0.66.0 > python3-libcomps >= 0.1.8 > python3-libdnf > python3-libdnf >= 0.66.0 > python3-rpm >= 4.14.0 > > We would need to package (at least) 4 packages: > > python3.11-gpg (gpgme) > python3.11-hawkey and python3.11-libdnf (libdnf) > python3.11-libcomps (libcomps) > python3.11-dnf (dnf) > > There's also a possible usage of the gi.Modulemd module from libmodulemd , but > I've only been able to grep that in tests :/ > > Reproducing the approach from python3-rpm should work, but I haven't tried it. > I am not able to commit myself to maintaining the dnf stack in EPEL for couple > years. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] python311-dnf for el8 and el9
Hi folks, I have some Python apps that "import dnf". I wanted to run these on the parallel Python versions in RHEL 8 and 9, but there's no python311-dnf library available. I haven't looked into this yet. Has anyone else looked at it? I think I'll need something like https://src.fedoraproject.org/rpms/python3-rpm/c/966f38637a7f51376e57b7aeb19a872986a39b8a , but for a "python3-dnf" package? (By the way, thanks Python team for python3.11 in RHEL 8 and 9. That is helpful for moving workloads across RHEL versions and helping the Python ecosystem move forward. And thank you Miro for python311-rpm!) ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RHEL moving to issues.redhat.com only long term
On Fri, Mar 11, 2022, 8:53 AM Peter Robinson wrote: > > On Thu, Mar 10, 2022 at 9:45 AM Colin Walters > wrote: > > > Long term if Bugzilla slowly morphs into only being used by Fedora, > > > personally I'd prefer to have bugs/issues in gitlab instead. > > > > Yes, I personally think gitlab.com would be a good replacement for > > src.fedoraproject.org and bugzilla.redhat.com. > > I disagree as the interface for agile development like sprints, kanban > and other team tools is rudimentary at best and really not suitable > for anything more than the basics and is not a patch on the > functionality and plugin ecosystem that is available in Jira. The > gitlab functionality there is a toy in comparison. > Toys are fun, one of the four Fs for Fedora. I'm not interested in bringing sprints or kanban to Fedora. I am interested in making it fun for volunteers :) - Ken ___ 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: RHEL moving to issues.redhat.com only long term
On Thu, Mar 10, 2022 at 9:45 AM Colin Walters wrote: > Long term if Bugzilla slowly morphs into only being used by Fedora, > personally I'd prefer to have bugs/issues in gitlab instead. Yes, I personally think gitlab.com would be a good replacement for src.fedoraproject.org and bugzilla.redhat.com. - Ken ___ 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: mold linker
On Wed, Mar 2, 2022 at 2:16 PM Jakub Jelinek wrote: > > On Wed, Mar 02, 2022 at 01:29:00PM -0500, Ben Beasley wrote: > > In RPM packaging, of course, everything is built from scratch, usually with > > LTO, and a package that takes a minute to link probably takes an hour to > > build. While any work that can be saved in an RPM build is helpful, I think > > the gains from a fast linker are likely to be much less dramatic here. > > > > [1] https://src.fedoraproject.org/rpms/mold/blob/rawhide/f/mold.spec#_24 > > Note, until a few days ago mold didn't support linker plugins, so was > incompatible with GCC LTO. There is some support in now but still a WIP. > > Linking speed is just one of the factors in choosing a linker, > reliability (e.g. known races in gold which is now effectively unmaintained > are a problem), or what features it supports. > mold doesn't support linker scripts so it is out of question for many use > cases, for other use cases it might matter more how large binaries and with > what security features in it it creates, etc. > I think for building Fedora packages in koji those other factors are much > more important than a few seconds saved during the package build. Some of the Ceph developers were investigating mold, since Ceph takes so long to build. Linking time is a problem for us with Ceph. But I don't know if those interested Ceph developers have done benchmarks yet. And the lack of s390x and ppc64le is problematic for us in Ceph too. But overall I'm amazed at how fast mold development is progressing. - Ken ___ 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: Review swap - python-specfile
On Wed, Feb 16, 2022 at 4:09 AM Nikola Forró wrote: > Hello, > > is there anybody willing to review python-specfile [1]? Your email made me look at this upstream (https://github.com/packit/specfile). It looks interesting! I wonder if we could use it more broadly (like for pyrpkg). It reminds me of https://github.com/containerbuildsystem/dockerfile-parse . I'm looking forward to playing around with this API. - Ken ___ 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
IMA signing notes and code
Hi folks, I've been researching IMA signing with RPM. This is a new feature in CentOS 9 that has not been enabled in Fedora I'm not an IMA expert, and I don't work on this for Red Hat, I'm just an interested user. (In particular, I'm interested in how our build systems track signatures, and how those get passed along the rest of the pipeline.) I'm finding there's no simple "guide to RPM and IMA" where I might contribute further documentation, so for now I've posted my notes and code to https://github.com/ktdreyer/ima It would be great to build some sort of documentation site that explains this stuff, but it's unclear to me what is the RPM team's responsibility vs other teams, etc. See https://github.com/rpm-software-management/rpm-web/issues/28 for example - RPM has a new "FILESIGNATURES" header, but no docs for that. What's a better place for this documentation to live? - Ken ___ 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: IMA signing questions
On Mon, Jan 17, 2022 at 4:44 PM Ken Dreyer wrote:
> Something else I'm wondering: rpmsign writes those four-byte "keyid"
> values to my FILESIGNATURE entries even if I don't have a public cert
> at all. How does it do that? I see verify_rpm.py checks the RPM's
> keyid values against the final four bytes of a sha1 of a public
> certificate, but what if I haven't generated that yet?
I understand this part about public and private certs now.
python-cryptography can read the values from the RSA private keyfile
to determine the public key values.
This Python script will find the IMA-style keyid from a RSA private keyfile:
with open('privatekey.pem', 'rb') as f:
key = serialization.load_pem_private_key(f.read(),
password=None,
backend=default_backend())
public_key = key.public_key()
# The "keyid" is the SHA1 hash of the DER-encoded ASN.1 sequence of the
# modulus and exponent of an RSA public key. (public_key.public_numbers() "n"
# and "e"). This method does it for us:
public_key_id = x509.SubjectKeyIdentifier.from_public_key(public_key)
# The IMA signature's "keyid" is the last four bytes of this SHA1 digest.
ima_keyid = public_key_id.digest[-4:]
print(ima_keyid)
I've been concerned for a while that Koji uses small GPG key ID
values, for the reasons explained at https://evil32.com/
When it comes to IMA signature handling with Koji, I don't want to use
small key ID lengths for that either. Even sha1 is pretty weak now. Is
there any chance of using stronger key IDs for IMA?
- Ken
___
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: IMA signing questions
On Thu, Jan 6, 2022 at 5:17 AM Patrick マルタインアンドレアス Uiterwijk wrote: > > - How do I generate my own new keypair so I can IMA-sign an RPM? > > You can generate the key with the standard OpenSSL commands. > For example, an RSA key can be generated like: > openssl genrsa | openssl pkcs8 -topk8 -nocrypt -outform DER -out > privatekey.der > > (do note that the key will need to be in DER format). Thanks for these tips. rpm-sign complains when I use a DER-formatted key. I switched to a regular PEM-formatted key file, and that works. Looking at libimaevm's read_priv_pkey(), it checks for a "pkcs11:" URI, and if it doesn't find that string prefix, it just calls fopen and PEM_read_PrivateKey. Reading rpm_head_signing/verify_rpm.py it looks like you're sending a DER-formatted file to "evmctl ima_verify". I guess that's where the DER format comes in? Something else I'm wondering: rpmsign writes those four-byte "keyid" values to my FILESIGNATURE entries even if I don't have a public cert at all. How does it do that? I see verify_rpm.py checks the RPM's keyid values against the final four bytes of a sha1 of a public certificate, but what if I haven't generated that yet? Also, on Rawhide, rpmsign fails with an error in EVP_PKEY_sign. Example with a random SRPM: rpmsign --addsign --define "_gpg_name secur...@example.com" --signfiles --fskpath privatekey.pem bash-5.1.8-3.fc36.src.rpm bash-5.1.8-3.fc36.src.rpm: hash(sha1): 9958fb4ee30415c75bd992982ac1463c6ff6ce739e00aaf7d7ad992feb0b40f1 sign_hash_v2: signing failed: (invalid digest length) in EVP_PKEY_sign openssl: error:1C8000A6:Provider routines::invalid digest length error: sign_hash failed error: signFile failed Since this works on CentOS Stream 9, I updated my Rawhide test environment from ima-evm-utils-1.3.2-4.fc36 to the version in CentOS 9 Stream (ima-evm-utils-1.4-4), then rebuilt rpm-4.17.0-4.fc36 against the newer libimaevm.so.3.0.0, and then I could use --signfiles in Rawhide. My builds are at https://fedorapeople.org/~ktdreyer/ima/ . I think the next step is to get ima-evm-utils 1.4 into Fedora. - Ken ___ 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
[EPEL-devel] recent failures with "fedpkg mockbuild" for epel8
Hi folks, When I run "fedpkg mockbuild" for my epel8 dist-git branches, it fails with the following error: Error: Error downloading packages: Status code: 403 for https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/audit-libs-3.0-0.17.20191104git1c2f876.el8.x86_64.rpm (IP: 38.145.60.16) I'm using mock-2.16-1.fc34 and fedpkg-1.41-2.fc34 What should I do to mock-build EPEL 8 packages locally with fedpkg? - Ken ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
IMA signing questions
Hi folks, I want to add "intro to IMA signing" instructions to https://docs.pagure.org/koji/signing/ . I wrote a basic PR at https://pagure.io/koji/pull-request/3206 but it lacks technical details. - How do I generate my own new keypair so I can IMA-sign an RPM? - Can I use my existing GPG keypair? - How do I IMA-sign files in an RPM locally (apart from Koji)? (Is it the --signfiles option from rpmsign(8)?) - How do I inspect the IMA signatures on an existing RPM? - When I gpg-sign an RPM with "Key A" and IMA-sign an RPM with "Key B", does Koji "know" about Key B at all? - Ken ___ 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: Onboarding package
On Tue, Nov 30, 2021 at 2:41 PM Otto Urpelainen wrote: > > Have you considered submitting a link to this to the Koji docs? A while > ago, I tried to set up a dev Koji environment just by following the > docs. Having a pointer to this would have been very useful. No, but that's a good idea! ___ 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: Onboarding package
On Sun, Oct 10, 2021 at 2:33 PM Dan Čermák wrote: > > Maybe we can make a VM image (for KVM/qemu + VirtualBox) with a small > > set of Fedora infra, including Koji+Bodhi. > > How about a vagrant box or a docker-compose file :) > > However, I'm a little worried that this might be too fat or not too > simple to set up automatically (koji itself uses Kerberos for auth, > which by itself is a huge beast…) Here's my Vagrant file that sets up Kerberos and Koji. https://github.com/ktdreyer/koji-playbooks/tree/master/vagrant It's overkill for new Fedora contributors but it helps with setting up dev Koji environments. - Ken ___ 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: API endpoint listing ISOs and checksums for Fedora releases and Rawhide?
On Sat, Oct 16, 2021 at 11:09 AM Richard W.M. Jones wrote: > > Looks like several people have reinvented wheels here because Fedora > doesn't really offer this. I've wanted to make more use of virt-builder. Here is the bug that I last encountered with this: https://bugzilla.redhat.com/show_bug.cgi?id=1834972 It would be great if Pungi (or even a script in https://pagure.io/compose-utils) could generate the virt-builder files automatically. Then the virt-builder indexes would happen for every compose, and the CentOS teams, Fedora teams, etc. could work from a shared tool. I guess the wrinkle there is probably GPG signing, like https://pagure.io/pungi/issue/506 - Ken ___ 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: API endpoint listing ISOs and checksums for Fedora releases and Rawhide?
On Wed, Oct 13, 2021 at 2:21 PM Neal Gompa wrote:
> Unfortunately, we lack a usable equivalent for releases, though that's
> good to know for Rawhide.
For that I use the following URL format string:
https://download.fedoraproject.org/pub/fedora/linux/releases/{version}/Cloud/x86_64/images/Fedora-Cloud-Base-{version}-1.2.x86_64.qcow2
- Ken
___
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: API endpoint listing ISOs and checksums for Fedora releases and Rawhide?
On Tue, Oct 12, 2021 at 3:26 PM Adam Williamson
wrote:
> Hanging over all of this is the threat that PDC might go away at some
> point, which would be a bit of an inconvenience. In A World Where there
> is no PDC, you have to grab the metadata files for composes that still
> exist from kojipkgs; there is no record of the metadata for composes
> that have been garbage-collected. For stable releases you'd have to
> parse whatever metadata you can just out of the actual release tree on
> the mirrors.
Yeah, PDC is a big liability to Fedora at this point and we should run
away from it.
Here's the code I use to download Rawhide images:
get_rawhide_image_url():
# We don't have productmd data available, so we must download COMPOSE_ID
# and interpolate that directly into the assumed URL.
r =
requests.get('https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/COMPOSE_ID')
r.raise_for_status()
compose_id = r.text.strip()
_, _, numeric = compose_id.split('-')
url =
'https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Cloud/x86_64/images/Fedora-Cloud-Base-Rawhide-%s.x86_64.qcow2'
% numeric
return url
- Ken
___
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
[EPEL-devel] Re: python-gevent and pytest-cov in el9
On Sun, Sep 26, 2021 at 2:25 PM Miro Hrončok wrote: > > On 24. 09. 21 21:45, Ken Dreyer wrote: > > This means that python-pytest-cov and python-pytest-xdist won't be > > available on epel9, since those require gevent. > > Ignoring the rest of your email for now, but I don't the gevent dependency > does > not exsist: You're right, gevent is not a runtime requirement. pytest-xdist requires execnet, but execnet only BuildRequires gevent for the unit tests. So we could build execnet on el9 if we disabled %check and the "execmodel=gevent" feature. Maybe that's fine, since https://github.com/pytest-dev/execnet is almost unmaintained upstream, and users have opened unaddressed GitHub tickets in execnet and xdist regarding gevent hangs. This is another reason why I want to reduce Fedora's dependence on pytest-xdist and pytest-cov, if execnet is growing more unstable. - Ken ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-gevent and pytest-cov in el9
On Fri, Sep 24, 2021 at 3:59 PM Josh Boyer wrote: > > https://odcs.stream.centos.org/production/CentOS-Stream-9-20210924.0/compose/CRB/x86_64/os/Packages/libuv-devel-1.42.0-1.el9.x86_64.rpm On the one hand, thank you for pointing out that this build is now available. That's good to know. On the other hand, this points at the bigger issue that dealing with the entire problem of missing packages requires a level of scripting and bookkeeping that is very difficult to keep up when building layered projects. > You could request libev-devel in the composes. The reason I did not do that in this case is that pytest-cov is an optional dependency, and we can just remove it from the Python packages instead. I'd rather reduce the dependencies on gevent to make everything faster. When I looked at gevent in EPEL 8 a month or so ago, it did not look like many packages depended on it. > I remain confused why > it has to be in the compose though, because libev and it's devel > package are accessible in the CentOS Stream 9 buildroots today. We could point at https://kojihub.stream.centos.org/kojifiles/repos/c9s-build/latest/ , but that location will not have GPG-signed builds, and the repo is not currently in https://github.com/rpm-software-management/mock/blob/main/mock-core-configs/etc/mock/templates/centos-stream-9.tpl - Ken ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] python-gevent and pytest-cov in el9
Hi folks, The RHEL 9 composes do not have libev-devel and libuv-devel, so we cannot build python-gevent on EPEL 9 easily. (It's possible to package the missing -devel packages separately, and I've been doing this by automatically following the NVR changes in Stream 9's Koji for several weeks with scripts at https://github.com/ktdreyer/ceph-el9. My conclusion is that it is so painful that it's not sustainable to do this for years.) This means that python-pytest-cov and python-pytest-xdist won't be available on epel9, since those require gevent. Several Python packages require python-pytest-cov because upstream lists it in requirements.txt or tests-requirements.txt. I think we should just patch these out in Fedora. Even apart from RHEL's restrictions, it's not a good use of resources to run pytest-cov when no one reviews coverage reports in the Koji logs, and we'll speed up builds when mock doesn't have to install this spurious BuildRequires. Here are a list of packages where I've removed pytest-cov: https://src.fedoraproject.org/rpms/python-watchdog/pull-request/4 https://src.fedoraproject.org/rpms/python-cheroot/pull-request/15 https://src.fedoraproject.org/rpms/python-portend/pull-request/5 https://src.fedoraproject.org/rpms/python-typing-extensions/pull-request/3 - Ken ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: FF builds
On Fri, Sep 10, 2021 at 2:11 PM Stephen John Smoogen wrote: > Small correction. Miroslav didn't say COPR uses ccache. He said COPR > uses ramdisk for mock. Oh, whoops. Got it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: FF builds
On Fri, Sep 10, 2021 at 9:33 AM Miroslav Suchý wrote: > We use this in Copr. AFAIK Koji does not use it. You can join Fedora infra to > change it :) Is there more documentation about how Copr uses ccache? I was grepping around https://pagure.io/copr/copr for "ccache" and I see the "ccache_enable" plugin config is set to "False". The reason I'm asking is that I'm considering testing mock's ccache plugin within Koji for Ceph. I'm wondering about management, specifically whether we must track and maintain per-ceph-version ccaches. Do you have utilities for examining the caches, clearing them, etc? Do you distribute caches across builders? Anything else we should think about? - Ken ___ 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: FF builds
On Thu, Sep 9, 2021 at 1:01 PM Neal Gompa wrote: > We'd need icecream[1] support enabled in Koji. I am not even sure Mock > (the build engine) supports icecream right now. This is on my list of things to investigate one day. Ceph has the same problem - builder machines with 16GB RAM can barely build Ceph. https://news.ycombinator.com/item?id=25603162 has some other useful info about icecream. - Ken ___ 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: Why so long for EPEL-8?
On Mon, Jul 19, 2021 at 7:06 AM Björn Persson wrote: > > I suspect that many users are like me: I don't want to constantly be a > guinea-pig for the whole testing repository, but if I could be notified > about updates of certain packages I'm interested in, then I could > choose to test those if I'm not too busy at the time. I don't know a > convenient way to do that, so I end up installing updates when they > show up in the updates repository. Exactly. If I see a user commenting in Bugzilla or giving feedback on current Bodhi updates, I make a mental note that the person could be interested in participating in the future. When I push future updates, I'll send them a quick email asking them to test the update and add +1 in Bodhi. It's not perfect but it helps. I recently did this for a random Ceph dependency update to fix a bug, and was very helpful. Sometimes users don't realize it's that easy. - Ken ___ 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
[EPEL-devel] Re: Where should branch requests be filed?
On Thu, Jul 8, 2021 at 11:08 AM Michel Alexandre Salim wrote: > I might eventually extend python-bugzilla a bit to make it easier to > do this. A lot of the operations seem to assume it's a small Bugzilla > instance an would try to pre-load all the components for a given > product. Your comment about pre-loading too much reminded me of https://github.com/python-bugzilla/python-bugzilla/issues/49 . I think some of those things might be historical accidents from earlier Bugzilla APIs that did not give all the information we needed. - Ken ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Updating sources file using fedpkg
On Fri, Jun 18, 2021 at 4:24 AM Vít Ondruch wrote: > > I always use `fedpkg import` and this command has `--offline` option, > which populates the `sources` file without uploading the archives to the > look-a-side cache. Oh, nice, I did not know of that command. Thanks. ___ 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: Updating sources file using fedpkg
On Thu, Jun 17, 2021 at 8:33 AM Richard Shaw wrote: > > On Thu, Jun 17, 2021 at 7:22 AM Ewoud Kohl van Wijngaarden > wrote: >> >> >> To be clear: I don't want to fiddle with the sources file, hence this >> email. However, I would like to at least complete a local mockbuild >> before uploading to the lookaside cache. It is my understanding that >> new-sources always does this. > > > That's actually a nit I've been tempted to complain about. If I'm upgrading a > package to a new version I update the spec file: > > rpmdev-bumpspec -n -c "Update to ." *.spec > > And download the new source: > > spectool -g *.spec > > But then I have to upload the new source with 'fedpkg new-sources' if I don't > want it to download the old version. Yeah, the way I deal with this is I zero out the sources file, like "> sources". Or another alternative that I use sometimes is "sha512sum --tag", like: sha512sum --tag kstart-4.2.tar.gz > sources - Ken ___ 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: Koji query to get the source commit for a build
Does "fedpkg gitbuildhash" do what you want? Source is gitbuildhash() method in https://pagure.io/rpkg/blob/master/f/pyrpkg/__init__.py On Fri, Feb 26, 2021, 5:54 PM Audrey Toskin wrote: > I'm interested in looking up the source used for different builds on Koji > -- particularly the exact commit to the spec file's repo, when building > from SCM -- in a scriptable way. > > `koji list-history` has the most filtering options, so it seems like it > *ought* to work... but I can't figure out how to make it include the > source. Possibly with the `--xkey` or `--show` switches? But neither > `--xkey=source` nor `--show=source` seems to do anything. I can't tell what > the property name would be to get the source commits for a given build here. > > Or, `koji list-tasks` does show the commits -- but it can't filter by > package name, and the full NVR and source commit are on separate lines, so > I'm in regular-expression hell trying to figure out how to grep or sed the > output such that it will show matching pairs of NVRs and source commits... > > Any ideas? > ___ > 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 > ___ 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: Copr in 2020 and outlook for 2021
On Sat, Feb 13, 2021 at 3:06 PM Ken Dreyer wrote: > > On Mon, Jan 4, 2021 at 9:52 AM Miroslav Suchý wrote: > > * Contribute to fedpkg/koji to have machine-readable output. > > There is a "--json" argument to "koji call", and that produces > machine-readable output for individual Koji RPCs. > > It would be really nice if rpkg had something similar, or even an > easier-to-extend Python API. There was an attempt a while back, with > https://pagure.io/rpkg2 . Incidentally I ran into this on another project with a coworker recently, so I opened a ticket to track it: https://pagure.io/rpkg/issue/542 - Ken ___ 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: Copr in 2020 and outlook for 2021
On Mon, Jan 4, 2021 at 9:52 AM Miroslav Suchý wrote: > * Contribute to fedpkg/koji to have machine-readable output. There is a "--json" argument to "koji call", and that produces machine-readable output for individual Koji RPCs. It would be really nice if rpkg had something similar, or even an easier-to-extend Python API. There was an attempt a while back, with https://pagure.io/rpkg2 . - Ken ___ 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: Reproducible builds
On Wed, Feb 3, 2021 at 8:42 PM Neal Gompa wrote: > The Koji build system already records buildinfo data in a slightly > different form, where build IDs are linked to all the inputs that > constructed the build environment as recorded by Koji itself. This > implicitly includes a definition of all the RPM macros that are inputs > for a build, too. There is a presentation about Koji and the reproducible-builds.org effort at https://www.youtube.com/watch?v=wxzGdX5iMgw ___ 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: dropping selinux-policy strict version requirement
Thanks Vit!
That clears it up. It sounds like if we want to support multiple RHEL
minor releases *and* CentOS Stream, we're going to have to compile in
a buildroot that has the oldest version of selinux-policy that we want
to support.
- Ken
On Thu, Jan 28, 2021 at 2:00 AM Vit Mojzis wrote:
>
> Hi,
>
> the exact version requirement is in place to avoid incompatibility
> between the policy on the target system (system you want to install the
> module on) and the custom policy module.
>
> Lets call the policy used to compile your module "A", policy on the
> target system "B" and your custom module "C".
>
> C can be incompatible with B if A contains a new definition (object
> class, permission, type or boolean) that is not present in B and the
> newly defined name is used in your module (e.g. because of an interface
> used in your module). The incompatibility will prevent installation of
> your module ("semodule -i" will fail).
>
> Please see [1] to get an idea of when you can expect new definitions to
> appear in RHEL policy.
>
> Depending on an unversioned selinux-policy-base can therefore cause
> problems not only when installing policy compiled on RHEL to a CentOS
> system, but also when installing it on the same version of RHEL, with
> outdated system policy.
>
> I would at least suggest using dependency on some reasonably recent
> fixed version of selinux-policy-base, and testing each new build of your
> module on a system with that fixed version of selinux-policy-base.
>
> However, it would be best to avoid cross-sytem installations.
>
> Hope this helps.
>
>
> Vit
>
>
> [1] - https://access.redhat.com/articles/4854201
>
> On 1/27/21 6:30 PM, Ken Dreyer wrote:
> > Hi folks,
> >
> > Many applications ship their own "-selinux" sub-package. These
> > subpackages usually set a minimal dependency on the exact
> > selinux-policy version in the buildroot.
> >
> > In Ceph's case, we have:
> >
> >Requires(post): selinux-policy-base >= %{_selinux_policy_version}
> >
> > This version requirement causes problems in two scenarios:
> >
> > 1. If we build Ceph on CentOS Stream, the ceph-selinux package will be
> > uninstallable on RHEL.
> >
> > 2. If we build Ceph on the latest RHEL 8, the ceph-selinux package
> > package will be uninstallable on RHEL 8 EUS.
> >
> > Is it safe to drop the exact version requirement here and just depend
> > on an unversioned "selinux-policy-base"?
> >
> > I can't find any official Fedora Packaging Guideline on this. I opened
> > https://tracker.ceph.com/issues/49034 to track this in Ceph upstream.
> >
> > - Ken
> > ___
> > 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
___
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 deprecated `fedpkg local`
On Wed, Jan 27, 2021 at 9:17 AM Vít Ondruch wrote: > I wonder, what would be the sentiment if I proposed to deprecated the > `fedpkg local` command. I don't think it should be used. Mock should be > the preferred way. Would there be anybody really missing this functionality? Seems like this is a speed-vs-correctness thing. I prefer "fedpkg mock" personally, because it's closer to what Koji does, but it is definitely slower. What if the pyrpkg --help text for the local sub-command steered new users away from "local"? Or at least explained the caveats involved? - Ken ___ 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
dropping selinux-policy strict version requirement
Hi folks,
Many applications ship their own "-selinux" sub-package. These
subpackages usually set a minimal dependency on the exact
selinux-policy version in the buildroot.
In Ceph's case, we have:
Requires(post): selinux-policy-base >= %{_selinux_policy_version}
This version requirement causes problems in two scenarios:
1. If we build Ceph on CentOS Stream, the ceph-selinux package will be
uninstallable on RHEL.
2. If we build Ceph on the latest RHEL 8, the ceph-selinux package
package will be uninstallable on RHEL 8 EUS.
Is it safe to drop the exact version requirement here and just depend
on an unversioned "selinux-policy-base"?
I can't find any official Fedora Packaging Guideline on this. I opened
https://tracker.ceph.com/issues/49034 to track this in Ceph upstream.
- Ken
___
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: GPG check FAILED for libuv on F32
On Wed, Jan 6, 2021, 5:49 PM Kevin Fenzi wrote: > On Wed, Jan 06, 2021 at 10:20:59PM -, Endi Sukma Dewata wrote: > > Hi, there seems to be a problem with libuv on F32. > > It doesn't seem to be happening on F33. Is anybody > > familiar with this? Thanks. > > I'm not sure how this could happen with updates repos. pungi (The tool > that makes them) fails if something isn't signed correctly. :( > > Another f32-updates push is going on right now, lets see if that fixes > it. > > If not, we can investigate more... > > Sorry for any issues. > I saw this as well, and after I ran "dnf clean all", it went away. - Ken > ___ 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: Stale proven packagers
On Sun, Dec 27, 2020 at 7:38 PM Kevin Fenzi wrote: > You can add more than one. Just put them in a file and upload all of > them for 'ssh key' one key per line. There's a limit based on > applications getting the ssh keys, but you can upload multiple keys > fine. Oh, ok! Thanks. ___ 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: Stale proven packagers
On Thu, Dec 24, 2020 at 12:33 AM Dridi Boukelmoune wrote: > > > The weakest point in the current system is really the FAS password. If > > you have a packager's FAS password you can change the ssh key > > associated with the account to another that you control, and the FAS > > password is also all you need to run a build and submit it to Bodhi. > > Or you add an SSH key without removing the maintainer's keys on the > off chance that it would go unnoticed... From what I can tell, the current implementation of FAS does not allow more than one SSH key per user account. - Ken ___ 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: Stale proven packagers
On Tue, Dec 22, 2020, 2:39 PM Adam Williamson wrote: > So that proposal was just for all packagers. I think it should at least > be reasonable to set a relatively high bar for being a provenpackager. Agreed that there's a higher bar here. I think the privilege should be revoked if you've not built anything in Koji for one year. - Ken ___ 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 documentation [was Re: The future of Fedora Server...] Fedora CoreOS a Fedora Edition (System-Wide Change))
On Thu, Dec 10, 2020 at 12:52 PM Matthew Miller wrote: > Thanks for filing this, and I'll highlight it for the modularity team's > attention. Thanks. I also filed https://pagure.io/fm-orchestrator/issue/1629 a while back. I think this could help users understand MBS a bit better. - Ken ___ 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 documentation [was Re: The future of Fedora Server...] Fedora CoreOS a Fedora Edition (System-Wide Change))
On Tue, Dec 8, 2020, 3:18 PM Matthew Miller wrote: > On Tue, Dec 08, 2020 at 08:02:01AM -0700, James Szinger wrote: > > I find the modularity end-user documentation to be woefully > > inadequate, especially for developers. > > Is there a particular part of the documentation you're struggling with, or > something specifically you find missing? I don't mean to be snarky, but I > heard a lot of this complaint at the last DevConf.cz, and then when the > things mentioned were checked out, they actually _are_ covered pretty > nicely > in the https://docs.fedoraproject.org/en-US/modularity/ docs. > Hi Matt, I opened https://pagure.io/fedora-docs/modularity/issue/74 about the docs. We're still using "calc" in the examples, and "lorim ipsum", etc. Which module in Fedora today is the best example of modularity? That one would be a good one to use in the docs. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Fri, Dec 4, 2020, 3:25 PM Matthew Miller wrote: > On Fri, Dec 04, 2020 at 02:16:23PM -0800, Japheth Cleaver wrote: > > be a better-engineered and tested option. But as time goes on and > > the next EL release isn't either isn't announced or isn't stable > > enough to rely on, Fedora Server probably sees more use as a > > quasi-stable release base.. This fills a real need when your users > > are absolutely clamoring for things that aren't likely to be > > backported into the stable EL release and you don't want to have to > > send them into Ubuntu/Debian land (or have them grab an > > un-administered container off the shelf). > > Yeah, we may have an opportunity to do this better with CentOS Stream. > Starting with RHEL 8, there's no more "next EL isn't announced" -- instead, > they're every three years. So, we know when Fedora ELN is going to flow > into > CentOS Stream and from there to RHEL. We could actually position and label > each Fedora Server release by where it fits on the wave of that cadence. > It's too early to say that this hypothetical workflow is a replacement for Fedora. Things still show up in RHEL 8 ahead of CentOS Stream. A strong Fedora Server edition means a strong RHEL Server. - Ken > ___ 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: Self Introduction - Jason Edgecombe
On Sun, Nov 15, 2020 at 5:13 PM Jason Edgecombe wrote: > In my personal time, I'm learning a little about fedora packaging in order > to build some Fedora packages on RHEL8/CENTOS8 for my personal use. I'm > somewhat familiar with RPM spec files and building RPMs. Welcome Jason! - Ken ___ 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 from today's FESCo Meeting (2020-11-11)
On Fri, Nov 13, 2020 at 3:23 PM Matthew Miller wrote: > That reason was _mainly_ to erase the inside Red Hat, > community-around-the-edges distinction. That was a huge success and Fedora > wouldn't be interesting without that. But I think the _technical_ choice was > in retrospect a mistake. There's a reason RHEL 8 switched the _other_ way. It's true that RHEL 8 split content into BaseOS and AppStream, but the technical reasons for that particular split were never clear to me. For example, Fedora users (and release engineers, etc) would have to add multiple repos into kickstarts instead of one. - Ken ___ 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 from today's FESCo Meeting (2020-11-11)
On Thu, Nov 12, 2020, 4:15 PM Matthew Miller wrote: > On Fri, Nov 13, 2020 at 12:07:29AM +0100, Kevin Kofler via devel wrote: > > I still believe that this concept is inherently incompatible with the > idea > > of a cooperative community distribution, and that bringing it up again > and > > again with minimally changed wording is not a constructive thing to do. > > > > I can see why RHEL has a business case for having such "second-class > > citizen" packages, but this is not how Fedora works or should work. > > Well, except, it clearly *does* work that way. We have many > lightly-maintained packages in practice. I think it's better to label them > as such and find positive ways to encourage the collaboration I think we > all > agree is best, rather than the current state where we basically just > pretend > that everything is maintained with high attention. > I'm not sure anyone's pretending. In my experience distros that spilt up into many repos add complexity (and mistakes) on the releng side and a poor UX for the users. If we had labels in Pagure for the packages that you consider to be troublesome, would that help? - Ken > > ___ 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 Next
On Wed, Sep 9, 2020, 6:50 AM Petr Pisar wrote: > On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote: > > To solve this problem, I am proposing that we create a new repository > called > > EPEL 8 Next. > > > > - built against CentOS 8 Stream > > - opt-in for packagers (must request epel8-next dist-git branch) > > - opt-in for users (part of epel-release but disabled by default) > > - used *with* epel8, not *instead of* > > > I agree with all of that. I only don't like the name. Why EPEL 8 Next? If > it > is to be use with Stream, why don't we call it EPEL 8 Stream? I think the > meaning of the repository would be easier to understand. > I was thinking the same thing. EPEL stream is so much easier for users to understand. - Ken > ___ 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: RHEL 9 and modularity
On Fri, Jun 19, 2020 at 9:16 AM Stephen Gallagher wrote: > I love how people hold up "containers" as a solution to these problems > without considering for a moment how exactly the container itself gets > built. If you were to look into the flatpak build system in Fedora, > you'd see that they are using Modularity to construct them. You're right, Flatpak is doing that. Alternatively, my team and I build containers with multiple repos when we want to choose versions of software. "fedpkg container-build --repo-url" takes multiple .repo files. This works well because it uses the standard behavior that we've relied on in Yum and DNF for many years. The corner-cases around dependencies and what-version-overrides-what are well understood across the developer community. This same .repo method works well across RHEL 7, RHEL 8, and beyond. The .repo files are extremely flexible and can come from a variety of systems that are not MBS. Contrast this with the way that OSBS and ODCS work. The current implementation is misleading, and the reason I say this is because several independent teams recently arrived at the same erroneous conclusions around how developers are supposed to use modules with OSBS and ODCS: https://github.com/containerbuildsystem/osbs-docs/pull/152 - Ken ___ 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 Thu, Jun 18, 2020 at 1:27 PM Josh Boyer wrote: > I don't think burst-to-cloud means we only burst to a single cloud. > That seems like a great way to just lock into that cloud with no > flexibility. Rather, I would look at it as a hybrid cloud opportunity > and use AWS, or the IBM cloud that offers s390x instances, or Packet > for ARM, etc. Right, I think the challenge here is that multi-cloud is a hard requirement for a first implementation to be viable. (libcloud really helped Ceph out here). - Ken ___ 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 Thu, Jun 18, 2020 at 10:31 AM Josh Boyer wrote: > Personally, I have long wanted burst-to-cloud or the ability for > others to donate hosts to the Fedora build system without having to > physically ship hardware. Koji is somewhat limited in that regard. > Maybe developing a shim layer and some security best practices to > allow that would help. I'm interested in this because I think it would make Koji more flexible, and there are some challenges. I think we would need a separate Koji daemon to watch the task queues on the hub and bring additional builders up or down as needed. Maybe an OpenShift operator could do this. Non-x86_64 arches are complicated as well, because not all cloud providers have s390x (for example). A service needs to inspect the Koji buildArch task parameters to determine what arches to bring up, and that's just for RPMs - we'd need code to do it for the VM image tasks, containers, etc. Do you have specific vendors lined up who would donate build hosts? In the Ceph project, we have something like what you're describing with libcloud and Jenkins. Our CI build hosts' costs were wildly expensive compared to our bare metal hosts, and the performance can be variable/worse. At a certain point, there is a constant baseline load in the buildsystem, and it makes sense to run as much of that on our own hosts as we can. - Ken ___ 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: Modules again
It is amazing to me how often this setting makes things work. It seems like we're hard-coding this to "1" more widely. On Tue, May 19, 2020, 12:01 PM Paul Howarth wrote: > On Tue, 19 May 2020 09:21:46 -0700 > Kevin Fenzi wrote: > > > On Tue, May 19, 2020 at 11:48:04AM -0400, Stephen John Smoogen wrote: > > > On Tue, 19 May 2020 at 11:05, Paul Howarth > > > wrote: > > > > On Tue, 19 May 2020 09:07:30 -0400 > > > > Stephen John Smoogen wrote: > > > > > > > > > On Tue, 19 May 2020 at 06:05, Paul Howarth > > > > > wrote: > > > > > > > > Yes, I'm using vanilla configs straight from mock-core-configs for > > > > this, and that has epel-8-x86_64.cfg, which pulls in centos-8.tpl, > > > > which has the PowerTools repo defined and not disabled. > > > > > > > > (I generally use my own configs and don't touch the original > > > > ones, so I know that if I try the original ones from upstream > > > > then they should work as intended) > > > > > > > > Note that the error message doesn't say it can't find Judy-devel, > > > > it says that it (and Judy) is/are excluded. I don't know why that > > > > is. > > > > > > > > > > > Ohhh sorry. I missed the obvious. I am going to guess from past > > > problems, the system is trying to pull in mariadb which filters it > > > out and mariadb-devel which has it in. So when it sees the filters > > > it says 'nope can't do this sorry'. I wish there was a 'no I know > > > it might break my system do it anyway!' flag but I don't see one > > > looking through /usr/share/doc/mock/site-defaults.cfg . This was > > > one of the reasons for grobisplitter being used. > > > > You should be able to set: > > > > module_hotfixes = True > > > > in your dnf/yum/mock config. > > > > From the dnf man page: > > > > "Set this to True to disable module RPM filtering and make all RPMs > > from the repository available. The default is False. This allows > > user to create a repository with cherry-picked hotfixes that are > > included in a package set on a modular system." > > Ah, setting that option for the PowerTools repo allows the build to > work. Now if only there was a way to do that from the command line so I > didn't have to touch the mock config. > > Thanks! > > Paul. > ___ > 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 > ___ 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: Is dist-git a good place for work?
On Wed, May 13, 2020 at 4:29 PM clime wrote: > Probably there are more variants but I see these three right now. I > think variants 1 and 2 where the spec file is kept in dist-git but > patches can be in source-git are more within our reach right now (but > I might be wrong, variant 3 is also interesting). I think the best approach is to try your ideas on many different real Fedora packages from many different upstreams, and refine the tools as you go, documenting what works and what doesn't. Tools like tito and rdopkg have the advantage of having been tested and hardened across many different packages, Fedora releases, and RHEL versions. In relation to rdopkg, I forgot to mention that Debian's git-buildpackage tool uses a patch management model that is almost identical to rdopkg for RPMs. Debian packagers create "patch-queue" branches from the upstream project, and git-buildpackage can write out a quilt-formatted series of .patch files into the debian packaging. It is pretty fast to manage a large series of downstream patches this way, rebase to new versions, etc. - Ken ___ 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: Is dist-git a good place for work?
On Tue, May 12, 2020 at 6:20 PM clime wrote: > When you do rdopkg new-version and you are asked to force push, is > also the current master-patches HEAD tagged with the current package > NVR? It's something that I have to do before I run "new-version". Here's the command I ran today: $ rdopkg tag-patches --push And rdopkg performed the following commands for me: git tag python-jenkins-job-builder-3.2.0-1 master-patches git push patches python-jenkins-job-builder-3.2.0-1 You can see the new tag here: https://fedorapeople.org/cgit/ktdreyer/public_git/python-jenkins-job-builder.git/log/?h=master-patches rdopkg read the current NVR, tagged the tip of the master-patches branch for me, and pushed that tag to the patches remote. > Somewhere I was expecting to see a lot of NVR tags for past sate of > master-patches (i assume, you could have also f32-patches, > f31-patches, epel8-patches, ... ?) but I don't see those tags :) that > would form the mentioned "history of histories". You're correct, rdopkg supports branch names like "f32-patches", "f31-patches", and "epel8-patches". In my case I only needed to patch Rawhide, so I created "master-patches" there. You're right that I didn't create a ton of NVR tags. This package is a super trivial example where I only started using this model to fix a FTBFS, so I did not tag every NVR. The reason I did this was because there are only a few patches and I did not expect to keep them in Fedora very long, because I can easily rebase Rawhide to 3.3.0 soon, and the upstream authors were going to ship 3.3.0 soon. When we ship an unpatched upstream release, there's less utility to tagging the NVR like that. For the ceph package in RH Ceph Storage, we've tagged over three hundred NVRs with this system. We could probably go back and check which old builds koji-gc has deleted, and then delete those Git tags as well, if we want to clean up the ones that we never shipped. - Ken ___ 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: Is dist-git a good place for work?
On Tue, May 12, 2020 at 1:45 AM clime wrote: > > Ken, would it be, please, possible to provide links to the patch > branches and mentioned dist-git repos. I would like to have a closer > look. Sure. I can't share the links to the RH Ceph Storage dist-git repos, so I will give one example where I used rdopkg in Fedora recently. Here is an example where I bumped the version of a Python package and included some cherry-picked patches: https://src.fedoraproject.org/rpms/python-jenkins-job-builder/c/78b70d24cf65a4c7a100d3e56358ae22d3a6eaf6?branch=master At first glance, the two new patches I included there look like the output from "git-format-patch", and that is because rdopkg wraps git-format-patch for some operations. rdopkg automatically inserted those into the .spec file, and it also formats them with some compatibility options to preserve the .patch file formats between RHEL 7's Git 1.8.3.1 + RHEL 8's Git 2.18.2 + Fedora's Git, so that it does not matter what OS the packager is running. So that's the change in "master" (dist-git's rawhide branch), and there is a corresponding "master-patches" branch to go along with that: https://fedorapeople.org/cgit/ktdreyer/public_git/python-jenkins-job-builder.git/?h=master-patches In my dist-git clone on my laptop, I have three remotes, set up like this: $ git remote -v originssh://ktdre...@pkgs.fedoraproject.org/rpms/python-jenkins-job-builder (fetch) originssh://ktdre...@pkgs.fedoraproject.org/rpms/python-jenkins-job-builder (push) patches ssh://fedorapeople.org/home/fedora/ktdreyer/public_git/python-jenkins-job-builder.git (fetch) patches ssh://fedorapeople.org/home/fedora/ktdreyer/public_git/python-jenkins-job-builder.git (push) upstreamhttps://opendev.org/jjb/jenkins-job-builder.git (fetch) upstreamhttps://opendev.org/jjb/jenkins-job-builder.git (push) "rdopkg new-version" will update to the latest upstream version for me. Specifically it looks at the upstream repo, finds the latest Git tag, parses that tag string into a number, writes that number into the .spec file, downloads and uploads the new upstream tarball, etc. It will also rebase my "patches" branch for me and edit the Patch entries as necessary. I haven't done that today for the sake of this example, but at some point in the future I will run "rdopkg new-version", and it will pull in 3.3.0 and eliminate those two patches, since they're both included in version 3.3.0 upstream. In fact, you can try it on your computer if you set up the Git clones like I've done above. If you run "rdopkg new-version", then rdopkg will rewrite the "master-patches" branch, and then prompt you to force-push this to the "patches" remote. You won't have SSH access to push to my fedorapeople.org repo, so just imagine that is a team repo where many people on my team can push :) This just a really simple example with two patches in one small package. - Ken ___ 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: Is dist-git a good place for work?
On Sun, May 10, 2020 at 11:51 PM Petr Pisar wrote: > How do you backport fixes? Do apply the fixes directly to dist-git? Or do you > apply the fixes to a corresponding patches branch that you occur to have > around till needed (e.g. till the hitorical code is supported) for the purpose > of backporting? It's the latter. We use "git cherry-pick" to pick changes to our "patches" branch, and then "rdopkg patch" writes those as .patch files and PatchXXX entries in our .spec file in the corresponding dist-git branch. At a general level, a typical Fedora packager performs three kinds of operations in dist-git: 1) Rebasing to a new upstream version (eg. bumping the "Version" field in httpd.spec from 2.4.43 to 2.4.44) 2) Fixing something in RPM packaging itself (eg. removing "Groups" from httpd.spec file, fixing %check, etc) 3) Patching the source code (eg. cherry-picking a patch from upstream). The current implementation of dist-git allows everyone and anyone to very clearly audit all three of these actions. This kind of transparency is really important to Fedora's goal of building a trusted operating system. Upstream projects do ninja edits all the time. It's just too convenient to force-push or move Git tags, etc. Sometimes upstream authors have valid reasons for doing that kind of thing, but downstream we have different incentives. The fact that we have strong history preservation guarantees is one of the reasons I use Fedora. rdopkg has sub-commands to automate each of the three categories above. For #3 (patching), in RH Ceph Storage we run the "rdopkg patch" operations in Jenkins, because that is the most common operation by far. I'm watching packit, and I am interested to try it out one day to understand more about how it compares. I'm still not clear from this thread what source-git is, or how it compares technically to what we're doing with Ceph and OpenStack. - Ken ___ 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: Is dist-git a good place for work?
On Wed, May 6, 2020 at 2:24 PM Simo Sorce wrote: > > Well, a way to allow force pushes would be to have a git hook that > branches the tree before the force push. (creating a branch named > something like audit-force-push-) In Ceph we do this at a slightly different point of time. We use "rdopkg tag-patches" to save each of the "patches" refs that we've translated into patch series in dist-git. Each Git tag is the NVR of the package. We rebase and force-push our "patches" branches frequently, so a patches branch is one "history", and dist-git becomes a "history of histories". It's critical to have this flexibility + auditability so we can move fast and still go back and reproduce everything. - Ken ___ 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
proxying fedora mirrors with HTTPS
For several years I've run my kickstart installs through a squid proxy that caches packages that I download. My kickstarts have something like this: url --url=http://mirror.chpc.utah.edu/pub/fedora/linux/releases/31/Everything/x86_64/os/ --proxy=http://squid.example.com:3128 As I test many repeated Fedora installs in my network, I can rely on Squid's caching, so the packages download faster and I put less load on the Fedora mirrors. This all happens over plaintext HTTP, and as I do more Fedora automated installs, that's concerning. Is there any easy way to do similar package caching with a Fedora mirror that provides HTTPS? I read https://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpExplicit . I think I would use this to have Squid to generate and sign its own certificates for the Fedora mirror host on the fly? I see pykickstart supports https URLs for --proxy, so I think I can just do --proxy https://squid.example.com:3128 ? I don't understand how I would get the installer to trust my custom CA to communicate with the HTTPS proxy, though. Am I headed in the right direction? Has anyone else done something like this? - Ken ___ 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: Kerberos authentication fails: unable to obtain a session
On Tue, Mar 10, 2020 at 11:55 AM Kevin Fenzi wrote: > > when you see a proxy name there it usually means you have rdns true in > /etc/krb5.conf (it should be false), or krb_rdns or krb_canon_host true > in /etc/koji.conf or ~/.koji.conf (should be false). I think those options only apply to the "old-style" Kerberos authentication in Koji (that we want to remove upstream). The only way to affect the GSSAPI authentication that we do with koji.fedoraproject.org is to edit [libdefaults] in /etc/krb5.conf. I've filed two tickets to improve the UX here: 1) Remove the old option from fedora.conf: https://bugzilla.redhat.com/show_bug.cgi?id=1812702 2) Better error messages from the koji gssapi_login method: https://pagure.io/koji/issue/2063 I think the MIT Kerberos devs realize that this is a problem too, because there is a new dns_canonicalize_hostname=fallback option in krb 1.18. That option will help for the general case of proxying applications that use GSSAPI auth. - Ken ___ 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: URGENT: users prompted to upgrade to F32
On Mon, Feb 17, 2020 at 10:52 AM Adam Williamson wrote: > Since this is an API endpoint of a real system which needs to be > updated correctly when the release events actually happen, it should > have the benefits pkgdb used to be (the information should be reliable > and timely) Do we have stats on how many hits per second that current endpoint receives? It would be a bummer to inadvertently bring down Bodhi because of this feature. What do you think about having Bodhi write out a flat file to disk or something for Apache to serve in a similar way, so it doesn't have to go through mod_wsgi or touch the database for that URL? - Ken ___ 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: Proposed official change to EPEL guidelines: modules and RHEL
On Thu, Feb 13, 2020 at 5:54 AM Matthew Miller wrote: > > In EPEL 8 or later, it is permitted to have module streams which contain > packages with alternate versions to those provided in RHEL. These packages > may be newer, built with different options, or even older to serve > compatibility needs. These MUST NOT be the default stream -- in every > case, explicit user action must be required to opt in to these versions. Is there any chance that a module in EPEL 8 will be named identically to a module in RHEL 8? If that happens, what is the process to choose between RHEL's module and EPEL's module? This is not entirely hypothetical :) We face this situation if we consider putting Ceph into a module in RHEL 8 and a module in EPEL 8. - Ken ___ 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: Koji build failure from missing tarball
On Fri, Feb 7, 2020 at 3:19 PM Kevin Fenzi wrote: > > On Fri, Feb 07, 2020 at 01:46:26PM -0700, Ken Dreyer wrote: > > I'm not sure where to report such an RFE. Is > > https://github.com/release-engineering/dist-git right? > > yep. Exactly the right place. Thanks, I opened https://github.com/release-engineering/dist-git/issues/27 - Ken ___ 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: Koji build failure from missing tarball
On Fri, Feb 7, 2020 at 3:48 AM Lubomír Sedlář wrote: > It seems you accidentally uploaded the source RPM instead of the > tarball. Simply run fedpkg new-sources on the correct file and push the > new sources file. The build should then work. Can we have a blacklist on the dist-git lookaside server to block "src.rpm" files? I'm not sure where to report such an RFE. Is https://github.com/release-engineering/dist-git right? - Ken ___ 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: Copr Build System - review of 2019 and vote for features in 2020
On Thu, Jan 23, 2020, 9:04 AM Stephen John Smoogen wrote: > On Wed, 22 Jan 2020 at 06:04, Kevin Kofler wrote: > > > > Kevin Kofler wrote: > > > IMHO, this whole "delete by default" concept is inherently flawed and > > > dangerous and cannot be fixed. Notification e-mails can be lost in so > many > > > ways (wrong Fedora notification settings, e-mail provider issues, spam > > > filter false positives, out-of-quota mailbox, etc.) or be missed due to > > > being offline for a prolonged period of time. It should never be > allowed > > > to delete users' data without their explicit confirmation. Especially > in > > > this case where it is not even possible to reupload the data because > Copr > > > can no longer build for those EOL chroots (which is another quite > annoying > > > limitation of Copr – allowing to build for EOL releases would also > allow > > > people to try backporting select security fixes to those releases > Fedora > > > no longer wants to support). > > > > PS: I also think that at the very least, there ought to be a way to > > permanently opt-out a Copr repository out of all future cleanups. Some > Coprs > > such as the Kannolo Copr should just always be preserved. > > > > I also do not understand why 6 TB of disk space is such an issue in times > > where one single HDD can carry up to 16 TB. > > I think I have written something like the following every 3-4 years. > Every time newer larger disks come out there is some sort of magical > effect which makes people forget why that doesn't solve the problems > that koji, copr and mirrors have when dealing with storage. > > 1. A single disk can carry a lot of data, and can be reasonable fast > to get for 1 person. However start adding more people and different > size read/writes and that disk will drop completely. > 2. SATA disks are cheap, but they are very expensive to use because > the logic on the controller and disk are dumb. Add different > read/write sizes like you do for a large number of users and the > actual performance dies. > 3. Money for hardware, software and the place to put said > hardware/software needs to be accounted for and so just because you > ran out of disk space.. you will have to wait until the next business > cycle to get money to buy it. You will also be competing with every > other group who want money for their things too. This isn't any > different from a University or a company. > > So we could go buy 1-4 very large disks and no person using COPR will > never see anything you compiled because they and 10k other charging > bison will be trying to get data from the disks. The IO falls through > the floor or becomes a square wave form. I say this from experience of > trying this experiment several times because someone read that they > could buy 4 and it would quadruple what > they could get from our shared storage. Then we go through all the > magical kernel and filesystem options that they found which 'make it > work for someone else'.. and then we end up having to either buy more > disks because the fundamental problem is that drinking a milkshake > through a single cocktail straw doesn't work very well. You need more > cocktail straws or a bigger straw or something less thick than a > milkshake. > > So you need more read/write heads to get the data to people in a way > which is acceptable for their own patience. We can do that normally > with 8 SAS disks (expensive smaller disks with a lot more onboard > logic to control data-ordering problems ) or 12-16 SATA disks to get > the same IO performance. With SATA arrays you end up with un-usable > space if you are being actively reading/writing a lot. Yes you have > 200 TB in that array.. but you can only effectively use 40 to 100 TB > at a high IO rate. With SAS you are pretty much at what you have is > what you can use. If you have a workload like backups or something > similar where you are only doing writes, or only doing reads for a > SMALL number of processes you can also use a large SATA array and use > all of it. If instead you are using it for a lot of processes wanting > lots of different data or writing different data (aka COPR), you > effectively starve yourself by using it all because there is not > enough bandwidth. [I guess an analogy would be to be using the 36+ GB > memory sizes on a 32 bit processor. > I'm not trying to suggest that Ceph would be a magic bullet here, and it comes with its own costs. Nevertheless since I work on the RH storage team, it occurred to me that the performance and scale problems that you've touched on are exactly the problem space that the Ceph project tries to address. - Ken ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
On Thu, Jan 30, 2020 at 3:59 PM Robbie Harwood wrote: > Richard Shaw writes: > > > Not replying to anyone in particular but to the thead as a whole... > > > > 1. Nothing in the packager introduction process prepares a packager > > for what to do when they get a CVE filed against one of their > > packages. I found the whole ordeal rather stressful. > > Agreed, this would be good to spell out. > > > 4. I'm not a C/C++ programmer > > Maybe I'm missing something, but why is being a C/C++ programmer > relevant to fixing security bugs? Are you packaging programs in a > language you don't speak? Yes, I do that all the time. It's how I learn new things. It's already intimidating for a new Fedora user to become a "Fedora developer". Let's make that funnel of users->contributors wider. - Ken ___ 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 for better development processes when maintaining hundreds of packages
On Wed, Jan 29, 2020 at 7:18 AM Remi Collet wrote: > There are different: > > * Changelog is for end user > * Git log is for package maintainer I completely agree with this distinction. We're creating more "noise" for end users if we end up adding all the "whoops" commits into the %changelog. And asking maintainers to add "[skip]" strings or whatever into the Git commit logs adds yet another magic/manual thing that packagers must learn. This is why rdopkg writes the dist-git commit messages from the RPM %changelog instead of the other way around. For example I can write or modify my message in %changelog, run "rdopkg amend", and it automatically updates my dist-git message to match what I wrote in %changelog. I have not had to copy-and-paste information from %changelog into the dist-git message in years. > > * committing to git should build the package > > > > Is there a reason why this wouldn't be the case? > > Yes, because I often commit various changse "before" the build > (some being cherry-pick on other branch, some not) This one I happen to disagree with. I've set up a Jenkins job that automatically builds on another (non-Fedora) Koji instance for a large number of packages, and it is fantastic to never worry about remembering to run "rpkg build" by hand any more. I trigger the builds on the "push" bus messages though, instead of building every single commit. If I'm making many small changes, then I'll commit them all to Git locally, then push them all at once. When other developers don't follow that practice of batching up their commit pushes, it does mean that Koji ends up building a lot more frequently, and we trigger composes more frequently throughout each day... but frankly that leads to some other advantages, because it makes things more "continuous" overall. > IMHO, remember KISS, and don't try to add more magic to our tooling > > And I really prefer to see stabilization of our current tools and > infrastructure before breaking it again. I completely agree with this Remi. We're still suffering from the loss of pkgdb's features. I would prefer to fix what's broken before trying to mess with changelogs and end up with something half-baked. - Ken ___ 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: Not a bug (was: Re: Can't log into Koji)
On Sat, Jan 18, 2020 at 5:09 AM Richard W.M. Jones wrote:
>
> On Sat, Jan 18, 2020 at 12:02:08PM +, Richard W.M. Jones wrote:
> >
> > $ KRB5_TRACE=/dev/stderr koji -d hello
> > 2020-01-18 12:00:47,323 [DEBUG] koji: Opening new requests session
> > 2020-01-18 12:00:47,323 [DEBUG] koji: Opening new requests session
> > 2020-01-18 12:00:47,619 [DEBUG] koji: Opening new requests session
> > 2020-01-18 12:00:47,619 [DEBUG] koji: gssapi auth failed:
> > requests.exceptions.SSLError:
> > HTTPSConnectionPool(host='koji.fedoraproject.org', port=443): Max retries
> > exceeded with url: /kojihub/ssllogin (Caused by
> > SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED]
> > certificate verify failed: unable to get local issuer certificate
> > (_ssl.c:1108)')))
> >
> > Traceback (most recent call last):
> > File "/usr/bin/koji", line 336, in
> > rv = locals()[command].__call__(options, session, args)
> > File "/usr/lib/python3.8/site-packages/koji_cli/commands.py", line 7372,
> > in handle_moshimoshi
> > activate_session(session, options)
> > File "/usr/lib/python3.8/site-packages/koji_cli/lib.py", line 571, in
> > activate_session
> > session.krb_login(proxyuser=runas)
> > File "/usr/lib/python3.8/site-packages/koji/__init__.py", line 2258, in
> > krb_login
> > if self.gssapi_login(principal, keytab, ccache, proxyuser=proxyuser):
> > File "/usr/lib/python3.8/site-packages/koji/__init__.py", line 2415, in
> > gssapi_login
> > raise AuthError('unable to obtain a session')
> > koji.AuthError: unable to obtain a session
>
> Sorry, not a bug. I remembered that I had put some alternate
> certificates into ~/.koji to access another Koji instance.
I think there is a usability RFE here. If we get an SSLError *and* the
Koji client is configured to use one specific CA bundle file on disk,
then we should log that path to the CA file we used.
- Ken
___
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: What would it take to drop release and changelog from our spec files? (and do we want to?)
On Fri, Jan 10, 2020 at 9:37 AM Pierre-Yves Chibon wrote: > Thus our call for input to accept or reject the idea and if the former > scope/define the system. Whatever you decide, please try it out on a small set of packages that you personally maintain for a long time. This "field testing" will ensure that you're covering all the corner cases that you know about (and many of the ones that you do not). With the packages I maintain with rdopkg, we generally do it the other way around: We write a human-readable %changelog entry, and then "rdopkg amend" will amend my dist-git commit log to match the text that I wrote in the .spec file. - Ken ___ 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: Non-responsive maintainer tchaikov
I work on a team at Red Hat with Kefu. He is very active with upstream Ceph, though I have not watched his Fedora activity or lack thereof. Is there a particular Fedora bug that you need Kefu to address? - Ken On Tue, Dec 17, 2019, 4:59 AM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > Hello. > > According to non-responsive maintainer procedure for tchaikov, I'm > asking here if anyone know how to reach out for the maintainer. > > RHBZ ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1778081 > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.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 > ___ 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: "python3" vs "python%{python3_pkgversion}"
On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa wrote:
>
> On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer wrote:
> >
> > Hi folks,
> >
> > In EPEL 7 we have some packages with "python34" and "python36"
> > prefixes in their names. I guess this is a consequence of using the
> > %{python3_pkgversion} macro over time.
> >
> > Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
> > EPEL 7, I'm wondering about this.
> >
> > If I'm introducing a Python 3 subpackage in a new build today, should
> > I name this sub-package "python3-foo" or
> > "python%{python3_pkgversion}-foo" ?
> >
>
> The subpackage should be "python%{python3_pkgversion}-foo" and you
> should also make sure you have "%{?python_provide:%python_provide
> python%{python3_pkgversion}-foo}" in the subpackage declaration too.
This is confusing to me, and it diverges from what Fedora does. Can we
just reduce this down to "python3-" now that RHEL 7 has python3, and
we'll probably never put another Python version into EPEL 7?
- Ken
___
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
[EPEL-devel] "python3" vs "python%{python3_pkgversion}"
Hi folks,
In EPEL 7 we have some packages with "python34" and "python36"
prefixes in their names. I guess this is a consequence of using the
%{python3_pkgversion} macro over time.
Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
EPEL 7, I'm wondering about this.
If I'm introducing a Python 3 subpackage in a new build today, should
I name this sub-package "python3-foo" or
"python%{python3_pkgversion}-foo" ?
- Ken
___
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 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Tue, Oct 15, 2019 at 10:13 AM Adam Williamson wrote: > What's happening right now is the process of us trying something out > and finding out where the problems are. That's what happens when you > invent new stuff, it's harder than just carrying on doing the old > stuff. I agree Adam. I think Neal's summary helps and I appreciate it. I agree it's negative, but I think there is one additional aspect from my point of view: There are some proponents of Modularity that keep pitching the idea to me that everything I do needs to go into a module, like, yesterday. Maybe we can tone that messaging down a bit around Fedora for a while. - Ken - Ken ___ 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: Defining the future of the packager workflow in Fedora
On Thu, Sep 26, 2019 at 7:11 AM Pierre-Yves Chibon wrote:
>
> On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > Here is what the vision we came to and that we would like to discuss:
> > >
> > > ○ Every changes to dist-git is done via pull-requests
> >
> > IMHO Have to stay optional, making this mandatory being a terrible headache.
>
> What makes it a headache? What can we do to not have this be a terrible
> headache? Can we fix/improve the tooling?
One of the reasons I push directly to branches in Pagure instead of
opening Pull Requests is that the workflow is too clunky and slow. I
have to toggle between the browser and the console, make sure I have a
Fedora Kerberos ticket, etc.
Please get a stopwatch app and try the following workflows in GitHub
and Pagure, and compare the speed at which you can do these:
- Create a new personal fork of a repository
This is almost instant on GitHub, and much slower in Pagure,
sometimes hanging entirely at the "waiting..." web page.
- Push a hundred commits to a topic branch
GitHub can accept the ref updates very quickly, and Pagure has so
many hooks and operations that I've seen my Git client hang for
seconds or sometimes even minutes. I'm not sure what is going on, but
I suspect it involves ACL checks, Fedmesg, etc. I've seen this one
several times: I forked a project a year ago and I did not update my
forked copy of "master". I push a new topic branch to my clone, and
this topic branch has all the changes from todays' upstream master,
plus my new changes for the topic branch. When I run "git push" for my
new topic branch, Pagure.io will process all of those commits
one-by-one and emit fedmsgs for all of them *according to my old
version of master, not upstream*. I have no idea if that is single
reason for why I see my "git push" commits return very slowly, but it
is probably one of the reasons.
- Open a new pull request
The GitHub web UI provides a lot of different buttons in a lot of
different places, allowing the user to fall into the "pit of success"
and submit the change upstream. GitHub always immediately knows "hey
this branch is ready to go upstream, do you want to open a PR?" With
Pagure, the UI to open a pull request requires many different clicks,
and if I open it from certain pages (like the origin repository), the
web UI makes some AJAX calls that just hang forever. GitHub also has a
really mature CLI ("hub") that makes opening PRs lightning quick
because the GitHub's REST API responds very fast.
You might wonder why I've not opened tickets for these, and it's
because I am not sure it's worth piling on your team when you guys are
already extremely overloaded. The UX problems I've encountered do not
strike me as trivial issues to resolve in an afternoon. Sometimes I
ask in #fedora-admin if it really looks like I've broken something.
Maybe that's lame and I should just open the tickets. I also have a
bigger concern though: I've played around with pygit2 in some smaller
applications in order to learn it, and I'm beginning to think that
it's simply not possible to get close to the performance and
functionality that GitHub has achieved.
I would like to hear if you see Pagure as still strategic, and if so,
how we can make these common user operations faster.
- Ken
___
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: two Ceph updates for f28, f29, stuck in pending testing for six days
On Fri, Mar 22, 2019 at 1:08 PM Kevin Fenzi wrote: > > Fixed, and I looked and asked upstream and this is fixed in sigul 1.0. > > So, hopefully we won't have to keep doing this too much longer. Thanks for digging into this! ___ 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: Scratch build uploads to koji VERY SLOW
I guess this depends on the status of the Apache httpd workers. Like are they stuck in IO to the /mnt/koji scratch location, or something else? Unfortunately it's not secure to publicly display Koji's in-flight HTTP requests with mod_status, since the URLs contain the authenticated session information, but that's where I'd go for the next level of investigation if this happens frequently. Maybe we need a separate utility in kojiweb to sanitize the hub's mod_status' output for the public and display "what's the hub doing now". - Ken On Thu, Mar 7, 2019, 12:08 PM Richard Shaw wrote: > On Wed, Mar 6, 2019 at 6:39 PM Kevin Fenzi wrote: > >> On 3/6/19 4:14 PM, Richard Shaw wrote: >> > >> > New since the last couple of weeks but I've been more active working on >> > FTBFS issues so can't say exactly when it started. It's never been super >> > speedy but also never been this painful. >> >> Odd. I can't think of anything on the server end that has changed >> recently that might cause this. It's just as fast as always for me. >> >> Has curl been updated on your machine(s) around the time it started? >> >> Does koji --debug build scratch tag src.rpm >> > > Hah... just tried it and the srpm uploaded at >1MB/sec... > > Thanks, > RIchard > ___ > 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 > ___ 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: modular repositories in mock configs: please don't
On Tue, Mar 5, 2019, 12:53 PM Miroslav Suchý wrote: > Dne 04. 03. 19 v 17:34 Ken Dreyer napsal(a): > > > > I'm there with you Richard. I don't really get how I can get started > building a module outside of the Fedora > > infrastructure's system (Koji or Copr). > > In fact, Copr support building modules for ages - even before the > modularity has been finalized. > > You just create project in Copr, build regular packages there. Then you > click on "Modules" tab, then "Create new > module", select which packages should be part of module and submit the > form. Few seconds later your module should be ready. > > Copr does not support all features of modularity, because the format of > modules changed every few week and it was hard > for us to keep pace. But you are simply build simple module in Copr. > What I meant was that I don't know how to do this outside of Koji or Copr. My use cases: * I want to experiment on my laptop, * I want to build modules I cannot distribute through Copr, * I have a large project with many changes every day, and if I sent all of those into copr.fedoraproject.org via Jenkins, it could melt down With Fedora regular RPMs, fedpkg has "mockbuild" to do local builds. How can I do something similar on my laptop for a module? ___ 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: modular repositories in mock configs: please don't
On Fri, Mar 1, 2019, 8:26 AM Richard Shaw wrote: > Not replying to anyone in particular but just a nit for me... > > I've been a Fedora packager for probably 10 years now (need to check!) but > I *STILL* don't really understand modules other than at a high level (it > lets you use dependencies that aren't available in the main repos). I've > read through some of the documentation but it's still not clear. I know I > would have to crate some kind of module file which I think tools could be > developed to mostly automate (spec->module template converter?). > > While modularity is more of a Fedora thing I think it's sad that for more > standard tools I reference Arch documentation more often than Fedora > documentation. Of course there's the, "I could help with that" part and I > might, but frankly I can barely keep up with my packages between $DAYJOB, > $FAMILY, Fedora, and RPM Fusion. > I'm there with you Richard. I don't really get how I can get started building a module outside of the Fedora infrastructure's system (Koji or Copr). I'm hoping this gets a lot clearer after modules come in RHEL 8 and we get concrete examples. - Ken ___ 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: Fedora 31 System-Wide Change proposal: Gating Rawhide - Single package updates
On Fri, Mar 1, 2019, 3:20 PM Ben Cotton wrote: > > ** infrastructure: deploy the new version of bodhi and the new koji plugin > What's the new Koji plugin? - Ken ___ 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: python-cherrypy vs python3-cherrypy - can we keep just one?
On Fri, Feb 15, 2019 at 1:10 AM Matthias Runge wrote: > With that, I'm looking for co-maintainers for python-cherrypy. The > package is severely outdated and it seems there hasn't been any > significant contribution to this over the past 4 years. I may have been > too optimistic with my available time for this. The newest versions of Ceph depend on CherryPy, so I'm interested in keeping it up-to-date as long as that continues. There are several new dependencies to bring in. I've packaged them in https://copr.fedorainfracloud.org/coprs/ktdreyer/python-cherrypy/ We also need python-path to be updated, https://src.fedoraproject.org/rpms/python-path/pull-request/2 . Xavier would you please review and merge that change? - Ken ___ 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: two Ceph updates for f28, f29, stuck in pending testing for six days
On Tue, Feb 19, 2019 at 10:47 AM Kevin Fenzi wrote: > > Sadly, not that I can find. ;( Thanks for looking into it. ___ 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: two Ceph updates for f28, f29, stuck in pending testing for six days
On Mon, Feb 18, 2019 at 2:48 PM Kevin Fenzi wrote: > > On 2/18/19 12:56 PM, Kaleb Keithley wrote: > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-1c53f1a6c8 > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-6a2e72916a > > > > Would someone please give them a kick? > > For some reason autosign likes to not process these correctly. Is there any error message from Sigul or somewhere else? - Ken ___ 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: python-cherrypy vs python3-cherrypy - can we keep just one?
On Tue, Feb 12, 2019 at 1:57 PM Felix Schwarz wrote: > "Upstream are releasing separate tarballs for Python 2 and Python 3 (from > separate SVN branches), so this is a separate specfile for the Python 3 > branch." > > https://bugzilla.redhat.com/show_bug.cgi?id=579593 Thanks for that pointer Felix. In that case, we can retire python3-cherrypy and move all development to python-cherrypy, right? - Ken ___ 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
python-cherrypy vs python3-cherrypy - can we keep just one?
Hi python packagers, Could someone please help me understand why we have python-cherrypy and python3-cherrypy as two separate Fedora packages? https://src.fedoraproject.org/rpms/python-cherrypy https://src.fedoraproject.org/rpms/python3-cherrypy It seems to me that "python3-cherrypy" should be retired and merged into "python-cherrypy", but apparently python3-cherrypy was already orphaned once, retired, then re-reviewd and re-introduced, so I must be missing something! - Ken ___ 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: EPEL and RHEL High Availability / Resilient Storage
On Mon, Feb 11, 2019 at 11:38 AM Kevin Fenzi wrote: > > On 2/11/19 9:27 AM, Ken Dreyer wrote: > > Hi EPEL folks, > > > > There are some packages in CentOS 7 that did not ship in the main RHEL > > 7 Server product. > > > > Examples: > > > > python-jwt http://access.redhat.com/errata/RHEA-2018:1032 > > python-adal https://access.redhat.com/errata/RHEA-2018:1042 > > > > This went into the "High Availability" and "Resilient Storage" add-ons > > of RHEL, not the usual RHEL Base/Optional/Extras. > > > > This means that CentOS 7 really includes the RHEL 7 HA and RS products. > > > > This also means that some EPEL 7 packages cannot install without these > > repos enabled on RHEL, see eg. > > https://bugzilla.redhat.com/show_bug.cgi?id=1674764 > > > > Should EPEL's documentation include these two repos? > > https://fedoraproject.org/wiki/EPEL > > Well, we have: > > https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F > > I am not sure this belongs on the front page... but it might be nice to > be more visible yeah. Cool, thanks for the confirmation! My teammates and I have hit this a couple times unfortunately. I've edited the front EPEL wiki page to instruct RHEL users to enable the HA repo in addition to Optional and Extras. - Ken ___ 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] EPEL and RHEL High Availability / Resilient Storage
Hi EPEL folks, There are some packages in CentOS 7 that did not ship in the main RHEL 7 Server product. Examples: python-jwt http://access.redhat.com/errata/RHEA-2018:1032 python-adal https://access.redhat.com/errata/RHEA-2018:1042 This went into the "High Availability" and "Resilient Storage" add-ons of RHEL, not the usual RHEL Base/Optional/Extras. This means that CentOS 7 really includes the RHEL 7 HA and RS products. This also means that some EPEL 7 packages cannot install without these repos enabled on RHEL, see eg. https://bugzilla.redhat.com/show_bug.cgi?id=1674764 Should EPEL's documentation include these two repos? https://fedoraproject.org/wiki/EPEL ___ 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: How to avoid re-generating Pagure API keys all the time?
On Thu, Dec 13, 2018 at 4:14 AM Nicolas Mailhot wrote: > Not treating it as a community objective is how we got in a situation, > where upstreams (including @rh upstreams) want nothing to do with rpms > and Fedora, and invent their own packaging tech to bypass Linux > distributions completely. They're not doing it for lofty theoretical > reasons. Those are added later as PC justifications. The root cause of > why they behave like this, is that they feel, the packager experience > Fedora (or Debian, or Ubuntu) sucks loads. It used not to suck, when it > matched perfectly c/c++ autotools needs, and then it slowly degraded as > things were not updated to match new needs and packagers were asked to > fill in the gaps. The dynamic that you've described about upstreams matches my experience. If we do have some kind of "packager experience" SIG, I would like to be a part of it. I would love to help bring back the birds-eye view dashboard that pkgdb provided for things like "how many packages does X person maintain", or "who is on the watch list for X component in Bugzilla". Maybe we could build that into the fedora-packages application ? I know the Infra team doesn't need more new apps to run :) - Ken ___ 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: Fedora Lifecycles: imagine longer-term possibilities
On Thu, Dec 6, 2018 at 6:12 AM Florian Weimer wrote: > I'm worried that this kind of pointless work makes it hard to attract > talent. Florian, you might want to check out rdopkg. https://github.com/softwarefactory-project/rdopkg . It's a bit like fedpkg, in that it's a CLI with sub-commands. The idea is that you have three Git remotes: originssh://ktdre...@pkgs.fedoraproject.org/rpms/remctl patchesg...@example.com:ktdreyer/remctl upstreamhttps://git.eyrie.org/git/kerberos/remctl.git The "origin" is dist-git, the "upstream" is obviously the upstream project, and the "patches" remote is a fork of upstream. You can maintain all your backports and cherry-picks in the "patches" remote, in "-patches" branches. So for rawhide, the dist-git branch is "master", so the patches branch would be "master-patches". This branch is the upstream point release tag, plus any downstream cherry-picks. The "rdopkg patch" command will automatically run git-format-patch with the proper commit range and inject the patch series into the .spec file. It will update the %changelog and dist-git commit message as well. We use that to maintain several hundred cherry-picks across many different releases of Ceph. The RDO teams use it to help maintain over 800 packages. (I have "rdopkg patch" running in Jenkins also, so the rest of my team can just do "git cherry-pick -x" for their backports and not have to touch packaging or dist-git.) We get the strong history preservation guarantees that dist-git always gives us, along with the flexibility to rebase or edit patch series quickly. The patches remote can live anywhere. It is similar to Debian's patch-queue concept from git-buildpackage. Even if you maintain a package in Fedora that has just one or two patches, it is really handy to use rdopkg to manage that. You can jump back and forth between the "-patches" branch and the dist-git branch. The ability to quickly rebase or amend patches makes packaging fun again (for me anyway :) - Ken ___ 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: Improving the compose: leave the current compose in place
On Tue, Nov 27, 2018 at 7:59 AM Owen Taylor wrote: > > A lot of discussion about improving the compose process seem to end up > with a "reality check" - that ideas have already been tried but don't > work because of requirements a) b) c) d). You can't have the pony, but > maybe if a lot of effort is put into it, you can have a faster rocking > horse. > > If want to fundamentally improve the Fedora workflow we need compose > ponies, we can't just have rocking horses! There have several efforts to improve Pungi performance over time. Is there any email list or communication channel where this effort could be coordinated? I work on a project in Ceph that uses Pungi a lot, so I'm really interested in making composes as fast as possible. Our Jenkins system runs Pungi several times a day (every time a build completes in Koji), so that we can deliver composes to QE immediately. I'd like to run it even more frequently (like on every pull request scratch build). Maybe we could write a dedicated page in Pungi's upstream documentation, "performance tips for making Pungi as fast as possible". It could explain the dogpile.cache stuff, hardlinks vs http, etc. > I don't know what the system would look like exactly, but you could > imagine things like: > > * Composed of several micro-composes (micro-compose-services?) to > avoid blocking on everything completing successfully. > > * Able to do speculative composes for CI > > * Either x86_64-only, or with decoupled architectures so that we can > throw x86_64 hardware (or cloud resources) at it, and make it super > fast. > > * No IO /mnt/koji during the compose - having a big network share be > central to the process creates a performance bottleneck, makes it hard > to move to the cloud, and potentially adds a lot of "noise" to > figuring out what is going on where things are slow because of some > other entirely different thing is goin gon. This is a great idea, although it's a little tricky to do everything in a local tmpdir and still take advantage of the speed that NFS hardlinks provide. > Add your own bullet points :-) Another hairbrained idea: reduce or eliminate Pungi's thread model and make it asynchronous, using https://github.com/ktdreyer/txkoji :) ___ 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: Container updates available in bodhi
On Thu, Nov 15, 2018 at 6:09 AM Clement Verna wrote: > > On Thu, 15 Nov 2018 at 13:55, Petr Pisar wrote: >> And unrelated question: The koji build NVR does not contain dist-git >> name space. Does that mean there will be race conditions between rpms >> and container builds when the NVR string will conflict and preventing >> from an successfull koji build? > > OSBS grabs from koji the latest NVR available and increments the release > number, so we would not have identical NVR. But indeed that could mess up the > build of the rpm package if the release number was already used by OSBS, > that's something that needs to be improved. I think it's a good idea for Koji content generators to import builds named with a particular suffix. For OSBS, it makes sense to have all the container builds named with a "-container" suffix. This is how we do it in another Koji+OSBS instance I use. I guess there is nothing in OSBS (yet!) that enforces this convention for the "BZComponent' or "com.redhat.component" labels in the Dockerfile. When we use name suffixes with content generator builds, we won't have Release number collisions, or pollute "koji list-tagged --latest" or "koji list-builds --package", or throw off getAverageBuildDuration, etc. - Ken ___ 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: prevent accidentally creating branches in dist-git
Wow, thanks Dusty! This should definitely be the default for Pagure dist-git. On Tue, Nov 20, 2018 at 7:25 AM Dusty Mabe wrote: > > > I've certainly made the mistake of accidentally creating branches > in dist-git and now being stuck with them because we can't delete > them. Now that src.fedoraproject.org (dist-git) is backed by a newer > version of pagure you can prevent creating new branches by `git push`. > > For your project in the web UI: > > - Go to the `Settings` menu > - Select `Hooks` from the left hand side > - Expand `Prevent creating new branches by git push` > - Click the checkbox > - Click `Update` > > I personally think this should be the default for all projects but > I don't know if there is a way to easily make that happen when a project > gets created. > > Hope this helps someone! > Dusty > ___ > 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 ___ 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: Fedora Lifecycles: imagine longer-term possibilities
On Thu, Nov 15, 2018 at 12:30 PM Colin Walters wrote: > > The doc does assume that the reader has some familiarity with > the rpmdistro-gitoverlay project, yes. I'll look at tweaking that > doc to mention looking at the toplevel README. I looked at the top-level README but I gotta admit I was equally lost. And it says it "is no longer under active development", so I'm not sure what the status is. > rpmdistro-gitoverlay *replaces* koji, it isn't something you can use > on a "traditional package". Thanks, this was one of the missing pieces for me :) It would help to expand this out in that document. > Anyways, it's pretty simple, rpmdistro-gitoverlay does a recursive > git mirror in to src/ - and recursive here includes submodules, for > exactly the reason you raised. A number of important real-world > modules use them (including ostree/rpm-ostree). I see, so it's dynamically re-writing the .gitmodules file(s) on each build? We had something like this in Ceph, https://github.com/ceph/autobuild-ceph/blob/master/use-mirror.sh ___ 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: Fedora Lifecycles: imagine longer-term possibilities
On Thu, Nov 15, 2018 at 9:40 AM Colin Walters wrote: > On Thu, Nov 15, 2018, at 10:57 AM, Matthew Miller wrote: > > I think to do this we would need to have our own, controlled local git > > mirror. > > This is step 2 in > https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md I am sorry to be such a noob, but I read the words on that page, they sound exciting, but I am lost. What does "mirror git repositories like rpmdistro-gitoverlay does" mean? I could use a really clear step-by-step walkthrough of how I might do this for a traditional package. - Ken ___ 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: Fedora Lifecycles: imagine longer-term possibilities
On Thu, Nov 15, 2018 at 5:02 AM Florian Weimer wrote: > Make it cheap to maintain branches. I expect that one what to achieve > this would be to build directly out of Git, with synthesized release > numbers and changelogs. This way, you can apply a lot of fixes to > multiple branches without encountering mandatory conflicts. > > There is no technical reason why the payload in an SRPMs cannot contain > the full exploded upstream source tree, with an RPM spec file in the > root. One of the problems I've encountered with this approach is that the upstream Git repo links to (a lot of) submodules. If you're lucky those submodules point at Git repos and sha1s that don't disappear over time. It doesn't really capture the entire "source" like I get with an upstream release tarball. - Ken ___ 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: Fedora Lifecycles: imagine longer-term possibilities
On Tue, Nov 13, 2018 at 4:37 PM Matthew Miller wrote: > But there are some good cases for a longer lifecycle. For one thing, > this has been a really big blocker for getting Fedora shipped on > hardware. This is an interesting topic to me because I recently toured the System76 factory here in Denver. They are engineering their own operating system (Pop!_OS) on top of Ubuntu, and I would love to see Fedora become more viable as a base in these types of situations. We have a lot of data stored in Bodhi. I've wondered about mining the security update data in particular to discover: A) How many security updates that we push that would have affected older versions of Fedora, over time? In other words, based on the Fedora 28 data, how many security updates does Fedora 27 lack 3 months past its EOL? 6 months? 12 months? That would give a rough scope of the security situation and level of effort. B) Is it possible to "mock rebuild" those security updates' SRPMs for the EOL Fedora releases? How much harder does it get over time? This could be a semi-automated way to experiment with extending the lifecycle of older Fedoras. Obviously this is not perfect, but I imagine that solely focusing on security updates could help extend the lifecycle from 13 months to maybe 25 months. - Ken ___ 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: Consistent CI Messages
On Tue, Aug 21, 2018 at 4:50 AM, Petr Šplíchal wrote: > Hi, > > as part of bringing upstream and downstream workflows related to > testing one more step closer together and allow easier automation > tools development and sharing between Fedora, Red Hat Enterprise > Linux and other products, the CI team is proposing to use a > consistent format for the CI related messages: > > https://pagure.io/fedora-ci/messages > > The specification (currently describing koji-build and brew-build > messages) is written in self-documented YAML files defining a > JSON SCHEMA which can be used to validate the message format. > Included is also a set of example messages to get a quick start. > > Please, review the proposed format and share your feedback. > Thanks! Are these completely separate from what Koji generates with https://pagure.io/koji/blob/master/f/plugins/hub/protonmsg.py ? - Ken ___ 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/message/DSTQB2LKEGKDN3AXAHWWH45HWJUZQDG2/
Re: Changes in packages workflow vs. modular Fedora
On Thu, Aug 16, 2018 at 9:28 AM, Miro Hrončok wrote: > > This has received no reply in ~2 weeks. Am I the only one who ask those > questions? I'm interested as well, I just have no idea about the answers. - Ken ___ 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/message/P57PZWCX4CECVMZXUT4PWHSWKJSGMVFM/
Re: Linking commits to builds on dist-git
On Fri, Aug 10, 2018 at 3:16 AM, Daniel P. Berrangé wrote: > ie, I'd love to be able todo "git show libvirt-4.5.0-1.fc28" from the cli > to view a tag / commit from which the NEVR was made. It would be cool to have Git tags in dist-git. There is something very close that I use in the meantime, "fedpkg gitbuildhash". It queries Koji and prints the dist-git commit sha1 of a build NVR. For example: $ fedpkg gitbuildhash remctl-3.14-2.fc29 6c633d840e4221831f5502c36822a73b0860e5fc - Ken ___ 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/message/SN2Y5DKGCSEM3CFZEM7ATCQOUFRQVDDU/
[EPEL-devel] Re: python2-jenkins-job-builder package version
On Wed, Jul 18, 2018 at 2:29 PM, Jason L Tibbitts III wrote: >>>>>> "KD" == Ken Dreyer writes: > > KD> I've always thought it's the other way around, that EPEL moves > KD> faster than RHEL, > > Well, what I said didn't contradict that, so... I guess I don't > understand what you're trying to say. > > I said that EPEL maintainers aren't generally as reluctant as Red Hat > would be to update something. So they are more likely to update than > Red Hat would. Which implies that EPEL moves faster than RHEL. My bad Jason, I got mixed up when I read your earlier comment there. I see now we're in agreement. - Ken ___ 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/message/WCA2VFSFA3OFBET5Y7STG6PH3QEPCXW6/
[EPEL-devel] Re: python2-jenkins-job-builder package version
On Wed, Jul 18, 2018 at 9:36 AM, Jason L Tibbitts III wrote: >> "RI" == Roman Iuvshyn writes: > > Maintainers are generally going to be very reluctant to update a package > in EPEL without some pressing need. Not generally as reluctant as Red Hat > would > be for a package in RHEL7 proper but you would still need to ask. I've always thought it's the other way around, that EPEL moves faster than RHEL, but you're making me think there's gotta be a story behind this comment! :D - Ken ___ 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/message/VDGTCBYPUTV6NII4Z4SZCKCEL4U4LUOQ/
Re: Packages which use the BuildRoot: directive
On Wed, Jul 11, 2018 at 11:39 AM, Ben Rosser wrote: > We have been telling people for a while now that they don't "own" > their packages. Making it easier for people to maintain their packages > outside of dist-git and (effectively) ignore changes from > proven-packagers seems to take us in the opposite direction. I don't think I agree with the messaging that people don't "own" their packages. I get the point that people should be open to other contributors changing things, like the original context of this thread. On the other hand, people don't take pride in work if they don't "own" it :) We want to bring more contributors into Fedora, and there's an element of pride in becoming a package maintainer that's a good community incentive. - Ken ___ 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/message/K27PQCIBIKRIIAZDUD6CTH4X6HVDKL3B/
Re: Packages which use banned tags
On Tue, Jul 10, 2018 at 2:43 PM, Jason L Tibbitts III wrote: > I guess that has to be another of those "nobody > can touch this" packages. Hey, c'mon, Ceph doesn't bite (that badly...) Seriously though, we do maintain ceph.spec upstream in http://github.com/ceph/ceph, in coordination with SUSE developers who do a good job helping with that complicated package. If there are changes that originate in the Fedora community, branto or I can push those upstream. - Ken ___ 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/message/T6ML4ZH5BO5C56QMCL5EFSL33R7PCRG3/
Re: F29 Self Contained Change: Deprecate YUM 3
On Thu, Jun 28, 2018 at 7:16 AM, Daniel Mach wrote: > DNF shouldn't diverge from YUM just "because we can". > We're fixing some obvious differences that weren't introduced for any good > reason. > > There will be no special compat layer just a yum -> dnf symlink. > If the compatibility is preserved to sufficient level, we believe it's a > better > option than to have 2 executables with different behavior. I think this is a great plan. Thank you for explaining it here. I also like Matt's idea of re-titling the change "Replace Yum 3 with Yum 4, powered by DNF"? I think it would help bring publicity to what's going on with Yum in Fedora. - Ken ___ 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/message/LZ6DAL66VRHQNHLMN76OFTDJIRZSMMEX/
Re: Change in Copr retention policy?
On Fri, Jun 1, 2018 at 4:30 AM, Miroslav Suchý wrote: > Do you have a use case for using ancient fedoras repos? What is better for > you: to have ancient fedora repos or to have > more architectures in Copr? More arches for sure. Even if multi-arch was not a consideration, it seems like a lot of extra infra load to keep all those old files around for EOL distros. - Ken ___ 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/message/5OCFANPUOYVHE4MJ6E6TFC4AXZ2YSR5D/
orphaning my Ruby and Perl packages
Hi folks, I had several Ruby and Perl packages in Fedora that I no longer maintain any more. I've assigned all these to the "orphan" ID in src.fedoraproject.org . perl-Nagios-Plugin-WWW-Mechanize perl-Net-INET6Glue perl-Net-IP-Match-Regexp perl-Test-Carp rubygem-activerecord-nulldb-adapter rubygem-acts-as-taggable-on rubygem-axiom-types rubygem-bogus rubygem-bourne rubygem-capillary rubygem-climate_control rubygem-cocaine rubygem-coercible rubygem-creole rubygem-dependor rubygem-descendants_tracker rubygem-equalizer rubygem-escape_utils rubygem-exception_notification rubygem-expression_parser rubygem-gemnasium-parser rubygem-geoip rubygem-hipchat rubygem-ice_nine rubygem-inflecto rubygem-innertube rubygem-joiner rubygem-just_paginate rubygem-liquid rubygem-literati rubygem-loofah rubygem-middleware rubygem-mono_logger rubygem-org-ruby rubygem-pkgwat rubygem-posix-spawn rubygem-rack-openid rubygem-rails_autolink rubygem-redis-namespace rubygem-resque rubygem-resque-cleaner rubygem-riddle rubygem-rots rubygem-rspec-its rubygem-ruby-openid rubygem-rubypants rubygem-thinking-sphinx rubygem-tiltout rubygem-vegas rubygem-virtus rubygem-wikicloth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
