Re: Ipsilon broken?
On Wed, Oct 13, 2021 at 6:36 PM Kevin Fenzi wrote: > On Wed, Oct 13, 2021 at 04:23:46PM -0500, Richard Shaw wrote: > > I'm trying to log into COPR but when I press submit it just stays at the > > login page and doesn't forward me back to COPR. > > This email looks a few hours old? What exact time were you seeing the > problems? > > It's very likely it was during a short outage we had eariler today... > > Anyhow, please try again, if it's still happening file a infra ticket > and we can track it down. (or mail ad...@fedoraproject.org if you can't > login to file a ticket). > Looks like it's working now. It must have remembered my login attempt from earlier as it didn't even prompt for my username and password. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Ipsilon broken?
On Wed, Oct 13, 2021 at 04:23:46PM -0500, Richard Shaw wrote: > I'm trying to log into COPR but when I press submit it just stays at the > login page and doesn't forward me back to COPR. This email looks a few hours old? What exact time were you seeing the problems? It's very likely it was during a short outage we had eariler today... Anyhow, please try again, if it's still happening file a infra ticket and we can track it down. (or mail ad...@fedoraproject.org if you can't login to file a ticket). 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: jq issue with integer handling logic
On Wed, 2021-10-13 at 18:53 -0400, Neal Gompa wrote: > > I can pick this up as a provenpackager tomorrow if this has been > requested and accepted as an FE for F35 and the maintainers haven't > done anything yet. Thanks, I have proposed this as a Freeze Exception: https://bugzilla.redhat.com/show_bug.cgi?id=2008979#c2 Cheers Davide ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: jq issue with integer handling logic
On Wed, Oct 13, 2021 at 6:29 PM Davide Cavalca via devel
wrote:
>
> Hello,
>
> the jq package currently has an unfortunate issue with handling large
> integers:
>
> $ echo '{"a":9011153322235679}' | jq '.a'
> 9011153322235680
>
> I reported this in https://bugzilla.redhat.com/show_bug.cgi?id=2008979
> a while ago and put up a PR at
> https://src.fedoraproject.org/rpms/jq/pull-request/4 to fix it. I think
> it'd be nice to get this merged and built before Fedora 35 releases if
> possible. For reference, the equivalent PR has already been merged in
> CentOS Stream 9
> (https://gitlab.com/redhat/centos-stream/rpms/jq/-/merge_requests/1).
>
I can pick this up as a provenpackager tomorrow if this has been
requested and accepted as an FE for F35 and the maintainers haven't
done anything yet.
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
jq issue with integer handling logic
Hello,
the jq package currently has an unfortunate issue with handling large
integers:
$ echo '{"a":9011153322235679}' | jq '.a'
9011153322235680
I reported this in https://bugzilla.redhat.com/show_bug.cgi?id=2008979
a while ago and put up a PR at
https://src.fedoraproject.org/rpms/jq/pull-request/4 to fix it. I think
it'd be nice to get this merged and built before Fedora 35 releases if
possible. For reference, the equivalent PR has already been merged in
CentOS Stream 9
(https://gitlab.com/redhat/centos-stream/rpms/jq/-/merge_requests/1).
Cheers
Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Ipsilon broken?
I'm trying to log into COPR but when I press submit it just stays at the login page and doesn't forward me back to COPR. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: API endpoint listing ISOs and checksums for Fedora releases and Rawhide?
On Tue, Oct 12, 2021, at 1:52 PM, Neal Gompa wrote: > Hey all, > > I'm working on extending quickemu[1] to be able to easily spin up > Fedora VMs, but our lack of a static URL formula for fetching ISOs > makes this a bit difficult. > > Do we have some kind of API endpoint that has the necessary > information for this? It'd be nice to be able to fetch some kind of > JSON file with the necessary information so that tools can fetch it > programmatically... For Fedora CoreOS we have standard stream metadata for this purpose: https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started/#_streams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-35-20211013.0 compose check report
No missing expected images. Failed openQA tests: 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-35-20211012.0): ID: 1027076 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1027076 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-35-20211012.0): ID: 1027061 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/1027061 Passed openQA tests: 15/16 (x86_64), 14/15 (aarch64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: System load changed from 0.05 to 0.20 Previous test data: https://openqa.fedoraproject.org/tests/1025452#downloads Current test data: https://openqa.fedoraproject.org/tests/1027065#downloads Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.52 to 0.41 Previous test data: https://openqa.fedoraproject.org/tests/1025457#downloads Current test data: https://openqa.fedoraproject.org/tests/1027070#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Robby Callicotte
Hello Maxwell, Thanks for the welcome. Here is the bugzilla link: https://bugzilla.redhat.com/show_bug.cgi?id=2013796 Cheers! ‐‐‐ Original Message ‐‐‐ On Wednesday, October 13th, 2021 at 14:31, Maxwell G (@gotmax23) via devel wrote: > Oct 13, 2021 2:29:10 PM Robby Callicotte via devel > devel@lists.fedoraproject.org: > > > Hello all, > > > > I am a long time Linux user (Mandrake 7.0, Fedora Core) and I want to > > contribute to the project. As part of my dayjob, I build rpm packages with > > a private koji instance as part of our internal deliverables pipeline. I > > have created a package for salt-lint, an ansible-lint like application for > > SaltStack, and submitted a review on Bugzilla. I also need a sponsor for > > some guidance. > > > > I look forward to the fun and the challenges. > > > > Sent with ProtonMail[https://protonmail.com/] Secure Email. > > Hi Robby, > > Welcome to Fedora! Do you mind including a link to the Bugzilla ticket? > > Thanks, > > Maxwell > > > Maxwell G (@gotmax23) > > Pronouns: He/Him/His > > PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 > > gotmax@e.email > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure publickey - rcallicotte@protonmail.com - 0xD97F72A7.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Robby Callicotte
Oct 13, 2021 2:29:10 PM Robby Callicotte via devel : > Hello all, > > I am a long time Linux user (Mandrake 7.0, Fedora Core) and I want to > contribute to the project. As part of my dayjob, I build rpm packages with a > private koji instance as part of our internal deliverables pipeline. I have > created a package for salt-lint, an ansible-lint like application for > SaltStack, and submitted a review on Bugzilla. I also need a sponsor for > some guidance. > > I look forward to the fun and the challenges. > > > > > Sent with ProtonMail[https://protonmail.com/] Secure Email. > Hi Robby, Welcome to Fedora! Do you mind including a link to the Bugzilla ticket? Thanks, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Self Introduction: Robby Callicotte
Hello all, I am a long time Linux user (Mandrake 7.0, Fedora Core) and I want to contribute to the project. As part of my dayjob, I build rpm packages with a private koji instance as part of our internal deliverables pipeline. I have created a package for salt-lint, an ansible-lint like application for SaltStack, and submitted a review on Bugzilla. I also need a sponsor for some guidance. I look forward to the fun and the challenges. Sent with ProtonMail Secure Email. publickey - rcallicotte@protonmail.com - 0xD97F72A7.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: final link failed: memory exhausted on armv7l
On 13/10/2021 15:44, Iñaki Ucar wrote:
Why rawhide and F35 and not F34?
Random issue due to the different builders.
Anything I can do in the SPEC to fix this?
Try this:
%ifarch %{arm}
%global _smp_build_ncpus 1
%endif
If it will not help, you can also try this:
%ifarch %{arm}
%global _smp_build_ncpus 1
%global optflags %(echo %{optflags} | sed 's/-g /-g1 /')
%endif
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: API endpoint listing ISOs and checksums for Fedora releases and Rawhide?
On Wed, 2021-10-13 at 14:45 -0400, Ken Dreyer wrote:
> On Wed, Oct 13, 2021 at 2:21 PM Neal Gompa wrote:
> > Unfortunately, we lack a usable equivalent for releases, though that's
> > good to know for Rawhide.
>
> For that I use the following URL format string:
>
> https://download.fedoraproject.org/pub/fedora/linux/releases/{version}/Cloud/x86_64/images/Fedora-Cloud-Base-{version}-1.2.x86_64.qcow2
That's not reliable. It will only work if we happened to release the
second candidate compose. That's certainly not the case for every
release.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: API endpoint listing ISOs and checksums for Fedora releases and Rawhide?
On Wed, Oct 13, 2021 at 2:21 PM Neal Gompa wrote:
> Unfortunately, we lack a usable equivalent for releases, though that's
> good to know for Rawhide.
For that I use the following URL format string:
https://download.fedoraproject.org/pub/fedora/linux/releases/{version}/Cloud/x86_64/images/Fedora-Cloud-Base-{version}-1.2.x86_64.qcow2
- Ken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: API endpoint listing ISOs and checksums for Fedora releases and Rawhide?
On Wed, Oct 13, 2021 at 2:14 PM Ken Dreyer wrote:
>
> On Tue, Oct 12, 2021 at 3:26 PM Adam Williamson
> wrote:
> > Hanging over all of this is the threat that PDC might go away at some
> > point, which would be a bit of an inconvenience. In A World Where there
> > is no PDC, you have to grab the metadata files for composes that still
> > exist from kojipkgs; there is no record of the metadata for composes
> > that have been garbage-collected. For stable releases you'd have to
> > parse whatever metadata you can just out of the actual release tree on
> > the mirrors.
>
> Yeah, PDC is a big liability to Fedora at this point and we should run
> away from it.
>
> Here's the code I use to download Rawhide images:
>
> get_rawhide_image_url():
> # We don't have productmd data available, so we must download COMPOSE_ID
> # and interpolate that directly into the assumed URL.
> r =
> requests.get('https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/COMPOSE_ID')
> r.raise_for_status()
> compose_id = r.text.strip()
> _, _, numeric = compose_id.split('-')
> url =
> 'https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Cloud/x86_64/images/Fedora-Cloud-Base-Rawhide-%s.x86_64.qcow2'
> % numeric
> return url
>
Unfortunately, we lack a usable equivalent for releases, though that's
good to know for Rawhide.
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: API endpoint listing ISOs and checksums for Fedora releases and Rawhide?
On Tue, Oct 12, 2021 at 3:26 PM Adam Williamson
wrote:
> Hanging over all of this is the threat that PDC might go away at some
> point, which would be a bit of an inconvenience. In A World Where there
> is no PDC, you have to grab the metadata files for composes that still
> exist from kojipkgs; there is no record of the metadata for composes
> that have been garbage-collected. For stable releases you'd have to
> parse whatever metadata you can just out of the actual release tree on
> the mirrors.
Yeah, PDC is a big liability to Fedora at this point and we should run
away from it.
Here's the code I use to download Rawhide images:
get_rawhide_image_url():
# We don't have productmd data available, so we must download COMPOSE_ID
# and interpolate that directly into the assumed URL.
r =
requests.get('https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/COMPOSE_ID')
r.raise_for_status()
compose_id = r.text.strip()
_, _, numeric = compose_id.split('-')
url =
'https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Cloud/x86_64/images/Fedora-Cloud-Base-Rawhide-%s.x86_64.qcow2'
% numeric
return url
- Ken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: API endpoint listing ISOs and checksums for Fedora releases and Rawhide?
On Wed, 2021-10-13 at 08:11 -0400, Stephen Gallagher wrote: > On Tue, Oct 12, 2021 at 2:42 PM Frantisek Zatloukal > wrote: > > > > Hi, > > > > in testcloud ( > > https://pagure.io/testcloud/blob/master/f/testcloud/util.py#_100 ), I am > > using adam's openqa nightlies.json for rawhide/branched: > > https://openqa.fedoraproject.org/nightlies.json (this isn't a "stable api") > > > > and https://getfedora.org/releases.json for stable releases. > > > > For programmatically determining which are the current fedora releases, I > > am using oraculum's > > https://packager-dashboard.fedoraproject.org/api/v1/releases (this wouldn't > > change nor break). > > For what it's worth, Bodhi provides a stable API for getting the list > of current Fedora releases. See my Github Action at > https://github.com/sgallagher/get-fedora-releases-action/blob/main/get_fedora_releases.py > (which I use to programmatically keep my CI tests running on all > active releases). The main problem I faced with using Bodhi for this purpose is that in Bodhi a new release gets set to stable state quite 'early'. Specifically, it gets marked as stable before the official release date, and so before the release tree is actually available in the expected location on public mirrors. I used Bodhi as the data source for fedfind for a couple of cycles, but both times this caused problems, which is why I stopped doing that. My long-term plan for making this whole area better is to get releasestream[0] deployed and onboard a bunch of the releng processes to it, but I haven't had any roundtuits to work on that lately. [0] https://pagure.io/fedora-qa/releasestream -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora minimum hardware requirements
Hi, Workstation working group was tracking this: #241 Re-revisit Fedora Workstation minimums https://pagure.io/fedora-workstation/issue/241 But to answer the questions, I think we need to broaden the conversation, hence this email. Only Fedora Workstation edition explicitly states minimum hardware requirements: "Fedora requires a minimum of 20GB disk, 2GB RAM, to install and run successfully. Double those amounts is recommended." https://getfedora.org/en/workstation/download/ Minimum hardware requirements is intended to setup some kind of expectation of performance. The goal isn't the hardware requirement, that's just the means of getting to the goal. So what's the goal? For sure folks need to be able to install it plus some breathing room to install additional software and user data. That gets to the minimum storage space angle. But the CPU, memory, and IO angle are more complex. A completely objective metric would account for the local workload, which we don't know. So we're going to have to come up with a subjective recommendation, i.e. take an educated guess. (I enjoy underscoring that subjective != arbitrary.) How does the minimum hardware requirement achieve the intended goal? And is it testable? We could ask folks to run some workloads on low-CPU, low-memory hardware, and report 'grep -r . /proc/pressure' whenever they think the system is performing worse than expected? Or what? Anyway, this is just to kick off a conversation. Let's see where it goes. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: final link failed: memory exhausted on armv7l
On Wed, Oct 13 2021 at 06:06:50 PM +0200, Björn 'besser82' Esser wrote: What you describe as lto requires a lot of memory is caused by building lto along with non-lto in the same object file requires significantly more memory. For that reason one can disable building non-lto along with lto using the `-f-no-fat-lto-objects` compiler flags instead of `-f-fat-lto-objects`, if and *only IF* the package in question does *NOT* ship static libraries. More background: this default is, of course, backwards. Fedora packages do not generally ship static libraries, so it makes more sense for the few packages that do to opt-in instead of opt-out. Jeff proposed a change to improve that here: https://fedoraproject.org/wiki/Changes/LTOBuildImprovements but he left Red Hat, so it hasn't been implemented. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: final link failed: memory exhausted on armv7l
Thanks, Björn, Dan and Fabio for your comments.
On Wed, 13 Oct 2021 at 18:20, Björn 'besser82' Esser
wrote:
>
> Am Mittwoch, dem 13.10.2021 um 16:51 +0200 schrieb Björn 'besser82'
> Esser:
> > Am Mittwoch, dem 13.10.2021 um 15:44 +0200 schrieb Iñaki Ucar:
> > > Hi,
> > >
> > > RStudio is failing consistently on armv7l on F35 [1, 2] and rawhide
> > > [3, 4] with this message (memory exhausted). The same build on the
> > > same machine (CPU and RAM) succeeds on F34 [5]. Any clue what's going
> > > on? Why rawhide and F35 and not F34? Anything I can do in the SPEC to
> > > fix this?
> > >
> > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159810
> > > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170457
> > > [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159795
> > > [4] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170370
> > > [5] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159829
> >
> >
> > As the package doesn't build any *distributed* static library, you can
> > try to avoid building the linker object files to contain non-lto code:
> >
> > %global optflags %(echo '%{optflags}' | sed -e 's!-ffat-lto-objects!-
> > fno-fat-lto-objects!g')
> >
> > That should drastically cut the amount of memory the linker needs to
> > create the final ELF binary. It doesn't hurt to do that on all arches /
> > releases, as it will also result in significantly shorter build time.
> >
> > Björn
>
>
> Works as suggested in a scratch build:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77177126
And thanks for this. I launched a scratch build to test this too, but
you were faster, so cancelling now. ;-) I'll implement this suggestion
then.
--
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Fedora-35-20211013.n.0 compose check report
No missing expected images. Failed openQA tests: 7/204 (x86_64), 8/141 (aarch64) New failures (same test not failed in Fedora-35-20211012.n.0): ID: 1026602 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/1026602 ID: 1026615 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/1026615 ID: 1026619 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/1026619 ID: 1026620 Test: x86_64 Server-dvd-iso base_package_install_remove URL: https://openqa.fedoraproject.org/tests/1026620 ID: 1026707 Test: aarch64 Server-dvd-iso install_blivet_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1026707 ID: 1026769 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1026769 ID: 1026829 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/1026829 ID: 1026867 Test: aarch64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/1026867 ID: 1026881 Test: aarch64 universal install_blivet_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/1026881 ID: 1026888 Test: aarch64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/1026888 Old failures (same test failed in Fedora-35-20211012.n.0): ID: 1026662 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1026662 ID: 1026678 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1026678 ID: 1026708 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1026708 ID: 1026774 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1026774 ID: 1026880 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1026880 Soft failed openQA tests: 3/204 (x86_64), 2/141 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-35-20211012.n.0): ID: 1026636 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1026636 ID: 1026679 Test: x86_64 Silverblue-dvd_ostree-iso gedit URL: https://openqa.fedoraproject.org/tests/1026679 ID: 1026690 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1026690 ID: 1026763 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1026763 ID: 1026781 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1026781 Passed openQA tests: 194/204 (x86_64), 130/141 (aarch64) New passes (same test not passed in Fedora-35-20211012.n.0): ID: 1026649 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1026649 ID: 1026711 Test: aarch64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1026711 ID: 1026713 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/1026713 ID: 1026751 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1026751 Skipped non-gating openQA tests: 1 of 345 Installed system changes in test x86_64 Server-dvd-iso install_default_upload: System load changed from 0.14 to 0.41 Previous test data: https://openqa.fedoraproject.org/tests/1024556#downloads Current test data: https://openqa.fedoraproject.org/tests/1026589#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Used swap changed from 6 MiB to 3 MiB 1 services(s) added since previous compose: geoclue.service System load changed from 1.01 to 0.63 Previous test data: https://openqa.fedoraproject.org/tests/1024600#downloads Current test data: https://openqa.fedoraproject.org/tests/1026633#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 3 packages(s) added since previous compose: breeze-gtk-gtk4, gtk4, xdg-desktop-portal-gnome System load changed from 0.63 to 0.74 Previous test data: https://openqa.fedoraproject.org/tests/1024624#downloads Current test data: https://openqa.fedoraproject.org/tests/1026657#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: 3 packages(s) added since previous compose: breeze-gtk-gtk4, gtk4, xdg-desktop-portal-gnome System load changed from 1.01 to 1.38 Previous test data: https://openqa.fedoraproject.org/tests/1024625#downloads Current test data: https://openqa.fedoraproject.org/tests/1026658#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso
[Test-Announce] Fedora Linux 35 Final is NO-GO
Due to outstanding blocker bugs[1], we do not have an F35 Final RC. As a result, F35 Final is NO-GO by default and tomorrow's Go/No-Go meeting is cancelled. The next Fedora Linux 35 Final Go/No-Go meeting[2] will be held at 1700 UTC on Thursday 21 October in #fedora-meeting. We will aim for the "target date #1" milestone of 26 October. The release schedule[3] has been updated accordingly. [1] https://qa.fedoraproject.org/blockerbugs/milestone/35/final/buglist [2] https://calendar.fedoraproject.org/meeting/10102/ [3] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: final link failed: memory exhausted on armv7l
Building with lto disabled is a bad idea, as Fedora intentionally enabled lto by default. What you describe as lto requires a lot of memory is caused by building lto along with non-lto in the same object file requires significantly more memory. For that reason one can disable building non-lto along with lto using the `-f-no-fat-lto-objects` compiler flags instead of `-f-fat-lto-objects`, if and *only IF* the package in question does *NOT* ship static libraries. Björn signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: final link failed: memory exhausted on armv7l
Am Mittwoch, dem 13.10.2021 um 16:51 +0200 schrieb Björn 'besser82'
Esser:
> Am Mittwoch, dem 13.10.2021 um 15:44 +0200 schrieb Iñaki Ucar:
> > Hi,
> >
> > RStudio is failing consistently on armv7l on F35 [1, 2] and rawhide
> > [3, 4] with this message (memory exhausted). The same build on the
> > same machine (CPU and RAM) succeeds on F34 [5]. Any clue what's going
> > on? Why rawhide and F35 and not F34? Anything I can do in the SPEC to
> > fix this?
> >
> > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159810
> > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170457
> > [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159795
> > [4] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170370
> > [5] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159829
>
>
> As the package doesn't build any *distributed* static library, you can
> try to avoid building the linker object files to contain non-lto code:
>
> %global optflags %(echo '%{optflags}' | sed -e 's!-ffat-lto-objects!-
> fno-fat-lto-objects!g')
>
> That should drastically cut the amount of memory the linker needs to
> create the final ELF binary. It doesn't hurt to do that on all arches /
> releases, as it will also result in significantly shorter build time.
>
> Björn
Works as suggested in a scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=77177126
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: final link failed: memory exhausted on armv7l
Hi Iñaki, Iñaki Ucar writes: > Hi, > > RStudio is failing consistently on armv7l on F35 [1, 2] and rawhide > [3, 4] with this message (memory exhausted). The same build on the > same machine (CPU and RAM) succeeds on F34 [5]. Any clue what's going > on? Why rawhide and F35 and not F34? Anything I can do in the SPEC to > fix this? You could try to build without LTO, iirc that requires a lot of memory during linking. And if that doesn't help: ExcludeArch… Hope this helps, Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: final link failed: memory exhausted on armv7l
On Wed, Oct 13, 2021 at 3:45 PM Iñaki Ucar wrote: > > Hi, > > RStudio is failing consistently on armv7l on F35 [1, 2] and rawhide > [3, 4] with this message (memory exhausted). The same build on the > same machine (CPU and RAM) succeeds on F34 [5]. Any clue what's going > on? Why rawhide and F35 and not F34? Anything I can do in the SPEC to > fix this? I think you could try either reducing LTO parallelism (-flto=1 instead of -flto=auto, e.g. by overriding "%_lto_cflags"), or by reducing debuginfo verbosity (compiling with -g1 or even -g0 instead of with -g, I think you need to "sed" the C(XX)FLAGS in this case). Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: final link failed: memory exhausted on armv7l
Am Mittwoch, dem 13.10.2021 um 15:44 +0200 schrieb Iñaki Ucar:
> Hi,
>
> RStudio is failing consistently on armv7l on F35 [1, 2] and rawhide
> [3, 4] with this message (memory exhausted). The same build on the
> same machine (CPU and RAM) succeeds on F34 [5]. Any clue what's going
> on? Why rawhide and F35 and not F34? Anything I can do in the SPEC to
> fix this?
>
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159810
> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170457
> [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159795
> [4] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170370
> [5] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159829
As the package doesn't build any *distributed* static library, you can
try to avoid building the linker object files to contain non-lto code:
%global optflags %(echo '%{optflags}' | sed -e 's!-ffat-lto-objects!-
fno-fat-lto-objects!g')
That should drastically cut the amount of memory the linker needs to
create the final ELF binary. It doesn't hurt to do that on all arches /
releases, as it will also result in significantly shorter build time.
Björn
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Package owner required for ImageMagick
On 2021-10-13 05:13, Troy Curtis Jr wrote: On Tue, Oct 12, 2021, 10:14 PM Luya Tshimbalanga wrote: On 2021-10-12 15:37, Michael Cronenworth wrote: > Hi all, > > I would like to put out a public call for a new primary owner for > ImageMagick[1]. > > I only picked it up a few years ago to prevent it from being orphaned, > but I no longer have the desire or time to maintain it. > > Thanks, > Michael > > [1] https://src.fedoraproject.org/rpms/ImageMagick > Hello Michael, I will take that package because it is used by Fedora Design team for conversion and some applications depend on it. Luya, if you'd also like some help, I'd be happy to co-maintain this with you. I find myself using it in various scenarios. Troy Thanks, Troy. I added you to the list. -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
final link failed: memory exhausted on armv7l
Hi, RStudio is failing consistently on armv7l on F35 [1, 2] and rawhide [3, 4] with this message (memory exhausted). The same build on the same machine (CPU and RAM) succeeds on F34 [5]. Any clue what's going on? Why rawhide and F35 and not F34? Anything I can do in the SPEC to fix this? [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159810 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170457 [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159795 [4] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170370 [5] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159829 Regards, -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Authselect Mandatory (System-Wide Change proposal)
On Wed, Oct 13 2021 at 10:22:14 AM +0200, Hans de Goede wrote: Making what IMHO is a poor default of always using sssd everywhere hardcoded even deeper into Fedora seems like a bad idea to me. I think we can fix this at the same time. Make authselect default to its minimal profile rather than its sssd profile, and make realmd responsible for running authselect to enable the sssd profile when it is required. I think realmd is already capable of installing the dependencies it needs when enabled, right? This way, most Fedora systems would no longer run sssd, but enabling enterprise login would not require manual configuration for those who need it. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Fedora 35 Branched 20211013.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 35 Branched 20211013.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20211010.n.0: anaconda-35.22.2-1.fc35.src, 20211013.n.0: anaconda-35.22.2-2.fc35.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/35 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20211013.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20211013.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20211013.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20211013.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20211013.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20211013.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20211013.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Woah! [Thanks, Nest sponsors]
On Wednesday, 13 October 2021 at 14:39, Stephen Snow wrote: > On Wed, 2021-10-13 at 14:33 +0200, Dominik 'Rathann' Mierzejewski > wrote: [...] > I got the email with tracking info two days prior to arrival of swag. > but in between reg and ship, no communication. Alright, I'll remain patient then. Thanks for sharing your story. > > Nothing yet. :( > > Hope it arrives for you soon, Thanks! I'll keep my fingers crossed. :) Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Woah! [Thanks, Nest sponsors]
On Wed, Oct 13, 2021 at 02:33:19PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 13 October 2021 at 13:08, Luna Jernberg wrote: > > You had to register at a website during the event, > > That I did. On August 7th, I received an e-mail with a promo code to > enter at https://coolstuff.redhat.com/promo/fedora which I did, but I > haven't heard from them since. Same with me. > > got an email with > > tracking information from both Fedex and Red Hat > > Nothing yet. :( Nothing. Are swag packs sent in batches? -- Tomasz TorczOnly gods can safely risk perfection, to...@pipebreaker.pl it's a dangerous thing for a man. — Alia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-36-20211013.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 1/16 (x86_64), 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-36-20211012.0): ID: 1026546 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/1026546 ID: 1026561 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1026561 Passed openQA tests: 15/16 (x86_64), 14/15 (aarch64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: System load changed from 0.19 to 0.30 Previous test data: https://openqa.fedoraproject.org/tests/1025764#downloads Current test data: https://openqa.fedoraproject.org/tests/1026539#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: System load changed from 0.11 to 0.22 Previous test data: https://openqa.fedoraproject.org/tests/1025775#downloads Current test data: https://openqa.fedoraproject.org/tests/1026550#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Woah! [Thanks, Nest sponsors]
On Wed, 2021-10-13 at 14:33 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 13 October 2021 at 13:08, Luna Jernberg wrote: > > You had to register at a website during the event, > > That I did. On August 7th, I received an e-mail with a promo code to > enter at https://coolstuff.redhat.com/promo/fedora which I did, but I > haven't heard from them since. > I got the confirmation of regsitration almost immediately after registering. > > got an email with > > tracking information from both Fedex and Red Hat > I got the email with tracking info two days prior to arrival of swag. but in between reg and ship, no communication. > Nothing yet. :( > > Regards, > Dominik > -- Hope it arrives for you soon, Stephen > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess > Irulan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Woah! [Thanks, Nest sponsors]
On Wednesday, 13 October 2021 at 13:08, Luna Jernberg wrote: > You had to register at a website during the event, That I did. On August 7th, I received an e-mail with a promo code to enter at https://coolstuff.redhat.com/promo/fedora which I did, but I haven't heard from them since. > got an email with > tracking information from both Fedex and Red Hat Nothing yet. :( Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package owner required for ImageMagick
On Tue, Oct 12, 2021, 10:14 PM Luya Tshimbalanga wrote: > > On 2021-10-12 15:37, Michael Cronenworth wrote: > > Hi all, > > > > I would like to put out a public call for a new primary owner for > > ImageMagick[1]. > > > > I only picked it up a few years ago to prevent it from being orphaned, > > but I no longer have the desire or time to maintain it. > > > > Thanks, > > Michael > > > > [1] https://src.fedoraproject.org/rpms/ImageMagick > > > Hello Michael, > > I will take that package because it is used by Fedora Design team for > conversion and some applications depend on it. > Luya, if you'd also like some help, I'd be happy to co-maintain this with you. I find myself using it in various scenarios. Troy > -- > Luya Tshimbalanga > Fedora Design Team > Fedora Design Suite maintainer > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: API endpoint listing ISOs and checksums for Fedora releases and Rawhide?
On Tue, Oct 12, 2021 at 2:42 PM Frantisek Zatloukal wrote: > > Hi, > > in testcloud ( > https://pagure.io/testcloud/blob/master/f/testcloud/util.py#_100 ), I am > using adam's openqa nightlies.json for rawhide/branched: > https://openqa.fedoraproject.org/nightlies.json (this isn't a "stable api") > > and https://getfedora.org/releases.json for stable releases. > > For programmatically determining which are the current fedora releases, I am > using oraculum's https://packager-dashboard.fedoraproject.org/api/v1/releases > (this wouldn't change nor break). For what it's worth, Bodhi provides a stable API for getting the list of current Fedora releases. See my Github Action at https://github.com/sgallagher/get-fedora-releases-action/blob/main/get_fedora_releases.py (which I use to programmatically keep my CI tests running on all active releases). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Removal of quagga from Fedora
On 10/12/21 4:13 PM, Neal Gompa wrote: > On Tue, Oct 12, 2021 at 7:54 AM Michal Ruprich wrote: >> Hi, >> >> I am planning to start a retirement process for quagga in Fedora. The >> package is very outdated since the upstream is dead for a couple of >> years. There is a replacement in the form of FRR that can be used in a >> very similar fashion and it has active upstream with a lot of >> development going on. >> >> This is more of an FYI message to let you know and to see if anyone >> would miss quagga. >> > Only tears shed for the funny name. Alas, FRR is just too boring! FRR still has zebra at least :D -- Michal Ruprich Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20211013.n.0 changes
OLD: Fedora-Rawhide-20211012.n.0 NEW: Fedora-Rawhide-20211013.n.0 = SUMMARY = Added images:3 Dropped images: 0 Added packages: 1 Dropped packages:0 Upgraded packages: 98 Downgraded packages: 0 Size of added packages: 141.80 MiB Size of dropped packages:0 B Size of upgraded packages: 6.70 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -95.12 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Python_Classroom live x86_64 Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20211013.n.0.iso Image: Server raw-xz aarch64 Path: Server/aarch64/images/Fedora-Server-Rawhide-20211013.n.0.aarch64.raw.xz Image: Python_Classroom raw-xz aarch64 Path: Labs/aarch64/images/Fedora-Python-Classroom-Rawhide-20211013.n.0.aarch64.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: python3.11-3.11.0~a1-1.fc36 Summary: Version 3.11 of the Python interpreter RPMs:python3.11 Size:141.80 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: PyQt-builder-1.12.1-1.fc36 Old package: PyQt-builder-1.11.0-1.fc36 Summary: The PEP 517 compliant PyQt build system RPMs: PyQt-builder Size: 86.45 KiB Size change: 1.42 KiB Changelog: * Tue Oct 12 2021 Scott Talbert - 1.12.1-1 - Update to new upstream release 1.12.1 (#2013246) Package: Zim-0.74.2-1.fc36 Old package: Zim-0.74.1-1.fc36 Summary: Desktop wiki & notekeeper RPMs: Zim Size: 1.82 MiB Size change: 7.57 KiB Changelog: * Wed Oct 13 2021 Robin Lee 0.74.2-1 - Update to 0.74.2 Package: anaconda-36.7-1.fc36 Old package: anaconda-36.6-1.fc36 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui anaconda-widgets anaconda-widgets-devel Size: 20.60 MiB Size change: 32.92 KiB Changelog: * Tue Oct 12 2021 Martin Kolman - 36.7-1 - Cache the parsed content of the help mapping files (vponcova) - Use specific help directories (vponcova) - Remove the default_help_pages configuration option (vponcova) - Remove the helpFile attribute (vponcova) - Implement the unified help support (vponcova) - Mention manual journal dumps for mising logs (vslavik) - Revert "Install kbd-legacy if keyboard layout is "fi" (#1955793)" (vponcova) Package: anaconda-user-help-26.2-1.fc36 Old package: anaconda-user-help-26.1-14.fc35 Summary: Content for the Anaconda built-in help system RPMs: anaconda-user-help Size: 294.27 KiB Size change: 937 B Changelog: * Mon Oct 04 2021 Vendula Poncova - 26.2-1 - Add mapping files for the unified help support (vponcova) - Install help files to the fedora directory (vponcova) Package: ansible-collection-community-general-3.8.0-1.fc36 Old package: ansible-collection-community-general-3.7.0-1.fc36 Summary: Modules and plugins supported by Ansible community RPMs: ansible-collection-community-general Size: 1.48 MiB Size change: 14.06 KiB Changelog: * Tue Oct 12 2021 Maxwell G (@gotmax23) - 0.14.6-1 - 0.14.6 Package: awscli-1.20.60-1.fc36 Old package: awscli-1.20.58-1.fc36 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 2.11 MiB Size change: 13.73 KiB Changelog: * Tue Oct 12 2021 Gwyn Ciesla - 1.20.59-1 - 1.20.59 * Tue Oct 12 2021 Gwyn Ciesla - 1.20.60-1 - 1.20.60 Package: azure-cli-2.29.0-2.fc36 Old package: azure-cli-2.28.0-4.fc36 Summary: Microsoft Azure Command-Line Tools RPMs: azure-cli python3-azure-cli-core python3-azure-cli-telemetry python3-azure-cli-testsdk Size: 3.68 MiB Size change: 76.90 KiB Changelog: * Tue Oct 12 2021 Major Hayden 2.29.0-1 - Update to 2.29.0 * Tue Oct 12 2021 Major Hayden 2.29.0-2 - Allow humanfriendly 8.2 or higher Package: chromium-94.0.4606.81-1.fc36 Old package: chromium-94.0.4606.71-1.fc36 Summary: A WebKit (Blink) powered web browser that Google doesn't want you to use RPMs: chrome-remote-desktop chromedriver chromium chromium-common chromium-headless Size: 428.18 MiB Size change: -139.93 MiB Changelog: * Wed Oct 06 2021 Tom Callaway - 94.0.4606.71-2 - add official_build flag - apply upstream patch to handle nullptr correctly in PartitionGetSizeEstimate() * Fri Oct 08 2021 Tom Callaway - 94.0.4606.81-1 - update to 94.0.4606.81 Package: cyrus-sasl-2.1.27-16.fc36 Old package: cyrus-sasl-2.1.27-15.fc36 Summary: The Cyrus SASL library RPMs: cyrus-sasl cyrus-sasl-devel cyrus-sasl-gs2 cyrus-sasl-gssapi cyrus-sasl-ldap cyrus-sasl-lib cyrus-sasl-md5 cyrus-sasl-ntlm cyrus-sasl-plain cyrus-sasl-scram cyrus-sasl-sql Size: 6.90 MiB Size change: 6.28 KiB Changelog: * Tue Oct 12 2021 Simo Sorce -
Re: GNOME 42 - Initial Software port to GTK4 (MR!944)
On Tue, Oct 12, 2021 at 9:05 PM Reon Beon via devel wrote: > > https://www.youtube.com/watch?v=OapTyDo2hk4 > > GNOME GTK4 PortInitiative (ISSUE26) > https://gitlab.gnome.org/GNOME/Initiatives/-/issues/26 I just want to say: cool video! I like this method of demoing the work that the team has been doing. That said, I suggest in the future that you provide a little more context in the body of the email. I can easily see this being misinterpreted as a spam message. I don't want anyone to miss great content like this! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Woah! [Thanks, Nest sponsors]
You had to register at a website during the event, got an email with tracking information from both Fedex and Red Hat On Wed, Oct 13, 2021 at 1:06 PM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Tuesday, 12 October 2021 at 16:03, Luna Jernberg wrote: > > On Tue, Oct 12, 2021 at 3:29 PM Michael J Gruber > > wrote: > > > > > Today that special package for Nest participants arrived here. > > > Back then I thought: "Nice, a few stickers." Today, after opening the > > > package, I thought: "Woah!". [ No spoilers here ;) ] > > > > > > So, thanks to anyone who made possible Nest as well as this form of > > > community appreciation! > > > > > > [posting it here where I learned about Nest; feel free to redirect] > > > > Getting mine on Thursday or Friday this week > > Curious. How do you know when you're getting it? I received no > information at all after registering, so I don't even know if I'm > getting one. > > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Woah! [Thanks, Nest sponsors]
On Tuesday, 12 October 2021 at 16:03, Luna Jernberg wrote: > On Tue, Oct 12, 2021 at 3:29 PM Michael J Gruber > wrote: > > > Today that special package for Nest participants arrived here. > > Back then I thought: "Nice, a few stickers." Today, after opening the > > package, I thought: "Woah!". [ No spoilers here ;) ] > > > > So, thanks to anyone who made possible Nest as well as this form of > > community appreciation! > > > > [posting it here where I learned about Nest; feel free to redirect] > > Getting mine on Thursday or Friday this week Curious. How do you know when you're getting it? I received no information at all after registering, so I don't even know if I'm getting one. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20211013.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20211012.0): ID: 1026108 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1026108 ID: 1026116 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1026116 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Claiming ownership of a dropped package
On Wed, Oct 13, 2021 at 10:59 AM Artur Frenszek-Iwicki < s...@fedoraproject.org> wrote: > > In the docs there is a section about Claiming Ownership of an Orphaned > Package > You were looking almost in the right place. There's a separate section > about claiming retired packages. [1] > I missed that. Thank you Artur! Now I know what to do next. > > tl;dr: If it was retired for more than 8 weeks, it needs to go through the > Package Review process again. > After the review is approved, instead of filing a "new repo" ticket, you > need to file a "claim ownership" ticket. > > [1] > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Peter Kotvan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Claiming ownership of a dropped package
> In the docs there is a section about Claiming Ownership of an Orphaned Package You were looking almost in the right place. There's a separate section about claiming retired packages. [1] tl;dr: If it was retired for more than 8 weeks, it needs to go through the Package Review process again. After the review is approved, instead of filing a "new repo" ticket, you need to file a "claim ownership" ticket. [1] https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Claiming ownership of a dropped package
Hello folks! I would like to become a maintainer/packager of package scrot [1] that was dropped [2] last year. (Disclaimer: I have experience with maintaining some packages in COPR but not with actually maintaining packages in the official Fedora repos. I'm completely new to this.) In the docs there is a section about Claiming Ownership of an Orphaned Package [3] but I'm not sure whether this still applies if the package was already dropped. Should I follow the New Package Process for New Contributors [4] as if the package was completely new? Thanks in advance for any help. Regards [1] https://github.com/resurrecting-open-source-projects/scrot [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YCLZFYRTA3GGTPBQ7PLDN4OGXE6MATHO/ [3] https://docs.fedoraproject.org/en-US/package-maintainers/Package_Orphaning_Process/#claiming_ownership_of_an_orphaned_package [4] https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/ -- Peter Kotvan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: bodhi updates skipping updates-testing entirely
On Tue, Oct 12, 2021 at 10:49 AM Miro Hrončok wrote:
>
> On 12. 10. 21 10:35, Fabio Valentini wrote:
> > Hi everybody,
> >
> > There seems to be some inconsistency with how our update workflow
> > currently works. When an update gets enough positive karma "pre-push"
> > (still in "pending → testing" state) so that it can be pushed to
> > stable, bodhi changes its state to ("pending → stable"), making it
> > skip the "updates-testing" repository entirely.
> >
> > That isn't that big of a problem most of the time, since "fedora" /
> > "updates" and "updates-testing" repositories are composed daily, but
> > during freezes, this leads to the weird problem that possibly
> > important updates get stuck in a state where they are available from
> > *no repository at all*.
> >
> > For example, this now happened to the flatpak 1.12.1 update:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2021-256d5ee9fe
> >
> > It got +5 karma before the update was even available from the
> > updates-testing repository (presumably users tested the builds from
> > koji directly - I hope?), so it got pushed to "stable" by bodhi. But
> > now it's been sitting in "pending → stable" state for two days because
> > of the final freeze, making the update available from *no repository*,
> > while it's a pretty big update (1.11 → 1.12) and also contains
> > security fixes and bug fixes for Steam - maybe it should get a freeze
> > exception now, otherwise it will only become available as a 0day
> > update.
> >
> > So, I wonder, should updates always be allowed to skip being in the
> > "updates-testing" repository entirely? There's probably good reasons
> > for it sometimes (for example, time-critical security updates, i.e.
> > firefox, kernel, etc.), but in the general case, not giving regular
> > "non-koji" update testers any time to test updates before they're
> > pushed to stable seems suboptimal.
> >
> > Maybe updates should only be able to be pushed to stable by karma if
> > they are in the "testing" state, and need a manual "submit to stable"
> > button push if they're still "pending"? That should be both fairly
> > straightforward to implement in bodhi, and should allow for both the
> > "pending → stable fast-track, this is urgent" and the "lets wait and
> > let it sit in updates-testing for at least one day" scenarios.
> >
> > What do you think?
>
> This could also be solved by implementing the "pending -> stable" action to
> always behave like "pending -> testing -> stable", rather than waiting an
> extra
> day, no?
Yeah, that's effectively what I meant to say by what I wrote.
Since pushes happen once per day (if everything works), packages would
spend at least one day in the "testing" state, which is better than
"no time" in most cases, I think.
Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Authselect Mandatory (System-Wide Change proposal)
Hi,
On 10/12/21 5:32 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory
>
> == Summary ==
> This change wants to make authselect required to configure
> authentication and identity sources and forcefully update
> non-authselect configuration to the sssd authselect profile to
> eliminate any existing non-authselect setups.
>
> Even though it will still be possible to manually modify the
> configuration, users that require special configuration should create
> and use custom authselect profile.
>
> ''Authselect is available in Fedora since Fedora 27 and enabled by
> default on new installations since Fedora 28. Authconfig compatibility
> tool was removed from Fedora 35 as a
> [[Changes/RemoveAuthselectCompatPackage|system wide change page]]. It
> is now well accepted by the community as well as the package
> maintainers. The package maintainers have repeatedly requested to make
> authselect mandatory for the users which lead to creation of
> [https://bugzilla.redhat.com/show_bug.cgi?id=2000936 this bugzilla].''
>
> == Owner ==
> * Name: [[User:pbrezina|Pavel Březina]]
> * Email: pbrez...@redhat.com
>
>
> == Detailed Description ==
> The following components must be updated to make authselect mandatory:
> * authselect
> * pam
> * glibc
> * packages that use it: systemd, ecryptfs, nss-mdns and fingerprint.
>
>
> Required changes:
> # Remove user-nsswitch.conf functionality from authselect
> # Move ownership of /etc/nsswitch.conf and /etc/pam.d/{system-auth,
> password-auth, smartcard-auth, fingerprint-auth, postlogin} to
> authselect from glibc and pam
> # Require authselect in pam
> # Remove non-authselect support from systemd, ecryptfs, nss-mdns and
> fingerprint
> # Select default profile when authselect is installed
> # Select default profile when authselect is upgraded
>
> === Remove user-nsswitch.conf functionality ===
> File /etc/authselect/user-nsswitch.conf was introduced in authselect
> to allow partial user modifications of nsswitch.conf without the need
> to create a custom authselect profile. The main driver was to enable
> modules that are not included in authselect such as systemd-resolved
> and nss-mdns.
>
> This however made the situation more confusing to users and it is not
> desirable any more if authselect is mandatory.
>
> '''Authselect will drop user-nsswitch.conf functionality and instead
> add more nsswitch modules to existing profiles and be more open about
> future inclusion requests.'''
>
> === Own /etc/nsswitch.conf and /etc/pam.d/{system-auth, password-auth,
> smartcard-auth, fingerprint-auth, postlogin} instead of glibc and pam
> ===
> File /etc/nsswitch.conf is currently owned by glibc. It will be now
> owned by authselect and removed from glibc.
>
> PAM configuration generated by authselect is currently owned by pam.
> It will be now owned by authselect and removed from pam.
>
> ''Note: that config-util and other will still be owned by pam since
> these files are not generated by authselect.''
>
> '''All files that are generated by authselect are now owned by authselect.'''
>
> === Require authselect in pam ===
> The pam package will require authselect. This will tie pam and
> authselect together and it will be impossible to uninstall authselect
> without uninstalling pam which fundamentally makes authselect a hard
> dependency on each system.
>
> '''This step will make it impossible to uninstall authselect, making
> it always available to RPM packages.'''
>
> === Remove non-authselect support from systemd, ecryptfs, nss-mdns and
> fingerprint ===
> '''Non-authselect configuration support will be dropped in these packages.'''
>
> === Select default profile when authselect is installed ===
> If authselect configuration is not detected and this is a new
> installation of authselect it will automatically select the
> distribution default authselect profile by calling authselect select
> --force with distribution specific parameters.
>
> If existing authselect configuration is detected (perhaps from
> previous installation), it will be updated (current behavior).
>
> This makes sure that if authselect is installed (which is always) a
> configuration is created.
> Select default profile when authselect is upgraded
> If authselect is upgraded from an older version and non-authselect
> configuration is detected, it will forcefully overwrite it with
> distribution defaults by calling authselect select --force with
> distribution specific parameters.
>
> This is a one time event so if someone does not want to use
> authselect, it remains possible. However, non-authselect
> configurations will not be supported by RPM packages mentioned above.
>
> If authselect is upgraded on a system that already is configured by
> it, the update process remains the same as it is now.
>
> '''This step will forcefully update existing installations to
> authselect configuration. It is a one time event and opt-out is still
> possible but no lon
Re: F36 Change: Make Authselect Mandatory (System-Wide Change proposal)
Dne 12. 10. 21 v 17:45 Neal Gompa napsal(a): On Tue, Oct 12, 2021 at 11:33 AM Ben Cotton wrote: === 1. It is difficult to deliver updates to configurations === FIles /etc/nsswitch.conf and /etc/pam.d/* are distributed as %config(noreplace) which means that they are configuration files and are only installed if they are not yet present. If they are present then they are never overwritten with package updates, instead an *.rpmnew file is created and the update responsibility is left completely to the user. It is done this way to prevent overwriting user changes configurations. But at the same time it means that even configurations that are not modified by the users can not be changed so we can not deliver fixes and changes efficiently. It is only possible through difficult scriptlets. As an example, we can show this bugzilla where a change in Gnome required an update to PAM otherwise the user could not authenticate. Delivering the change was easy with authselect, but difficult for non-authselect systems. Authselect already knows how the resulting configuration should look and does not risk overriding user configuration. Making it mandatory will help distribute important updates to nsswitch and PAM configuration. PAM gained support for systemd-style overlay configuration some time ago. Actually a number of core system components did, if the libeconf dependency is turned on. Instead of forcing authselect, we should probably make sure base functional configuration is shipped in something like /usr/share/pam/pam.d or something like that. Not that I think authselect is bad, but I think it's a bad hammer to solve this problem. Right, the best would be if all the "configuration" files were removed from /etc. I have never had a need to change the configurations, but I had to fix those files several times. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20211013.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20211012.0): ID: 1025863 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1025863 ID: 1025871 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1025871 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
