Re: Missing LLVM stack bugfix updates in stable Fedora branches
On 8/18/22 15:32, Fabio Valentini wrote: On Thu, Aug 18, 2022 at 5:23 PM Tom Stellard wrote: I'm working on the 14.0.5 update for F36 right now. The 14.0.6 release is going to have to wait until after 15.0.0 lands in F37 and rawhide, because I don't think it's worth doing the 14.0.6 update there, since 15.0.0 is so close. Awesome, thanks for the update! Here is the Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-2022-eecc713e20 14.0.6 only has a small fix that probably won't affect most Fedora users, so I think 14.0.5 should be fine for now. Sounds good to me :) Thanks again, 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, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2119903] New: Please branch and build perl-Net-Patricia for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2119903 Bug ID: 2119903 Summary: Please branch and build perl-Net-Patricia for EPEL 9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-Net-Patricia Assignee: or...@nwra.com Reporter: fedoraproj...@virtual.drop.net QA Contact: extras...@fedoraproject.org CC: or...@nwra.com, perl-devel@lists.fedoraproject.org, phil...@redfish-solutions.com Target Milestone: --- Classification: Fedora Please branch and build perl-Net-Patricia for EPEL 9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2119903 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2119901] New: perl-Business-CreditCard-0.39 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2119901 Bug ID: 2119901 Summary: perl-Business-CreditCard-0.39 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Business-CreditCard Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jpazdzi...@redhat.com, mastah...@gmail.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 0.39 Upstream release that is considered latest: 0.39 Current version/release in rawhide: 0.36-19.fc37 URL: http://search.cpan.org/dist/Business-CreditCard/ 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/2672/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Business-CreditCard -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2119901 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
python-ntlm-auth License Correction
I've corrected the license of python-ntlm-auth from LGPLv3+ to MIT. It was relicensed upstream 5 years ago, but the previous maintainer never updated the License field. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 Beta blocker status email
Action summary Accepted blockers - 1. kde-settings — KDE needs to pick up F37 backgrounds — ON_QA ACTION: None 2. sddm — Logout from KDE session on Rawhide goes to console, not SDDM — POST ACTION: Maintainers to build package with X11 by default Proposed blockers - 1. anaconda — Anaconda will not start F37 Raw — NEW ACTION: Reporter to provide requested log files NEEDINFO: aalmeleh.whatever.0101 2. dnf — "dnf update" runs out of memory on swapless 0.5 GiB RAM machine — NEW ACTION: Maintainers to investigate short-term dnf improvements NEEDINFO: jmracek 3. openssl-pkcs11 — FreeIPA client enrollment fails due to DNS issues with openssl-pkcs11-0.4.12-2.fc37 — NEW ACTION: Maintainers to diagnose issue 4. osinfo-db — failed to install server iso with virt-install due to the missing of isolinux in the media — NEW ACTION: Maintainers to diagnose issue Bug-by-bug detail = Accepted blockers - 1. kde-settings — https://bugzilla.redhat.com/show_bug.cgi?id=2117706 — ON_QA KDE needs to pick up F37 backgrounds New desktop backgrounds require a new KDE settings update. Fixed in FEDORA-2022-fe8729bced. 2. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=2110801 — NEW Logout from KDE session on Rawhide goes to console, not SDDM After logging out of KDE Plasma, you end up at a console on tty2. SDDM had been running on tty1 but just shows a flashing cursor. This appears to be specific to Wayland, so a PR is pending to revert to and X11 default. Proposed blockers - 1. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=2101229 — NEW Anaconda will not start F37 Raw Neither clicking the desktop icon nor the taskbar icon will launch anaconda. openQA is not experiencing this. Using basic graphics mode results in the expected behavior. 2. dnf — https://bugzilla.redhat.com/show_bug.cgi?id=1907030 — NEW "dnf update" runs out of memory on swapless 0.5 GiB RAM machine dnf is killed by oom-kill on machines with 512 MB of RAM. Adding a swap disk or disabling the updates repo works around this issue. Recently, FCOS has seen this behavior with 1 GB VMs. The issue appears to be the size of the metadata for the repository. The short term fixes look like they may need to be made on the repo side, not in dnf. 3. openssl-pkcs11 — https://bugzilla.redhat.com/show_bug.cgi?id=2117859 — NEW FreeIPA client enrollment fails due to DNS issues with openssl-pkcs11-0.4.12-2.fc37 Tests in openQA cannot resolve kojipkgs.fedoraproject.org. Previous F37 build (openssl-okcs11-0.4.12-1.fc37) behaves as expected. The corresponding versions both work on F36. Disabling dnssec on the server is a workaround. 4. osinfo-db — https://bugzilla.redhat.com/show_bug.cgi?id=2103835 — NEW failed to install server iso with virt-install due to the missing of isolinux in the media virt-install fails because there's no isolinux path, where it looks for vmlinuz and initrd.img . An upstream fix has been released in F35, F36, and F37 updates, but it does not appear to fully solve the problem on F37 and Rawhide. See also RHBZ 2119633. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2119882] New: perl-Socket-2.036 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2119882 Bug ID: 2119882 Summary: perl-Socket-2.036 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Socket Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 2.036 Upstream release that is considered latest: 2.036 Current version/release in rawhide: 2.035-2.fc37 URL: http://search.cpan.org/dist/Socket/ 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/3321/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Socket -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2119882 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Fri, Aug 19, 2022 at 10:47 AM P J P wrote: > * Interesting numbers there. (see below on another number) > * While I get that such pruning from time to time is generally good. > What happens to the packages orphaned by removing inactive packagers? > > * Removing orphaned packages may not be easy, as other packages may depend on > them. Obviously, if the packages are still desired or needed, an active packager will need to pick them up. For a number of those packages I suspect that they have been running more or less on successful auto-pilot (mass rebuild) for some time, so picking them up should not result in substantially increased workload going forward after the initial take, but I admit I, myself, do not look forward to having to add to the list of packages I might need to feel (at least notionally) responsible for if I end up having to take some of them on due to dependencies in things I do care about. I would also say, that while it is probably not entirely easy to do so, a *very* interesting additional number would have been how many packages would be orphaned if all of the identified packagers are removed, just so we have an order of magnitude of what we are looking at moving forward. But that list is probably best produced at a later time, as, for all we know, many of the people may indeed still be active (and because their packagers do run on auto-pilot, do not regularly engage). These are, of course, probably mostly first run issues. Once the process is in place and ongoing, the order of magnitude of the people and packages is likely to be the usual background noise levels. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: nspawn for rawhide?
On Fri, Aug 19, 2022 at 04:50:07PM +0200, Florian Weimer wrote: > * Stephen Smoogen: > > > On Fri, 19 Aug 2022 at 05:44, Florian Weimer wrote: > > > > * Kevin Fenzi: > > > > > Greetings everyone. > > > > > > Many years ago mock introduced and then made default it's isolation to > > > use systemd-nspawn instead of chroot. Shortly after the nspawn isolation > > > was added, it was used in fedoraproject koji builds, but there were > > > issues and since then the fedoraproject koji has defaulted to using > > > chroot isolation. > > > > > > Releng has had a ticket open for a long time to switch > > > ( https://pagure.io/releng/issue/6967 ) > > > > > > I think the two items listed there (kernel bind mounts and loop devices) > > > have long since been fixed, so I would like to propose we switch rawhide > > > to using nspawn and see if any other issues show up. > > > > What's the version of nspawn that will be used here? Presumably it's > > not the rawhide version, but the host version? > > > > Currently I think all builders are Fedora 36. > > Okay, I tried to reproduce this environment with the mock in Fedora 36 > and the fedora-rawhide-x86_64 configuration. This tester: snip... > > This looks very good, no problematic EPERM errors. So I don't expect > this type of system call compatibility issues from the switch. Great! thanks for testing. I seem to dimly recall that glibc was something that nspawn broke before, but like I said, it was only right after it landed that it was even attempted. Since everyone seems postivie on this, I'll look at switching it on monday and see what breaks. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: nspawn for rawhide?
On 18. 08. 22 23:01, Kevin Fenzi wrote: Greetings everyone. Many years ago mock introduced and then made default it's isolation to use systemd-nspawn instead of chroot. Shortly after the nspawn isolation was added, it was used in fedoraproject koji builds, but there were issues and since then the fedoraproject koji has defaulted to using chroot isolation. Releng has had a ticket open for a long time to switch ( https://pagure.io/releng/issue/6967 ) I think the two items listed there (kernel bind mounts and loop devices) have long since been fixed, so I would like to propose we switch rawhide to using nspawn and see if any other issues show up. If everyone is ok with it, I can enable it (just for rawhide) and we can look for issues with composes or any other items. At least then we would have a good list of things we would like to fix. If it turns out things just work ok we can leave it enabled. I think moving to this will: * More closely match developers local test mock builds. * Provide better isolation for builds * Help with resources as systemd-nspawn is a lot more cgroup aware than chroot * Allow us to close a 5 year old ticket. ;) Thoughts? Let's do it :) -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: ca-certificates latest updates and Mozilla NSS certdata.txt modifications
On 8/19/22 6:08 AM, Alexander Sosedkin wrote:
On Thu, Aug 18, 2022 at 1:45 PM Yann Droneaud wrote:
I've noticed ca-certificates package was updated recently, and went looking
at the changes, and I have some questions.
Not Bob Relyea, but I'll try to answer to the best of my knowledge:
Alexander is correct. Most of the information you are looking for is in :
https://bugzilla.redhat.com/show_bug.cgi?id=2117793
The certdata.txt is created by using scripts in
https://github.com/rjrelyea/ca-certificate-scripts, namely
fetch_objsign.sh and mergepem2certdata.py. The former fetches the
appropriate object signing list of certs and mergepem2certdata.py merges
it with the mozilla certdata.txt.
Certs that are only in the object signing list are marked in comments
("microsoft object signing only") and should only have the object
signing bit on. They won't show up in any extracted lists except
/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem.
Certs that are in both lists keep the mozilla entry and have the object
signing trust attribute turned on.
Once there are versioned object signing releases from microsoft I'll
update the fetch scripts in the ca-certificate package on rawhide so
others can optionally pick up these changes as well (as well as adding
time-stamping support).
bob
The first issue is what certdata.txt was used ? It's supposed to be
downloaded from Mozilla NSS sources, but doesn't match any released
versions.
3.79, as suggested by both the changelog entries and
https://src.fedoraproject.org/rpms/ca-certificates/blob/rawhide/f/nssckbi.h
matching
https://hg.mozilla.org/projects/nss/raw-file/NSS_3_79_RTM/lib/ckfw/builtins/nssckbi.h
The second issue is what are the changes that were made to certdata.txt ?
The commit messages and RPM changelogs say the root CA certificate database
was updated thrice to the same version.
Below the 3 latest updates to certdata.txt used to build the root CA
certificates database in ca-certificates RPM package for Fedora Rawhide
from ca-certificates git repository
...
As you can find, the last 3 ca-certificate's certdata.txt version match
*no* NSS's certdata.txt which is suspicious.
In https://fedoraproject.org/wiki/CA-Certificates it is said, that since
Fedora 25, there's no modification on the upstream root certificates
database. So what happened here ?
Unfortunately, the ca-certificates' commit messages nor the RPM's changelog
provide any reason for the differences.
This raise the question of the trust we can have in the update, if the
certdata.txt supposedly imported from Mozilla NSS, doesn't match any file
released by Mozilla.
Indeed it doesn't.
If you diff it against Mozilla's
https://hg.mozilla.org/projects/nss/log/NSS_3_79_RTM/lib/ckfw/builtins/certdata.txt
you should observe significant differences of two varieties:
1. -CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_MUST_VERIFY_TRUST
+CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_TRUSTED_DELEGATOR
on some of the Mozilla-originating certificates
2. half of the file consisting of newly added certificates with a comment
# Microsoft Code Signing Only Certificate
trusted for code signing alone.
diff -U0 upstream-3.79.txt certdata-fedora.txt | grep CKA_TRUST | sort -u
+CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_TRUSTED_DELEGATOR
+CKA_TRUST_EMAIL_PROTECTION CK_TRUST CKT_NSS_MUST_VERIFY_TRUST
+CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_MUST_VERIFY_TRUST
+CKA_TRUST_STEP_UP_APPROVED CK_BBOOL CK_FALSE
-CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_MUST_VERIFY_TRUST
Thus, for purposes other than code signing we have effectively
Mozilla's 3.79 version.
For code signing, we additionally trust an extra set of certificates,
including ones not coming from Mozilla.
The rather detailed description in
https://bugzilla.redhat.com/show_bug.cgi?id=2117793
suggests that this is an unfortunately non-transparent stop-gap
solution of sorts
to satisfy .NET code signing needs while a better approach is in the works.
Commit messages (and RPM changelog) should details the changes made to the
NSS's certdata.txt during the update. And, for the sake of traceability, the
repository, branch, tag, hg commit, from which certdata.txt was pulled
should
also be part of the commit message (and RPM changelog). (and an empty line
between commit title and the rest of the commit message would be
appreciated,
for git log --oneline usage).
That'd be great.
The RPM change log and git log come from the release tools. When I
release a new version of ca-certificates, I release them on a number of
platforms (and have to deal with some rhel process). Unfortunately it
means that it wasn't easy to add this kind of change to the actual
checking on all these platforms (since it was mostly automated.
It should also be noted the fetch.sh script (most notably check_certs.sh) is
doing a terrible job at reporting the changes, most notably saying already
present certificates are added.
I'd also like to suggest separating Mozilla and
Re: Inactive packagers to be removed after the F37 release
Il 19/08/22 14:07, Ben Cotton ha scritto: > On Fri, Aug 19, 2022 at 2:46 AM Merlin Cooper > wrote: >> I like this policy, but it strikes me as odd that the packagers' email >> addresses are posted publicly on the Pagure tickets... Wouldn't that >> make it easier for spammers to get more email addresses? > The script has a flag I can use in the future which (I believe) will > mask the addresses in the tickets. I didn't use it this time because > email addresses are already displayed all over the place. If a spammer > gets an email address from these tickets that they didn't have before, > then I'll be very surprised. > The '--privacy' flag I've put in the code only masks email addresses in the logs. At the time I've added the flag, the purpose was to be able to share the logs into the policy proposal. I think it should be fairly simple to use the same flag to also mask the email in the tickets text. Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: nspawn for rawhide?
* Stephen Smoogen:
> On Fri, 19 Aug 2022 at 05:44, Florian Weimer wrote:
>
> * Kevin Fenzi:
>
> > Greetings everyone.
> >
> > Many years ago mock introduced and then made default it's isolation to
> > use systemd-nspawn instead of chroot. Shortly after the nspawn isolation
> > was added, it was used in fedoraproject koji builds, but there were
> > issues and since then the fedoraproject koji has defaulted to using
> > chroot isolation.
> >
> > Releng has had a ticket open for a long time to switch
> > ( https://pagure.io/releng/issue/6967 )
> >
> > I think the two items listed there (kernel bind mounts and loop devices)
> > have long since been fixed, so I would like to propose we switch rawhide
> > to using nspawn and see if any other issues show up.
>
> What's the version of nspawn that will be used here? Presumably it's
> not the rawhide version, but the host version?
>
> Currently I think all builders are Fedora 36.
Okay, I tried to reproduce this environment with the mock in Fedora 36
and the fedora-rawhide-x86_64 configuration. This tester:
#include
#include
#include
#include
#include
#include
#include
#include
#include
static void
noop_handler (int signo)
{
}
int
main (int argc, char **argv)
{
if (argc != 3)
{
fprintf (stderr, "usage: %s FIRST-SYSCALL LAST-SYSCALL\n", argv[0]);
return 1;
}
int first_syscall = atoi (argv[1]);
if (first_syscall <= 0)
errx (1, "invalid system call number: %s", argv[1]);
int last_syscall = atoi (argv[2]);
if (last_syscall <= 0)
errx (1, "invalid system call number: %s", argv[2]);
if (signal (SIGALRM, noop_handler) == SIG_ERR)
err (1, "signal (SIGALRM)");
volatile long int *results = mmap (NULL, 2 * sizeof (*results),
PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_SHARED, -1, 0);
if (results == MAP_FAILED)
err (1, "mmap");
for (int nr = first_syscall; nr <= last_syscall; ++nr)
{
results[0] = -1;
results[1] = 0;
pid_t pid = fork ();
if (pid < 0)
err (1, "fork");
if (pid == 0)
{
errno = 0;
results[0] = syscall (nr, 0, 0, 0, 0, 0, 0, 0);
results[1] = errno;
_exit (0);
}
alarm (1);
int status;
int waitpid_ret = waitpid (pid, , 0);
int waitpid_error = errno;
alarm (0);
if (waitpid_ret < 0)
{
if (errno != EINTR)
{
errno = waitpid_error;
err (1, "waitpid");
}
else
printf ("%d: timeout\n", nr);
}
else if (results[1] != ENOSYS)
{
errno = results[1];
printf("%d: %ld (errno %ld [%#m])\n", nr, results[0], results[1]);
}
}
}
Produces this output when run with arguments 330 800:
330: 1 (errno 0 [Success])
331: 0 (errno 0 [Success])
332: -1 (errno 14 [Bad address])
333: -1 (errno 22 [Invalid argument])
334: -1 (errno 22 [Invalid argument])
424: -1 (errno 9 [Bad file descriptor])
425: -1 (errno 14 [Bad address])
426: -1 (errno 95 [Operation not supported])
427: -1 (errno 95 [Operation not supported])
428: -1 (errno 14 [Bad address])
429: -1 (errno 14 [Bad address])
430: -1 (errno 14 [Bad address])
431: -1 (errno 22 [Invalid argument])
432: -1 (errno 22 [Invalid argument])
433: -1 (errno 14 [Bad address])
434: -1 (errno 22 [Invalid argument])
435: -1 (errno 22 [Invalid argument])
436: 0 (errno 0 [Success])
437: -1 (errno 22 [Invalid argument])
438: -1 (errno 9 [Bad file descriptor])
439: -1 (errno 14 [Bad address])
440: -1 (errno 9 [Bad file descriptor])
441: -1 (errno 22 [Invalid argument])
442: -1 (errno 22 [Invalid argument])
444: -1 (errno 14 [Bad address])
445: -1 (errno 77 [File descriptor in bad state])
446: -1 (errno 77 [File descriptor in bad state])
448: -1 (errno 9 [Bad file descriptor])
449: -1 (errno 22 [Invalid argument])
450: 0 (errno 0 [Success])
This looks very good, no problematic EPERM errors. So I don't expect
this type of system call compatibility issues from the switch.
Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Packaging a cross-compilation environment (wasi-libc)
Hi again, thanks for all the suggestions! I'm taking the AVR approach so far; if you want to play with my drafts, I have a experimental COPR: https://copr.fedorainfracloud.org/coprs/jstanek/wasi-libc/ I plan to open a proper Fedora Review request on Monday; right now, I'm a bit too tired to go through the bureaucracy Have a nice weekend! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Fri, 19 Aug 2022 at 08:42, Ian McInerney via devel < devel@lists.fedoraproject.org> wrote: > On Fri, Aug 19, 2022 at 1:08 PM Ben Cotton wrote: > >> On Fri, Aug 19, 2022 at 2:46 AM Merlin Cooper >> wrote: >> > >> > I like this policy, but it strikes me as odd that the packagers' email >> > addresses are posted publicly on the Pagure tickets... Wouldn't that >> > make it easier for spammers to get more email addresses? >> >> The script has a flag I can use in the future which (I believe) will >> mask the addresses in the tickets. I didn't use it this time because >> email addresses are already displayed all over the place. If a spammer >> gets an email address from these tickets that they didn't have before, >> then I'll be very surprised. >> > > I really wish people would stop making the argument that just because > other places/systems have terrible data hygiene, we can have terrible data > hygiene too. Fedora should be trying to set the example of how to interact > and behave, and the "follow the herd" mentality here is not acceptable in > my opinion. > > Email address could be considered PII, and so there is a debate about when > the GDPR-type regulations would apply to them (from what I read, it would > apply for work email addresses giving full names or personal email > addresses). While there is a legal basis for keeping the email address in > the system and using it, I fail to see a legal basis that would allow > publicly displaying an email address in this way. > > Many systems are also trying to reduce the exposure of personal email > addresses, with major git hosting providers even creating anonymous commit > emails that can be associated with user accounts on those systems and then > used for your commits should you choose. > > So in short, I strongly argue for masking/removing the email address from > all tickets like this, and the fact that they are displayed there was is so > concerning to me that I opened a ticket about it last night: > https://pagure.io/find-inactive-packagers/issue/619. > > I am going to argue that this isn't bad data hygiene because this data being public serves an important purpose for the ongoing working of this project. When you become a Fedora maintainer, you are not just helping your fellow maintainers, you are also helping the general public who may be upstream developers, users, and packagers in different projects. When a person makes a change or has had their 'hands' on a package, that is made public in many many places to make sure that any and all interested people can contact them for questions. Upstream may have suggestions to make that change better or worse. Other packagers may need to understand why that package affects them. Packagers in different projects need to contact to see if this will solve their problem with said package or not. This has been and is mostly still done via email first and bugzilla and other methods last. When that information is not easily available, trust in the change, package, maintainer drops. That lack of trust tends to boil through many areas and lowers trust in the overall operations of the distribution. Because of this, email addresses for packagers have never been very secret. They are in spec files, they are in email posts about changes to packages, they are in various message buses which anyone can subscribe to on the idea that the information being free improves trust. Then there comes the removal of privileges. This is a big concern and needs to be done in an open and clear fashion. Other developers and packagers need to understand WHO was attempted to be contacted and why that contact may have failed. When other projects have not done this in an open arena, it has caused unrelated packagers to quit because they are not sure they can trust the project to not do the same with them. There is also the fact that email addresses change a lot and sometimes the person who has been listed as `foo...@uforgot.me` may have gone to `notme@notmy.email` and need to update their info. It might be even clear that notme@notmy.email has been active in bugzilla or some other area but hasn't done a build because a different maintainer has done so. We may need to come up with different methods of 'trust'. That is a larger conversation because it would require a complete rethink of what we are as a project and how we 'trust' each other, and allow others to 'trust' us. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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,
Re: Retiring the pcre package from Fedora
On Thu, Aug 18, 2022 at 5:30 AM Zbigniew Jędrzejewski-Szmek wrote: > > Why F39? Shouldn't the deprecation (and the work on porting) be already > happening for F38? I'm going to wait to process the proposal until we have an answer to this question. (I believe Lukas is out of the office, so it may be a few days) -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: nspawn for rawhide?
On Fri, 19 Aug 2022 at 05:44, Florian Weimer wrote: > * Kevin Fenzi: > > > Greetings everyone. > > > > Many years ago mock introduced and then made default it's isolation to > > use systemd-nspawn instead of chroot. Shortly after the nspawn isolation > > was added, it was used in fedoraproject koji builds, but there were > > issues and since then the fedoraproject koji has defaulted to using > > chroot isolation. > > > > Releng has had a ticket open for a long time to switch > > ( https://pagure.io/releng/issue/6967 ) > > > > I think the two items listed there (kernel bind mounts and loop devices) > > have long since been fixed, so I would like to propose we switch rawhide > > to using nspawn and see if any other issues show up. > > What's the version of nspawn that will be used here? Presumably it's > not the rawhide version, but the host version? > Currently I think all builders are Fedora 36. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Is system upgrade automatic or not?
On Thu, 18 Aug 2022 at 21:52, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Stephen Smoogen wrote: > > I should have been clearer. I was talking about the changes between > > XP->7->8->8.1->10->11 versus 10. -> 10.. I was thinking > of > > it more since for the most part they used pretty much the same compiler > > for all of 10 versus new compiler and major library changes every six > > months > > That is a very developer-centric view though. End users will usually not This is a developer centric mailing list and you have in the past been quite likely to point out in very clear terms when I am not being developer centric here :). > > care about what compiler the operating system was compiled with, all the > more on Windows, which does not even ship with a compiler (so those who do > actually need to compile code can select their compiler version more or > less > independently of the operating system version). > > What they will notice though is when the Windows desktop shell (the > Windows > equivalent of KDE Plasma or GNOME Shell) gets a major update which makes > it > look different, and I know from Windows users' complaints that that > has > happened repeatedly in Windows 10 point releases. Start Menu, Control > Panel, > etc. have all had significant look changes at least once. > > And as you point out yourself, those updates are also not always without > issues. E.g., another frequent complaint is that device configuration is > reset during upgrades, e.g., that it simply forgets printers that are not > plugged in while upgrading (and always plugging in all hardware is not > possible on a notebook that travels between different locations). > > So I would really compare those Windows point releases with Fedora > releases. > The schedule is basically the same and the risk is also about the same. > (Though one difference is that Windows ships a lot less software, so you > can Yes they have a very much 'core'/'extras' viewpoint on their software. The 'core' parts are compiled with their same inhouse compilers for about '2 year' runs and then moved to the next level. [This is why there are 6 month updates and about an 18->24 month mega update in the 10 cycle.] They are now moving away from that and will just move to 11 and then 18 months to 2 years later to 12, etc according to their announced schedule. The extras are becoming more like 'flatpaks/scls' in that they are a bundled universe with their own path settings, libraries etc to make things work. Because it is a 'core'/'extras' strategy, I didn't see it as something we would emulate. > > have fewer issues with software getting upgraded as part of the operating > system upgrade there. Though that can also result in the application > stopping to work after the operating system upgrade, at least until you > manually upgrade the application as well.) > > I wonder whether we should simply switch Fedora releases to a different > numbering scheme more like RHEL or Windows. (Keep in mind that my > suggestion > would be only a pure renumbering, there would be no changes whatsoever to > the schedule (including EOL dates) or the nature of the releases.) So we > would by default just release the next Fedora as 37.1, then 37.2, etc. > Only > if some comittee (probably FESCo) decides that a release has enough major > changes to warrant a new major version (e.g., Fedora 9 with KDE/Plasma 4, > GCC 4, etc., or Fedora 15 with GNOME 3), then it moves to 38.0. This can > be > decided shortly before the release, after having the final list of > accepted > and not reverted changes. After all, Linus also decided on a fairly short > notice to renumber the kernel from Linux 5.20 to Linux 6.0, without even > any > reason for the bump other than "the second number is getting too large", > so > my proposal would work similarly, but less arbitrarily and more in the > spirit of semantic versioning. > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Re: ca-certificates latest updates and Mozilla NSS certdata.txt modifications
On Thu, Aug 18, 2022 at 1:45 PM Yann Droneaud wrote: > I've noticed ca-certificates package was updated recently, and went looking > at the changes, and I have some questions. Not Bob Relyea, but I'll try to answer to the best of my knowledge: > The first issue is what certdata.txt was used ? It's supposed to be > downloaded from Mozilla NSS sources, but doesn't match any released > versions. 3.79, as suggested by both the changelog entries and https://src.fedoraproject.org/rpms/ca-certificates/blob/rawhide/f/nssckbi.h matching https://hg.mozilla.org/projects/nss/raw-file/NSS_3_79_RTM/lib/ckfw/builtins/nssckbi.h > The second issue is what are the changes that were made to certdata.txt ? > The commit messages and RPM changelogs say the root CA certificate database > was updated thrice to the same version. > > Below the 3 latest updates to certdata.txt used to build the root CA > certificates database in ca-certificates RPM package for Fedora Rawhide > from ca-certificates git repository > ... > As you can find, the last 3 ca-certificate's certdata.txt version match > *no* NSS's certdata.txt which is suspicious. > > In https://fedoraproject.org/wiki/CA-Certificates it is said, that since > Fedora 25, there's no modification on the upstream root certificates > database. So what happened here ? > > Unfortunately, the ca-certificates' commit messages nor the RPM's changelog > provide any reason for the differences. > > This raise the question of the trust we can have in the update, if the > certdata.txt supposedly imported from Mozilla NSS, doesn't match any file > released by Mozilla. Indeed it doesn't. If you diff it against Mozilla's https://hg.mozilla.org/projects/nss/log/NSS_3_79_RTM/lib/ckfw/builtins/certdata.txt you should observe significant differences of two varieties: 1. -CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_MUST_VERIFY_TRUST +CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_TRUSTED_DELEGATOR on some of the Mozilla-originating certificates 2. half of the file consisting of newly added certificates with a comment # Microsoft Code Signing Only Certificate trusted for code signing alone. diff -U0 upstream-3.79.txt certdata-fedora.txt | grep CKA_TRUST | sort -u +CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_TRUSTED_DELEGATOR +CKA_TRUST_EMAIL_PROTECTION CK_TRUST CKT_NSS_MUST_VERIFY_TRUST +CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_MUST_VERIFY_TRUST +CKA_TRUST_STEP_UP_APPROVED CK_BBOOL CK_FALSE -CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_MUST_VERIFY_TRUST Thus, for purposes other than code signing we have effectively Mozilla's 3.79 version. For code signing, we additionally trust an extra set of certificates, including ones not coming from Mozilla. The rather detailed description in https://bugzilla.redhat.com/show_bug.cgi?id=2117793 suggests that this is an unfortunately non-transparent stop-gap solution of sorts to satisfy .NET code signing needs while a better approach is in the works. > Commit messages (and RPM changelog) should details the changes made to the > NSS's certdata.txt during the update. And, for the sake of traceability, the > repository, branch, tag, hg commit, from which certdata.txt was pulled > should > also be part of the commit message (and RPM changelog). (and an empty line > between commit title and the rest of the commit message would be > appreciated, > for git log --oneline usage). That'd be great. > It should also be noted the fetch.sh script (most notably check_certs.sh) is > doing a terrible job at reporting the changes, most notably saying already > present certificates are added. I'd also like to suggest separating Mozilla and Microsoft-originating certdata in the repository and only mixing them together as part of the build process, if need be. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20220819.n.0 changes
OLD: Fedora-Rawhide-20220817.n.1 NEW: Fedora-Rawhide-20220819.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 2 Dropped packages:2 Upgraded packages: 145 Downgraded packages: 0 Size of added packages: 105.22 MiB Size of dropped packages:1.55 MiB Size of upgraded packages: 7.17 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 41.27 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: nextcloud-24.0.3-1.module_f38+15035+8d60dfda Summary: Private file sync and share server RPMs:nextcloud nextcloud-httpd nextcloud-mysql nextcloud-nginx nextcloud-postgresql nextcloud-sqlite Size:105.18 MiB Package: rust-inflate-0.4.5-13.fc38 Summary: DEFLATE decoding RPMs:rust-inflate+default-devel rust-inflate+unstable-devel rust-inflate-devel Size:40.21 KiB = DROPPED PACKAGES = Package: evolution-rss-1:0.3.96-9.fc36 Summary: Evolution RSS Reader RPMs:evolution-rss Size:1.39 MiB Package: libnss-pgsql-1.5.0-0.29.beta.fc37 Summary: Name Service Switch library that interface with PostgreSQL RPMs:libnss-pgsql Size:170.22 KiB = UPGRADED PACKAGES = Package: Mars-4.5-20.fc38 Old package: Mars-4.5-19.fc37 Summary: An interactive development environment for programming in MIPS assembly language RPMs: Mars Size: 3.11 MiB Size change: -42 B Changelog: * Thu Aug 18 2022 W. Michael PEtullo - 4.5-20 - Build using Java 17 Package: ansible-collection-community-rabbitmq-1.2.2-1.fc38 Old package: ansible-collection-community-rabbitmq-1.2.1-2.fc37 Summary: RabbitMQ collection for Ansible RPMs: ansible-collection-community-rabbitmq Size: 61.93 KiB Size change: -4.31 KiB Changelog: * Thu Aug 18 2022 Maxwell G - 1.2.2-1 - Update to 1.2.2. Fixes rhbz#2106951. - Adopt new Fedora licensing guidelines - Run unit tests Package: bindfs-1.17.0-1.fc38 Old package: bindfs-1.15.1-4.fc37 Summary: Fuse filesystem to mirror a directory RPMs: bindfs Size: 204.26 KiB Size change: 2.16 KiB Changelog: * Fri Aug 19 2022 Filipe Rosset - 1.17.0-1 - Update to 1.17.0 fixes rhbz#2098359 Package: clisp-2.49.93-27.20210628gitde01f0f.fc38 Old package: clisp-2.49.93-26.20210628gitde01f0f.fc38 Summary: ANSI Common Lisp implementation RPMs: clisp clisp-devel Size: 44.29 MiB Size change: -20.71 KiB Changelog: * Mon Aug 15 2022 Jerry James - 2.49.93-26 - Convert License tag to SPDX * Thu Aug 18 2022 Jerry James - 2.49.93-27 - Rebuild for libsvm 3.3 Package: cmake-3.24.1-1.fc38 Old package: cmake-3.24.0-1.fc38 Summary: Cross-platform make system RPMs: cmake cmake-data cmake-doc cmake-filesystem cmake-gui cmake-rpm-macros Size: 47.01 MiB Size change: 35.12 KiB Changelog: * Thu Aug 18 2022 Bj??rn Esser - 3.24.1-1 - cmake-3.24.1 Package: codespell-2.2.1-1.fc38 Old package: codespell-2.2.0-1.fc38 Summary: Fix common misspellings in text files RPMs: codespell Size: 200.34 KiB Size change: 71 B Changelog: * Thu Aug 18 2022 Bastien Nocera - 2.2.1-1 + codespell-2.2.1-1 - Update to 2.2.1 Package: converseen-0.9.9.6-1.fc38 Old package: converseen-0.9.9.5-2.fc37 Summary: A batch image conversion tool written in C++ with Qt5 and Magick++ RPMs: converseen Size: 1.23 MiB Size change: 5.79 KiB Changelog: * Fri Aug 19 2022 Filipe Rosset - 0.9.9.6-1 - Update to 0.9.9.6 fixes rhbz#2103519 Package: copr-backend-1.159-1.fc38 Old package: copr-backend-1.157-1.fc37 Summary: Backend for Copr RPMs: copr-backend copr-backend-doc Size: 420.43 KiB Size change: 693 B Changelog: * Tue Aug 16 2022 Jiri Kyjovsky 1.158-1 - log every request that is sent to frontend * Tue Aug 16 2022 Pavel Raiskup 1.159-1 - count only hits from an appropriate CDN hostname - add option for infinite number of attempts to the hitcounter script - print more reasonable output from AWS hitcounter script Package: copr-cli-1.103-1.fc38 Old package: copr-cli-1.102-1.fc37 Summary: Command line interface for COPR RPMs: copr-cli Size: 93.61 KiB Size change: -207 B Changelog: * Tue Aug 16 2022 Jiri Kyjovsky 1.103-1 - add packit_forge_projects_allowed for Copr projects Package: copr-dist-git-0.57-1.fc38 Old package: copr-dist-git-0.56-1.fc37 Summary: Copr services for Dist Git server RPMs: copr-dist-git Size: 57.71 KiB Size change: 77 B Changelog: * Tue Aug 16 2022 Jiri Kyjovsky 0.57-1 - log the URL that got us new tasks Package: cyrus-sasl-2.1.28-8.fc38 Old package: cyrus-sasl-2.1.28-7.fc37 Summary: The Cyrus SASL library RPMs: cyrus-sasl cyrus-sasl-devel cyrus-sasl-gs2 cyrus-sasl-gssapi cyrus-sasl-ldap cyrus-sasl-lib cyrus-sasl-md5
Re: Inactive packagers to be removed after the F37 release
On Fri, Aug 19, 2022 at 1:08 PM Ben Cotton wrote: > On Fri, Aug 19, 2022 at 2:46 AM Merlin Cooper > wrote: > > > > I like this policy, but it strikes me as odd that the packagers' email > > addresses are posted publicly on the Pagure tickets... Wouldn't that > > make it easier for spammers to get more email addresses? > > The script has a flag I can use in the future which (I believe) will > mask the addresses in the tickets. I didn't use it this time because > email addresses are already displayed all over the place. If a spammer > gets an email address from these tickets that they didn't have before, > then I'll be very surprised. > I really wish people would stop making the argument that just because other places/systems have terrible data hygiene, we can have terrible data hygiene too. Fedora should be trying to set the example of how to interact and behave, and the "follow the herd" mentality here is not acceptable in my opinion. Email address could be considered PII, and so there is a debate about when the GDPR-type regulations would apply to them (from what I read, it would apply for work email addresses giving full names or personal email addresses). While there is a legal basis for keeping the email address in the system and using it, I fail to see a legal basis that would allow publicly displaying an email address in this way. Many systems are also trying to reduce the exposure of personal email addresses, with major git hosting providers even creating anonymous commit emails that can be associated with user accounts on those systems and then used for your commits should you choose. So in short, I strongly argue for masking/removing the email address from all tickets like this, and the fact that they are displayed there was is so concerning to me that I opened a ticket about it last night: https://pagure.io/find-inactive-packagers/issue/619. -Ian > > That said, if there's a general consensus that addresses should be > masked in the ticket, then we can do that in the future. I considered > whether the tickets should default to private, but the downside is > that people wouldn't be able to log in and comment on the ticket via > the Pagure web interface, only by email. > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
CPE Weekly Update – Week 33 2022
Hi everyone, This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat (https://libera.chat/). Week: 15th August - 19th August 2022 If you wish to read this in form of a blog post, check the post on Fedora community blog: https://communityblog.fedoraproject.org/cpe-weekly-update---week-33-2022/ # Highlights of the week ## Infrastructure & Release Engineering Goal of this Initiative --- Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on. Link to planning board: https://zlopez.fedorapeople.org/I Link to docs: https://docs.fedoraproject.org/en-US/infra/ Update -- ### Fedora Infra * Mass update/reboot cycle this week (stg/nonoutage done, outage later today) * Freeze for f37 beta starts next week ### CentOS Infra including CentOS CI * Discussion around the CentOS Stream infra hand over * New tasks for the CI infra migration * S3 bucket for the Stream CoreOS effort * Some infra projects moved from gitea to gitlab ### Release Engineering * Openh264 composes fo f36,37,38 send to cisco * Package retirement issues after the branching, thanks to human error ## CentOS Stream Goal of this Initiative --- This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream. Updates --- * Face to face meeting in Boston. * Penultimate parts of Module process sync. Between el8 and el9. ## EPEL Goal of this initiative --- Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more. Updates --- * EPEL9 is up to 7339 (+106) packages from 3278 (+71) source packages * Found the bloaty package was uninstallable because of a libre2 soname fix, rebuilding it fixed the issue. ## FMN replacement Goal of this initiative --- FMN (Fedora-Messaging-Notification) is a web application allowing users to create filters on messages sent to (currently) fedmsg and forward these as notifications on to email or IRC. The goal of the initiative is mainly to add fedora-messaging schemas, create a new UI for a better user experience and create a new service to triage incoming messages to reduce the current message delivery lag problem. Community will profit from speedier notifications based on own preferences (IRC, Matrix, Email), unified fedora project to one message service and human-readable results in Datagrepper. Also, CPE tech debt will be significantly reduced by dropping the maintenance of fedmsg altogether. Updates --- * Frontend * Use CoreUI components * Set up i18n * Initial version of a “New Rule” page * Authentication integration FE/BE (ongoing) * Backend: SQLAlchemy integration (ongoing)) Kindest regards, CPE Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora 37 compose report: 20220819.n.0 changes
OLD: Fedora-37-20220818.n.0 NEW: Fedora-37-20220819.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 0 Dropped packages:9 Upgraded packages: 113 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:97.02 MiB Size of upgraded packages: 5.01 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 40.22 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-37-20220819.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = Package: flatpak-rpm-macros-37-1.module_f37+15012+d91ecd81 Summary: Macros for building RPMS for flatpaks RPMs:flatpak-rpm-macros Size:43.55 KiB Package: flatpak-runtime-config-37-1.module_f37+15012+d91ecd81 Summary: Configuration files that live inside the flatpak runtime RPMs:flatpak-runtime-config Size:46.51 KiB Package: libnss-pgsql-1.5.0-0.29.beta.fc37 Summary: Name Service Switch library that interface with PostgreSQL RPMs:libnss-pgsql Size:170.22 KiB Package: postgresql-10.20-1.module_f37+14079+af0f42b7 Summary: PostgreSQL client programs RPMs:postgresql postgresql-contrib postgresql-docs postgresql-plperl postgresql-plpython postgresql-plpython3 postgresql-pltcl postgresql-server postgresql-server-devel postgresql-static postgresql-test postgresql-test-rpm-macros postgresql-upgrade postgresql-upgrade-devel Size:96.38 MiB Package: rust-cap-async-std-0.24.2-2.fc37 Summary: Capability-based version of async-std RPMs:rust-cap-async-std+arf-strings-devel rust-cap-async-std+arf_strings-devel rust-cap-async-std+camino-devel rust-cap-async-std+default-devel rust-cap-async-std+fs_utf8-devel rust-cap-async-std-devel Size:78.46 KiB Package: rust-cap-fs-ext-0.24.2-2.fc37 Summary: Extension traits for Dir, File, etc RPMs:rust-cap-fs-ext+arf-strings-devel rust-cap-fs-ext+arf_strings-devel rust-cap-fs-ext+async-std-devel rust-cap-fs-ext+async-trait-devel rust-cap-fs-ext+async_std-devel rust-cap-fs-ext+async_std_arf_strings-devel rust-cap-fs-ext+async_std_fs_utf8-devel rust-cap-fs-ext+camino-devel rust-cap-fs-ext+cap-async-std-devel rust-cap-fs-ext+cap-std-devel rust-cap-fs-ext+default-devel rust-cap-fs-ext+fs_utf8-devel rust-cap-fs-ext+std-devel rust-cap-fs-ext-devel Size:120.82 KiB Package: rust-cap-rand-0.24.2-2.fc37 Summary: Capability-based random number generators RPMs:rust-cap-rand+default-devel rust-cap-rand+small_rng-devel rust-cap-rand-devel Size:32.59 KiB Package: rust-cap-time-ext-0.24.2-2.fc37 Summary: Extension traits for SystemClock and MonotonicClock RPMs:rust-cap-time-ext+cap-std-devel rust-cap-time-ext+default-devel rust-cap-time-ext-devel Size:31.48 KiB Package: rust-system-interface-0.20.0-2.fc37 Summary: Extensions to the Rust standard library RPMs:rust-system-interface+async-std-devel rust-system-interface+cap-async-std-devel rust-system-interface+cap-std-devel rust-system-interface+cap_async_std_impls-devel rust-system-interface+cap_async_std_impls_fs_utf8-devel rust-system-interface+cap_std_impls-devel rust-system-interface+cap_std_impls_fs_utf8-devel rust-system-interface+default-devel rust-system-interface+os_pipe-devel rust-system-interface+socket2-devel rust-system-interface+use_os_pipe-devel rust-system-interface+use_socket2-devel rust-system-interface-devel Size:133.69 KiB = UPGRADED PACKAGES = Package: ansible-collection-community-rabbitmq-1.2.2-1.fc37 Old package: ansible-collection-community-rabbitmq-1.2.1-2.fc37 Summary: RabbitMQ collection for Ansible RPMs: ansible-collection-community-rabbitmq Size: 61.84 KiB Size change: -4.39 KiB Changelog: * Thu Aug 18 2022 Maxwell G - 1.2.2-1 - Update to 1.2.2. Fixes rhbz#2106951. - Adopt new Fedora licensing guidelines - Run unit tests Package: ansible-packaging-1-7.fc37 Old package: ansible-packaging-1-6.fc37 Summary: RPM packaging macros and generators for Ansible collections RPMs: ansible-packaging ansible-packaging-tests ansible-srpm-macros Added RPMs: ansible-packaging-tests Size: 35.88 KiB Size change: 7.60 KiB Changelog: * Mon Aug 01 2022 Maxwell G - 1-7 - Implement %ansible_test_unit and add ansible-packaging-tests metapackage. - Require ansible-core at buildtime Package: bindfs-1.17.0-1.fc37 Old package: bindfs-1.15.1-4.fc37 Summary: Fuse filesystem to mirror a directory RPMs: bindfs Size: 204.28 KiB Size change: 2.18 KiB Changelog: * Fri Aug 19 2022 Filipe Rosset - 1.17.0-1 - Update to 1.17.0 fixes rhbz#2098359 Package: cmake-3.24.1-1.fc37 Old package: cmake-3.24.0-1.fc37 Summary: Cross-platform make system RPMs: cmake cmake-data cmake-doc cmake-filesystem cmake-gui cmake-rpm-macros Size: 46.98 MiB Size change: 4.53
Re: Inactive packagers to be removed after the F37 release
On Fri, Aug 19, 2022 at 2:46 AM Merlin Cooper wrote: > > I like this policy, but it strikes me as odd that the packagers' email > addresses are posted publicly on the Pagure tickets... Wouldn't that > make it easier for spammers to get more email addresses? The script has a flag I can use in the future which (I believe) will mask the addresses in the tickets. I didn't use it this time because email addresses are already displayed all over the place. If a spammer gets an email address from these tickets that they didn't have before, then I'll be very surprised. That said, if there's a general consensus that addresses should be masked in the ticket, then we can do that in the future. I considered whether the tickets should default to private, but the downside is that people wouldn't be able to log in and comment on the ticket via the Pagure web interface, only by email. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Fri, Aug 19, 2022 at 1:18 AM Adam Williamson wrote: > > Can we handle that? Can you manually flag those cases to continue > through the process, or something? It's like 10,000 spoons, when all you need is removal from the packager group. But yes, I'm manually handling those cases. Right now, it's by putting them on a list of "people who will show up as active but have acked removal". I have plans for how that can be handled in the future without me keeping a separate list on my Todoist task. But for now I am (slowly) going through every comment on tickets to make sure that everything gets handled correctly. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2119302] Upgrade perl-Type-Tiny to 1.016008
https://bugzilla.redhat.com/show_bug.cgi?id=2119302 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Fixed In Version||perl-Type-Tiny-1.016008-1.f ||c38 ||perl-Type-Tiny-1.016008-1.f ||c37 Last Closed||2022-08-19 11:16:35 --- Comment #1 from Jitka Plesnikova --- Built by corsepiu -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2119302 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2105085] CVE-2022-31081 perl-HTTP-Daemon: HTTP::Daemon allows request smuggling
https://bugzilla.redhat.com/show_bug.cgi?id=2105085 --- Comment #11 from Michal Josef Spacek --- Upstream has not released a new version of distribution with fixes, because there are some failing tests related to the issue. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2105085 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
Hi, On Friday, 19 August, 2022, 03:05:03 am IST, Ben Cotton wrote: >I just completed the first run of FESCo's newly approved Inactive >Packager Policy[1]. Packagers that have been identified as inactive >have a ticket in the find-inactive-packagers repo[2]. One week after >the F37 final release, packagers who remain inactive will be removed >from the packager group. > >For the curious, here are the stats from today's run: > >2550 users checked >913 of those had no activity on src.fedoraproject.org or pagure.io >835 of those had no activity in Bodhi >812 of those had no activity on the mailing lists >606 of those (~24% of packagers) had no activity in Bugzilla. > * Interesting numbers there. * While I get that such pruning from time to time is generally good. What happens to the packages orphaned by removing inactive packagers? * Removing orphaned packages may not be easy, as other packages may depend on them. Thank you. --- -P J P http://feedmug.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: nspawn for rawhide?
* Kevin Fenzi: > Greetings everyone. > > Many years ago mock introduced and then made default it's isolation to > use systemd-nspawn instead of chroot. Shortly after the nspawn isolation > was added, it was used in fedoraproject koji builds, but there were > issues and since then the fedoraproject koji has defaulted to using > chroot isolation. > > Releng has had a ticket open for a long time to switch > ( https://pagure.io/releng/issue/6967 ) > > I think the two items listed there (kernel bind mounts and loop devices) > have long since been fixed, so I would like to propose we switch rawhide > to using nspawn and see if any other issues show up. What's the version of nspawn that will be used here? Presumably it's not the rawhide version, but the host version? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2096953] perl-HTTP-Message-6.37 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2096953 Michal Josef Spacek changed: What|Removed |Added Fixed In Version||perl-HTTP-Message-6.37-1.fc ||38 Status|ASSIGNED|CLOSED Resolution|--- |RAWHIDE Last Closed||2022-08-19 09:37:36 --- Comment #2 from Michal Josef Spacek --- After creating of f37 branch were build f37 and rawhide builds: perl-HTTP-Message-6.37-1.fc37 perl-HTTP-Message-6.37-1.fc38 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2096953 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: qarte: missing python dependencies ?
Thanks for your hint. The developer of the program released a patch for this a few minutes ago. https://bazaar.launchpad.net/~vincent-vandevyvre/qarte/qarte-5/diff/82?context=3 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: qarte: missing python dependencies ?
> Hi,
>
> I want to start qarte-5.1 on Fedora 37, but the startup aborts
> with the following error message:
>
> $ qarte -d
> 16:06:00: INFO - qarte Qarte-5.1.0
> 16:06:00: INFO - qarte Python 3.11.0rc1 on
> Linux-5.19.1-300.fc37.x86_64-x86_64-with-glibc2.36
> 16:06:00: INFO - qarte File system encoding: utf-8
> 16:06:00: INFO - qarte System encoding: utf-8
> /usr/bin/qarte:71: DeprecationWarning: Use setlocale(), getencoding() and
> getlocale()
> instead
> logger.info("Locale encoding: {0}".format(locale.getdefaultlocale()))
> 16:06:00: INFO - qarte Locale encoding: ('de_DE', 'UTF-8')
> QSocketNotifier: Can only be used with threads started with QThread
> Traceback (most recent call last):
> File "/usr/bin/qarte", line 118, in
> from core import Core
> File "/usr/share/qarte/core.py", line 23, in
> gettext.install('qarte', LOC_PATH, True)
> TypeError: install() takes from 1 to 2 positional arguments but 3 were given
This tells you that the quarte code calls gettext's install function with too
many (non-kw) arguments. Indeed:
"Changed in version 3.11: names is now a keyword-only parameter."
(https://docs.python.org/3.11/library/gettext.html#gettext.install)
> how can i solve this ?
>
> [1] https://martinkg.fedorapeople.org/Packages/test/qarte-5.1.0-1.fc37.src.rpm
> [2]
> https://martinkg.fedorapeople.org/Packages/test/python-m3u8-3.1.0-2.fc37
I found no upstream repo or such (and did not go through unpacking the srpm).
Maybe they are aware of this.
In the line above, `names=True` may solve the problem, but from the doc I don't
even think that True is a valid choice here. They may have missed the removal
of the `codeset` parameter which used to be in slot 3 before 3.10.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
qarte: missing python dependencies ?
Hi,
I want to start qarte-5.1 on Fedora 37, but the startup aborts
with the following error message:
$ qarte -d
16:06:00: INFO - qarte Qarte-5.1.0
16:06:00: INFO - qarte Python 3.11.0rc1 on
Linux-5.19.1-300.fc37.x86_64-x86_64-with-glibc2.36
16:06:00: INFO - qarte File system encoding: utf-8
16:06:00: INFO - qarte System encoding: utf-8
/usr/bin/qarte:71: DeprecationWarning: Use setlocale(), getencoding() and
getlocale() instead
logger.info("Locale encoding: {0}".format(locale.getdefaultlocale()))
16:06:00: INFO - qarte Locale encoding: ('de_DE', 'UTF-8')
QSocketNotifier: Can only be used with threads started with QThread
Traceback (most recent call last):
File "/usr/bin/qarte", line 118, in
from core import Core
File "/usr/share/qarte/core.py", line 23, in
gettext.install('qarte', LOC_PATH, True)
TypeError: install() takes from 1 to 2 positional arguments but 3 were given
how can i solve this ?
[1] https://martinkg.fedorapeople.org/Packages/test/qarte-5.1.0-1.fc37.src.rpm
[2]
https://martinkg.fedorapeople.org/Packages/test/python-m3u8-3.1.0-2.fc37.src.rpm
Regards
Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On 19/08/2022 08:45, Merlin Cooper wrote: I like this policy, but it strikes me as odd that the packagers' email addresses are posted publicly on the Pagure tickets... Wouldn't that make it easier for spammers to get more email addresses? Spammers can easily get email addresses from all Git commits. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
I like this policy, but it strikes me as odd that the packagers' email addresses are posted publicly on the Pagure tickets... Wouldn't that make it easier for spammers to get more email addresses? On Thu, 2022-08-18 at 17:28 -0400, Ben Cotton wrote: > Hello everyone! > > I just completed the first run of FESCo's newly approved Inactive > Packager Policy[1]. Packagers that have been identified as inactive > have a ticket in the find-inactive-packagers repo[2]. One week after > the F37 final release, packagers who remain inactive will be removed > from the packager group. (Note that pagure.io is one of the systems > checked for activity, so commenting on your ticket that you're still > around will prevent you from showing up in the second round.) > > Since this is the first time we've done something like this, it could > be a little rough. I appreciate your patience and understanding. If > you have suggestions for improvement, look for the open feature > issues[3] and file an issue in the find-inactive-packagers repo[4] if > it's not there already. > > For the curious, here are the stats from today's run: > > 2550 users checked > 913 of those had no activity on src.fedoraproject.org or pagure.io > 835 of those had no activity in Bodhi > 812 of those had no activity on the mailing lists > 606 of those (~24% of packagers) had no activity in Bugzilla. > > The script took a little under three hours to run. > > [1] > https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ > [2] > https://pagure.io/find-inactive-packagers/issues?tags=inactive_packager=Open > [3] https://pagure.io/find-inactive-packagers/issues?tags=feature > [4] https://pagure.io/find-inactive-packagers/new_issue > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to > devel-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/devel-annou...@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2116641] perl-MIME-Charset-1.013.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2116641 Petr Pisar changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Version|rawhide |37 CC||ppi...@redhat.com --- Comment #6 from Petr Pisar --- This fixes a test failure in perl-MIME-Charset-1.012.2-18.fc38: t/03ooinfo.t ok # Failed test 'ISO-8859-8-I' # at t/04alias.t line 31. # got: 'ISO-8859-8' # expected: 'ISO-8859-8-I' # UTF-16 is decoded by 'x-utf16auto' encoding # UTF-32 is decoded by 'x-utf32auto' encoding # HZ-GB-2312 is decoded by 'hz' encoding # TIS-620 is decoded by 'cp874' encoding # Looks like you failed 1 test of 33. t/04alias.t . Dubious, test returned 1 (wstat 256, 0x100) Failed 1/33 subtests triggered by a change in Encode-3.19: 1.013_01 2022-08-08 Hatuka*nezumi - IKEDA Soji * Imp: Added support for DIN 66003. * Chg: Workaround: "ISO-8859-8-I" is treated as an alias of "ISO-8859-8" by Encode (3.18): See the note in https://encoding.spec.whatwg.org/#legacy-single-byte-encodings However we'll treat these as separate names for compatibility. Please upgrade this package in Fedora ≥ 37. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2116641 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
Il 19/08/22 07:17, Adam Williamson ha scritto: > On Thu, 2022-08-18 at 17:28 -0400, Ben Cotton wrote: >> Hello everyone! >> >> I just completed the first run of FESCo's newly approved Inactive >> Packager Policy[1]. Packagers that have been identified as inactive >> have a ticket in the find-inactive-packagers repo[2]. One week after >> the F37 final release, packagers who remain inactive will be removed >> from the packager group. (Note that pagure.io is one of the systems >> checked for activity, so commenting on your ticket that you're still >> around will prevent you from showing up in the second round.) > So on this point specifically - I had a look through the tickets for > interest, and saw two cases where people replied to the ticket to say > essentially "yes, it's fine to take away my packager rights". Which, > ironically, would prevent it from happening, it seems. > > Can we handle that? Can you manually flag those cases to continue > through the process, or something? Unfortunately, with the script in the current status **ALL** tickets need to be handled manually. This kind of reply from a user is what it made me choose to not handle opened tickets automatically when I initially wrote the script. I know this will going to be painful in this first run, but in following runs I'd expect only a bunch of tickets to be created. It can however be enhanced, maybe we can add a specific tag "requested_removal" so that the script knows how to handle them (in a future version). But it will always need a manual intervention to add the tag to the ticket. Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
