Re: LibreOffice packages

[Stephan Bergmann]

On 6/7/23 15:15, Michael Catanzaro wrote:

[1] https://github.com/flathub/flatpak-external-data-checker


Oh, thanks, didn't know about that.  Will try to make use of it for 
LibreOffice, 
 "Add 
metadata for flatpak-external-data-checker".

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SIG proposal: libreoffice-sig

[Stephan Bergmann]

On 6/7/23 08:00, Mattia Verga via devel wrote:

As for admin privileges on the FAS group and ML, I'd like to ask 3-4
people to be set up. @decathorpe, @limb, @sharkcz ? @caolanm and
@sbergmann would you like to continue helping in your great work on LO
packages outside RH assignment?


Yes, you can count me (sbergmann) in on trying to help out as far as my 
spare time permits.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Stephan Bergmann]

On 6/6/23 18:07, Fabio Valentini wrote:

In general, I do like having software available as flatpaks,
especially if it's not available from Fedora repositories.
However, there's also the question of *trust* - do I trust the
software source and / or the people / projects providing them?

Let's take LibreOffice as an example, since it started this whole discussion.
The Fedora package appears to bundle only one "major" dependency,
hsqldb, and it's documented and justified why this is the case in the
spec file.

On the other hand, the libreoffice flatpak bundles ~80 projects:
- OpenJDK 17 (huh? is there no shared JDK flatpak runtime / SDK extension?)
- krb5 (huh?)
- xmlsec
- boost 1.80
- gpgme (huh?)
- mariadb-connector-c
- openldap (huh?)
- poppler
- PostgreSQL 13.10 (huh?)
- and about 70 more (but with less memorable names)

While I *do* trust the LibreOffice project (somewhat) to ship their
own software correctly, do I trust them regarding these ~80 bundled -
and partially security sensitive - libraries, as well? I'm not sure.
Do I trust the Fedora packages for these libraries? Probably. Many of
these libraries are installed by default on Fedora, and are not only
used by LibreOffice, so I basically placed implicit trust in these
when I first installed Fedora on my machine.


If you are talking about the LibreOffice upstream flatpak on Flathub 
(i.e., 
):


* It bundles OpenJDK 17 provided by the 
org.freedesktop.Sdk.Extension.openjdk17 sdk-extension.  Whenever a new 
version of the LibreOffice flatpak is provided, it automatically 
includes whatever latest version of that openjdk17 extension is 
provided.  (And the assumption is that the providers of that extension 
take timely action in case of any relevant (security) issues.)  Still, 
if there are urgent (security) issues in the extension, we would need to 
notice that and rebuild the LibreOffice flatpak accordingly.  (It would 
be nicer if Java was provided as an org.freedesktop.Platform extension 
rather than only as an org.freedesktop.Sdk extension.)


* It bundles gvfs (see 
 
"Re-enable GIO support") and krb5 (see 
 
"Add krb5" and 
 
"Introduce optional krb5 support for internal PostgreSQL") "on 
its own":  If there are any (security) issues with their upstream 
sources, we need to notice that and adapt the LibreOffice flatpak 
accordingly.


* It bundles another 83 packages (from pdfium-5408.tar.bz2 to 
f543e6e2d7275557a839a164941c0a86e5f2c3f2a0042bfc434c88c6dde9e140-opens___.ttf) 
that are "managed" by upstream LibreOffice:  These are also used for 
other upstream LibreOffice builds (e.g., on macOS and Windows), and if 
there are any relevant (security) issues, upstream LibreOffice takes 
care of that and provides a new upstream LibreOffice version (and thus a 
new LibreOffice flatpak version).


* It includes ant as a build-time--only dependency.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: more distinct default bash prompt?

[Stephan Bergmann]

On 5/22/23 16:42, Richard W.M. Jones wrote:

FWIW Haiku uses bash and has a prompt which changes colour (green/red)
depending on whether the status code of the last command was good or
bad.  I found this surprisingly useful.  They use:

\[`if [ $? = 0 ]; then echo "\e[32m"; else echo "\e[31m"; fi`\]\w[\e[0m\]>


(or, as another example, just a fat red $? if it's != 0,


PS1='\[\e[0;1;31m\]${?#0}\[\e[30m\]\w \[\e[0m\]'


which I've gotten really dependent on over the years)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libpq-devel and postgresql-private-devel providing conflicting libpq.so symlink

[Stephan Bergmann]

filed  
"postgresql-private-devel conflicts with libpq-devel over 
pkgconfig(libpq), blocks rebuild of LibreOffice flatpak"

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libpq-devel and postgresql-private-devel providing conflicting libpq.so symlink

[Stephan Bergmann]

On 24/08/2022 08:21, Stephan Bergmann wrote:
Seen at least on F36 x86_64:  The package 
libreoffice-postgresql-7.3.4.2-4.fc36.x86_64 (built 2022-07-12) contains 
a library /usr/lib64/libreoffice/program/libpostgresql-sdbc-impllo.so 
that links against libpq (built with -lpq), so the library has



 0x0001 (NEEDED) Shared library: [libpq.so.5]


and the package requires


libpq.so.5()(64bit)
libpq.so.5(RHPG_9.6)(64bit)


satisfied by libpq-14.1-2.fc36.x86_64.

But when I scratch-rebuilt that exact same 
libreoffice-postgresql-7.3.4.2-4.fc36.x86_64 yesterday 
(<https://koji.fedoraproject.org/koji/taskinfo?taskID=91173820>), the 
build apparently picked up postgresql-private-devel-14.3-2.fc36.x86_64 
rather than the expected libpq-devel-14.1-2.fc36.x86_64, so was built 
against



/usr/lib64/libpq.so -> libpq.so.private14-5.14


rather than the expected


/usr/lib64/libpq.so -> libpq.so.5.14


so the resulting 
/usr/lib64/libreoffice/program/libpostgresql-sdbc-impllo.so unexpectedly 
has


 0x0001 (NEEDED) Shared library: 
[libpq.so.private14-5]


and the package unexpectedly requires


libpq.so.private14-5()(64bit)


satisfied by postgresql-private-libs-14.3-2.fc36.x86_64.  (Which is a 
problem when trying to do a fresh libreoffice-flatpak build, which 
bundles libpq but not postgresql-private-libs.)


I'm not sure what changed between the two 
libreoffice-postgresql-7.3.4.2-4.fc36.x86_64 builds (2022-07-12 and 
2022-08-23), and whether libpq-devel and postgresql-private-devel 
already conflict over /usr/lib64/libpq.so since ~forever (and that's 
expected and wanted?).  Maybe somebody has an idea?


The corresponding libreoffice.spec has


BuildRequires: pkgconfig(libpq)


and the libpq-devel and postgresql-private-devel packages apparently 
also conflict over /usr/lib64/pkgconfig/libpq.pc.  I don't know how such 
a BuildRequires is resolved exactly, but could it be that it 
deliberately chooses postgresql-private-devel now over libpq-devel 
because the latest


$ rpm -q --provides -p postgresql-private-devel-14.3-2.fc36.x86_64.rpm 
pkgconfig(libpq) = 14.3

postgresql-private-devel = 14.3-2.fc36
postgresql-private-devel(x86-64) = 14.3-2.fc36


now advertises a higher "pkgconfig(libpq) = 14.3" than the latest

$ rpm -q --provides -p libpq-devel-14.1-2.fc36.x86_64.rpm 
libpq-devel = 14.1-2.fc36

libpq-devel(x86-64) = 14.1-2.fc36
pkgconfig(libpq) = 14.1
postgresql-devel = 14.1-2.fc36


still only advertising "pkgconfig(libpq) = 14.1"?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

libpq-devel and postgresql-private-devel providing conflicting libpq.so symlink

[Stephan Bergmann]

Seen at least on F36 x86_64:  The package 
libreoffice-postgresql-7.3.4.2-4.fc36.x86_64 (built 2022-07-12) contains 
a library /usr/lib64/libreoffice/program/libpostgresql-sdbc-impllo.so 
that links against libpq (built with -lpq), so the library has



 0x0001 (NEEDED) Shared library: [libpq.so.5]


and the package requires


libpq.so.5()(64bit)
libpq.so.5(RHPG_9.6)(64bit)


satisfied by libpq-14.1-2.fc36.x86_64.

But when I scratch-rebuilt that exact same 
libreoffice-postgresql-7.3.4.2-4.fc36.x86_64 yesterday 
(), the 
build apparently picked up postgresql-private-devel-14.3-2.fc36.x86_64 
rather than the expected libpq-devel-14.1-2.fc36.x86_64, so was built 
against



/usr/lib64/libpq.so -> libpq.so.private14-5.14


rather than the expected


/usr/lib64/libpq.so -> libpq.so.5.14


so the resulting 
/usr/lib64/libreoffice/program/libpostgresql-sdbc-impllo.so unexpectedly has



 0x0001 (NEEDED) Shared library: [libpq.so.private14-5]


and the package unexpectedly requires


libpq.so.private14-5()(64bit)


satisfied by postgresql-private-libs-14.3-2.fc36.x86_64.  (Which is a 
problem when trying to do a fresh libreoffice-flatpak build, which 
bundles libpq but not postgresql-private-libs.)


I'm not sure what changed between the two 
libreoffice-postgresql-7.3.4.2-4.fc36.x86_64 builds (2022-07-12 and 
2022-08-23), and whether libpq-devel and postgresql-private-devel 
already conflict over /usr/lib64/libpq.so since ~forever (and that's 
expected and wanted?).  Maybe somebody has an idea?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Incomprehensible rpmlint error messages

[Stephan Bergmann]

On 08/12/2021 09:33, Dan Horák wrote:

On Wed, 8 Dec 2021 08:32:10 +0100

zxing-cpp.x86_64: E: shlib-policy-name-error 1
zxing-cpp.x86_64: E: invalid-ldconfig-symlink /usr/lib64/libZXing.so.1.2.0 
libZXing.so.1.2.0
=== 1 packages and 0 specfiles checked; 2 errors, 0 warnings, 2 
badness; has taken 2.5 s ===


[dan@t460 ~]$ rpmlint -I shlib-policy-name-error
shlib-policy-name-error:

so yes, this needs further explanation :-)


Ah, rpmlint-2.1.0-5.fc35.noarch apparently has some -e option instead of 
an -I option now (it doesn't appear to have a man page, though):



$ rpmlint -e shlib-policy-name-error
shlib-policy-name-error:
The package contains shared library but is not named after its SONAME.


So the proposed package would presumably better be named libZXing rather 
than zxing-cpp.



[dan@t460 ~]$ rpmlint -I invalid-ldconfig-symlink
invalid-ldconfig-symlink:
The symbolic link references the wrong file. It should reference the
shared library.


...which still leaves it unclear which symbolic link is allegedly wrong, 
because the libraries and symlinks contained in the rpm look just fine:



$ ls -l usr/lib64/
total 1204
lrwxrwxrwx. 1 sbergman sbergman  17 Dec  7 16:26 libZXing.so.1 -> 
libZXing.so.1.2.0
-rwxr-xr-x. 1 sbergman sbergman 1229720 Dec  7 16:26 libZXing.so.1.2.0



This is from rpmlint 1.11 (F-34), perhaps there is a newer version.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Incomprehensible rpmlint error messages

[Stephan Bergmann]

Trying to review  
"Review Request: zxing-cpp - C++ version of ZXing ("Zebra Crossing") 
barcode scanning library" on Fedora 35, `fedora-review -b 2029219` 
produces a 2029219-zxing-cpp/review.txt that states



Rpmlint
---
Cannot parse rpmlint output:


(with no further information), and a manual `rpmlint 
2029219-zxing-cpp/results/zxing-cpp-1.2.0-1.fc36.x86_64.rpm` fails with



== rpmlint session starts 
==
rpmlint: 2.1.0
configuration:
/usr/lib/python3.10/site-packages/rpmlint/configdefaults.toml
/etc/xdg/rpmlint/fedora.toml
/etc/xdg/rpmlint/licenses.toml
/etc/xdg/rpmlint/scoring.toml
/etc/xdg/rpmlint/users-groups.toml
/etc/xdg/rpmlint/warn-on-functions.toml
checks: 31, packages: 1

zxing-cpp.x86_64: E: shlib-policy-name-error 1
zxing-cpp.x86_64: E: invalid-ldconfig-symlink /usr/lib64/libZXing.so.1.2.0 
libZXing.so.1.2.0
=== 1 packages and 0 specfiles checked; 2 errors, 0 warnings, 2 
badness; has taken 2.5 s ===


and I don't understand what either the shlib-policy-name-error nor the 
invalid-ldconfig-symlink errors are actually about, and can't find any 
documentation.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: hamcrest update to 2.2 in Fedora rawhide

[Stephan Bergmann]

On 01/06/2021 05:42, Mikolaj Izdebski wrote:

On Mon, May 31, 2021 at 1:12 PM Miro Hrončok  wrote:

[...]

Seems like the configure script (or whatever that is) fails to find hamcrest.


That's because libreoffice hardcodes path to hamcrest JAR in the
configure script, instead of using one of the tools designed to locate
JAR files in the system. That is covered in Java Packaging Guidelines
[1].


"packager SHOULD use one of tools designed to locating JAR files in the 
system": whatever those tools are; that packaging guidelines page 
doesn't seem to tell



The bugzilla is https://bugzilla.redhat.com/show_bug.cgi?id=1965975


I could add a compat symlink to the hamcrest package, but it seems
that the issue was fixed on the libreoffice side.


yes, thanks, no need to adapt the hamcrest side

[...]

[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_hardcoded_paths

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage

[Stephan Bergmann]

On 09/02/2021 12:24, Kevin Kofler via devel wrote:

Kalev Lember wrote:

The glib upstream MR got rejected, which means all consumers are going
to have to fix their use of glib headers to not include them in an
extern "C" block.


That is extremely unhelpful. What is the point of rejecting a 2-line (!)
patch that keeps backwards compatibility and avoids having to fix dozens of
other packages, which potentially have this #include in dozens of places
each?


Note that wrapping the header include in an extern declaration violates 
C++ standard requirements.  ("A translation unit shall include a header 
only outside of any declaration or definition", [using.headers]/3)

___
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: Fwd: Re: CppunitTest_sw_htmlexport failing due to zlib variation?

[Stephan Bergmann]

On 31/08/2020 23:05, Adenilson Cavalcanti wrote:

Joining the discussion, since I worked on the original optimization patches and 
I'm one of the maintainers of Chromium's zlib.

Just seconding what Jeremy mentioned, it is possible to generate a valid 
DEFLATE stream wrapped with GZIP format that may be different depending on the 
encoder used (e.g. zlib vs libdeflate vs zopfli).

Specifically on the aarch64 specific patches, most probably the patch 
0002-Porting-optimized-longest_match.patch would be responsible for the 
difference observed when compared to a vanilla canonical zlib (i.e. Mark 
Adler's zlib https://github.com/madler/zlib).

That optimization uses a slightly different strategy for finding the matching 
strings while performing LZ77 compression.

Just to be on the safe side, I decided to write a small test case comparing the 
pixels of the failing libreoffice test to verify if indeed, the decompressed 
data was a perfect match.

The test case can be found here (https://codepen.io/Savago/pen/BaKddem). It 
displays side-by-side the expected image and the generated image and by 
clicking in the button, it will print the number of mismatched pixels and also 
a version of the image with the mismatched highlighted pixels.

To prove that the test case is sound, there is another version here 
(https://codepen.io/Savago/full/qBZXXOv) where I explicitly added some changes 
in the generated image (i.e. added one eye, smile and a '4' symbol in the chest 
of the icon using GIMP).

I also observed that the generated PNG is actually a few bytes smaller (2066 
bytes vs 2102 bytes), which shows slightly better compression.

I hope that this should be enough to prove that there are no bugs in the 
optimization patches used by Fedora.


Wow, thanks a lot for going above and beyond to proof my naive 
assumption was indeed right.  :)



Unfortunately, there is the common assumption that you could compare binary 
compressed gzipped data but that fails if a newer version of a compression 
library implement changes that may improve compression ratio.

I looked into the posted fix to libreoffice 
(https://gerrit.libreoffice.org/c/core/+/101329/3/sw/qa/extras/htmlexport/htmlexport.cxx),
 that is not ideal since it will just inspect if some PNG was inserted in the 
document, without actually testing if the pixels match.


Yeah, but the reported purpose of that unit test is to verify that an 
image is embedded, not to verify the correctness of the PNG-generating 
code.  Lets hope that there's other tests in the suite that cover the 
latter.


[...]
___
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

Fwd: Re: CppunitTest_sw_htmlexport failing due to zlib variation?

[Stephan Bergmann]

All,

The below question came up in the context of a LibreOffice unit test, 
where LibreOffice writes out a PNG image (involving zlib for 
compression) and the test checked the exact sequence of bytes, which 
failed on aarch64 when using Fedora's zlib.  (Though the resulting 
images look rather identical.  Full thread starting at 
<https://lists.freedesktop.org/archives/libreoffice/2020-August/085792.html> 
"CppunitTest_sw_htmlexport failing due to zlib variation?")


Given the Fedora zlib aarch64 optimization patches quoted below:  Does 
anybody know whether it is indeed the case that the above scenario 
(client code using zlib to generate a PNG image) can legitimately 
generate varying output depending on zlib implementation details?  Or 
would that rather indicate a bug somewhere?


Thanks,
Stephan


 Forwarded Message 
Subject: Re: CppunitTest_sw_htmlexport failing due to zlib variation?
Date: Wed, 26 Aug 2020 08:37:15 +0200
From: Stephan Bergmann 
To: libreoff...@lists.freedesktop.org

On 25/08/2020 11:07, Stephan Bergmann wrote:
At least when building recent master on recent Fedora rawhide aarch64 
with (among others) --with-system-zlib, CppunitTest_sw_htmlexport fails 
with

[...]
The base64-encoded payload apparently is a PNG image.  And from what 
little I know about PNG, it looks plausible to me that there can be 
different (compressed) PNG content that decompress to identical raw 
data, and that the LibreOffice code would be allowed to generate 
differing (compressed) PNG content for the above data:image/png URL 
payload.


What supports the theory that "the LibreOffice code would be allowed to 
generate differing (compressed) PNG content" is the Fedora zlib commit 
<https://src.fedoraproject.org/rpms/zlib/c/25e9802713484882c27c1f979a6610a42414ee13> 
"aarch64 optimizations", adding lots of code that presumably is only 
relevant for aarch64 and presumably changes details of the compression 
algorithm.

___
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: Very strange compiler/linker related build failures in rawhide

[Stephan Bergmann]

On 24/07/2020 10:31, Fabio Valentini wrote:

Other errors look like this one from switchboard-plug-onlineaccounts:

src/libonline-accounts.so.p/Authentification/Server.c: In function
‘online_accounts_server_on_bus_acquired’:
src/libonline-accounts.so.p/Authentification/Server.c:498:2: error:
function ‘__errno_location’ is initialized like a variable
   498 |  gint errno = 0;
   |  ^~~~

Where errno is neither __errno_location, nor a function, but a gint??


Note that, depending on what you include, errno may be a macro.


Does somebody have a clue what's going on here? It's currently
blocking rawhide composes because libreoffice fails to build /
install.


(The LibreOffice build failure is tracked at 
 "LibreOffice FTBFS 
with internal compiler error".)

___
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 System-Wide Change proposal: CompilerPolicy Change

[Stephan Bergmann]

On 05/06/2020 15:16, Ian McInerney wrote:
On Fri, Jun 5, 2020 at 1:51 PM Stephan Bergmann <mailto:sberg...@redhat.com>> wrote:


On 05/06/2020 10:15, Frantisek Zatloukal wrote:
 > [...] Apart from
 > browsers, LibreOffice is going to use LLVM/Clang from Release 7.0
too,
 > so that would potentially be another added work to LibreOffice
packagers
 > in the future.

Just to clarify, upstream LibreOffice supports both GCC and Clang on
Linux equally well since ~forever, and there is no change coming for LO
7.0 that I'm aware of.  Upstream Linux binaries are built with GCC,
FWIW.


I think what they are referring to is that there was a patch [1] a few 
months ago making Clang /preferred/ for building the LibreOffice 
rendering code in response to a slow-performance bug [2].


[1] 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=647499ef8151d9383983f89230a970edcb44b5bb

[2] https://bugs.documentfoundation.org/show_bug.cgi?id=131697


Yes, exclusively for LO's copy of the skia library (and which isn't of 
much use for LO on Fedora anyway, at least for now).

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

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

[Stephan Bergmann]

On 05/06/2020 10:15, Frantisek Zatloukal wrote:
[...] Apart from 
browsers, LibreOffice is going to use LLVM/Clang from Release 7.0 too, 
so that would potentially be another added work to LibreOffice packagers 
in the future.


Just to clarify, upstream LibreOffice supports both GCC and Clang on 
Linux equally well since ~forever, and there is no change coming for LO 
7.0 that I'm aware of.  Upstream Linux binaries are built with GCC, FWIW.

___
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: Aarch64 build failure: hidden symbol `__aarch64_ldadd4_acq_rel' in /usr/lib/gcc/aarch64-redhat-linux/10/libgcc.a(ldadd_4_4.o) is referenced by DSO

[Stephan Bergmann]

On 02/05/2020 19:19, Kevin Fenzi wrote:

On Sat, May 02, 2020 at 11:51:57AM -0500, Rex Dieter wrote:

Jakub Jelinek wrote:


On Sat, May 02, 2020 at 12:36:29PM +0200, Sandro Mani wrote:

Hi

I'm stuck on the following build failure of the aarch64 build here [1]

/usr/bin/ld: .libs/geod: hidden symbol `__aarch64_ldadd4_acq_rel' in
/usr/lib/gcc/aarch64-redhat-linux/10/libgcc.a(ldadd_4_4.o) is referenced
by DSO
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

Never seen anything like this, any ideas?


#1830472


wouldn't it have been better to untag the broken build asap so folks can
continue working?  (Sorry if there was discussion about that possibility,
but I didn't see anything)

As-is, everyone is blocking on waiting for the new gcc build to complete
(that koji estimates is another ~6 hours away).

Personally, this morning was my primary chance to get a significant amount
of work done for the coming week... lost.  :(


I just untagged it. It should be out in the next newrepo.

Sorry for not doing it sooner.


So when is doing koji f32 aarch64 builds expected to work again? 
(Asking because a flatpak build of mine was still failing because of 
this issue a couple of hours ago, and I'm not sure this is generally not 
expected to work again, or the flatpak/mbs/koji machinery is just 
special and needs some additional fixing.)

___
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: Strange covert module builds [sbergmann ?]

[Stephan Bergmann]

On 02/03/2020 13:30, Michal Schorm wrote:

Can you please brief me really quick on how does the flatpack work
from maintainer POV? (what does it need for build / creation; what
does it need for runtime )

If the flatpack uses the packages from base Fedora;
'rpms/mariadb-connector-c', which I'm the maintainer of probably sent
me the email to notify me, that someone somewhere built the package -
which would be expected.


What should happen is that rpms/mariadb-connector-c, branch f31, is 
built in a way suitable for inclusion in the resulting LibreOffice 
flatpak.  (At runtime, that LibreOffice flatpak will run against a 
Fedora 31 flatpak runtime, but which does not include 
mariadb-connector-c used by LibreOffice, so the LibreOffice flatpak 
needs to bundle that.)



Anyway, that doesn't clarify to me why the builds looks so much like
module builds.


Presumably because the fedpkg machinery to build such flatpaks leverages 
the module-build infrastructure.

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

Re: Strange covert module builds [sbergmann ?]

[Stephan Bergmann]

On 02/03/2020 12:48, Michal Schorm wrote:

I'm the maintainer of 'mariadb' & 'mariadb-connector-c' packages
(rpms) and also 'modules/mariadb'.
Recently, I discovered a 'modules/mariadb-connector-c' exists. Created
by my colleague years ago, discontinued in 2017.
This is correct - as we don't want it to build (anymore, most likely
ever). There is 'mariadb-connector-c' in base Fedora (rpms namespace)
and it should do all the job anyone would need.

But I got this e-mail, saying it was recently built again: [1] [2] [3] [4]

And it is very strange:
1) I don't know why I received the email (even though I'm glad I did).
I'm not a maintainer of the 'modules/mariadb-connector-c', nor
watching it (AFAIK).
2) I don't understand how the most recent release of the
'mariadb-connector-c' was built, since in the
'modules/mariadb-connector-c' repo, there's only versions from 2017
and last commits 2-3 years ago; but new release (rebuild from the same
branch but newer (rpms/...) commit *REQUIRES* new (modules/...) commit
).
3) In all history of MBS [5] there are only 2 builds of
'modules/mariadb-connector-c', #1462 & #1463.
No recent build, no nothing.
3) It is tagged for the LibreOffice.
I'd like to know *why* anyone would like to build
'mariadb-connector-c' themselves instead of using the one available.
4) I tried to search for the "libreoffice" module, but haven't found any ! [6]


At this point, I have no idea what's going on.
The only hint is a LibreOffice *flatpack* [7]
which mentions 'mariadb-connector-c' [8]
I haven't met flatpack before, so I don't know how it works (and
what's it good for), but still:
   A) I don't see the need to build the package again
   B) I don't understand why it would disguise so much as a Fedora
Module. That would be really confusing and misleading, if that would
be the case.


The nick in Subject is the author of the KOJI build and a maintainer
of the 'flatpaks/libreoffice'.
Hope he may confirm / disprove that he's responsible for the build and
some rel-eng or infrastructure member would explain why it behave so
weird ...


I assume whatever notification emails you get are a consequence of me 
doing a Flatpak-from-Fedora-RPMs build of LibreOffice (see 
, 
).


But I have no idea how/why building that LibreOffice flatpak would 
involve builds of a discontinued modules/mariadb-connector-c, or why you 
are getting confusing email.  Maybe Owen (in cc) can shed some light on 
that?



[1] mbs/mbs.fedoraproject.org's
mariadb-connector-c-3.1.7-1.module_f31+8201+43134e23 completed
[2] http://koji.fedoraproject.org/koji/buildinfo?buildID=1470803
[3] mbs/mbs.fedoraproject.org's
mariadb-connector-c-3.1.7-1.module_f31+8207+96410d98 completed
[4] http://koji.fedoraproject.org/koji/buildinfo?buildID=1471050
[5] https://release-engineering.github.io/mbs-ui/modules
[6] https://src.fedoraproject.org/projects/modules/%2A
[7] https://src.fedoraproject.org/flatpaks/libreoffice
[8] 
https://src.fedoraproject.org/flatpaks/libreoffice/blob/master/f/libreoffice.yaml#_173

___
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: Who maintains the service at mbs.fedoraproject.org:443?

[Stephan Bergmann]

On 17/02/2020 13:54, Pierre-Yves Chibon wrote:

On Mon, Feb 17, 2020 at 12:46:17PM +0100, Mikolaj Izdebski wrote:

mbs.fedoraproject.org is maintained by Infrastructure Team [1]. You
can report issues at [2].


I don't think that we do, but we may know who does and help you redirect your
question to them.


thanks; filed  
"`fedpkg module-build` fails with "The modulemd libreoffice.yaml is 
invalid. Please verify the syntax is correct." upon buildopts: arches: 
[x86_64]" now

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

Who maintains the service at mbs.fedoraproject.org:443?

[Stephan Bergmann]

I am trying to do a build of LibreOffice from Fedora RPMs (à la 
), but `fedpkg 
module-build` keeps failing with



The modulemd libreoffice.yaml is invalid. Please verify the syntax is correct.


after 
 
"Restrict builds to x86_64".


Judging from strace and what little information the --verbose option of 
fedpkg provides, it looks like that error message is reported back from 
mbs.fedoraproject.org:443.  Could it be that that installation is 
missing 
 
"Add support for new ModulemdBuildopts arches attribute"?

___
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

[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: glib-2.0 G_CONST_RETURN causing GCC "warning: const' on F31

[Stephan Bergmann]

On 25/09/2019 18:12, Stephan Bergmann wrote:
(At least partly; /usr/include/glib-2.0/glib/gmacros.h has only 540 
lines, there's no line 913; so whatever #line tricks get played there...)


Ha, that part was easy:  I looked at the file with Emacs, but had no 
Emacs installed on the F31 system, just a Flatpak version (which then of 
course shows /usr/include/... in the Flatpak runtime, but otherwise 
behaved inconspicuous enough to fool me into believing I was running the 
"real thing").  :)


But still, the GCC warning messages should be better...
___
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: glib-2.0 G_CONST_RETURN causing GCC "warning: const' on F31

[Stephan Bergmann]

On 25/09/2019 17:16, Stephan Bergmann wrote:

~ gcc $(pkg-config -cflags glib-2.0) -c test.c
test.c:2:13: warning: const
    2 | G_CONST_RETURN char * f();
  | ^~~


emits a cryptic warning (and gets the positioning of the squiggly 
underline wrong).


On both F30 and F31, /usr/include/glib-2.0/glib/gmacros.h contains


/* Deprecated -- do not use. */
#ifndef G_DISABLE_DEPRECATED
#ifdef G_DISABLE_CONST_RETURNS
#define G_CONST_RETURN
#else
#define G_CONST_RETURN const
#endif
#endif


so I'm not sure what causes the warning to be emitted on F31 but not on 
F30.


So Clang gives it away:


test.c:2:1: warning: const [-W#pragma-messages]
G_CONST_RETURN char * f();
^
/usr/include/glib-2.0/glib/gmacros.h:913:30: note: expanded from macro 
'G_CONST_RETURN'
#define G_CONST_RETURN const GLIB_DEPRECATED_MACRO_IN_2_30_FOR(const)
 ^
/usr/include/glib-2.0/glib/gversionmacros.h:387:49: note: expanded from macro 
'GLIB_DEPRECATED_MACRO_IN_2_30_FOR'
# define GLIB_DEPRECATED_MACRO_IN_2_30_FOR(f)   GLIB_DEPRECATED_MACRO_FOR(f)
^
/usr/include/glib-2.0/glib/gmacros.h:990:38: note: expanded from macro 
'GLIB_DEPRECATED_MACRO_FOR'
#define GLIB_DEPRECATED_MACRO_FOR(f) _GLIB_GNUC_DO_PRAGMA(GCC warning #f)
 ^
/usr/include/glib-2.0/glib/gmacros.h:988:33: note: expanded from macro 
'_GLIB_GNUC_DO_PRAGMA'
#define _GLIB_GNUC_DO_PRAGMA(x) _Pragma(G_STRINGIFY (x))
^
:110:6: note: expanded from here
 GCC warning "const"
 ^
1 warning generated.


(At least partly; /usr/include/glib-2.0/glib/gmacros.h has only 540 
lines, there's no line 913; so whatever #line tricks get played there...)

___
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

glib-2.0 G_CONST_RETURN causing GCC "warning: const' on F31

[Stephan Bergmann]

After switching to F31 beta I came across a GCC warning that looks like 
it is useful, trying to warn about misguided uses of the G_CONST_RETURN 
macro from glib-2.0.  However, it leaves me puzzled:



$ cat test.c
#include "glib.h"
G_CONST_RETURN char * f();


On F30:


~ gcc --version
gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~ gcc $(pkg-config -cflags glib-2.0) -c test.c


works fine.  On F31 beta,


~ gcc --version
gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~ gcc $(pkg-config -cflags glib-2.0) -c test.c
test.c:2:13: warning: const
2 | G_CONST_RETURN char * f();
  | ^~~


emits a cryptic warning (and gets the positioning of the squiggly 
underline wrong).


On both F30 and F31, /usr/include/glib-2.0/glib/gmacros.h contains


/* Deprecated -- do not use. */
#ifndef G_DISABLE_DEPRECATED
#ifdef G_DISABLE_CONST_RETURNS
#define G_CONST_RETURN
#else
#define G_CONST_RETURN const
#endif
#endif


so I'm not sure what causes the warning to be emitted on F31 but not on F30.

( 
states: "The macro can be used in place of const for functions that 
return a value that should not be modified."  So the intent of the 
warning appears to be to warn about uses of G_CONST_RETURN that don't 
make the return type const, but rather make the return type be e.g. 
pointer-to-const as in my example.)

___
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: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Stephan Bergmann]

On 21/03/2019 09:59, Zbigniew Jędrzejewski-Szmek wrote:

"-fstack-protector-strong" is the only one that has a clearly
beneficial effect.

But then there's the overall counterargument from Jakub that we start
deviating from upstream defaults and some users will need to add counter-options
to go back to the compiler defaults. I feel like the possible benefits
from enabling "-fstack-protector-strong" are not big enough to justify
the change. For serious hardening, one would enable way more flags,
and just turning on one or two is enough for the downsides to kick in, but
not enough to have serious benefits.


...and if any of the suggested changes to default options are deemed to 
be of value to users of Fedora, wouldn't they also be of value to users 
of upstream GCC, and should be implemented there?


(I share the sentiment that deviating defaults in distros are a pain for 
users.  It already bites me often enough when a distro unhelpfully 
sneaks in ccache behind my back, let alone something like adding -O.)

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

F28 `dnf update` "Error: Failed to synchronize cache for repo 'fedora-debuginfo'"

[Stephan Bergmann]

On F28, `dnf update` recently started to fail for me with "Error: Failed 
to synchronize cache for repo 'fedora-debuginfo'":



$ sudo dnf -vv --disablerepo=\* --enablerepo=fedora-debuginfo --refresh 
makecache
Loaded plugins: builddep, config-manager, copr, debug, debuginfo-install, 
download, generate_completion_cache, needs-restarting, playground, repoclosure, 
repograph, repomanage, reposync, system-upgrade, versionlock
DNF version: 2.7.5
cachedir: /var/cache/dnf
Making cache files for all metadata files.
fedora-debuginfo: has expired and will be refreshed.
Cannot download 
'https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-28=x86_64': Cannot 
prepare internal mirrorlist: file "repomd.xml" was not found in metalink.
Error: Failed to synchronize cache for repo 'fedora-debuginfo'


and


curl 
'https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-28=x86_64'

http://www.metalinker.org/; type="dynamic" pubdate="Wed, 16 May 2018 
08:44:47 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager;>




claims it's both available and not available.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Binutils version 2.29.1

[Stephan Bergmann]

On 23.01.2018 09:28, Tom Hughes wrote:

None the less the man page for ld (at least on F27) says:

     defs
     Disallows undefined symbols in object files.  Undefined symbols
     in shared libraries are still allowed.

which says that undefined symbols are allowed when linking a shared 
library even with -zdefs.


I think the man page talks about shared libraries among the inputs to ld 
there, not whether ld is generating a shared library as output.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Hardening Flags Updates for Fedora 28

[Stephan Bergmann]

On 01/05/2018 12:41 PM, Mark Wielaard wrote:

On Thu, Jan 04, 2018 at 09:36:27PM -0800, John Reiser wrote:

2) The explicit write by the stack probe can mask a memcheck(valgrind)
violation, at least until memcheck groks the probe.


That should not be true. The probe is done after the stack pointer is
lowered, so memcheck/valgrind knows that memory is used.


But if, as claimed, the probe is done by writing (a fixed value) instead 
of reading, couldn't that hide later memcheck reports about use of 
uninitialized memory?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: -Wl,--as-needed by default (and glibc ldconfig file trigger)

[Stephan Bergmann]

On 11/21/2017 04:12 PM, David Tardon wrote:

On Tue, Nov 21, 2017 at 01:54:13PM +, Tomasz Kłoczko wrote:

On 21 November 2017 at 10:43, Igor Gnatenko
 wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2017-11-21 at 10:26 +, Tomasz Kłoczko wrote:

So is it any final decision about start use by default --as-needed in
linker options?


Can you link Change Proposal you (or someone else) submitted? I have not heard
anything about that.


https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/3

[..]

In my opinion number of affected packages will be very low (few).


Counting numbers of affected packages by guessing is very bad idea.


Call it educated guess if you want.


You know, there is a way to get more reliable data: do scratch builds of
all Fedora packages and analyze the results. Then we'd know _exactly_
how many packages would need to be patched.


...depending on how thoroughly the analysis is done, as the breakage 
caused by an erroneous --as-needed might, at least in principle, only 
happen at runtime, rather than at build time.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: C++ build errors

[Stephan Bergmann]

On 12/07/2016 11:08 AM, Jakub Jelinek wrote:

On Wed, Dec 07, 2016 at 11:04:37AM +0100, Stephan Bergmann wrote:

On 12/06/2016 04:16 PM, Jakub Jelinek wrote:

On Tue, Dec 06, 2016 at 02:51:14PM -, Jeremy Newton wrote:

Anyone have any idea what causes these errors? Trying to update a package and 
it failed during a local test build in mock (f25):

In file included from /usr/include/c++/6.2.1/stdlib.h:36:0,
from expr.ypp:5:
/usr/include/c++/6.2.1/cstdlib:124:11: error: '::div_t' has not been declared


See https://gcc.gnu.org/gcc-6/porting_to.html
Header  changes
part.  Most likely the package is doing something wrong.


I ran into an error like that the other day when some #include (that
indirectly then #include'd ) was wrapped in a namespace { ... }.


Don't do that, that is invalid in C++.


Of course.  It's just that that caused exactly the same symptoms, so I'm 
assuming the OP ran into the same problem.  (And I guess that some such 
broken code happened to go unnoticed with older versions of GCC/libstdc++.)

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: C++ build errors

[Stephan Bergmann]

On 12/06/2016 04:16 PM, Jakub Jelinek wrote:

On Tue, Dec 06, 2016 at 02:51:14PM -, Jeremy Newton wrote:

Anyone have any idea what causes these errors? Trying to update a package and 
it failed during a local test build in mock (f25):

In file included from /usr/include/c++/6.2.1/stdlib.h:36:0,
 from expr.ypp:5:
/usr/include/c++/6.2.1/cstdlib:124:11: error: '::div_t' has not been declared


See https://gcc.gnu.org/gcc-6/porting_to.html
Header  changes
part.  Most likely the package is doing something wrong.


I ran into an error like that the other day when some #include (that 
indirectly then #include'd ) was wrapped in a namespace { ... }.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ABRT, Faf and current state of bug reporting

[Stephan Bergmann]

On 04/23/2013 03:27 PM, Richard Marko wrote:

This allows us to get accurate statistics of crashing applications while
not forcing every user to report to bugzilla. This is a trade-off
between getting accurate statistics and quality of the reports as
automated reports are anonymous which is also the reason why they can't
contain full backtrace with data.


To clarify, is it so that from now on we'll always get (less detailed) 
[faf] bugzilla issues instead of the old (more detailed) [abrt] 
ones, or does that depend on how the user experiencing a crash interacts 
with ABRT?


Stephan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

GCC produced wrong code in gvfs-1.14.2-3.fc18.x86_64

[Stephan Bergmann]

I happened to run across a problem with current gvfsd-sftp in x86_64 
Fedora 18 that is apparently due to bad code generated by GCC.


The function


void
g_vfs_read_channel_send_seek_offset (GVfsReadChannel *read_channel,
 goffset offset)
{
  GVfsDaemonSocketProtocolReply reply;
  GVfsChannel *channel;

  channel = G_VFS_CHANNEL (read_channel);

  reply.type = g_htonl (G_VFS_DAEMON_SOCKET_PROTOCOL_REPLY_SEEK_POS);
  reply.seq_nr = g_htonl (g_vfs_channel_get_current_seq_nr (channel));
  reply.arg1 = g_htonl (offset  0x);
  reply.arg2 = g_htonl (offset  32);

  g_vfs_channel_send_reply (channel, reply, NULL, 0);
}


in /usr/src/debug/gvfs-1.14.2/daemon/gvfsreadchannel.c shall split the 
signed 64 bit goffset offset into reply.arg1 and reply.arg2.  What 
happens though is that reply.arg2 erroneously contains the same 
(byte-swapped, due to g_htonl) low-order 32 bits as reply.arg1.  The 
generated code is



0x00421c90 +0:  push  %rbp
0x00421c91 +1:  mov   %rsi,%rbp
0x00421c94 +4:  push  %rbx
0x00421c95 +5:  mov   %rdi,%rbx
0x00421c98 +8:  sub   $0x18,%rsp
0x00421c9c +12: callq 0x415cf0 g_vfs_channel_get_type
0x00421ca1 +17: mov   %rbx,%rdi
0x00421ca4 +20: mov   %rax,%rsi
0x00421ca7 +23: callq 0x4093b0 g_type_check_instance_cast@plt
0x00421cac +28: mov   %rax,%rdi
0x00421caf +31: mov   %rax,%rbx
0x00421cb2 +34: movl  $0x200,(%rsp)
0x00421cb9 +41: callq 0x416ab0 g_vfs_channel_get_current_seq_nr
0x00421cbe +46: mov   %ebp,%esi
0x00421cc0 +48: mov   $0x20,%ecx
0x00421cc5 +53: bswap %eax
0x00421cc7 +55: sar   %cl,%esi

^^

0x00421cc9 +57: mov   %eax,0x4(%rsp)
0x00421ccd +61: mov   %ebp,%eax
0x00421ccf +63: bswap %esi
0x00421cd1 +65: bswap %eax
0x00421cd3 +67: mov   %rbx,%rdi
0x00421cd6 +70: mov   %esi,0xc(%rsp)
0x00421cda +74: xor   %ecx,%ecx
0x00421cdc +76: mov   %rsp,%rsi
0x00421cdf +79: xor   %edx,%edx
0x00421ce1 +81: mov   %eax,0x8(%rsp)
0x00421ce5 +85: callq 0x416210 g_vfs_channel_send_reply
0x00421cea +90: add   $0x18,%rsp
0x00421cee +94: pop   %rbx
0x00421cef +95: pop   %rbp
0x00421cf0 +96: retq


where sar %cl,%esi with %ecx=$0x20 is a nop, as the processor masks the 
upper three bits of the [%cl] count operand [AMD64 Architecture 
Programmer’s Manual Volume 3: General Purpose and System Instructions].


Is this a known problem with (Fedora 18's) GCC?

Stephan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GCC produced wrong code in gvfs-1.14.2-3.fc18.x86_64

[Stephan Bergmann]

On 03/15/2013 04:23 PM, Stephan Bergmann wrote:

I happened to run across a problem with current gvfsd-sftp in x86_64
Fedora 18 that is apparently due to bad code generated by GCC.

The function


void
g_vfs_read_channel_send_seek_offset (GVfsReadChannel *read_channel,
 goffset offset)
{
  GVfsDaemonSocketProtocolReply reply;
  GVfsChannel *channel;

  channel = G_VFS_CHANNEL (read_channel);

  reply.type = g_htonl (G_VFS_DAEMON_SOCKET_PROTOCOL_REPLY_SEEK_POS);
  reply.seq_nr = g_htonl (g_vfs_channel_get_current_seq_nr (channel));
  reply.arg1 = g_htonl (offset  0x);
  reply.arg2 = g_htonl (offset  32);

  g_vfs_channel_send_reply (channel, reply, NULL, 0);
}


in /usr/src/debug/gvfs-1.14.2/daemon/gvfsreadchannel.c shall split the
signed 64 bit goffset offset into reply.arg1 and reply.arg2.  What
happens though is that reply.arg2 erroneously contains the same
(byte-swapped, due to g_htonl) low-order 32 bits as reply.arg1.  The
generated code is

[...]

Is this a known problem with (Fedora 18's) GCC?


Grr, sorry for the noise; appears to be rather a bug in 
glib2-devel-2.34.2-2.fc18.x86_64, where /usr/include/glib-2.0/glib/gtypes.h



#define GUINT32_SWAP_LE_BE(val) ((guint32) __builtin_bswap32 ((gint32) val))


misses parentheses around val, so the above


reply.arg2 = g_htonl (offset  32);


ultimately expands to


reply.arg2 = guint32) __builtin_bswap32 ((gint32) offset  32;


(and building gvfs with -Werror would have nicely given it away, 
warning: right shift count = width of type [enabled by default]).


Stephan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GCC produced wrong code in gvfs-1.14.2-3.fc18.x86_64

[Stephan Bergmann]

On 03/15/2013 05:06 PM, Stephan Bergmann wrote:

Grr, sorry for the noise; appears to be rather a bug in
glib2-devel-2.34.2-2.fc18.x86_64


See https://bugzilla.gnome.org/show_bug.cgi?id=695925 
GUINT32/64_SWAP_LE_BE macros do not enclose val argument in parentheses.


Stephan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Problem in rawhide with ld and weak symbols?

[Stephan Bergmann]

Building LibreOffice for x86_64 starting to fail in an odd way recently, 
http://koji.fedoraproject.org/koji/getfile?taskID=5091173name=build.logoffset=-4000, 
I stripped that down to what I would assume is a newly introduced bug in 
how ld resolves weak references?


Given a test.s of


.text
.globl main
.type main, @function
main:
.quad x
.weakref x,__pthread_key_create


gcc test.s builds fine, while gcc test.s -lcom_err, i.e., including 
a reference to some .so that in turn needs libpthread, fails with



/usr/bin/ld: /tmp/cckAPSW1.o: undefined reference to symbol 
'__pthread_key_create@@GLIBC_2.2.5'
/usr/bin/ld: note: '__pthread_key_create@@GLIBC_2.2.5' is defined in DSO 
/lib64/libpthread.so.0 so try adding it to the linker command line
/lib64/libpthread.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status


The same works fine in F-18.  The failing ld is GNU ld version 
2.23.52.0.1-4.fc19 20130226.


Stephan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Problem in rawhide with ld and weak symbols?

[Stephan Bergmann]

On 03/07/2013 08:31 PM, Jon Ciesla wrote:

On Thu, Mar 7, 2013 at 1:28 PM, Stephan Bergmann sberg...@redhat.com
mailto:sberg...@redhat.com wrote:

Building LibreOffice for x86_64 starting to fail in an odd way
recently,

http://koji.fedoraproject.__org/koji/getfile?taskID=__5091173name=build.logoffset=__-4000

http://koji.fedoraproject.org/koji/getfile?taskID=5091173name=build.logoffset=-4000,
I stripped that down to what I would assume is a newly introduced
bug in how ld resolves weak references?

Given a test.s of

 .text
 .globl main
 .type main, @function
main:
 .quad x
 .weakref x,__pthread_key_create


gcc test.s builds fine, while gcc test.s -lcom_err, i.e.,
including a reference to some .so that in turn needs libpthread,
fails with

/usr/bin/ld: /tmp/cckAPSW1.o: undefined reference to symbol
'__pthread_key_create@@GLIBC___2.2.5'
/usr/bin/ld: note: '__pthread_key_create@@GLIBC___2.2.5' is
defined in DSO /lib64/libpthread.so.0 so try adding it to the
linker command line
/lib64/libpthread.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status


The same works fine in F-18.  The failing ld is GNU ld version
2.23.52.0.1-4.fc19 20130226.


I ran into this with kismet, adding an '-lpthread' at the right spot
fixed it.  I think it just got stricter again.


Just see this is a known problem already, 
https://bugzilla.redhat.com/show_bug.cgi?id=918003  New ld broke 
handling of undefined weak symbols (and adding an '-lpthread' at the 
right spot just works around the symptoms).


Stephan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

[Stephan Bergmann]

On 02/06/2013 02:36 AM, Andrea Pescetti wrote:

About the soffice alias, it still breaks parallel installation in F18
(just tried, the desktop integration from OpenOffice conflicts with
libreoffice-core). It seems that the upstream LibreOffice packages no
longer use the soffice alias (at least, the desktop integration only
installs libreoffice3.6),


Yeah, looks like 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=b1cf810a8e7342ad5d518528fd58266daf6e90ec 
LibreOffice branding: make desktop integration work (fix2) dropped the 
/usr/bin/soffice symlink from the upstream LO packages, for reasons that 
escape me---maybe it was just ignorance or an oversight.


 while the upstream OpenOffice packages still

use soffice. Are Stephan's concerns about legacy applications still
valid?


The concerns about applications using the interface I described (not 
sure what you mean with legacy, though) still hold.


Stephan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

[Stephan Bergmann]

On 02/03/2013 09:15 PM, Pavel Alexeev wrote:

01.02.2013 00:17, drago01 wrote:

On Thu, Jan 31, 2013 at 8:10 PM, Adam Williamsonawill...@redhat.com  wrote:

On Thu, 2013-01-31 at 14:20 +0100, Robert Mayr wrote:


I think that's not the point, one of the two suites will be dominant
and you can't provide both of them on a live image for example.
LibreOffice was introduced to our live images and we hit target 1GB,
do you really think it could be useful having a larger image just
because you want to provide both of the office suites?

The proposal explicitly says that it doesn't envisage including OO on
any images or in any default install configurations, simply adding it as
an option in the package repositories.

Which doesn't really need a FESCo approval ... just a package review.

Meantime there one sentence which optionally require changes in
LibreOffice too:  The /usr/bin/soffice alias is still a problem since
(in the Fedora packages) it would conflict between LibreOffice and
Apache OpenOffice: it is recommended to fix it in the LibreOffice
packages too, at least using the Alternatives system.


Some background:

For the benefit of applications that programmatically spawn an OOo 
process to get their work done, OOo and, by inheritance, LO have 
traditionally offered an executable named program/soffice as part of 
their stable interface (together with a helper executable named 
program/unoinfo).  Not breaking such applications has been one reason 
why it has never been considered worthwhile to drop neither the 
program nor the soffice conventions just for aesthetics.


Also, given OOo/LO's tradition of being installable to arbitrary 
locations (which in turn is a direct consequence of its multi-plaform 
nature), there's code available in OOo/LO's SDK that can be bundled with 
such applications mentioned above to help them to find a OOo/LO 
installation, with fallbacks to platform-specific heuristics.  For Unix, 
that includes searching PATH for a file or symlink named soffice.  Not 
breaking that has been one reason why it has never been considered 
worthwhile to drop the /usr/bin/soffice symlink just for aesthetics.


Stephan

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: using rpms for non-root installs

[Stephan Bergmann]

On 01/31/2013 08:40 AM, Michael Stahnke wrote:

You actually may have an option. It's dirty, and here be dragons. I
know this from working on RPM on AIX, so again, it's hacky. I did this
on a CentOS 6.3 box for my example, should work on Fedora.

You can do something like:

   ls zip-3.0-1.el6.x86_64.rpm
   mkdir $HOME/.myrpm
   cp -pr /var/lib/rpm/* $HOME/.myrpm/
   chown -R $USER  $HOME/.myrpm/
   rpm -Uvh --justdb --dbpath $HOME/.myrpm zip-3.0-1.el6.x86_64.rpm
   rpm2cpio  zip-3.0-1.el6.x86_64.rpm | cpio  -idmv
   rpm -q --dbpath $HOME/.myrpm zip

Results:

[vagrant@localhost ~]$ rpm -q --dbpath /home/vagrant/.myrpm zip
zip-3.0-1.el6.x86_64
[vagrant@localhost ~]$ rpm -q zip
package zip is not installed


You now have zip installed (and rooted) in $HOME.  You'd have to add
the --dbpath option to rpm any time you used it, and it would get out
of sync with the system rpm database unless you wrote some tooling
around that. But it's completely do-able.

Again, it's ugly and I don't recommend it.


FWIW, we have a similar script for LibreOffice, 
http://cgit.freedesktop.org/libreoffice/core/tree/setup_native/scripts/install_linux.sh 
(inherited from its OpenOffice.org ancestry), and at least back in OOo 
times used it frequently to install instances to the side.  Worked 
reasonably well.


Stephan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

grub2-tools and UEFI/GPT

[Stephan Bergmann]

When my UEFI/GPT-based Fedora 17 box refused to boot yesterday, I ran 
into the following trouble.  The disk looked reasonably well from a 
rescue system, so I naively figured that something might be wrong with 
its initial sectors, and that grub2-install might magically fix that again.


First, grub2-install (which wasn't installed on my box, so I installed 
grub2-tools) kept asking about --target or --directory switches that 
didn't make much sense to me, until I figured that it found no data in 
/usr/lib/grub, and that installing the grub2 package would solve that, 
putting /usr/lib/grub/i386-pc there.  Is that a missing dependency of 
grub2-tools on grub2, or is that by design?


Then, grub2-install /dev/sda still failed to work with this GPT 
partition label contains no BIOS Boot Partition; embedding won't be 
possible.  In the end, I managed to get things working again with 
re-installing Fedora 17 onto itself via CD, which has apparently 
corrected any corrupted data in some way.  What would the manual way to 
do that have looked like?


Stephan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub2-tools and UEFI/GPT

[Stephan Bergmann]

On 12/12/2012 10:39 AM, Chris Murphy wrote:

UEFI is not BIOS. The command you were looking for is grub2-efi-install, 
whereas grub2-install is for BIOS systems. The package you should already have 
is grub2-efi. And on UEFI systems there are no boot sectors, there is a 
partition dedicated for boot managers/loaders as EFI applications called the 
EFI System partition which must be specified when using the install command.


Ah, turns out my machine was still on legacy grub (grub-efi package) 
rather than grub2-efi after all.  (Though neither of the two packages 
appears to contain a grub[2]-efi-install tool, at least not the Fedora 
17 rpms; but then again, I hopefully won't need to fiddle with that 
again anyway...)


Thanks,
Stephan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: C++ ABI rebuilds for rawhide too?

[Stephan Bergmann]

On 02/28/2012 09:18 PM, Bruno Wolff III wrote:

Are the same packages going to get automatically rebuilt in rawhide as
well as f17?


Btw, does anybody have a pointer to that ABI breakage in gcc 4.7 for 
c++ (i.e., was it an inadvertent breakage, or is there a planned 
incompatibility for GCC 4.7)?


Stephan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Self Introduction

[Stephan Bergmann]

Hi all,

I've recently joined Red Hat's OpenOffice.org/LibreOffice team, so I'll 
probably want to get my hands dirty with the corresponding Fedora 
packages in the future.

My background:  I've been a core member of OpenOffice.org development 
for 14 years.  I'm mostly taking care of the lower code layers, and have 
also been deeply involved in areas like building, testing, and packaging 
the code.  (So its hopefully not all Greek to me here...)

-Stephan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel