Fedora rawhide compose report: 20191214.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20191213.n.0
NEW: Fedora-Rawhide-20191214.n.1

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  46
Dropped packages:21
Upgraded packages:   120
Downgraded packages: 1

Size of added packages:  11.40 MiB
Size of dropped packages:16.65 MiB
Size of upgraded packages:   2.44 GiB
Size of downgraded packages: 10.18 MiB

Size change of upgraded packages:   50.04 MiB
Size change of downgraded packages: 3.19 MiB

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-Rawhide-20191213.n.0.aarch64.raw.xz

= ADDED PACKAGES =
Package: cbi-plugins-1.1.5-5.fc30
Summary: A set of helpers for Eclipse CBI
RPMs:cbi-plugins cbi-plugins-javadoc
Size:225.56 KiB

Package: cdist-6.3.0-4.fc32
Summary: Usable configuration management
RPMs:cdist cdist-doc
Size:807.86 KiB

Package: eclipse-ecf-3.14.4-2.fc30
Summary: Eclipse Communication Framework (ECF) Eclipse plug-in
RPMs:eclipse-ecf-core eclipse-ecf-runtime eclipse-ecf-sdk
Size:6.13 MiB

Package: fira-code-fonts-2-1.fc32
Summary: Monospaced font with programming ligatures
RPMs:fira-code-fonts
Size:309.12 KiB

Package: keylime-5.4.1-1.fc32
Summary: Open source TPM software for Bootstrapping and Maintaining Trust
RPMs:keylime
Size:376.50 KiB

Package: python-django-ipware-2.1.0-2.fc32
Summary: A Django application to retrieve client's IP address
RPMs:python3-django-ipware
Size:29.48 KiB

Package: python-django-rules-2.1.0-2.fc32
Summary: Awesome Django authorization, without the database
RPMs:python3-django-rules
Size:44.54 KiB

Package: python-mozilla-django-oidc-1.2.2-2.fc32
Summary: A django OpenID Connect library
RPMs:python3-mozilla-django-oidc
Size:39.10 KiB

Package: rust-actix-macros-0.1.0-1.fc32
Summary: Actix runtime macros
RPMs:rust-actix-macros+default-devel rust-actix-macros-devel
Size:16.09 KiB

Package: rust-actix-testing-1.0.0-1.fc32
Summary: Actix testing utils
RPMs:rust-actix-testing+default-devel rust-actix-testing-devel
Size:23.06 KiB

Package: rust-actix-tls-1.0.0-1.fc32
Summary: Actix tls services
RPMs:rust-actix-tls+default-devel rust-actix-tls+native-tls-devel 
rust-actix-tls+nativetls-devel rust-actix-tls+openssl-devel 
rust-actix-tls+rustls-devel rust-actix-tls+tokio-openssl-devel 
rust-actix-tls+tokio-rustls-devel rust-actix-tls+tokio-tls-devel 
rust-actix-tls+webpki-devel rust-actix-tls+webpki-roots-devel 
rust-actix-tls-devel
Size:87.29 KiB

Package: rust-alloc-no-stdlib-2.0.1-1.fc32
Summary: Dynamic allocator that may be used with or without the stdlib
RPMs:rust-alloc-no-stdlib+default-devel rust-alloc-no-stdlib+unsafe-devel 
rust-alloc-no-stdlib-devel
Size:34.00 KiB

Package: rust-alloc-stdlib-0.2.1-1.fc32
Summary: Dynamic allocator example that may be used with the stdlib
RPMs:rust-alloc-stdlib+default-devel rust-alloc-stdlib+unsafe-devel 
rust-alloc-stdlib-devel
Size:28.77 KiB

Package: rust-assert_matches-1.3.0-1.fc32
Summary: Asserts that a value matches a pattern
RPMs:rust-assert_matches+default-devel rust-assert_matches-devel
Size:22.25 KiB

Package: rust-async-trait-0.1.21-1.fc32
Summary: Type erasure for async trait methods
RPMs:rust-async-trait+default-devel 
rust-async-trait+support_old_nightly-devel rust-async-trait-devel
Size:41.54 KiB

Package: rust-battery-0.7.5-1.fc32
Summary: Cross-platform information about the notebook batteries
RPMs:rust-battery+default-devel rust-battery-devel
Size:57.23 KiB

Package: rust-brotli-decompressor-2.3.0-1.fc32
Summary: Brotli decompressor that with an interface avoiding the rust stdlib
RPMs:rust-brotli-decompressor+alloc-stdlib-devel 
rust-brotli-decompressor+benchmark-devel rust-brotli-decompressor+default-devel 
rust-brotli-decompressor+disable-timer-devel 
rust-brotli-decompressor+pass-through-ffi-panics-devel 
rust-brotli-decompressor+seccomp-devel rust-brotli-decompressor+std-devel 
rust-brotli-decompressor+unsafe-devel rust-brotli-decompressor-devel
Size:219.02 KiB

Package: rust-bytestring-0.1.1-1.fc32
Summary: UTF-8 encoded string with Bytes as a storage
RPMs:rust-bytestring+default-devel rust-bytestring-devel
Size:21.79 KiB

Package: rust-chunked_transfer-1.0.0-1.fc32
Summary: Encoder and decoder for HTTP chunked transfer coding (RFC 7230 ?? 4.1)
RPMs:rust-chunked_transfer+default-devel rust-chunked_transfer-devel
Size:23.03 KiB

Package: rust-futures-0.3.1-1.fc32
Summary: Implementation of futures and streams
RPMs:rust-futures+alloc-devel rust-futures+async-await-devel 
rust-futures+bilock-devel rust-futures+cfg-target-has-atomic-devel 
rust-futures+compat-devel rust-futures+default-devel 
rust-futures+executor-devel rust-futures+futures-executor-devel 
rust-futures+io-compat-devel rust-futures+read-initializer-devel 
rust-futures+std-devel rust-futures+thread-pool-devel 
rust-futures+uns

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

[Fedora compose checker]

No missing expected images.

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

Failed openQA tests: 17/165 (x86_64), 1/2 (arm)

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

ID: 498373  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/498373
ID: 498374  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/498374
ID: 498375  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/498375
ID: 498376  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/498376
ID: 498388  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/498388
ID: 498390  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/498390
ID: 498394  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/498394
ID: 498444  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING**
URL: https://openqa.fedoraproject.org/tests/498444
ID: 498505  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/498505
ID: 498506  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/498506
ID: 498518  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/498518
ID: 498522  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/498522

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

ID: 498377  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/498377
ID: 498393  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/498393
ID: 498423  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/498423
ID: 498432  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/498432
ID: 498450  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/498450
ID: 498520  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/498520

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

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

ID: 498358  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/498358
ID: 498359  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/498359
ID: 498369  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/498369
ID: 498371  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/498371
ID: 498372  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/498372
ID: 498406  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/498406
ID: 498411  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/498411
ID: 498424  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/498424
ID: 498429  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/498429
ID: 498480  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/498480
ID: 498486  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/498486
ID: 498487  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/498487

Passed openQA tests: 136/165 (x86_64)

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

ID: 498422  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/498422

Skipped non-gating openQA tests: 1 of 167

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
System load changed from 0.03 to 0.19
Previous test data: https://openqa.fedoraproject.org/tests/498027#downloads
Current test data: https://openqa.fedoraproject.org/tests/498366#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Used swap changed from 6 MiB to 7 MiB
System load changed from 1.49 to 0.98
Average CPU usage changed from 24.24285714 to 10.68095238
Previous test data: https://openqa.fedoraproject.org/tests/498060#downloads
C

Re: No pthread on s390x?

[Kevin Kofler]

Jerry James wrote:
> $ gcc -specs=/usr/lib/rpm/redhat/redhat-hardened-ld test.c -o test
> -lpthread /usr/bin/ld: /tmp/ccWdPlbg.o: `pthread_create@@GLIBC_2.2'
> non-PLT reloc for symbol defined in shared library and accessed from
> executable (rebuild file with -fPIC ?)

The problem is that both your test invocation above and the original 
invocation from CMake are passing
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld and not
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1. The code needs to be 
compiled with the redhat-hardened-cc1 specs (which will enable -fpie) so 
that it can be linked with the redhat-hardened-ld specs.

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: stime() is no longer declared in time.h for rawhide

[Kevin Kofler]

Tom Hughes wrote:
> Commit history explains:
> 
>https://sourceware.org/git/?p=glibc.git;a=commit;h=12cbde1da

For what it's worth, I think this is a completely pointless incompatibility.

It costs almost nothing to maintain this function (and in fact they have to 
do it anyway for old binaries), so I do not see the point of hiding it from 
the linker at all. All it means is that the applications have to copy&paste 
the same boilerplate everywhere (and do it wrong, e.g., Martin Gansser's 
patch will trigger an – admittedly harmless – compiler warning due to 
partial structure initialization). Sure, the new API is better because it 
supports split seconds, but if you do not have any nanoseconds to pass to 
it, there is no benefit in setting up the structure in the caller instead of 
letting glibc do it.

So I do not understand at all why glibc is now hiding this function from the 
compiler and the linker.

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: eit.c:394:13: error: 'stime' was not declared in this scope; did you mean 'ctime'?

[Kevin Kofler]

Martin Gansser wrote:
> +timespec ts = {0};

The compiler will warn about the missing initializers with this idiom. 
(struct timespec has more than one member.) Write this instead:
timespec ts = {};
(If you omit the initializer list within the braces entirely, as I have done 
above, GCC will know that you want to initialize the struct to all zeros and 
not complain about the missing zeros. Just make sure you keep the = {} part, 
otherwise the struct will not be initialized at all.)

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 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[John M. Harris Jr]

On Saturday, December 14, 2019 10:42:57 AM MST Adam Williamson wrote:
> > What is the process for this now? i.e. is this only tested once virtual cd
> >  image tests have been completed?
> 
> 
> Yes, but I don't see the *relevance* of that. You keep mentioning it,
> but I don't see what it has to do with the Change at all. The physical
> testing takes the same time either way.

To clarify, I only asked this once, because it was an obvious area to remove 
the need for physical media, if it wasn't already done. I didn't really expect 
a different answer, but didn't want to run with an assumption.

> It would be nearly impossible to do the physical testing before virtual
> tests have run, because the virtual tests are automated, openQA runs
> them as soon as the compose completes. If virtual optical media boot is
> broken we find out approximately 10 minutes after the compose completes
> (5 minutes for the tests to be scheduled and the Everything network
> install ISO to be downloaded, 5 minutes for the test to time out).
> 
> 
> > As for having a DVD burner, that's been a standard option on workstations
> > since ~2005.
> 
> 
> Well...not really. It *was* a standard option in 2005. It is
> increasingly becoming less standard as time goes on.

I find it hard to believe that this is just something I'm experiencing, but 
here's a little anecdote. I recently ordered a set of RHEL certified 
workstations from Dell. We never mentioned that we needed a CD/DVD drive, and 
yet each system had a DVD R/W drive.

-- 
John M. Harris, Jr.
Splentity

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

[Nathanael Noblet]

> On Dec 14, 2019, at 10:46 AM, Stephan Bergmann  wrote:
> 
> On 14/12/2019 18:00, Nathanael Noblet wrote:
>>   Not strictly a fedora devel question but I’m hoping all the experience and 
>> knowledge will be able to help. I need a newer poppler in epel 7. I’ve 
>> managed to bring it up to 0.68. However moving past that results in a 
>> compilation error. It seems the compiler (?) needs to support the c++14 
>> standard. I’m using devtoolset-8 to get gcc 8.3.1 and from what I can find 
>> via google, this really should support c++14 (in this case 
>> std::string_literals). However when it compiles it sets the std to c++1y 
>> which was an alias for the draft of c++14 from what I can gather. If I go 
>> into a mock shell however and manually run it with --std=c++14 it still 
>> fails. When I grep through the includes for each it seems both have 
>> definitions for them but it still fails. Can anyone supplement what I have 
>> wrong here? Should c++ 8.3.1 be able to handle std::string_literals? It 
>> somewhat confuses me that people are talking about the compiler and not some 
>> library supporting it. Any pointers/help would be appreciated. Here’s a 
>> snippet of the build log.
> 
> Are you sure that the below /usr/bin/c++ really points to the devtoolset-8 
> GCC?  GCC 8 (or rather, its accompanying libstdc++) should be new enough to 
> support string_literals (see "User-defined literals for  and 
> " at 
> ).

You are correct that I had the BuildRequires for devtoolset-8 but in double 
checking realized that I hadn’t enabled it prior to building!!! I was confused 
because when I went into the shell and enabled it and manually changed the 
command below it still failed so was confused by that. Now that I’ve added the 
proper call in the build section it is building. It still fails but not because 
of that anymore so I can move on to my next steps. Thanks for your help!

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Chris Murphy]

On Sat, Dec 14, 2019 at 7:26 AM Justin W. Flory  wrote:
>
> (1) This change affects people differently in different regions of the world
>
> The Fedora community has large user and contributor communities all over the 
> world. Historically, our Ambassadors/Advocates relied on DVD media in these 
> regions to install Fedora and promote it at events, because there is not 
> always reliable, consistent Internet connection in parts of these regions. 
> Additionally, the hardware that exists in these regions is often 
> previous-generation hardware that does not mirror the same hardware advances 
> in the West.
>
> Without more data on DVD media usage to support this Change, I am concerned 
> of the impact of this Change on Fedora user and advocacy communities that may 
> still rely on this as a vital deliverable to support their community work in 
> promoting Fedora globally.

Related questions, though possibly tangent to this Change, in the
context of regions where Internet is not as reliable or fast:

Is it typical that installations are not immediately updated? By
default, Fedora Workstation will start downloading updates within
minutes of the first login (following first user creation in GNOME
Initial Setup). Not merely updated repo metadata, but the actual RPMs.
Soon after release, weeks, this first update payload is easily the
size of the Workstation Live ISO. Is it typical to setup a local
mirror to mitigate this problem? If it were easier to setup a local
mirror, or locally mirror a subset of the RPMs in a release, would
that help make netinstall more viable in addition to making it easier
to provide up to date installations?

If it's most helpful to have a self-contained initial installation, is
the current 2GB Workstation Live size limitation actually a negative?
As in, there's generally a desire for more pre-installed applications
and functionality? A larger ISO translates into an even larger update
demand when the time comes, so it's a balancing act of course - but
I'm wondering whether a sub 2GB ISO size for this use case actually
makes things more difficult. Or if it's considered OK as is.

Thanks,

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

[Test-Announce] Proposal to CANCEL: 2019-12-16 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting for Monday. There are
various proposals under active discussion, but I'm not sure we need a
meeting to discuss any of them right now, they probably need a bit more
mailing list kicking around.

If you're aware of anything important we have to discuss this week,
please do reply to this mail. I may not be around to run the meeting,
though, I'm officially going to be off work as I'm burning off the
vacation days I have left over for this year. I may be around anyway,
but I'm not committed to it. :P

Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://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

Re: No pthread on s390x?

[Jerry James]

On Sat, Dec 14, 2019 at 6:28 AM Richard Shaw  wrote:
> This error only happens on s390x...
>
> -- Looking for pthread.h
> -- Looking for pthread.h - found
> -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
> -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
> -- Looking for pthread_create in pthreads
> -- Looking for pthread_create in pthreads - not found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - not found
> -- Check if compiler accepts -pthread
> -- Check if compiler accepts -pthread - no
> CMake Error at 
> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
>   Could NOT find Threads (missing: Threads_FOUND)
> Call Stack (most recent call first):
>   /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:393 
> (_FPHSA_FAILURE_MESSAGE)
>   /usr/share/cmake/Modules/FindThreads.cmake:220 
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>   /usr/lib64/cmake/Qt5UiTools/Qt5UiToolsConfig.cmake:73 (find_package)
>   /usr/lib64/cmake/Qt5UiTools/Qt5UiToolsConfig.cmake:233 
> (_qt5_UiTools_process_prl_file)
>   sources/cmake_helpers/helpers.cmake:21 (find_package)
>   sources/pyside2/CMakeLists.txt:159 (collect_optional_modules)
> -- Configuring incomplete, errors occurred!
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=39567395
>
> On other platforms the last check succeeds. I've never run into this before.
>
> Ideas?

The cmake log says:

Determining if the function pthread_create exists in the pthread
failed with the following output:
Change Dir: 
/builddir/build/BUILD/pyside-setup-opensource-src-5.13.2/s390x-linux/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/gmake cmTC_a4bb3/fast && /usr/bin/gmake
-f CMakeFiles/cmTC_a4bb3.dir/build.make
CMakeFiles/cmTC_a4bb3.dir/build
gmake[1]: Entering directory
'/builddir/build/BUILD/pyside-setup-opensource-src-5.13.2/s390x-linux/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_a4bb3.dir/CheckFunctionExists.c.o
/usr/bin/cc   -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches -m64 -march=zEC12
-mtune=z13 -fasynchronous-unwind-tables
-DCHECK_FUNCTION_EXISTS=pthread_create   -o
CMakeFiles/cmTC_a4bb3.dir/CheckFunctionExists.c.o   -c
/usr/share/cmake/Modules/CheckFunctionExists.c
Linking C executable cmTC_a4bb3
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_a4bb3.dir/link.txt
--verbose=1
/usr/bin/cc -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches -m64 -march=zEC12
-mtune=z13 -fasynchronous-unwind-tables
-DCHECK_FUNCTION_EXISTS=pthread_create  -Wl,-z,relro -Wl,--as-needed
-Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -rdynamic
CMakeFiles/cmTC_a4bb3.dir/CheckFunctionExists.c.o  -o cmTC_a4bb3
-lpthread
/usr/bin/ld: CMakeFiles/cmTC_a4bb3.dir/CheckFunctionExists.c.o:
`pthread_create@@GLIBC_2.2' non-PLT reloc for symbol defined in shared
library and accessed from executable (rebuild file with -fPIC ?)
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_a4bb3.dir/build.make:87: cmTC_a4bb3] Error 1
gmake[1]: Leaving directory
'/builddir/build/BUILD/pyside-setup-opensource-src-5.13.2/s390x-linux/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:121: cmTC_a4bb3/fast] Error 2

Indeed, something is seriously borked on s390x Rawhide.  Try compiling
this simple C program:

#include 

void* test_func(void* data)
{
  return data;
}

int main(void)
{
  pthread_t thread;
  pthread_create(&thread, NULL, test_func, NULL);

  return 0;
}

like this:

$ gcc -specs=/usr/lib/rpm/redhat/redhat-hardened-ld test.c -o test -lpthread
/usr/bin/ld: /tmp/ccWdPlbg.o: `pthread_create@@GLIBC_2.2' non-PLT
reloc for symbol defined in shared library and accessed from
executable (rebuild file with -fPIC ?)
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

The -spec flag seems to be triggering the issue.  The contents of
/usr/lib/rpm/redhat/redhat-hardened-ld are:

*self_spec:
+ %{!static:%{!shared:%{!r:-pie}}}

which indicates that executables (which are neither static nor shared)
are to be linked with -pie.  Sure enough:

$ gcc -pie test.c -o test -lpthread
/usr/bin/ld: /tmp/ccUbJfXW.o: `pthread_create@@GLIBC_2.2' non-PLT
reloc for symbol defined in shared library and accessed from
executable (rebuild file with -fPIC ?)
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

None of this happens in F31.
-- 
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.f

Re: c++ std=c++14 in EPEL7

[Stephan Bergmann]

On 14/12/2019 18:00, Nathanael Noblet wrote:

   Not strictly a fedora devel question but I’m hoping all the experience and 
knowledge will be able to help. I need a newer poppler in epel 7. I’ve managed 
to bring it up to 0.68. However moving past that results in a compilation 
error. It seems the compiler (?) needs to support the c++14 standard. I’m using 
devtoolset-8 to get gcc 8.3.1 and from what I can find via google, this really 
should support c++14 (in this case std::string_literals). However when it 
compiles it sets the std to c++1y which was an alias for the draft of c++14 
from what I can gather. If I go into a mock shell however and manually run it 
with --std=c++14 it still fails. When I grep through the includes for each it 
seems both have definitions for them but it still fails. Can anyone supplement 
what I have wrong here? Should c++ 8.3.1 be able to handle 
std::string_literals? It somewhat confuses me that people are talking about the 
compiler and not some library supporting it. Any pointers/help would be 
appreciated. Here’s a snippet of the build log.


Are you sure that the below /usr/bin/c++ really points to the 
devtoolset-8 GCC?  GCC 8 (or rather, its accompanying libstdc++) should 
be new enough to support string_literals (see "User-defined literals for 
 and " at 
).



/usr/bin/c++  -Dpoppler_EXPORTS -I/builddir/build/BUILD/poppler-0.73.0 
-I/builddir/build/BUILD/poppler-0.73.0/fofi 
-I/builddir/build/BUILD/poppler-0.73.0/goo 
-I/builddir/build/BUILD/poppler-0.73.0/poppler 
-I/builddir/build/BUILD/poppler-0.73.0/build 
-I/builddir/build/BUILD/poppler-0.73.0/build/poppler -I/usr/include/freetype2 
-I/usr/include/openjpeg-2.3  -Wall -Wextra -Wpedantic -Wno-unused-parameter 
-Wcast-align -Wformat-security -Wframe-larger-than=65536 -Wlogical-op 
-Wmissing-format-attribute -Wnon-virtual-dtor -Woverloaded-virtual 
-Wmissing-declarations -Wundef -Wzero-as-null-pointer-constant -fno-exceptions 
-fno-check-new -fno-common -D_DEFAULT_SOURCE -O2 -g -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic 
-DQT_NO_DEBUG -fPIC   -I/usr/include/nss3 -I/usr/include/nspr4 -pthread 
-std=c++1y -o CMakeFiles/poppler.dir/fofi/FoFiType1.cc.o -c 
/builddir/build/BUILD/poppler-0.73.0/fofi/FoFiType1.cc
/builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc:70:22: error: 
'string_literals' is not a namespace-name
  using namespace std::string_literals;
   ^
/builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc:70:37: error: expected 
namespace-name before ';' token
  using namespace std::string_literals;
  ^
/builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc: In function 'FILE* 
openFile(const char*, const char*)':
/builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc:369:38: error: unable to find string 
literal operator 'operator"" s'
const std::string modeStr = mode + "e”s;

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Adam Williamson]

On Sat, 2019-12-14 at 10:28 -0700, John M. Harris Jr wrote:
> On Saturday, December 14, 2019 9:26:12 AM MST Adam Williamson wrote:
> > Note, the testing isn't *hard* to do, really, it's just tedious and
> > time consuming. Not just the act of running the test (though that does
> > take quite a while, between the burning process and the boot, media
> > check and install itself), but the fact that it means we need to ensure
> > we have at least a couple of people who still have access to a DVD
> > burner and blank media.
> 
> What is the process for this now? i.e. is this only tested once virtual cd 
> image tests have been completed?

Yes, but I don't see the *relevance* of that. You keep mentioning it,
but I don't see what it has to do with the Change at all. The physical
testing takes the same time either way.

It would be nearly impossible to do the physical testing before virtual
tests have run, because the virtual tests are automated, openQA runs
them as soon as the compose completes. If virtual optical media boot is
broken we find out approximately 10 minutes after the compose completes
(5 minutes for the tests to be scheduled and the Everything network
install ISO to be downloaded, 5 minutes for the test to time out).

> As for having a DVD burner, that's been a standard option on workstations 
> since ~2005.

Well...not really. It *was* a standard option in 2005. It is
increasingly becoming less standard as time goes on.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[John M. Harris Jr]

On Saturday, December 14, 2019 9:26:12 AM MST Adam Williamson wrote:
> Note, the testing isn't *hard* to do, really, it's just tedious and
> time consuming. Not just the act of running the test (though that does
> take quite a while, between the burning process and the boot, media
> check and install itself), but the fact that it means we need to ensure
> we have at least a couple of people who still have access to a DVD
> burner and blank media.

What is the process for this now? i.e. is this only tested once virtual cd 
image tests have been completed?

As for having a DVD burner, that's been a standard option on workstations 
since ~2005.

-- 
John M. Harris, Jr.
Splentity

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[John M. Harris Jr]

On Saturday, December 14, 2019 7:39:15 AM MST Miro Hrončok wrote:
> On 14. 12. 19 15:25, Justin W. Flory wrote:
> 
> > I was surprised to see this Change be proposed without engagement with the
> > Fedora Mindshare Committee or reaching out to the advocacy / user
> > communities for more feedback. 
> 
> Just a note without replying to your other specific concerns.
> 
> The devel list is the first place where developers gather feedback. The idea
> to  reach a committee (whether FESCo or Mindshare) before reaching to
> devel is hence entirely wrong in my opinion. Committees should rubber stamp
> community decisions, not drive them.

Agreed, though I wouldn't say "rubber stamp", so much as "influence".

-- 
John M. Harris, Jr.
Splentity

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

c++ std=c++14 in EPEL7

[Nathanael Noblet]

Hello,

  Not strictly a fedora devel question but I’m hoping all the experience and 
knowledge will be able to help. I need a newer poppler in epel 7. I’ve managed 
to bring it up to 0.68. However moving past that results in a compilation 
error. It seems the compiler (?) needs to support the c++14 standard. I’m using 
devtoolset-8 to get gcc 8.3.1 and from what I can find via google, this really 
should support c++14 (in this case std::string_literals). However when it 
compiles it sets the std to c++1y which was an alias for the draft of c++14 
from what I can gather. If I go into a mock shell however and manually run it 
with --std=c++14 it still fails. When I grep through the includes for each it 
seems both have definitions for them but it still fails. Can anyone supplement 
what I have wrong here? Should c++ 8.3.1 be able to handle 
std::string_literals? It somewhat confuses me that people are talking about the 
compiler and not some library supporting it. Any pointers/help would be 
appreciated. Here’s a snippet of the build log.


/usr/bin/c++  -Dpoppler_EXPORTS -I/builddir/build/BUILD/poppler-0.73.0 
-I/builddir/build/BUILD/poppler-0.73.0/fofi 
-I/builddir/build/BUILD/poppler-0.73.0/goo 
-I/builddir/build/BUILD/poppler-0.73.0/poppler 
-I/builddir/build/BUILD/poppler-0.73.0/build 
-I/builddir/build/BUILD/poppler-0.73.0/build/poppler -I/usr/include/freetype2 
-I/usr/include/openjpeg-2.3  -Wall -Wextra -Wpedantic -Wno-unused-parameter 
-Wcast-align -Wformat-security -Wframe-larger-than=65536 -Wlogical-op 
-Wmissing-format-attribute -Wnon-virtual-dtor -Woverloaded-virtual 
-Wmissing-declarations -Wundef -Wzero-as-null-pointer-constant -fno-exceptions 
-fno-check-new -fno-common -D_DEFAULT_SOURCE -O2 -g -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic 
-DQT_NO_DEBUG -fPIC   -I/usr/include/nss3 -I/usr/include/nspr4 -pthread 
-std=c++1y -o CMakeFiles/poppler.dir/fofi/FoFiType1.cc.o -c 
/builddir/build/BUILD/poppler-0.73.0/fofi/FoFiType1.cc
/builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc:70:22: error: 
'string_literals' is not a namespace-name
 using namespace std::string_literals;
  ^
/builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc:70:37: error: expected 
namespace-name before ';' token
 using namespace std::string_literals;
 ^
/builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc: In function 'FILE* 
openFile(const char*, const char*)':
/builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc:369:38: error: unable to find 
string literal operator 'operator"" s'
   const std::string modeStr = mode + "e”s;

Thanks in advance for anyone able to shed some light on this for me.

Sincerely,
— 
Nathanael


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Adam Williamson]

On Sat, 2019-12-14 at 09:37 -0500, Nico Kadel-Garcia wrote:
> On Sat, Dec 14, 2019 at 9:26 AM Justin W. Flory  wrote:
> 
> > For what it's worth, I like Miro's idea a lot but also haven't
> > thought about it extensively. I think this could prioritize these
> > issues as release-blocking when we don't have enough data to
> > understand the impact of this Change, but it also saves a lot of
> > time and effort on the QA team for shipping releases to focus on
> > other things. Another piece of feedback I'd be interested to know
> > is how often serious issues do come up when testing optical media,
> > or if the issue is that it is just a lot of manual work that is
> > hard to do.
> > 
> > Some of my 2¢.
> 
> Isn't the primary optical media testing done these days by mounting an
> iso image attached to a virtual machine? I'd not even bother burning
> media these days until it passed this test, due to the need for
> hands-on media management. And it's certainly one of the use caes for
> virtual media and iso images. I'm not suggesting that physical media
> not be tested, but isn't all the media testing first done with a
> virtual OS and virtual media? In which case, the virtual image testing
> is pretty much happening anyway.

Yes, but the point of this proposal is that we are still required to
test actual physical media. Booting from a virtual optical disc is
tested automatically several dozen times with each nightly compose.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Adam Williamson]

On Sat, 2019-12-14 at 14:25 +, Justin W. Flory wrote:
> (2) USB media were always turned down in the Fedora budget requests
> for Ambassadors/Advocates throughout the last decade.
> 
> In the Ambassador/Advocate community, there are volunteers from North
> America / Europe who advocated for Fedora USB keys for years.
> Throughout my five or six years in Fedora now, these requests from
> the community were always turned down because of cost. If memory
> serve me correctly, the cost of mass-producing USB media for our
> community was $100s of USD, if not $1000s, more.
> 
> So, the other consequence of this Change could be that we leave a lot
> of people doing valuable community work behind, because DVD media is
> no longer release blocking and Fedora community advocates can't get
> USB keys funded. (Except, somehow, Fedora-branded USB keys were
> acquired for past FOSDEM events, I don't remember seeing this
> decision work its way through the community though.)

If there are all these thousands of people out there who care deeply
about the optical media...wouldn't it be nice if some of them turned up
and helped run the tests once in a while?

> > Juts a random idea, not very thought-out:
> > Could we keep optical media bugs reported by users as blocking, but not 
> > require 
> > it during validation testing?
> > aka: Fedora QE would no longer have to verify optical media works.
> > but: If a tester finds an optical media  bug, it is still blocking.
> > That would still have 2 of the 3 listed benefits. The remaining benefit is 
> > arguable (is optical media a corner case? there are no corners on DVD).
> 
> For what it's worth, I like Miro's idea a lot but also haven't
> thought about it extensively. I think this could prioritize these
> issues as release-blocking when we don't have enough data to
> understand the impact of this Change, but it also saves a lot of time
> and effort on the QA team for shipping releases to focus on other
> things. Another piece of feedback I'd be interested to know is how
> often serious issues do come up when testing optical media, or if the
> issue is that it is just a lot of manual work that is hard to do.

Very very rarely. As Chris Murphy wrote, by pure coincidence one showed
up the day before yesterday (to be clear, it has nothing at all to do
with this Change proposal, the proposers of the Change were not aware
of that bug until well after the Change was submitted). Before that the
last time I can find, by searching my Bugzilla mail box for relevant
words at least, is 2015:

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

the last time we had a *fatal* issue that I can find is 2014:

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

Note, the testing isn't *hard* to do, really, it's just tedious and
time consuming. Not just the act of running the test (though that does
take quite a while, between the burning process and the boot, media
check and install itself), but the fact that it means we need to ensure
we have at least a couple of people who still have access to a DVD
burner and blank media.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Adam Williamson]

On Sat, 2019-12-14 at 14:25 +, Justin W. Flory wrote:
> Hi all,
> 
> I was surprised to see this Change be proposed without engagement
> with the Fedora Mindshare Committee or reaching out to the advocacy /
> user communities for more feedback. There are a lot of people this
> Change could impact and I am concerned many of those voices are not
> represented in this discussion or on this list.
> 
> Is there any data or supporting evidence to support back this Change?
> Other than private RH BZ customer tickets? I am really curious to
> know the "why" behind this Change other than eliminating an
> admittedly tedious task for the QA team to perform. I am thinking
> about this from two points-of-view:

There is no "why" behind this Change "other than eliminating an
admittedly tedious task for the QA team". That's the whole thing. There
aren't any "private RH BZ customer tickets". Why would RH customers
care about whether or not Fedora blocks on physical optical media
booting?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora Packager Dashboard mockups

[Miro Hrončok]

Hello devel,

I got nerdslipped and I ahve created some HTML only mockup of a thing that I 
find very useful. A Fedora Packager Dashboard.


You can find the early mockup at:

https://hroncok.cz/packager-dashboard-mockup/


The idea is to collect some data about your packages and present them in some 
nice form. Such data would be gathered by plugins. Examples on the mockup:


 - active updates
 - active buildroot overrides
 - open PRs
 - orphaned or broken depnddencies
 - bugzillas
 - FTBFS (from koschei)

Ideas not included in the mockup:

 - running Koji builds

Let me know what you think. I can work on this on the backend level (plugin 
architecture design, gathering data, cache...) but even copy pasting HTML from 
Bodhi to present the mockup was very painful for me, so if we want this, 
somebody with more fronted experience would need to help.


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

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Miro Hrončok]

On 14. 12. 19 15:25, Justin W. Flory wrote:
I was surprised to see this Change be proposed without engagement with the Fedora Mindshare Committee or reaching out to the advocacy / user communities for more feedback. 


Just a note without replying to your other specific concerns.

The devel list is the first place where developers gather feedback. The idea to 
reach a committee (whether FESCo or Mindshare) before reaching to devel is hence 
entirely wrong in my opinion. Committees should rubber stamp community 
decisions, not drive them.


As for users communities, yes, that is a good idea. However, so is first 
discussing this within the engineering contributors community and only once 
there is a consensus, involve advocacy / user communities for more feedback.


Hence, I disagree with what you say - discussing this on the devel list first is 
the best thing to do IMHO.


--
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: Regarding Adam Miller (maxamillion) packager status

[Alessio]

FYI I took ophcrack.

Ciao,
A.

On Tue, Dec 10, 2019 at 9:48 PM Miro Hrončok  wrote:
>
> On 09. 12. 19 18:38, Adam Miller wrote:
> > On Mon, Dec 9, 2019 at 11:15 AM Miro Hrončok  wrote:
> >>
> >> On 09. 12. 19 18:04, Richard Shaw wrote:
> >>> I had a short email conversation with Adam and he doesn't have time to 
> >>> maintain
> >>> any his packages anymore. I don't know how to tell which packages he's 
> >>> main
> >>> admin on but he on 391 packages overall.
> >>>
> >>> https://src.fedoraproject.org/user/maxamillion/projects
> >>
> >>
> >> This is the full list of component's where Adam is the main admin:
> >>
> >> https://src.fedoraproject.org//api/0/projects?owner=maxamillion&per_page=100&short=true&fork=false
> >>
> >>> He did point out a problem and I'm not sure what the solution is. Without 
> >>> old
> >>> pkgdb, how does one mass remove themselves from packages?
> >>
> >> Releng has a script to mass orphan packages from a list. The list can be
> >> obtained from the above. Adam, shall I run it?
> >>
> >
> > As much as I hate to say it. Yes please, have them run it.
> >
> > I hope to return as a contributor in a meaningful way one day.
> >
> > <3 Fedora
>
> Done:
>
> Giving container/cockpit to orphan
> Giving container/kubernetes to orphan
> Giving rpms/MochiKit to orphan
> Giving rpms/apachetop to orphan
> Giving rpms/binclock to orphan
> Giving rpms/http_ping to orphan
> Giving rpms/ifstatus to orphan
> Giving rpms/ike-scan to orphan
> Giving rpms/koji-containerbuild to orphan
> Giving rpms/mcollective to orphan
> Giving rpms/mcollective-qpid-plugin to orphan
> Giving rpms/mod_auth_cas to orphan
> Giving rpms/nbtscan to orphan
> Giving rpms/ninvaders to orphan
> Giving rpms/ophcrack to orphan
> Giving rpms/pscan to orphan
> Giving rpms/python-dockerpty to orphan
> Giving rpms/python-enum to orphan
> Giving rpms/python-fedmsg-rabbitmq-serializer to orphan
> Giving rpms/python-texttable to orphan
> Giving rpms/python-virtkey to orphan
> Giving rpms/reg to orphan
> Giving rpms/shed to orphan
> Giving rpms/sslstrip to orphan
> Giving rpms/tcptraceroute to orphan
> Giving rpms/tmuxinator to orphan
> Giving rpms/txt2man to orphan
> Giving rpms/vttest to orphan
>
> --
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Nico Kadel-Garcia]

On Sat, Dec 14, 2019 at 9:26 AM Justin W. Flory  wrote:

> For what it's worth, I like Miro's idea a lot but also haven't thought about 
> it extensively. I think this could prioritize these issues as 
> release-blocking when we don't have enough data to understand the impact of 
> this Change, but it also saves a lot of time and effort on the QA team for 
> shipping releases to focus on other things. Another piece of feedback I'd be 
> interested to know is how often serious issues do come up when testing 
> optical media, or if the issue is that it is just a lot of manual work that 
> is hard to do.
>
> Some of my 2¢.

Isn't the primary optical media testing done these days by mounting an
iso image attached to a virtual machine? I'd not even bother burning
media these days until it passed this test, due to the need for
hands-on media management. And it's certainly one of the use caes for
virtual media and iso images. I'm not suggesting that physical media
not be tested, but isn't all the media testing first done with a
virtual OS and virtual media? In which case, the virtual image testing
is pretty much happening anyway.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Justin W. Flory]

Hi all,

I was surprised to see this Change be proposed without engagement with the 
Fedora Mindshare Committee or reaching out to the advocacy / user communities 
for more feedback. There are a lot of people this Change could impact and I am 
concerned many of those voices are not represented in this discussion or on 
this list.

Is there any data or supporting evidence to support back this Change? Other 
than private RH BZ customer tickets? I am really curious to know the "why" 
behind this Change other than eliminating an admittedly tedious task for the QA 
team to perform. I am thinking about this from two points-of-view:


(1) This change affects people differently in different regions of the world

The Fedora community has large user and contributor communities all over the 
world. Historically, our Ambassadors/Advocates relied on DVD media in these 
regions to install Fedora and promote it at events, because there is not always 
reliable, consistent Internet connection in parts of these regions. 
Additionally, the hardware that exists in these regions is often 
previous-generation hardware that does not mirror the same hardware advances in 
the West.

Without more data on DVD media usage to support this Change, I am concerned of 
the impact of this Change on Fedora user and advocacy communities that may 
still rely on this as a vital deliverable to support their community work in 
promoting Fedora globally.


(2) USB media were always turned down in the Fedora budget requests for 
Ambassadors/Advocates throughout the last decade.

In the Ambassador/Advocate community, there are volunteers from North America / 
Europe who advocated for Fedora USB keys for years. Throughout my five or six 
years in Fedora now, these requests from the community were always turned down 
because of cost. If memory serve me correctly, the cost of mass-producing USB 
media for our community was $100s of USD, if not $1000s, more.

So, the other consequence of this Change could be that we leave a lot of people 
doing valuable community work behind, because DVD media is no longer release 
blocking and Fedora community advocates can't get USB keys funded. (Except, 
somehow, Fedora-branded USB keys were acquired for past FOSDEM events, I don't 
remember seeing this decision work its way through the community though.)

From a non-engineering / Fedora community perspective, I am strongly -1 to this 
proposal without more data to support this. I think a better approach to inform 
this decision is to collaborate with the Mindshare Committee on collecting 
feedback from the wider community about this Change. Holding it here on this 
mailing list is not enough because only the most active, most passionate people 
are likely to join this discussion.


> Juts a random idea, not very thought-out:
> 
> Could we keep optical media bugs reported by users as blocking, but not 
> require 
> it during validation testing?
> 
> 
> aka: Fedora QE would no longer have to verify optical media works.
> but: If a tester finds an optical media  bug, it is still blocking.
> 
> That would still have 2 of the 3 listed benefits. The remaining benefit is 
> arguable (is optical media a corner case? there are no corners on DVD).

For what it's worth, I like Miro's idea a lot but also haven't thought about it 
extensively. I think this could prioritize these issues as release-blocking 
when we don't have enough data to understand the impact of this Change, but it 
also saves a lot of time and effort on the QA team for shipping releases to 
focus on other things. Another piece of feedback I'd be interested to know is 
how often serious issues do come up when testing optical media, or if the issue 
is that it is just a lot of manual work that is hard to do.

Some of my 2¢.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Nico Kadel-Garcia]

On Sat, Dec 14, 2019 at 1:25 AM John M. Harris Jr  wrote:
>
> On Friday, December 13, 2019 1:34:29 PM MST Mike Pinkerton wrote:
> > On 13 Dec 2019, at 15:03, John M. Harris Jr wrote:
> >
> >
> > > On Friday, December 13, 2019 12:53:57 PM MST Chris Murphy wrote:
> > >
> > >>
> > >>
> > >> What? There are only two images that are release blocking for optical
> > >> media right now.
> > >>
> > >>
> > >>
> > >> Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-
> > >> _RELEASE_MILESTONE_.i
> > >> so
> > >> Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-
> > >> _RELEASE_MILESTONE_.i
> > >> so https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking
> > >>
> > >>
> > >>
> > >> I'm suggesting one instead of zero. Whatever image you're saying you
> > >> must have is already non-blocking so I don't even understand what
> > >> you're complaining about now.
> > >
> > >
> > >
> > > This isn't something that *I* personally need. The only ISO image I
> > > personally
> > > need is the KDE Spin ISO, so you'd be correct. For end-users,
> > > there's no need
> > > for the complexity of the Everything image to be present, however.
> > > If the end
> > > user wants to install the GNOME Spin, they shouldn't have to jump
> > > through
> > > hoops and know what they're picking.
> >
> >
> > I would say that the Everything netinstall image is more useful than
> > the Workstation Live image:
> >
> > *  netinstall is smaller
> > *  netinstall can be used to install servers
> > *  netinstall with updates repo enabled yields current system without
> > doing the almost inevitable post-install (from non-netinstall image)
> > update
>
> That'd be great experience for users that already know what they want. and
> have a NIC which is supported in mainline. It's also not an option for users
> installing in airgapped environments, users who don't have internet access or
> have bad internet service, among other common issues. It would NOT be a good
> experience for a user to grab a GNOME or KDE Spin DVD, attempt to boot, and
> not be able to boot it.
>
> --
> John M. Harris, Jr.
> Splentity

Part of my approach for airgapped environments, and environments I
want to do installs and updates from my local network for,  has been
to bring external an external medium, such as a USB drive, with a full
mirror of all of that fedora release's current upstream mirror. and
mount *that*. It's currently about 150 GB for the entire Fedora 31
release. The approach has also been very handy when setting up
clusters or when the installer lacks network drivers until after the
kernel update, and I don't want to spend cycles building a new
bootable image.

I'll also admit that since 2000, I've building tarballs of OS images
much as "mock" builds cached OS images and using them on a network
kickstart or installer CD image to ignore most of anaconda, partition
the disk image with anaconda's '%pre" scripting, and blow the OS image
onto the disk. It's *much, much, much faster* than negotiating the
graphical anaconda screens and selections and it provides *much* more
flexibility for disk partitioning than sitting down working through
the  anaconda disk paritioning or software selection GUI provides.
The approach uses anaconda's scripting tools to provide very scalable
deployments, I once used it for 13,000 deployed systems in one month,
including negotiating which of the network ports were eth0 and which
eth1for consistent "eth1 is on top" for the poor beggars wiring up
the machines.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: No pthread on s390x?

[Dan Horák]

On Sat, 14 Dec 2019 07:27:46 -0600
Richard Shaw  wrote:

> This error only happens on s390x...
> 
> -- Looking for pthread.h
> -- Looking for pthread.h - found
> -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
> -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
> -- Looking for pthread_create in pthreads
> -- Looking for pthread_create in pthreads - not found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - not found
> -- Check if compiler accepts -pthread
> -- Check if compiler accepts -pthread - no
> CMake Error at
> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:146
> (message): Could NOT find Threads (missing: Threads_FOUND)
> Call Stack (most recent call first):
>   /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:393
> (_FPHSA_FAILURE_MESSAGE)
>   /usr/share/cmake/Modules/FindThreads.cmake:220
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>   /usr/lib64/cmake/Qt5UiTools/Qt5UiToolsConfig.cmake:73 (find_package)
>   /usr/lib64/cmake/Qt5UiTools/Qt5UiToolsConfig.cmake:233
> (_qt5_UiTools_process_prl_file)
>   sources/cmake_helpers/helpers.cmake:21 (find_package)
>   sources/pyside2/CMakeLists.txt:159 (collect_optional_modules)
> -- Configuring incomplete, errors occurred!
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=39567395
> 
> On other platforms the last check succeeds. I've never run into this
> before.
> 
> Ideas?

it will need the full cmake check log to see the reason, pthread is
available for s390x too ...


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

No pthread on s390x?

[Richard Shaw]

This error only happens on s390x...

-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - no
CMake Error at
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
  Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:393
(_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake/Modules/FindThreads.cmake:220
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  /usr/lib64/cmake/Qt5UiTools/Qt5UiToolsConfig.cmake:73 (find_package)
  /usr/lib64/cmake/Qt5UiTools/Qt5UiToolsConfig.cmake:233
(_qt5_UiTools_process_prl_file)
  sources/cmake_helpers/helpers.cmake:21 (find_package)
  sources/pyside2/CMakeLists.txt:159 (collect_optional_modules)
-- Configuring incomplete, errors occurred!

https://koji.fedoraproject.org/koji/taskinfo?taskID=39567395

On other platforms the last check succeeds. I've never run into this before.

Ideas?

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

Re: eit.c:394:13: error: 'stime' was not declared in this scope; did you mean 'ctime'?

[Martin Gansser]

solved now with this patch:

diff --git a/eit.c b/eit.c
index 50d8229..82294dc 100644
--- a/eit.c
+++ b/eit.c
@@ -391,7 +391,9 @@ cTDT::cTDT(const u_char *Data)
   if (abs(diff) > MAX_TIME_DIFF) {
  mutex.Lock();
  if (abs(diff) > MAX_ADJ_DIFF) {
-if (stime(&dvbtim) == 0)
+timespec ts = {0};
+ts.tv_sec = dvbtim;
+if (clock_settime(CLOCK_REALTIME, &ts) == 0)
isyslog("system time changed from %s (%ld) to %s (%ld)", 
*TimeToString(loctim), loctim, *TimeToString(dvbtim), dvbtim);
 else
esyslog("ERROR while setting system time: %m");
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: stime() is no longer declared in time.h for rawhide

[Martin Gansser]

solved now with this patch:

diff --git a/eit.c b/eit.c
index 50d8229..82294dc 100644
--- a/eit.c
+++ b/eit.c
@@ -391,7 +391,9 @@ cTDT::cTDT(const u_char *Data)
   if (abs(diff) > MAX_TIME_DIFF) {
  mutex.Lock();
  if (abs(diff) > MAX_ADJ_DIFF) {
-if (stime(&dvbtim) == 0)
+timespec ts = {0};
+ts.tv_sec = dvbtim;
+if (clock_settime(CLOCK_REALTIME, &ts) == 0)
isyslog("system time changed from %s (%ld) to %s (%ld)", 
*TimeToString(loctim), loctim, *TimeToString(dvbtim), dvbtim);
 else
esyslog("ERROR while setting system time: %m");
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Qt 5.14 update plans?

[Barry Scott]

> On 13 Dec 2019, at 02:04, Richard Shaw  wrote:
> 
> Looks like Qt just released 5.14, I believe this officially supports Python 
> 3.8? So it would probably be a good idea to update Rawhide sooner rather than 
> later.
> 
> Rex, I'm willing to help coordinate/perform builds. 

Christian Tismer has been on the python dev list looking for help to fix a ref 
count leak in PySide with python3.8.

Not sure if that is resolved yet.

Barry



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