Re: cxxtools-2.2.1 fails to compile on rawhide with gcc11 with /usr/include/c++/11/string_view:98:21: error: static assertion failed

[Martin Gansser]

The issue has now been resolved with this patch:

+++ include/cxxtools/char.h 2021-01-30 18:28:23.87739 +0100
@@ -68,9 +68,7 @@
 typedef int32_t value_type;
 
 //! Constructs a character with a value of 0.
-Char()
-: _value(0)
-{}
+Char() = default;
 
 //! Constructs a character using the given char as base for the 
character value.
 Char(char ch)
@@ -114,9 +112,6 @@
 return Char(0);
 }
 
-Char& operator=(const Char& ch)
-{ _value = ch._value; return *this; }
-
 /**
  * @brief Returns the internal value (unsigned 32 bits) of this 
character.
  * @return The 32-bit-value of this character.
@@ -336,14 +331,14 @@
 inline char_traits::char_type*
 char_traits::move(char_type* s1, const char_type* s2, 
int_type n)
 {
-return (cxxtools::Char*)std::memmove(s1, s2, n * 
sizeof(cxxtools::Char));
+return 
static_cast(std::memmove(static_cast(s1), 
static_cast(s2), n * sizeof(cxxtools::Char)));   
 }
 
 
 inline char_traits::char_type*
 char_traits::copy(char_type* s1, const char_type* s2, 
size_t n)
 {
-return (cxxtools::Char*)std::memcpy(s1, s2, n * 
sizeof(cxxtools::Char));
+return 
static_cast(std::memcpy(static_cast(s1), 
static_cast(s2), n * sizeof(cxxtools::Char))); 
 }
 
Regards
Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: bootstrapping without .spec modification

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jan 30, 2021 at 12:03:21PM -0800, Kevin Fenzi wrote:
> On Fri, Jan 29, 2021 at 03:49:28PM +0100, Miro Hrončok wrote:
> > 
> > Currently a Koji task says:
> > 
> > Source: 
> > git+https://src.fedoraproject.org/rpms/python3.9.git#563b4f4b59a9f81095acfe30899fdc4b040c1b9b
> > Build Target: f34-rebuild
> > Options:
> >   fail_fast = True
> >   wait_builds =
> > 
> > Example taken from 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=60654655
> > 
> > With this feature, it would say:
> > 
> > Source: 
> > git+https://src.fedoraproject.org/rpms/python3.9.git#563b4f4b59a9f81095acfe30899fdc4b040c1b9b
> > Build Target: f34-rebuild
> > Options:
> >   fail_fast = True
> >   wait_builds =
> > Macro overrides:
> >   _with_bootstrap: 1
> > 
> > And when reproducing, you'd just run the same command, e.g.
> > 
> > $ koji build f34-rebuild --fail-fast --macro '_with_bootstrap 1' 
> > 'git+https://src.fedoraproject.org/rpms/python3.9.git#563b4f4b59a9f81095acfe30899fdc4b040c1b9b'
> > 
> > The Koji web interface could even display the command.
> > 
> > That's very much as reproduce as now.
> 
> So, koji already can set macros per tag.
> For example, eln sig uses this: 
> 
> ➜  ~ koji taginfo eln-build
> Tag: eln-build [22493]
> Arches: i686 x86_64 aarch64 ppc64le s390x
> Groups: appliance-build, build, livecd-build, livemedia-build, srpm-build
> Tag options:
>   mock.new_chroot : 0  [f34]
>   mock.package_manager : 'dnf' [f34]
>   rpm.macro.dist : ('%{!?distprefix0:%{?distprefix}}%{expand:%{lua:for 
> i=0, do '
>  'print("%{?distprefix" .. i .."}") '
>  'end}}.eln%{eln}%{?with_bootstrap:~bootstrap}')
>   rpm.macro.eln : 108
>   rpm.macro.rhel : 9
> This tag is a buildroot for one or more targets
> Current repo: repo#2902927: 2021-01-30 19:46:56.747509+00:00
> Targets that build from this tag:
>   eln-rebuild
>   eln
>   eln-candidate
> Inheritance:
>   0 eln [22492]
>   5 f34-build [27045]
> 
> We had a request to enable this for side-tags: 
> 
> https://pagure.io/fedora-infrastructure/issue/9048

That'd be great.

> what was passed in for the build so if you just had the src.rpm you
> could figure out what was going on?

Yeah, I think we should consider the creation of record so this can be
reviewed after the fact as a requirement for enablement.

> but didn't want to due to how this could be used. 
> 
> My thought was to try and ask koji developers to add some kind of
> 'non-mergable' bit on side-tags. So, if you want to use a side tag to
> play around with/test something you could, but if you adjusted things
> beyond some whitelist, the side-tag would not be mergable back into
> rawhide, and we could allow _with_bootstrap. 

I think those worries are overblown. When a packager has the rights to
build an rpm (in a side-tag or not), they also have the right to
commit whatever they want to the spec file. That packager also already
has the ability to influence the build by tagging things into the
side-tag. This type of modification does not require modification of
the spec file. There isn't any fundamental difference in influencing
the build through macros compared to the other ways. We just need to
record what was set, similarly to the list of rpms that is pulled into
the buildroot.

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

[Test-Announce] Fedora 34 Rawhide 20210131.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 34 Rawhide 20210131.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20210128.n.0: anaconda-34.20-1.fc34.src, 20210131.n.0: 
anaconda-34.21-1.fc34.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/34

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210131.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210131.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210131.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210131.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210131.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210131.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210131.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: 20210131.n.0 changes

[Fedora Rawhide Report]

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

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  24
Dropped packages:0
Upgraded packages:   49
Downgraded packages: 0

Size of added packages:  119.05 MiB
Size of dropped packages:0 B
Size of upgraded packages:   1.60 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: golang-github-twpayne-geom-1.3.6-1.fc34
Summary: Efficient geometry types for geospatial applications
RPMs:golang-github-twpayne-geom-devel
Size:117.98 KiB

Package: golang-github-twpayne-kml-1.5.2-1.fc34
Summary: Convenince methods for creating and writing KML documents
RPMs:golang-github-twpayne-kml-devel
Size:36.14 KiB

Package: golang-github-twpayne-polyline-1.0.1-1.fc34
Summary: Google Maps Encoding Polyline encoder and decoder
RPMs:golang-github-twpayne-polyline-devel
Size:13.27 KiB

Package: golang-github-twpayne-waypoint-0-0.1.20210130git4f8e6bf.fc34
Summary: Reads and writes waypoints in formats used by the free flying community
RPMs:golang-github-twpayne-waypoint golang-github-twpayne-waypoint-devel
Size:3.77 MiB

Package: octave-6:6.1.0-1.module_f34+11129+457484d3
Summary: A high-level language for numerical computations
RPMs:octave octave-devel octave-doc
Size:88.30 MiB

Package: octave-communications-1.2.2-4.module_f34+11129+457484d3
Summary: Communications for Octave
RPMs:octave-communications
Size:1.24 MiB

Package: octave-control-3.2.0-8.module_f34+11129+457484d3
Summary: Computer-Aided Control System Design (CACSD) Tools for Octave
RPMs:octave-control
Size:4.13 MiB

Package: octave-dicom-0.4.0-2.module_f34+11129+457484d3
Summary: Dicom processing for Octave
RPMs:octave-dicom
Size:2.06 MiB

Package: octave-doctest-0.7.0-8.module_f34+11129+457484d3
Summary: Documentation tests for Octave
RPMs:octave-doctest
Size:28.24 KiB

Package: octave-general-2.1.1-2.module_f34+11129+457484d3
Summary: General tools for Octave, string dictionary, parallel computing
RPMs:octave-general
Size:237.90 KiB

Package: octave-gsl-2.1.1-2.module_f34+11129+457484d3
Summary: Octave bindings to the GNU Scientific Library
RPMs:octave-gsl
Size:763.45 KiB

Package: octave-image-2.12.0-2.module_f34+11129+457484d3
Summary: Image processing for Octave
RPMs:octave-image
Size:3.07 MiB

Package: octave-interval-3.2.0-11.module_f34+11129+457484d3
Summary: Interval arithmetic for Octave
RPMs:octave-interval
Size:9.18 MiB

Package: octave-io-2.6.3-2.module_f34+11129+457484d3
Summary: Input/Output in external formats
RPMs:octave-io
Size:1.14 MiB

Package: octave-jsonlab-2.0-3.module_f34+11129+457484d3
Summary: A JSON/UBJSON/MessagePack encoder/decoder for MATLAB/Octave
RPMs:octave-jsonlab
Size:88.07 KiB

Package: octave-metch-0.6-4.module_f34+11129+457484d3
Summary: Mesh/volume registration toolbox
RPMs:octave-metch
Size:23.18 KiB

Package: octave-miscellaneous-1.3.0-5.module_f34+11129+457484d3
Summary: Miscellaneous functions for Octave
RPMs:octave-miscellaneous
Size:501.03 KiB

Package: octave-ncarray-1.0.4-13.module_f34+11129+457484d3
Summary: Access NetCDF files as a multi-dimensional array
RPMs:octave-ncarray
Size:37.29 KiB

Package: octave-netcdf-1.0.14-2.module_f34+11129+457484d3
Summary: A MATLAB compatible NetCDF interface for Octave
RPMs:octave-netcdf
Size:505.51 KiB

Package: octave-optim-1.6.0-8.module_f34+11129+457484d3
Summary: A non-linear optimization tool kit for Octave
RPMs:octave-optim
Size:1.13 MiB

Package: octave-quaternion-2.4.0-17.module_f34+11129+457484d3
Summary: Quaternion package for Octave
RPMs:octave-quaternion
Size:1.21 MiB

Package: octave-signal-1.4.1-8.module_f34+11129+457484d3
Summary: Signal processing tools for Octave
RPMs:octave-signal
Size:969.77 KiB

Package: octave-struct-1.0.16-7.module_f34+11129+457484d3
Summary: Structure handling for Octave
RPMs:octave-struct
Size:333.54 KiB

Package: octave-symbolic-2.9.0-5.module_f34+11129+457484d3
Summary: Symbolic computations for Octave
RPMs:octave-symbolic
Size:254.64 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  ansible-bender-0.9.0-1.fc34
Old package:  ansible-bender-0.8.1-4.fc33
Summary:  Build container images using Ansible playbooks
RPMs: ansible-bender
Size: 4.86 MiB
Size change:  4.78 MiB
Changelog:
  * Tue Jan 26 2021 Fedora Release Engineering  - 
0.8.1-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Sat Jan 30 2021 Gordon Messmer  - 0.9.0-1
  - Build 0.9.0


Package:  apcupsd-3.14.14-22.fc34
Old package:  apcupsd-3.14.14-17.fc32
Summary:  APC UPS Power Control Daemon
RPMs: apcupsd apcupsd-cgi apcupsd-gui
Size

Re: bootstrapping without .spec modification

[Kalev Lember]

On 1/31/21 11:55, Zbigniew Jędrzejewski-Szmek wrote:

I think those worries are overblown. When a packager has the rights to
build an rpm (in a side-tag or not), they also have the right to
commit whatever they want to the spec file.

Just taking a sentence out of context here:

I believe you are incorrect here and koji doesn't apply any restrictions 
on who can build packages (secure boot packages have a restriction but 
that's a different story). As far as I am aware, anyone who has access 
to koji can build anything that's already commited to git.


Or to put it another way:

There's fine grained restrictions on git access. The same restrictions 
do not apply to koji.


--
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 for FTBFS packages: apcupsd and firefox-pkcs11-loader

[Germano Massullo]

Il giorno dom 31 gen 2021 alle ore 01:38 Robert-André Mauchin
 ha scritto:
> It seems out of tree builds are not supported by the build script.
> Just copy the xpi to the build directory to make it work:
>
> cp -a *.xpi %{_vpath_builddir}/
>
> (after the %cmake call)

Thank you, it worked!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-IoT-34-20210131.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Failed openQA tests: 9/15 (aarch64), 4/16 (x86_64)

New failures (same test not failed in Fedora-IoT-34-20210130.0):

ID: 766208  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/766208

Old failures (same test failed in Fedora-IoT-34-20210130.0):

ID: 766182  Test: x86_64 IoT-dvd_ostree-iso podman
URL: https://openqa.fedoraproject.org/tests/766182
ID: 766185  Test: x86_64 IoT-dvd_ostree-iso podman_client
URL: https://openqa.fedoraproject.org/tests/766185
ID: 766186  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/766186
ID: 766190  Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay
URL: https://openqa.fedoraproject.org/tests/766190
ID: 766194  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/766194
ID: 766196  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/766196
ID: 766197  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/766197
ID: 766200  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/766200
ID: 766201  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/766201
ID: 766205  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/766205
ID: 766206  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi
URL: https://openqa.fedoraproject.org/tests/766206
ID: 766207  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/766207

Soft failed openQA tests: 1/16 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-IoT-34-20210130.0):

ID: 766178  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/766178

Passed openQA tests: 11/16 (x86_64), 6/15 (aarch64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.64 to 0.85
Previous test data: https://openqa.fedoraproject.org/tests/765591#downloads
Current test data: https://openqa.fedoraproject.org/tests/766180#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora rawhide compose report: 20210129.n.0 changes

[Miro Hrončok]

On 30. 01. 21 19:12, Kevin Fenzi wrote:

resubmit should resubmit it just the way it was, ie, against
f34-rebuild. A new build should get a new taskid, but this seemed to be
the same one the releng one had. Dunno. Perhaps we could ask the people
doing this?


I've recently did:

$ koji tag f34-pending rb_libtorrent-1.2.11-3.fc34

To fix a problem in rawhide that was fixed by the mass rebuild build.

Should I not do that?

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

The problem is affecting everyone I think.  Emulated builds, when they are
CPU/Memory bound, tend to be even 10 times slower.

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?

Pavel

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



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

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp
Minimal 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: 40/123 (aarch64), 33/181 (x86_64)

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

ID: 765964  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/765964
ID: 766083  Test: aarch64 universal install_blivet_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/766083
ID: 766086  Test: aarch64 universal install_anaconda_text@uefi
URL: https://openqa.fedoraproject.org/tests/766086

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

ID: 765827  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/765827
ID: 765832  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/765832
ID: 765844  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/765844
ID: 765845  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/765845
ID: 765848  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/765848
ID: 765854  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/765854
ID: 765855  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/765855
ID: 765856  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/765856
ID: 765858  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/765858
ID: 765881  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/765881
ID: 765900  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/765900
ID: 765903  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/765903
ID: 765922  Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/765922
ID: 765923  Test: aarch64 Minimal-raw_xz-raw.xz base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/765923
ID: 765924  Test: aarch64 Minimal-raw_xz-raw.xz 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/765924
ID: 765925  Test: aarch64 Minimal-raw_xz-raw.xz release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/765925
ID: 765931  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/765931
ID: 765934  Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/765934
ID: 765938  Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/765938
ID: 765946  Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/765946
ID: 765953  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/765953
ID: 765957  Test: aarch64 Server-dvd-iso install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/765957
ID: 765961  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/765961
ID: 765963  Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/765963
ID: 765965  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/765965
ID: 765971  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/765971
ID: 765972  Test: aarch64 Server-raw_xz-raw.xz base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/765972
ID: 765973  Test: aarch64 Server-raw_xz-raw.xz 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/765973
ID: 765974  Test: aarch64 Server-raw_xz-raw.xz release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/765974
ID: 765994  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/765994
ID: 765999  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/765999
ID: 766001  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/766001
ID: 766002  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/766002
ID: 766004  Test: x86_64 universal upgrade_2_desktop_enc

Re: Test timeouts in Fedora Copr emulated envs

[Miro Hrončok]

On 31. 01. 21 15:35, Pavel Raiskup wrote:

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?



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

--timeout %{adjust_timeout 3600}

And the macro would:

Check if %__timeout_coefficient is set. If not, evaluate to the first argument 
as is. If set, multiply the two numbers and evaluate to that.


The emulated copr chroots would define the %__timeout_coefficient macro to a 
value provided by the admins (via an educated guess).


-

A proof of concept macro definition (requires RPM 4.16+ == Fedora 33+):

 %adjust_timeout() %[%{?__timeout_coefficient}%{?!__timeout_coefficient:1} * %1]

(It would require a rewrite to Lua / Shell if we want to support float values as 
well, as RPM expressions AFAIK only know integers.)


-

Obviously, there is a downside. If we go this way and define %adjust_timeout in 
Fedora and/or upstream RPM, spec files with --timeout %{adjust_timeout 3600} 
will only work on new enough Fedoras. There is an ugly way to actually make the 
spec file compatible with past versions:


--timeout %{?adjust_timeout:%{adjust_timeout 3600}}%{?!adjust_timeout:3600}

Since this is hideous, I would prefer to backport the macro wherever possible :/

--
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 Sunday, January 31, 2021 4:17:04 PM CET Miro Hrončok wrote:
> On 31. 01. 21 15:35, Pavel Raiskup wrote:
> > 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?
> 
> 
> 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.

Pavel

> And the macro would:
> 
> Check if %__timeout_coefficient is set. If not, evaluate to the first 
> argument 
> as is. If set, multiply the two numbers and evaluate to that.
> 
> The emulated copr chroots would define the %__timeout_coefficient macro to a 
> value provided by the admins (via an educated guess).
> 
> -
> 
> A proof of concept macro definition (requires RPM 4.16+ == Fedora 33+):
> 
>   %adjust_timeout() %[%{?__timeout_coefficient}%{?!__timeout_coefficient:1} * 
> %1]
> 
> (It would require a rewrite to Lua / Shell if we want to support float values 
> as 
> well, as RPM expressions AFAIK only know integers.)
> 
> -
> 
> Obviously, there is a downside. If we go this way and define %adjust_timeout 
> in 
> Fedora and/or upstream RPM, spec files with --timeout %{adjust_timeout 3600} 
> will only work on new enough Fedoras. There is an ugly way to actually make 
> the 
> spec file compatible with past versions:
> 
>  --timeout %{?adjust_timeout:%{adjust_timeout 
> 3600}}%{?!adjust_timeout:3600}
> 
> Since this is hideous, I would prefer to backport the macro wherever possible 
> :/
> 
> 



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

[Peter Boy]

> Am 27.01.2021 um 13:56 schrieb Robert Marcano via devel 
> :
> 
> On 1/25/21 5:53 AM, Peter Boy wrote:
>> With Fedora 33 network configuration is by default persisted in 
>> /etc/NetworkManager/system-connections/*.nmconnection files. The old 
>> /etc/sysconfig/network-scripts/ifcfg* files are „legacy“. They are still 
>> being processed for the time being, but obviously it is time to migrate.
>> (cf 
>> https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh).
>> Is there a kind of „mapping“ ifcfg-* —> *-nmconnection. ?
> 
> You can "migrate" using nmcli:
> 
> Save the output of `nmcli connection show `, then 
> create a new empty one a do a diff of the new `nmcli connection show 
> ` with the old one. Set set the differences on the new 
> connection with `nmcli connection modify ...`
> 

Thanks, it worked. Saves the effort of searching for the correct syntax for 
each parameter. Very nice. 


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

[Peter Boy]

> Am 27.01.2021 um 13:18 schrieb Dominik 'Rathann' Mierzejewski 
> :
> 
> On Wednesday, 27 January 2021 at 13:11, Arthur G wrote:
>> Too bad NetworkManager persists with the old MS-DOS "INI" file format for
>> it's configuration files. At least network-scripts was bash script friendly.
> 
> You can use crudini to manage .ini files. Works quite well. There's also
> nmcli...

Did not know that. Very convenient indeed for ini files. Thanks
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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?

[Neal Gompa]

On Sun, Jan 31, 2021 at 11:55 AM Peter Boy  wrote:
>
>
>
> > Am 27.01.2021 um 13:18 schrieb Dominik 'Rathann' Mierzejewski 
> > :
> >
> > On Wednesday, 27 January 2021 at 13:11, Arthur G wrote:
> >> Too bad NetworkManager persists with the old MS-DOS "INI" file format for
> >> it's configuration files. At least network-scripts was bash script 
> >> friendly.
> >
> > You can use crudini to manage .ini files. Works quite well. There's also
> > nmcli...
>
> Did not know that. Very convenient indeed for ini files. Thanks

It's not INI either, it's GNOME GVariant file format:
https://developer.gnome.org/glib/stable/gvariant-text.html

It's *similar* to INI, but has slightly different rules.



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

[Test-Announce] 2021-02-01 @ 16:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2021-02-01
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

We didn't meet for a couple of weeks, and there are interesting goings-
on, so let's meet up tomorrow.

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 34 status and Changes
3. Criteria proposals, etc.
4. Test Day / community event status
5. Open floor
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


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

btrfs hash algorithm (should xxhash be the default?)

[Matthew Miller]

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?

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

[Neal Gompa]

On Sun, Jan 31, 2021 at 1:57 PM 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 can't see a reason why we wouldn't at least move to xxhash, given
what hardware profiles we're typically running on.

Could you file an issue on the fedora-btrfs project[1] on it?

[1]: https://pagure.io/fedora-btrfs/project


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

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

[Matthew Miller]

On Sun, Jan 31, 2021 at 02:00:02PM -0500, Neal Gompa wrote:
> Could you file an issue on the fedora-btrfs project[1] on it?

Done (with exactly the same text as my email here): 

https://pagure.io/fedora-btrfs/project/issue/40

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

[Florian Weimer]

* Matthew Miller:

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

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Jython maintainer for Fedora needed

[Miro Hrončok]

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.


I'd like to keep Jython in Fedora, but my interest is not driven by any actual 
need. I don't know any actual Jythonistas using Fedora. Do you? Are there any?


I can help with the Python side of things wrt Jython maintenance, but my Java 
skills are almost non-existent.


If there is someone who would like to keep Jython in Fedora by maintaining it, 
even if they are not yet a packager, please talk to me.


Thanks,
--
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: Jython maintainer for Fedora needed

[Stephen John Smoogen]

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

What does having Jython remain in Fedora help with?



> I'd like to keep Jython in Fedora, but my interest is not driven by any
> actual
> need. I don't know any actual Jythonistas using Fedora. Do you? Are there
> any?
>
> I can help with the Python side of things wrt Jython maintenance, but my
> Java
> skills are almost non-existent.
>
> If there is someone who would like to keep Jython in Fedora by maintaining
> it,
> even if they are not yet a packager, please talk to me.
>
> Thanks,
> --
> 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

Re: Jython maintainer for Fedora needed

[Miro Hrončok]

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.


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

Re: Fedora 33 network configuration (ifcfg*) migration guide available?

[Kevin Kofler via devel]

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

Re: Fedora rawhide compose report: 20210129.n.0 changes

[Kevin Fenzi]

On Sun, Jan 31, 2021 at 03:28:15PM +0100, Miro Hrončok wrote:
> On 30. 01. 21 19:12, Kevin Fenzi wrote:
> > resubmit should resubmit it just the way it was, ie, against
> > f34-rebuild. A new build should get a new taskid, but this seemed to be
> > the same one the releng one had. Dunno. Perhaps we could ask the people
> > doing this?
> 
> I've recently did:
> 
> $ koji tag f34-pending rb_libtorrent-1.2.11-3.fc34
> 
> To fix a problem in rawhide that was fixed by the mass rebuild build.
> 
> Should I not do that?

It shouldn't cause any great problem... as long as it doesn't break
anything in rawhide. When we tag the rebuild side tag in, it will see
that it's already in and not move it. 

But indeed that is one way such a build could appear in the rawhide
report per merge. 

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

License change: libevdev -> MIT

[Peter Hutterer]

Thanks to a copy/paste error many years ago, libevdev's COPYING file
contained the HPND sell variant [1], not the intended MIT license. This has
been fixed upstream with the 1.11.0 release which is currently hitting the
Fedora repos.

libevdev was always meant to be MIT, from the developer's perspective this
isn't a license change as such, it's more getting the paperwork in order.
From a legal perspective... IANAL.

Cheers,
   Peter

[1] https://spdx.org/licenses/HPND-sell-variant.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: [Help wanted] Setting vi/view/vim via alternatives

[Zdenek Dohnal]

Thank you, Vitaly and Fabio!

That makes sense, I didn't look on the issue from new user's view. Most
people who use vi/vim are aware of the differences and wanted vi/vim
just work if the other is not installed, so vi/vim are drop-in
replacements for them in this matter of speaking. And Vi is just a Vim
compiled more strictly nowadays, so it adds another confusion :) .

But speaking technically, they aren't drop-in replacements because of
different configuration options.

I will drop alternatives usage and use wrappers - then it will work for
immutable Fedoras too.

On 1/30/21 7:41 PM, Fabio Valentini wrote:
> On Sat, Jan 30, 2021 at 7:24 PM Peter Boy  wrote:
>>
>>
>>> Am 30.01.2021 um 17:45 schrieb Vitaly Zaitsev via devel 
>>> :
>>>
>>> On 30.01.2021 16:58, Peter Boy wrote:
 But it’s perfectly usable for Fedora Workstation or Server and almost 
 indispensable for some development projects, e.g. Java (and vi/vim for a 
 terminal environment). Why should alternatives not be usable there?  Or 
 what is a suitable  and adequate replacement?
>>> https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
>> Thanks for the info. Unfortunately, I don’t see a connection to immutable 
>> Fedora (it is about drop-in, user configurable, etc). Or do I miss something?
> If you read the Packaging Guidelines, they actually explicitly mention
> that vi / vim are a bad example for using the alternatives system -
> because they're not drop-in replacements.
>
> Additionally, as far as I know, OSTree based Fedora variants do not
> execute any RPM scriptlets, but implement their own handling of e.g.
> ldconfig and such things.
> And alternatives is definitely not compatible with OSTree - according
> to these bug reports, at least Java alternatives are broken -
> apparently primarily because OSTree stores configuration in /var
> instead of /etc:
>
> - https://bugzilla.redhat.com/show_bug.cgi?id=1657367
> - https://github.com/coreos/rpm-ostree/issues/1614
>
>
> 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

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C




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