[Bug 1970124] perl-Feed-Find-0.08 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1970124 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|jples...@redhat.com,| |mmasl...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
abseil-cpp 20210324.2 coming to rawhide
Hi all, I will be updating abseil-cpp to version 20210324.2 in rawhide. I'll handle rebuilding the following dependencies as well: bloaty fcitx5-mozc grpc Rich ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On 6/9/21 15:53, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jun 09, 2021 at 10:29:50AM -0500, Justin Forbes wrote: On Wed, Jun 9, 2021 at 10:19 AM David Duncan wrote: On Wed, Jun 9, 2021, 4:13 AM Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jun 09, 2021 at 06:52:40AM -, David Duncan wrote: Bumping this for technical discussion. We are planning to put this in action if there are no technical objections. Please wait until the FESCo has approved the Change. I made that sound like an imperative. That was a mistake. I wanted to redirect the thread to technical review instead of program concerns. Of course no actual implementation will be done without approval. So, I suppose I should mention here for discussion what I put in the FESCo ticket. My main concern with this from a cloud image standpoint, is cloud images are run on a number of hosts. Many of those hosts are RHEL or CentOS based. As RHEL does not enable the btrfs filesystem at all, and has no plans to that I am aware of, this means that users on those hosts will no longer be able to mount their images to debug issues or modify in any way. Libguestfs for RHEL is not a workaround at this point, because it doesn't support btrfs on RHEL either. It would also mean that these images could not be used as container images in that environment. Of course the images can still be booted, and will work as expected as long as they are running in a virtualized environment with their own kernel. I am not sure how important this is for people, but it needs to be considered. Yeah, I think we have to accept that there won't be any kernel support in RHEL in a timeframe that matters for Fedora, and the RHEL host will not be able to mount the images natively. So the questions for me are: 1. I this a problem in practice? I.e. how often do people need to use Fedora images for containers on RHEL hosts? 2. What workaround can we put in place? Something in EPEL or dkms module with btrfs in a copr repo? Zbyszek Container images have nothing to do with this. Container images are stored as tar balls and are constructed on the underlying OS. This is purely an issue with soemthing like libguestfs ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
dracut broken in 054 -- bz#1965585
Hello all, I wanted to raise awareness of https://bugzilla.redhat.com/show_bug.cgi?id=1965585: this has regressed in dracut 054 and the pending dracut 055 update (https://bodhi.fedoraproject.org/updates/FEDORA-2021-a3ab421a63) does not fix it. Seeing as this is a regression affecting several users (adding 90s to boot time and preventing Wayland from starting, requiring fallback to Xorg); what are the next steps? Is it possible to untag 054 from updates? Could we get 055 masked so it does not get pushed either? See also conversation on #fedora between myself and TJ- attempting to debug this. Attempting to file needinfo? assignee reports: > You can't ask dracut-maint-l...@redhat.com because that account is disabled. - Alex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[Bug 1970148] perl-IPC-Shareable-1.00 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1970148 --- Comment #1 from Upstream Release Monitoring --- An HTTP error occurred downloading the package's new Source URLs: Getting https://cpan.metacpan.org/authors/id/M/MS/MSOUTH/IPC-Shareable-1.00.tar.gz to ./IPC-Shareable-1.00.tar.gz -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1970148] New: perl-IPC-Shareable-1.00 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1970148 Bug ID: 1970148 Summary: perl-IPC-Shareable-1.00 is available Product: Fedora Version: rawhide Status: NEW Component: perl-IPC-Shareable Keywords: FutureFeature, Triaged Assignee: spo...@gmail.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, perl-devel@lists.fedoraproject.org, spo...@gmail.com Target Milestone: --- Classification: Fedora Latest upstream release: 1.00 Current version/release in rawhide: 0.61-21.fc35 URL: http://search.cpan.org/dist/IPC-Shareable Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/7130/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Wed, 2021-06-09 at 19:53 +, Zbigniew Jędrzejewski-Szmek wrote: > Yeah, I think we have to accept that there won't be any kernel support > in RHEL in a timeframe that matters for Fedora, and the RHEL host will > not be > able to mount the images natively. So the questions for me are: > 1. I this a problem in practice? I.e. how often do people need to use > Fedora > images for containers on RHEL hosts? > 2. What workaround can we put in place? Something in EPEL or dkms > module with > btrfs in a copr repo? I've put together a Fedora-based libguestfs container that should address some of these issues and allow accessing and manipulating btrfs filesystems even on RHEL hosts that do not support it. It's currently in review at https://bugzilla.redhat.com/show_bug.cgi?id=1970071 and I'd appreciate any feedback you might have there. In addition to this, we're exploring the possiblity of developing a userspace btrfs-fuse implementation by leveraging the existing logic in brtfsprogs, which could also provide an alternative access option. On the CentOS side, the Hyperscale SIG is working on a btrfs-enabled kernel for CentOS Stream: https://pagure.io/centos-sig-hyperscale/sig/issue/7 . There's also a kmods SIG currently being proposed (https://wiki.centos.org/SpecialInterestGroup/Kmods) that could be a place for distributing a btrfs module for RHEL / CentOS stock kernels for the time being. Cheers Davide ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[Bug 1970124] New: perl-Feed-Find-0.08 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1970124 Bug ID: 1970124 Summary: perl-Feed-Find-0.08 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Feed-Find Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.08 Current version/release in rawhide: 0.07-31.fc35 URL: http://search.cpan.org/dist/Feed-Find/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2875/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Wed, Jun 09, 2021 at 10:29:50AM -0500, Justin Forbes wrote: > On Wed, Jun 9, 2021 at 10:19 AM David Duncan wrote: > > On Wed, Jun 9, 2021, 4:13 AM Zbigniew Jędrzejewski-Szmek > > wrote: > >> > >> On Wed, Jun 09, 2021 at 06:52:40AM -, David Duncan wrote: > >> > Bumping this for technical discussion. We are planning to put this in > >> > action if there are no technical objections. > >> > >> Please wait until the FESCo has approved the Change. > > > > > > I made that sound like an imperative. That was a mistake. I wanted to > > redirect the thread to technical review instead of program concerns. Of > > course no actual implementation will be done without approval. > > > > So, I suppose I should mention here for discussion what I put in the > FESCo ticket. My main concern with this from a cloud image > standpoint, is cloud images are run on a number of hosts. Many of > those hosts are RHEL or CentOS based. As RHEL does not enable the > btrfs filesystem at all, and has no plans to that I am aware of, this > means that users on those hosts will no longer be able to mount their > images to debug issues or modify in any way. Libguestfs for RHEL is > not a workaround at this point, because it doesn't support btrfs on > RHEL either. It would also mean that these images could not be used > as container images in that environment. Of course the images can > still be booted, and will work as expected as long as they are running > in a virtualized environment with their own kernel. I am not sure how > important this is for people, but it needs to be considered. Yeah, I think we have to accept that there won't be any kernel support in RHEL in a timeframe that matters for Fedora, and the RHEL host will not be able to mount the images natively. So the questions for me are: 1. I this a problem in practice? I.e. how often do people need to use Fedora images for containers on RHEL hosts? 2. What workaround can we put in place? Something in EPEL or dkms module with btrfs in a copr repo? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Use of Epoch/improper ordering
> On Tue, Jun 08, 2021 at 03:31:07PM -0500, Greg Hellings wrote:
>
> While you might have no choice, I'd caution that there a few traps
> with using Epoch, not just with Koji. One particular trap is that
> subpackage dependencies like:
>
> %package devel
> ...
> Requires: %{name}%{?_isa} = %{version}-%{release}
>
> will break because the dependency should be:
>
> Requires: %{name}%{?_isa} = %{epoch}:%{version}-%{release}
>
> More insidious is that things like:
>
> Obsoletes: oldpackage < %{version}-%{release}
>
> will silently do the wrong thing.
Oops, good catch! I've updated that and rebuilt again.
>
> If you had the choice of moving to upstream 1.9.1, I'd do that instead.
Unfortunately, upstream only releases on their own timetable and this can
sometimes be years between versions. I was hoping to use that, as well, but
with 1.9.0 out just in Autumn of last year it's unlikely we'll see a 1.9.1
before the Fedora 36 release going by past releases. Upstream mostly just
builds off of SVN HEAD for their own purposes and development moves very slowly.
--Greg
>
> Rich.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Use of Epoch/improper ordering
> On Tue, Jun 08, 2021 at 03:31:07PM -0500, Greg Hellings wrote: > > This problem is because koji ignores the epoch when checking if a build > version already exists and stores output in directories whose name does > not contain the epoch. The solution is simply to *also* bump the release > tag to '6'. This makes koji see it is as a new build and the epoch change > makes the RPM upgrade path happy. > > Regards, > Daniel Ah, you are a gentleperson and a scholar. Thank you! --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora for WSL
Susi, I've updated the repository in GitHub to allow issues to be followed. How did you install the certificate? I had to go through some of the deep Windows internals. Clicking the file and adding it directly wasn't enough, but my machine was also the dev machine so there's lots of things that would be different. If you either reply here or file an issue on the tracker, I can try to replicate what you've done in a clean Windows VM. --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
intent to orphan notice: python-nss
Seeing as I've moved on from Fedora packaging... :-) And dogtag-pki no longer depends on python-nss... :-) I'd like to orphan python-nss. But in case anyone wants it, I'm making this offer before I officially orphan the package. There's some context here that Red Hat formerly was the sponsor (and main developer) upstream in Mozilla; the official project page links back to Fedora's bugzilla to report issues. However, the former developer has moved on and so have I. So keep in mind, if you accept this package in Fedora, you might be considered the official upstream maintainer as well. :D If I don't get a response in a couple of days, I'll click the orphan button in Pagure. Happy hackin', - A ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Self Introduction: Sam Clements
Hi Sam, Le 6/9/21 à 5:37 PM, Sam Clements a écrit : Hi! My name is Sam, a DevOps engineer maintaining build and release pipelines. I've previously published my own open-source projects (including python-colorlog which is already distributed in Fedora). I'll be working with Neal Gompa and Dalton Miner, and learning about packaging from them. Cheers, Sam Clements Welcome and enjoy being around here! Best, Frédéric OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Self Introduction: Sam Clements
Welcome aboard Sam. Envoyé depuis ProtonMail mobile \ Message d'origine Le 9 juin 2021 11 h 37, Sam Clements < s...@borntyping.co.uk > a écrit : > > > > Hi! > > > > My name is Sam, a DevOps engineer maintaining build and release pipelines. > I've previously published my own open-source projects (including > python-colorlog which is already distributed in Fedora). I'll be working with > Neal Gompa and Dalton Miner, and learning about packaging from them. > > > > > Cheers, > > Sam Clements publickey - EmailAddress(s=remilauzier@protonmail.com) - 0xC69091A8.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Self Introduction: Sam Clements
Hi! My name is Sam, a DevOps engineer maintaining build and release pipelines. I've previously published my own open-source projects (including python-colorlog which is already distributed in Fedora). I'll be working with Neal Gompa and Dalton Miner, and learning about packaging from them. Cheers, Sam Clements ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Wed, Jun 9, 2021 at 10:19 AM David Duncan wrote: > > > > > > On Wed, Jun 9, 2021, 4:13 AM Zbigniew Jędrzejewski-Szmek > wrote: >> >> On Wed, Jun 09, 2021 at 06:52:40AM -, David Duncan wrote: >> > Bumping this for technical discussion. We are planning to put this in >> > action if there are no technical objections. >> >> Please wait until the FESCo has approved the Change. > > > I made that sound like an imperative. That was a mistake. I wanted to > redirect the thread to technical review instead of program concerns. Of > course no actual implementation will be done without approval. > So, I suppose I should mention here for discussion what I put in the FESCo ticket. My main concern with this from a cloud image standpoint, is cloud images are run on a number of hosts. Many of those hosts are RHEL or CentOS based. As RHEL does not enable the btrfs filesystem at all, and has no plans to that I am aware of, this means that users on those hosts will no longer be able to mount their images to debug issues or modify in any way. Libguestfs for RHEL is not a workaround at this point, because it doesn't support btrfs on RHEL either. It would also mean that these images could not be used as container images in that environment. Of course the images can still be booted, and will work as expected as long as they are running in a virtualized environment with their own kernel. I am not sure how important this is for people, but it needs to be considered. Justin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: rpmautospec: Invitiation to Test
On Tue, Jun 08, 2021 at 02:00:00PM +0200, Nils Philippsen wrote: > Hey everybody, > > we've recently deployed the changes needed to enable automatic RPM > release numbers and changelogs to Koji in staging, and now we want you > to throw things at it! > > Detailed information is below, but the gist is: it looks like this will > be real sometime soon. This is the time to ensure we folks working on > it over the past weeks haven't left in any glaring errors. > > We look forward to hearing from you! I haven't taken the time to test this yet, but I just wanted to send a: thank you for working on this. I very much look forward seeing it :) Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Wed, Jun 9, 2021, 4:13 AM Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jun 09, 2021 at 06:52:40AM -, David Duncan wrote: > > Bumping this for technical discussion. We are planning to put this in > action if there are no technical objections. > > Please wait until the FESCo has approved the Change. > I made that sound like an imperative. That was a mistake. I wanted to redirect the thread to technical review instead of program concerns. Of course no actual implementation will be done without approval. ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: Packages that failed to build with Python 3.10 (and what to do)
On 09. 06. 21 2:44, Michel Alexandre Salim via devel wrote: On Tue, Jun 08, 2021 at 05:38:27PM -0700, Michel Alexandre Salim via devel wrote: Hi, On Tue, Jun 08, 2021 at 03:58:04PM +0200, Tomas Hrnciar wrote: Hello. As you might already know, we have recently merged in the Python 3.10 side tag to Rawhide, despite several builds not succeeding. We always aim for some compromise between having the side tag open for too long and having too many failures. https://fedoraproject.org/wiki/Changes/Python3.10 For some reason, `mock -r fedora-rawhide-x86_64 install python3` is still pulling in python3-3.9.5-2.fc35.x86_64 This makes testing any fix rather difficult, as it will pass locally and then fail when doing a Koji (scratch) build. e.g. https://src.fedoraproject.org/rpms/python-typeguard/pull-request/2 For future reference, `mock --enablerepo=local` does the trick. Yes, as written in the original email: ## How to run things locally? You can use mock. Make sure to: 1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all 2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 --enablerepo=local ... -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Use of Epoch/improper ordering
On Tue, Jun 08, 2021 at 03:31:07PM -0500, Greg Hellings wrote:
> Quick question about the Epoch tag in a spec file: I goofed during
> F34's rawhide series and packaged an RC of my package with the wrong
> version name (1.9.0RC3-1 instead of 1.9.0-0.1) which causes it to
> sort higher in ordering than the final 1.9.0-5. From what I can
> gather, the proper resolution for this is to add an Epoch tag to the
> SRPM file and build 1:1.9.0-5. However, adding the epoch tag seems
> to have no effect. When I try to build, I'm told version 1.9.0-5 is
> already built for Rawhide/Fedora 34.
>
> Is there a way to claw back the improperly versioned 1.9.0RC3
> package from ages ago? Is there some magic to enable the Epoch tag
> that I'm missing? How do I get 1.9.0 final package out into Fedora?
While you might have no choice, I'd caution that there a few traps
with using Epoch, not just with Koji. One particular trap is that
subpackage dependencies like:
%package devel
...
Requires: %{name}%{?_isa} = %{version}-%{release}
will break because the dependency should be:
Requires: %{name}%{?_isa} = %{epoch}:%{version}-%{release}
More insidious is that things like:
Obsoletes: oldpackage < %{version}-%{release}
will silently do the wrong thing.
If you had the choice of moving to upstream 1.9.1, I'd do that instead.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: valgrinded executable seem to run far more slowly in Rawhide
On Wed, Jun 09, 2021 at 10:20:28AM +0200, Mark Wielaard wrote: > Hi Rich, > > On Tue, Jun 08, 2021 at 04:09:33PM +0100, Richard W.M. Jones wrote: > > I haven't filed a bug yet because I'm not sure what component to > > assign this too. I upgraded to Rawhide this morning and noticed that > > some tests that previously ran OK are now timing out. It turned out > > that the tests were failing because a valgrinded executable runs much > > more slowly in Rawhide today. > > > > Here's my test: > > > > Upgrade to Rawhide and install these additional packages: > > > > # dnf install libnbd nbdkit valgrind > > > > Unpack the certificates from > > http://oirase.annexia.org/tmp/rawhide-valgrind-bug/pki.tar.gz into /tmp > > > > Run this command as NON-root (it's self-contained and just connects > > the two commands together over localhost port 10809): > > > > $ time nbdkit --tls=require --tls-certificates=/tmp/pki null --run > > 'valgrind nbdinfo nbds://localhost' > > > > For me this takes over 40 seconds in Rawhide, versus a couple of > > seconds in Fedora 33/34. Also if you remove "valgrind" it runs > > instantaneously even in Rawhide. If you run it as root, it runs > > quickly again (WTF!) > > > > The perf flamegraph seems to indicate it's doing a lot of stuff with > > DWARF 3 symbols. > > > > http://oirase.annexia.org/tmp/rawhide-valgrind-bug/libnbd.svg > > > > Uninstalling all relevant debuginfo packages didn't seem to help. > > Thanks for using valgrind and sorry we made it even slower. I am > working on it. As you already figured out, it has to do with > debuginfo. Basically valgrind should only really need to read the line > tables, but it does a lot more. This is the fedora bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1662656 > > This has become more urgent now that debuginfod has become the default > in rawhide (valgrind supports debuginfod since 3.17.0): > https://fedoraproject.org/wiki/Changes/DebuginfodByDefault > > That also explains your observations, it depends on whether or not > DEBUGINFOD_URLS is set in the environment (and whether > elfutils-debuginfod-client is installed). FWIW yes it is (to "https://debuginfod.fedoraproject.org/;) Unsetting the environment variable does improve the performance back to expected levels. This also explains the mystery of why "sudo" fixed the problem, since sudo won't pass this environment through to the subprocess. Rich. > I'll work on making valgrind fast again, as far as valgrind is fast to > begin with :) > > Cheers, > > Mark > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Please upgrade fortune-mod to v3.6.1
Hi, In resume you are rindolf and don't have access to fedora anymore ? and you want that someone update it for you ? I can happily do that, if you give me permissions in fortune-mod , as you know my fas name is sergiomb , can you acess to https://src.fedoraproject.org/rpms/fortune-mod via web ? Best regards, On Wed, 2021-06-09 at 09:03 +, Shlomi Fish wrote: > * finalzone (~Thunderbi@fedora/Finalzone) has joined > hi all! Can someone please update fortune-mod to 3.6.1 in > fedora? > https://github.com/shlomif/fortune-mod/releases/tag/fortune-mod-3.6.1 > anyone? > * finalzone has quit (Read error: Connection reset by peer) > rindolf: the maintainer must do it > take a look here, and see if a bug exists. If not, best to > file one so that the maintainers are notified: > https://src.fedoraproject.org/rpms/fortune-mod > * Hazelesque18 (~Hazelesqu@194.107.231.152) has joined > * Hazelesque18 has quit (Remote host closed the connection) > FranciscoD: i am a maintainer - @shlomif > * calexil2 (~cale...@node-nr9.pool-182-53.dynamic.totinternet.net) has > joined > * calexil2 has quit (Remote host closed the connection) > rindolf: then you should be able to update it? > FranciscoD: as evidence: > https://www.shlomifish.org/me/rindolf/ > rindolf: sure, I'm not questioning that, but I don't > understand why you're asking someone else to update the package if you > are the maintainer? > :D > rindolf: also, if you weren't aware, we've moved to a > different network now (see /topic) > FranciscoD: i no longer have access to a fast enuf fedora sys > rindolf: ah, in that case, it'll be best to e-mail the > devel list and ask for co-maintainers who can help? > FranciscoD: ah > FranciscoD: can you do it please? i'm not subscribed and > there are anti-spam traps and stuffs. feel free to quote this irc convo > rindolf: I could but it's really best coming from a > maintainer. I see `sheltren` is the main admin for the package too--- > can they not help? > * rindolf remembers being subscribed to lkml - gmai > FranciscoD: "perfect is the enemy of good" > rindolf: no, it's more that if some else posts they end up > playing middle man between you and the list---which is not efficient > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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 -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Fedora-Cloud-34-20210609.0 compose check report
No missing expected images. Failed openQA tests: 8/8 (x86_64) Old failures (same test failed in Fedora-Cloud-34-20210604.0): ID: 904379 Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove URL: https://openqa.fedoraproject.org/tests/904379 ID: 904380 Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation URL: https://openqa.fedoraproject.org/tests/904380 ID: 904381 Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount URL: https://openqa.fedoraproject.org/tests/904381 ID: 904382 Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start URL: https://openqa.fedoraproject.org/tests/904382 ID: 904383 Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux URL: https://openqa.fedoraproject.org/tests/904383 ID: 904384 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/904384 ID: 904385 Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging URL: https://openqa.fedoraproject.org/tests/904385 ID: 904386 Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli URL: https://openqa.fedoraproject.org/tests/904386 Soft failed openQA tests: 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20210604.0): ID: 904391 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/904391 Passed openQA tests: 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Wed, Jun 09, 2021 at 06:52:40AM -, David Duncan wrote: > Bumping this for technical discussion. We are planning to put this in action > if there are no technical objections. Please wait until the FESCo has approved the Change. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Please upgrade fortune-mod to v3.6.1
* finalzone (~Thunderbi@fedora/Finalzone) has joined hi all! Can someone please update fortune-mod to 3.6.1 in fedora? https://github.com/shlomif/fortune-mod/releases/tag/fortune-mod-3.6.1 anyone? * finalzone has quit (Read error: Connection reset by peer) rindolf: the maintainer must do it take a look here, and see if a bug exists. If not, best to file one so that the maintainers are notified: https://src.fedoraproject.org/rpms/fortune-mod * Hazelesque18 (~Hazelesqu@194.107.231.152) has joined * Hazelesque18 has quit (Remote host closed the connection) FranciscoD: i am a maintainer - @shlomif * calexil2 (~cale...@node-nr9.pool-182-53.dynamic.totinternet.net) has joined * calexil2 has quit (Remote host closed the connection) rindolf: then you should be able to update it? FranciscoD: as evidence: https://www.shlomifish.org/me/rindolf/ rindolf: sure, I'm not questioning that, but I don't understand why you're asking someone else to update the package if you are the maintainer? :D rindolf: also, if you weren't aware, we've moved to a different network now (see /topic) FranciscoD: i no longer have access to a fast enuf fedora sys rindolf: ah, in that case, it'll be best to e-mail the devel list and ask for co-maintainers who can help? FranciscoD: ah FranciscoD: can you do it please? i'm not subscribed and there are anti-spam traps and stuffs. feel free to quote this irc convo rindolf: I could but it's really best coming from a maintainer. I see `sheltren` is the main admin for the package too---can they not help? * rindolf remembers being subscribed to lkml - gmai FranciscoD: "perfect is the enemy of good" rindolf: no, it's more that if some else posts they end up playing middle man between you and the list---which is not efficient ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
New Mock release v2.11 (mock-core-configs v34.4)
I'm pleased to announce that we have another Mock release: https://github.com/rpm-software-management/mock/wiki/Release-Notes-2.11 There are some bug-fixes, but also new features like the `%_platform_multiplier` macro and `--install` command support for "external dependencies". See the release notes above for more info. Bodhi update links: Fedora 34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-9c978fcae6 Fedora 33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8ee36d8295 EPEL 7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b5054640a9 EPEL 8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bea8f54571 Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: valgrinded executable seem to run far more slowly in Rawhide
Hi Rich, On Tue, Jun 08, 2021 at 04:09:33PM +0100, Richard W.M. Jones wrote: > I haven't filed a bug yet because I'm not sure what component to > assign this too. I upgraded to Rawhide this morning and noticed that > some tests that previously ran OK are now timing out. It turned out > that the tests were failing because a valgrinded executable runs much > more slowly in Rawhide today. > > Here's my test: > > Upgrade to Rawhide and install these additional packages: > > # dnf install libnbd nbdkit valgrind > > Unpack the certificates from > http://oirase.annexia.org/tmp/rawhide-valgrind-bug/pki.tar.gz into /tmp > > Run this command as NON-root (it's self-contained and just connects > the two commands together over localhost port 10809): > > $ time nbdkit --tls=require --tls-certificates=/tmp/pki null --run > 'valgrind nbdinfo nbds://localhost' > > For me this takes over 40 seconds in Rawhide, versus a couple of > seconds in Fedora 33/34. Also if you remove "valgrind" it runs > instantaneously even in Rawhide. If you run it as root, it runs > quickly again (WTF!) > > The perf flamegraph seems to indicate it's doing a lot of stuff with > DWARF 3 symbols. > > http://oirase.annexia.org/tmp/rawhide-valgrind-bug/libnbd.svg > > Uninstalling all relevant debuginfo packages didn't seem to help. Thanks for using valgrind and sorry we made it even slower. I am working on it. As you already figured out, it has to do with debuginfo. Basically valgrind should only really need to read the line tables, but it does a lot more. This is the fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1662656 This has become more urgent now that debuginfod has become the default in rawhide (valgrind supports debuginfod since 3.17.0): https://fedoraproject.org/wiki/Changes/DebuginfodByDefault That also explains your observations, it depends on whether or not DEBUGINFOD_URLS is set in the environment (and whether elfutils-debuginfod-client is installed). I'll work on making valgrind fast again, as far as valgrind is fast to begin with :) Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
Bumping this for technical discussion. We are planning to put this in action if there are no technical objections. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
