[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a6e2c9bc8c radare2-5.3.1-1.el8 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0209079fce aom-3.1.1-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing dmlite-1.15.0-4.el8 Details about builds: dmlite-1.15.0-4.el8 (FEDORA-EPEL-2021-351c441d6a) Lcgdm grid data management and storage framework Update Information: Synchonize version for all supported os versions Update DOME API documentation Add fix for puppet TokenId configuration * bugfixes: LCGDM-2965, LCGDM-2967, LCGDM-2971, LCGDM-2972, LCGDM-2973, LCGDM-2974, LCGDM-2975 --- * compatibility: dpm-tester.py LCGDM-2958 and reverted head to disknode token configuration LCGDM-2961 * bufix LCGDM-2967 * improvements in build dependencies * bugfixes LCGDM-2958, LCGDM-2961, LCGDM-2963, LCGDM-2964, OOB reads * improvements LCGDM-2943, LCGDM-2959, LCGDM-2962, davs speed * bugfix update for LCGDM-2953 * dropped update for IAM group normalization LCGDM-2950 * bugfixes LCGDM-2948, LCGDM-2949, LCGDM-2950, LCGDM-2954, LCGDM-2955, LCGDM-2957 * bugfixes LCGDM-2940, LCGDM-2941, LCGDM-2945, LCGDM-2946, LCGDM-2951 * xrootd plugin library versions configuration cleanup (requires xrootd config file update / puppet run) * compatibility: dpm-tester.py LCGDM-2958 and reverted head to disknode token configuration LCGDM-2961 * bufix LCGDM-2967 * improvements in build dependencies * bugfixes LCGDM-2958, LCGDM-2961, LCGDM-2963, LCGDM-2964, OOB reads * improvements LCGDM-2943, LCGDM-2959, LCGDM-2962, davs speed * bugfix update for LCGDM-2953 * dropped update for IAM group normalization LCGDM-2950 * bugfixes LCGDM-2948, LCGDM-2949, LCGDM-2950, LCGDM-2954, LCGDM-2955, LCGDM-2957 * bugfixes LCGDM-2940, LCGDM-2941, LCGDM-2945, LCGDM-2946, LCGDM-2951 * xrootd plugin library versions configuration cleanup (requires xrootd config file update / puppet run) Initial packages for CentOS8 (testing CentOS8/EPEL8 dependencies) ChangeLog: ___ 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: RFC: Banning bots from submitting automated koji builds
On Sun, Jun 20, 2021 at 7:19 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Sun, Jun 20, 2021 at 08:37:03AM -0500, Michael Catanzaro wrote: > > On Sun, Jun 20 2021 at 07:29:16 AM -0400, Neal Gompa > > wrote: > > >Most of our rules are designed to make sure there's someone ultimately > > >responsible for everything going into Fedora. Unfortunately, bots are > > >the opposite of that, because there's no one to reach to stop bad > > >behavior when it happens. > > > Hm, this seems pretty simple to solve though, right? Allow bots to > > submit updates on behalf of packagers, but not with their own bot > > FAS accounts. > > Let's not throw out the baby with the bath water. > > A human *is* responsible and known. When a bot account is given > permission, we make sure that there's a known human behind the account. > Things are no other in this particular case, see the original ticket [1]. > > Actually, if the bot were using their human's account, things would be *less* > transparent. By using a separate account, we are making it clear that > this update stream is made by this particular bot (as opposed to e.g. > some human occasionally using a script to release some updates). > > [1] https://pagure.io/fesco/issue/2228 > I wish our new FAS implementation gave us the ability to generate delegate/service accounts associated with a primary account. That way, we have a clear record of a human owning it, and when that human's account is known to no longer be active, the bot breaks with it. > > This would be like how GNOME package updates currently > > work, where a bot does the hard work but a human is ultimately > > responsible (and subscribed to each bodhi update, so feedback will > > at least not be completely missed). > > The line can be a big hazy, but I'd say that if: > - a human is just using a script or even a some program to fire off > the update — this particular person's account must be used. > - some bot prepares the update, but a human still need to make the final > step and may or may not publish the update: probably better to do it > using this person's account. > - the bot is set up once and then keeps releasing updating until stopped, > and may be managed by multiple people — a separate bot account is > preferable. > The problem is that this whole thing works off the premise that Rawhide is a dumping ground. It is not. It also works off the premise that nobody cares about the stuff being pushed into Dist-Git, Koji, and to users. And frankly, that has not been true for a *very* long time, if it ever was. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Unretiring coffee-script
On Fri, 2021-06-18 at 16:37 +0100, Sérgio Basto wrote: > On Fri, 2021-06-18 at 17:05 +0200, Vít Ondruch wrote: > > Hi, > > > > coffee-script package was recently retired due to being orphaned and > > FTBFS for some while. Since there are some other packages depending > > on > > it, I have decided to unretire it [1]. I have working package ready > > (at > > since F29): > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=70366160 > > > > Is here anybody, who would will to help with maintenance of this > > package? > > > In the last few days I tried to keep the package. > Updating from 1.10.0 to 2.5.1 build fails with "Error: Cannot find > module 'jison'" but jison is retired since 2019-05 (1) so I guest it > will be hard . > > > (1) > https://src.fedoraproject.org/rpms/nodejs-jison > > this weekend I played with nodejs-packaging-bundler and I could build nodejs-jison and coffeescript 2.5.1 on copr (2) , the specs are here (3) and (4) Best regards, (2) https://copr.fedorainfracloud.org/coprs/sergiomb/nodejs/builds/ (3) https://src.fedoraproject.org/fork/sergiomb/rpms/nodejs-jison/commits/f30 https://src.fedoraproject.org/fork/sergiomb/rpms/nodejs-jison/tree/f30 (4) https://src.fedoraproject.org/fork/sergiomb/rpms/coffee-script/commits/rawhide > > Thx > > > > > > Vít > > > > > > > > [1] https://pagure.io/releng/issue/10172 > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/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
Re: Forbidden to download EPEL packages?
On Sun, 2021-06-20 at 17:24 -0500, Ron Olson wrote:
> Hey all-
>
> I’m trying to run a mock build with EPEL-8 (epel-8-x86_64) and it fails
> with:
>
https://mirrors.fedoraproject.org/mirrorlist?repo=epel-8=x86_64
is working for me
mock -r epel-8-x86_64 --install kernel-headers also works for me
mock -r epel-8-x86_64 --debug-config
config_opts['dnf.conf'] = ('\n'
'[main]\n'
'keepcache=1\n'
'debuglevel=2\n'
'reposdir=/dev/null\n'
'logfile=/var/log/yum.log\n'
'retries=20\n'
'obsoletes=1\n'
'gpgcheck=0\n'
'assumeyes=1\n'
'syslog_ident=mock\n'
'syslog_device=\n'
'metadata_expire=0\n'
'mdpolicy=group:primary\n'
'best=1\n'
'protected_packages=\n'
'module_platform_id=platform:el8\n'
'user_agent={{ user_agent }}\n'
'\n'
'[baseos]\n'
'name=CentOS-$releasever - Base\n'
'mirrorlist=http://mirrorlist.centos.org/?release=8=$basearch=BaseOS=$infra\n'
'failovermethod=priority\n'
'gpgkey=file:///usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-
CentOS-Official\n'
'gpgcheck=1\n'
'skip_if_unavailable=False\n'
'\n'
'[appstream]\n'
'name=CentOS-$releasever - AppStream\n'
'mirrorlist=http://mirrorlist.centos.org/?release=8=$basearch=AppStream=$infra\n'
'#baseurl=http://mirror.centos.org/centos/$releasever/AppStream/$basearch/os/\n'
'gpgcheck=1\n'
'gpgkey=file:///usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-
CentOS-Official\n'
'\n'
'[powertools]\n'
'name=CentOS-$releasever - PowerTools\n'
'mirrorlist=http://mirrorlist.centos.org/?release=8=$basearch=PowerTools=$infra\n'
'#baseurl=http://mirror.centos.org/centos/$releasever/PowerTools/$basearch/os/\n'
'gpgcheck=1\n'
'gpgkey=file:///usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-
CentOS-Official\n'
'\n'
'[devel]\n'
'name=CentOS-$releasever - Devel WARNING! FOR BUILDROOT USE ONLY!\n'
'mirrorlist=http://mirrorlist.centos.org/?release=$releasever=$basearch=Devel=$infra\n'
'#baseurl=http://mirror.centos.org/$contentdir/$releasever/Devel/$basearch/os/\n'
'gpgcheck=1\n'
'enabled=0\n'
'gpgkey=file:///usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-
CentOS-Official\n'
'\n'
'[plus]\n'
'name=CentOS-$releasever - Plus\n'
'mirrorlist=http://mirrorlist.centos.org/?release=8=$basearch=centosplus=$infra\n'
'#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/os/\n'
'gpgcheck=1\n'
'enabled=0\n'
'gpgkey=file:///usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-
CentOS-Official\n'
'\n'
'[cr]\n'
'name=CentOS-$releasever - cr\n'
'baseurl=http://mirror.centos.org/centos/8/cr/$basearch/os/\n'
'gpgcheck=1\n'
'enabled=0\n'
'gpgkey=file:///usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-
CentOS-Official\n'
'\n'
'[debuginfo]\n'
'name=CentOS-$releasever - Debuginfo\n'
'baseurl=http://debuginfo.centos.org/8/$basearch/\n'
'gpgcheck=1\n'
'enabled=0\n'
'gpgkey=file:///usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-
CentOS-Official\n'
'\n'
'[extras]\n'
'name=CentOS-$releasever - Extras\n'
'mirrorlist=http://mirrorlist.centos.org/?release=8=$basearch=extras=$infra\n'
'#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/os/\n'
'gpgcheck=1\n'
'enabled=1\n'
'gpgkey=file:///usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-
CentOS-Official\n'
'\n'
'[fasttrack]\n'
'name=CentOS-$releasever - fasttrack\n'
'mirrorlist=http://mirrorlist.centos.org/?release=8=$basearch=fasttrack=$infra\n'
'#baseurl=http://mirror.centos.org/centos/$releasever/fasttrack/$basearch/os/\n'
'gpgcheck=1\n'
'enabled=0\n'
'gpgkey=file:///usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-
CentOS-Official\n'
'\n'
'[baseos-source]\n'
'name=CentOS-$releasever - BaseOS Sources\n'
'baseurl=http://vault.centos.org/centos/8/BaseOS/Source/\n'
'gpgcheck=1\n'
'enabled=0\n'
'gpgkey=file:///usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-
CentOS-Official\n'
'\n'
'[appstream-source]\n'
'name=CentOS-$releasever - AppStream Sources\n'
'baseurl=http://vault.centos.org/centos/8/AppStream/Source/\n'
'gpgcheck=1\n'
'enabled=0\n'
'gpgkey=file:///usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-
CentOS-Official\n'
'\n'
'[powertools-source]\n'
'name=CentOS-$releasever - PowerTools Sources\n'
'baseurl=http://vault.centos.org/centos/8/PowerTools/Source/\n'
'gpgcheck=1\n'
'enabled=0\n'
'gpgkey=file:///usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-
CentOS-Official\n'
'\n'
'[extras-source]\n'
'name=CentOS-$releasever - Extras Sources\n'
'baseurl=http://vault.centos.org/centos/8/extras/Source/\n'
'gpgcheck=1\n'
'enabled=0\n'
'gpgkey=file:///usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-
CentOS-Official\n'
'\n'
'[splus-source]\n'
'name=CentOS-$releasever - Plus Sources\n'
'baseurl=http://vault.centos.org/centos/8/centosplus/Source/\n'
'gpgcheck=1\n'
'enabled=0\n'
'gpgkey=file:///usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-
CentOS-Official\n'
'\n'
'\n'
'[epel]\n'
'name=Extra Packages for Enterprise Linux $releasever - $basearch\n'
'mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-8=$basearch\n'
'failovermethod=priority\n'
Forbidden to download EPEL packages?
Hey all- I’m trying to run a mock build with EPEL-8 (epel-8-x86_64) and it fails with: [MIRROR] kernel-headers-4.18.0-305.3.1.el8_4.x86_64.rpm: Status code: 403 for https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/kernel-headers-4.18.0-305.3.1.el8_4.x86_64.rpm (IP: 38.145.60.16) [MIRROR] kernel-headers-4.18.0-305.3.1.el8_4.x86_64.rpm: Status code: 403 for https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/kernel-headers-4.18.0-305.3.1.el8_4.x86_64.rpm (IP: 38.145.60.16) (230/232): gcc-c++-8.4.1-1.el8.x86_64.rpm 5.9 MB/s | 12 MB 00:02 [MIRROR] kernel-headers-4.18.0-305.3.1.el8_4.x86_64.rpm: Status code: 403 for https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/kernel-headers-4.18.0-305.3.1.el8_4.x86_64.rpm (IP: 38.145.60.16) [MIRROR] kernel-headers-4.18.0-305.3.1.el8_4.x86_64.rpm: Status code: 403 for https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/kernel-headers-4.18.0-305.3.1.el8_4.x86_64.rpm (IP: 38.145.60.16) [FAILED] kernel-headers-4.18.0-305.3.1.el8_4.x86_64.rpm: Status code: 403 for https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/kernel-headers-4.18.0-305.3.1.el8_4.x86_64.rpm (IP: 38.145.60.16) Error: Error downloading packages: Status code: 403 for https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/kernel-headers-4.18.0-305.3.1.el8_4.x86_64.rpm (IP: 38.145.60.16) I’ve given it a couple of days but this is still the case; any idea what’s going on or what I’m doing wrong? I tried epelplayground-8-x86_64 as well with the same result. Thanks, Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 1974141] New: perl-Config-INI-0.026 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1974141 Bug ID: 1974141 Summary: perl-Config-INI-0.026 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Config-INI Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.026 Current version/release in rawhide: 0.025-19.fc35 URL: http://search.cpan.org/dist/Config-INI/ 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/12545/ -- 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 1974142] New: perl-Config-INI-Reader-Ordered-0.021 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1974142 Bug ID: 1974142 Summary: perl-Config-INI-Reader-Ordered-0.021 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Config-INI-Reader-Ordered Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.021 Current version/release in rawhide: 0.020-14.fc35 URL: http://search.cpan.org/dist/Config-INI-Reader-Ordered/ 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/13760/ -- 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: systemd unit auto-enabling question
On Fri, Jun 18, 2021 at 09:02:08AM -0500, Michael Catanzaro wrote: > On Fri, Jun 18 2021 at 08:02:05 AM +1000, Peter Hutterer > wrote: > > Right now pipewire gets around this by hardcoding pipewire-media-session > > and > > starting it directly (instead of the systemd service) but that makes it > > hard > > to replace. > > > > Anyway, sounds like I'd need to get the FESCo approval for both packages > > then? > > Yes, you need FESCo approval to modify 90-default-user.preset. But also, I > see I don't have pipewire-media-session installed at all on F34, so you'll > also need Workstation WG approval to add a new package if you want one of > these to be installed by default. (I don't know what they do, or why they > were not included in the F34 change.) Right now, pipewire-media-session is part of the pipewire package itself and started by the pipewire daemon. So you do have it, just not as individual package :) Check your ps output, it's running. The goal is to make it replaceable which would require a separate package, but yes, that will also require some other hoops to jump through, the systemd part is merely the first one of those. Cheers, Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 1974137] New: F35FailsToInstall: perl-Pinto
https://bugzilla.redhat.com/show_bug.cgi?id=1974137 Bug ID: 1974137 Summary: F35FailsToInstall: perl-Pinto Product: Fedora Version: rawhide Status: NEW Component: perl-Pinto Assignee: jples...@redhat.com Reporter: mhron...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Blocks: 1927313 (F35FailsToInstall,RAWHIDEFailsToInstall) Target Milestone: --- Classification: Fedora Hello, Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (mhron...@redhat.com). Your package (perl-Pinto) Fails To Install in Fedora 35: can't install perl-Pinto: - nothing provides perl(Throwable::Error) >= 0.25 needed by perl-Pinto-1:0.14-13.fc35.noarch If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem. If you don't react accordingly to the policy for FTBFS/FTI bugs (https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/), your package may be orphaned in 8+ weeks. P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors. P.P.S. If this bug has been reported in the middle of upgrading multiple dependent packages, please consider using side tags: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages Thanks! Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1927313 [Bug 1927313] Fedora 35 Fails To install Tracker -- 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 1974136] New: F35FailsToInstall: perl-Email-Sender
https://bugzilla.redhat.com/show_bug.cgi?id=1974136 Bug ID: 1974136 Summary: F35FailsToInstall: perl-Email-Sender Product: Fedora Version: rawhide Status: NEW Component: perl-Email-Sender Assignee: emman...@seyman.fr Reporter: mhron...@redhat.com QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, perl-devel@lists.fedoraproject.org Blocks: 1927313 (F35FailsToInstall,RAWHIDEFailsToInstall) Target Milestone: --- Classification: Fedora Hello, Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (mhron...@redhat.com). Your package (perl-Email-Sender) Fails To Install in Fedora 35: can't install perl-Email-Sender: - nothing provides perl(Throwable::Error) >= 0.23 needed by perl-Email-Sender-1.300036-1.fc35.noarch If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem. If you don't react accordingly to the policy for FTBFS/FTI bugs (https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/), your package may be orphaned in 8+ weeks. P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors. P.P.S. If this bug has been reported in the middle of upgrading multiple dependent packages, please consider using side tags: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages Thanks! Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1927313 [Bug 1927313] Fedora 35 Fails To install Tracker -- 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: RFC: Banning bots from submitting automated koji builds
On Sun, Jun 20, 2021 at 8:45 PM Kevin Fenzi wrote: > > My question would be: Are these automated builds otherwise known working > and ready for integration testing with the rest of the distribution in > rawhide? > > If they are, we (just) need to fix the bot to not do the wrong thing. > > If they are not, then indeed, only those that meet that critera should > be pushed into rawhide. > > ie, it doesn't matter to me if the package version is > 0.0alpha-do-not-use if the maintainer(s) say it works and is > ready to integrate with the rest of the distribution. One projects > "0.001-danger" is another projects "10.1" stable. We should trust > maintainer(s) to know this... I wouldn't have a problem with this, but looking at those builds apparently - nobody monitors bodhi updates created for those builds, and - nobody reads emails for the rhcontainerbot account. The bodhi updates look very much like "throw this over the wall and forget it". They are never interacted with. If gating fails (which happens regularly), they're just stuck in rawhide's weird "testing" state, until the next update for that package obsoletes them. In combination with the bot pushing weird / wrong versions, this doesn't look too trustworthy to me. Who is even responsible for the rhcontainerbot account? I looked at the linked FESCo ticket (this was approved before my time), but I couldn't figure out who's actually using this bot now, or who is responsible for monitoring its actions. Because it sure seems like nobody is looking. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: RFC: Banning bots from submitting automated koji builds
On Sun, Jun 20, 2021 at 02:36:57PM +0200, Aleksandra Fedorova wrote: > Hi, > > On Sun, Jun 20, 2021 at 1:30 PM Neal Gompa wrote: ...snip... > > > > Rawhide is still not your CI environment. > > By the way I think we need to reconsider this statement. I think we should turn it around and say: Rawhide is your first stop to integrate your otherwise ready package(s) with the rest of the distribution. Meh, thats not great either... perhaps a slogan is bad. ;) kevin signature.asc Description: PGP 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
[Test-Announce] Proposal to CANCEL: 2021-06-21 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't have anything urgent on the agenda again, so let's take a break. If you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@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: RFC: Banning bots from submitting automated koji builds
On Sun, Jun 20, 2021 at 03:26:52PM +, Zbigniew Jędrzejewski-Szmek wrote: > > Yeah. I'm looking a the original ticket in > https://pagure.io/fesco/issue/2228, and I think this was a mistake. > We shouldn't have approved a bot that packages snapshot commits for > rawhide. In the discussion, we talked about load on the infra, and ability > to contact the maintainers, and even cooperation withb packit, but somehow > the question whether we want this at all didn't come up. > > I guess the effort to make rawhide palatable hadn't really sunk in > deep enough back then ;) Well, it's still not clear to me if these builds are not suitable for rawhide, or if the bot that is pushing them just has bugs. In the case that caused this thread, the bot pushed older pacakges? So, it wasn't that they were completely broken, it's that they were just _wrong_. > @lsm5, would you be willing to adjust the bot to only package actual > releases? Also, what is going on with the version jumps? My question would be: Are these automated builds otherwise known working and ready for integration testing with the rest of the distribution in rawhide? If they are, we (just) need to fix the bot to not do the wrong thing. If they are not, then indeed, only those that meet that critera should be pushed into rawhide. ie, it doesn't matter to me if the package version is 0.0alpha-do-not-use if the maintainer(s) say it works and is ready to integrate with the rest of the distribution. One projects "0.001-danger" is another projects "10.1" stable. We should trust maintainer(s) to know this... kevin signature.asc Description: PGP 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: RFC: Banning bots from submitting automated koji builds
On Sun, 2021-06-20 at 10:42 +0200, Miro Hrončok wrote: > On 20. 06. 21 9:39, Zbigniew Jędrzejewski-Szmek wrote: > > I think we should just disable this particular bot until it fixed. > > We should also clarify/update the Update Guidelines so that > > undesirable > > updates are disallowed, no matter if submitted by a bot or a human. > > I think this is a good idea. This particular bot has a history of > misbehavior > and rather than banning all the well behaving bots (that be > definition we don't > even know about, because they behave good), we should disable this > particular one. > > Rather than "no bots allowed" policy, we might need a "bots that > violate our > policies and guidelines or have a tendency to break things will be > disabled > until fixed" policy. 100% agree, the problem is the bot that is, how to say without being offensive, not very smart. > -- > 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 -- 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
Re: RFC: Banning bots from submitting automated koji builds
Miro Hrončok writes: >> - releng and SIGs submitting scripted mass rebuilds (no actual package >> changes, triggered by a person) >> - bots submitting rawhide builds for ELN (no package change, just >> built for different buildroot) > Other random ideas of what should be allowed: > - a human approves a pull request, bot merges it and builds > - a bot rebuilds packages automatically (bump-only or no changes), > when dependencies change A simpler way to phrase that would be: "No autonomous bots are to push builds into rawhide or release branches." - FChE ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: RFC: Banning bots from submitting automated koji builds
On Sun, 2021-06-20 at 12:52 +0100, Peter Robinson wrote: > > Rawhide is still not your CI environment. Years ago, we got rid of > > alphas for the express purpose to stabilize Rawhide into alpha > > quality. Stuff like this degrades the quality of Rawhide because they > > make the assumption that nobody cares about the quality of Rawhide. > > Being one of the people driving that in rel-eng at the time, the other > was dgilmore, that statement is incorrect. The dropping of Alphas was > because we improved the compose to produce all release artifacts on > the nightly composes, both rawhide and branched, instead of just the > network installer and live images. Previously to that we only produced > all artifacts with the TC/RC composes, we also got rid of the TCs as > part of that process. My recollection is that both of these things are correct. Having full nightly composes was one part of dropping Alphas, but so was the idea that Rawhide would continually maintain Alpha quality. This is why the Basic release criteria exist - they are the requirements that Rawhide is supposed to meet *all the time*. They say this right at the top: "The objectives for all Branched and Rawhide nightly composes, as well as Beta and Final releases, are to..." The whole "Rawhide gating" idea was part of this: the idea was/is that Rawhide composes should not be synced unless they meet the Basic criteria. The rawhide_compose_sync_to_mirrors greenwave policy exists to check this, but for whatever reason, the work of actually completing this effort so compose sync doesn't happen unless that policy passes was never done. We've talked about various concerns around this in the past (the technicalities of exactly how to implement it, and the concern that not enough composes actually meet the requirements so we'd wind up with few composes synced and a big disconnect between what's in the repos and what's in Koji), but the *idea* has been there all along and I agree with Neal that it was tied up with 'no more Alphas'. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: RFC: Banning bots from submitting automated koji builds
Dnia Sun, Jun 20, 2021 at 10:39:34AM +0200, Miro Hrončok napisał(a): > On 19. 06. 21 22:18, Fabio Valentini wrote: > > The following things should still be allowed: > > - releng and SIGs submitting scripted mass rebuilds (no actual package > > changes, triggered by a person) > > - bots submitting rawhide builds for ELN (no package change, just > > built for different buildroot) > > Other random ideas of what should be allowed: > > - a bot rebuilds packages automatically (bump-only or no changes), when > dependencies change We supposedly have it in Fedora already: https://fedoraproject.org/wiki/Koschei but it never worked for me. -- Tomasz Torcz “If you try to upissue this patchset I shall be seeking to...@pipebreaker.pl an IP-routable hand grenade.” — Andrew Morton (LKML) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: RFC: Banning bots from submitting automated koji builds
On Sun, 2021-06-20 at 07:29 -0400, Neal Gompa wrote: > > If you want the features of Rawhide for CI, then we should talk about > enabling this in more places. For example, there's no technical reason > we couldn't do OpenQA runs for packages in COPR. There are serious > consequences to shipping packages into Rawhide, not the least of which > is that it locks an NVR forever into Koji and ships it to people using > Rawhide as a daily driver. Also having the ability to have COPR > auto-rebuild as stuff changes in the build root makes the CI case work > better, and that's something we literally can't do in Koji (by policy > and by design). I mean, there's no need for COPR to be involved. Rawhide runs through Bodhi these days. We could configure the package(s) concerned to gate the updates on testing. One major stumbling block there is that the openQA tests Peter values only run on nightly composes, and those only pull in stable packages. But it's not like we couldn't engineer our way around that if we wanted to. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-Rawhide-20210620.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 3 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 17/134 (aarch64), 15/199 (x86_64) New failures (same test not failed in Fedora-Rawhide-20210619.n.0): ID: 912851 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/912851 ID: 912863 Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi URL: https://openqa.fedoraproject.org/tests/912863 ID: 912875 Test: x86_64 universal install_sata@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/912875 ID: 912894 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/912894 ID: 912962 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/912962 ID: 913043 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/913043 ID: 913044 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/913044 Old failures (same test failed in Fedora-Rawhide-20210619.n.0): ID: 912668 Test: x86_64 Server-dvd-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/912668 ID: 912691 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/912691 ID: 912694 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/912694 ID: 912708 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/912708 ID: 912709 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/912709 ID: 912710 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/912710 ID: 912713 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/912713 ID: 912716 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/912716 ID: 912721 Test: x86_64 Workstation-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/912721 ID: 912742 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/912742 ID: 912763 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/912763 ID: 912796 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/912796 ID: 912799 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/912799 ID: 912824 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/912824 ID: 912825 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/912825 ID: 912826 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/912826 ID: 912837 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/912837 ID: 912839 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/912839 ID: 912850 Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi URL: https://openqa.fedoraproject.org/tests/912850 ID: 912854 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/912854 ID: 912862 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/912862 ID: 912956 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/912956 ID: 912984 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/912984 ID: 913001 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/913001 ID: 913005 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/913005 Soft failed openQA tests: 7/199 (x86_64), 5/134 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20210619.n.0): ID: 912781 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/912781 ID: 912783 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/912783 ID: 912840 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/912840 ID: 912868 Test:
Re: RFC: Banning bots from submitting automated koji builds
On Sun, Jun 20, 2021 at 10:55:00AM +0200, Fabio Valentini wrote: > On Sun, Jun 20, 2021 at 10:45 AM Miro Hrončok wrote: > > > > I think this is a good idea. This particular bot has a history of > > misbehavior > > and rather than banning all the well behaving bots (that be definition we > > don't > > even know about, because they behave good), we should disable this > > particular one. > > > > Rather than "no bots allowed" policy, we might need a "bots that violate our > > policies and guidelines or have a tendency to break things will be disabled > > until fixed" policy. > > Yeah, that works for me too. Though I wouldn't want to make this a > special case and create an actual policy for this instead, that we > could point to when something like this happens. > > I also think that I probably was not clear in my original message. > > Any builds that are triggered by an actual human action, like > - scripted (mass) rebuilds with no *Version* changes, > - automatic builds after human-approved PRs, > - etc. > are of course exempt, because the action of an actual human being > triggered them. > > The only thing I *don't* want is: Bots submitting builds for new > *Versions*, without human interaction. So... what about new versions of clamav-data? I'm pretty sure that's OK to bot-ize. Then what about new minor version of thousands of rust packages? If we have %check sections and CI and gating, the act of releasing the update as a packager is not much different than a what a bot would do. Right now we mostly don't automatize this, but I think we could in the future. > Regarding Zbyszek's point: > > > Second, I think the guideline is simply wrong. As counterexamples, we > > currently have python3.10beta2 in rawhide, systemd-249-rc1, and > > kernel-5.13.0-0.rc6. Pushing pre-release vesions of low-level packages > > is a crucial part of development of the distro and collaboration with > > upstream projects and language ecosystems. > > There's actually already an exemption in the Updates Policy for those cases. > And I don't have any problem with those, because those builds are > prepared, built, tested, and shepherded by actual humans, instead of > created by a bot that just throws them at the wall to see what sticks > and what doesn't. Oh, OK. I didn't look at the policy page, just went by the quote provided. > If you look at bodhi updates for rhcontainerbot it's pretty obvious > that nobody even looks at the updates that are created for those > builds: > https://bodhi.fedoraproject.org/updates/?search==testing=rhcontainerbot > It looks like any build that receives -1 karma or fails gating tests > will just be stuck in "testing" until obsoleted by the next automated > build for that package. Yeah. I'm looking a the original ticket in https://pagure.io/fesco/issue/2228, and I think this was a mistake. We shouldn't have approved a bot that packages snapshot commits for rawhide. In the discussion, we talked about load on the infra, and ability to contact the maintainers, and even cooperation withb packit, but somehow the question whether we want this at all didn't come up. I guess the effort to make rawhide palatable hadn't really sunk in deep enough back then ;) @lsm5, would you be willing to adjust the bot to only package actual releases? Also, what is going on with the version jumps? 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: RFC: Banning bots from submitting automated koji builds
On Sun, Jun 20, 2021 at 08:37:03AM -0500, Michael Catanzaro wrote: > On Sun, Jun 20 2021 at 07:29:16 AM -0400, Neal Gompa > wrote: > >Most of our rules are designed to make sure there's someone ultimately > >responsible for everything going into Fedora. Unfortunately, bots are > >the opposite of that, because there's no one to reach to stop bad > >behavior when it happens. > Hm, this seems pretty simple to solve though, right? Allow bots to > submit updates on behalf of packagers, but not with their own bot > FAS accounts. Let's not throw out the baby with the bath water. A human *is* responsible and known. When a bot account is given permission, we make sure that there's a known human behind the account. Things are no other in this particular case, see the original ticket [1]. Actually, if the bot were using their human's account, things would be *less* transparent. By using a separate account, we are making it clear that this update stream is made by this particular bot (as opposed to e.g. some human occasionally using a script to release some updates). [1] https://pagure.io/fesco/issue/2228 > This would be like how GNOME package updates currently > work, where a bot does the hard work but a human is ultimately > responsible (and subscribed to each bodhi update, so feedback will > at least not be completely missed). The line can be a big hazy, but I'd say that if: - a human is just using a script or even a some program to fire off the update — this particular person's account must be used. - some bot prepares the update, but a human still need to make the final step and may or may not publish the update: probably better to do it using this person's account. - the bot is set up once and then keeps releasing updating until stopped, and may be managed by multiple people — a separate bot account is preferable. 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
Fedora-IoT-35-20210620.0 compose check report
No missing expected images. Failed openQA tests: 2/16 (x86_64), 6/15 (aarch64) Old failures (same test failed in Fedora-IoT-35-20210619.0): ID: 913018 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/913018 ID: 913027 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/913027 ID: 913028 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/913028 ID: 913030 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/913030 ID: 913034 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/913034 ID: 913036 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/913036 ID: 913041 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/913041 ID: 913042 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/913042 Soft failed openQA tests: 3/16 (x86_64), 1/15 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-35-20210619.0): ID: 913012 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/913012 ID: 913013 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/913013 ID: 913014 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/913014 ID: 913029 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/913029 Passed openQA tests: 8/15 (aarch64), 11/16 (x86_64) New passes (same test not passed in Fedora-IoT-35-20210619.0): ID: 913035 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi URL: https://openqa.fedoraproject.org/tests/913035 Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: System load changed from 0.40 to 0.23 Previous test data: https://openqa.fedoraproject.org/tests/912598#downloads Current test data: https://openqa.fedoraproject.org/tests/913013#downloads Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 3.98 to 0.56 Average CPU usage changed from 95.23809524 to 8.27142857 Previous test data: https://openqa.fedoraproject.org/tests/912614#downloads Current test data: https://openqa.fedoraproject.org/tests/913029#downloads -- 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
[Bug 1974101] New: perl-CPAN-Perl-Releases-5.20210620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1974101 Bug ID: 1974101 Summary: perl-CPAN-Perl-Releases-5.20210620 is available Product: Fedora Version: rawhide Status: NEW Component: perl-CPAN-Perl-Releases Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 5.20210620 Current version/release in rawhide: 5.20210521-1.fc35 URL: http://search.cpan.org/dist/CPAN-Perl-Releases/ 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/5881/ -- 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: debugging pipewire & root access to systemd userspace
On Sun, Jun 20, 2021 at 03:19:27PM +0200, Alexander Ploumistos wrote:
> Hello Zbigniew,
>
> Thank you very much for your answers and sorry for the late reply, IRL
> things have been hectic. I've had the problem with pipewire once since
> I last wrote, but I can't figure out how to trigger it at will.
>
>
> On Fri, Jun 18, 2021 at 8:36 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Fri, Jun 18, 2021 at 01:38:08AM +0200, Alexander Ploumistos wrote:
> > > Should gdb be able to read from a sound device?
> >
> > It shouldn't attempt to.
>
> Should I file a bug against gdb or abrt?
You *may*, but I think it's one of those cases where you'll need to figure
it our on your own anyway. Until you have narrowed down what is going wrong,
filing a bug is likely to only cause the maintainers to ask you for
(a lot of) info.
> > > Having root logged in a terminal, I tried to check the state of
> > > pipewire.service:
> > > systemctl --machine=myuser@.host --user status pipewire.service
> > >
> > > to which I got the reply:
> > > Failed to get properties: Transport endpoint is not connected
> >
> > The way that myuser@.host is implemented is surprisingly complex. See
> > the original commit https://github.com/systemd/systemd/commit/1b630835df
> > for a description.
> >
> > Does it work for other users? If yes, then it looks like something
> > is borked for that particular user.
>
> Forgot to check, I will try to do it later today.
>
>
> > systemctl -M myuser@.host executes
> > systemd-run -p User=myuser systemd-stdio-bridge
> > -punix:path=${XDG_RUNTIME_DIR}/bus
> > The error message is most likely from systemd-stdio-bridge,
> > or from systemctl failing to connect to the bridge. Since the
> > invocation of systemd-stdio-bridge goes through the system manager,
> > you can look at the logs for that unit ('journalctl -b -u
> > run-u.service').
> > It should show some error.
>
> There is no such service. Assuming is the uid,
No, is a (pseudorandom) number assigned to the service. Every time
you execute 'systemctl -M myuser@.host', this invokes 'systemd-run', which
in turns causes 'systemd' to start a new 'run-u.service' unit.
> Looking at the logs for user@1000.service, there's nothing pertinent.
This is not part of user@1000.service.
> Actually there's nothing even in the unfiltered log when I issue the
> command and it fails.
That seems wrong. Maybe you're not seeing all logs because you don't have
enough privileges?
> > > I haven't had to bother with a userspace systemd service before, so
> > > going down that rabbit hole, at some point I started messing with
> > > machinectl, and apparently, running something seemingly innocuous such
> > > as "machinectl list-images --all" triggers a SELinux denial. But not
> > > always…
> > > The message I'm seeing is this:
> > > audit[1079]: AVC avc: denied { write } for pid=1079
> > > comm="systemd-machine" name="/" dev="dm-1" ino=2
> > > scontext=system_u:system_r:systemd_machined_t:s0
> > > tcontext=system_u:object_r:root_t:s0 tclass=dir permissive=0
> > >
> > > setroubleshoot tells me that if I want to allow daemons to dump core,
> > > then I should enable the 'daemons_dump_core' boolean. I don't know if
> > > I want to, do I need to do that in order to dive deeper into my
> > > pipewire issue? How is listing the images on a system related to
> > > allowing demons to dump core though?
> >
> > If machined crashes, there should be logs about this. Did you
> > look at the journal?
>
> Nothing in the journal about machined crashing or doing anything else
> other than getting the SELinux denial.
The usual method to debugging those is to set permissive mode and then
check if the issue still reproduces.
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: systemd unit auto-enabling question
On Sun, Jun 20, 2021 at 10:17 AM Michael Catanzaro wrote: > > On Fri, Jun 18 2021 at 08:02:05 AM +1000, Peter Hutterer > wrote: > > Right now pipewire gets around this by hardcoding > > pipewire-media-session and > > starting it directly (instead of the systemd service) but that makes > > it hard > > to replace. > > > > Anyway, sounds like I'd need to get the FESCo approval for both > > packages > > then? > > Yes, you need FESCo approval to modify 90-default-user.preset. But > also, I see I don't have pipewire-media-session installed at all on > F34, so you'll also need Workstation WG approval to add a new package > if you want one of these to be installed by default. (I don't know what > they do, or why they were not included in the F34 change.) Nobody said anything about it, which is why it didn't get enabled. And no, WG approval is not required if it's already a dependency of pipewire (which is used by all Fedora variants). That policy only applies to new extra things or GNOME things (as Workstation WG is effectively the GNOME SIG). -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 1974093] New: perl-Module-CoreList-5.20210620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1974093 Bug ID: 1974093 Summary: perl-Module-CoreList-5.20210620 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Module-CoreList Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, jples...@redhat.com, mspa...@redhat.com, perl-devel@lists.fedoraproject.org, spo...@gmail.com, st...@silug.org Target Milestone: --- Classification: Fedora Latest upstream release: 5.20210620 Current version/release in rawhide: 5.20210521-1.fc35 URL: http://search.cpan.org/dist/Module-CoreList/ 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/3080/ -- 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: RFC: Banning bots from submitting automated koji builds
On Sun, Jun 20 2021 at 07:29:16 AM -0400, Neal Gompa wrote: Most of our rules are designed to make sure there's someone ultimately responsible for everything going into Fedora. Unfortunately, bots are the opposite of that, because there's no one to reach to stop bad behavior when it happens. Hm, this seems pretty simple to solve though, right? Allow bots to submit updates on behalf of packagers, but not with their own bot FAS accounts. This would be like how GNOME package updates currently work, where a bot does the hard work but a human is ultimately responsible (and subscribed to each bodhi update, so feedback will at least not be completely missed). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: RFP: Just
Hi, I'll take care of packaging rust-target and just. Best regards, -- Olivier ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 rawhide compose report: 20210620.n.0 changes
OLD: Fedora-Rawhide-20210619.n.0 NEW: Fedora-Rawhide-20210620.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 61 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 4.60 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -46.46 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: R-bslib-0.2.4-3.fc35 Old package: R-bslib-0.2.4-2.fc35 Summary: Custom Bootstrap Sass Themes for shiny and rmarkdown RPMs: R-bslib Size: 2.96 MiB Size change: 1.79 KiB Changelog: * Sat Jun 19 2021 Elliott Sales de Andrade - 0.2.4-3 - Rebuild for R 4.1 Package: R-jquerylib-0.1.4-2.fc35 Old package: R-jquerylib-0.1.4-1.fc35 Summary: Obtain jQuery as an HTML Dependency Object RPMs: R-jquerylib Size: 300.11 KiB Size change: -1.86 KiB Changelog: * Sat Jun 19 2021 Elliott Sales de Andrade - 0.1.4-2 - Rebuild for R 4.1 Package: R-sass-0.3.1-2.fc35 Old package: R-sass-0.3.1-1.fc35 Summary: Syntactically Awesome Style Sheets (Sass) RPMs: R-sass Size: 1.54 MiB Size change: -242 B Changelog: * Sat Jun 19 2021 Elliott Sales de Andrade - 0.3.1-2 - Rebuild for R 4.1 Package: R-shiny-1.5.0-5.fc35~bootstrap Old package: R-shiny-1.5.0-4.fc35~bootstrap Summary: Web Application Framework for R RPMs: R-shiny Size: 4.22 MiB Size change: 18 B Changelog: * Sat Jun 19 2021 Elliott Sales de Andrade - 1.5.0-5 - Fix upgrade problem due to symlink->directory change (#1936222) Package: acme-tiny-4.1.0-7.fc35 Old package: acme-tiny-4.1.0-6.fc35 Summary: Tiny auditable script to issue, renew Let's Encrypt certificates RPMs: acme-tiny acme-tiny-core Size: 34.77 KiB Size change: 1.43 KiB Changelog: * Thu May 27 2021 Stuart D. Gathman 4.1.0-7 - Fix BZ#1839904 - enhance notify after cert update, incrond no longer needed Package: bind-32:9.16.18-1.fc35 Old package: bind-32:9.16.17-2.fc35 Summary: The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server RPMs: bind bind-chroot bind-devel bind-dlz-filesystem bind-dlz-ldap bind-dlz-mysql bind-dlz-sqlite3 bind-dnssec-doc bind-dnssec-utils bind-doc bind-libs bind-license bind-pkcs11 bind-pkcs11-devel bind-pkcs11-libs bind-pkcs11-utils bind-utils python3-bind Size: 23.36 MiB Size change: -391 B Changelog: * Fri Jun 18 2021 Petr Menk - 32:9.16.18-1 - Update to 9.16.18 Package: bind-dyndb-ldap-11.9-3.fc35 Old package: bind-dyndb-ldap-11.9-2.fc35 Summary: LDAP back-end plug-in for BIND RPMs: bind-dyndb-ldap Size: 529.16 KiB Size change: 753 B Changelog: * Sat Jun 19 2021 Petr Menk - 11.9-3 - Rebuilt for BIND 9.16.18 Package: bottles-3.1.15-1.fc35 Old package: bottles-3.1.14-1.fc35 Summary: Easily manage Wine prefix in a new way RPMs: bottles Size: 177.72 KiB Size change: 5.91 KiB Changelog: * Sat Jun 19 2021 Artem Polishchuk - 3.1.15-1 - build(update): 3.1.15 Package: clipman-1.6.0-1.fc35 Old package: clipman-1.5.2-1.fc35 Summary: A simple clipboard manager for Wayland RPMs: clipman golang-github-yory8-clipman-devel Size: 6.41 MiB Size change: -52.41 KiB Changelog: * Sat Jun 19 2021 Bob Hepple - 1.6.0-1 - new version Package: corsix-th-0.65-2.fc35 Old package: corsix-th-0.65-1.fc35 Summary: Open source clone of Theme Hospital RPMs: corsix-th corsix-th-data Size: 2.80 MiB Size change: 3.47 KiB Changelog: * Sat Jun 19 2021 Artem Polishchuk - 0.65-2 - build(update): 0.65 (new, re-tagged upstream version) Package: culmus-fonts-0.133-1.fc35 Old package: culmus-fonts-0.130-18.fc34 Summary: Fonts for Hebrew from Culmus project RPMs: clm-aharoni-fonts clm-caladings-fonts clm-david-fonts clm-drugulin-fonts clm-ellinia-fonts clm-frank-ruehl-fonts clm-hadasim-fonts clm-keter-yg-fonts clm-miriam-fonts clm-miriam-mono-fonts clm-nachlieli-fonts clm-shofar-fonts clm-simple-fonts clm-stam-ashkenaz-fonts clm-stam-sefarad-fonts clm-yehuda-fonts culmus-fonts-all Added RPMs: clm-aharoni-fonts clm-caladings-fonts clm-david-fonts clm-drugulin-fonts clm-ellinia-fonts clm-frank-ruehl-fonts clm-hadasim-fonts clm-keter-yg-fonts clm-miriam-fonts clm-miriam-mono-fonts clm-nachlieli-fonts clm-shofar-fonts clm-simple-fonts clm-stam-ashkenaz-fonts clm-stam-sefarad-fonts clm-yehuda-fonts culmus-fonts-all Dropped RPMs: culmus-aharoni-clm-fonts culmus-caladings-clm-fonts culmus-david-clm-fonts culmus-drugulin-clm-fonts culmus-ellinia-clm-fonts culmus-fonts-common culmus-frank-ruehl-clm-fonts culmus-hadasim-clm-fonts culmus-kete
Re: debugging pipewire & root access to systemd userspace
Hello Zbigniew,
Thank you very much for your answers and sorry for the late reply, IRL
things have been hectic. I've had the problem with pipewire once since
I last wrote, but I can't figure out how to trigger it at will.
On Fri, Jun 18, 2021 at 8:36 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Fri, Jun 18, 2021 at 01:38:08AM +0200, Alexander Ploumistos wrote:
> > Should gdb be able to read from a sound device?
>
> It shouldn't attempt to.
Should I file a bug against gdb or abrt?
> > Having root logged in a terminal, I tried to check the state of
> > pipewire.service:
> > systemctl --machine=myuser@.host --user status pipewire.service
> >
> > to which I got the reply:
> > Failed to get properties: Transport endpoint is not connected
>
> The way that myuser@.host is implemented is surprisingly complex. See
> the original commit https://github.com/systemd/systemd/commit/1b630835df
> for a description.
>
> Does it work for other users? If yes, then it looks like something
> is borked for that particular user.
Forgot to check, I will try to do it later today.
> systemctl -M myuser@.host executes
> systemd-run -p User=myuser systemd-stdio-bridge
> -punix:path=${XDG_RUNTIME_DIR}/bus
> The error message is most likely from systemd-stdio-bridge,
> or from systemctl failing to connect to the bridge. Since the
> invocation of systemd-stdio-bridge goes through the system manager,
> you can look at the logs for that unit ('journalctl -b -u run-u.service').
> It should show some error.
There is no such service. Assuming is the uid, I have these units listed:
user-runtime-dir@1000.service
user@1000.service
user-1000.slice
Looking at the logs for user@1000.service, there's nothing pertinent.
Actually there's nothing even in the unfiltered log when I issue the
command and it fails.
> > I haven't had to bother with a userspace systemd service before, so
> > going down that rabbit hole, at some point I started messing with
> > machinectl, and apparently, running something seemingly innocuous such
> > as "machinectl list-images --all" triggers a SELinux denial. But not
> > always…
> > The message I'm seeing is this:
> > audit[1079]: AVC avc: denied { write } for pid=1079
> > comm="systemd-machine" name="/" dev="dm-1" ino=2
> > scontext=system_u:system_r:systemd_machined_t:s0
> > tcontext=system_u:object_r:root_t:s0 tclass=dir permissive=0
> >
> > setroubleshoot tells me that if I want to allow daemons to dump core,
> > then I should enable the 'daemons_dump_core' boolean. I don't know if
> > I want to, do I need to do that in order to dive deeper into my
> > pipewire issue? How is listing the images on a system related to
> > allowing demons to dump core though?
>
> If machined crashes, there should be logs about this. Did you
> look at the journal?
Nothing in the journal about machined crashing or doing anything else
other than getting the SELinux denial.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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 1967544] perl-SDL-2.548-11.fc35 skips all video tests with sdl12-compat-devel-0.0.1~git.20210602.cc5826a-1.fc35: Failed to init video
https://bugzilla.redhat.com/show_bug.cgi?id=1967544 Neal Gompa changed: What|Removed |Added Status|NEW |CLOSED CC||igor.ra...@gmail.com Component|perl-SDL|sdl12-compat Fixed In Version||sdl12-compat-0.0.1~git.2021 ||0618.f44f295-1.fc35 Resolution|--- |RAWHIDE Assignee|hdego...@redhat.com |ngomp...@gmail.com QA Contact|extras...@fedoraproject.org | Last Closed||2021-06-20 12:56:27 --- Comment #9 from Neal Gompa --- Koschei reports that this is no longer a problem: https://koschei.fedoraproject.org/build/10490013 -- 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
License field change: dippi
The dippi package has been updated to 3.1.0 for ElementaryOS 6 in Rawhide. Upstream clarified the licensing, and the entire program is now GPLv3+ with CC0 AppStream metadata. Based on this, and on recent discussion suggesting a community preference for using effective licenses where feasible, the License field has been updated from “GPLv3+ and GPLv2+ and CC0” to "GPLv3+". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: RFC: Banning bots from submitting automated koji builds
Hi, On Sun, Jun 20, 2021 at 1:30 PM Neal Gompa wrote: > > On Sun, Jun 20, 2021 at 7:10 AM Peter Robinson wrote: > > > > > With things like [0] (TL;DR: bots submitting broken builds to rawhide) > > > becoming a more regular occurrence, I propose that we extend the > > > existing Updates Policy [1] to make it explicit that bots are not > > > allowed to submit builds / updates - even to rawhide - unattended: > > > "Rawhide is not your CI environment." > > > > I don't think that's good for either the packages that are using bots > > or for Fedora as a whole. > > > > While the bots certainly don't always get it right nor do the humans > > and I would garner that there's a lot more problems introduced in this > > way by humans, over the years I've spent considerable time fixing > > issues like this introduced by humans. Do we ban humans too? Do we ban > > RHBZ bots as well because they don't always get it right either? > > Ultimately automation is hard, but ultimately I feel it generally gets > > it wrong no less than humans do, and generally in a consistent way at > > least. > > > > > Currently, the Updates Policy states: > > > > > > - packagers must verify that no known broken builds are pushed, > > > - packagers must announce ABI and API changes once week in advance, > > > - packagers must not push pre-release versions of low-level packages. > > > > > > While it is debatable whether podman + friends + > > > container-stuff-dependencies count as "low-level" packages, they *are* > > > installed by default in Workstation. I think it is clear that by using > > > a bot to automatically push pre-release snapshots as rawhide updates, > > > the first two requirements CANNOT be met. > > > > > > I would like to make this conflict explicit and add a statement like > > > this to the Updates Policy: "Automated systems / bots are not allowed > > > to submit new builds for inclusion into Fedora without the involvement > > > of a packager." > > > > Please no. > > > > > The following things should still be allowed: > > > - releng and SIGs submitting scripted mass rebuilds (no actual package > > > changes, triggered by a person) > > > - bots submitting rawhide builds for ELN (no package change, just > > > built for different buildroot) > > > > > > The following should be explicitly banned: > > > - bots submitting new, non-scratch snapshot builds of software to > > > rawhide unattended (often leading to broken versions, versioning > > > snafus, or blatant errors leading to package downgrades, as it > > > happened today [0]) > > > > The problem with this is we will likely drive away contributors, > > packaging takes a lot of time, especially if you've got a stack of > > packages that are part of a group. > > > > Over the years there's been a bunch of effort all over the place to > > automate some of this, from tito, the upstream monitoring project > > thing (the new hottness or what ever it's called), packit and the rh > > container bot. None of them are perfect and all have their quirks. > > > > I would much sooner an officially support/ed/sanctioned auto packaging > > bot that upstreams can integrate into their projects to do automated > > packaging so they can get on and do more useful work either upstream > > or within the project. With something that is a "one true automated > > way" it would at least be consistent in the results. > > > > > There is already a requirement that no packager should submit builds > > > that are never intended to go "stable", and I see this as a similar > > > requirement - since those snapshot builds are presumably only done for > > > automated CI purposes without the intention of them ever reaching > > > stable Fedora releases, where they are superseded by packager-created > > > manual builds of those packages - but leaving Rawhide with unstable, > > > bot-created snapshot builds. > > > > I find the automated builds, in conjunction with OpenQA testing, very > > useful for IoT as they've caught a number of issues with upstream > > which likely wouldn't have been caught before the release goes stable > > and hence gets into stable IoT releases, it doesn't catch everything > > but the more it catches the better off the project is as a whole. > > > > I would much sooner the effort here goes into a sanctioned package > > build bot than trying to ban things TBH. > > > > Most of our rules are designed to make sure there's someone ultimately > responsible for everything going into Fedora. Unfortunately, bots are > the opposite of that, because there's no one to reach to stop bad > behavior when it happens. > > Rawhide is still not your CI environment. By the way I think we need to reconsider this statement. I think I understand the intent, but the statement itself is misleading, if not wrong, when taken out of context. For a person outside of the bubble it is hard to understand and it seems to be contradicting with the idea of Rawhide being the integrated development branch of the Fedora Linux
Re: RFC: Banning bots from submitting automated koji builds
On Sun, Jun 20, 2021 at 12:31 PM Neal Gompa wrote: > > On Sun, Jun 20, 2021 at 7:10 AM Peter Robinson wrote: > > > > > With things like [0] (TL;DR: bots submitting broken builds to rawhide) > > > becoming a more regular occurrence, I propose that we extend the > > > existing Updates Policy [1] to make it explicit that bots are not > > > allowed to submit builds / updates - even to rawhide - unattended: > > > "Rawhide is not your CI environment." > > > > I don't think that's good for either the packages that are using bots > > or for Fedora as a whole. > > > > While the bots certainly don't always get it right nor do the humans > > and I would garner that there's a lot more problems introduced in this > > way by humans, over the years I've spent considerable time fixing > > issues like this introduced by humans. Do we ban humans too? Do we ban > > RHBZ bots as well because they don't always get it right either? > > Ultimately automation is hard, but ultimately I feel it generally gets > > it wrong no less than humans do, and generally in a consistent way at > > least. > > > > > Currently, the Updates Policy states: > > > > > > - packagers must verify that no known broken builds are pushed, > > > - packagers must announce ABI and API changes once week in advance, > > > - packagers must not push pre-release versions of low-level packages. > > > > > > While it is debatable whether podman + friends + > > > container-stuff-dependencies count as "low-level" packages, they *are* > > > installed by default in Workstation. I think it is clear that by using > > > a bot to automatically push pre-release snapshots as rawhide updates, > > > the first two requirements CANNOT be met. > > > > > > I would like to make this conflict explicit and add a statement like > > > this to the Updates Policy: "Automated systems / bots are not allowed > > > to submit new builds for inclusion into Fedora without the involvement > > > of a packager." > > > > Please no. > > > > > The following things should still be allowed: > > > - releng and SIGs submitting scripted mass rebuilds (no actual package > > > changes, triggered by a person) > > > - bots submitting rawhide builds for ELN (no package change, just > > > built for different buildroot) > > > > > > The following should be explicitly banned: > > > - bots submitting new, non-scratch snapshot builds of software to > > > rawhide unattended (often leading to broken versions, versioning > > > snafus, or blatant errors leading to package downgrades, as it > > > happened today [0]) > > > > The problem with this is we will likely drive away contributors, > > packaging takes a lot of time, especially if you've got a stack of > > packages that are part of a group. > > > > Over the years there's been a bunch of effort all over the place to > > automate some of this, from tito, the upstream monitoring project > > thing (the new hottness or what ever it's called), packit and the rh > > container bot. None of them are perfect and all have their quirks. > > > > I would much sooner an officially support/ed/sanctioned auto packaging > > bot that upstreams can integrate into their projects to do automated > > packaging so they can get on and do more useful work either upstream > > or within the project. With something that is a "one true automated > > way" it would at least be consistent in the results. > > > > > There is already a requirement that no packager should submit builds > > > that are never intended to go "stable", and I see this as a similar > > > requirement - since those snapshot builds are presumably only done for > > > automated CI purposes without the intention of them ever reaching > > > stable Fedora releases, where they are superseded by packager-created > > > manual builds of those packages - but leaving Rawhide with unstable, > > > bot-created snapshot builds. > > > > I find the automated builds, in conjunction with OpenQA testing, very > > useful for IoT as they've caught a number of issues with upstream > > which likely wouldn't have been caught before the release goes stable > > and hence gets into stable IoT releases, it doesn't catch everything > > but the more it catches the better off the project is as a whole. > > > > I would much sooner the effort here goes into a sanctioned package > > build bot than trying to ban things TBH. > > > > Most of our rules are designed to make sure there's someone ultimately > responsible for everything going into Fedora. Unfortunately, bots are > the opposite of that, because there's no one to reach to stop bad > behavior when it happens. So that should be fixed so that each bot has a contact so that problems have means of escalation. > Rawhide is still not your CI environment. Years ago, we got rid of > alphas for the express purpose to stabilize Rawhide into alpha > quality. Stuff like this degrades the quality of Rawhide because they > make the assumption that nobody cares about the quality of Rawhide. Being one of the people
Re: RFC: Banning bots from submitting automated koji builds
On Sun, Jun 20, 2021 at 7:10 AM Peter Robinson wrote: > > > With things like [0] (TL;DR: bots submitting broken builds to rawhide) > > becoming a more regular occurrence, I propose that we extend the > > existing Updates Policy [1] to make it explicit that bots are not > > allowed to submit builds / updates - even to rawhide - unattended: > > "Rawhide is not your CI environment." > > I don't think that's good for either the packages that are using bots > or for Fedora as a whole. > > While the bots certainly don't always get it right nor do the humans > and I would garner that there's a lot more problems introduced in this > way by humans, over the years I've spent considerable time fixing > issues like this introduced by humans. Do we ban humans too? Do we ban > RHBZ bots as well because they don't always get it right either? > Ultimately automation is hard, but ultimately I feel it generally gets > it wrong no less than humans do, and generally in a consistent way at > least. > > > Currently, the Updates Policy states: > > > > - packagers must verify that no known broken builds are pushed, > > - packagers must announce ABI and API changes once week in advance, > > - packagers must not push pre-release versions of low-level packages. > > > > While it is debatable whether podman + friends + > > container-stuff-dependencies count as "low-level" packages, they *are* > > installed by default in Workstation. I think it is clear that by using > > a bot to automatically push pre-release snapshots as rawhide updates, > > the first two requirements CANNOT be met. > > > > I would like to make this conflict explicit and add a statement like > > this to the Updates Policy: "Automated systems / bots are not allowed > > to submit new builds for inclusion into Fedora without the involvement > > of a packager." > > Please no. > > > The following things should still be allowed: > > - releng and SIGs submitting scripted mass rebuilds (no actual package > > changes, triggered by a person) > > - bots submitting rawhide builds for ELN (no package change, just > > built for different buildroot) > > > > The following should be explicitly banned: > > - bots submitting new, non-scratch snapshot builds of software to > > rawhide unattended (often leading to broken versions, versioning > > snafus, or blatant errors leading to package downgrades, as it > > happened today [0]) > > The problem with this is we will likely drive away contributors, > packaging takes a lot of time, especially if you've got a stack of > packages that are part of a group. > > Over the years there's been a bunch of effort all over the place to > automate some of this, from tito, the upstream monitoring project > thing (the new hottness or what ever it's called), packit and the rh > container bot. None of them are perfect and all have their quirks. > > I would much sooner an officially support/ed/sanctioned auto packaging > bot that upstreams can integrate into their projects to do automated > packaging so they can get on and do more useful work either upstream > or within the project. With something that is a "one true automated > way" it would at least be consistent in the results. > > > There is already a requirement that no packager should submit builds > > that are never intended to go "stable", and I see this as a similar > > requirement - since those snapshot builds are presumably only done for > > automated CI purposes without the intention of them ever reaching > > stable Fedora releases, where they are superseded by packager-created > > manual builds of those packages - but leaving Rawhide with unstable, > > bot-created snapshot builds. > > I find the automated builds, in conjunction with OpenQA testing, very > useful for IoT as they've caught a number of issues with upstream > which likely wouldn't have been caught before the release goes stable > and hence gets into stable IoT releases, it doesn't catch everything > but the more it catches the better off the project is as a whole. > > I would much sooner the effort here goes into a sanctioned package > build bot than trying to ban things TBH. > Most of our rules are designed to make sure there's someone ultimately responsible for everything going into Fedora. Unfortunately, bots are the opposite of that, because there's no one to reach to stop bad behavior when it happens. Rawhide is still not your CI environment. Years ago, we got rid of alphas for the express purpose to stabilize Rawhide into alpha quality. Stuff like this degrades the quality of Rawhide because they make the assumption that nobody cares about the quality of Rawhide. If you want the features of Rawhide for CI, then we should talk about enabling this in more places. For example, there's no technical reason we couldn't do OpenQA runs for packages in COPR. There are serious consequences to shipping packages into Rawhide, not the least of which is that it locks an NVR forever into Koji and ships it to people using Rawhide as a
Re: RFC: Banning bots from submitting automated koji builds
> With things like [0] (TL;DR: bots submitting broken builds to rawhide) > becoming a more regular occurrence, I propose that we extend the > existing Updates Policy [1] to make it explicit that bots are not > allowed to submit builds / updates - even to rawhide - unattended: > "Rawhide is not your CI environment." I don't think that's good for either the packages that are using bots or for Fedora as a whole. While the bots certainly don't always get it right nor do the humans and I would garner that there's a lot more problems introduced in this way by humans, over the years I've spent considerable time fixing issues like this introduced by humans. Do we ban humans too? Do we ban RHBZ bots as well because they don't always get it right either? Ultimately automation is hard, but ultimately I feel it generally gets it wrong no less than humans do, and generally in a consistent way at least. > Currently, the Updates Policy states: > > - packagers must verify that no known broken builds are pushed, > - packagers must announce ABI and API changes once week in advance, > - packagers must not push pre-release versions of low-level packages. > > While it is debatable whether podman + friends + > container-stuff-dependencies count as "low-level" packages, they *are* > installed by default in Workstation. I think it is clear that by using > a bot to automatically push pre-release snapshots as rawhide updates, > the first two requirements CANNOT be met. > > I would like to make this conflict explicit and add a statement like > this to the Updates Policy: "Automated systems / bots are not allowed > to submit new builds for inclusion into Fedora without the involvement > of a packager." Please no. > The following things should still be allowed: > - releng and SIGs submitting scripted mass rebuilds (no actual package > changes, triggered by a person) > - bots submitting rawhide builds for ELN (no package change, just > built for different buildroot) > > The following should be explicitly banned: > - bots submitting new, non-scratch snapshot builds of software to > rawhide unattended (often leading to broken versions, versioning > snafus, or blatant errors leading to package downgrades, as it > happened today [0]) The problem with this is we will likely drive away contributors, packaging takes a lot of time, especially if you've got a stack of packages that are part of a group. Over the years there's been a bunch of effort all over the place to automate some of this, from tito, the upstream monitoring project thing (the new hottness or what ever it's called), packit and the rh container bot. None of them are perfect and all have their quirks. I would much sooner an officially support/ed/sanctioned auto packaging bot that upstreams can integrate into their projects to do automated packaging so they can get on and do more useful work either upstream or within the project. With something that is a "one true automated way" it would at least be consistent in the results. > There is already a requirement that no packager should submit builds > that are never intended to go "stable", and I see this as a similar > requirement - since those snapshot builds are presumably only done for > automated CI purposes without the intention of them ever reaching > stable Fedora releases, where they are superseded by packager-created > manual builds of those packages - but leaving Rawhide with unstable, > bot-created snapshot builds. I find the automated builds, in conjunction with OpenQA testing, very useful for IoT as they've caught a number of issues with upstream which likely wouldn't have been caught before the release goes stable and hence gets into stable IoT releases, it doesn't catch everything but the more it catches the better off the project is as a whole. I would much sooner the effort here goes into a sanctioned package build bot than trying to ban things TBH. Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-20210620.0 compose check report
No missing expected images. Failed openQA tests: 8/8 (x86_64) Old failures (same test failed in Fedora-Cloud-34-20210619.0): ID: 912645 Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount URL: https://openqa.fedoraproject.org/tests/912645 ID: 912646 Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start URL: https://openqa.fedoraproject.org/tests/912646 ID: 912647 Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli URL: https://openqa.fedoraproject.org/tests/912647 ID: 912648 Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove URL: https://openqa.fedoraproject.org/tests/912648 ID: 912649 Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging URL: https://openqa.fedoraproject.org/tests/912649 ID: 912650 Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation URL: https://openqa.fedoraproject.org/tests/912650 ID: 912651 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/912651 ID: 912652 Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux URL: https://openqa.fedoraproject.org/tests/912652 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-20210619.0): ID: 912657 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/912657 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: RFC: Banning bots from submitting automated koji builds
On Sun, Jun 20, 2021 at 10:45 AM Miro Hrončok wrote: > > I think this is a good idea. This particular bot has a history of misbehavior > and rather than banning all the well behaving bots (that be definition we > don't > even know about, because they behave good), we should disable this particular > one. > > Rather than "no bots allowed" policy, we might need a "bots that violate our > policies and guidelines or have a tendency to break things will be disabled > until fixed" policy. Yeah, that works for me too. Though I wouldn't want to make this a special case and create an actual policy for this instead, that we could point to when something like this happens. I also think that I probably was not clear in my original message. Any builds that are triggered by an actual human action, like - scripted (mass) rebuilds with no *Version* changes, - automatic builds after human-approved PRs, - etc. are of course exempt, because the action of an actual human being triggered them. The only thing I *don't* want is: Bots submitting builds for new *Versions*, without human interaction. Regarding Zbyszek's point: > Second, I think the guideline is simply wrong. As counterexamples, we > currently have python3.10beta2 in rawhide, systemd-249-rc1, and > kernel-5.13.0-0.rc6. Pushing pre-release vesions of low-level packages > is a crucial part of development of the distro and collaboration with > upstream projects and language ecosystems. There's actually already an exemption in the Updates Policy for those cases. And I don't have any problem with those, because those builds are prepared, built, tested, and shepherded by actual humans, instead of created by a bot that just throws them at the wall to see what sticks and what doesn't. If you look at bodhi updates for rhcontainerbot it's pretty obvious that nobody even looks at the updates that are created for those builds: https://bodhi.fedoraproject.org/updates/?search==testing=rhcontainerbot It looks like any build that receives -1 karma or fails gating tests will just be stuck in "testing" until obsoleted by the next automated build for that package. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: RFC: Banning bots from submitting automated koji builds
On 20. 06. 21 9:39, Zbigniew Jędrzejewski-Szmek wrote: I think we should just disable this particular bot until it fixed. We should also clarify/update the Update Guidelines so that undesirable updates are disallowed, no matter if submitted by a bot or a human. I think this is a good idea. This particular bot has a history of misbehavior and rather than banning all the well behaving bots (that be definition we don't even know about, because they behave good), we should disable this particular one. Rather than "no bots allowed" policy, we might need a "bots that violate our policies and guidelines or have a tendency to break things will be disabled until fixed" policy. -- 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: RFC: Banning bots from submitting automated koji builds
On 19. 06. 21 22:18, Fabio Valentini wrote: The following things should still be allowed: - releng and SIGs submitting scripted mass rebuilds (no actual package changes, triggered by a person) - bots submitting rawhide builds for ELN (no package change, just built for different buildroot) Other random ideas of what should be allowed: - a human approves a pull request, bot merges it and builds - a bot rebuilds packages automatically (bump-only or no changes), when dependencies change -- 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
[Bug 1973908] perl-App-Cmd-0.334 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1973908 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-App-Cmd-0.334-1.fc35 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2021-06-20 08:20:00 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1773975 -- 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 1973898] perl-Test-Routine-0.028 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1973898 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Test-Routine-0.028-1.f ||c35 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2021-06-20 08:18:24 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1773998 -- 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 1973648] perl-Crypt-RandPasswd-0.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1973648 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Crypt-RandPasswd-0.07- ||1.fc35 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2021-06-20 08:17:34 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1773977 -- 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 1973290] perl-Email-Sender-1.300036 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1973290 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Email-Sender-1.300036- ||1.fc35 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2021-06-20 08:15:44 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1773979 -- 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: RFC: Banning bots from submitting automated koji builds
On Sat, Jun 19, 2021 at 10:18:45PM +0200, Fabio Valentini wrote: > Hi everybody, > > With things like [0] (TL;DR: bots submitting broken builds to rawhide) > becoming a more regular occurrence, I propose that we extend the > existing Updates Policy [1] to make it explicit that bots are not > allowed to submit builds / updates - even to rawhide - unattended: > "Rawhide is not your CI environment." I agree with the goal of avoiding random snapshot packages in rawhide, but I disagree that banning bots is the way to achieve that. In this particular case, the problem is that the bot is either buggy or misconfigured or both. (I hope that the discussion in the other thread can clarify what went wrong.) A blanket ban for automated updates doesn't directly address the problem (because even a human could push the same broken snapshots to rawhide), and will constrain future development. [For example, let's say we make a bot that looks at the huge Python3.10 FTBFS/FTI dependency tree, watches bugzilla events, and automatically fires off a no-change rebuild of packages for which all depended-on have been closed. It would be forbidden by this policy, even though it wouldn't cause those kinds of problems we have now.] I think we should just disable this particular bot until it fixed. We should also clarify/update the Update Guidelines so that undesirable updates are disallowed, no matter if submitted by a bot or a human. > Currently, the Updates Policy states: > > - packagers must verify that no known broken builds are pushed, > - packagers must announce ABI and API changes once week in advance, > - packagers must not push pre-release versions of low-level packages. > > While it is debatable whether podman + friends + > container-stuff-dependencies count as "low-level" packages, they *are* > installed by default in Workstation. I think it is clear that by using > a bot to automatically push pre-release snapshots as rawhide updates, > the first two requirements CANNOT be met. First, I think podman fits the intent of this guideline, even if not the letter. Second, I think the guideline is simply wrong. As counterexamples, we currently have python3.10beta2 in rawhide, systemd-249-rc1, and kernel-5.13.0-0.rc6. Pushing pre-release vesions of low-level packages is a crucial part of development of the distro and collaboration with upstream projects and language ecosystems. 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
Fedora-Cloud-33-20210620.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210619.0): ID: 912635 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/912635 ID: 912641 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/912641 Passed openQA tests: 7/8 (x86_64), 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: Fedora rawhide compose report: 20210619.n.0 changes
On Sat, Jun 19, 2021 at 03:44:11PM +0200, Fabio Valentini wrote: > On Sat, Jun 19, 2021 at 2:52 PM Fedora Rawhide Report > wrote: > > > > = DOWNGRADED PACKAGES = > > Package: crun-0.19.1.13-0.15.git63400f2.fc35 > > Old package: crun-0.20.1.3-0.14.git9dec366.fc35 > > Summary: OCI runtime written in C > > RPMs: crun > > Size: 846.40 KiB > > Size change: -6.22 KiB > > Changelog: > > * Sat Jun 19 2021 RH Container Bot - > > 0.19.1.13-0.15.git63400f2 > > - bump to 0.19.1.13 > > - autobuilt 63400f2 > > > > > > Package: fuse-overlayfs-0.7.8-2.dev.git5f666c1.fc35 > > Old package: fuse-overlayfs-1.6-3.dev.git91a020f.fc35 > > Summary: FUSE overlay+shiftfs implementation for rootless containers > > RPMs: fuse-overlayfs > > Size: 348.69 KiB > > Size change: -18.67 KiB > > Changelog: > > * Sat Jun 19 2021 RH Container Bot - > > 0.7.8-2.dev.git5f666c1 > > - bump to 0.7.8 > > - autobuilt 5f666c1 > > I swear ... is rhcontainerbot at it again? > https://pagure.io/fesco/issue/2624 > > Both of those look like obvious mistakes, since they're not just > "versioning snafu"s but real version downgrades. What *is* the purpose of RH Container Bot? A google search shows various repos seemingly used by it, but why and how? 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
