Re: Updating xorg-x11-server
On Sun, Sep 29, 2024 at 06:03:01PM GMT, Peter Robinson wrote: > On Sun, 29 Sept 2024 at 17:21, Kevin Fenzi wrote: > > > > On Thu, Sep 19, 2024 at 02:33:21PM GMT, Simone Caronni wrote: > > > > xorg-x11-server is ready, I just fixed last issue which was with > > > > Nouveau drive > > > > > > > > https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/merge_requests/10 > > > > > > > > > As mentioned in the thread, I'll proceed. Thanks. > > > > Just FYI, this appears to have broken the exising xorg-x11-drv-armsoc > > build, causing rawhide composes to fail the last few days. :) > > > > I just did a simple rebuild to get rawhide composes working again, but I > > have no way of testing that hardware off hand, so more work may be > > needed there. > > I've retired it, TBH I thought I had some time ago, there's now > official MALI support in kernel/mesa and that should work now on all > the HW we care about. Great! Thanks. 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: Updating xorg-x11-server
On Thu, Sep 19, 2024 at 02:33:21PM GMT, Simone Caronni wrote: > > xorg-x11-server is ready, I just fixed last issue which was with > > Nouveau drive > > > > https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/merge_requests/10 > > > As mentioned in the thread, I'll proceed. Thanks. Just FYI, this appears to have broken the exising xorg-x11-drv-armsoc build, causing rawhide composes to fail the last few days. :) I just did a simple rebuild to get rawhide composes working again, but I have no way of testing that hardware off hand, so more work may be needed there. https://bodhi.fedoraproject.org/updates/FEDORA-2024-b6943b25c5 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
[Canceled] Schedule for Tuesday's FESCo Meeting (2024-09-24)
The only topic pending tomorrow's FESCo meeting is the issue "#3271 [F41 blocker] Ensure that all packages with dead.package are removed from repos" and they are already all blocked. Since that was the only issue, the FESCo meeting Tuesday at 17:00 UTC in #meeting:fedoraproject.org is canceled. I can't chair the next meeting on Tuesday, October 1st, so if another FESCo member could take that on, that would be great. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-09-24 17:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = None = Followups = None = New business = #3269 [F41 blocker] Ensure that all packages with dead.package are removed from the repos https://pagure.io/fesco/issue/3271 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. 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: Location of available packages and versions for EPEL 10?
On Thu, Sep 19, 2024 at 03:31:54PM GMT, Ron Olson wrote: > Hey all- > > Dunno if there’s a better place to ask, epel-de...@lists.fedoraproject.org perhaps? > but as part of trying to build Swift for EPEL 10 I’ve been running into some > old issues that were resolved because of later versions of other packages > (e.g. clang, python); is there somewhere a place that I can find what is > available in EPEL 10 and what version they are. Any of the normal means should work for epel packages: https://packages.fedoraproject.org As others noted stream should have a lot of the base packages, so you should be able to look there with mock or the like. Also, if you are doing scratch builds in fedoraproject koji you can look at the root.log there and see the exact versions in the buildroot it used. 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: Cannot upload package source
On Fri, Sep 20, 2024 at 04:47:01PM GMT, Felix Wang wrote: > I want to upload package source on Fedora rawhide today with fedpkg > new-sources, it showed, Network error: (66, 'Failed to find SSL backend for > endpoint'). I have seen an comment from > https://pagure.io/fedora-infrastructure/issue/12182#comment-932050, and > restarted the computer to load the freshly updated packages, but it still > existed. The comment of > https://pagure.io/fedora-infrastructure/issue/12182#comment-932271 said he > downgraded curl 8.10.0 to 8.2.1 and it worked. Any suggestions? thanks in > advance. > > ``` > ❯ fedpkg new-sources /home/ruby/rpmbuild/SOURCES/nanopb-0.4.9.tar.gz > Uploading: /home/ruby/rpmbuild/SOURCES/nanopb-0.4.9.tar.gz to > https://src.fedoraproject.org/repo/pkgs/upload.cgi > Network error: (66, 'Failed to find SSL backend for endpoint') > The operation will be retried in 15s. I've seen several other reports of this... it might be https://github.com/curl/curl/issues/14973 Did downgrading curl work for you? 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
[Canceled] Schedule for Tuesday's FESCo Meeting (2024-09-17)
The only topic pending tomorrow's FESCo meeting is the issue "Re-evaluate ban on pre-compiled CSS", but we will give another week for more discussion of it. Since that was the only issue, the FESCo meeting Tuesday at 17:00 UTC in #meeting:fedoraproject.org is canceled. I will chair the next meeting on Tuesday, September 24th. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-09-17 17:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = None = Followups = None = New business = #3269 Re-evaluate ban on pre-compiled CSS https://pagure.io/fesco/issue/3269 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. 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: Summary/Minutes from today's FESCo Meeting (2024-09-10)
Josh Boyer wrote: > Yes, but people could just use HTML mail as well. I'm far too lazy to > deal with multiple syncs across devices and phones, and other online > clients suffer from the same problems. Huh? Is it not the point of IMAP that everything happens on the server, there is nothing to sync (just as when using webmail)? Assuming of course that you use online IMAP, but if you are using the GMail website, that is online-only as well. 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
Re: Email when build completes
On Sat, Sep 14, 2024 at 09:19:42AM GMT, Sandro wrote: > On 13-09-2024 18:26, Ron Olson wrote: > > Thanks Gary, is there any documentation on how the rules work? I _think_ > > I created the appropriate rule but I haven’t received any notification > > and it’s likely I just did it wrong. > > I have set "Tracking Rule" to "My Events" with "Applications" set to "Koji". > There are probably other options like "Artifacts by user". But that rule > definition works for me. > > However, yesterday afternoon (UTC+2), I noticed quite some delay in the > messages being delivered. Some arrived only an hour after the build job was > actually finished. So, there's that as well. yeah, we were tagging the beta in and it emitted a... large number of messages (one per build tagged). ;( 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: Fedora CI - installability gone wild, cannot dnf install base packages
On Sat, Sep 14, 2024 at 08:39:26AM GMT, Adam Williamson wrote: > On Sat, 2024-09-14 at 03:33 +, Chen Chen wrote: > > I just made a PR on https://src.fedoraproject.org/rpms/glfw/pull-request/6 > > Then the installability test failed because it got a 403 on "dnf install > > createrepo_c". > > https://artifacts.dev.testing-farm.io/ef6b74c1-7335-499c-a15a-c367b6dfa25a/ > > > > Checked that the package indeed lives in el8 > > > [root@sirius ~]# dnf info createrepo_c-libs > > > Last metadata expiration check: 2:04:56 ago on Sat 14 Sep 2024 09:11:34 > > > AM CST. > > > Available Packages > > > Name : createrepo_c-libs > > > Version : 0.17.7 > > > Release : 6.el8 > > > Architecture : x86_64 > > > Size : 115 k > > > Source : createrepo_c-0.17.7-6.el8.src.rpm > > > Repository : appstream > > > Summary : Library for repodata manipulation > > > URL : https://github.com/rpm-software-management/createrepo_c > > > License : GPLv2+ > > > Description : Libraries for applications using the createrepo_c library > > > : for easy manipulation with a repodata. > > > > and the URL from the log is not accessible from public Internet > > > wget > > > https://composes.stream.centos.org/stream-8/production/latest-CentOS-Stream/compose/AppStream/x86_64/os/Packages/createrepo_c-0.17.7-6.el8.x86_64.rpm > > > Connecting to composes.stream.centos.org > > > (composes.stream.centos.org)|2600:9000:271a:a800:16:bca0:9700:93a1|:443... > > > connected. > > > HTTP request sent, awaiting response... 403 Forbidden > > > 2024-09-14 11:23:04 ERROR 403: Forbidden. > > > > How can I trigger another CI run and whom should I report this problem to? > > testing-farm.io or CI group guys? > > The problem is not in CI, it's in CentOS infra - that URL ought to work > fine but is currently 403. I've filed a ticket at > https://pagure.io/centos-infra/issue/1495 , hopefully that will get it > resolved. Well, CentOS stream 8 is EOL and no longer around. I suspect that the ci pipeline just needs to switch to rhel 8 in this case... 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: Orphaning python-nss
On Tue, Sep 10, 2024 at 06:45:38PM GMT, David Shea wrote: > I tried raising this one from the dead last year, but changes in > crypto-policy have made the use cases I cared about difficult-to-impossible, > and I am no longer interested in maintaining this package. Upstream moved on > from this project some time ago[1], so anyone taking over the package would > need to effectively become the upstream as well. Sadly this affects sigul (our signing server). Will look into options... thanks for maintaining it as long as you have! 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: Something wrong with rawhide (41) keys?
On Fri, Sep 06, 2024 at 03:49:45PM GMT, Gabriel L. Somlo wrote: > $ rpm -q mock mock-core-configs distribution-gpg-keys > mock-5.6-1.fc40.noarch > mock-core-configs-40.6-1.fc40.noarch > distribution-gpg-keys-1.104-1.fc40.noarch > > The weird thing is that doing `dnf clean all; dnf update` right around > the time I sent out my first email asking about this got me *nothing*. > > Repeating `dnf update` right now, after checking package versions, did > get me updated packages for > mock-core-configs-41.2-1.fc40.noarch > and > distribution-gpg-keys-1.105-1.fc40.noarch > > So my guess was partially correct, updated versions for these things > were in the process of "percolating" through whatever mirrors dnf > managed to reach when I checked earlier, and I was simply trying to > run my mock build at the wrong time. Odd. I think those went to stable updates about 3 weeks ago... https://bodhi.fedoraproject.org/updates/FEDORA-2024-4a6de3d12d https://bodhi.fedoraproject.org/updates/FEDORA-2024-49a775adbe > Thanks for the handholding, and sorry for the noise :) Glad you got it working... 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: (fedora) Re: Proposed CHOST change for the 64bit time_t transition
On Fri, Sep 06, 2024 at 11:03:49AM GMT, Stephen Gallagher wrote: > On Fri, Sep 6, 2024 at 8:06 AM Dridi Boukelmoune > wrote: > > > > On Fri, Sep 6, 2024 at 10:21 AM Andreas K. Huettel > > wrote: > > > > > > Seems like the fedora list moderators decided to not let the follow-ups > > > pass to the fedora-dev list, > > > so please if you're interested follow the discussion on one of the other > > > involved mailing lists. > > > I'm fairly sure this is also relevant here. > > > > There are other threads on this mailing list mentioning mailman > > problems when cross-posting to multiple lists. > > > > Probably not a moderator intervention. > > > > > E.g., see for the thread > > > https://sourceware.org/pipermail/libc-alpha/2024-September/159610.html > > > Correct, many of the responses were only being sent to one of the > other mailing lists CCed in the original email as well. Yeah, the reason those all hit moderation is because they were going to more than 10 addresses. mailman3 flags that as possible cross post spam. ;( So, I acked the first one, but then... the only other ones hitting this list seemed to be from the OP, replying to others on other lists that were not cc'ed, so the conversation was... not very clear. > My recommendation is that the original mailing be treated as a notice > for all the distros to start talking, but one SINGLE mailing list be > designated for continuing the conversation. The upstream libc-alpha > list seems like the best choice to me, as it's distro-agnostic and > directly relevant to the changes being proposed. Yeah. I think this is the only workable path. 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: [SPDX] packages that are "not valid neither as Callaway nor as SPDX"
On Fri, Sep 06, 2024 at 02:03:20PM GMT, Miroslav Suchý wrote:
> Dne 06. 09. 24 v 1:33 odp. Ben Beasley napsal(a):
> > Both python-graph-tool and python-llvmlite also use the %{shrink: …}
> > macro in their spec files. You’ve demonstrated how they can be validated
> > correctly by first allowing RPM to form the License expression in a
> > single line, rather than grepping the spec file directly.
>
> Yes. The same issue as Ben and Petr. Fixed now and will not be reported again.
Can you do a updated run so we can see how many are left after that
change?
Thanks!
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: Something wrong with rawhide (41) keys?
On Fri, Sep 06, 2024 at 01:59:16PM GMT, Gabriel L. Somlo wrote: > > Nope, running that returns no output. Any chance the f40 > mock-core-configs are still testing, or somehow behind the ones on f41 > or whatever everyone else who is *not* running into my issue is using? :D No, it should be in stable updates? what does: rpm -q mock mock-core-configs distribution-gpg-keys give? > Since this is turning out not to be obvious, maybe it would be better > done as a bugzilla ticket; I'll file one later tonight when I'm back in my > regular work environment... Sure, the mock maintainers are more likely to be able to track this down at this point. :( 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: Something wrong with rawhide (41) keys?
On Thu, Sep 05, 2024 at 11:41:59PM GMT, Adam Williamson wrote: > On Thu, 2024-09-05 at 20:48 -0400, Gabriel L. Somlo wrote: > > Hi Kevin, > > > > On Thu, Sep 05, 2024 at 2024 11:01:07 -0700, Kevin Fenzi wrote: > > > On Thu, Sep 05, 2024 at 07:03:05AM GMT, Gabriel L. Somlo wrote: > > > > As of right now (09/05/2024, 7:00am EDT), I'm getting an error when > > > > running `mock -r fedora-rawhide-x86_64 --clean --init` on an > > > > up-to-date f40 machine: > > > > > > > > ... > > > > > > You need to update to the latest mock-core-configs and > > > distribution-gpg-keys packages, then do a 'mock --scrub=all'. > > > > My mock-core-configs (well, all mock-* packages) and distribution-gpg-keys > > are all up to date (on f40). I removed /var/lib/mock/* AND ran > > `mock --scrub=all`, and still keep getting the same `transaction > > failed: Signature verification failed.` error as before when I attempt > > to build anything for `mock -r fedora-rawhide-x86_64 foo.src.rpm` > > > > > Basically we have branched f41 from rawhide, and rawhide is now moving > > > toward f42. So it's signed by a different key, but your mock/keys thinks > > > it's still f41 and may have old f41 cached packages it's trying to use? > > > > I figured that's what must have happened, but from where I'm sitting > > there are some lingering remaining side-effects that seem out of my > > control :) Any further ideas as to what might be happening much > > appreciated! > > When I ran into stuff like this around the dnf5 and container > transition, I just wiped every dir under /var/lib/mock and > /var/cache/mock , and it seemed to clear it up. Yeah, I am not sure what else it could be... unless you have locally modified the config anywhere? Does a 'rpm -V mock-core-configs' show any changes in the rawhide template? 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
fedmsg / python-fedmsg-meta-fedora-infrastructure orphaned
Hi. I've just orphaned fedmsg and python-fedmsg-meta-fedora-infrastructure packages. We only have one last app using fedmsg and it's being moved to fedora-messaging very soon. After thats done, we will likely set a sunset time for taking down our fedmsg bus. If any folks are using fedmsg for their own infra, feel free to take the packages, however, fedmsg fails to build in f41/rawhide so you should probibly look at/solve that before you take the packages on. https://bugzilla.redhat.com/show_bug.cgi?id=2300669 https://bugzilla.redhat.com/show_bug.cgi?id=2291518 https://bugzilla.redhat.com/show_bug.cgi?id=2272977 https://bugzilla.redhat.com/show_bug.cgi?id=2272977 https://bugzilla.redhat.com/show_bug.cgi?id=2301145 Thanks, 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: Something wrong with rawhide (41) keys?
On Thu, Sep 05, 2024 at 07:03:05AM GMT, Gabriel L. Somlo wrote: > As of right now (09/05/2024, 7:00am EDT), I'm getting an error when > running `mock -r fedora-rawhide-x86_64 --clean --init` on an > up-to-date f40 machine: > > ... > > [153/153] Total 100% | 0.0 B/s | 0.0 B | > 00m00s > Running transaction > Importing PGP key 0xE99D6AD1: > Userid : "Fedora (41) " > Fingerprint: 466CF2D8B60BC3057AA9453ED0622462E99D6AD1 > From : > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-41-primary > The key was successfully imported. > Importing PGP key 0xE99D6AD1: > Userid : "Fedora (41) " > Fingerprint: 466CF2D8B60BC3057AA9453ED0622462E99D6AD1 > From : > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-41-primary > The key was successfully imported. > Importing PGP key 0xA15B79CC: > Userid : "Fedora (40) " > Fingerprint: 115DF9AEF857853EE8445D0A0727707EA15B79CC > From : > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary > The key was successfully imported. > > Transaction failed: Signature verification failed. > PGP check for package "tar-2:1.35-4.fc41.x86_64" > (/var/lib/mock/fedora-rawhide-x86_64/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/tar-1.35-4.fc41.x86_64.rpm) > from repo "fedora" has failed: Import of the key didn't help, wrong key? > > Any ideas on what might be wrong, with either rawhide and/or what I'm > doing on my end? :) You need to update to the latest mock-core-configs and distribution-gpg-keys packages, then do a 'mock --scrub=all'. Basically we have branched f41 from rawhide, and rawhide is now moving toward f42. So it's signed by a different key, but your mock/keys thinks it's still f41 and may have old f41 cached packages it's trying to use? 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: Looking For a Sponsor
On Sun, Sep 01, 2024 at 08:05:31PM GMT, None via devel wrote: > Hello everyone, I would like to become a package maintainer and I have my > first review request here: > https://bugzilla.redhat.com/show_bug.cgi?id=2301387. I also have quite a few > more packages that I would like to maintain(either for Fedora or RPM Fusion), > I have some of them(not all) on my github: https://github.com/siliconwaffle. > Is anyone willing to help me out and sponsor me? Looks like Benson Muite is reviewing your first package. ;) might be worth submitting another package or two to show you know the guidelines, etc? 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: Questions regarding CPUs on aarch64 builders
NING]: guess_soc_from_uarch: No uarch matched the list [WARNING]: guess_soc_from_pci: No PCI device matched the list 3. We have 4 newer mt snow boxes: buildhw-a64-03/04/05/06 Vendor ID:ARM BIOS Vendor ID: Ampere(R) Model name: Neoverse-N1 BIOS Model name: Ampere(R) Altra(R) Processor Q80-30 CPU @ 3.0GHz BIOS CPU family: 257 Model:1 [WARNING]: SoC detection failed using /proc/cpuinfo: No string found [WARNING]: read_file: /sys/bus/nvmem/devices/rockchip-efuse0/nvmem: No such file or directory [WARNING]: read_file: /sys/bus/nvmem/devices/rockchip-otp0/nvmem: No such file or directory [WARNING]: guess_soc_from_uarch: No uarch matched the list [WARNING]: guess_soc_from_pci: No PCI device matched the list SoC: Unknown # ## # # ## ## Technology: Unknown ### ### ### ### Microarchitecture: Neoverse N1 ### ## ### ######## Max Frequency: 3.000 GHz ### ### ######## Cores: 80 cores ## ## ### ######## Features: NEON,SHA1,SHA2,AES,CRC32 Peak Performance:3.84 TFLOP/s 4. There's a bunch of buildvm-a64's on newer mt snow boxes: Vendor ID:ARM BIOS Vendor ID: QEMU Model name: Neoverse-N1 BIOS Model name: virt-rhel9.2.0 CPU @ 2.0GHz BIOS CPU family: 1 ... [WARNING]: Could not open '/sys/devices/system/cpu/cpu11/cpufreq/cpuinfo_max_freq' [WARNING]: Unable to fetch max frequency for core 11. This is probably because the core is offline [WARNING]: Could not open '/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq' [WARNING]: Unable to find max frequency from udev, measuring CPU frequency [WARNING]: Running frequency measurement with 725 iterations on core 0... cpufetch is measuring the max frequency...[WARNING]: SoC detection failed using /proc/cpuinfo: No string found [WARNING]: read_file: /sys/bus/nvmem/devices/rockchip-efuse0/nvmem: No such file or directory [WARNING]: read_file: /sys/bus/nvmem/devices/rockchip-otp0/nvmem: No such file or directory [WARNING]: guess_soc_from_uarch: No uarch matched the list [WARNING]: guess_soc_from_pci: No PCI device matched the list SoC: Unknown # ## # # ## ## Technology: Unknown ### ### ### ### Microarchitecture: Neoverse N1 ### ## ### ######## Max Frequency: ~2.990 GHz ### ### ######## Cores: 12 cores ## ## ### ######## Features: NEON,SHA1,SHA2,AES,CRC32 Peak Performance:574.08 GFLOP/s Hope that helps... 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: Planned Outage - network hardware updates - 2024-08-27 15:00 UTC
On Wed, Aug 28, 2024 at 04:53:07PM GMT, ke...@scrye.com wrote: > The content of this message was lost. It was probably cross-posted to > multiple lists and previously handled on another list. Sigh. That bug is sure anoying sometimes. ;( Planned Outage - network hardware updates - 2024-08-29 15:00 UTC There will be an outage starting at 2024-08-29 15:00 UTC, which will last approximately 1 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2024-08-29 15:00UTC' Reason for outage: Some networking hardware at our IAD datacenter will be updated. There may be small network outages as devices reboot into new firmware and routes and switch ports reconverge. Affected Services: services at IAD2, but only for small windows. Ticket Link: https://pagure.io/fedora-infrastructure/issue/12153 Please join #fedora-admin or #fedora-noc on irc.libera.chat or #admin:fedoraproject.org / #noc:fedoraproject.org on matrix. Please add comments to the ticket for this outage above. Updated status for this outage may be available at https://www.fedorastatus.org/ 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
Planned Outage - network hardware updates - 2024-08-27 15:00 UTC
The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list. -- ___ 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
Re: New repo closed as invalid
On Fri, Aug 23, 2024 at 08:13:13PM GMT, Sergio Pascual wrote: > Hello, I have requested a repo for a package recently approved > > https://bugzilla.redhat.com/show_bug.cgi?id=2213588 > > and the releng-bot is closing the issue with "The Bugzilla review bug > creator could not be found in FAS. Make sure your FAS email address is > the same as in Bugzilla." > > For example, this one: > > https://pagure.io/releng/fedora-scm-requests/issue/65453 > > > Any idea of what is happening? This was fallout from the auth issues last night. I have worked around the issue for now and these should process again as normal. I reopened that one for you and it seems to have processed ok now. If anyone else is hitting this, reopening should have it reprocess... 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: poppler soname bump in Rawhide
Jan Grulich wrote: > The reason for this is that qt5-qtwebengine copies over re2 header files, > but that doesn't mean it links against the system version, it still uses > the bundled one anyway. The way it was SUPPOSED to work was that the header hack was supposed to be applied together with an unbundling build system patch that linked against the system library instead of building the bundled stuff. But that hack either never worked as intended or has stopped working at some point. (The build system parts of the hack might have been lost at some point in time.) 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
Re: Inactive packagers for the F41 cycle
On Wed, Aug 21, 2024 at 10:50:05PM GMT, Michel Lind wrote: > On Wed, Aug 21, 2024 at 09:33:19AM -0700, Kevin Fenzi wrote: > > On Wed, Aug 21, 2024 at 06:07:12AM GMT, Mattia Verga via devel wrote: > > > Il 20/08/24 20:11, Ankur Sinha ha scritto: > > > > Hi Mattia, > > > > > > > > Thanks for this. > > > > > > > > I had a small query about the removal of folks from groups---are they > > > > not also removed from other packager groups? > > > > > > > > For example, I noticed we had folks in the neuro-sig packager group that > > > > had been removed from the packager group due to inactivity. I went ahead > > > > and removed them manually now, but that brought up a query about > > > > src.fp.o: > > > > > > > > If people are still in the neuro-sig packager group, even if they're not > > > > in the packager group, do they still have access to the neuro-sig > > > > packages? > > > I think they'd still have commit access to the package repository. > > > > Yep. > > > > > However, AFAIK pushing a build in Koji or submitting a Bodhi update > > > should be impossible for them, because the packager group membership is > > > mandatory there (at least, for Bodhi). > > > > Yep. > Does Packit enforce this too? Otherwise for packages configured to tell > Packit to auto-build, if the ex-packager still has commit access, a > build and Bodhi update can still happen since the submitter is Packit, > not the packager. You mean someone pushing a change and waiting for an upstream release for packit to do a build/update? I suppose thats possible sure. 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: Inactive packagers for the F41 cycle
On Wed, Aug 21, 2024 at 06:07:12AM GMT, Mattia Verga via devel wrote: > Il 20/08/24 20:11, Ankur Sinha ha scritto: > > Hi Mattia, > > > > Thanks for this. > > > > I had a small query about the removal of folks from groups---are they > > not also removed from other packager groups? > > > > For example, I noticed we had folks in the neuro-sig packager group that > > had been removed from the packager group due to inactivity. I went ahead > > and removed them manually now, but that brought up a query about > > src.fp.o: > > > > If people are still in the neuro-sig packager group, even if they're not > > in the packager group, do they still have access to the neuro-sig > > packages? > I think they'd still have commit access to the package repository. Yep. > However, AFAIK pushing a build in Koji or submitting a Bodhi update > should be impossible for them, because the packager group membership is > mandatory there (at least, for Bodhi). Yep. > > Also, of course, FAS only syncs with src.fp.o when people login, so even > > though I removed these folks from the FAS group, they're still listed on > > the src.fp.o group (but this isn't an issue since I expect they'll be > > removed from here when they login and things sync): > > > > https://src.fedoraproject.org/group/neuro-sig > > > > vs > > > > https://accounts.fedoraproject.org/group/neuro-sig/ > > > > > Yeah, the src.fp.org only synchs from accounts.fp.org when a user logs > in. There was WIP to have an automated scheduled script that do the > synch in background, but I lost track of the progress on that. https://pagure.io/fedora-infra/toddlers/issue/190 is the issue on it. Basically we have had to add some message bus messages and now waiting on some fasjson support to list things we need. (at least thats what I recall) 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: Orphaned m2crypto
On Tue, Aug 20, 2024 at 02:33:32PM GMT, Neal Gompa wrote:
> Hey all,
>
> I've just orphaned m2crypto. I and a couple of other folks tried to
> fix it this cycle and it's too difficult for us to deal with. I have
> no need for this anymore, and upstream is moribund and more or less
> recommending people to port away from it.
Yeah, understandable. ;(
> Here's the list of reverse dependencies from DNF:
>
> ngompa@fedora ~> dnf rq --qf "%{SOURCERPM}" --whatrequires "python3-m2crypto"
> dmlite-1.15.2-21.fc41.src.rpm
> dnsviz-0.10.0-3.fc41.src.rpm
> fts-rest-client-3.13.2-1.fc41.src.rpm
> hash-slinger-3.2-5.fc41.src.rpm
> module-build-service-3.9.2-9.fc41.src.rpm
> oz-0.18.1-15.fc41.src.rpm
^ This is the only one I care about...
I know we can/are moving away, so perhaps we can do that before we need
to move builders to f41.
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: F41 branching completed
On Fri, Aug 16, 2024 at 11:01:54AM GMT, Artur Frenszek-Iwicki wrote: > Hi, Kevin. > > I spotted an issue where one of my Bodhi updates for F41 got marked as > obsoleted by an F42 update > and now F42 is updated, F40 has an update in testing, whereas F41 has the old > package version. > Is is possible to re-tag the F41 build? > > Obsoleted update: > https://bodhi.fedoraproject.org/updates/FEDORA-2024-88ea1e8a79 > Affected package: > https://src.fedoraproject.org/rpms/chocolate-doom Not really. There's already that existing update, so we cannot make another one with the same n-v-r. We could just manually tag it into f41, but then there's no record of it in bodhi, so if we wanted to see what happened later it would not at all be clear. I'd suggest just bumping the release and doing another f41 build to get a proper update, etc. 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: Inactive provenpackagers for the F41 cycle
On Fri, Aug 16, 2024 at 04:40:25PM GMT, Mattia Verga via devel wrote: > Il 16/08/24 11:01, Stephen Smoogen ha scritto: > > There is currently a bug in the Fedora mailman which is causing emails > > sent to multiple lists to delete some copies of the emails. It is > > being looked at by the upstream to figure out why and how to fix. > > > > > Yeah, but I just sent the email to devel-announce (and bcc the affected > provenpackagers), so I did not cross posted the mail to other lists... Yeah, devel-announce posts to devel also. (ie, devel is subscribed to devel-announce) https://pagure.io/fedora-infrastructure/issue/12011 is our ticket on it https://gitlab.com/mailman/mailman/-/issues/1162 is the upstream ticket where we are trying to debug with mailman folks. 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: Unannounced soname bump in libre2
On Wed, Aug 14, 2024 at 04:30:09PM GMT, Sandro via devel wrote: > On 14-08-2024 15:32, Ben Beasley wrote: > > Given the timing and the complexity of the dependency chains involved > > here, I used provenpackager privilege to start rebuilding grpc in both > > F42 and F41, which will unblock many of the other packages that need to > > be rebuilt. > > > > To do so, I added a BuildRequires on openssl-devel-engine[1] as a > > short/medium-term resolution for FTBFS due to > > https://fedoraproject.org/wiki/Changes/OpensslDeprecateEngine. The > > rebuilds are still in progress – it usually takes about 2-3 hours to > > build grpc in koji – but I expect them to succeed. > > > > - https://koji.fedoraproject.org/koji/taskinfo?taskID=121948781 > > > > - https://koji.fedoraproject.org/koji/taskinfo?taskID=121948783 > > > > If I have time later today, I’ll check in on these and try to rebuild > > more of the affected packages. > > > > [1] > > https://src.fedoraproject.org/rpms/grpc/c/2f7c688380196227334a331cfc701bc5e203157c?branch=rawhide > > Thank you Ben! I suppose fixing grpc needed to happen anyway. My build in > Copr, applying the same fix, just succeeded. > > However, I'm not sure the re2 update is compatible with other dependent > packages. My smoke test, yesterday, already showed some packages fail to > build with libre2.so.11, while they do succeed with libre2.so.9. Packages > known to fail with libre2.so.11 are: > > perl-re-engine-RE2 > python-fb-re2 > qt5-qtwebengine > > Of those qt5-qtwebengine impacts 48 other packages directly. So, the f41 branched compose is syncing (almost done) right now and has this update in it. (as does rawhide). We could untag it from one or both rawhide/f41, but... is that desired now? Sounds like folks have rebuilt some dependent packages, so it would break those unless we also untagged them. Or is it better to just power through and rebuild things ? 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: F41 branching completed
On Tue, Aug 13, 2024 at 10:17:41PM GMT, Peter Robinson wrote: > > It could be tagged for both. > > > Or would you prefer to just do another f42/rawhide build? > > I can do another build, I was looking to push a newer version but I > need to do some more testing before the bump to 1.4.x I just tagged it into f42 for now. You can update later at your leasure. 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: F41 branching completed
On Tue, Aug 13, 2024 at 10:07:07PM GMT, Peter Robinson wrote: > Hi Kevin, > > > Fedora Linux 41 has now been branched, please be sure to do a > > 'git fetch -v' to pick up the new branch. As an additional reminder, > > rawhide/41 has been completely isolated from previous releases, which > > means that anything you do for 41 you also have to do in the rawhide > > branch and do a build there. There will be a Fedora Linux 41 compose and > > it will appear in [1] once complete. > > > > Bodhi is currently enabled in the 41 branch like it is for rawhide, with > > automatic update creation. At the hit Beta change freeze point in the > > Fedora Linux 41 schedule [2] updates-testing will be enabled and manual > > bodhi updates will be required as in all stable releases. > > > > 41/branched release is frozen right now until we get a successful > > compose, expect that your 41 builds won't be available immediately. > > It seems there's some minor tagging issues, I suspect due to timing > around when I did a build, I would have expected > open62541-1.3.12-1.fc41 to be tagged 42 but open62541-1.3.10-4.fc41 > was tagged. yeah, that was right at the wrong time. :) Would you like it untagged from f41 and tagged into f42? Or would you prefer to just do another f42/rawhide build? 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: Missing Bugzilla component for a new package
On Tue, Aug 13, 2024 at 02:24:57PM GMT, Michal Schmidt wrote: > Thanks, I filed: https://pagure.io/fedora-infrastructure/issue/12127 > Michal I'll note here what I added to the ticket already: Yeah, we are aware. This is more breakage from retiring pdc. ;( We actually have the new setup ( https://pagure.io/fedora-infra/toddlers/pull-request/238 ) but we didn't get time before flock to roll it out. Hopefully in the next few days we will get it tested and rolled out. Sorry for the issue. 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
F41 branching completed
Hi All, Fedora Linux 41 has now been branched, please be sure to do a 'git fetch -v' to pick up the new branch. As an additional reminder, rawhide/41 has been completely isolated from previous releases, which means that anything you do for 41 you also have to do in the rawhide branch and do a build there. There will be a Fedora Linux 41 compose and it will appear in [1] once complete. Bodhi is currently enabled in the 41 branch like it is for rawhide, with automatic update creation. At the hit Beta change freeze point in the Fedora Linux 41 schedule [2] updates-testing will be enabled and manual bodhi updates will be required as in all stable releases. 41/branched release is frozen right now until we get a successful compose, expect that your 41 builds won't be available immediately. Thanks for understanding. Regards, Fedora Release Engineering [1] https://dl.fedoraproject.org/pub/fedora/linux/development/41/ [2] https://fedorapeople.org/groups/schedule/f-41/f-41-key-tasks.html signature.asc Description: PGP signature -- ___ 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
Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)
On Mon, Aug 05, 2024 at 01:06:20AM GMT, Kevin Kofler via devel wrote: > Kevin Fenzi wrote: > > I am not making any such assumputions. Let me be clear (and speaking > > only for myself): > > > > Changes are not always good > > Not every unacceptable/rejected change can be reworked to be acceptable. > > > > Where did I say otherwise? > > The "Not every unacceptable/rejected change can be reworked to be > acceptable." part is not the impression I get when I read your paragraph: > > > The approved/second/reworked version of this _did_ take lots of people's > > concerns into account. In this case yes. In other cases no. You are trying to make some kind of sweeping generality based on a specific case. > So "lots of people's concerns" were "take[n] into account". That does not > imply though that this is sufficient to fix the issues with the proposal, as > you are implicitly implying here. This is where I first got the impression > that you are assuming that it is always possible to rework a Change to make > it acceptable. I'm sorry if you got that impression. > > There were/are still some few people who still didn't like it for whatever > > reasons, but I think it's pretty clear that concerns were defintely heard. > > That goes even father, implying that it is OK to ignore the objections of > "some few people". There is also no evidence that the people still objecting > are few, for that matter. It's ok to approve a change that a majority of FESCo members feel is acceptable. I can't speak to the thoughts of my fellow FESCo members in this case. Sometimes not everyone likes/would approve a change, thats unfortunate, but sometimes it happens. > > The change owners were very patient and responded to tons of people. > > Again, responding does not imply that they even changed the proposal as a > response (as opposed to trying to explain the issues away, as happens so > often), let alone that the changes were sufficient to fix the issues in it. Looking at the orig proposal vs the one that was approved shows they changed the proposal? > > > You cannot sometimes please everyone. > > And that again implies that it is OK to trample over the objections of other > people and force through controversial changes. It's ok for FESCo members to use their judgement in passing changes that still have some objections. Anyhow, I have to get up super early to travel tomorrow, so I will leave it at that. 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: Schedule for Tuesday's FESCo Meeting (2024-07-23)
Kevin Fenzi wrote: > I am not making any such assumputions. Let me be clear (and speaking > only for myself): > > Changes are not always good > Not every unacceptable/rejected change can be reworked to be acceptable. > > Where did I say otherwise? The "Not every unacceptable/rejected change can be reworked to be acceptable." part is not the impression I get when I read your paragraph: > The approved/second/reworked version of this _did_ take lots of people's > concerns into account. So "lots of people's concerns" were "take[n] into account". That does not imply though that this is sufficient to fix the issues with the proposal, as you are implicitly implying here. This is where I first got the impression that you are assuming that it is always possible to rework a Change to make it acceptable. > There were/are still some few people who still didn't like it for whatever > reasons, but I think it's pretty clear that concerns were defintely heard. That goes even father, implying that it is OK to ignore the objections of "some few people". There is also no evidence that the people still objecting are few, for that matter. > The change owners were very patient and responded to tons of people. Again, responding does not imply that they even changed the proposal as a response (as opposed to trying to explain the issues away, as happens so often), let alone that the changes were sufficient to fix the issues in it. > You cannot sometimes please everyone. And that again implies that it is OK to trample over the objections of other people and force through controversial changes. 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
Re: [Java related] packaging Italian ID card middleware
Björn Persson wrote: > I wish I were allowed to use FIDO2. The dominant ID protocol in Sweden > is called BankID. It's a proprietary and secretive protocol that > requires a proprietary app that requires an operating system from > either Apple or Google – or sometimes Microsoft, but in many cases not > even Windows is allowed. No FIDO2 or other open standard is allowed. > > It's becoming ever more difficult to be a Fedora user in Sweden. > Several banks require BankID. Members of various associations must have > BankID to log in to membership pages. Many webshops accept payment only > through Klarna, and Klarna now requires everybody to use BankID. Thus > the BankID cartel effectively controls which operating systems have > access to the Swedish market. Users of other operating systems are > severely restricted in which banks they can have accounts in, which > shops they can buy from, et cetera. Keep in mind that the ID Austria system (the one that has a FIDO2 option as an alternative to the proprietary smartphone app) is essentially only for government agencies. Only few private companies (such as the former public monopoly postal service (Post)) support it. Banks have their own authentication methods for online banking, typically a bank-specific proprietary smartphone app. 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
Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)
On Fri, Aug 02, 2024 at 02:07:18AM GMT, Kevin Kofler via devel wrote: > Kevin Fenzi wrote: > > The approved/second/reworked version of this _did_ take lots of people's > > concerns into account. There were/are still some few people who still > > didn't like it for whatever reasons, but I think it's pretty clear that > > concerns were defintely heard. The change owners were very patient and > > responded to tons of people. You cannot sometimes please everyone. > > Well, here, you are making the next fallacious assumption that is so common > in the Fedora Change process (after the "change is always good" one), and > that is that every unacceptable Change proposal can be reworked to make it > acceptable. That is fallacious because some Changes are unacceptable by > design, i.e., the whole concept of the Change is unacceptable. E.g., IMHO, I am not making any such assumputions. Let me be clear (and speaking only for myself): Changes are not always good Not every unacceptable/rejected change can be reworked to be acceptable. Where did I say otherwise? I think its good for us to push on change proposals and if the submitters are willing to compromise to get more support thats great. If they aren't, thats fine too, and the proposal can just be rejected if it doesn't have enough support. I think often there's things change owners don't think of and are happy to adjust, or things they would rather not change, but they have empathy and make what changes they are willing to. > telemetry is always an unacceptable privacy invasion, and as such, no amount > of reworking of the Change proposal can possibly make it acceptable. Such an > unfixable Change just has to be finally (i.e., irrevocably) rejected. Yes, your position is clear, I (and apparently others) don't share it. 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: Orphaned packages looking for new maintainers
On Sat, Aug 03, 2024 at 10:13:52AM GMT, Maxwell G wrote: > > On 8/3/24 10:05 AM, maxw...@gtmx.me wrote: > > Report started at 2024-08-03 14:00:44 UTC > > > > The following packages are orphaned and will be retired when they > > are orphaned for six weeks, unless someone adopts them. > > The packages listed as orphaned for 6 weeks have already been retired in > distgit but have not yet been blocked in Koji, due to [1], so they remain > present in this list. Please don't try to unorphan those packages. > > [1] https://pagure.io/releng/issue/12192 I have blocked all the ones there. I really thought we would have this fixed up before now, sorry about that. > See you all at Flock next week! I'll be staffing the registration desk on > Wednesday afternoon and speaking about fedrq, my repository querying tool, > on Thursday. Looking forward to it! 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: Schedule for Tuesday's FESCo Meeting (2024-07-23)
Przemek Klosowski via devel wrote: > I just can't agree with this statement---both in some deep philosophical > sense and in practical terms. F is for First! Yes, the changes are > sometimes annoying---I miss my FreeCAD :(---but, overall, I think Fedora > has a track record of consistently advancing technology. To you and everyone else who has brought up the "First" objective: Please keep in mind that "First" is only ONE of the four 'F's. I strongly object to making "First" the one priority at the expense of the other three 'F's. I believe there is also a deep misunderstanding in large parts of the community about the meaning of "First": "First" means that Fedora should offer the latest software. It does NOT mean that Fedora should remove older applications and/or the compatibility libraries they require at the first perceived occasion. In fact, I also believe that dropping support for compatibility libraries/interpreters/… and removing the applications that require them goes against ALL THREE of the other 'F's: * Freedom, because of "Freedom Zero", "The freedom to run the program as you wish, for any purpose" [https://www.gnu.org/philosophy/free-sw.html.en]. Removing needed compatibility libraries makes it a lot harder for the users to exercise that basic freedom. * Features, because every application you remove is a major feature loss for the distribution. To me, "Features" implies that we should strive to ship as much software in Fedora as possible, even if it is old, unmaintained, and dependent on legacy (i.e., also unmaintained) libraries or interpreters. * Friends, because removing the applications users need will definitely not make you any friends. As for Changes that are not about shipping any new software at all, but just about doing things differently, I do not see how those even fall under "First" to begin with. 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
Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)
Kevin Fenzi wrote: > The approved/second/reworked version of this _did_ take lots of people's > concerns into account. There were/are still some few people who still > didn't like it for whatever reasons, but I think it's pretty clear that > concerns were defintely heard. The change owners were very patient and > responded to tons of people. You cannot sometimes please everyone. Well, here, you are making the next fallacious assumption that is so common in the Fedora Change process (after the "change is always good" one), and that is that every unacceptable Change proposal can be reworked to make it acceptable. That is fallacious because some Changes are unacceptable by design, i.e., the whole concept of the Change is unacceptable. E.g., IMHO, telemetry is always an unacceptable privacy invasion, and as such, no amount of reworking of the Change proposal can possibly make it acceptable. Such an unfixable Change just has to be finally (i.e., irrevocably) rejected. 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
Re: package maintainers should be using fedpkg-1.45
On Tue, Jul 30, 2024 at 01:03:14PM GMT, Jens-Ulrik Petersen wrote: > It seems PDC was turned off about 12 hours ago. yeah, we have actually been disabling it and thinking we were done, but then something still has it's tendrils into it and we re-enable it to fix that, etc. It's now been down for almost 2 days and I think we have cleaned up the last of the things we found that used it. > This affects fbrnch unfortunately: though I am planning a new release > soon... > In the meantime you can use `touch ~/.cache/fedora/product-versions.json` > as a workaround, though every 5 hours alas. Sorry about that breakage. :( 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: Following up on: Three steps we could take to make supply chain attacks a bit harder
On Mon, Jul 29, 2024 at 03:33:21PM GMT, Gordon Messmer wrote: > tl;dr: Quick update, and one question: Are there other packages that should > be monitored? > > > > On 2024-06-24 9:03 PM, Gordon Messmer wrote: > > (As a topic for later: the tirpc library exports functions with the same > > name as functions that appear in libc, so the behavior of erroring on > > duplicate symbols needs to be rationalized. Maybe an exemption for > > libtirpc.so? Are there other libraries that do this?) > > > For now, I've added a list of symbols have have been found in multiple > libraries in services that I've checked. There are some symbols defined in > libc and libm, and in libc and libtirpc, and in libsasl2 and some of its > related libraries. There's probably a better implementation than this... > > > > I have a proof-of-concept test implemented for the openssh package, in > > this pull request: > > https://src.fedoraproject.org/rpms/openssh/pull-request/73 > > > Over the weekend, I opened a series of PRs for other services that are > probably frequently exposed to the public: sendmail, exim, postfix, > cyrus-imapd, haproxy, nginx, and httpd. These are lower-value targets than > sshd, since they don't run as root and may be run in a restricted SELinux > domain, but I tend to think that anything that provides an authentication > backend or listens for public connections should be checked. I'll work on > 389-ds and the krb5 packages later... Any other packages that might be > worth monitoring? Some possible ones I'll toss out there: avahi-daemon cups rsyslog dovecot cockpit Thanks again for doing 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packages with problematic license tag (for SPDX conversion)
On Tue, Jul 30, 2024 at 04:07:01PM GMT, Miroslav Suchý wrote: ...snip... mxml kevin mxml is ASL-2.0 with a linking exception for "GPLv2 or LGPLv2" ( https://github.com/michaelrsweet/mxml/blob/master/NOTICE ) Should that be: apache-2.0 WITH GPL-Linking-Exception ? 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: List of long term FTBFS packages to be retired in 2 weeks
On Mon, Jul 29, 2024 at 09:41:14PM GMT, Michael Cronenworth wrote: > On 7/17/24 11:19 AM, Kevin Fenzi wrote: > > On Tue, Jul 16, 2024 at 12:43:06PM GMT, Michael Cronenworth wrote: > > > On 7/16/24 12:18 PM, Miro Hrončok wrote: > > > > php-symfony siwinski > > > > php-symfony-psr-http-message-bridge siwinski > > > > php-symfony3 remi, siwinski > > > Can someone pick these up? I do not have any more capacity to take on > > > packages. > > > > > > As the report will show these will break Mediawiki if dropped. > > I suppose infra-sig could if no one else will... since we need mediawiki > > for... well, the wiki. > > > > I'll wait until the next report in hopes someone else will take them > > though. :) > > > > kevin > > The packages have now been removed[1] from Rawhide and builds are > failing[2]. Could you pick them up and push them back out? Unretirement ticket: https://pagure.io/releng/issue/12229 :( 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: Fedora Mass Rebuild 41 has completed
> > So I see https://pagure.io/releng/issue/12195 is closed, but looks like > the correspoding F41FTBFS bugs are not yet created. > Are these FTBFS bugs going to be created at least before F42 branching? yes. 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
package maintainers should be using fedpkg-1.45
Greetings. All package maintainers should be using at least fedpkg-1.45, which was released a month ago now. This version drops checks aginst pdc.fedoraproject.org. We are retiring pdc and it will no longer be answering requests, so older versions of fedpkg may error. Thanks, kevin signature.asc Description: PGP signature -- ___ 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
Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)
On Wed, Jul 24, 2024 at 09:41:16AM GMT, Stephen Smoogen wrote: ...snip... > > That said, I also find this unanimous approval problematic for a > couple of reasons: > > 1. There are some subset of people who use Fedora because they thought > it was a privacy focused distribution. Their concerns did not seem to > be taken into account or it needs to be made clearer that is not what > the project aims as a high priority compared to other items. Those > people can then make a choice if the distribution is still what they > want to use. The approved/second/reworked version of this _did_ take lots of people's concerns into account. There were/are still some few people who still didn't like it for whatever reasons, but I think it's pretty clear that concerns were defintely heard. The change owners were very patient and responded to tons of people. You cannot sometimes please everyone. > 2. I would have liked to see a working server and infrastructure plan > on who and how this service is to be run. A service needing to be run > by Fedora Infrastructure usually needs a bit more time to get Yet > Another Service Never Used(*3) running without problems. Yeah, this was somewhat glossed over, but my understanding is that the SIG would be responsible for working with infrastructure on deploying things. In part I think this was not super detailed because no one wanted to do a bunch of planning and implementing before the change was even approved. I think the time to start working on those plans is... now. ;) > 3. This is collecting data which for the most part will end up like > the bug reports from Koschei, Retrace, Abrt, etc.. stored somewhere > with data which very few developers look at except to filter into > another '/dev/null' folder .. but required to have infrastructure > running for over a decade because it might still be needed. Well, that might be the case, but the change owners definitely plan to use this data for their planning. I expect others groups probibly won't short term, but this is really only targeting workstation right now. If it proves very useful to them, other groups may want to look at it. > To me any of those needed to be detailed further. Where does personal > privacy actually fit in the 4 F's. At the confluence of several of them, IMHO. > What happens to users if the Fedora > infrastructure breaks or isn't possible to get to due to some Internet The reporting part would just keep retrying I think, but good to confirm that with change owners. > problem. What is to be done if this turns out to be not needed or > useful after a release or two? I would expect if this doesn't work out, the sig would say 'sorry we don't need that anymore' and infrastructure would oc delete it. > Maybe those aren't FESCO issues (The first one is probably a council > issue, the second one is infrastructure in some ways. but the third > might be.) but I feel they need to be looked at. Absolutely. 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: Schedule for Tuesday's FESCo Meeting (2024-07-23)
Am Mittwoch, 24. Juli 2024 02:52:44 CEST schrieb Gary Buhrmaster: On Tue, Jul 23, 2024 at 10:38 PM Kevin Kofler via devel wrote: And this one is yet another case of FESCo rubberstamping a change without even any dissenting vote despite loads of negative mailing list feedback. How can one determine "loads"? Since the feedback itself is opt-in, no statistically valid conclusion can be reached based on the feedback received(*). FESCo needs to review the feedback that was received, and use their best judgement as to whether to approve or disapprove, and no one should expect there to be a dissenting vote just because of negative feedback. I would actually expect FESCo to unanimously vote against the feature if the feedback on the mailing list is overwhelmingly negative. Or at least a majority of FESCo, if it is controversial. But unanimous approval shows that the feedback on the mailing list has been completely ignored, making the feedback process entirely useless. (*) And in addition, there is lots of cases where only those with negative feedback will decide to "opt-in" to offer an opinion, as they are motivated. If there are not enough people motivated enough to comment in favor of the Change, this shows that the Change is not valuable enough to be implemented. If in addition, enough people object to the Change for good reasons, it follows that the Change should be rejected. The big issue with the process is that there is this ground assumption in Fedora that change is inherently good, and hence any Change should be approved by default. But IMHO, Fedora used to already be almost perfect, to the point where changing anything could only possibly make it worse. And, again IMHO, make it worse the Changes did. Some Changes globally increased the size of the distribution (though admittedly a lot of the creeping bloat also comes from upstream feature creep beyond the Fedora Project's control). Some Changes needlessly broke backwards compatibility, making existing software users were still relying on suddenly break. (The "Retire Python 2.7" Change is in that category.) Some Changes replaced working technologies with incomplete and/or buggy replacements that do not work for users' workflows. Sometimes, an opt-out is possible (and then I end up opting out on my machines more often than not, making my setup diverge more and more from the default), sometimes the replacement is unconditionally forced onto all users (and sometimes the opt-out gets silently discontinued in a later release without even a new Change). Some Changes were about gradually making native distribution packages second-class citizens, second to inferior technologies such as atomic images, containerized applications (Flatpak, Docker, …), etc. Some Changes are a threat to users' privacy. (The "Opt-In Metrics for Fedora Workstation" Change is in that category. All the more if the opt-in process uses the planned weasel wording to trick users into "opting in".) Some Changes are a threat to users' freedom, e.g., by offering proprietary software for download through various means. And there are probably more reasons I and others objected to Changes. Those objections were unfortunately never treated by FESCo as a reason to reject the Change. 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
Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)
Am Mittwoch, 24. Juli 2024 02:41:12 CEST schrieb Gary Buhrmaster: And, FWIW, it appears that qtwebkit has been FTBFS since F39, so qtwebkit could end up being a moot point. It built fine in the F39 mass rebuild, only started failing in the F40 one. So it is NOT in the list of packages to be retired in this cycle. I will try to fix the FTBFS ASAP, but the unilateral removal of Python 2 is going to make it a lot harder to get this package to build again. The current error is just due to an incompatible libxslt change requiring a "const" to be added somewhere: https://bugzilla.redhat.com/show_bug.cgi?id=2261634#c4 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
Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)
Zbigniew Jędrzejewski-Szmek wrote: > #3242 Change: Opt-In Metrics for Fedora Workstation > https://pagure.io/fesco/issue/3242 > APPROVED (+6, 0, 0) And this one is yet another case of FESCo rubberstamping a change without even any dissenting vote despite loads of negative mailing list feedback. I really wonder what we give feedback for at all if FESCo OKs any and all changes (except ones that propose to replace GNOME as the default desktop environment) anyway. 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
Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)
Zbigniew Jędrzejewski-Szmek wrote: > #3244 Change: Retire Python 2.7 > https://pagure.io/fesco/issue/3244 > APPROVED (+8, 0, 0) This is going to break the build of a whole bunch of compatibility packages, which will in turn break a lot of software in Fedora. Do you expect packages to do what Qt5WebEngine did for EPEL and bundle their own copy of Python 2 to be used at build time? This just does not make any sense whatsoever. For Qt5WebEngine, there is now a patch from Arch Linux to make it build with Python 3 that we could apply, but both the Qt 4 and 5 QtWebKit require Python 2 to build. As do several other packages, I am pretty sure. 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
Fedora rawhide compose report: 20240723.n.0 changes/updates
Hi everyone. The mass rebuild finished yesterday and after some untagging and restarting composes, the rawhide compose finished. For the next 2 weeks, You can see the report at: https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20240723.n.0/logs/changelog-Fedora-Rawhide-20240723.n.0.verbose Warning: it's 10MB Unfortunately the oom killer killed the compose just after it finished, but before it could sync and send the report. I am manually syncing it now and it should be done in the next few hours. 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: Fedora Mass Rebuild 41 has completed
On Mon, Jul 22, 2024 at 11:07:32PM GMT, Zbigniew Jędrzejewski-Szmek wrote:
> I noticed the following when comparing packages after the rebuild:
>
> │ │ │
> -{"type":"rpm","name":"guile22","version":"2.2.7-12.fc41","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:40"}
> │ │ │
> +{"type":"rpm","name":"guile22","version":"2.2.7-14.fc41","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:40"}
>
> It seems the info in os-release hasn't been updated so the
> package notes embedded in the binaries are off.
Odd. fedora-release definitely was updated...
% cat /usr/lib/system-release-cpe
cpe:/o:fedoraproject:fedora:41
I wonder where it's picking up 40 there?
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: Fedora Mass Rebuild 41 has completed
On Tue, Jul 23, 2024 at 12:48:27AM GMT, Miro Hrončok wrote: > On 22. 07. 24 22:26, Miro Hrončok wrote: > > > > > > Many of them are due to: > > > > nothing provides libguile-2.2.so.1()(64bit) > > > > or > > > > nothing provides libguile-3.0.so.1()(64bit) > > See https://bugzilla.redhat.com/show_bug.cgi?id=2299414 for the cause. I have untagged: guile22-2.2.7-14.fc41 mbedtls-3.6.0-2.fc41 guile30-3.0.9-2.fc41 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: Fedora Mass Rebuild 41 has completed
On Mon, Jul 22, 2024 at 04:05:17PM GMT, Chris Adams wrote: > Once upon a time, Björn Persson said: > > Kevin Fenzi wrote: > > > Per the Fedora Linux f41 schedule [1] we started a mass rebuild for > > > Fedora Linux f41 on 2024-07-17. > > > > I received 20 "BUILDING" notifications and 17 "COMPLETE" notifications. > > For three of my packages no "COMPLETE" notification arrived, but when I > > looked in the Koji web interface those builds were shown as completed. > > I got 0 notifications for 24 packages. I've filed https://pagure.io/fedora-infrastructure/issue/12074 to track this issue. 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: [Java related] packaging Italian ID card middleware
Julian Sikorski wrote: > Germany uses their own implementation too: > https://src.fedoraproject.org/rpms/AusweisApp2 > To add insult to injury, it requires the use of custom EC curves, which > are bound to stop working at any moment: > https://bugzilla.redhat.com/show_bug.cgi?id=2259403 At which point you should probably just bundle a static OpenSSL with AusweisApp2. As unfortunate as it is, there appears to be little other choice to keep the package running here, and bundling forked libraries is no longer against Fedora packaging guidelines. And there are other packages already bundling forked versions of OpenSSL (e.g., Chromium and derivatives all bundle some version of "BoringSSL"). And at least the German stuff (and the Italian, Portuguese, and Estonian ones) is Free Software. The Austrian ID Austria app is entirely proprietary. Though, as far as I know, you can buy physical FIDO2 hardware, then go register that with the ID Austria office, and then log in on the ID Austria website with any FIDO2 enabled browser and the hardware you bought. But the default workflow goes through a proprietary smartphone app. 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
Re: [Java related] packaging Italian ID card middleware
Marián Konček wrote: > I had the same question and I don't exactly remember the most important > reason, but it was something like there were large differences between > versions which made the builds more difficult. Now I see it also uses > Kotlin, maybe that is also a reason. Upstream projects tend to just > bundle their own Gradle with them for building. Bootstrapping is one issue. As you noticed, Gradle now depends on Kotlin, which in turn requires Gradle to build, a circular dependency. Another is that, as was already mentioned by Fabio Valentini, neither Gradle projects nor Gradle itself are designed to be built without Internet access, which is a requirement for Fedora. Upstream's (Google's) idea of bootstrapping is that Gradle just downloads prebuilt JARs of all the dependencies from the Internet at build time, which violates both the "no Internet access" and the "no binary blobs" rule in Fedora. The first of which is a requirement for the package to build at all in Koji, the second a MUST-level Packaging Guideline. 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
Re: [Java related] packaging Italian ID card middleware
Germano Massullo wrote:
> 1. please switch to CMake build system completely: some parts of the
> software need to be built through Eclipse, I.E. cie-pkcs11. CMake should
> be the only build system in the project. CMake will also enable CIE
> Middleware being built for all Linux distributions, Mac OS, Windows;
As much as I like CMake, I would not recommend it here. CMake has only
limited support for Java. Maven (mvn) makes more sense to use here.
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
Fedora Mass Rebuild 41 has completed
Hi all, Per the Fedora Linux f41 schedule [1] we started a mass rebuild for Fedora Linux f41 on 2024-07-17. We did a mass rebuild for Fedora Linux f41 for: https://pagure.io/releng/issues?status=Open&tags=mass+rebuild The mass rebuild was done in a side tag (f41-rebuild) and moved over to f41. Failures can be seen https://kojipkgs.fedoraproject.org/mass-rebuild/f41-failures.html Things still needing rebuilding https://kojipkgs.fedoraproject.org/mass-rebuild/f41-need-rebuild.html 22899 builds have been tagged into f41, there is currently 1008 failed builds that need to be addressed by the package maintainers. FTBFS bugs will be filed shortly. Please be sure to let releng know if you see any bugs in the reporting. You can contact releng in #fedora-releng on libera.chat, by dropping an email to our list [2], joining #releng:fedoraproject.org on Matrix, or filing an issue in pagure [3]. Regards, Fedora Release Engineering [1] https://fedorapeople.org/groups/schedule/f-41/f-41-key-tasks.html [2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/ [3] https://pagure.io/releng/ signature.asc Description: PGP signature -- ___ 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
Re: nbdkit -> openssl-devel-engine build dependency
On Fri, Jul 19, 2024 at 06:44:39PM GMT, Clemens Lang wrote: > Hi Jonathan, > > > > On 19. Jul 2024, at 18:13, Jonathan Wakely wrote: > > > > It's possible to find all packages in F40 (before openssl-devel-engine > > was introduced) that depend on the ENGINE_cleanup symbol (or some > > other symbol if there's a better one to check for), which will tell us > > all the packages that were affected by this change. Then bugs can be > > filed and each package can decide whether to add BuildRequires: > > openssl-devel-engine to its spec or not. Once that's step is done, all > > existing packages will be correct: they either don't use engines, > > because they never needed them, or they opt-in to using them. Then > > there will be no silent failures. Anything that isn't using them is > > doing so intentionally, so not a "failure". > > > > For new packages that want to use engines, presumably somebody will > > check that engine support is enabled when testing the functionality of > > the new package. If they mess that up, that's a packaging bug and can > > be fixed. > > > > So I really do think the way to fix this is to default to > > OPENSSL_NO_ENGINE and simultaneously file bugs for all packages using > > ENGINE_cleanup and tell them to decide whether to BuildRequires: > > openssl-devel-engine. > > Correct, I just didn’t have the time to work on this yet. > > See https://bugzilla.redhat.com/show_bug.cgi?id=2296114 for some progress > towards this. > > If anybody has automated tooling to mass-file Fedora tickets that I could > re-use, pointers very welcome. See https://docs.fedoraproject.org/en-US/fesco/Mass_package_changes/ first I'm not sure we have some standard mass bugzilla filing script. I know various folks have done it, but it might be nice to have one place for something like that. 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: [Java related] packaging Italian ID card middleware
Germano Massullo wrote: > It worths also mentioning that both the Windows and Mac OS versions do > not contain any Java source. > Moreover, the Windows version contains some C# sources > https://github.com/italia/cie-middleware > and the Mac OS version contains some Objective C sources > https://github.com/italia/cie-middleware-macos > They should have just used Qt libraries like the Estonian ID card > software stack > https://github.com/open-eid This implementation looks like they just had the requirement to make a "Linux version" on their requirement sheet, but no actual GNU/Linux developers. So they just used what they knew, which unfortunately is Java. Whereas the proprietary operating systems get nice native applications in one of the operating system's preferred programming languages. Sad. I wonder whether unofficial software (e.g., a port of any of those 3 implementations to C++/Qt) would be allowed or whether there would be legal risks in attempting to use them. (Hopefully, at least exercising the Free Software rights under the license of the official software ought to be safe!) 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
Re: [Java related] packaging Italian ID card middleware
Marián Konček wrote:
> You will do the others a great service if you use the English
> language in GitHub commits and READMEs.
I doubt this will be used outside of Italy, except perhaps by Italian
citizens abroad (like me), who should also understand the Italian language.
It looks like every single country does its own NIH solution for electronic
identity cards, as Christian Le pointed out:
Cristian Le wrote:
> Re: Sergio, so far it seems all Italian, Portuguese and Estonian are
> using different infrastructures.
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
Re: The future Fedora Copr "rolling" chroot cleanup policy
Pavel Raiskup wrote: > Yes, I believe there are high chances to accept this (much harder will > to prioritize the feature). If you know what you are doing, the point > should not be to make the prolonging process click-expensive - which it > admittedly is now, if you maintain dozens of long-term projects. Note > that OTOH I still think that *we all* should actively push our users to > evacuate EOL Fedora releases. > > IMO, the point is to keep the maintainer active, and get the response > periodically. But sure, once we have the RFE, we'll have a proper place > to discuss it with the rest of the Copr team. OK, I have filed the RFE: https://github.com/fedora-copr/copr/issues/ I would have marked it with the RFE label, but I am not allowed to set labels as the reporter, only team members can do that. 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
Re: corporatemarketingguide
Just a reminder in this thread of the line in the footer of all messages to this list: > > -- > ___ > 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 This user was blocked/disabled and the post was removed from the archive already. 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: [SPDX] Mass license change AGPLv3 to AGPL-3.0-only
On Thu, Jul 18, 2024 at 11:33:13AM GMT, Fabio Valentini wrote: > On Thu, Jul 18, 2024 at 9:40 AM Miro Hrončok wrote: > > > > On 18. 07. 24 1:30, Neal Gompa wrote: > > > You are conflating license tag conversion with a license audit. Tag > > > conversion is explicitly*not* an audit exercise. > > > > No, I state the old GPL tags and the new GPL identifiers have different > > meanings. > > > > > This is not an audit, and we have never offered a guarantee of > > > accuracy. If you want the tags to be accurate, you need to evaluate > > > the package every time it is updated. And I know you do it for your > > > stuff, but we know not everyone does. And we do not have tooling to > > > help people audit their packages properly. We also do not have tooling > > > to validate audits in place either. The change to SPDX identifiers is > > > *not* coupled to the "no effective licensing" thing. Those were > > > separate updates that happened at roughly the same time, but are > > > *still* not coupled to each other. > > > > I don't want to have this conversation here again. I won't change your mind. > > > > However, I say that what FESCo approved is not what you are acting as-if > > FESCo > > approved. Do you at least see that? > > I agree that the conversation in the meeting and what was finally > approved was slightly confusing, and I already feared that we were not > thinking it meant the same thing when we approved it (one of the > reasons why I voted 0). > > Some FESCo members seem to think that we approved "trivial license > conversions to SPDX are OK", others seem to think that we approved > "licenses that cannot be trivially converted to SPDX must use > LicenseRef--". The proposal voted on matches > the latter statement, but it does *not*, IMO, imply the first > statement. Yeah, I was confused by some of the proposals and asked to clarify and I thought we had, but I guess not. ;) First, the ticket says it's about "Mass license change GPLv2 to GPL-2.0-only", so I assumed that was the scope here, not all mass license changes, but I guess that was not the case. What I (thought) I voted on was to convert packages with GPLv2 to Licenseref-Fedoraoldwhatever-GPL-2.0-Only. This would allow the tooling to work on those things and still allow everyone to see it needs to be audited. In any case, please don't do any more changes and we should revisit 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: The future Fedora Copr "rolling" chroot cleanup policy
Pavel Raiskup wrote: > Have you considered to submit an RFE for this "Extend All" feature? > I think this convenience button (or even with API, if reasonably easy to > implement) sounds like an acceptable compromise to me. I remember having once suggested that on this mailing list and having received a quite negative reply from a Copr team member, saying that they deliberately did not want to make it that easy to extend everything. But if you think the RFE has a serious chance of being considered, I can file one. 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
Re: Introduction
On Wed, Jul 17, 2024 at 01:25:23PM GMT, Daniel Frantes wrote: > Hello, > Daniel Frantes here. I want to help you with packaging one day. > But I never done this, so I hope I will learn fast. If you guys have > questions on me, post it in thread I will try to respond. Welcome Daniel! Take a look at the package maintainer docs area: https://docs.fedoraproject.org/en-US/package-maintainers/ and do feel free to ask questions here, or in our #devel:fedoraproject.org matrix channel. 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: List of long term FTBFS packages to be retired in 2 weeks
On Tue, Jul 16, 2024 at 12:43:06PM GMT, Michael Cronenworth wrote: > On 7/16/24 12:18 PM, Miro Hrončok wrote: > > php-symfony siwinski > > php-symfony-psr-http-message-bridge siwinski > > php-symfony3 remi, siwinski > > Can someone pick these up? I do not have any more capacity to take on > packages. > > As the report will show these will break Mediawiki if dropped. I suppose infra-sig could if no one else will... since we need mediawiki for... well, the wiki. I'll wait until the next report in hopes someone else will take them though. :) 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: sbin-merge: what to do?
On Tue, Jul 16, 2024 at 11:51:28AM GMT, Neal Gompa wrote: > On Tue, Jul 16, 2024 at 11:13 AM Adam Williamson > wrote: > > > > On Tue, 2024-07-16 at 08:08 +0100, Daniel P. Berrangé wrote: > > > On Mon, Jul 15, 2024 at 05:07:57PM -0700, Kevin Fenzi wrote: > > > > On Mon, Jul 15, 2024 at 08:23:05AM GMT, Zbigniew Jędrzejewski-Szmek > > > > wrote: > > > > > > > > > So… the question now: should I pull the plug on the change for F41, > > > > > dump the side tag, and try again for F42? Or wait for some of the > > > > > patches > > > > > above to be merged? The mass rebuild is supposed to start in two days… > > > > > > > > How hard would it be to move back to the old state? > > > > Does that mean a bunch of reverts and rebuilds? or ? > > > > > > Assuming there was nothing impactful outside of the mentioned side tag, > > > then no rebuilds should be required, just abandon the tag, and do > > > dist-git reverts. yes, but... that has to happenright now or the mass rebuild will just build all those things again and it will land in rawhide anyhow. > > > > It sounds to me like there's still a lot of outstanding questions, so I > > > > would say moving it to f42 (and trying to land it after branching in > > > > rawhide) would be best, but that depends somewhat on how hard the revert > > > > is... if it's hard it might be better to power on through? > > > > > > Agree it sounds like the wise thing to do is to postpone to F42, to give > > > further time to fully explore the implications. If done right at the > > > start of the F42 dev cycle, there'll be a greater window for finding > > > and resolving any fallout before the F42 beta freeze point. > > > > Yeah, +1 to this. What concerns me about the openQA experience so far > > is the broad range of issues we hit, including ones that were kinda > > 'coincidental' (not actually the thing the test was trying to test). > > Since openQA is nowhere close to comprehensive, this implies more weird > > failures will show up even once it passes all the openQA update tests, > > and we will need time to identify and fix those. > > I will note that unless this is done right after F41 is branched from > Rawhide, we won't actually have a lot of time to get it sorted out. > Spring Fedora releases have a lot less time than fall ones because of > all the holidays leading up to it. So this needs to be planned to be > started again *right* after branching completes to maximize time to > fix things. Yep. agreed. 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: The future Fedora Copr "rolling" chroot cleanup policy
Pavel Raiskup wrote: > This is a gentle heads-up (at least a year in advance) that we plan to > address Fedora Copr storage consumption related to Fedora Rawhide > builds. Currently, Rawhide build results are kept indefinitely, but > this is going to change in the future. > > For the full story, see the blog post: > https://fedora-copr.github.io/posts/cleanup-rawhide-builds > > TL;DR: We plan to start monitoring build activity in Copr projects. > If no builds appear for a long time in these "rolling" chroots (such as > Fedora Rawhide), we'll disable such chroots, preserve the built results > for a while, and then delete them if no action is taken by the user. > > Hope this isn't going to cause too much inconvenience. Feel free to > discuss this here or under the blog post. So Copr is going even further with this broken approach of deleting user data to "address storage consumption". As I have already stated several times, deleting user data by default (on an opt-out basis) is NEVER acceptable. Even more so if the opt-out requires one to fight Copr's dark patterns deliberately making it a pain in the neck: One has to log into Copr every so often, and each time click a whole bunch of "Extend" buttons one at a time. There is no way to opt out permanently nor even for a longer time period than the default, nor even an "Extend All" button. The real issue still appears to be that "Disk storage is the commodity that incurs the highest cloud costs.", which means that cloud might not be the right technology to use here. Or at least the particular cloud implementation you are using (which last I checked was from Amazon). I understand that (also last I checked) the cloud infrastructure was donated to you for free. But that donation is not of much use if it does not include a workable amount of storage for something like Copr nor an offer to extend the storage at a reasonable price (which Amazon's list price is apparently not). 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
Re: sbin-merge: what to do?
Kevin Fenzi wrote: > I guess you are talking about live images here? > > If so, they shouldn't need rpm as they don't install using it... The live images MUST contain the rpm executable because their contents are installed to disk (HDD/SSD/whatever) when installing the live image, and at that point, rpm is needed to update the system. There are also use cases where users want to install some package into the transient overlay in RAM, or even just run some rpm -q query on the running live image. 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
Re: sbin-merge: what to do?
Zbigniew Jędrzejewski-Szmek wrote: > So… the question now: should I pull the plug on the change for F41, > dump the side tag, Yes please! > and try again for F42? No thanks! Please just dump this broken idea into the trashcan it belongs in. 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
Re: sbin-merge: what to do?
Frank R Dana Jr. wrote:
> I do not envy you this work. The documentation fallout alone...
So WHY again are we doing this then? All this is achieving is causing
breakage, for zero user-visible benefit.
IMHO, the sbin merge should NOT be merged/pushed from the side tag into
Rawhide. Instead, the changes should be reverted in dist-git and the Change
dropped for F41 and forever.
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
Re: sbin-merge: what to do?
the plug on the change for F41, > dump the side tag, and try again for F42? Or wait for some of the patches > above to be merged? The mass rebuild is supposed to start in two days… How hard would it be to move back to the old state? Does that mean a bunch of reverts and rebuilds? or ? It sounds to me like there's still a lot of outstanding questions, so I would say moving it to f42 (and trying to land it after branching in rawhide) would be best, but that depends somewhat on how hard the revert is... if it's hard it might be better to power on through? 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: Error building new package in sidetag
On Sun, Jul 14, 2024 at 10:02:28PM GMT, Mark E. Fuller via devel wrote: > Yes, it won't build at all for some reason: ...snip... The branch wasn't added propperly: https://pagure.io/releng/fedora-scm-requests/issue/63631 I asked it to retry (note, that anyone can do this, just add another comment and it should retry). It should be good in a few minutes... 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: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
Kevin Kofler via devel wrote: > That said, it is not sufficient to reject adding Fedora downstream > spyware. Fedora also needs a policy that upstream "telemetry" spyware is > not allowed and needs to be disabled at compile time or patched out. We > have several packaged applications wanting to "phone home" for this kind > of "anonymized usage statistics". This should not be allowed in a > privacy-concious distribution. PS (sorry, just read this right now): The most recent offender: https://gladtech.social/@cuchaz/112775302929069283 (This is not the first anti-user misfeature Firefox has been implementing, but this one is particularly bad.) 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
Re: Intent to retire pkpgcounter
Ohms, Jannis wrote: > I Inherited a legacy Project using this tool to count pages. I use this > tool as part of a tea4cups hook . are you aware of any substitutes for > pkpgcounter There is this fork: https://github.com/berghetti/pkpgcounter-1 that at least claims to support Python 3. (It is a fork of the lynxis/pkpgcounter fork that adds Python 3 support, but the lynxis fork was abandoned and there is at least one showstopper bug that is not fixed there, as can be seen in the issues. That bug is fixed in the berghetti fork, at least I see the change that should fix the bug in the code changes in the commit history. Note that I have NOT tested any of the versions.) 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
Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
mkol...@redhat.com wrote: > To only change that could impact spins is that we would ideally like to > drop the X11-only libXklavier library we have used for keaboard > handling so far and replace it with the universal localed keyboard > handling API. IIRC Jiri Konecny already notified all spin owners and > started some discussions about this. Unfortunately, the "universal localed keyboard handling API" is not as universal as your wording appears to imply. At least, not yet. Historically, the API was primarily intended to set the systemwide default locale and the systemwide default keyboard layout, requiring a reboot to apply. So getting the changes picked up in real time is something the desktop has to support explicitly. (And that support may also have to be enabled explicitly, e.g., KWin requires the --locale1 option.) I also wonder how this is expected to work in a multi-user setup (where some users may want to use different locale, keyboard layout, etc. settings than the system default), though in the context of installation, that is probably a non-issue. This of course also affects installers other than Anaconda, e.g., see also the discussion under: https://github.com/calamares/calamares/pull/2180 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
Re: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
Michael Catanzaro wrote: > We don't have proposed wording yet. We should of course be reasonable > and not write something misleading, but I think the question should be > something along the lines of "help improve Fedora" (e.g. "Help improve > Fedora by sending anonymous usage data" plus maybe "Fedora will never > collect identifiable data"). I believe that that is exactly the kind of euphemistic wording that Gary Buhrmaster was worried about. At least it looks very much suggestive to me. 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
Re: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
Mattia Verga via devel wrote:
> BTW, it's not really different on how the kde-sig managed to drop x11
> support - they wanted to do so and they have not stopped until they got
> what they want, addressing most of the concerns raised by the community.
But the main concern was that the community does not want X11 dropped to
begin with, so there was no way to address that concern while still dropping
X11 support from Plasma. Which is also why there are now the separate -x11
packages I maintain.
It is pretty much the same here: The main concern here is that we do NOT
want ANY spyware ("metrics", "telemetry") in Fedora, neither opt-in nor opt-
out. No amount of changes to the proposal will address that concern. The
only reasonable course of action is to reject this Change with prejudice
(i.e., reject it with the clear understanding that any refilings will be
summarily rejected without even getting announced or discussed again – there
is no point in beating a dead horse).
That said, it is not sufficient to reject adding Fedora downstream spyware.
Fedora also needs a policy that upstream "telemetry" spyware is not allowed
and needs to be disabled at compile time or patched out. We have several
packaged applications wanting to "phone home" for this kind of "anonymized
usage statistics". This should not be allowed in a privacy-concious
distribution.
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
Re: Summary/Minutes from today's FESCo Meeting (2024-07-09)
On Fri, Jul 12, 2024 at 09:11:49AM GMT, Stephen Gallagher wrote: > > Well, one thing that we ALSO lost in the conversion to Matrix was that > the minutes used to include links to the full text (in both text and > HTML formats) on meetbot.fedoraproject.org > In that case, the summary was enough to at least let people know 1) > what was discussed and 2) if a decision was made. If they wanted more, > a handy link was available to get the full logs. > > I have been trying to remember to manually add those links back when I > chair, but I'm inconsistent (at best). If something is missing that was there before, please do file a RFE on it. https://github.com/GregSutcliffe/maubot-meetings/issues or do you mean the web interface? https://github.com/fedora-infra/mote Possibly https://github.com/fedora-infra/mote/issues/684 ? 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: Sending mail using @fedoraproject.org (SMTP server needed)
On Thu, Jul 11, 2024 at 11:53:03AM GMT, Michel Lind wrote: > On Thu, Jul 11, 2024 at 03:03:33PM +0100, Daniel P. Berrangé wrote: > > On Thu, Jul 11, 2024 at 03:48:40PM +0200, Remi Collet wrote: > > > Hi, > > > > > > For years, it was possible to send email using a fedoraproject.org > > > address. > > > > > > It seems that various ISP now refuse to send mail from an alias outside > > > of their authority > > > > > > Ex: Orange French ISP now only allows @orange.fr address > > > linked to the authenticated account > > > > > > They suggest to use fedora project SMTP server > > > which doesn't exist > > > > > > For now, workaround exists (switching to another SMTP server) > > > but in the future more providers will probably apply same constraint yeah, sadly over time the email aliases are becoming less and less useful. > > Even if you use a different server, Fedora publishes SPF records, so if > > you're sending from a server that's not in SPF, your mail is more likely > > to be classified as spam. Note that the SPF record for fedoraproject is: fedoraproject.org descriptive text "v=spf1 a a:mailers.fedoraproject.org ip4:38.145.60.11 ip4:38.145.60.12 ?all" which has ?all at the end, which is _supposed_ to mean "Interpreted as None / No policy" So, providers should not care about this, but of course some providers probibly ignore all that and treat any spf record as deny all. > @centosproject.org is set up similarly - and I observed that sending > emails out with my own SMTP, with the from changed to my CentOS alias, > results in the mail being rejected by... Red Hat's server. To my knowledge, CentOS never provided aliases for maintainers. Things from @centos.org should normally be coming from official/expected IP's and allowed. I could of course be wrong... 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: Koji side tag -- how to use an older build?
On Thu, Jul 11, 2024 at 10:55:03PM GMT, Jan Pazdziora wrote: > > Hello, > > my Koji knowledge seems to be rusty and I used to be an admin in my > Koji instance, so I'm coming for an advice how to achieve what I need > in Fedora's Koji with the permissions given me by fedpkg. > > I'd need to debug a FTBFS issue, so I'd like to run a > > fedpkg scratch-build --target=... > > with a side tag target where I'd have an older version of > a specific dependency package. ok > I've used fedpkg request-side-tag to get me a side tag off f40-build, > then I used koji tag-build to tag a specific older build of openvdb > I want to have for my scratch build ... Sounds reasonable. > But when I run the scratch build, I still get the latest greatest > build from f40-updates. So it seems tagging into my child tag (target) > does not "override" the build seen, I still get newer build from the > parent tags. Did you wait for the next newrepo? It's not instant. You have to tag the package and wait-repo for the next newrepo for that sidetag. > How can I stop any newer build of that package to propagate from > f40 (or f40-updates) to my side tag and force the old build I need > to take precedence? You shouldn't need to, koji doesn't know anything about 'versions'. It only knows what is the most recently tagged in build of that package. 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
discuss f41 schedule adjustment for branching
Hey folks. I happened to notice the other day that f41 branching is currently scheduled for 2024-08-06. This is the day before flock. https://fedorapeople.org/groups/schedule/f-41/f-41-key-tasks.html I don't think this is a good time. :) While Samyak (who will be doing most/all of the releng work for branching) is unfortunately not going to be able to attend flock, there are often issues or things that need adjustment from others, and I think it's pretty unreasonable to ask those people to do these things and also be present at flock. So, we could: 1. Do nothing, but branching may be in a weird state or messed up or people going to flock may not be able to give their talks or interact with others because they are fixing things. 2. Move the branching a week later: 2024-08-13 and just leave it at that. That would leave one less week to clean up branching stuff and get updates through before bodhi enablement. 3. Move the branching a week later: 2024-08-13 and move the entire rest of the schedule out a week. 4. Move the branching a week sooner: 2024-07-30 and leave everything the same after. This would mean less time for the mass rebuild fixes, less time for maintainers to land changes that they wanted to land before branching. I probibly like 3 the best myself, with 2 pretty close. I don't like 1 or 4 much at all. :) Thoughts? 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
Planned Outage - Server updates/reboots - 2024-07-10 21:00 UTC
Planned Outage - Server updates/reboots - 2024-07-10 21:00 UTC There will be an outage starting at 2024-07-10 21:00 UTC, which will last approximately 6 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2024-07-10 21:00UTC' Reason for outage: We will be applying various updates and rebooting servers. During the outage window various services may be down for short periods of time. Additionally, we will be upgrading builders to Fedora 40. This will mean that koji buildroot repodata will change to being zstd based (per fedora 40 createrepo_c defaults). Affected Services: Many services will see short outages as machines are updated and rebooted. Ticket Link: https://pagure.io/fedora-infrastructure/issue/12041 Please join #fedora-admin or #fedora-noc on irc.libera.chat or #admin:fedoraproject.org / #noc:fedoraproject.org on matrix. Please add comments to the ticket for this outage above. Updated status for this outage may be available at https://www.fedorastatus.org/ signature.asc Description: PGP signature -- ___ 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
Re: libdisplay-info soname bump
Am Mittwoch, 3. Juli 2024 06:15:04 CEST schrieb Aleksei Bavshin: All the prep work has been finished and the side-tag is ready. Please, rebuild your packages with 'fedpkg build --target=f41-build-side-91835'. I have rebuilt kwin and kwin-x11 in the above side tag. 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
Re: fedorapeople.org updated (including new ssh host key)
On Wed, Jul 03, 2024 at 07:01:05AM GMT, Peter Boy wrote: > > > > Am 02.07.2024 um 23:50 schrieb Kevin Fenzi : > > > > On Tue, Jul 02, 2024 at 02:21:40PM GMT, Chris Adams wrote: > >> Once upon a time, Kevin Fenzi said: > >>> Please see https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org > >>> For more information, including information on adding our SSH CA or > >>> using dnssec / sshfp to verify the ssh host key of the new host. > >> > >> AFAIK the default Fedora setup with systemd-resolved does not support > >> DNSSEC for ssh using SSHFP records, and also the default SSH config > >> doesn't have VerifyHostKeyDNS enabled (so even if ssh could get the > >> record, with DNSSEC, it wouldn't use it). > > > > Yep, you need to enable dnssec in systemd-resolved (and have a > > nameserver that supports it) and set VerifyHostKeyDNS=yes in ssh_config. > > > > For that reason, I would say just adding the fedoraproject CA to > > known_hosts is much easier. (And also works for other fedoraproject.org > > hosts). > > > Maybe we need a more extensive documentation for this? Something like: Docs are always good. Note that the audience for these is fedora contributors that have access to fedorapeople.org, not all fedora users. > 1. minimal action > - What do you achieve (just use the functionality as you did before) > - Deal with the message "… authenticity of host … can't be established.“ > > 2. Use optional functionality > - SSH CA > —- What do you achieve > —- How to configure > - dnssec > —- What do you achieve > —- How to configure Well, I think probibly we should just tell folks to add the CA to their known_hosts and then perhaps as a aside mention sshfp records and such. Thats much harder to setup right. > We could do that by creating a Quick Doc article or by adding a section to > the current Wiki page. The wiki page could always use improvement... I guess at some point ideally we would move docs like this off the wiki and under docs.fedoraproject.org somewhere ( under the infra space seems not fully right, but I guess it could be there if nothing else comes to mind ). 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: fedorapeople.org updated (including new ssh host key)
On Tue, Jul 02, 2024 at 02:21:40PM GMT, Chris Adams wrote: > Once upon a time, Kevin Fenzi said: > > Please see https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org > > For more information, including information on adding our SSH CA or > > using dnssec / sshfp to verify the ssh host key of the new host. > > AFAIK the default Fedora setup with systemd-resolved does not support > DNSSEC for ssh using SSHFP records, and also the default SSH config > doesn't have VerifyHostKeyDNS enabled (so even if ssh could get the > record, with DNSSEC, it wouldn't use it). Yep, you need to enable dnssec in systemd-resolved (and have a nameserver that supports it) and set VerifyHostKeyDNS=yes in ssh_config. For that reason, I would say just adding the fedoraproject CA to known_hosts is much easier. (And also works for other fedoraproject.org hosts). 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
fedorapeople.org updated (including new ssh host key)
Greetings everyone. Last week we moved fedorapeople (people02.fedoraproject.org) from the now EOL RHEL7 to RHEL9. As part of this reinstall/migration, the ssh host key has changed. Please see https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org For more information, including information on adding our SSH CA or using dnssec / sshfp to verify the ssh host key of the new host. If you notice any problems with the server, please do file an infrastructure ticket ( https://pagure.io/fedora-infrastructure ) and we will take a look. Thanks, kevin signature.asc Description: PGP signature -- ___ 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
Re: koji excessive timeouts
On Mon, Jul 01, 2024 at 01:57:39PM GMT, Richard W.M. Jones wrote: > On Mon, Jul 01, 2024 at 02:24:45PM +0200, Ralf Corsépius wrote: > > Hi, > > > > Today, I am unable to access koji, apparently due to excessive timeouts. > > > > In ca. 3 out of 4 attempts, I am greeted with an error message of this kind: > > > > Gateway Timeout > > > > The gateway did not receive a timely response from the upstream > > server or application. > > Can confirm, it's pretty painful doing builds at the moment. Should be back to normal now. So what happened was that the rawhide compose runs a script called 'block_retired.py' at the beginning of the compose. This untags and blocks packages that are retired. Normally that takes a minute or two, no big deal... but sunday all the EPEL7 packages became end of life and considered retired by the script. It then tried to untag and block all epel7 packages and it was hammering koji doing so. ;( I have changed the script to not look at epel7 and restarted a new rawhide compose. koji should be back to normal. We do still have to decide what we want to do for all the things it untagged from epel7. Normally for fedora we just keep things we released for historical reasons, but perhaps we don't care for epel7. In any case we can do that slower/without breaking everything. 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: Fedora Hosted login for mailing lists error
On Thu, Jun 27, 2024 at 04:46:41PM GMT, Nathanael Noblet wrote: > Hello, > >I just happened to be looking at > https://lists.fedorahosted.org/accounts/login/?next=/archives/list/firewalld-users%40lists.fedorahosted.org/ > to try to sign up, and when I click on "Fedora" to try to use my fedora > account, I get a page telling me they'll redirect. Clicking continue > and I get 400 - Bad Request. "Invalid redirect_uri" and a message > saying to let Fedora Infra know. I don't know how to do that. There's a link in the message right there. ;) https://pagure.io/fedora-infrastructure/issues >I've used the "send an email to the special address" way, but just > wasn't sure how else to report the issue. In this case it's likely fallout from the massive mailman upgrade from eailer today. We already have a few issues to sort out noted in https://pagure.io/fedora-infrastructure/issue/8455#comment-916759 I'll add a note that the lists.fedorahosted.org login isn't working right. 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: New Fedora Planet
Multiple rss feeds should now be available in the account system profiles. Please do add any additional feeds there. 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: Following up on: Three steps we could take to make supply chain attacks a bit harder
On Wed, Jun 26, 2024 at 05:42:14PM GMT, Gordon Messmer wrote: > On 2024-06-25 10:37 AM, Kevin Fenzi wrote: > > I wonder if this wouldn't fit in as a CI test? > > > Do you mean https://docs.fedoraproject.org/en-US/ci/generic_tests/ ? yeah... > Maybe it would? If I misunderstand this, please correct me: > > Because Fedora uses "-z,relro" and "-z,now" in %build_ldflags, all binaries > should have a fully resolved GOT when they reach main(). That being the > case, gdb could be started with any binary, at which point it could set a > breakpoint at "main", run the binary, and then audit the GOT at the > breakpoint. > > Does that sound right? Sounds reasonable to me, but I don't know this area very well. > > Or something that might be added to rpminspect? > > > It's been a few months since I looked at rpminspect. Does it install a > package and all of its deps in order to inspect it? The GOT can't be > audited unless the process can start. yeah, I think it is able to start processes to test things, but I am again not sure of the details. So, hopefully rpminspect / ci folks will chime in... 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: fedpkg unable to push to rawhide or main
On Thu, Jun 27, 2024 at 03:45:59PM GMT, Anirban Mitra via devel wrote: > I am packager and maintainer and upstream developer of two font packages > fbf-mukti-fonts and uniol-fonts. The packages were orphaned and retired for > my inactivity. I followed the process of getting them re-reviewed and > unretiring the packages. However after un-retirement I can not push to > rawhide the latest versions. > However I am able to successfully request branch, push, koji build and bodhi > update in f40 branch, so there is no problem with my credentials. > On attempting to fedpkg push to rawhide I get the following message > > remote: Branch refs/heads/rawhide is unsupported. Cannot push to a disabled > branch (maybe eol?). > remote: Denied push for ref 'refs/heads/rawhide' for user 'mitradranirban' > remote: All changes have been rejected > To ssh://pkgs.fedoraproject.org/rpms/fbf-mukti-fonts > ! [remote rejected] rawhide -> rawhide (pre-receive hook declined) > > How to proceed further ? Wait for folks to sort it out in the releng ticket you filed? https://pagure.io/releng/issue/11913 The package seems to be in a weird state where it's not listed in pdc at all for rawhide... ;( 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
Planned Outage - fedorapeople.org - 2024-06-27 21:00 UTC
There will be an outage starting at 2024-06-27 21:00 UTC, which will last approximately 1 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2024-06-27 21:00 UTC' Reason for outage: We will be moving the fedorapeople.org vm to a RHEL9 install. During the outage repos and access to the server will be unavailable as we sync data from the old vm. Additionally, we will be pointing fedoraplanet.org to a new application that pulls rss feeds from the fedora account system instead of using .planet files. Please make sure your rss feed(s) are set in your account to continue sindicating them on fedoraplanet.org Affected Services: fedorapeople.org and all data stored there. Ticket Link: https://pagure.io/fedora-infrastructure/issue/12008 Please join #fedora-admin or #fedora-noc on irc.libera.chat or #admin:fedoraproject.org / #noc:fedoraproject.org on matrix. Please add comments to the ticket for this outage above. Updated status for this outage may be available at https://www.fedorastatus.org/ signature.asc Description: PGP signature -- ___ 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
Re: Following up on: Three steps we could take to make supply chain attacks a bit harder
On Tue, Jun 25, 2024 at 08:34:38AM GMT, Alexander Bokovoy wrote: > On Пан, 24 чэр 2024, Gordon Messmer wrote: ...snip... > > Is this work interesting? Should I continue working on it? > > Yes, it is definitely an interesting test. Thank you for investing your > time and resources into this. Yes, seconded. I wonder if this wouldn't fit in as a CI test? Or something that might be added to rpminspect? I guess it would need to keep state so it can keep track of changes, but hopefully thats possible. 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: 2FA policy for provenpackagers is now active
On Mon, Jun 24, 2024 at 09:09:58PM GMT, Leon Fauster via devel wrote: > Am 24.06.24 um 20:14 schrieb Tom Hughes via devel: > > On 24/06/2024 18:26, Stephen Gallagher wrote: > > > > > Not really an issue if you have GSSAPI set up on your system. Such as > > > by installing fedora-chromium-config-gssapi (for Chrome/Chromium > > > users) or by using Firefox which is set up for GSSAPI out-of-the-box. > > > > I've never seen Firefox use my kerberos ticket, it always asks me > > to login. That doesn't bother me though because I have my password > > manager readily available there, unlike at the command line. > > > Its long time ago that I used it. IIRC the website should be on the > site-list of the FF config. The key is > > network.negotiate-auth.trusted-uris > > maybe also > >network.negotiate-auth.delegation-uris > > Access it via ui (about:config) or add a system-wide config. Just FYI, the default for network.negotiate-auth.trusted-uris these days is: https:// ie, any https uri. 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: 2FA policy for provenpackagers is now active
On Mon, Jun 24, 2024 at 09:02:05PM GMT, Alexander Bokovoy wrote: > > BTW, the cheapest and verified to work with Fedora USB token I was able > to find is T2F2-NFC-Slim from Token2.eu: > https://www.token2.eu/shop/product/token2-t2f2-nfc-slim-fido2-u2f-and-totp-security-key > > The company actually sponsored FIDO2 passkey support development for > FreeIPA by sending this token to me a year ago. It is still in active > daily use. > > This token supports HOTP, TOTP, and FIDO2 operations, so it can be used > with Fedora Accounts today and in future, when Fedora infrastructure > upgrades to RHEL 9.4+, it will be able to handle FIDO2 passkey > authentication as well. Yeah, note that we are using RHEL 9.4, but... we need to add FIDO2/passkey management to noggin (the account system/frontend). (Unless I am missing something). I filed https://github.com/fedora-infra/noggin/issues/1424 on this, please feel free to add info there. 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: 2FA policy for provenpackagers is now active
On Mon, Jun 24, 2024 at 04:53:22PM GMT, Leigh Scott wrote: > > > I personally don't see why entering a otp once a week is such a > > burden... but it does seem to be. ;( > > > > kevin > > It isn't just once. > > 1. kerberos > 2. Web login on infra, bugzilla, bodhi, devel list and accounts > > If you do nightly shutdown you would need to enter it many times per week. Are you not using sssd-kcm? It stores your kerberos credentials so they survive reboots, etc. All web logins in infra should honor your kerberos credentials, so if you have a valid ticket, it should just log you in without having to enter anything. tickets are valid for 24hours and can be renewed for 1 week. (Either via gnome online accounts or just 'kinit -R') 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: 2FA policy for provenpackagers is now active
On Mon, Jun 24, 2024 at 02:39:13PM GMT, Mattia Verga via devel wrote: > > Perhaps it's a stupid idea, but we already have ssh public keys stored > in fas, would it be possible for fkinit to use the private key as second > factor? That way, on a system which is considered secure (it has the > private key stored in it) we would only require the user to enter the > FAS password, while on a smartphone or a temporary device the > password+otp would still be required. No, it's not currently possible. Rememver that we are using IPA as a backend, so it would need support in IPA. How would it know you wanted to use a ssh key instead of otp? I suppose it would have to try all your keys and see if any worked? It likely would cause a lot of confusion also for those that didn't expect it. I personally don't see why entering a otp once a week is such a burden... but it does seem to be. ;( 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
