Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)

[ElXreno]

Is earlyoom disabled on this system? It should send SIGTERM to
something in this case - which is not the best UX as a hint that an
adjustment needs to be made. But I want to make sure there isn't
something else going wrong.
Yes, it's off. And I have an assumption that earlyoom may not have time 
to work if there is a lot of pressure on the memory.

___
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

Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)

[Chris Murphy]

On Tue, Jan 12, 2021 at 12:14 AM ElXreno  wrote:
>
> > Does this reduce your concern?
> In a way, yes. Most of the time memory will be compressible, I agree,
> but there are non-compressible data, and I'm only concerned about that.
>
> In my opinion, it's better not to set the zram size to 100% for
> everyone. Whoever is sure that their data will be compressible can set
> it to 100%.
>
> > Are you sure that this data is compressed in memory as well as the
> > on-disk encoding? The editing operations themselves surely operate on
> > uncompressed data, and then it's compressed upon being written to
> > disk.
> I'm not sure. But I've had a few times where zram didn't compress
> anything and ended up freezing the system completely.

Is earlyoom disabled on this system? It should send SIGTERM to
something in this case - which is not the best UX as a hint that an
adjustment needs to be made. But I want to make sure there isn't
something else going wrong.


-- 
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

Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)

[ElXreno]

Does this reduce your concern?
In a way, yes. Most of the time memory will be compressible, I agree, 
but there are non-compressible data, and I'm only concerned about that.


In my opinion, it's better not to set the zram size to 100% for 
everyone. Whoever is sure that their data will be compressible can set 
it to 100%.



Are you sure that this data is compressed in memory as well as the
on-disk encoding? The editing operations themselves surely operate on
uncompressed data, and then it's compressed upon being written to
disk.
I'm not sure. But I've had a few times where zram didn't compress 
anything and ended up freezing the system completely.

___
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

[389-devel] 389 DS nightly 2021-01-12 - 94% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2021/01/12/report-389-ds-base-2.0.1-20210112gitacaf2235c.fc33.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)

[Chris Murphy]

On Mon, Jan 11, 2021 at 1:55 PM ElXreno  wrote:

> I think it's a bad idea. It is better to make `zram-fraction` equal to
> 0.8 or 0.9, but not 1.0.

Just to clarify. zram-fraction 1.0 means the zram *device size* will
be equal to RAM, capped at 8G. The actual amount of memory used is
zero, until the kernel starts to evict dirty pages to swap, where they
are then compressed. And the maximum amount of RAM due to compression
would be predicated on compression ratio. If we assume a conservative
2:1 ratio (compression results in 50% of original size), the max ram
would be the lesser of 4G or 50% of RAM.

Does this reduce your concern?

80% might still be reasonable, and still pretty conservative.

> For example, if you run Darktable, load a floating-point TIFF image into
> it, and try to export it, on systems with little RAM, it will fill both
> RAM itself and zram, and cause the system to freeze completely because
> the memory is almost incompressible.
> Also, other data (video editors, for example) which are not compressible
> can get into RAM.

Are you sure that this data is compressed in memory as well as the
on-disk encoding? The editing operations themselves surely operate on
uncompressed data, and then it's compressed upon being written to
disk.

-- 
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

[Bug 1914367] perl-Net-HTTP-6.20 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914367



--- Comment #5 from Fedora Update System  ---
FEDORA-2021-cc1cde9ba7 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-cc1cde9ba7`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-cc1cde9ba7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: How did this file end up in the lookaside cache?

[Michael Schwendt]

On Tue, 12 Jan 2021 00:13:21 +, Cristian Morales Vega wrote:

> Not sure exactly when, but it looks like me creating
> https://src.fedoraproject.org/rpms/doxygen/pull-request/9 has
> triggered a process uploading the tarball to the lookaside cache.
> 
> The tarball inside
> https://kojipkgs.fedoraproject.org//work/tasks/5674/59445674/doxygen-1.9.1-1.fc34.src.rpm
> is fine. But when I later tried to build the same sources in copr I
> got a 404 error when downloading the tarball from the lookaside cache
> (https://download.copr.fedorainfracloud.org/results/reddwarf/personal/srpm-builds/01876339/builder-live.log.gz).
> The thing is that
> https://src.fedoraproject.org/lookaside/pkgs/doxygen/doxygen-1.9.1.src.tar.gz/sha512/a84fbea1874921317b58345c53fc4eac0382c9e593f0e1ee899a31e67ead3fd12b2da8145b37e2e09d665e28d060e6717c92de7e8d0a31fc5f24fdcc4715f54d/doxygen-1.9.1.src.tar.gz
> is a 19 MiB monster (instead of the 5 MiB of the real tarball) with,
> obviously, the wrong hash.
> 
> How did this happen? Is it "expected" even if I don't understand it?
> Is it a bug somewhere?

The tarball you refer to first is gzipped and matches the commit diff for
the "sources" file:

$ sha512sum doxygen-1.9.1.src.tar.gz 
637496c549a4a150cfaeb5d4913de512262145ecd7d455d7b7f3dd68f9416e47d931a6c1efd8a17d931e4baf4a8a9f2ed21124664003b123b6f89ca4abf263ed
  doxygen-1.9.1.src.tar.gz

The later one ends with .tar.gz but is uncompressed and matches the "sources"
file in Fedora dist-git:

$ file doxygen-1.9.1.src.tar.gz
doxygen-1.9.1.src.tar: POSIX tar archive
$ grep doxygen sources
SHA512 (doxygen-1.9.1.src.tar.gz) = 
a84fbea1874921317b58345c53fc4eac0382c9e593f0e1ee899a31e67ead3fd12b2da8145b37e2e09d665e28d060e6717c92de7e8d0a31fc5f24fdcc4715f54d
$ sha512sum doxygen-1.9.1.src.tar.gz
a84fbea1874921317b58345c53fc4eac0382c9e593f0e1ee899a31e67ead3fd12b2da8145b37e2e09d665e28d060e6717c92de7e8d0a31fc5f24fdcc4715f54d
  doxygen-1.9.1.src.tar

So, it seems a Fedora maintainer of doxygen has uploaded the huge 
uncompressed tarball to the lookaside cache accidentally or unknowingly
because of its .gz extension.
___
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

Re: How did this file end up in the lookaside cache?

[clime]

On Tue, 12 Jan 2021 at 01:14, Cristian Morales Vega
 wrote:
>
> Not sure exactly when, but it looks like me creating
> https://src.fedoraproject.org/rpms/doxygen/pull-request/9 has
> triggered a process uploading the tarball to the lookaside cache.
>
> The tarball inside
> https://kojipkgs.fedoraproject.org//work/tasks/5674/59445674/doxygen-1.9.1-1.fc34.src.rpm
> is fine. But when I later tried to build the same sources in copr I
> got a 404 error when downloading the tarball from the lookaside cache
> (https://download.copr.fedorainfracloud.org/results/reddwarf/personal/srpm-builds/01876339/builder-live.log.gz).
> The thing is that
> https://src.fedoraproject.org/lookaside/pkgs/doxygen/doxygen-1.9.1.src.tar.gz/sha512/a84fbea1874921317b58345c53fc4eac0382c9e593f0e1ee899a31e67ead3fd12b2da8145b37e2e09d665e28d060e6717c92de7e8d0a31fc5f24fdcc4715f54d/doxygen-1.9.1.src.tar.gz
> is a 19 MiB monster (instead of the 5 MiB of the real tarball) with,
> obviously, the wrong hash.
>
> How did this happen? Is it "expected" even if I don't understand it?
> Is it a bug somewhere?

It seems, the package maintainer himself updated to 1.9.1 and uploaded
the new sources in about the same time (maybe slightly later) you
opened the pull request.

https://src.fedoraproject.org/rpms/doxygen/commits/master

That probably led to the confusion. Lookaside cache is not populated
just by opening a pull request :).

Best Regards
clime

> ___
> 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
___
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

[Bug 1912612] perl-HTTP-Cookies-6.10 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1912612

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-HTTP-Cookies-6.10-1.fc |perl-HTTP-Cookies-6.10-1.fc
   |34  |34
   ||perl-HTTP-Cookies-6.10-1.fc
   ||33
 Resolution|--- |ERRATA
Last Closed||2021-01-12 01:32:04



--- Comment #6 from Fedora Update System  ---
FEDORA-2021-b50706b7de has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1914567] perl-CPAN-Perl-Releases-5.20210109 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914567



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-1d9d6b41ac has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-1d9d6b41ac`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-1d9d6b41ac

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1914567] perl-CPAN-Perl-Releases-5.20210109 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914567

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-d95aded654 has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-d95aded654`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-d95aded654

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1914367] perl-Net-HTTP-6.20 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914367

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2021-92700dc791 has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-92700dc791`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-92700dc791

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

How did this file end up in the lookaside cache?

[Cristian Morales Vega]

Not sure exactly when, but it looks like me creating
https://src.fedoraproject.org/rpms/doxygen/pull-request/9 has
triggered a process uploading the tarball to the lookaside cache.

The tarball inside
https://kojipkgs.fedoraproject.org//work/tasks/5674/59445674/doxygen-1.9.1-1.fc34.src.rpm
is fine. But when I later tried to build the same sources in copr I
got a 404 error when downloading the tarball from the lookaside cache
(https://download.copr.fedorainfracloud.org/results/reddwarf/personal/srpm-builds/01876339/builder-live.log.gz).
The thing is that
https://src.fedoraproject.org/lookaside/pkgs/doxygen/doxygen-1.9.1.src.tar.gz/sha512/a84fbea1874921317b58345c53fc4eac0382c9e593f0e1ee899a31e67ead3fd12b2da8145b37e2e09d665e28d060e6717c92de7e8d0a31fc5f24fdcc4715f54d/doxygen-1.9.1.src.tar.gz
is a 19 MiB monster (instead of the 5 MiB of the real tarball) with,
obviously, the wrong hash.

How did this happen? Is it "expected" even if I don't understand it?
Is it a bug somewhere?
___
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

Re: can't build the package

[Alexander Vasilenko]

Issue was created: https://pagure.io/fedora-infrastructure/issue/9577
___
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

Re: What should I do, without being in the packager group, to get updates for a package?

[Cristian Morales Vega]

On Thu, 7 Jan 2021 at 13:20, Felix Schwarz  wrote:
> Am 07.01.21 um 13:05 schrieb Cristian Morales Vega:
> > My failed attempt has left me with some questions.
>
> I think I don't understand what you tried so far and what failed exactly 
> (maybe
> I misunderstood your email).

I basically gave up when I saw I couldn't update the lookaside cache.
I have now created the PR and things start to make sense.
___
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

Scala license change

[Jerry James]

I am about to build scala 2.13.4 in Rawhide.  This comes with a
license change from:

BSD and CC0 and Public Domain

to:

ASL 2.0 and BSD and MIT

Regards,
-- 
Jerry James
http://www.jamezone.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

Re: can't build the package

[Kevin Fenzi]

I'm not sure we need to keep debugging this on the list. 
Can you file a infrastructure ticket?

And next step would be output of: 

KRB5_TRACE=/dev/stdout koji hello

Can you add that to the ticket?

https://pagure.io/fedora-infrastructure/issues

kevin
--
On Mon, Jan 11, 2021 at 09:37:50PM -, Alexander Vasilenko wrote:
> [Flash@localhost dnscrypt-proxy-gui]$ fedpkg build
> Could not execute build: Error getting CCache Collection
> [Flash@localhost dnscrypt-proxy-gui]$ 
> After stop and remove sssd-kcm have:
> 
> [Flash@localhost SRPMS]$ koji build --scratch f33 
> ./dnscrypt-proxy-gui-1.24.17-1.fc34.src.rpm
> 2021-01-12 00:27:42,285 [ERROR] koji: AuthError: unable to obtain a session
> [Flash@localhost SRPMS]$ 
> [Flash@localhost dnscrypt-proxy-gui]$ fedpkg build
> Kerberos authentication is used, but you do not have a valid credential.
> Please use kinit to get credential with a principal that has realm 
> FEDORAPROJECT.ORG
> Could not execute build: Could not login to 
> https://koji.fedoraproject.org/kojihub
> [Flash@localhost dnscrypt-proxy-gui]$ kinit f1...@fedoraproject.org
> Password for f1...@fedoraproject.org: 
> [Flash@localhost dnscrypt-proxy-gui]$ fedpkg build
> Kerberos authentication fails: unable to obtain a session
> Could not execute build: Could not login to 
> https://koji.fedoraproject.org/kojihub
> [Flash@localhost dnscrypt-proxy-gui]$
> ___
> 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


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

Re: can't build the package

[Alexander Vasilenko]

Relogin and reboot not helpful, because it still some days...

After stopping and remove sssd-kcm have:
(not login with kinit yet)
$ fedpkg build
Kerberos authentication is used, but you do not have a valid credential.
Please use kinit to get credential with a principal that has realm 
FEDORAPROJECT.ORG
Could not execute build: Could not login to 
https://koji.fedoraproject.org/kojihub
[Flash@localhost dnscrypt-proxy-gui]$ kinit f1...@fedoraproject.org(new 
login with kinit)
Password for f1...@fedoraproject.org: 
[Flash@localhost dnscrypt-proxy-gui]$ fedpkg build
Kerberos authentication fails: unable to obtain a session
Could not execute build: Could not login to 
https://koji.fedoraproject.org/kojihub
[Flash@localhost dnscrypt-proxy-gui]$
___
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

Re: Chromium built in rawhide does not render most strings

[Kevin Kofler via devel]

Kevin Kofler via devel wrote:
> So now I had a new idea how to figure out what difference the version of
> glibc we are compiling against can make: track down the symbol version:
> nm -D --with-symbol-versions Downloads/libQt5WebEngineCore.so.5.15.2 |
> grep '@GLIBC_2\.33'
>  U fstat64@GLIBC_2.33
>  U fstatat64@GLIBC_2.33
>  U lstat64@GLIBC_2.33
>  U stat64@GLIBC_2.33
> 
> So we are getting new symbol versions of the above 4 functions. So now we
> only need to know what is different between the above and the syscalls
> presumably used previously:
> nm -D --with-symbol-versions Downloads/libQt5WebEngineCore.so.5.15.1 |
> grep 'stat\(at\)\?64'
>  U __fxstat64@GLIBC_2.2.5
>  U __fxstatat64@GLIBC_2.4
>  U __lxstat64@GLIBC_2.2.5
>  U __xstat64@GLIBC_2.2.5
> (That's the version from F33 GA, definitely built against an older glibc.)

PS: This commit:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8ed005daf0ab03e142500324a34087ce179ae78e
is why the version of glibc used at compile time makes a difference.

Until glibc 2.32, stat64 etc. were redirected to __xstat64 etc. by inline 
functions or macros; glibc 2.33 changed them to true functions. As a result, 
code compiled against glibc 2.32 or older will get the old __xstat64 etc. 
implementation that is still present, whereas code compiled against glibc 
2.33 will get the new stat64 etc. implementation.

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

Re: Chromium built in rawhide does not render most strings

[Kevin Kofler via devel]

Florian Weimer wrote:
> It's not.  It may be a completely different system call.

So now I had a new idea how to figure out what difference the version of 
glibc we are compiling against can make: track down the symbol version:
nm -D --with-symbol-versions Downloads/libQt5WebEngineCore.so.5.15.2 | grep 
'@GLIBC_2\.33'
 U fstat64@GLIBC_2.33
 U fstatat64@GLIBC_2.33
 U lstat64@GLIBC_2.33
 U stat64@GLIBC_2.33

So we are getting new symbol versions of the above 4 functions. So now we 
only need to know what is different between the above and the syscalls 
presumably used previously:
nm -D --with-symbol-versions Downloads/libQt5WebEngineCore.so.5.15.1 | grep 
'stat\(at\)\?64'
 U __fxstat64@GLIBC_2.2.5
 U __fxstatat64@GLIBC_2.4
 U __lxstat64@GLIBC_2.2.5
 U __xstat64@GLIBC_2.2.5
(That's the version from F33 GA, definitely built against an older glibc.)

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

Re: can't build the package

[Alexander Vasilenko]

[Flash@localhost dnscrypt-proxy-gui]$ fedpkg build
Could not execute build: Error getting CCache Collection
[Flash@localhost dnscrypt-proxy-gui]$ 
After stop and remove sssd-kcm have:

[Flash@localhost SRPMS]$ koji build --scratch f33 
./dnscrypt-proxy-gui-1.24.17-1.fc34.src.rpm
2021-01-12 00:27:42,285 [ERROR] koji: AuthError: unable to obtain a session
[Flash@localhost SRPMS]$ 
[Flash@localhost dnscrypt-proxy-gui]$ fedpkg build
Kerberos authentication is used, but you do not have a valid credential.
Please use kinit to get credential with a principal that has realm 
FEDORAPROJECT.ORG
Could not execute build: Could not login to 
https://koji.fedoraproject.org/kojihub
[Flash@localhost dnscrypt-proxy-gui]$ kinit f1...@fedoraproject.org
Password for f1...@fedoraproject.org: 
[Flash@localhost dnscrypt-proxy-gui]$ fedpkg build
Kerberos authentication fails: unable to obtain a session
Could not execute build: Could not login to 
https://koji.fedoraproject.org/kojihub
[Flash@localhost dnscrypt-proxy-gui]$
___
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

Re: Orphaned packages looking for new maintainers

[Peter Lemenkov]

пн, 11 янв. 2021 г. в 16:24, Marius Schwarz :
>
> Am 11.01.21 um 16:07 schrieb Vitaly Zaitsev via devel:
> > On 11.01.2021 14:43, Peter Lemenkov wrote:
> >> XMPP-based and it looks like XMPP days
> >> are numbered.
> >
> > XMPP is alive. I maintain 2 XMPP clients in Fedora.
> >
>
> I just tried Jitsi latest Build 5633 on Fedora 32 and it started and run
> ... for approximatly 10 seconds before it crashed :)

So right now we don't have a opensource VoIP client application for
SIP/XMPP networks in Fedora as far as I know.

I guess everyone is betting on Web-based desktop clients relying on
WebRTC so standalone clients are going to fade away.

-- 
With best regards, Peter Lemenkov.
___
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

[Bug 1914981] Upgrade perl-DateTime-Calendar-Julian to 0.103

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914981

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2021-01-11 21:26:19



--- Comment #1 from Tom "spot" Callaway  ---
0.103 in rawhide.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: can't build the package

[Kevin Fenzi]

This may be an your kcm daemon?

If you logout/reboot and try again does it start working?

Or if you remove sssd-kcm does it start 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

spot pushed to perl-DateTime-Calendar-Julian (master). "fix changelog year"

[notifications]

Notification time stamped 2021-01-11 21:07:58 UTC

From 6dd6ddee4083d57131a732648b339bba49e89335 Mon Sep 17 00:00:00 2001
From: Tom spot Callaway 
Date: Jan 11 2021 21:07:53 +
Subject: fix changelog year


---

diff --git a/perl-DateTime-Calendar-Julian.spec 
b/perl-DateTime-Calendar-Julian.spec
index cc77624..b7f3a44 100644
--- a/perl-DateTime-Calendar-Julian.spec
+++ b/perl-DateTime-Calendar-Julian.spec
@@ -39,7 +39,7 @@ make test
 %{_mandir}/man3/DateTime::Calendar::Julian.3pm*
 
 %changelog
-* Mon Jan 11 2020 Tom Callaway  - 0.103-1
+* Mon Jan 11 2021 Tom Callaway  - 0.103-1
 - update to 0.103
 
 * Tue Jul 28 2020 Fedora Release Engineering  - 
0.102-4



https://src.fedoraproject.org/rpms/perl-DateTime-Calendar-Julian/c/6dd6ddee4083d57131a732648b339bba49e89335?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

spot pushed to perl-DateTime-Calendar-Julian (master). "0.103"

[notifications]

Notification time stamped 2021-01-11 21:00:48 UTC

From 93b89b8559d40644530292662f670cce86de8022 Mon Sep 17 00:00:00 2001
From: Tom spot Callaway 
Date: Jan 11 2021 21:00:44 +
Subject: 0.103


---

diff --git a/.gitignore b/.gitignore
index 852c9dc..8961a07 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /DateTime-Calendar-Julian-0.100.tar.gz
 /DateTime-Calendar-Julian-0.101.tar.gz
 /DateTime-Calendar-Julian-0.102.tar.gz
+/DateTime-Calendar-Julian-0.103.tar.gz
diff --git a/perl-DateTime-Calendar-Julian.spec 
b/perl-DateTime-Calendar-Julian.spec
index 0b5999d..cc77624 100644
--- a/perl-DateTime-Calendar-Julian.spec
+++ b/perl-DateTime-Calendar-Julian.spec
@@ -1,6 +1,6 @@
 Name:  perl-DateTime-Calendar-Julian
-Version:   0.102
-Release:   4%{?dist}
+Version:   0.103
+Release:   1%{?dist}
 License:   GPL+ or Artistic
 Summary:   Julian Calendar support for DateTime.pm
 Url:   https://metacpan.org/release/DateTime-Calendar-Julian
@@ -39,6 +39,9 @@ make test
 %{_mandir}/man3/DateTime::Calendar::Julian.3pm*
 
 %changelog
+* Mon Jan 11 2020 Tom Callaway  - 0.103-1
+- update to 0.103
+
 * Tue Jul 28 2020 Fedora Release Engineering  - 
0.102-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
 
diff --git a/sources b/sources
index 91a1d22..e64a21f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (DateTime-Calendar-Julian-0.102.tar.gz) = 
7adb5ab1c6115e9ba62f46a3a925cfd246e4c12ed1688a4fe03930ea3ebf3662886066bc45b25bf9b25095490a47e2d047763fbbdc6454f00a9de67b08fa03cf
+SHA512 (DateTime-Calendar-Julian-0.103.tar.gz) = 
0c272bdb3e90584fa48c925c0afa19d157e80cb99bbd3ffedf19572e2e1bd7ad43e2d41a17bf3ae427cff88e0592ca9da2f194a1520f03eb564406594f8f68b6



https://src.fedoraproject.org/rpms/perl-DateTime-Calendar-Julian/c/93b89b8559d40644530292662f670cce86de8022?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1915067] New: perl-Devel-PatchPerl-2.08 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1915067

Bug ID: 1915067
   Summary: perl-Devel-PatchPerl-2.08 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Devel-PatchPerl
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.08
Current version/release in rawhide: 2.06-1.fc34
URL: http://search.cpan.org/dist/Devel-PatchPerl/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/6561/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)

[ElXreno]

I apologize for the possible duplicate message, the past didn't show up 
for reasons I don't understand.


I think it's a bad idea. It is better to make `zram-fraction` equal to 
0.8 or 0.9, but not 1.0.
For example, if you run Darktable, load a floating-point TIFF image into 
it, and try to export it, on systems with little RAM, it will fill both 
RAM itself and zram, and cause the system to freeze completely because 
the memory is almost incompressible.
Also, other data (video editors, for example) which are not compressible 
can get into RAM.

___
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

drafting change: ppc64le 4k page size

[Daniel Pocock]

I started drafting the change on the wiki[1] and there is discussion[2]
in Pagure

Is there anybody from the POWER SIG or kernel team who would like to
collaborate as co-owner?

Are there any ppc64le users who would like to propose requirements for
upgrade, test or anything else?

Regards,

Daniel


1. https://fedoraproject.org/wiki/Changes/Power4kPageSizeF34
2. https://pagure.io/releng/issue/9939
___
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

Re: poppler soname bump in rawhide

[Ankur Sinha]

On Mon, Jan 11, 2021 18:44:47 +0100, Marek Kasik wrote:
> Hi,

Hi Marek,

> I've prepared rebase of poppler to 21.01.0 in the side tag
> "f34-build-side-35737". I ask you to build your dependent packages in it and
> I will ask to merge it to main branch next Tuesday (19th of January).
> Let me know if you won't have time for that or there will be some other
> circumstances where I can help.

Thanks. I've kicked off builds for gdcm and pdfpc. I don't *think* any
of my other packages depend on poppler.

- https://koji.fedoraproject.org/koji/taskinfo?taskID=59461809
- https://koji.fedoraproject.org/koji/taskinfo?taskID=59461658

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: poppler soname bump in rawhide

[Kevin Kofler via devel]

Marek Kasik wrote:
> I've also removed the Qt4 frontend which we've maintained for
> compatibility. Relevant package maintainers were contacted and some of
> them already switched to Qt5.

For diffpdf, it looks like it needs to be upgraded to this fork:
https://gitlab.com/eang/diffpdf

(The original upstream is now proprietary software.)

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

Re: ELN build order

[Fabio Valentini]

On Mon, Jan 11, 2021 at 3:57 PM Vít Ondruch  wrote:
>
> Also, rubygem-eventmachine should be installable after rebuild. But 
> certainly, there might happen race conditions a it happened this time.

This reminds me - over a year ago, I triggered discussion about making
the dist.rpmdeplint test blocking for all packages, which would solve
this exact problem. However, taskotron was retired shortly after, and
Fedora CI has only been catching up lately. Is there an installability
check in Fedora CI now? Can we make it so that if packages contained
in an update do not install correctly the update fails gating checks?

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

Re: Non-responsive maintainer check: tnorth (for autojump branch request)

[Michel Alexandre Salim]

Hi Thibault,

On Sun, 2021-01-10 at 21:04 +0100, Thibault North wrote:
> Hi there,
> 
> I apologize for the lack of response. I've been unable to contribute
> lately for personal reasons. I'll attempt to pass or orphan packages
> I can't support any more.
> @Michel Alexandre Salim: I gave you the requested rights. Please get
> in touch with me per e-mail directly if need anything (en français ça
> va aussi).
> 
Thanks for getting in touch! I have one additional request (please also
orphan autojump so we can find a new primary maintainer), and hope
everything is fine personally.

cc:ing the other maintainers to see if anyone wants to be the new
primary, if not, I can take it.

Best,

Michel

> Best,
> Thibault
> 
> 
> On Sat, Jan 9, 2021 at 12:55 AM Michel Alexandre Salim <
> mic...@michel-slm.name> wrote:
> > On Fri, 2021-01-08 at 15:34 -0800, Michel Alexandre Salim wrote:
> > > Hi,
> > > 
> > > I'm initiating the non-responsive maintainer process for tnorth,
> > > per 
> > > 
> > https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/
> > > 
> > > An EPEL branch request has been open since November 19 with no
> > > response.
> > > 
> > > Does anyone know how to get in touch with him?
> > > 
> > > Bugzilla:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1914467
> > > 
> > > Last activity:
> > 
> > I'm fixing fedora-active-user to support the new Bodhi API, and get
> > the
> > following:
> > 
> > ```
> > Last package update on bodhi:
> >    2016-07-19 08:45:14 on package python-numexpr-2.6.1-1.fc24
> > ```
> > 
> > 
> > ___
> > 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

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


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

Re: Proposal: gate stable release critical path updates on openQA test results

[Kevin Kofler via devel]

Stephen Gallagher wrote:
> Just to be clear: We're working under the assumption that autopush and
> the other policies we have in place now *reduces* the rate at which
> mistakes are made with the lowest amount of maintainer overhead.

And that is the basic assumption that I have a hard time believing.

What I see is that we are repeatedly having issues caused by not very smart 
automagic, and the proposed remedy is always the same: add more automagic to 
try and catch the individual problem. Yet, the issues are not going away.

> Kevin is suggesting that he believes that maintainers should be the
> sole arbiters of when a package is pushed, not that maintainers are
> infallible.

Exactly. Nobody is infallible, but an experienced maintainer has a lower 
error rate than a software heuristic that simply cannot see the whole 
picture.

And the current situation where:
* autopush is enabled by default, and
* Bodhi does not allow pushing manually if the minimum criteria for an
  automatic push (minimum karma value and/or minimum time passed) are not
  yet satisfied
encourages maintainers to enable autopush when they otherwise wouldn't. 

E.g., in the old system, I was able to file the update, and come back a week 
later and push it to stable if the feedback was good. Now, if I want to do 
that, I am forced to check repeatedly whether the 7 days of testing, which 
are counted not based on anything I can control, but based on when the push 
actually happened, have passed, because Bodhi won't let me push the update 
even a microsecond earlier if it did not get that +1 vote (and multiply 
everything by 2 for critical path packages). So the maintainers who have 
other things to do than checking back all the time whether the magic timeout 
has expired will necessarily enable the automagic.

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

Re: poppler soname bump in rawhide

[Scott Talbert]

On Mon, 11 Jan 2021, Gwyn Ciesla via devel wrote:


I didn't realize sip5 provided the python bindings, but it does. The build 
still fails:

https://kojipkgs.fedoraproject.org//work/tasks/6643/59456643/build.log


Looks like you're still using sip4?  /usr/bin/sip is sip4.  sip5 is 
/usr/bin/sip5.


building 'popplerqt5' extension
/usr/bin/sip -I /usr/share/sip -t POPPLER_V21_01_0 -c 
build/temp.linux-armv7l-3.9 -b build/temp.linux-armv7l-3.9/poppler-qt5.sbf 
-I /usr/share/sip/PyQt5 -n PyQt5.sip -t WS_X11 -t Qt_5_15_0 
poppler-qt5.sip
sip: poppler-form.sip:152: 
::Poppler::FormFieldChoice::choicesWithExportValues() unsupported function 
return type - provide %MethodCode and a C++ signature

error: command '/usr/bin/sip' failed with exit code 1

Scott
___
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

Re: can't build the package

[Alexander Vasilenko]

$ env KRB5_TRACE=/dev/stdout kinit f1...@fedoraproject.org  
[9092] 1610393839.304594: Getting initial credentials for 
f1...@fedoraproject.org
[9092] 1610393839.304596: Sending unauthenticated request
[9092] 1610393839.304597: Sending request (208 bytes) to FEDORAPROJECT.ORG
[9092] 1610393839.304598: Resolving hostname id.fedoraproject.org
[9092] 1610393840.487545: TLS certificate name matched "id.fedoraproject.org"
[9092] 1610393840.487546: Sending HTTPS request to https 209.132.190.2:443
[9092] 1610393841.217394: Received answer (311 bytes) from https 
209.132.190.2:443
[9092] 1610393841.217395: Terminating TCP connection to https 209.132.190.2:443
[9092] 1610393841.217396: Sending DNS URI query for _kerberos.FEDORAPROJECT.ORG.
[9092] 1610393841.217397: URI answer: 10 1 
"krb5srv:m:kkdcp:https://id.fedoraproject.org/KdcProxy/;
[9092] 1610393841.217398: Response was from master KDC
[9092] 1610393841.217399: Received error from KDC: -1765328359/Additional 
pre-authentication required
[9092] 1610393841.217402: Preauthenticating using KDC method data
[9092] 1610393841.217403: Processing preauth types: PA-PK-AS-REQ (16), 
PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147), PA-ENC-TIMESTAMP 
(2), PA_AS_FRESHNESS (150), PA-FX-COOKIE (133)
[9092] 1610393841.217404: Selected etype info: etype aes256-cts, salt 
"A7!R@cu?+A22.eW:", params ""
[9092] 1610393841.217405: Received cookie: MIT
Password for f1...@fedoraproject.org: 
[9092] 1610393929.526549: AS key obtained for encrypted timestamp: 
aes256-cts/6160
[9092] 1610393929.526551: Encrypted timestamp (for 1610393929.419454): plain 
301AA011180F32303231303131313139333834395AA105020306667E, encrypted 
6868A6998D492AF31C2C8997E8A776021F4846A0FFB7DC987FB018AD52ECFFADFC45F0CEC8842BE48070408C0718B5FC37294885BBA6F894
[9092] 1610393929.526552: Preauth module encrypted_timestamp (2) (real) 
returned: 0/Success
[9092] 1610393929.526553: Produced preauth for next request: PA-FX-COOKIE 
(133), PA-ENC-TIMESTAMP (2)
[9092] 1610393929.526554: Sending request (303 bytes) to FEDORAPROJECT.ORG
[9092] 1610393929.526555: Resolving hostname id.fedoraproject.org
[9092] 1610393929.526556: TLS certificate name matched "id.fedoraproject.org"
[9092] 1610393929.526557: Sending HTTPS request to https 209.132.190.2:443
[9092] 1610393930.521673: Received answer (785 bytes) from https 
209.132.190.2:443
[9092] 1610393930.521674: Terminating TCP connection to https 209.132.190.2:443
[9092] 1610393930.521675: Sending DNS URI query for _kerberos.FEDORAPROJECT.ORG.
[9092] 1610393930.521676: URI answer: 10 1 
"krb5srv:m:kkdcp:https://id.fedoraproject.org/KdcProxy/;
[9092] 1610393930.521677: Response was from master KDC
[9092] 1610393930.521678: Processing preauth types: PA-ETYPE-INFO2 (19)
[9092] 1610393930.521679: Selected etype info: etype aes256-cts, salt 
"A7!R@cu?+A22.eW:", params ""
[9092] 1610393930.521680: Produced preauth for next request: (empty)
[9092] 1610393930.521681: AS key determined by preauth: aes256-cts/6160
[9092] 1610393930.521682: Decrypted AS reply; session key is: aes256-cts/02B1
[9092] 1610393930.521683: FAST negotiation: available
[9092] 1610393930.521684: Initializing KCM:1000 with default princ 
f1...@fedoraproject.org
[9092] 1610393930.521685: Storing f1...@fedoraproject.org -> 
krbtgt/fedoraproject@fedoraproject.org in KCM:1000
[9092] 1610393930.521686: Storing config in KCM:1000 for 
krbtgt/fedoraproject@fedoraproject.org: fast_avail: yes
[9092] 1610393930.521687: Storing f1...@fedoraproject.org -> 
krb5_ccache_conf_data/fast_avail/krbtgt\/FEDORAPROJECT.ORG\@FEDORAPROJECT.ORG@X-CACHECONF:
 in KCM:1000
[9092] 1610393930.521688: Storing config in KCM:1000 for 
krbtgt/fedoraproject@fedoraproject.org: pa_type: 2
[9092] 1610393930.521689: Storing f1...@fedoraproject.org -> 
krb5_ccache_conf_data/pa_type/krbtgt\/FEDORAPROJECT.ORG\@FEDORAPROJECT.ORG@X-CACHECONF:
 in KCM:1000
$
___
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

Re: can't build the package

[Robert-André Mauchin]

On 1/11/21 8:25 PM, Alexander Vasilenko wrote:

Fedora rawhide, last updates.

Package: https://src.fedoraproject.org/rpms/dnscrypt-proxy-gui
Pushed new version to master, f33, f32.

$ kinit f1...@fedoraproject.org -- sussecc,

but
$ fedpkg build
Kerberos authentication fails: unable to obtain a session
Could not execute build: Could not login to 
https://koji.fedoraproject.org/kojihub
$

and simple scratch from local src.rpm file
$ koji build --scratch f33 ./dnscrypt-proxy-gui-1.24.17-1.fc34.src.rpm
2021-01-11 22:24:09,616 [ERROR] koji: AuthError: unable to obtain a session
$

Any suggestion, pls.
___
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



What does:

env KRB5_TRACE=/dev/stdout kinit f1...@fedoraproject.org

give you?
___
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

can't build the package

[Alexander Vasilenko]

Fedora rawhide, last updates.

Package: https://src.fedoraproject.org/rpms/dnscrypt-proxy-gui
Pushed new version to master, f33, f32.

$ kinit f1...@fedoraproject.org -- sussecc,

but 
$ fedpkg build
Kerberos authentication fails: unable to obtain a session
Could not execute build: Could not login to 
https://koji.fedoraproject.org/kojihub
$

and simple scratch from local src.rpm file
$ koji build --scratch f33 ./dnscrypt-proxy-gui-1.24.17-1.fc34.src.rpm
2021-01-11 22:24:09,616 [ERROR] koji: AuthError: unable to obtain a session
$

Any suggestion, pls.
___
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

Re: poppler soname bump in rawhide

[Gwyn Ciesla via devel]

I didn't realize sip5 provided the python bindings, but it does. The build 
still fails:

https://kojipkgs.fedoraproject.org//work/tasks/6643/59456643/build.log


-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, January 11, 2021 12:29 PM, Scott Talbert  wrote:

> On Mon, 11 Jan 2021, Gwyn Ciesla via devel wrote:
> 

> > python3-sip-4.19.24 seems too old for python3-poppler-qt5 21.1.0, and
> > sip5 seems to lack python bindings. What's the best plan to resolve
> > this?
> 

> What do you mean by "sip5 seems to lack python bindings?"
> 

> Scott
> 

> 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



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

[Bug 1915028] New: perl-Role-Tiny-2.002003 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1915028

Bug ID: 1915028
   Summary: perl-Role-Tiny-2.002003 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Role-Tiny
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.002003
Current version/release in rawhide: 2.001004-4.fc33
URL: http://search.cpan.org/dist/Role-Tiny/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/10665/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Bash 5.1: stdout contains \x1b[?2004l\r376\r ?

[Miro Hrončok]

On 11. 01. 21 18:22, Miro Hrončok wrote:

On 11. 01. 21 18:02, Miro Hrončok wrote:

On 11. 01. 21 13:19, Miro Hrončok wrote:

On 11. 01. 21 13:13, Miro Hrončok wrote:

Hello Siteshwar,

I see two Python packages that fail to test with Bash 5.1 due to 
\x1b[?2004l\r376\r or similar unexpectedly in captured stdout:


https://bugzilla.redhat.com/show_bug.cgi?id=1914782
https://bugzilla.redhat.com/show_bug.cgi?id=1914880

Is this anything you are aware of? What shall be done to fix this?

Thanks,


Actually, I see more:

https://koschei.fedoraproject.org/affected-by/bash?epoch1=0=5.0.17=3.fc34=0=5.1.0=1.fc34=f34 



e.g. pytest:

 child.expect("Pdb")
 >   assert "\r\n'i=0.'\r\n" in child.before.decode("utf8")
E   assert "\r\n'i=0.'\r\n" in ") 'i=%i.' % 
i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h("
E    +  where ") 'i=%i.' % i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h(" = 
('utf8')
E    +    where  
= b") 'i=%i.' % i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h(".decode
E    +  where b") 'i=%i.' % i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h(" 
= .before

/builddir/build/BUILD/pytest-6.0.2/testing/test_debugging.py:492: AssertionError

E   AssertionError: assert '\r\nENTERING RECURSIVE DEBUGGER\r\n' in 
'\r\n\x1b[?2004hdebug set_trace()\r\n\x1b[?2004l\rENTERING RECURSIVE 
DEBUGGER\r\n'


or python-pexpect:

 >   assert res.strip() == '11'
E   AssertionError: assert '\x1b[?2004l\...\n\x1b[?2004h' == '11'
E - 11
E + [?2004l
E + 11
E + [?2004h

And more...

Also ccing devel list for help.


There was some off-list discussion about this. A summary:

This is coming from the bracketed paste, which is enabled by default:

  https://lists.gnu.org/archive/html/bug-readline/2020-11/msg00010.html
  https://lists.gnu.org/archive/html/bug-bash/2020-10/msg00048.html
  https://lists.gnu.org/archive/html/bug-bash/2020-10/msg00087.html

The tests would already fail in the situations where user has enabled 
bracketed paste mode in their environments. Since Bash 5.1, this is the 
default, so the tests fail in mock. It might be a good idea to fix the tests 
(or sometimes even the implementation) to work with bracketed paste. However, 
as a stop-gap measure, this seem to work reliably:


   %check
   echo "set enable-bracketed-paste off" > .inputrc
   export INPUTRC=$PWD/.inputrc


It appears that the common denominator of all (or at least most of) the failures 
is pexpect:


https://bugzilla.redhat.com/show_bug.cgi?id=1914843


Correction, terminado does not use pexpect:

https://bugzilla.redhat.com/show_bug.cgi?id=1914880

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: poppler soname bump in rawhide

[Scott Talbert]

On Mon, 11 Jan 2021, Gwyn Ciesla via devel wrote:

python3-sip-4.19.24 seems too old for python3-poppler-qt5 21.1.0, and 
sip5 seems to lack python bindings. What's the best plan to resolve 
this?


What do you mean by "sip5 seems to lack python bindings?"

Scott
___
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

Re: What is the most time consuming task for you as packager?

[Nikola Forró]

On Sat, 2020-12-26 at 20:39 +, Sérgio Basto wrote:
> Hi, 
> For me the most time consuming is monkey updates packages like kde
> apps, which every month or two we have a new release ( kde app
> 20.04.1 20.04.2 20.08.0 , 20.12.00 etc )
> 
> I did some scripts to automate my builds , we got some software like 
> https://github.com/fedora-infra/the-new-hotness/ 
> but the more I do, I always some variables that are different from
> project to project , we need to know the version number, we may need
> to download more than one source, we may need drop patches that we
> know that are already upstreamed, not all the package are build in
> same branches so we need to know what branches we want update , we
> may have to add buildroot-overrides, we need add build to bodhi and
> fill some information , we need close bugs create made by hotness or
> other users etc
> 
> Examples of my scripts are usually in packages sources like 
> 
> https://src.fedoraproject.org/rpms/virtualbox-guest-additions/blob/master/f/update_vbox.sh
>  
> 
> or (in attachment) scripts in very quick-and-dirty style 

Have you tried rebase-helper? [1] It won't solve everything, but you could find 
it useful.
However particularly in case of virtualbox-guest-additions there is an
issue with the extra "a" in source name. I'm open to suggestions on how
to deal with that :)

Regards,
Nikola

[1] https://github.com/rebase-helper/rebase-helper


___
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

Re: poppler soname bump in rawhide

[Gwyn Ciesla via devel]

python3-sip-4.19.24 seems too old for python3-poppler-qt5 21.1.0, and sip5 
seems to lack python bindings. What's the best plan to resolve this?


-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, January 11, 2021 11:44 AM, Marek Kasik  wrote:

> Hi,
> 

> I've prepared rebase of poppler to 21.01.0 in the side tag
> "f34-build-side-35737". I ask you to build your dependent packages in it
> and I will ask to merge it to main branch next Tuesday (19th of January).
> Let me know if you won't have time for that or there will be some other
> circumstances where I can help.
> 

> There are several API changes and soname bump of the base library
> libpoppler.so.*.
> 

> I've also removed the Qt4 frontend which we've maintained for
> compatibility. Relevant package maintainers were contacted and some of
> them already switched to Qt5.
> 

> Upstream removed poppler-cairo.pc and poppler-splash.pc since it
> considers those APIs pure internal. It is better to use poppler-glib or
> poppler-qt5.
> 

> Btw, if your package still uses the unstable API (headers from
> poppler-devel), could you consider to change it to use a stable API
> (glib, qt5, C++)? It would mean less work for you and I would be able to
> disable the unstable API.
> 

> Regards
> 

> Marek
> 

> 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



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

Re: Proposal: gate stable release critical path updates on openQA test results

[Adam Williamson]

On Mon, 2021-01-11 at 12:09 -0500, Stephen Gallagher wrote:
> To rephrase their statements in my own words (and correct me if I get
> them wrong):
> Kevin is suggesting that he believes that maintainers should be the
> sole arbiters of when a package is pushed, not that maintainers are
> infallible.
> Adam is saying that we have tried Kevin's approach previously and
> found it to be less successful on the whole than what we are doing
> right now.

Not quite, no. What I'm saying is that Kevin suggests that if we just
make the process require manual action at each step and remove things
like autopush, maintainers will get it right (AIUI). I'm saying that
IMHO the evidence suggests this is not true, for two reasons:

i) As I recall, before we had autopush or enabled it by default,
maintainers still did things wrong sometimes.

ii) even with autopush, maintainers *can* be more careful, in three
possible ways. They can disable autopush, or they can include the
dependencies in the library update, or they can wait for the library
update to go stable before pushing the dependent update even to
testing.

As I understand Kevin's argument, he's saying that some maintainers
might not bother to do any of those three things, *but* if we disabled
autopush, they *would* check that the updates their update depends on
have gone stable before pushing it stable manually. I'm sceptical that
that is the case.
-- 
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

Re: poppler soname bump in rawhide

[Neal Gompa]

On Mon, Jan 11, 2021 at 12:45 PM Marek Kasik  wrote:
>
> Hi,
>
> I've prepared rebase of poppler to 21.01.0 in the side tag
> "f34-build-side-35737". I ask you to build your dependent packages in it
> and I will ask to merge it to main branch next Tuesday (19th of January).
> Let me know if you won't have time for that or there will be some other
> circumstances where I can help.
>
> There are several API changes and soname bump of the base library
> libpoppler.so.*.
>
> I've also removed the Qt4 frontend which we've maintained for
> compatibility. Relevant package maintainers were contacted and some of
> them already switched to Qt5.
>
> Upstream removed poppler-cairo.pc and poppler-splash.pc since it
> considers those APIs pure internal. It is better to use poppler-glib or
> poppler-qt5.
>
> Btw, if your package still uses the unstable API (headers from
> poppler-devel), could you consider to change it to use a stable API
> (glib, qt5, C++)? It would mean less work for you and I would be able to
> disable the unstable API.
>

I believe that Jan Grulich (Cc'd to this email) is working on bringing
Qt6 into Fedora now[1], so it'd be great if we could coordinate that so
Poppler gets its Qt6 frontend enabled too.

[1]: https://pagure.io/fedora-kde/SIG/issue/30




--
真実はいつも一つ！/ 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

poppler soname bump in rawhide

[Marek Kasik]

Hi,

I've prepared rebase of poppler to 21.01.0 in the side tag 
"f34-build-side-35737". I ask you to build your dependent packages in it 
and I will ask to merge it to main branch next Tuesday (19th of January).
Let me know if you won't have time for that or there will be some other 
circumstances where I can help.


There are several API changes and soname bump of the base library
libpoppler.so.*.

I've also removed the Qt4 frontend which we've maintained for 
compatibility. Relevant package maintainers were contacted and some of 
them already switched to Qt5.


Upstream removed poppler-cairo.pc and poppler-splash.pc since it 
considers those APIs pure internal. It is better to use poppler-glib or 
poppler-qt5.


Btw, if your package still uses the unstable API (headers from 
poppler-devel), could you consider to change it to use a stable API 
(glib, qt5, C++)? It would mean less work for you and I would be able to 
disable the unstable API.


Regards

Marek
___
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

Re: Bugzilla error when saving

[Miro Hrončok]

On 04. 01. 21 16:17, Richard Shaw wrote:

I was trying to add an issue to this bug but I keep on getting a jira error:

https://bugzilla.redhat.com/show_bug.cgi?id=1912472 



Thanks,
Richard

---

There was an error reported for the RPC call to Jira: There was an error 
reported for a GitHub REST call. URL: 
https://api.github.com/repos/fail2ban/fail2ban/issues/2904 
 Error: 403 
Forbidden at 
/loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line 111. 
at /loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line 
111. eval {...} called at 
/loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line 98 
Bugzilla::Extension::ExternalBugs::Type::GitHub::_do_rest_call('Bugzilla::Extension::ExternalBugs::Type::GitHub=HASH(0x559586...', 
'https://api.github.com/repos/fail2ban/fail2ban/issues/2904 
', 'GET') called at 
/loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line 62 
Bugzilla::Extension::ExternalBugs::Type::GitHub::get_data('Bugzilla::Extension::ExternalBugs::Type::GitHub=HASH(0x559586...', 
'Bugzilla::Extension::ExternalBugs::Bug=HASH(0x559586d39d80)') called at 
/loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Bug.pm line 302 eval 
{...} called at /loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Bug.pm 
line 302 
Bugzilla::Extension::ExternalBugs::Bug::update_ext_info('Bugzilla::Extension::ExternalBugs::Bug=HASH(0x559586d39d80)', 
1) called at /loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Bug.pm line 
125 
Bugzilla::Extension::ExternalBugs::Bug::create('Bugzilla::Extension::ExternalBugs::Bug', 
'HASH(0x559586967008)') called at 
/var/www/html/bugzilla/extensions/ExternalBugs/Extension.pm line 940 
Bugzilla::Extension::ExternalBugs::bug_start_of_update('Bugzilla::Extension::ExternalBugs=HASH(0x559586b85cd8)', 
'HASH(0x559586b70760)') called at /var/www/html/bugzilla/Bugzilla/Hook.pm line 
21 Bugzilla::Hook::process('bug_start_of_update', 'HASH(0x559586b70760)') called 
at /var/www/html/bugzilla/Bugzilla/Bug.pm line 1173 
Bugzilla::Bug::update('Bugzilla::Bug=HASH(0x559586b46d38)') called at 
/var/www/html/bugzilla/process_bug.cgi line 558 
ModPerl::ROOT::Bugzilla::ModPerl::ResponseHandler::var_www_html_bugzilla_process_bug_2ecgi::handler('Apache2::RequestRec=SCALAR(0x559586a0cc18)') 
called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 207 eval 
{...} called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 207 
ModPerl::RegistryCooker::run('Bugzilla::ModPerl::ResponseHandler=HASH(0x559586b86560)') 
called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 173 
ModPerl::RegistryCooker::default_handler('Bugzilla::ModPerl::ResponseHandler=HASH(0x559586b86560)') 
called at /usr/lib64/perl5/vendor_perl/ModPerl/Registry.pm line 32 
ModPerl::Registry::handler('Bugzilla::ModPerl::ResponseHandler', 
'Apache2::RequestRec=SCALAR(0x559586a0cc18)') called at 
/var/www/html/bugzilla/mod_perl.pl  line 139 
Bugzilla::ModPerl::ResponseHandler::handler('Bugzilla::ModPerl::ResponseHandler', 'Apache2::RequestRec=SCALAR(0x559586a0cc18)') 
called at -e line 0 eval {...} called at -e line 0 at 
/var/www/html/bugzilla/Bugzilla/Error.pm line 130. 
Bugzilla::Error::_throw_error('global/user-error.html.tmpl', 
'ext_bz_rest_error', 'HASH(0x559586da17c0)') called at 
/var/www/html/bugzilla/Bugzilla/Error.pm line 193 
Bugzilla::Error::ThrowUserError('ext_bz_rest_error', 'HASH(0x559586da17c0)') 
called at /loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm 
line 120 
Bugzilla::Extension::ExternalBugs::Type::GitHub::_do_rest_call('Bugzilla::Extension::ExternalBugs::Type::GitHub=HASH(0x559586...', 
'https://api.github.com/repos/fail2ban/fail2ban/issues/2904 
', 'GET') called at 
/loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line 62 
Bugzilla::Extension::ExternalBugs::Type::GitHub::get_data('Bugzilla::Extension::ExternalBugs::Type::GitHub=HASH(0x559586...', 
'Bugzilla::Extension::ExternalBugs::Bug=HASH(0x559586d39d80)') called at 
/loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Bug.pm line 302 eval 
{...} called at /loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Bug.pm 
line 302 
Bugzilla::Extension::ExternalBugs::Bug::update_ext_info('Bugzilla::Extension::ExternalBugs::Bug=HASH(0x559586d39d80)', 
1) called at /loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Bug.pm line 
125 
Bugzilla::Extension::ExternalBugs::Bug::create('Bugzilla::Extension::ExternalBugs::Bug', 
'HASH(0x559586967008)') called at 
/var/www/html/bugzilla/extensions/ExternalBugs/Extension.pm line 940 
Bugzilla::Extension::ExternalBugs::bug_start_of_update('Bugzilla::Extension::ExternalBugs=HASH(0x559586b85cd8)', 

Re: Bash 5.1: stdout contains \x1b[?2004l\r376\r ?

[Miro Hrončok]

On 11. 01. 21 18:02, Miro Hrončok wrote:

On 11. 01. 21 13:19, Miro Hrončok wrote:

On 11. 01. 21 13:13, Miro Hrončok wrote:

Hello Siteshwar,

I see two Python packages that fail to test with Bash 5.1 due to 
\x1b[?2004l\r376\r or similar unexpectedly in captured stdout:


https://bugzilla.redhat.com/show_bug.cgi?id=1914782
https://bugzilla.redhat.com/show_bug.cgi?id=1914880

Is this anything you are aware of? What shall be done to fix this?

Thanks,


Actually, I see more:

https://koschei.fedoraproject.org/affected-by/bash?epoch1=0=5.0.17=3.fc34=0=5.1.0=1.fc34=f34 



e.g. pytest:

 child.expect("Pdb")
 >   assert "\r\n'i=0.'\r\n" in child.before.decode("utf8")
E   assert "\r\n'i=0.'\r\n" in ") 'i=%i.' % 
i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h("
E    +  where ") 'i=%i.' % i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h(" = 
('utf8')
E    +    where  
= b") 'i=%i.' % i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h(".decode
E    +  where b") 'i=%i.' % i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h(" 
= .before

/builddir/build/BUILD/pytest-6.0.2/testing/test_debugging.py:492: AssertionError

E   AssertionError: assert '\r\nENTERING RECURSIVE DEBUGGER\r\n' in 
'\r\n\x1b[?2004hdebug set_trace()\r\n\x1b[?2004l\rENTERING RECURSIVE 
DEBUGGER\r\n'


or python-pexpect:

 >   assert res.strip() == '11'
E   AssertionError: assert '\x1b[?2004l\...\n\x1b[?2004h' == '11'
E - 11
E + [?2004l
E + 11
E + [?2004h

And more...

Also ccing devel list for help.


There was some off-list discussion about this. A summary:

This is coming from the bracketed paste, which is enabled by default:

  https://lists.gnu.org/archive/html/bug-readline/2020-11/msg00010.html
  https://lists.gnu.org/archive/html/bug-bash/2020-10/msg00048.html
  https://lists.gnu.org/archive/html/bug-bash/2020-10/msg00087.html

The tests would already fail in the situations where user has enabled bracketed 
paste mode in their environments. Since Bash 5.1, this is the default, so the 
tests fail in mock. It might be a good idea to fix the tests (or sometimes even 
the implementation) to work with bracketed paste. However, as a stop-gap 
measure, this seem to work reliably:


   %check
   echo "set enable-bracketed-paste off" > .inputrc
   export INPUTRC=$PWD/.inputrc


It appears that the common denominator of all (or at least most of) the failures 
is pexpect:


https://bugzilla.redhat.com/show_bug.cgi?id=1914843

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: gate stable release critical path updates on openQA test results

[Stephen Gallagher]

On Mon, Jan 11, 2021 at 11:37 AM Adam Williamson
 wrote:
>
> On Mon, 2021-01-11 at 15:41 +0100, Kevin Kofler via devel wrote:
> > Matthew Miller wrote:
> > > And, also hopefully also a rare occasion, but if this were enabled (and
> > > the definitions up to date), problems like
> > >
> > https://lists.fedoraproject.org/archives/list/us...@lists.fedoraproject.org/thread/CAS6KHTZLR6LUNWEVK3BOIO6HVNQDETZ/#N5HJDKMTGOTL44BT2HZ43LE6Q23345IQ
> > > would be caught before they hit users.
> >
> > This issue was a result of using autopush. See also:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2021-5da509fd8e#comment-1807700
> > A maintainer would normally not manually push an update before the library
> > update it depends on, the autopush logic was what made that accident happen.
>
> Well, but maintainers *did*, back before we had autopush.
>
> You might just as well say "a maintainer would not normally enable
> autopush if they're submitting an update that depends on another update
> that is not yet stable", because they shouldn't. But they do. All the
> time.
>
> Maintainers get stuff wrong sometimes. We've tweaked the mechanisms in
> various ways for more than a decade and that hasn't stopped happening
> yet. Even if we changed Bodhi to precisely your preferred
> configuration, I'm gonna posit that maintainers would still manage to
> get stuff wrong sometimes. :)

Just to be clear: We're working under the assumption that autopush and
the other policies we have in place now *reduces* the rate at which
mistakes are made with the lowest amount of maintainer overhead.
Tweaks can continue to be made, but we're trying to balance
convenience with accuracy (while not introducing so much process that
people ignore or bypass it). Adam, I think your response came out a
little more like "perfect things aren't possible, so why change
anything?" rather than the "no solution is perfect, so we're trying to
get as close as we can" that I think you actually meant.

To rephrase their statements in my own words (and correct me if I get
them wrong):
Kevin is suggesting that he believes that maintainers should be the
sole arbiters of when a package is pushed, not that maintainers are
infallible.
Adam is saying that we have tried Kevin's approach previously and
found it to be less successful on the whole than what we are doing
right now.

In general, I would probably agree with Kevin *if* all maintainers
were as dedicated as Kevin. Unfortunately, experience has shown that
this is not the case. Outside of those paid to work on Fedora
packaging as part of their day-jobs, most maintainers are hobbyists
who work on Fedora whenever they have time (or the mood takes them).
As we are essentially *all* volunteers, we cannot load them up with
too much process or too many hoops to jump through, lest they decide
it's not fun anymore to be part of our community. At the same time, we
*do* want to deliver the best Fedora that we can. The best way to do
this is, I think, what we have been doing: experimenting with small
tweaks in the process over time to determine which pieces have a
better convenience:accuracy ratio and then keep iterating.
___
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

Re: Bash 5.1: stdout contains \x1b[?2004l\r376\r ?

[Miro Hrončok]

On 11. 01. 21 13:19, Miro Hrončok wrote:

On 11. 01. 21 13:13, Miro Hrončok wrote:

Hello Siteshwar,

I see two Python packages that fail to test with Bash 5.1 due to 
\x1b[?2004l\r376\r or similar unexpectedly in captured stdout:


https://bugzilla.redhat.com/show_bug.cgi?id=1914782
https://bugzilla.redhat.com/show_bug.cgi?id=1914880

Is this anything you are aware of? What shall be done to fix this?

Thanks,


Actually, I see more:

https://koschei.fedoraproject.org/affected-by/bash?epoch1=0=5.0.17=3.fc34=0=5.1.0=1.fc34=f34 



e.g. pytest:

     child.expect("Pdb")
 >   assert "\r\n'i=0.'\r\n" in child.before.decode("utf8")
E   assert "\r\n'i=0.'\r\n" in ") 'i=%i.' % 
i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h("
E    +  where ") 'i=%i.' % i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h(" = 
('utf8')
E    +    where  = 
b") 'i=%i.' % i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h(".decode
E    +  where b") 'i=%i.' % i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h(" = 
.before

/builddir/build/BUILD/pytest-6.0.2/testing/test_debugging.py:492: AssertionError

E   AssertionError: assert '\r\nENTERING RECURSIVE DEBUGGER\r\n' in 
'\r\n\x1b[?2004hdebug set_trace()\r\n\x1b[?2004l\rENTERING RECURSIVE DEBUGGER\r\n'


or python-pexpect:

 >   assert res.strip() == '11'
E   AssertionError: assert '\x1b[?2004l\...\n\x1b[?2004h' == '11'
E - 11
E + [?2004l
E + 11
E + [?2004h

And more...

Also ccing devel list for help.


There was some off-list discussion about this. A summary:

This is coming from the bracketed paste, which is enabled by default:

 https://lists.gnu.org/archive/html/bug-readline/2020-11/msg00010.html
 https://lists.gnu.org/archive/html/bug-bash/2020-10/msg00048.html
 https://lists.gnu.org/archive/html/bug-bash/2020-10/msg00087.html

The tests would already fail in the situations where user has enabled bracketed 
paste mode in their environments. Since Bash 5.1, this is the default, so the 
tests fail in mock. It might be a good idea to fix the tests (or sometimes even 
the implementation) to work with bracketed paste. However, as a stop-gap 
measure, this seem to work reliably:


  %check
  echo "set enable-bracketed-paste off" > .inputrc
  export INPUTRC=$PWD/.inputrc

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Scale_ZRAM_to_full_memory_size


== Summary ==
Fedora 33 [[Changes/SwapOnZRAM|enabled zram by default]]. The size of
the virtual swap devices was set so that the amount of memory used for
compressed swap pages was limited to a quarter of physical memory in
typical scenarios. That size is now increased to half of physical
memory (`zram-fraction` becomes 1.0, `max-zram-size` becomes 8 GiB).
This allows systems with small amounts to successfully launch the
[https://anaconda-installer.readthedocs.io/en/latest/ Anaconda
installer] and other programs.

== Owner ==

* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbys...@in.waw.pl
* Name: [[User:jwrdegoede|Hans de Goede]]
* Email: hdego...@redhat.com


== Detailed Description ==

When ZRAM was enabled by default in Fedora 33, the size of the device
(before compression) was limited to fraction 0.5 of RAM or 4 GiB,
whichever is less. The reason to limit the fraction to less than 1.0
is that with only incompressible data in memory, whole RAM would be
filled by the "compressed" pages, leaving no RAM for normal use. But
this concern seems to have been overblown, and there have been no
reports of compressed swap taking up too much memory. In real use, we
will have at least a few hundred MiB of code in memory, which
compresses quite well, so some compression will occur even when
working with incompressible data. In typical usage scenarios, we get
effective compression of 2:1 or 3:1, which means that the compressed
pages use at most between 1/4th and 1/6th of RAM. By increasing the
fraction to 1.0, we expect to consign up to half of RAM for compressed
pages.

Increasing the size of the device is important for small devices. For
devices with 1GB of RAM, sizing ZRAM to 1 GiB allows successful
installation with Anaconda. In general, it is expected that having
more compressed swap will make the device more functional after
installation too. This increase is the most important for devices with
small amounts of memory (< 1 GiB), but will be beneficial to systems
with slightly larger systems (1–8 GiB).

Technically, this change is completely trivial, amounting to two lines
of configuration. Nevertheless, there is some potential for problems
with incompressible workloads. The experience with ZRAM so far makes
the Change authors optimistic that no issues will be encountered, but
users and other developers should be aware of the change.


== Benefit to Fedora ==

Fedora works better on devices with low RAM. In particular, the
installer can function.

== Scope ==
* Proposal owners: change the defaults in `zram-generator-defaults`
package to `zram-fraction=1.0`, `max-zram-size=8096`.

* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
Default configuration is changed. Systems with local configuration
will not be affected. Systems which had zram-generator disabled will
not be affected.

== How To Test ==
Install the new version of the `zram-generator-defaults` package,
execute `sudo systemctl daemon-reload && sudo systemctl restart
swap-create@zram0`, use `zramctl` to check that the device has the
expected size. After some use, check that pages are compressed at
least with ration 2:1:

$ zramctl
NAME   ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle   7.6G   4K   74B   12K   4 [SWAP]
 ^   ^^
 |\\___ the ratio of those
values should be more than 2:1
 |
 `-- this should be approx the size of RAM

(Note that the device is destroyed and recreated during restart. This
means that all pages will be "swapped in", i.e. decompressed. On
machines with low memory, rebooting might be a better option.)

== User Experience ==
Not user visible.

== Dependencies ==
None.

== Contingency Plan ==
* Contingency mechanism: Revert default configuration to previous values.
* Contingency deadline: Final freeze, any time really.
* Blocks release? No
* Blocks product? No

== Documentation ==
None.

== Release Notes ==
The default size of compressed zram devices (`/dev/zram0`) has been
increased to 1.0 fraction of RAM, or 8 GiB, whichever is smaller.


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org

Fedora 34 Change: Comp Neuro Container Image (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Comp_Neuro_Container


== Summary ==
We will provide a Comp Neuro container image containing the same
computational neuroscience software that the CompNeuro Lab image
contains.
This will allow users to use the software using Podman/Docker also.

== Owner ==
* Name: [[User:bt0dotninja| Alberto Rodriguez Sanchez]],
[[User:Ankursinha| Ankur Sinha "FranciscoD"]], [[SIGs/NeuroFedora|
NeuroFedora SIG]]
* Email: `sanjay DOT ankur AT gmail.com`, `neuro-sig AT lists.fedoraproject.org`


== Detailed Description ==
The NeuroFedora team provides the CompNeuro Lab that includes a
plethora of software for modelling and simulating these neuroscience
models.
Nowadays, containers are frequently used in research work facilitating
model sharing and reproducibility.
To aid our users, we would like to provide a Fedora layered container
image that includes the same set of neuroscience software that the
CompNeuro Lab includes.


== Benefit to Fedora ==
This change allows users to use the complete set of CompNeuro packages
also using containers.

== Scope ==
* Proposal owners: It is an isolated change. It requires us to submit
a new container review (already submitted
[https://bugzilla.redhat.com/show_bug.cgi?id=1913491 here]). Once the
review has been completed, the proposal owners will build the
container image using `fedpkg` and push it out as updates.

* Other developers: N/A (not a System Wide Change)
* Release engineering: Does not require release engineering to do
anything. The standard package/container review process will be used.
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: it is not directly related to any
objectives currently.


== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==
N/A (not a System Wide Change)

== User Experience ==
In addition to the CompNeuro lab image, users will also be able to use
the container image.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)licable for
Changes that blocks specific product release/Fedora.next -->

== Documentation ==

The [https://docs.fedoraproject.org/en-US/neurofedora/containers/
page] in NeuroFedora documentation dealing with containers already
includes information on using general Fedora containers.
It will be updated to also include information on the CompNeuro container.


== Release Notes ==
A mention of the new container image would be very useful.



-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org

Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Scale_ZRAM_to_full_memory_size


== Summary ==
Fedora 33 [[Changes/SwapOnZRAM|enabled zram by default]]. The size of
the virtual swap devices was set so that the amount of memory used for
compressed swap pages was limited to a quarter of physical memory in
typical scenarios. That size is now increased to half of physical
memory (`zram-fraction` becomes 1.0, `max-zram-size` becomes 8 GiB).
This allows systems with small amounts to successfully launch the
[https://anaconda-installer.readthedocs.io/en/latest/ Anaconda
installer] and other programs.

== Owner ==

* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbys...@in.waw.pl
* Name: [[User:jwrdegoede|Hans de Goede]]
* Email: hdego...@redhat.com


== Detailed Description ==

When ZRAM was enabled by default in Fedora 33, the size of the device
(before compression) was limited to fraction 0.5 of RAM or 4 GiB,
whichever is less. The reason to limit the fraction to less than 1.0
is that with only incompressible data in memory, whole RAM would be
filled by the "compressed" pages, leaving no RAM for normal use. But
this concern seems to have been overblown, and there have been no
reports of compressed swap taking up too much memory. In real use, we
will have at least a few hundred MiB of code in memory, which
compresses quite well, so some compression will occur even when
working with incompressible data. In typical usage scenarios, we get
effective compression of 2:1 or 3:1, which means that the compressed
pages use at most between 1/4th and 1/6th of RAM. By increasing the
fraction to 1.0, we expect to consign up to half of RAM for compressed
pages.

Increasing the size of the device is important for small devices. For
devices with 1GB of RAM, sizing ZRAM to 1 GiB allows successful
installation with Anaconda. In general, it is expected that having
more compressed swap will make the device more functional after
installation too. This increase is the most important for devices with
small amounts of memory (< 1 GiB), but will be beneficial to systems
with slightly larger systems (1–8 GiB).

Technically, this change is completely trivial, amounting to two lines
of configuration. Nevertheless, there is some potential for problems
with incompressible workloads. The experience with ZRAM so far makes
the Change authors optimistic that no issues will be encountered, but
users and other developers should be aware of the change.


== Benefit to Fedora ==

Fedora works better on devices with low RAM. In particular, the
installer can function.

== Scope ==
* Proposal owners: change the defaults in `zram-generator-defaults`
package to `zram-fraction=1.0`, `max-zram-size=8096`.

* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
Default configuration is changed. Systems with local configuration
will not be affected. Systems which had zram-generator disabled will
not be affected.

== How To Test ==
Install the new version of the `zram-generator-defaults` package,
execute `sudo systemctl daemon-reload && sudo systemctl restart
swap-create@zram0`, use `zramctl` to check that the device has the
expected size. After some use, check that pages are compressed at
least with ration 2:1:

$ zramctl
NAME   ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle   7.6G   4K   74B   12K   4 [SWAP]
 ^   ^^
 |\\___ the ratio of those
values should be more than 2:1
 |
 `-- this should be approx the size of RAM

(Note that the device is destroyed and recreated during restart. This
means that all pages will be "swapped in", i.e. decompressed. On
machines with low memory, rebooting might be a better option.)

== User Experience ==
Not user visible.

== Dependencies ==
None.

== Contingency Plan ==
* Contingency mechanism: Revert default configuration to previous values.
* Contingency deadline: Final freeze, any time really.
* Blocks release? No
* Blocks product? No

== Documentation ==
None.

== Release Notes ==
The default size of compressed zram devices (`/dev/zram0`) has been
increased to 1.0 fraction of RAM, or 8 GiB, whichever is smaller.


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 34 Change: Comp Neuro Container Image (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Comp_Neuro_Container


== Summary ==
We will provide a Comp Neuro container image containing the same
computational neuroscience software that the CompNeuro Lab image
contains.
This will allow users to use the software using Podman/Docker also.

== Owner ==
* Name: [[User:bt0dotninja| Alberto Rodriguez Sanchez]],
[[User:Ankursinha| Ankur Sinha "FranciscoD"]], [[SIGs/NeuroFedora|
NeuroFedora SIG]]
* Email: `sanjay DOT ankur AT gmail.com`, `neuro-sig AT lists.fedoraproject.org`


== Detailed Description ==
The NeuroFedora team provides the CompNeuro Lab that includes a
plethora of software for modelling and simulating these neuroscience
models.
Nowadays, containers are frequently used in research work facilitating
model sharing and reproducibility.
To aid our users, we would like to provide a Fedora layered container
image that includes the same set of neuroscience software that the
CompNeuro Lab includes.


== Benefit to Fedora ==
This change allows users to use the complete set of CompNeuro packages
also using containers.

== Scope ==
* Proposal owners: It is an isolated change. It requires us to submit
a new container review (already submitted
[https://bugzilla.redhat.com/show_bug.cgi?id=1913491 here]). Once the
review has been completed, the proposal owners will build the
container image using `fedpkg` and push it out as updates.

* Other developers: N/A (not a System Wide Change)
* Release engineering: Does not require release engineering to do
anything. The standard package/container review process will be used.
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: it is not directly related to any
objectives currently.


== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==
N/A (not a System Wide Change)

== User Experience ==
In addition to the CompNeuro lab image, users will also be able to use
the container image.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)licable for
Changes that blocks specific product release/Fedora.next -->

== Documentation ==

The [https://docs.fedoraproject.org/en-US/neurofedora/containers/
page] in NeuroFedora documentation dealing with containers already
includes information on using general Fedora containers.
It will be updated to also include information on the CompNeuro container.


== Release Notes ==
A mention of the new container image would be very useful.



-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: gate stable release critical path updates on openQA test results

[Adam Williamson]

On Mon, 2021-01-11 at 15:41 +0100, Kevin Kofler via devel wrote:
> Matthew Miller wrote:
> > And, also hopefully also a rare occasion, but if this were enabled (and
> > the definitions up to date), problems like
> > 
> https://lists.fedoraproject.org/archives/list/us...@lists.fedoraproject.org/thread/CAS6KHTZLR6LUNWEVK3BOIO6HVNQDETZ/#N5HJDKMTGOTL44BT2HZ43LE6Q23345IQ
> > would be caught before they hit users.
> 
> This issue was a result of using autopush. See also:
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-5da509fd8e#comment-1807700
> A maintainer would normally not manually push an update before the library 
> update it depends on, the autopush logic was what made that accident happen.

Well, but maintainers *did*, back before we had autopush.

You might just as well say "a maintainer would not normally enable
autopush if they're submitting an update that depends on another update
that is not yet stable", because they shouldn't. But they do. All the
time.

Maintainers get stuff wrong sometimes. We've tweaked the mechanisms in
various ways for more than a decade and that hasn't stopped happening
yet. Even if we changed Bodhi to precisely your preferred
configuration, I'm gonna posit that maintainers would still manage to
get stuff wrong sometimes. :)
-- 
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

[Bug 1914983] New: Upgrade perl-Gtk2-SourceView2 to 0.12

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914983

Bug ID: 1914983
   Summary: Upgrade perl-Gtk2-SourceView2 to 0.12
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Gtk2-SourceView2
  Assignee: thomas.mosc...@gmx.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
thomas.mosc...@gmx.de
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 0.10 version. Upstream released 0.12. When you have free
time, please upgrade it.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1914982] New: Upgrade perl-Email-MIME-ContentType to 1.026

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914982

Bug ID: 1914982
   Summary: Upgrade perl-Email-MIME-ContentType to 1.026
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Email-MIME-ContentType
  Assignee: spo...@gmail.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org,
rob.my...@gtri.gatech.edu, spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 1.024 version. Upstream released 1.026. When you have
free time, please upgrade it.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1914981] New: Upgrade perl-DateTime-Calendar-Julian to 0.103

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914981

Bug ID: 1914981
   Summary: Upgrade perl-DateTime-Calendar-Julian to 0.103
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DateTime-Calendar-Julian
  Assignee: spo...@gmail.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 0.102 version. Upstream released 0.103. When you have
free time, please upgrade it.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1914174] Upgrade perl-Config-Model-TkUI to 1.373

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914174

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Config-Model-TkUI-1.37
   ||3-1.fc34
 Resolution|--- |RAWHIDE
Last Closed||2021-01-11 16:20:14




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1914939] Bad dependency on perl(Apache2::Log)

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914939

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Log-Dispatch-2.70-2.fc
   ||34
 Resolution|--- |RAWHIDE
Last Closed||2021-01-11 15:57:33




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1414996] please stop sending email to root in build tests

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1414996

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com
   Fixed In Version||perl-Log-Dispatch-2.70-2.fc
   ||34
 Resolution|EOL |RAWHIDE
   Assignee|tcall...@redhat.com |ppi...@redhat.com




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Non-responsive maintainer Eduardo Augusto Mayorga (mayorga)

[Nils Philippsen]

Hey,

On Sat, 2021-01-09 at 08:21 -0600, Eduardo A. Mayorga wrote:
> Hello,
> 
> El 1/8/21 a las 7:55 AM, Nils Philippsen escribió:
> > Happy New Year everyone!
> > 
> > I've tried to get in touch with Eduardo concerning co-
> > maintainership of
> > the python-rfc3987 package for EPEL8 a couple times at/after
> > December
> > 7th and haven't heard back from him.
> 
> I truly apologize for the delay in my response; I somehow missed that
> email. I have added the infra-sig group as an admin and BZ assignee
> for
> the EPEL branch.

thanks! I've closed the corresponding bug.

Nils
-- 
Nils Philippsen"Those who would give up Essential Liberty to
Software Engineer   purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:  D0C1 1576 CDA6 5B6E BBAE  95B2 7D53 7FCA E9F6 395D
old:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
___
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

Re: Orphaned packages looking for new maintainers

[Marius Schwarz]

Am 11.01.21 um 16:07 schrieb Vitaly Zaitsev via devel:

On 11.01.2021 14:43, Peter Lemenkov wrote:

XMPP-based and it looks like XMPP days
are numbered.


XMPP is alive. I maintain 2 XMPP clients in Fedora.



I just tried Jitsi latest Build 5633 on Fedora 32 and it started and run 
... for approximatly 10 seconds before it crashed :)


It still relies on Java 1.8 where Java 15 is the current release. Even 
with Java 11 it did not even compile in 1.8 mode. it will be a lot of work
to get all the old constructions out of the code before we can even 
think to run it with Java 11+.


If i get it to work proper with the help of the devs, I hope to get it 
back into Fedora Copr or stable.



Best regards,
Marius

___
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

Fedora-Rawhide-20210111.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp
Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
2 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 10/122 (aarch64), 10/180 (x86_64)

New failures (same test not failed in Fedora-Rawhide-20210110.n.0):

ID: 754344  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/754344
ID: 754393  Test: aarch64 Workstation-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/754393

Old failures (same test failed in Fedora-Rawhide-20210110.n.0):

ID: 754267  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/754267
ID: 754282  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/754282
ID: 754287  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/754287
ID: 754289  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/754289
ID: 754299  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/754299
ID: 754308  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/754308
ID: 754310  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/754310
ID: 754322  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/754322
ID: 754390  Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/754390
ID: 754397  Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/754397
ID: 754399  Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/754399
ID: 754462  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/754462
ID: 754489  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/754489
ID: 754516  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/754516
ID: 754521  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/754521
ID: 754525  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/754525
ID: 754530  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/754530
ID: 754531  Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/754531

Soft failed openQA tests: 7/180 (x86_64), 4/122 (aarch64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20210110.n.0):

ID: 754291  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/754291

Old soft failures (same test soft failed in Fedora-Rawhide-20210110.n.0):

ID: 754236  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/754236
ID: 754240  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/754240
ID: 754330  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/754330
ID: 754340  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/754340
ID: 754365  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/754365
ID: 754383  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/754383
ID: 754406  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/754406
ID: 754417  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/754417
ID: 754420  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/754420
ID: 754479  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/754479

Passed openQA tests: 163/180 (x86_64), 108/122 (aarch64)

New passes (same test not passed in Fedora-Rawhide-20210110.n.0):

ID: 754228  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/754228
ID: 754229  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/754229
ID: 754339  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/754339
ID: 754370  Test: aarch64 Server-dvd-iso 

Re: Orphaned packages looking for new maintainers

[Vitaly Zaitsev via devel]

On 11.01.2021 14:43, Peter Lemenkov wrote:

XMPP-based and it looks like XMPP days
are numbered.


XMPP is alive. I maintain 2 XMPP clients in Fedora.

--
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

Re: ELN build order

[Vít Ondruch]

Dne 11. 01. 21 v 15:15 Stephen Gallagher napsal(a):



On Mon, Jan 11, 2021 at 5:55 AM Vít Ondruch > wrote:


Can the ELN be fixed to stop doing rebuild like this? Of course
the issue is not in rubygem-thin but the issue is that once the
Ruby side tag was merged, ELN did not bothered with build order
and now there is rubygem-eventmachine which was built against Ruby
2.7 where is should have been build against Ruby 3.0. I can't
rebuild it, because that would require release bump in Fedora (I
don't want to do that, because Fedora maintainers should not be
bothered with ELN, right?).

I think that ELN should try to follow the Rawhide build order. If
it can't do that, then it should wait for manual intervention.


This is on our todo list, but we have been balancing a lot of things 
at the same time and haven't been able to get to it yet. Believe me, 
we want this fixed ASAP because it causes us (the ELN maintainers) a 
lot of problems.


I think that ELN should have done gating or scratch build and
check if the dependencies are the same as in Rawhide or something.


I'm not sure where or when in the process you are suggesting this 
would happen. ELN gates the compose, but not the builds.



When ELN built rubygem-eventmachine, it should have make sure that the 
dependencies are as expected. If rubygem-eventmachine depends in Rawhide 
on libruby.so.3.0()(64bit), then the dependency on 
libruby.so.2.7()(64bit) should trigger alarm.


Also, rubygem-eventmachine should be installable after rebuild. But 
certainly, there might happen race conditions a it happened this time.




I think that ELN should check the build result for dependency
issue and stop blindly submitting builds.

Again, I'm not sure what you're asking for, here.



For a human, single rebuild and check of log for rubygem-thin would 
reveal that something is wrong with rubygem-eventmachine. This could be 
detected from root.log and flagged. More builds are not needed.



Vít



OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Marius Schwarz]

Am 11.01.21 um 14:43 schrieb Peter Lemenkov:

Didn't touch Jitsi for a while but their Git repository looks active:

https://github.com/jitsi/jitsi


They focus on Jitsi Meet.. the last stable jitsi desktop build was 2017  
and the last one, has prebuild windows versions only.
The Downloadsection focuses on Jitsi Meet, which is just a video 
conference tool, not a messanger app anymore.


The last two commits have a pause of 6 months between them. It looks to 
me as if Ingo tries to hold up the flag or it's just updates to part, 
they recycled in Meet Jitsi.



The problem is that Jitsi is XMPP-based and it looks like XMPP days
are numbered.

I disagree here.

best regards,
marius
___
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

[rpms/perl-gettext] PR #1: Remove __make buildrequires

[Timm Bäder]

tbaeder opened a new pull-request against the project: `perl-gettext` that you 
are following:
``
Remove __make buildrequires
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-gettext/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Chromium built in rawhide does not render most strings

[Kevin Kofler via devel]

Florian Weimer wrote:
> It's not.  It may be a completely different system call.
> 
> Is there a way to get logging of filtered system calls from the sandbox?

What I'd suggest doing is strace-ing the rendering process in the version 
built against glibc 2.32 vs. the version built against glibc 2.33/2.32.9x 
and compare the syscalls it uses, to see what changed.

I see a few syscall use changes in glibc, but they are in .c files, not in 
.h files, so I am surprised that the version of glibc used at build time 
apparently matters.

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

[Bug 1914939] Bad dependency on perl(Apache2::Log)

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914939



--- Comment #3 from Tom "spot" Callaway  ---
I'm sure someone will file a bug if it's missed later. :) I think it's fine to
exclude it for RHEL 9 now.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Proposal: gate stable release critical path updates on openQA test results

[Kevin Kofler via devel]

Matthew Miller wrote:
> And, also hopefully also a rare occasion, but if this were enabled (and
> the definitions up to date), problems like
> 
https://lists.fedoraproject.org/archives/list/us...@lists.fedoraproject.org/thread/CAS6KHTZLR6LUNWEVK3BOIO6HVNQDETZ/#N5HJDKMTGOTL44BT2HZ43LE6Q23345IQ
> would be caught before they hit users.

This issue was a result of using autopush. See also:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-5da509fd8e#comment-1807700
A maintainer would normally not manually push an update before the library 
update it depends on, the autopush logic was what made that accident happen.

Another autopush issue has just happened on F32:
https://pagure.io/releng/issue/9943

We don't need more automagic, it will only make things worse. We need 
sentient beings taking care of pushes.

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

[rpms/perl-Test-Taint] PR #1: Remove __make buildrequires

[Timm Bäder]

tbaeder opened a new pull-request against the project: `perl-Test-Taint` that 
you are following:
``
Remove __make buildrequires
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Test-Taint/pull-request/1
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

Re: Proposal: gate stable release critical path updates on openQA test results

[Miro Hrončok]

On 11. 01. 21 15:28, David Cantrell wrote:

On Sat, Jan 09, 2021 at 12:27:32PM +0100, Vitaly Zaitsev via devel wrote:

On 08.01.2021 23:24, Matthew Miller wrote:

I think we should get to the point where it blocks manual pushes (without
the failure being waved). If the test is broken, fix the test.


Some tests are permanently broken. For example rpminspect-pipeline - filesize.

It's okay when the size of the files in the package changes, but it always 
fails.


Have you filed a bug about this at
https://github.com/rpminspect/rpminspect ?

Though thinking about it, I am not even sure the filesize check is
really important for Fedora builds anyway.  It might be more
appropriate to just turn it off for Fedora builds in
rpminspect-data-fedora
(https://github.com/rpminspect/rpminspect-data-fedora)


IMHO it makes sense to run it, but have some (higher) relative tolerance.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1914939] Bad dependency on perl(Apache2::Log)

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914939



--- Comment #2 from Petr Pisar  ---
And yet another question: May I disable the Log/Dispatch/ApacheLog.pm
subpackage on RHEL ≥ 9? Or you do you want to keep it enabled for EPEL 9?


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1914939] Bad dependency on perl(Apache2::Log)

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914939

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|spo...@gmail.com|ppi...@redhat.com




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1914939] Bad dependency on perl(Apache2::Log)

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914939



--- Comment #1 from Tom "spot" Callaway  ---
Feel free.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/perl-Params-Util] PR #2: Remove __make build requires

[Timm Bäder]

tbaeder opened a new pull-request against the project: `perl-Params-Util` that 
you are following:
``
Remove __make build requires
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Params-Util/pull-request/2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Proposal: gate stable release critical path updates on openQA test results

[David Cantrell]

On Sat, Jan 09, 2021 at 12:27:32PM +0100, Vitaly Zaitsev via devel wrote:

On 08.01.2021 23:24, Matthew Miller wrote:

I think we should get to the point where it blocks manual pushes (without
the failure being waved). If the test is broken, fix the test.


Some tests are permanently broken. For example rpminspect-pipeline - 
filesize.


It's okay when the size of the files in the package changes, but it 
always fails.


Have you filed a bug about this at
https://github.com/rpminspect/rpminspect ?

Though thinking about it, I am not even sure the filesize check is
really important for Fedora builds anyway.  It might be more
appropriate to just turn it off for Fedora builds in
rpminspect-data-fedora
(https://github.com/rpminspect/rpminspect-data-fedora)

Thanks,

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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

[Bug 1914939] New: Bad dependency on perl(Apache2::Log)

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914939

Bug ID: 1914939
   Summary: Bad dependency on perl(Apache2::Log)
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Log-Dispatch
  Assignee: spo...@gmail.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org,
rc040...@freenet.de, spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



perl-Log-Dispatch-2.70-1.fc34 build-requires perl(Apache2::Log). But the
dependency is not exhibited when running the tests. The package should stop
build-requiring perl(Apache2::Log).

perl-Log-Dispatch-2.70-1.fc34.noarch delivers
/usr/share/perl5/vendor_perl/Log/Dispatch/ApacheLog.pm which "require
Apache2::Log;", but the package is missing a run-time dependency on
perl(Apache2::Log). The package should run-require perl(Apache2::Log).

I recommend splitting the Log/Dispatch/ApacheLog.pm file into a separate
subpackage because a transitive dependency on mod_perl would be obtrusive to
many users.

I can resolve all these issues for you if you don't mind.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: ELN build order

[Stephen Gallagher]

On Mon, Jan 11, 2021 at 5:55 AM Vít Ondruch  wrote:

> Can the ELN be fixed to stop doing rebuild like this? Of course the issue
> is not in rubygem-thin but the issue is that once the Ruby side tag was
> merged, ELN did not bothered with build order and now there is
> rubygem-eventmachine which was built against Ruby 2.7 where is should have
> been build against Ruby 3.0. I can't rebuild it, because that would require
> release bump in Fedora (I don't want to do that, because Fedora maintainers
> should not be bothered with ELN, right?).
>
> I think that ELN should try to follow the Rawhide build order. If it can't
> do that, then it should wait for manual intervention.
>

This is on our todo list, but we have been balancing a lot of things at the
same time and haven't been able to get to it yet. Believe me, we want this
fixed ASAP because it causes us (the ELN maintainers) a lot of problems.


> I think that ELN should have done gating or scratch build and check if the
> dependencies are the same as in Rawhide or something.
>

I'm not sure where or when in the process you are suggesting this would
happen. ELN gates the compose, but not the builds.


> I think that ELN should check the build result for dependency issue and
> stop blindly submitting builds.
>
Again, I'm not sure what you're asking for, here.
___
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

Re: Orphaned packages looking for new maintainers

[Peter Lemenkov]

Didn't touch Jitsi for a while but their Git repository looks active:

https://github.com/jitsi/jitsi

The problem is that Jitsi is XMPP-based and it looks like XMPP days
are numbered.

пн, 11 янв. 2021 г. в 14:16, Marius Schwarz :
>
> Am 11.01.21 um 13:56 schrieb Peter Lemenkov:
> > We'd better have Jitsi (Java-based, beware!) ...  in repos.
>
> Jitsi is dead too :(
>
>
> In opposition to ekiga, Jitsi still works as expected.
>
> best regards,
> Marius
> ___
> 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



-- 
With best regards, Peter Lemenkov.
___
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

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2021-01-11.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains, see https://packager.fedorainfracloud.org/
For all orphaned packages, see https://packager.fedorainfracloud.org/orphan

Package  (co)maintainers   Status Change

apache-commons-chain  orphan   5 weeks ago
apache-log4j-extras   coolsvap, gil, orphan2 weeks ago
aseman-qt-tools   orphan   3 weeks ago
auto-destdir  orphan   1 weeks ago
azureus   orphan   2 weeks ago
banshee-community-extensions  elsupergomez, orphan, tpokorra   3 weeks ago
bip   adamwill, bcl, orphan5 weeks ago
boo   elsupergomez, orphan, tpokorra   2 weeks ago
clive orphan   1 weeks ago
csync2asalkeld, orphan, simonp 0 weeks ago
ekiga mcrha, orphan5 weeks ago
gnome-shell-extension-desktop-atim, orphan 5 weeks ago
icons
grpc  defolos, orphan  0 weeks ago
jabberpy  orphan   0 weeks ago
jvyamlb   orphan   3 weeks ago
lldpd orphan   0 weeks ago
msv   mizdebsk, orphan 2 weeks ago
nim   orphan   0 weeks ago
nodejs-shelljsnodejs-sig, orphan, patches  2 weeks ago
nodejs-svgo   nodejs-sig, orphan   2 weeks ago
nodoka-theme-gnomeorphan   2 weeks ago
opal  orphan, pfrields 5 weeks ago
pg-semver abrt-sig, mkutlak, orphan0 weeks ago
ptlib orphan, veillard 5 weeks ago
python-couchbase  orphan   0 weeks ago
python-junit_xml  orphan   0 weeks ago
python-kyotocabinet   orphan   0 weeks ago
python-ntlm-auth  orphan   0 weeks ago
python-pykafkaapevec, hguemar, jpena, orphan   3 weeks ago
python-requests-credssp   orphan   0 weeks ago
python-requests_ntlm  ignatenkobrain, orphan   0 weeks ago
python-social-auth-core   orphan   1 weeks ago
python-winrm  orphan   0 weeks ago
rubygem-debug_inspector   orphan   2 weeks ago
skipfish  athmane, orphan  5 weeks ago
sslh  orphan   0 weeks ago
sugar-starchart   callkalpa, chimosky, orphan  3 weeks ago
trac-accountmanager-pluginorphan   2 weeks ago
trac-spamfilter-pluginorphan   2 weeks ago

The following packages require above mentioned packages:
Depending on: auto-destdir (1), status change: 2020-12-30 (1 weeks ago)
corsix-th (maintained by: atim)
corsix-th-0.64-5.fc33.src requires auto-destdir = 1.11-18.fc33

Depending on: grpc (9), status change: 2021-01-04 (0 weeks ago)
buildstream (maintained by: atim, bochecha)
		buildstream-1.6.1-1.fc34.noarch requires python3-grpcio = 1.26.0-8.fc34, 
python3.9dist(grpcio) = 1.26

buildstream-1.6.1-1.fc34.src requires python3-grpcio = 
1.26.0-8.fc34

	ceph (maintained by: adeza, branto, dmick, ke4qqq, kkeithle, ktdreyer, steve, 
stingray)
		ceph-mgr-diskprediction-cloud-2:15.2.8-3.fc34.noarch requires python3-grpcio = 
1.26.0-8.fc34


  

Re: Orphaned packages looking for new maintainers

[Marius Schwarz]

Am 11.01.21 um 13:56 schrieb Peter Lemenkov:

We'd better have Jitsi (Java-based, beware!) ...  in repos.


Jitsi is dead too :(


In opposition to ekiga, Jitsi still works as expected.

best regards,
Marius
___
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

Re: Orphaned packages looking for new maintainers

[Antonio T. sagitter]

On 11/01/21 13:56, Peter Lemenkov wrote:

пн, 11 янв. 2021 г. в 13:10, Antonio T. sagitter :


On 11/01/21 11:47, Peter Lemenkov wrote:

Taking opal, ptlib

пн, 11 янв. 2021 г. в 11:37, Miro Hrončok :


ekiga mcrha, orphan5 weeks ago


I'm taking Ekiga.
It would be a shame letting die the rpm.


Might not be a good idea. Ekiga is dead long time ago, lacks behind
standards and RFCs, and might not be usable in some modern cases. I
personally advice you to let it go and look around for modern
alternatives.

We'd better have Jitsi (Java-based, beware!) or Jami in repos.



> I checked upstream, the current version is from 2013 and this repo

> https://github.com/ismaell/ekiga have 1585 commits ahead , 663 changed

> files with 155,735 additions and 168,142 deletions.


>
> IMHO will not be easy

Okay. Thanks.

--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Peter Lemenkov]

пн, 11 янв. 2021 г. в 13:10, Antonio T. sagitter :
>
> On 11/01/21 11:47, Peter Lemenkov wrote:
> > Taking opal, ptlib
> >
> > пн, 11 янв. 2021 г. в 11:37, Miro Hrončok :
> >>
> >> ekiga mcrha, orphan5 weeks 
> >> ago
>
> I'm taking Ekiga.
> It would be a shame letting die the rpm.

Might not be a good idea. Ekiga is dead long time ago, lacks behind
standards and RFCs, and might not be usable in some modern cases. I
personally advice you to let it go and look around for modern
alternatives.

We'd better have Jitsi (Java-based, beware!) or Jami in repos.

-- 
With best regards, Peter Lemenkov.
___
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

Re: Orphaned packages looking for new maintainers

[Sérgio Basto]

On Mon, 2021-01-11 at 13:09 +0100, Antonio T. sagitter wrote:
> On 11/01/21 11:47, Peter Lemenkov wrote:
> > Taking opal, ptlib
> > 
> > пн, 11 янв. 2021 г. в 11:37, Miro Hrončok :
> > > ekiga mcrha,
> > > orphan5 weeks ago
> 
> I'm taking Ekiga.
> It would be a shame letting die the rpm.

I checked upstream, the current version is from 2013 and this repo 
https://github.com/ismaell/ekiga have 1585 commits ahead , 663 changed
files with 155,735 additions and 168,142 deletions. 

IMHO will not be easy 

> ___
> 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
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20210111.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210110.n.0
NEW: Fedora-Rawhide-20210111.n.0

= SUMMARY =
Added images:9
Dropped images:  3
Added packages:  25
Dropped packages:8
Upgraded packages:   116
Downgraded packages: 0

Size of added packages:  68.36 MiB
Size of dropped packages:13.15 MiB
Size of upgraded packages:   942.11 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   3.76 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Xfce live x86_64
Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20210111.n.0.iso
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20210111.n.0.x86_64.vagrant-libvirt.box
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20210111.n.0.iso
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20210111.n.0.iso
Image: Xfce_Appliance raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Xfce-armhfp-Rawhide-20210111.n.0-sda.raw.xz
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20210111.n.0.iso
Image: SoaS raw-xz armhfp
Path: Spins/armhfp/images/Fedora-SoaS-armhfp-Rawhide-20210111.n.0-sda.raw.xz
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20210111.n.0.aarch64.raw.xz
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20210111.n.0.x86_64.vagrant-virtualbox.box

= DROPPED IMAGES =
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20210110.n.0.x86_64.vagrant-virtualbox.box
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20210110.n.0.x86_64.vagrant-libvirt.box
Image: KDE_Appliance raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20210110.n.0-sda.raw.xz

= ADDED PACKAGES =
Package: golang-github-facebookincubator-nvdtools-0.1.4-1.fc34
Summary: A collection of tools for working with National Vulnerability Database 
feeds
RPMs:golang-github-facebookincubator-nvdtools-devel nvdtools
Size:54.24 MiB

Package: python-pysam-0.16.0.1-1.fc34
Summary: pysam
RPMs:python-pysam-doc python3-pysam python3-pysam-devel
Size:12.54 MiB

Package: rust-alacritty_config_derive-0.1.0-1.fc34
Summary: Failure resistant deserialization derive
RPMs:rust-alacritty_config_derive+default-devel 
rust-alacritty_config_derive-devel
Size:25.69 KiB

Package: rust-assert_approx_eq-1.1.0-1.fc34
Summary: Assert approximately equal
RPMs:rust-assert_approx_eq+default-devel rust-assert_approx_eq-devel
Size:22.94 KiB

Package: rust-async-io-1.3.1-1.fc34
Summary: Async I/O and timers
RPMs:rust-async-io+default-devel rust-async-io-devel
Size:40.88 KiB

Package: rust-cache-padded-1.1.1-1.fc34
Summary: Prevent false sharing by padding and aligning to the length of a cache 
line
RPMs:rust-cache-padded+default-devel rust-cache-padded-devel
Size:23.84 KiB

Package: rust-concurrent-queue-1.2.2-1.fc34
Summary: Concurrent multi-producer multi-consumer queue
RPMs:rust-concurrent-queue+default-devel rust-concurrent-queue-devel
Size:30.88 KiB

Package: rust-console0.13-0.13.0-1.fc34
Summary: Terminal and console abstraction for Rust
RPMs:rust-console0.13+ansi-parsing-devel rust-console0.13+default-devel 
rust-console0.13+regex-devel rust-console0.13+unicode-width-devel 
rust-console0.13-devel
Size:58.58 KiB

Package: rust-cpython-0.5.2-1.fc34
Summary: Bindings to Python
RPMs:rust-cpython+default-devel rust-cpython+extension-module-devel 
rust-cpython+nightly-devel rust-cpython+no-auto-initialize-devel 
rust-cpython+nonnull-devel rust-cpython+py-link-mode-default-devel 
rust-cpython+py-link-mode-unresolved-static-devel rust-cpython+python-3-4-devel 
rust-cpython+python-3-5-devel rust-cpython+python-3-6-devel 
rust-cpython+python-3-7-devel rust-cpython+python-3-8-devel 
rust-cpython+python3-sys-devel rust-cpython+serde-convert-devel 
rust-cpython+serde-devel rust-cpython-devel
Size:203.88 KiB

Package: rust-ctor-0.1.17-1.fc34
Summary: __attribute__((constructor)) for Rust
RPMs:rust-ctor+default-devel rust-ctor-devel
Size:19.06 KiB

Package: rust-funty-1.1.0-1.fc34
Summary: Trait generalization over the primitive types
RPMs:rust-funty+default-devel rust-funty+std-devel rust-funty-devel
Size:31.88 KiB

Package: rust-futures-lite-1.11.3-1.fc34
Summary: Futures, streams, and async I/O combinators
RPMs:rust-futures-lite+alloc-devel rust-futures-lite+default-devel 
rust-futures-lite+fastrand-devel rust-futures-lite+futures-io-devel 
rust-futures-lite+parking-devel rust-futures-lite+std-devel 
rust-futures-lite+waker-fn-devel rust-futures-lite-devel
Size:91.08 KiB

Package: rust-ghost-0.1.2-1.fc34
Summary: Define your own PhantomData
RPMs:rust-ghost+default-devel rust-ghost-devel
Size

[Bug 1914675] perl-Pod-Strip-1.100 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914675

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Pod-Strip-1.100-1.fc34
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2021-01-11 12:27:49



--- Comment #3 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59430566


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Bash 5.1: stdout contains \x1b[?2004l\r376\r ?

[Miro Hrončok]

On 11. 01. 21 13:13, Miro Hrončok wrote:

Hello Siteshwar,

I see two Python packages that fail to test with Bash 5.1 due to 
\x1b[?2004l\r376\r or similar unexpectedly in captured stdout:


https://bugzilla.redhat.com/show_bug.cgi?id=1914782
https://bugzilla.redhat.com/show_bug.cgi?id=1914880

Is this anything you are aware of? What shall be done to fix this?

Thanks,


Actually, I see more:

https://koschei.fedoraproject.org/affected-by/bash?epoch1=0=5.0.17=3.fc34=0=5.1.0=1.fc34=f34

e.g. pytest:

child.expect("Pdb")
>   assert "\r\n'i=0.'\r\n" in child.before.decode("utf8")
E   assert "\r\n'i=0.'\r\n" in ") 'i=%i.' % 
i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h("
E+  where ") 'i=%i.' % i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h(" = 
('utf8')
E+where  = 
b") 'i=%i.' % i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h(".decode
E+  where b") 'i=%i.' % i\r\n\x1b[?2004l\r'i=0.'\r\n\x1b[?2004h(" = 
.before

/builddir/build/BUILD/pytest-6.0.2/testing/test_debugging.py:492: AssertionError

E   AssertionError: assert '\r\nENTERING RECURSIVE DEBUGGER\r\n' in 
'\r\n\x1b[?2004hdebug set_trace()\r\n\x1b[?2004l\rENTERING RECURSIVE DEBUGGER\r\n'


or python-pexpect:

>   assert res.strip() == '11'
E   AssertionError: assert '\x1b[?2004l\...\n\x1b[?2004h' == '11'
E - 11
E + [?2004l
E + 11
E + [?2004h

And more...

Also ccing devel list for help.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1914664] perltidy-20210111 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914664

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perltidy-20210111-1.fc34
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2021-01-11 12:10:15



--- Comment #2 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59427905


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Antonio T. sagitter]

On 11/01/21 11:47, Peter Lemenkov wrote:

Taking opal, ptlib

пн, 11 янв. 2021 г. в 11:37, Miro Hrončok :


ekiga mcrha, orphan5 weeks ago


I'm taking Ekiga.
It would be a shame letting die the rpm.

--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

proposal: move Data Corruption criterion from Final to Beta

[Kamil Paral]

Hello, I already sent this proposal (quoted below) to the test list last
week. Please read the existing discussion at:
https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/BFN427ECEZTGYCDKHJYH6VWWTGDA2BSG/

So far, I collected a thumbs up from Chris Murphy and Ben Cotton. I'm
forwarding it also here to the devel list, to collect more feedback, if
there is any.

Thanks,
Kamil

-- Forwarded message -
From: Kamil Paral 
Date: Thu, Jan 7, 2021 at 1:44 PM
Subject: proposal: move Data Corruption criterion from Final to Beta
To: test 

I propose we move the existing Data Corruption criterion from Final to
Beta. The criterion sounds like this:
"All known bugs that can cause corruption of user data must be fixed or
documented at Common F34 bugs."
https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#Data_corruption
(see footnotes for some additional details)

The reason for this proposal is this bugzilla [1] and this blocker ticket
[2] where we discussed whether we should ship an older Firefox on F33 Beta
media, which was known to completely wipe the whole user profile on
upgraded systems. We didn't (and still don't) have any release criterion
which says that this situation should not occur. Fortunately, in the F33
Beta case, we managed to ship a fixed version of Firefox in time, and so we
didn't really need to make a decision back then.

I talked about this problem in general in [2], and I said:
"I support moving the Data Corruption criterion to Beta, with the rationale
that we also require system upgrades to be fully working at Beta, and that
puts testers into a tough place where they are recommended to upgrade but
might lose personal data. It seems to me that those two things should be
coupled together, for important cases (like this one, IMO). The corruption
criterion allows us to decide when we want to demand the fix and when it's
enough to have it documented. If e.g. all my history+bookmarks+passwords
get purged from Firefox or if e.g. my ~/Documents folder gets removed on
Beta upgrade, I believe we should have an option to block the Beta release.
At the same time, we don't need to apply it if you only lose e.g. your
color profiles in gnome-terminal. Currently your whole home can get purged
and we don't have a way to stop it in Beta, I find that a problem."

The criterion as currently written is flexible enough that it doesn't force
us to fix the issue, if we consider it low-risk or low-impact, but it
*enables us* to have that conversation and accept the high-risk or
high-impact issues as blockers. That's why I believe moving it to Beta
doesn't bring any downsides, just advantages.

Please comment, thank you.
Kamil

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1881495
[2] https://pagure.io/fedora-qa/blocker-review/issue/118
___
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

[Bug 1914367] perl-Net-HTTP-6.20 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914367



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-92700dc791 has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-92700dc791


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1914367] perl-Net-HTTP-6.20 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914367



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-cc1cde9ba7 has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-cc1cde9ba7


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1914367] perl-Net-HTTP-6.20 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914367

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Net-HTTP-6.20-1.fc34



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1914367] perl-Net-HTTP-6.20 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1914367

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

ELN build order

[Vít Ondruch]

Can the ELN be fixed to stop doing rebuild like this? Of course the 
issue is not in rubygem-thin but the issue is that once the Ruby side 
tag was merged, ELN did not bothered with build order and now there is 
rubygem-eventmachine which was built against Ruby 2.7 where is should 
have been build against Ruby 3.0. I can't rebuild it, because that would 
require release bump in Fedora (I don't want to do that, because Fedora 
maintainers should not be bothered with ELN, right?).


I think that ELN should try to follow the Rawhide build order. If it 
can't do that, then it should wait for manual intervention.


I think that ELN should have done gating or scratch build and check if 
the dependencies are the same as in Rawhide or something.


I think that ELN should check the build result for dependency issue and 
stop blindly submitting builds.




Vít




 Přeposlaná zpráva 
Předmět: 	bpeck/jenkins-continuous-infra.apps.ci.centos.org's 
rubygem-thin-1.7.2-16.eln108 failed to build

Datum:  Mon, 11 Jan 2021 08:49:37 + (GMT)
Od: notificati...@fedoraproject.org
Komu:   vondr...@redhat.com



Notification time stamped 2021-01-11 08:49:35 UTC

bpeck/jenkins-continuous-infra.apps.ci.centos.org's 
rubygem-thin-1.7.2-16.eln108 failed to build

http://koji.fedoraproject.org/koji/buildinfo?buildID=128

--
You received this message due to your preference settings at 
https://apps.fedoraproject.org/notifications/vondruch.id.fedoraproject.org/email/50912


OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Peter Lemenkov]

Taking opal, ptlib

пн, 11 янв. 2021 г. в 11:37, Miro Hrončok :
>
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
>
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2021-01-11.txt
> grep it for your FAS username and follow the dependency chain.
>
> For human readable dependency chains, see 
> https://packager.fedorainfracloud.org/
> For all orphaned packages, see https://packager.fedorainfracloud.org/orphan
>
>  Package  (co)maintainers   Status 
> Change
> 
> apache-commons-chain  orphan   5 weeks ago
> apache-log4j-extras   coolsvap, gil, orphan2 weeks ago
> aseman-qt-tools   orphan   3 weeks ago
> auto-destdir  orphan   1 weeks ago
> azureus   orphan   2 weeks ago
> banshee-community-extensions  elsupergomez, orphan, tpokorra   3 weeks ago
> bip   adamwill, bcl, orphan5 weeks ago
> boo   elsupergomez, orphan, tpokorra   2 weeks ago
> clive orphan   1 weeks ago
> csync2asalkeld, orphan, simonp 0 weeks ago
> ekiga mcrha, orphan5 weeks ago
> gnome-shell-extension-desktop-atim, orphan 5 weeks ago
> icons
> grpc  defolos, orphan  0 weeks ago
> jabberpy  orphan   0 weeks ago
> jvyamlb   orphan   3 weeks ago
> lldpd orphan   0 weeks ago
> msv   mizdebsk, orphan 2 weeks ago
> nim   orphan   0 weeks ago
> nodejs-shelljsnodejs-sig, orphan, patches  2 weeks ago
> nodejs-svgo   nodejs-sig, orphan   2 weeks ago
> nodoka-theme-gnomeorphan   2 weeks ago
> opal  orphan, pfrields 5 weeks ago
> pg-semver abrt-sig, mkutlak, orphan0 weeks ago
> ptlib orphan, veillard 5 weeks ago
> python-couchbase  orphan   0 weeks ago
> python-junit_xml  orphan   0 weeks ago
> python-kyotocabinet   orphan   0 weeks ago
> python-ntlm-auth  orphan   0 weeks ago
> python-pykafkaapevec, hguemar, jpena, orphan   3 weeks ago
> python-requests-credssp   orphan   0 weeks ago
> python-requests_ntlm  ignatenkobrain, orphan   0 weeks ago
> python-social-auth-core   orphan   1 weeks ago
> python-winrm  orphan   0 weeks ago
> rubygem-debug_inspector   orphan   2 weeks ago
> skipfish  athmane, orphan  5 weeks ago
> sslh  orphan   0 weeks ago
> sugar-starchart   callkalpa, chimosky, orphan  3 weeks ago
> trac-accountmanager-pluginorphan   2 weeks ago
> trac-spamfilter-pluginorphan   2 weeks ago
>
> The following packages require above mentioned packages:
> Depending on: auto-destdir (1), status change: 2020-12-30 (1 weeks ago)
> corsix-th (maintained by: atim)
> corsix-th-0.64-5.fc33.src requires auto-destdir = 1.11-18.fc33
>
> Depending on: grpc (9), status change: 2021-01-04 (0 weeks ago)
> buildstream (maintained by: atim, bochecha)
> buildstream-1.6.1-1.fc34.noarch requires python3-grpcio = 
> 1.26.0-8.fc34,
> python3.9dist(grpcio) = 1.26
> buildstream-1.6.1-1.fc34.src 

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2021-01-11.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains, see https://packager.fedorainfracloud.org/
For all orphaned packages, see https://packager.fedorainfracloud.org/orphan

Package  (co)maintainers   Status Change

apache-commons-chain  orphan   5 weeks ago
apache-log4j-extras   coolsvap, gil, orphan2 weeks ago
aseman-qt-tools   orphan   3 weeks ago
auto-destdir  orphan   1 weeks ago
azureus   orphan   2 weeks ago
banshee-community-extensions  elsupergomez, orphan, tpokorra   3 weeks ago
bip   adamwill, bcl, orphan5 weeks ago
boo   elsupergomez, orphan, tpokorra   2 weeks ago
clive orphan   1 weeks ago
csync2asalkeld, orphan, simonp 0 weeks ago
ekiga mcrha, orphan5 weeks ago
gnome-shell-extension-desktop-atim, orphan 5 weeks ago
icons
grpc  defolos, orphan  0 weeks ago
jabberpy  orphan   0 weeks ago
jvyamlb   orphan   3 weeks ago
lldpd orphan   0 weeks ago
msv   mizdebsk, orphan 2 weeks ago
nim   orphan   0 weeks ago
nodejs-shelljsnodejs-sig, orphan, patches  2 weeks ago
nodejs-svgo   nodejs-sig, orphan   2 weeks ago
nodoka-theme-gnomeorphan   2 weeks ago
opal  orphan, pfrields 5 weeks ago
pg-semver abrt-sig, mkutlak, orphan0 weeks ago
ptlib orphan, veillard 5 weeks ago
python-couchbase  orphan   0 weeks ago
python-junit_xml  orphan   0 weeks ago
python-kyotocabinet   orphan   0 weeks ago
python-ntlm-auth  orphan   0 weeks ago
python-pykafkaapevec, hguemar, jpena, orphan   3 weeks ago
python-requests-credssp   orphan   0 weeks ago
python-requests_ntlm  ignatenkobrain, orphan   0 weeks ago
python-social-auth-core   orphan   1 weeks ago
python-winrm  orphan   0 weeks ago
rubygem-debug_inspector   orphan   2 weeks ago
skipfish  athmane, orphan  5 weeks ago
sslh  orphan   0 weeks ago
sugar-starchart   callkalpa, chimosky, orphan  3 weeks ago
trac-accountmanager-pluginorphan   2 weeks ago
trac-spamfilter-pluginorphan   2 weeks ago

The following packages require above mentioned packages:
Depending on: auto-destdir (1), status change: 2020-12-30 (1 weeks ago)
corsix-th (maintained by: atim)
corsix-th-0.64-5.fc33.src requires auto-destdir = 1.11-18.fc33

Depending on: grpc (9), status change: 2021-01-04 (0 weeks ago)
buildstream (maintained by: atim, bochecha)
		buildstream-1.6.1-1.fc34.noarch requires python3-grpcio = 1.26.0-8.fc34, 
python3.9dist(grpcio) = 1.26

buildstream-1.6.1-1.fc34.src requires python3-grpcio = 
1.26.0-8.fc34

	ceph (maintained by: adeza, branto, dmick, ke4qqq, kkeithle, ktdreyer, steve, 
stingray)
		ceph-mgr-diskprediction-cloud-2:15.2.8-3.fc34.noarch requires python3-grpcio = 
1.26.0-8.fc34