Fedora-Rawhide-20210201.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp
Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
5 of 43 required tests failed, 8 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 17/181 (x86_64), 13/123 (aarch64)

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

ID: 767601  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/767601
ID: 767673  Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/767673
ID: 767675  Test: aarch64 Server-dvd-iso 
install_repository_nfs_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/767675
ID: 767679  Test: aarch64 Server-dvd-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/767679
ID: 767829  Test: aarch64 universal install_anaconda_text@uefi
URL: https://openqa.fedoraproject.org/tests/767829
ID: 767853  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/767853

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

ID: 767607  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/767607
ID: 767612  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/767612
ID: 767624  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/767624
ID: 767643  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/767643
ID: 767646  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/767646
ID: 767677  Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/767677
ID: 767742  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/767742
ID: 767745  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/767745
ID: 767748  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/767748
ID: 767764  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/767764
ID: 767765  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/767765
ID: 767768  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/767768
ID: 767769  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/767769
ID: 767773  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/767773
ID: 767822  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/767822
ID: 767830  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/767830
ID: 767831  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/767831
ID: 767832  Test: aarch64 universal install_european_language@uefi
URL: https://openqa.fedoraproject.org/tests/767832
ID: 767841  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/767841
ID: 767859  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/767859
ID: 767861  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/767861
ID: 767877  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/767877
ID: 767878  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/767878
ID: 767879  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/767879

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

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

ID: 767703  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/767703
ID: 767714  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/767714
ID: 767737  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/767737
ID: 767744  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/767744
ID: 767747  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/767747
ID: 767762  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https

Request to Become Maintainer of a Retired Package (diffuse) + Brief Intro

[Noinsit Sidhere]

Hey everyone! Fedora user and long-time GNU/Linux enthusiast here. I am doing 
my best at attempting to complete the requisite steps[1] for re-introducing the 
diffuse diff utility to the official Fedora repositories. This is a light - yet 
very capable - GUI diff tool, that integrates nicely with GNOME and other 
GTK-based environments. It was included in the default repos until a couple of 
releases back[2]. The project was revived somewhat recently, and has been 
ported to Python 3, seeing regular stable releases[3].

I currently administer a COPR repo[4] for said package, but believe it would be 
beneficial for more users to have access to this very nice program, without 
having to add an external repository. I am relatively new to packaging for 
Fedora, but have been steadily getting better at it, and am in communication 
with the current developer of diffuse[5]. I hope that I'm going about this the 
right way.

Please let me know if I should furnish any of you with additional information, 
otherwise I am onto the next step in this process.

Thanks for your consideration!

---
References:
01. https://bugzilla.redhat.com/show_bug.cgi?id=1905277#c2
02. https://src.fedoraproject.org/rpms/diffuse
03. https://github.com/MightyCreak/diffuse/releases
04. https://copr.fedorainfracloud.org/coprs/niohiani/Diffuse-Python-3/
05. https://github.com/MightyCreak/diffuse/issues/68
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Jami (formerly Ring) P2P softphone packaging?

[Sérgio Basto]

On Tue, 2021-02-02 at 00:28 +, Sérgio Basto wrote:
> Hi,
> 
> On Mon, 2021-02-01 at 19:49 +0100, Daniel Pocock wrote:
> > Has anybody tested the Jami softphone from Savoir-Faire Linux?  It
> > was
> > formerly known as Ring.
> > 
> > They distribute RPMs directly from the web site[1].  It is
> > already[2]
> > in
> > Debian for some time.
> > 
> > They distribute[3] their DHT as a library, OpenDHT, for use in
> > other
> > projects.
> > 
> > Regards,
> > 
> > Daniel
> > 
> > 1. https://jami.net/
> > 2. https://packages.qa.debian.org/r/ring.html
> > 3. https://github.com/savoirfairelinux/opendht
> 
> I have maintain some Debian tools on fedora for these cases :) we may
> do :
> 
> gpg  --recv-keys 0740778A2DFC4A39C0C8BC8C8F2B113C6535C5A7
> 
> from https://tracker.debian.org/pkg/ring you get the dsc link 
> 
> dget 
> https://deb.debian.org/debian/pool/main/r/ring/ring_20210104.4.dda80df~ds1-1.dsc
>  
> 
> cd ring-20210104.4.dda80df~ds1
> and you may try : debuild -i -us -uc -d
> 
> but source ring_20210104.4.dda80df~ds1.orig.tar.gz include fedora
> specs
> , so it is more simpler 
> 
> tar xf ring_20210104.4.dda80df~ds1.orig.tar.gz 
> cd ring-project/
> cp ring-project/packaging/rules/fedora/jami-one-click.spec . 
> cp ring-project/packaging/rules/fedora/jami.spec .
> mv ring_20210104.4.dda80df~ds1.orig.tar.gz
> jami_20210104.4.dda80df.tar.gz 
> sed -i -e 's/RELEASE_VERSION/20210104.4.dda80df/' jami.spec
> rpmbuild -bs jami.spec  --define "_sourcedir ." --define "_srcrpmdir
> ."
> 
> Wrote: ./jami-20210104.4.dda80df-0.fc32.src.rpm
> 
> mock -r fedora-32-x86_64 --no-clean --rebuild  ./jami-
> 20210104.4.dda80df-0.fc32.src.rpm
> 
> package done ... also we may check debian patches 
> cat ring-20210104.4.dda80df~ds1/debian/patches/jsoncpp-rename.patch 
> cat ring-20210104.4.dda80df~ds1/debian/patches/dont-build-
> gnutls.patch 

Sorry I hadn't finish this email, but seems will not be easy , ring
project needs ffmpeg , x264 not available in Fedora , and build try to
download other packages ... 

+ make list
All packages:
  argon2 asio dbus-cpp ffmpeg ffnvcodec fmt gcrypt gmp gnutls gpg-error
  gsm http_parser iconv jack jsoncpp libarchive libressl msgpack natpmp
  nettle opencv opencv_contrib opendht opus pjproject portaudio
restinio
  secp256k1 speex speexdsp upnp uuid vpx x264 yaml-cpp zlib
Distribution-provided packages:
  gnutls iconv jsoncpp libressl nettle opus speex upnp uuid yaml-cpp
zlib
Automatically selected packages:
  dbus-cpp ffmpeg fmt http_parser libarchive msgpack natpmp opendht
  pjproject restinio secp256k1 speexdsp
Manually deselected packages:
  flac gsm natpmp ogg sndfile speex speexdsp vorbis vorbisenc
Manually selected packages:
  None
Depended-on packages:
  argon2 asio ffnvcodec gmp vpx x264
To-be-built packages:
  argon2 asio dbus-cpp ffmpeg ffnvcodec fmt gmp http_parser libarchive
  msgpack opendht pjproject restinio secp256k1 vpx x264
+ make fetch
curl -sS -f -L --retry-delay 10 --retry 4 -- "
https://sourceforge.net/projects/dbus-cplusplus/files/dbus-c%2B%2B/0.9.0/libdbus-c%2B%2B-0.9.0.tar.gz/download
" > "../../contrib/tarballs/libdbus-c++-0.9.0.tar.gz"
curl: (6) Could not resolve host: sourceforge.net
curl: (6) Could not resolve host: sourceforge.net

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

Re: Jami (formerly Ring) P2P softphone packaging?

[Sérgio Basto]

On Mon, 2021-02-01 at 22:39 +0100, Peter Lemenkov wrote:
> Hello All!
> Regarding Jami - looks like this is the last opensource SIP-client
> around which works out-of-the box (no need for extra patches for
> recent versions of various libraries, local rebuilds, or git
> knowledge
> required). I use it for SIP testing (OpenSIPS, Kamailio, SEMS,
> Asterisk servers) and so far it works as expected. Few glitches here
> and there but I overall it's great. Considering how bad is the
> current
> situation with desktop clients for Voice and Video communications I
> would say it's a promising project.


and https://src.fedoraproject.org/rpms/linphone ?


> I didn't test P2P because nobody (around me) is using it. All my
> contacts are either in FB, Telegram, or Signal.
> 
> пн, 1 февр. 2021 г. в 19:49, Daniel Pocock :
> > 
> > Has anybody tested the Jami softphone from Savoir-Faire Linux?  It
> > was
> > formerly known as Ring.
> > 
> > They distribute RPMs directly from the web site[1].  It is
> > already[2] in
> > Debian for some time.
> > 
> > They distribute[3] their DHT as a library, OpenDHT, for use in
> > other
> > projects.
> > 
> > Regards,
> > 
> > Daniel
> > 
> > 1. https://jami.net/
> > 2. https://packages.qa.debian.org/r/ring.html
> > 3. https://github.com/savoirfairelinux/opendht
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/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
-- 
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

Re: Jami (formerly Ring) P2P softphone packaging?

[Sérgio Basto]

Hi,

On Mon, 2021-02-01 at 19:49 +0100, Daniel Pocock wrote:
> Has anybody tested the Jami softphone from Savoir-Faire Linux?  It
> was
> formerly known as Ring.
> 
> They distribute RPMs directly from the web site[1].  It is already[2]
> in
> Debian for some time.
> 
> They distribute[3] their DHT as a library, OpenDHT, for use in other
> projects.
> 
> Regards,
> 
> Daniel
> 
> 1. https://jami.net/
> 2. https://packages.qa.debian.org/r/ring.html
> 3. https://github.com/savoirfairelinux/opendht

I have maintain some Debian tools on fedora for these cases :) we may
do :

gpg  --recv-keys 0740778A2DFC4A39C0C8BC8C8F2B113C6535C5A7

from https://tracker.debian.org/pkg/ring you get the dsc link 

dget 
https://deb.debian.org/debian/pool/main/r/ring/ring_20210104.4.dda80df~ds1-1.dsc
 

cd ring-20210104.4.dda80df~ds1
and you may try : debuild -i -us -uc -d

but source ring_20210104.4.dda80df~ds1.orig.tar.gz include fedora specs
, so it is more simpler 

tar xf ring_20210104.4.dda80df~ds1.orig.tar.gz 
cd ring-project/
cp ring-project/packaging/rules/fedora/jami-one-click.spec . 
cp ring-project/packaging/rules/fedora/jami.spec .
mv ring_20210104.4.dda80df~ds1.orig.tar.gz
jami_20210104.4.dda80df.tar.gz 
sed -i -e 's/RELEASE_VERSION/20210104.4.dda80df/' jami.spec
rpmbuild -bs jami.spec  --define "_sourcedir ." --define "_srcrpmdir ."

Wrote: ./jami-20210104.4.dda80df-0.fc32.src.rpm

mock -r fedora-32-x86_64 --no-clean --rebuild  ./jami-
20210104.4.dda80df-0.fc32.src.rpm

package done ... also we may check debian patches 
cat ring-20210104.4.dda80df~ds1/debian/patches/jsoncpp-rename.patch 
cat ring-20210104.4.dda80df~ds1/debian/patches/dont-build-gnutls.patch 


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

Re: Jami (formerly Ring) P2P softphone packaging?

[Kevin Kofler via devel]

Daniel Pocock wrote:
> Has anybody tested the Jami softphone from Savoir-Faire Linux?  It was
> formerly known as Ring.
> 
> They distribute RPMs directly from the web site[1].  It is already[2] in
> Debian for some time.

Jami has a mandatory dependency on FFmpeg and as such is unsuitable for 
Fedora.

In addition, the fact that their preferred GNU/Linux client uses GTK+ and 
GNOME libraries whereas their underlying libraries are still based on Qt 
(which is still used for their Windows client, whereas the KDE client was 
sadly abandoned in favor of the GNOME one) leads to ugly issues such as:
https://github.com/tumic0/QtPBFImagePlugin/issues/6#issuecomment-613503545

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: ECL soname bump

[Jerry James]

On Mon, Feb 1, 2021 at 11:29 AM José Abílio Matos  wrote:
> Maxima failed to build on rawhide due to a crash on gcl on the configure 
> stage:
>
> https://kojipkgs.fedoraproject.org//work/tasks/9904/60929904/build.log

Thank you for pointing that out.  I think I see the problem.  I'm
testing a fix now and will push it if it fixes the issue.
-- 
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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Pavel Valena]

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, January 25, 2021 4:43:21 PM
> Subject: Policy proposal (draft): Don't push knowingly broken or 
> work-in-progress work to dist git
> 
> On Mon, Jan 25, 2021 at 4:37 PM Stephen Gallagher 
> wrote:
> >
> > On Mon, Jan 25, 2021 at 10:31 AM Miro Hrončok  wrote:
> > >
> > > On 25. 01. 21 16:19, Stephen Gallagher wrote:
> > > > I'm fully in favor of this and I'd really like to see us add some
> > > > degree of CI gating to support it.
> > >
> > > Note that unfortunately CI gating happens too late. It has no capability
> > > to
> > > block commits that fail to build, because it only tests successful builds
> > > and
> > > because it only tests already pushed changes. CI on Pull Requests can
> > > solve
> > > this, but many packagers seem to be very much agianst the idea of sending
> > > PRs to
> > > packages they maintain themselves :(
> > >
> >
> > There are still ways around this; we could disallow direct pushes to
> > release branches.
> >
> > Yes, there are always going to be people who reject any new approach
> > we might take, but we should carefully consider whether "some/many
> > packagers are mildly annoyed" exceeds the potential gains inherent in
> > fewer broken builds and composes.
> 
> For those few of us who maintain hundreds-thousands of packages,
> having everything go via a Pull Request is just not scalable as things
> are right now.
> 
> If packaging tools can "hide the details" around this in a reliable
> way so that packagers don't see what happens behind the scenes, then
> we can talk.
> 
> But that would involve at least six new steps that would've to be
> automated: 1) Creating a fork on src.fp.o (plus error handling around
> already existing forks), 2) Cloning the fork instead of the main repo,
> 3) Automatically creating a PR after a git push, 4) Automatically
> merging the PR if CI passes, 5) Deleting the fork, 6) Automatically
> building the package in koji ...

FWIW I have already created this tooling (and more) for maintaining my 
rubygem-* packages (and also creating updates). It can be generalized of 
course. :)

Example PR: 
https://src.fedoraproject.org/rpms/rubygem-benchmark-ips/pull-request/1

I'll be presenting this on DevConf.CZ. (No external git yet, sorry.)

Pavel

> 
> 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: Jami (formerly Ring) P2P softphone packaging?

[Jared K. Smith]

On Mon, Feb 1, 2021 at 1:58 PM Daniel Pocock  wrote:

> Has anybody tested the Jami softphone from Savoir-Faire Linux?  It was
> formerly known as Ring.
>

 I haven't looked at it in a couple of years, but last I looked at it, the
packaging was awful, and the interdependencies between sub-packages made me
walk away in disgust.  As somebody who spends the majority of my waking
hours these days dealing with SIP and telecommunications systems, I'd be
happy to donate an hour or two to see if we can improve things with regards
to SIP clients in Fedora.

-Jared
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Jami (formerly Ring) P2P softphone packaging?

[Peter Lemenkov]

Hello All!
Regarding Jami - looks like this is the last opensource SIP-client
around which works out-of-the box (no need for extra patches for
recent versions of various libraries, local rebuilds, or git knowledge
required). I use it for SIP testing (OpenSIPS, Kamailio, SEMS,
Asterisk servers) and so far it works as expected. Few glitches here
and there but I overall it's great. Considering how bad is the current
situation with desktop clients for Voice and Video communications I
would say it's a promising project.

I didn't test P2P because nobody (around me) is using it. All my
contacts are either in FB, Telegram, or Signal.

пн, 1 февр. 2021 г. в 19:49, Daniel Pocock :
>
>
> Has anybody tested the Jami softphone from Savoir-Faire Linux?  It was
> formerly known as Ring.
>
> They distribute RPMs directly from the web site[1].  It is already[2] in
> Debian for some time.
>
> They distribute[3] their DHT as a library, OpenDHT, for use in other
> projects.
>
> Regards,
>
> Daniel
>
> 1. https://jami.net/
> 2. https://packages.qa.debian.org/r/ring.html
> 3. https://github.com/savoirfairelinux/opendht
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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

Re: btrfs hash algorithm (should xxhash be the default?)

[Chris Murphy]

On Sun, Jan 31, 2021 at 11:57 AM Matthew Miller
 wrote:
>
> On my Intel i7 laptop, xxhash is a small but clear performance win over
> crc32c:
>
> $ ./hash-speedtest  1000
> Block size: 4096
> Iterations: 1000
> Implementation: builtin
>
> NULL-NOP: cycles:   1372543560, c/i  137
>  NULL-MEMCPY: cycles:   2844174884, c/i  284
>   CRC32C: cycles:   9673117404, c/i  967
>   XXHASH: cycles:   7129819594, c/i  712
>   SHA256: cycles: 649914613520, c/i64991
>  BLAKE2b: cycles: 153513008046, c/i15351
>
>
> And I'm given to understand that this is even more the case on newer CPUs.
>
> Plus, it's 64 bit instead of 32 bit. The 256-bit algorithms are obviously
> much, much slower and probably not right for a default, but should we
> consider making xxhash the default for Fedora Linux systems with btrfs?

I'm seeing:

[1.179693] Btrfs loaded, crc32c=crc32c-generic, zoned=yes

Someone adventurous might want to figure out how to get it to use
crc32c_intel instead. I think it might need to be compiled into the
kernel.

CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=m

And then retest.

But also, the difference in performance between xxhash and crc32c is
pretty tiny. I'm using all four hashes on various file systems, and up
until there's a heavy IO workload, there's no performance difference
among them.


-- 
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: btrfs hash algorithm (should xxhash be the default?)

[Chris Murphy]

On Mon, Feb 1, 2021 at 8:10 AM Kevin Kofler via devel
 wrote:
>
> Matthew Miller wrote:
>
> > On Mon, Feb 01, 2021 at 01:24:53PM +, David Howells wrote:
> >> Matthew Miller  wrote:
> >> > Plus, it's 64 bit instead of 32 bit. The 256-bit algorithms are
> >> > obviously much, much slower and probably not right for a default, but
> >> > should we consider making xxhash the default for Fedora Linux systems
> >> > with btrfs?
> >> Does this affect what's on disk?
> >
> > Yes; it changes the checksums stored with each block to be in the selected
> > format. This can only be changed at filesystem creation time.
>
> I guess the real question is: does it increase the required disk space or
> does it only fill up bits that would otherwise be padding bits?

Both.

Data block size is equal to page size, i.e. x86 is 4KiB. And there are
4 bytes of crc32c, and 8 bytes of xxhash, per data block. These are
stored in the csum tree. So moving to xxhash will double the csum
tree. On my ~24G file system, csum tree is ~32MB with crc32c and would
be ~64MB with xxhash. So, yeah it's 200% bigger, but not significant
in terms of either CPU or IO.

Metadata block size defaults to 16KiB on x86, so in this case whether
4 bytes or 8 bytes of checksu, it's the same block size, no additional
space is used.

More info on the available hashes
https://kdave.github.io/selecting-hash-for-btrfs/

I think we should just follow upstream because we don't have a good
way to use non-default mkfs options in the installer. If upstream has
a plan to switch to xxhash by default, we can adopt it earlier than
they do just because we don't have to worry about coordinating with
longterm kernel support. e.g. right now none of these hashes are in
kernel 5.4 which is the current long term kernel. Upstream takes that
into account. Fedora doesn't need to. But since the work on xxh3 is
completed, it's an open question if that's a better candidate for a
default, or if some other candidate appears.

So yeah - we need to coordinate with upstream at least to some degree.


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

[Kevin Fenzi]

On Mon, Feb 01, 2021 at 03:03:07PM -0500, Mohan Boddu wrote:
> Fedora 34 mass rebuild of rpms is done and we started running the mass
> rebuild of modules. FTBFS tickets [0] are being filed now.
> 
> [0] https://bugzilla.redhat.com/show_bug.cgi?id=1868278

Additionally, the eln mass rebuild is running now also. 

Since it's many fewer packages it should finish before too long... 

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

Re: btrfs hash algorithm (should xxhash be the default?)

[Richard W.M. Jones]

On Mon, Feb 01, 2021 at 09:44:40AM -0500, Matthew Miller wrote:
> On Mon, Feb 01, 2021 at 03:16:32PM +0100, drago01 wrote:
> > Comparing the hash algorithms in isolation doesn't mean much - does it make
> > a difference if you try various file system workloads with the different
> > algorithms?
> 
> Probably? I'd have to make sample filesystems to test and don't have spare
> hardware for doing so at hand. I'm more interested in expanding from 32-bit
> to 64-bit and the speed increase is a pleasant surprise rather than the main
> goal.

RAM disks!

  # nbdkit memory 10G
  # nbd-client -b 512 localhost /dev/nbd0

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Mass Rebuild

[Stephen Gallagher]

On Mon, Feb 1, 2021 at 3:04 PM Mohan Boddu  wrote:
>
> Fedora 34 mass rebuild of rpms is done and we started running the mass
> rebuild of modules. FTBFS tickets [0] are being filed now.
>

A mass-rebuild of ELN packages is also underway right now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Mass Rebuild

[Mohan Boddu]

Fedora 34 mass rebuild of rpms is done and we started running the mass
rebuild of modules. FTBFS tickets [0] are being filed now.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1868278



On Tue, Jan 26, 2021 at 1:25 PM Mohan Boddu  wrote:
>
> On Tue, Jan 26, 2021 at 10:52 AM Fabio Valentini  wrote:
> >
> > On Tue, Jan 26, 2021 at 4:47 PM Jonathan Wakely
> >  wrote:
> > >
> > > On 25/01/21 15:16 +0100, Fabio Valentini wrote:
> > > >On Thu, Jan 21, 2021 at 5:10 PM Jakub Jelinek  wrote:
> > > >>
> > > >> On Wed, Jan 20, 2021 at 02:17:28PM -0500, Mohan Boddu wrote:
> > > >> > We are delaying the mass rebuild by a day as of now due to bugs in 
> > > >> > gcc
> > > >> > and dwz. As of now, we are expecting to start mass rebuild tomorrow,
> > > >> > Jan 21st 2021. There is a new build of gcc running currently which 
> > > >> > has
> > > >> > fixes to gcc bugs, but we are still figuring out the dwz fixes. We
> > > >> > will keep you posted with any further developments.
> > > >>
> > > >> Both gcc-11.0.0-0.16.fc34 and dwz-0.13-6.fc34 with the fixes
> > > >> are now in f34-build (and in eln-build too with s/fc34/eln108/).
> > > >> Those who had their builds fail in the last 2 days because of s390x
> > > >> rpm crashes, errors about strip failures of LTO debug sections or dwz
> > > >> crashes can retry their builds, sorry for the inconvenience.
> > > >>
> > > >> AFAIK we are waiting now for boost and maybe binutils.
> > > >
> > > >boost 1.75 was merged yesterday, and binutils 2.36 was postponed to F35.
> >
> > (snip)
> >
> > > >I'm wondering something else: Will automation trigger a "second mass
> > > >rebuild" for ELN once all the builds from the Fedora mass rebuild get
> > > >tagged into f34?
> > > >There's apparently issues with ELN right now, it looks like the base
> > > >buildroot is not installable because boost 1.75 builds were done in
> > > >the wrong order.
> > >
> > > Wrong in what way?
> >
> > Looks like this was a transient issue. koschei is no longer
> > complaining about boost.
> > The problem was some dependency chain involving rpm-build ->
> > source-highlight -> boost 1.73, but it appears to have been a
> > temporary problem, if it was a problem at all.
>
> Also, boost 1.75 builds were built in a side tag, when the side tag
> was merged it didn't merge boost-1.75 properly and the eln builds
> started using older boost, that also caused some issues with deps.
>
> >
> > 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Planned Outage - Fedora Packager Dashboard - 2021-02-02 08:00 UTC

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 01, 2021 at 05:15:04PM +0100, Frantisek Zatloukal wrote:
> There will be an outage starting at 2021-02-02 08:00 UTC,
> which will last approximately 2 hours.
> 
> To convert UTC to your local time, take a look at
> http://fedoraproject.org/wiki/Infrastructure/UTCHowto
> or run:
> 
> date -d '2021-02-02 08:00UTC'
> 
> Reason for outage:
> 
> Moving the project from its temporary server to the final, production
> hosting.
> 
> Affected Services:
> 
> Fedora Packager Dashboard - you can use staging instance for the time
> being: https://packager-dashboard.stg.fedoraproject.org/
> Fedora Easy Karma - fast pre cached data from bodhi via oraculum won't be
> available, the app automatically falls back to the old and slow data
> fetching directly from Bodhi

Maybe also disable https://packager.fedorainfracloud.org (I assume
that this is the same thing).  It's not getting updated but that's not
immediately obvious if you just load the page.

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

Re: btrfs hash algorithm (should xxhash be the default?)

[Matthew Miller]

On Mon, Feb 01, 2021 at 04:06:37PM +0100, Kevin Kofler via devel wrote:
> I guess the real question is: does it increase the required disk space or 
> does it only fill up bits that would otherwise be padding bits?

Josef tells me that 32 bytes are reserved _anyway_, with 4 used for crc32c
or 8 used for xxhash. So even using the 256-bit hashes wouldn't change the
size on disk; they'd just use the already-allocated space.

-- 
Matthew Miller

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

Jami (formerly Ring) P2P softphone packaging?

[Daniel Pocock]

Has anybody tested the Jami softphone from Savoir-Faire Linux?  It was
formerly known as Ring.

They distribute RPMs directly from the web site[1].  It is already[2] in
Debian for some time.

They distribute[3] their DHT as a library, OpenDHT, for use in other
projects.

Regards,

Daniel

1. https://jami.net/
2. https://packages.qa.debian.org/r/ring.html
3. https://github.com/savoirfairelinux/opendht
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: ECL soname bump

[José Abílio Matos]

On Monday, February 1, 2021 4:53:25 PM WET Jerry James wrote:
> A new version of ECL has been released, with an soname bump on the
> shared library.  Only maxima and sagemath depend on ECL, so I will
> rebuild both of them after updating ECL in about a week.  I will do
> test builds in advance to identify any problems with the upgrade.

Maxima failed to build on rawhide due to a crash on gcl on the configure 
stage:
https://kojipkgs.fedoraproject.org//work/tasks/9904/60929904/build.log 

-- 
José Abílio___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Test timeouts in Fedora Copr emulated envs

[Miro Hrončok]

On 29. 01. 21 16:26, Daniel P. Berrangé wrote:

Is there a good way to detect that the build is in an emulated copr
env rather than native. Does Copr / mock set any env variable to
show that you're emulated ?


I've talked to Pavel Raiskup on IRC about this.

Copr uses mock's --forcearch option to emulate the environment. The easiest way 
to detect it would be if mock automatically exposed a macro that says so:


https://github.com/rpm-software-management/mock/issues/697

--
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: Fedora CoreOS Virtual Meetup this week

[Matthew Miller]

On Mon, Feb 01, 2021 at 05:27:54PM +0100, Clement Verna wrote:
> The goal is to have an open discussion and come up with a way forward for
> both of these topics. If you are interested to listen or contribute please
> join us here[2]

Sounds interesting -- I'll be there!


-- 
Matthew Miller

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

ECL soname bump

[Jerry James]

A new version of ECL has been released, with an soname bump on the
shared library.  Only maxima and sagemath depend on ECL, so I will
rebuild both of them after updating ECL in about a week.  I will do
test builds in advance to identify any problems with the upgrade.
-- 
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

Fedora CoreOS Virtual Meetup this week

[Clement Verna]

Hi all,

We are going to hold a virtual meetup this Thursday (2021-02-04) . The
meetup will cover 2 topics

* Growing Fedora CoreOS Community - from 15:00  to 15:50 UTC [0]
and
* Fedora CoreOS as an Official Edition - from 16:00 to 16:50 UTC [1]

The goal is to have an open discussion and come up with a way forward for
both of these topics. If you are interested to listen or contribute please
join us here[2]

[0] - https://apps.fedoraproject.org/calendar/CoreOS/2021/2/4/#m9903
[1] - https://apps.fedoraproject.org/calendar/CoreOS/2021/2/4/#m9904
[2] - meet.google.com/pqi-epwy-udg
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [Help wanted] Setting vi/view/vim via alternatives

[Colin Walters]

On Sat, Jan 30, 2021, at 1:54 PM, Vitaly Zaitsev via devel wrote:
> On 30.01.2021 18:50, clime wrote:
> > Hey, what do you mean by this?
> 
> https://docs.fedoraproject.org/en-US/fedora-coreos/alternatives/
> 
> > Why should scriplets usage be incompatible with immutable Fedora
> > releases?
> 
> rpm-ostree doesn't execute any scriptlets.

Yes it does - on the server side by default, and if client side layering is 
enabled, then scripts are run client side.

Please be careful not to add inaccurate information here.

The conflict with alternatives isn't actually specific to (rpm-)ostree but it's 
around intermixing state in all 3 of /usr, /etc, and /var - which is something 
to avoid because it is a problem for *any* image-based update system (e.g. 
people using dm-verity) as well as people doing local filesystem snapshots.

I think https://bugzilla.redhat.com/show_bug.cgi?id=1657367 is the most 
recently updated bug for this.


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

Planned Outage - Fedora Packager Dashboard - 2021-02-02 08:00 UTC

[Frantisek Zatloukal]

There will be an outage starting at 2021-02-02 08:00 UTC,
which will last approximately 2 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2021-02-02 08:00UTC'

Reason for outage:

Moving the project from its temporary server to the final, production
hosting.

Affected Services:

Fedora Packager Dashboard - you can use staging instance for the time
being: https://packager-dashboard.stg.fedoraproject.org/
Fedora Easy Karma - fast pre cached data from bodhi via oraculum won't be
available, the app automatically falls back to the old and slow data
fetching directly from Bodhi

Ticket Link: https://pagure.io/fedora-infrastructure/issue/9612

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-20210201.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!
8 of 43 required tests failed, 8 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 39/123 (aarch64), 32/181 (x86_64)

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

ID: 766763  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/766763
ID: 767189  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/767189
ID: 767190  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/767190

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

ID: 766718  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/766718
ID: 766737  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/766737
ID: 766740  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/766740
ID: 766759  Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/766759
ID: 766760  Test: aarch64 Minimal-raw_xz-raw.xz base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/766760
ID: 766761  Test: aarch64 Minimal-raw_xz-raw.xz 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/766761
ID: 766762  Test: aarch64 Minimal-raw_xz-raw.xz release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/766762
ID: 766768  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/766768
ID: 766771  Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/766771
ID: 766775  Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/766775
ID: 766783  Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/766783
ID: 766790  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/766790
ID: 766794  Test: aarch64 Server-dvd-iso install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/766794
ID: 766798  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/766798
ID: 766800  Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/766800
ID: 766802  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/766802
ID: 766808  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/766808
ID: 766809  Test: aarch64 Server-raw_xz-raw.xz base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/766809
ID: 766810  Test: aarch64 Server-raw_xz-raw.xz 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/766810
ID: 766811  Test: aarch64 Server-raw_xz-raw.xz release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/766811
ID: 766831  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/766831
ID: 766836  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/766836
ID: 766838  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/766838
ID: 766839  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/766839
ID: 766841  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/766841
ID: 766842  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/766842
ID: 766843  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/766843
ID: 766844  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/766844
ID: 766856  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/766856
ID: 766857  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/766857
ID: 766858  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/766858
ID: 766859  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/766859
ID: 766860  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/766860
ID: 766862  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/766862
ID: 766863  Test: x86_64 universal i

Re: [i3] i3 Spin staging site now available

[Eduard Lucena]

Hello Justin and team,

Hi all,
>
> Ben Cotton built a preview of the i3 Spin website that will be used for
> Fedora 34. We need to include descriptions of the apps we will ship;
> currently, what is shown is for the LXQt desktop.
>
> https://spins.stg.fedoraproject.org/i3/
>

It looks awesome.


> Alternatively, we can also opt to not have any applications shown, but I
> think it would be cool to show what we're shipping here.
>

I think we can start with the list that is in our docs [2].



> We will need some hands to help us out with drafting the text to go on
> the site. More details in the fedora-websites ticket:
>
> https://pagure.io/fedora-websites/issue/1056


We agreed with the text on our ticketing instance [1]


[1] https://pagure.io/i3-sig/Fedora-i3-Spin/issue/31
[2] https://docs.fedoraproject.org/en-US/i3/package-groups/#minimal


-- 
Eduard Lucena
Móvil: +56962318010
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

i3 Spin staging site now available

[Justin W. Flory]

Hi all,

Ben Cotton built a preview of the i3 Spin website that will be used for
Fedora 34. We need to include descriptions of the apps we will ship;
currently, what is shown is for the LXQt desktop.

https://spins.stg.fedoraproject.org/i3/

Alternatively, we can also opt to not have any applications shown, but I
think it would be cool to show what we're shipping here.

We will need some hands to help us out with drafting the text to go on
the site. More details in the fedora-websites ticket:

https://pagure.io/fedora-websites/issue/1056

-- 
Cheers,
Justin W. Flory (he/him)
https://jwf.io
TZ=America/New_York


publickey - foss@jwf.io - 570e854f.asc
Description: application/pgp-keys


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

Re: btrfs hash algorithm (should xxhash be the default?)

[Kevin Kofler via devel]

Matthew Miller wrote:

> On Mon, Feb 01, 2021 at 01:24:53PM +, David Howells wrote:
>> Matthew Miller  wrote:
>> > Plus, it's 64 bit instead of 32 bit. The 256-bit algorithms are
>> > obviously much, much slower and probably not right for a default, but
>> > should we consider making xxhash the default for Fedora Linux systems
>> > with btrfs?
>> Does this affect what's on disk?
> 
> Yes; it changes the checksums stored with each block to be in the selected
> format. This can only be changed at filesystem creation time.

I guess the real question is: does it increase the required disk space or 
does it only fill up bits that would otherwise be padding bits?

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

perl-GIS-Distance-0.19 license change

[Petr Pisar]

perl-GIS-Distance-0.19 changed license from "GPLv3+" to "GPL+ or Artistic".

-- Petr


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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Kevin Kofler via devel]

Petr Pisar wrote:
> Technically you can make multiple builds from the very same branch and
> commit. And some of the builds can pass and some fail.

But only one of those will be the CI build used to make the decision.

So all that is needed is to ensure that we cannot have a non-CI build that 
succeeds if the CI build fails. If fedpkg build is made as smart as I 
suggest (mark the CI build as production instead of triggering a new build), 
that will happen automatically anyway. Otherwise (or I suppose it could be 
done as a sanity check either way), I suppose non-CI builds need to be put 
on hold and only allowed to start if and when the CI build succeeded.

> In reality there are modules which refer a component by a release branch
> (e.g. "master" or "f33" branch).

If modules are piggybacking on the non-modular branches, they also need to 
be treated as above: any module build for a not yet CIed commit needs to be 
put on hold and only allowed to start if and when the CI build succeeded.

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: btrfs hash algorithm (should xxhash be the default?)

[Matthew Miller]

On Mon, Feb 01, 2021 at 03:16:32PM +0100, drago01 wrote:
> Comparing the hash algorithms in isolation doesn't mean much - does it make
> a difference if you try various file system workloads with the different
> algorithms?

Probably? I'd have to make sample filesystems to test and don't have spare
hardware for doing so at hand. I'm more interested in expanding from 32-bit
to 64-bit and the speed increase is a pleasant surprise rather than the main
goal.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: btrfs hash algorithm (should xxhash be the default?)

[Matthew Miller]

On Sun, Jan 31, 2021 at 08:25:22PM +0100, Florian Weimer wrote:
> > Plus, it's 64 bit instead of 32 bit. The 256-bit algorithms are obviously
> > much, much slower and probably not right for a default, but should we
> > consider making xxhash the default for Fedora Linux systems with
> > btrfs?
> 
> Is this for an integrity check?  Wouldn't it be wise to use a CRC due to
> its well-understood statistical properties?

I will defer to the crypto experts; from what I can see this is a relatively
new algorithm but there are quite a few papers (and a lot more blogs) which
reference it and it seems generally regarded to have good non-cryptographic
hash properties.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: btrfs hash algorithm (should xxhash be the default?)

[Matthew Miller]

On Mon, Feb 01, 2021 at 01:24:53PM +, David Howells wrote:
> Matthew Miller  wrote:
> > Plus, it's 64 bit instead of 32 bit. The 256-bit algorithms are obviously
> > much, much slower and probably not right for a default, but should we
> > consider making xxhash the default for Fedora Linux systems with btrfs?
> Does this affect what's on disk?

Yes; it changes the checksums stored with each block to be in the selected
format. This can only be changed at filesystem creation time.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Petr Pisar]

V Fri, Jan 29, 2021 at 06:52:29PM +0100, Kevin Kofler via devel napsal(a):
> I still think that the best way to do CI would be what I already suggested 
> at least once:
> 1. maintainer pushes the commit to the branch "rawhide" or "fn"
> 2. a quick synchronous commit hook validates obvious things such as the
>presence of source files and patches
> If this fails, the push fails and we stop here. Otherwise:
> 3. another commit hook asynchronously triggers a CI build
> 4. the push succeeds (without waiting for the CI build to complete)
> 5. the asynchronous CI attempts to build the package
> 6. if the CI build fails, the branch "rawhide" or "fn" is automatically
>force-pushed back to the last commit that successfully built, and an
>e-mail notification is sent. Force-pushing is safe in that case because
>there was by definition no successful build, hence nothing that shipped
>in any repos.

Technically you can make multiple builds from the very same branch and commit. 
And
some of the builds can pass and some fail.

In reality there are modules which refer a component by a release branch (e.g.
"master" or "f33" branch).

-- Petr


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: btrfs hash algorithm (should xxhash be the default?)

[drago01]

On Sunday, January 31, 2021, Matthew Miller 
wrote:

> On my Intel i7 laptop, xxhash is a small but clear performance win over
> crc32c:
>
> $ ./hash-speedtest  1000
> Block size: 4096
> Iterations: 1000
> Implementation: builtin
>
> NULL-NOP: cycles:   1372543560, c/i  137
>  NULL-MEMCPY: cycles:   2844174884, c/i  284
>   CRC32C: cycles:   9673117404, c/i  967
>   XXHASH: cycles:   7129819594, c/i  712
>   SHA256: cycles: 649914613520, c/i64991
>  BLAKE2b: cycles: 153513008046, c/i15351
>
>
> And I'm given to understand that this is even more the case on newer CPUs.
>
> Plus, it's 64 bit instead of 32 bit. The 256-bit algorithms are obviously
> much, much slower and probably not right for a default, but should we
> consider making xxhash the default for Fedora Linux systems with btrfs?
>
>
Comparing the hash algorithms in isolation doesn't mean much - does it make
a difference if you try various file system workloads with the different
algorithms?



> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.
> org/en-US/project/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

Re: btrfs hash algorithm (should xxhash be the default?)

[David Howells]

Matthew Miller  wrote:

> Plus, it's 64 bit instead of 32 bit. The 256-bit algorithms are obviously
> much, much slower and probably not right for a default, but should we
> consider making xxhash the default for Fedora Linux systems with btrfs?

Does this affect what's on disk?

David
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Jython maintainer for Fedora needed

[Stephen John Smoogen]

On Sun, 31 Jan 2021 at 14:59, Miro Hrončok  wrote:

> On 31. 01. 21 20:44, Stephen John Smoogen wrote:
> >
> >
> > On Sun, 31 Jan 2021 at 14:29, Miro Hrončok  > > wrote:
> >
> > Hello Pythonistas (and especially Jythonistas),
> >
> > I've noticed Jython is orphaned in Fedora.
> >
> > There is a new version 2.7.2 available from March 2020. I took a
> peek, however
> > there are patches in Fedora's Jython I don't fully understand, so it
> is not
> > easy
> > for me to rebase them.
> >
> >
> > Isn't Jython a Python2 implementation? I thought it was orphaned because
> the
> > amount of Python2 needed to make it useful was getting to be problematic.
>
> Problematic in what way? The Jython interpreter itself is independent from
> the
> CPython 2 EOL. Like PyPy.
>
>
Problematic in that all the 'libraries' wanted by someone using Jython need
to be older ones which are able to work in python2 syntax. So as more
libraries in base python become Python3 only syntax, there is less and less
which would work with Jython or PyPy.


> > The Jython3 stack seems to be at continual catchup with Python as it is
> mentioning
> > Python3.8 on the last times the pages are updated.
>
> Quite recently updated thou:
>
> https://github.com/jython/jython.github.io/pull/21
>
> > What does having Jython remain in Fedora help with?
> That's something I'd like to understand more. If there are no people using
> Jython on Fedora then obviously nothing and we should not bother.
> Currently, it
> is nice to say: "We have all the Pythons in Fedora, even Jython", but that
> is
> not good enough reason :/
>
> --
> 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
>


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: 20210201.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210131.n.0
NEW: Fedora-Rawhide-20210201.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:4
Upgraded packages:   53
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:8.03 MiB
Size of upgraded packages:   4.75 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: aseman-qt-tools-1.0.0-15.fc33
Summary: Shared tools and functions, used in the aseman's projects
RPMs:aseman-qt-tools
Size:6.88 MiB

Package: jvyamlb-0.2.5-23.fc33
Summary: YAML processor for JRuby
RPMs:jvyamlb
Size:205.81 KiB

Package: python-pykafka-2.6.0-0.13.dev2.fc33
Summary: Full-Featured Pure-Python Kafka Client
RPMs:python3-pykafka
Size:828.69 KiB

Package: sugar-starchart-16-12.fc31
Summary: Display a map of the sky showing the position of the visible stars
RPMs:sugar-starchart
Size:147.38 KiB


= UPGRADED PACKAGES =
Package:  Zim-0.73.5-1.fc34
Old package:  Zim-0.73.4-1.fc34
Summary:  Desktop wiki & notekeeper
RPMs: Zim
Size: 1.73 MiB
Size change:  26.95 KiB
Changelog:
  * Mon Jan 25 2021 Fedora Release Engineering  - 
0.73.4-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Mon Feb 01 2021 Robin Lee  - 0.73.5-1
  - Update to 0.73.5


Package:  arpwatch-14:3.1-6.fc34
Old package:  arpwatch-14:3.1-4.fc34
Summary:  Network monitoring tools for tracking IP addresses on a network
RPMs: arpwatch
Size: 1.51 MiB
Size change:  5.96 KiB
Changelog:
  * Tue Jan 26 2021 Fedora Release Engineering  - 
14:3.1-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Sun Jan 31 2021 Benjamin A. Beasley  - 14:3.1-6
  - generate ethercodes.dat from latest oui.csv


Package:  catfish-4.16.0-2.fc34
Old package:  catfish-4.16.0-1.fc34
Summary:  A handy file search tool
RPMs: catfish
Size: 324.27 KiB
Size change:  306 B
Changelog:
  * Tue Jan 26 2021 Fedora Release Engineering  - 
4.16.0-1.1
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Sun Jan 31 2021 Mamoru TASAKA  - 4.16.0-2
  - Add GDK_BACKEND=x11 wrapper again (bug 1920378, upstream bug 42)


Package:  cxxtools-1:2.2.1-26.fc34
Old package:  cxxtools-1:2.2.1-25.fc34
Summary:  A collection of general-purpose C++ classes
RPMs: cxxtools cxxtools-devel
Size: 4.31 MiB
Size change:  -1.50 MiB
Changelog:
  * Sun Jan 31 2021 Martin Gansser  - 1:2.2.1-26
  - Add modified %{name}-%{version}-gcc11.patch now C++17 ready


Package:  detox-1.3.2-1.fc34
Old package:  detox-1.3.0-10.fc33
Summary:  Utility to replace problematic characters in file names
RPMs: detox
Size: 247.76 KiB
Size change:  4.63 KiB
Changelog:
  * Tue Jan 26 2021 Fedora Release Engineering  - 
1.3.0-11
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Sun Jan 31 2021 Filipe Rosset  - 1.3.2-1
  - Update to 1.3.2 fixes rhbz#1922713


Package:  dh-make-2.202003-2.fc34
Old package:  dh-make-2.202001-2.fc33
Summary:  Tool that converts source archives into Debian package source
RPMs: dh-make
Size: 41.92 KiB
Size change:  3.90 KiB
Changelog:
  * Tue Dec 01 2020 Fedora Release Monitoring 
 - 2.202003-1
  - Update to 2.202003 (#1869057)

  * Tue Jan 26 2021 Fedora Release Engineering  - 
2.202003-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild


Package:  dummy-test-package-gloster-0-2572.fc34
Old package:  dummy-test-package-gloster-0-2560.fc34
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 162.14 KiB
Size change:  733 B
Changelog:
  * Sun Jan 31 2021 packagerbot  - 0-2561
  - rebuilt

  * Sun Jan 31 2021 packagerbot  - 0-2562
  - rebuilt

  * Sun Jan 31 2021 packagerbot  - 0-2563
  - rebuilt

  * Sun Jan 31 2021 packagerbot  - 0-2564
  - rebuilt

  * Sun Jan 31 2021 packagerbot  - 0-2565
  - rebuilt

  * Sun Jan 31 2021 packagerbot  - 0-2566
  - rebuilt

  * Sun Jan 31 2021 packagerbot  - 0-2567
  - rebuilt

  * Sun Jan 31 2021 packagerbot  - 0-2568
  - rebuilt

  * Sun Jan 31 2021 packagerbot  - 0-2569
  - rebuilt

  * Mon Feb 01 2021 packagerbot  - 0-2570
  - rebuilt

  * Mon Feb 01 2021 packagerbot  - 0-2571
  - rebuilt

  * Mon Feb 01 2021 packagerbot  - 0-2572
  - rebuilt


Package:  fabtests-1.12.0-0.1.fc34
Old package:  fabtests-1.11.2-1.fc34
Summary:  Test suite for libfabric API
RPMs: fabtests
Size: 2.44 MiB
Size change:  8.53 KiB
Changelog:
  * Tue Jan 26 2021 Fedora Release Engineering  - 
1.11.2-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Sun Jan 31 2021 Honggang Li  - 1.12.0-0.1
  - Rebase to upstrea

Re: Fedora 34 Change: PostgreSQL 13 (Self-Contained Change)

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jan 29, 2021 at 04:17:02PM +0100, Patrik Novotny wrote:
> >
> > Hmm, this sounds rather complicated and risky.
> > Do I get this right that postgresql will bundle a copy of libpq,
> > and a separate unbundled libpq will be provided?
> >
> > Why not just include a specific Requires on a specific version of
> > libpq? (Maybe something like
> >   Requires:libpq(%_isa)>=x.y.z and libpq(%_isa) > or whatever the best syntax is).
> >
> > There are plenty of packages which require some specific version of a
> > separately-packages library. We don't normally use bundling in such
> > cases.  Since both packages are under the same maintainership, it
> > should be easy enough to keep them in sync.
> >
> 
> The libpq library is part of the postgresql codebase. We have previously
> decided to separate it downstream and package it as a separate component.
> This means that different versions of postgresql are built modularly
> against a single non-modular libpq library.
> 
> Upstream releases minor updates for all supported major version at once
> like this:
> 
> 13.0 -> 13.1
> 12.4 -> 12.5
> 11.9 ->  11.10
> 10.14 -> 10.15
> 9.6.19 -> 9.6.20
> 9.5.23 -> 9.5.24
> 
> This means that to be able to rebase all postgresql streams
> (13,12,11,10,9.6) to their latest minor release versions, first we need to
> rebase the libpq library to the (in this case) 13.1 version.
> In that scenario, all streams except postgresql:13 are being built against
> different version of libpq, even though there is the correct libpq version
> in each postgresql source tarball for each stream, as libpq is part of its
> codebase.
> 
> Historically, this way of packaging postgresql with separated libpq worked.
> However, upstream stated that they do not guarantee such compatibility, and
> postgresql was never intended to be built against external libpq.
> 
> With the release version 13.1, we encountered some (thankfully) minor
> incompatibilities, causing us to patch downstream all streams up to
> postgresql:13.
> 
> This new solution is not a classic bundle. It's a return to how postgresql
> is supposed to be built, while keeping a separate libpq package for users.

Thank you for the explanation.

Zbyszek
 
> Those bugs have a lot of detail... It seems that the only real solution
> > is to retroactively bump the so version. I couldn't figure out if that
> > is what happened upstream.
> >
> 
> The only change here is the symbol version, as they are versioned
> downstream, and a mistake happened regarding that patch on rebase to the
> version 12.x. There is no upstream change, nor are any symbols actually
> being changed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 33 network configuration (ifcfg*) migration guide available?

[Arthur G]

Thanks also for the nmcli tip, it got me out of a pickle today with RedHat
8. From what I've experienced so far it's well implemented.

On Mon, 1 Feb 2021 at 08:42, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Dominik 'Rathann' Mierzejewski wrote:
> > You can use crudini to manage .ini files. Works quite well. There's also
> > nmcli...
>
> You might also be able to work with kreadconfig5 and kwriteconfig5 from
> kf5-
> kconfig-core, though I have never tried those on NM configs.
>
> 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Test timeouts in Fedora Copr emulated envs

[Miro Hrončok]

On 31. 01. 21 16:44, Pavel Raiskup wrote:

There can be a macro that you would use like this:

  --timeout %{adjust_timeout 3600}

Currently the environment (the copr-rpmbuild wrapper script) guards that mock
doesn't run longer than expected (it is not a mock built-in timeout).

Not saying it is not possible to do this in Copr, but it wouldn't be an easy
thing to implement.  Much easier would be something like --timeout 3600
--timeout-armhfp=7200, or --timeout-forcearch=300%, or something alike.


To clarify, I'm talking about setting timeouts of individual jobs in the spec 
file based on a macro value. Not about timeouts of copr builds.


E.g.

%check
%pytest --timeout %{adjust_timeout 300}

--
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: Test timeouts in Fedora Copr emulated envs

[Miro Hrončok]

On 01. 02. 21 10:53, Pavel Raiskup wrote:

On Monday, February 1, 2021 10:32:04 AM CET Daniel P. Berrangé wrote:

On Sun, Jan 31, 2021 at 03:35:14PM +0100, Pavel Raiskup wrote:

On Friday, January 29, 2021 4:26:18 PM CET Daniel P. Berrangé wrote:

When we attempt to build libvirt in Copr, the test suite times out on
s390 builds.

IIUC, this is because s390 in Copr is using a QEMU emulated system,
not native hardware, and thus is massively slower to execute.

We don't want to bump up the default test suite timeout unconditonally,
as that makes it slower to diagnose problems for the common case
where the build env is not emulated.

Is there a good way to detect that the build is in an emulated copr
env rather than native. Does Copr / mock set any env variable to
show that you're emulated ?


No explicit environment variable I think.  It would be a question on
qemu-user-static maintainers probably.

You can check `uname -r` vs. `uname -i`?  Or something like that.


I'm thinking this is not really a libvirt specific problem - any app
using Meson is liable to hit the default test suite time limit if
running in an emulated chroot, and thus will need to set
--timeout-multiplier=10.
So perhaps RPM's %meson_test macro should automatically include
--timeout-multiplier=10 when running in an emulated world ?


I thought you mean the Copr limit (copr build --timeout) but this is
probably in-testsuite timetout.


Yeah, I mean  making  %meson_test expand to

  meson test --timeout-multiplier=10


I don't know, perhaps we could have some configurable coefficient for
timeout _in Copr_ for emulated architectures?  If that was say "3", and
the --timeout was 3600s, emulated arches would get 10800s instead?


Yeah, if Copr set some coefficient, that could be used directly as the
meson multiplier.


We don't even expose the pre-configured timeout down to rpmbuild ATM.  So for
the rpmbuild process (or even mock) it is just an unpredictable async interrupt
signal.

So indeed, it looks like a good idea to start passing the info down (e.g. as RPM
macros) so scripts like meson can adapt to the given timeout.


I don't think this has to do anything with the Copr build timeout thou.

What Daniel wants is to specify a timeout of an action during rpmbuild (such as 
running the tests) via a multiplier/variable. Such multiplier/variable would be 
carefully set by the chroot administrator to reflect the overall slowness of the 
builders.


--
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: Test timeouts in Fedora Copr emulated envs

[Pavel Raiskup]

On Monday, February 1, 2021 10:32:04 AM CET Daniel P. Berrangé wrote:
> On Sun, Jan 31, 2021 at 03:35:14PM +0100, Pavel Raiskup wrote:
> > On Friday, January 29, 2021 4:26:18 PM CET Daniel P. Berrangé wrote:
> > > When we attempt to build libvirt in Copr, the test suite times out on
> > > s390 builds.
> > > 
> > > IIUC, this is because s390 in Copr is using a QEMU emulated system,
> > > not native hardware, and thus is massively slower to execute.
> > > 
> > > We don't want to bump up the default test suite timeout unconditonally,
> > > as that makes it slower to diagnose problems for the common case
> > > where the build env is not emulated.
> > > 
> > > Is there a good way to detect that the build is in an emulated copr
> > > env rather than native. Does Copr / mock set any env variable to
> > > show that you're emulated ?
> > 
> > No explicit environment variable I think.  It would be a question on
> > qemu-user-static maintainers probably.
> > 
> > You can check `uname -r` vs. `uname -i`?  Or something like that.
> > 
> > > I'm thinking this is not really a libvirt specific problem - any app
> > > using Meson is liable to hit the default test suite time limit if
> > > running in an emulated chroot, and thus will need to set
> > > --timeout-multiplier=10.
> > > So perhaps RPM's %meson_test macro should automatically include
> > > --timeout-multiplier=10 when running in an emulated world ?
> > 
> > I thought you mean the Copr limit (copr build --timeout) but this is
> > probably in-testsuite timetout.
> 
> Yeah, I mean  making  %meson_test expand to
> 
>  meson test --timeout-multiplier=10
> 
> > I don't know, perhaps we could have some configurable coefficient for
> > timeout _in Copr_ for emulated architectures?  If that was say "3", and
> > the --timeout was 3600s, emulated arches would get 10800s instead?
> 
> Yeah, if Copr set some coefficient, that could be used directly as the
> meson multiplier.

We don't even expose the pre-configured timeout down to rpmbuild ATM.  So for
the rpmbuild process (or even mock) it is just an unpredictable async interrupt
signal.

So indeed, it looks like a good idea to start passing the info down (e.g. as RPM
macros) so scripts like meson can adapt to the given timeout.

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Test timeouts in Fedora Copr emulated envs

[Daniel P . Berrangé]

On Sun, Jan 31, 2021 at 03:35:14PM +0100, Pavel Raiskup wrote:
> On Friday, January 29, 2021 4:26:18 PM CET Daniel P. Berrangé wrote:
> > When we attempt to build libvirt in Copr, the test suite times out on
> > s390 builds.
> > 
> > IIUC, this is because s390 in Copr is using a QEMU emulated system,
> > not native hardware, and thus is massively slower to execute.
> > 
> > We don't want to bump up the default test suite timeout unconditonally,
> > as that makes it slower to diagnose problems for the common case
> > where the build env is not emulated.
> > 
> > Is there a good way to detect that the build is in an emulated copr
> > env rather than native. Does Copr / mock set any env variable to
> > show that you're emulated ?
> 
> No explicit environment variable I think.  It would be a question on
> qemu-user-static maintainers probably.
> 
> You can check `uname -r` vs. `uname -i`?  Or something like that.
> 
> > I'm thinking this is not really a libvirt specific problem - any app
> > using Meson is liable to hit the default test suite time limit if
> > running in an emulated chroot, and thus will need to set
> > --timeout-multiplier=10.
> > So perhaps RPM's %meson_test macro should automatically include
> > --timeout-multiplier=10 when running in an emulated world ?
> 
> I thought you mean the Copr limit (copr build --timeout) but this is
> probably in-testsuite timetout.

Yeah, I mean  making  %meson_test expand to

 meson test --timeout-multiplier=10

> I don't know, perhaps we could have some configurable coefficient for
> timeout _in Copr_ for emulated architectures?  If that was say "3", and
> the --timeout was 3600s, emulated arches would get 10800s instead?

Yeah, if Copr set some coefficient, that could be used directly as the
meson multiplier.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 01 February (Today)

[Ankur Sinha]

Hello everyone,

Please join us at the next Open NeuroFedora team meeting on Monday 1
February at 1300UTC in #fedora-neuro on IRC (Freenode). The meeting is a
public meeting, and open for everyone to attend. You can join us over:

IRC:
https://webchat.freenode.net/?channels=#fedora-neuro

or Matrix/Element:
https://matrix.to/#/!xgwUsLNGIoOAXMxGMQ:matrix.org?via=matrix.org&via=t2bot.io

The channel is also bridged to Telegram, so you can also join us there on the
@NeuroFedora group:
https://t.me/NeuroFedora

You can convert the meeting time to your local time using this command
in a terminal:
$ date --date='TZ="UTC" 1300 today'

or you can use this link:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+Meeting&iso=20210201T13&p1=1440&ah=1

The meeting will be chaired by @ankursinha (me). The agenda for the
meeting is:

- New introductions and roll call.
- Tasks from last week's meeting:
https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2021-01-18-13.06.html
- Open Pagure tickets:
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
- Open bugs check: https://tinyurl.com/neurofedora-bugs
- Open package reviews check:
https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro
- Koschei packages check:
https://koschei.fedoraproject.org/groups/neuro-sig
- CompNeuro lab compose status check for F33/F34:
https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

You can learn more about NeuroFedora here:
https://neuro.fedoraproject.org

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