Re: Question about LUKS2 on-disk format

[Milan Broz]

On 01/25/2018 08:40 PM, inderau...@arcor.de wrote:
>> Milan Broz  hat am 25. Januar 2018 um 20:32 geschrieben:
>> On 01/25/2018 08:05 PM, inderau...@arcor.de wrote:
>>> Hej there! Just want to ask if/or when it will be available for Fedora 
>>> workstation.
>>
>> Fedora usually has build of all cryptsetup/LUKS tools as the first distro.
>>
>> So, for now, rawhide has all recent builds, so Fedora 28 should get all 
>> builds of LUKS2 as well.
> 
> But it isn't in Fedora 27 already, is it?

No, and it will not be in F27 because part of the update to new libcryptsetup 
is soname library bump
that requires several rebuilds.

> Is it possible to choose it using the Anaconda install GUI?

Some discussion about using new format for installer is already ongoing but for 
now
I would definitely wait with this. LUKS1 format gives you compatibility with 
all distros
and if you do not need any new features, it works well.

> And does LUKS2 provides advantages for normal desktop/latop users as well?

It depends. Support for new authenticated modes is experimental and definitely 
should be
used only for testing for now.

The new on-disk format provides some new features (use of kernel keyring, new 
KDF etc)
but these are not probably so important for a regular user yet. LUKS2 allows us 
to add new things
easily in future, this was the main reason for the change.
(For more info see release notes available on project page
https://gitlab.com/cryptsetup/cryptsetup/blob/master/README.md)

So the plan for LUKS2 is (from upstream point of view) - prepare all 
infrastructure for
new format (soname change, support in systemd, liblkid, storage libraries and 
tools etc;
this is current state in rawhide) and then sometime later enable it in 
installer, if needed.
(If used from commandline, you can add --type luks2 for luksFormat already in 
rawhide.)

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

Re: GCC broken in rawhide?

[Philip Kovacs]

I'm getting:
configure: error: C compiler cannot create executables 

On Friday, January 26, 2018 1:53 AM, Ralf Corsepius  
wrote:
 

 Hi,

ATM all rawhide builds are failing for me, because autoconf's tests for 
CC are failing.

Digging into details led me to this error:
...
cc1: error: fail to initialize plugin 
/usr/lib/gcc/x86_64-redhat-linux/7/plugin/annobin.so
annobin: conftest.c: Error: plugin built for compiler version (7.3.1) 
but run with compiler version (7.2.1)
...

AFAIS, GCC in rawhide was updated to GCC-7.3.1, but apparently annobin 
wasn't rebuilt, resulting into rawhide now carrying an inconsistent 
GCC-toolchain.

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


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

Re: GCC broken in rawhide?

[Samuel Sieb]

On 01/25/2018 10:50 PM, Ralf Corsepius wrote:

Digging into details led me to this error:
...
cc1: error: fail to initialize plugin 
/usr/lib/gcc/x86_64-redhat-linux/7/plugin/annobin.so
annobin: conftest.c: Error: plugin built for compiler version (7.3.1) 
but run with compiler version (7.2.1)

...

AFAIS, GCC in rawhide was updated to GCC-7.3.1, but apparently annobin 
wasn't rebuilt, resulting into rawhide now carrying an inconsistent 
GCC-toolchain.


Are you sure you're reading that correctly?  That message tells me that 
annobin was rebuilt for 7.3.1, but the gcc in the build environment is 
still 7.2.1.

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

GCC broken in rawhide?

[Ralf Corsepius]

Hi,

ATM all rawhide builds are failing for me, because autoconf's tests for 
CC are failing.


Digging into details led me to this error:
...
cc1: error: fail to initialize plugin 
/usr/lib/gcc/x86_64-redhat-linux/7/plugin/annobin.so
annobin: conftest.c: Error: plugin built for compiler version (7.3.1) 
but run with compiler version (7.2.1)

...

AFAIS, GCC in rawhide was updated to GCC-7.3.1, but apparently annobin 
wasn't rebuilt, resulting into rawhide now carrying an inconsistent 
GCC-toolchain.


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

Re: Build flag injection for qmake

[Florian Weimer]

On 01/24/2018 11:18 PM, Rex Dieter wrote:

It should capture all of CFLAGS, CXXFLAGS, LDFLAGS , see
https://src.fedoraproject.org/rpms/qt5/blob/master/f/macros.qt5
where it pulls from %{optflags} and %{?__global_ldflags} as appropriate


Ahh—it's conditional whether CFLAGS etc. have been set.  If they are, 
those variables are used, and not the built-in RPM defaults.  So this 
part works.


I'm still concerned about the eval.  I think it will cause unintended 
shell evaluation of the remaining part of qmake arguments, e.g.:


$ eval echo '$(foo)'
bash: foo: command not found

There has to be a better way to do this.

But otherwise, this approach looks as good as it can be.  Could you 
document it in a .md file within the package?  Then I can link to it from:


https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md

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

[EPEL-devel] Re: Dummy python2 packages submitted

[Jason L Tibbitts III]

It would of course be better if I actually provided links to the
updates:

python2-setuptools (EPEL6):
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-92c3e1b0e4

python2-sphinx (EPEL7):
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9cd64dfc3c

python2-pytest (EPEL7):
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a878cfb2c5

python2-six (EPEL7):
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-92c3e1b0e4

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

Re: python2 dummy packages for EPEL

[Jason L Tibbitts III]

It would of course be better if I actually provided links to the
updates:

python2-setuptools (EPEL6):
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-92c3e1b0e4

python2-sphinx (EPEL7):
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9cd64dfc3c

python2-pytest (EPEL7):
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a878cfb2c5

python2-six (EPEL7):
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-92c3e1b0e4

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

[EPEL-devel] Dummy python2 packages submitted

[Jason L Tibbitts III]

(This is mostly a duplicate of a post I sent to devel@.  I wanted to
alert epel-devel@ but didn't want to crosspost.)

Following my proposal in
https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages which
met with favor from a number of folks here, I went ahead and set up four
dummy packages:

python2-setuptools (in EPEL6)
python2-sphinx (EPEL7)
python2-pytest (EPEL7)
python2-six (EPEL7)

I'll do EPEL6 versions of the latter tomorrow.  (I forgot that I can
only request one branch with the initial repo request.  Oops.  In my
defense, that's a really odd restriction.)

These should, once actually pushed to stable, allow you to avoid having
to add conditionals to depend on setuptools/sphinx/pytest/six in EPEL.
If this works out for folks, I (or anyone else) can potentially add
similar dummy packages for every package which needs one.  Anything to
cut down on those conditionals.

Please check my work, test and give karma as appropriate.  They seem to
work fine for me when I set up a local repo and do some mock builds, but
I only have access to Centos so I guess anything is possible.

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

python2 dummy packages for EPEL

[Jason L Tibbitts III]

Following my proposal in
https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages which
met with favor from a number of folks, I went ahead and set up four
dummy packages:

python2-setuptools (in EPEL6)
python2-sphinx (EPEL7)
python2-pytest (EPEL7)
python2-six (EPEL7)

I'll do EPEL6 versions of the latter tomorrow.  (I forgot that I can
only request one branch with the initial repo request.  Oops.  In my
defense, that's a really odd restriction.)

These should, once actually pushed to stable, allow you to avoid having
to add conditionals to depend on setuptools/sphinx/pytest/six in EPEL.
If this works out for folks, I (or anyone else) can potentially add
similar dummy packages for every package which needs one.  Anything to
cut down on those conditionals.

Please check my work, test and give karma as appropriate.  They seem to
work fine for me when I set up a local repo and do some mock builds, but
I only have access to Centos so I guess anything is possible.

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

Fedora Rawhide-20180125.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Server dvd i386
Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 10/129 (x86_64), 1/2 (arm)

Old failures (same test failed in Rawhide-20180123.n.1):

ID: 188367  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/188367
ID: 188394  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/188394
ID: 188395  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/188395
ID: 188396  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/188396
ID: 188397  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/188397
ID: 188407  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/188407
ID: 188409  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/188409
ID: 188410  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/188410
ID: 188430  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/188430
ID: 188436  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/188436
ID: 188480  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/188480

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

New soft failures (same test did not soft fail in Rawhide-20180123.n.1):

ID: 188358  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/188358
ID: 188359  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/188359
ID: 188380  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/188380
ID: 188426  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/188426

Old soft failures (same test soft failed in Rawhide-20180123.n.1):

ID: 188377  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/188377
ID: 188379  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/188379
ID: 188390  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/188390
ID: 188393  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/188393
ID: 188418  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/188418
ID: 188419  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/188419
ID: 188431  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/188431
ID: 188433  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/188433
ID: 188442  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/188442
ID: 188443  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/188443
ID: 188445  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/188445
ID: 188447  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/188447
ID: 188455  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/188455
ID: 188473  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/188473
ID: 188475  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/188475
ID: 188478  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/188478
ID: 188479  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/188479

Passed openQA tests: 85/129 (x86_64)

New passes (same test did not pass in Rawhide-20180123.n.1):

ID: 188459  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/188459

Skipped openQA tests: 11 of 131

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
1 packages(s) added since previous compose: libxcrypt
2 packages(s) removed since previous compose: gdbm-devel, libcrypt
Previous test data: https://openqa.fedoraproject.org/tests/187571#downloads
Current test data: https://openqa.fedoraproject.org/tests/188352#downloads

Installed system changes in test x86_64 Server-boot-iso install_default: 
1 packages(s) added since previous compose: libxcrypt
2 packages(s) removed since previous compose: gdbm-devel, 

Re: cflag ffast-math

[Andrew Lutomirski]

On Thu, Jan 25, 2018 at 2:53 PM, Sérgio Basto  wrote:

> Hi,
> Question about gcc cflag ffast-math .
> Should I enable cflag ffast-math on opencv build explicitly
> ( -DENABLE_FAST_MATH=ON ) ? and I keep disable cflag ffast-math in mlt
> build [1] ?
>
>
I have no meaningful comment on compiling with -ffast-math, but you
absolutely should not *link* with -ffast-math.  See:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522

and

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

Also, if any toolchain people are listening, maybe you could consider
fixing the GCC bug?  It should be easy, since it mostly consists of option
tweaking.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package review requests: Splitting the "sustmi" GNOME Shell extensions into separate packages

[Andrew Toskin]

One more time: both of the newly split packages have been marked as approved on 
Bugzilla, but I can't get anyone to do whatever final approval is needed for 
the old "sustmi" GNOME Shell extensions to become two separate packages in 
Fedora. I started this process back in October. I'd like to be done with it now 
:)

~ Andrew Toskin / FAS: terrycloth

> Update: I'm still working on splitting the "sustmi" GNOME Shell extension
> subpackages into their own packages. I've opened an issue on the releng 
> pagure page:
> 
> https://pagure.io/releng/issue/7124
> 
> I've also executed `fedpkg retire ...` for the old package on EPEL7, f27, and 
> master.
> And the package review requests for the newly split packages have passed. The 
> Bugzilla
> threads are here:
> 
> * HistoryManager Prefix Search -- 
> https://bugzilla.redhat.com/show_bug.cgi?id=1506428
> * WindowOverlay Icons -- https://bugzilla.redhat.com/show_bug.cgi?id=1506429
> 
> I *think* I might be done with my part of the process, but I haven't gotten 
> any
> feedback in a little while. Is there anything else I need to do?
> 
> Thanks,
> ~ Andrew Toskin / terrycloth
> 
> 
> > I'm the RPM package maintainer for these two GNOME Shell extensions:
> > 
> > * gnome-shell-extension-sustmi-windowoverlay-icons
> > * gnome-shell-extension-sustmi-historymanager-prefix-search
> > 
> > They're both currently subpackages of the main "sustmi" package,
> because
> > upstream had been developing them in a single git repository. The two shell
> extensions
> > have nothing to do with each other, though, and upstream finally decided to 
> > split
> them
> > into separate repositories. So I think it now makes sense to also split 
> > them into
> separate
> > packages.
> > 
> > I'm not entirely clear on the procedure. This wiki page
> > 
> > 
> > https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitt...
> > 
> > talks at first about *font* packages, but otherwise seems relevant. So, I've
> started
> > by splitting and updating the spec files, and creating these review 
> > requests. As I
> > understand it, because the packages were already accepted into Fedora, and 
> > the
> extension
> > code hasn't changed, just the packaging, I think all a reviewer should 
> > really
> need to
> > check is whether the upgrade path is sane and works properly.
> > 
> > * HistoryManager Prefix Search --
> https://bugzilla.redhat.com/show_bug.cgi?id=1506428
> > * WindowOverlay Icons -- https://bugzilla.redhat.com/show_bug.cgi?id=1506429
> > 
> > Please take a look, and let me know if I've missed anything.
> > 
> > Thanks,
> > ~ Andrew / terrycloth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

cflag ffast-math

[Sérgio Basto]

Hi, 
Question about gcc cflag ffast-math .
Should I enable cflag ffast-math on opencv build explicitly 
( -DENABLE_FAST_MATH=ON ) ? and I keep disable cflag ffast-math in mlt
build [1] ?

Thanks,

[1]  
https://src.fedoraproject.org/rpms/mlt/blob/master/f/mlt.spec#_127
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Removal of systemd-units

[Sérgio Basto]

On Thu, 2018-01-25 at 15:42 +0100, Igor Gnatenko wrote:
> On Thu, 2018-01-25 at 15:10 +0100, Igor Gnatenko wrote:
> > It's been 6 years since systemd-units package was merged to
> > systemd, but
> > package maintainers still use it. EL7 has same guidelines as
> > Fedora, so it is
> > safe to make it compliant with Guidelines even there. This is very
> > safe
> > change.
> > 
> > It's just 198 packages and we are just going to fix them for you in
> > following
> > days. Once those dependencies are removed, we plan to remove
> > Provides:
> > systemd-
> > units from systemd package.
> 
> Actually it turned out to be much more complicated because almost all
> of those
> packages were not touched for decades...
> 
> So my proposal is to file a bugs for each of those packages asking
> maintainers
> to fix it up:
> 
> * Remove dependency on systemd-sysv along with systemd-sysv-convert
> executions
> * Remove Requires(post,preun,postun): systemd-units and replace them
> with
> %{?systemd_requires}
> * Add BuildRequires: systemd where macro from previous point is used

Fixed in gammu [1]
[1] 
http://pkgs.fedoraproject.org/rpms/gammu/c/43670eaa87009c89246b54745d48
ce94854dca0f?branch=master 

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Samuel Sieb]

On 01/25/2018 12:02 PM, Howard Howell wrote:

[root@school lesh]# dnf debuginfo-install glibc-2.25-12.fc26.x86_64
Package glibc-debuginfo-2.23.1-11.fc24.x86_64 is already installed,
skipping.
Dependencies resolved.
Nothing to do.


Try adding --best to the command.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20180123.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Server dvd i386
Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 12/129 (x86_64), 1/2 (arm)

New failures (same test did not fail in Rawhide-20180117.n.1):

ID: 187628  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/187628
ID: 187629  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/187629
ID: 187699  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/187699
ID: 187915  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/187915

Old failures (same test failed in Rawhide-20180117.n.1):

ID: 187586  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/187586
ID: 187613  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/187613
ID: 187614  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/187614
ID: 187615  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/187615
ID: 187616  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/187616
ID: 187626  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/187626
ID: 187649  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/187649
ID: 187655  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/187655
ID: 187916  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/187916

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

New soft failures (same test did not soft fail in Rawhide-20180117.n.1):

ID: 187650  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/187650
ID: 187666  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/187666
ID: 187694  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/187694

Old soft failures (same test soft failed in Rawhide-20180117.n.1):

ID: 187596  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/187596
ID: 187598  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/187598
ID: 187609  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/187609
ID: 187612  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/187612
ID: 187637  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/187637
ID: 187638  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/187638
ID: 187652  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/187652
ID: 187661  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/187661
ID: 187662  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/187662
ID: 187664  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/187664
ID: 187674  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/187674
ID: 187692  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/187692
ID: 187697  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/187697
ID: 187698  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/187698

Passed openQA tests: 87/129 (x86_64)

New passes (same test did not pass in Rawhide-20180117.n.1):

ID: 187571  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/187571
ID: 187572  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/187572
ID: 187584  Test: x86_64 Server-dvd-iso server_filesystem_default
URL: https://openqa.fedoraproject.org/tests/187584
ID: 187607  Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/187607
ID: 187608  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/187608
ID: 187634  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/187634
ID: 187635  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/187635
ID: 187641  Test: x86_64 universal 

Re: Wyland is a disaster

[Howard Howell]

On Thu, 2018-01-25 at 09:51 -0800, Howard Howell wrote:
> On Wed, 2018-01-24 at 14:29 -0500, Przemek Klosowski wrote:
> > On 01/23/2018 06:56 PM, Howard Howell wrote:
> > > Due to that last line, issued su and password and ran it again:
> > > # lshw
> > > Segmentation fault (core dumped)
> > 
> > ok, great---so now do 'gdb lshw', type 'r' in gdb, and see where it
> > crashes.
> > 
> > You may need to debuginfo-install few packages if gdb says it can't
> > find 
> > debugging symbols, and you may need to install also some -source 
> > packages because the recent changes in packaging and dnf fail to do
> > so. 
> > Then, report whether the crash happens reliably in a single
> > location,
> > or 
> > is random as it would be if your hardware is flaky.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> It did not crash.  Here are the last 2 lines it output:
> 
> configuration: autonegotiation=off broadcast=yes driver=tun
> driverversion=1.6 duplex=full link=no multicast=yes port=twisted pair
> speed=10Mbit/s
> WARNING: output may be incomplete or inaccurate, you should run this
> program as super-user.
> [Inferior 1 (process 3063) exited normally]
> 
> The things I would point out are that Terminal is in a window, and
> when
> that crash occured I had just run the command, and it may not have
> terminated fully.  The command lshw seems to be multithreaded.
> 
> Regards,
> Les H
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Now I'm in a new and apparently unresolvable loop for debug info for
glibc.  The program gdb when running lshw needs glibc-2.25-
12.fc26.x86_64.

But the install won't pick up that version.  Here is the exchange with
me (gdb) run
Starting program: /usr/sbin/lshw 
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.25-
12.fc26.x86_64
USB 
Program received signal SIGSEGV, Segmentation fault.
0x772c1b70 in feof () from /lib64/libc.so.6
(gdb) exit
Undefined command: "exit".  Try "help".
(gdb) quit
A debugging session is active.

Inferior 1 [process 5734] will be killed.

Quit anyway? (y or n) y
[root@school lesh]# dnf debuginfo-install glibc-2.25-12.fc26.x86_64
enabling updates-debuginfo repository
enabling fedora-debuginfo repository
enabling rpmfusion-free-updates-debuginfo repository
enabling rpmfusion-free-debuginfo repository
enabling rpmfusion-nonfree-updates-debuginfo repository
enabling rpmfusion-nonfree-debuginfo repository
Last metadata expiration check: 0:46:46 ago on Thu 25 Jan 2018 11:11:19
AM PST.
Package glibc-debuginfo-2.23.1-11.fc24.x86_64 is already installed,
skipping.
Dependencies resolved.
Nothing to do.
Complete!
[root@school lesh]# gdb lshw
GNU gdb (GDB) Fedora 8.0.1-33.fc26
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from lshw...Reading symbols from
/usr/lib/debug/usr/sbin/lshw.debug...done.
done.
(gdb) run
Starting program: /usr/sbin/lshw 
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.25-
12.fc26.x86_64
USB 
Program received signal SIGSEGV, Segmentation fault.
0x772c1b70 in feof () from /lib64/libc.so.6
(gdb) 
and gdb running lshw:



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

Re: Question about LUKS2 on-disk format

[inderaue23]

Thanks for your quick reply!

> Milan Broz  hat am 25. Januar 2018 um 20:32 geschrieben:
> 
> 
> On 01/25/2018 08:05 PM, inderau...@arcor.de wrote:
> > Hej there! Just want to ask if/or when it will be available for Fedora 
> > workstation.
> 
> Fedora usually has build of all cryptsetup/LUKS tools as the first distro.
> 
> So, for now, rawhide has all recent builds, so Fedora 28 should get all 
> builds of LUKS2 as well.

But it isn't in Fedora 27 already, is it?
Is it possible to choose it using the Anaconda install GUI?
And does LUKS2 provides advantages for normal desktop/latop users as well?

> 
> I am definitely interested in any feedback.
> Red Hat "storage" seems to have other priorities for now, so we will see 
> where it is going :-]
> 
> m.
> 
> > 
> > https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf
> > 
> > https://fosdem.org/2018/schedule/event/cryptsetup/
> > 
> > All the best!
> > 
> > 
> >  
> > 
> > 
> >  
> > 
> > 
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Question about LUKS2 on-disk format

[Milan Broz]

On 01/25/2018 08:05 PM, inderau...@arcor.de wrote:
> Hej there! Just want to ask if/or when it will be available for Fedora 
> workstation.

Fedora usually has build of all cryptsetup/LUKS tools as the first distro.

So, for now, rawhide has all recent builds, so Fedora 28 should get all builds 
of LUKS2 as well.

I am definitely interested in any feedback.
Red Hat "storage" seems to have other priorities for now, so we will see where 
it is going :-]

m.

> 
> https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf
> 
> https://fosdem.org/2018/schedule/event/cryptsetup/
> 
> All the best!
> 
> 
>  
> 
> 
>  
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Question about LUKS2 on-disk format

[inderaue23]

Hej there! Just want to ask if/or when it will be available for Fedora 
workstation.

https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf

https://fosdem.org/2018/schedule/event/cryptsetup/

All the best!


 


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

Re: [HEADS UP] Removal of systemd-units

[Jason L Tibbitts III]

> "IG" == Igor Gnatenko  writes:

IG> It's just 198 packages and we are just going to fix them for you in
IG> following days.

When posting big lists of packages, please consider running that list
through
https://pagure.io/fedora-misc-package-utilities/blob/master/f/find-package-maintainers

For your list of packages, this gives the following two lists, making it
easy for maintainers to see if they have something to fix without
looking for individual package names.  (Hence it's now trivial for me to
see that I have a couple of things that need fixing.)

Maintainers by package:
389-adminmreynolds nhosoi nkinder rmeggins
389-ds-base  mreynolds nhosoi nkinder rmeggins
3proxy   hubbitus
Cannaorphan
OpenIPMI branto jridky pknirsch
Poundatkac lkundrak wolfy
abrt abrt-team jfilak jmilan mhabrnal mkutlak mmarusak msuchy
accountsservice  gnome-sig mclasen stefw
accumulo ctubbsii milleruntime mizdebsk
aiccupavlix
am-utils iankent
amanda   jridky phracek tibbs
apcupsd  sandeen tibbs
apg  kevin limb smooge
aprsdlucilanga
apt  athimm itamarjp moceap
argusfab janfrode limb
asterisk itamarjp jsmith russellb
at   mmaslano tmraz
audio-entropyd   spot
auditsgrubb
authdcaiqian
autofs   iankent jmoyer
bdii ellert lfield
beanstalkd   gnat jjh
bip  adamwill bcl mmahut
bitlbee  robert
bwbaradrian
cachefilesd  dhowells steved
certmonger   jcholast mharmsen nalin rcritten
cherokee pali
cmst martinkg
colord   gnome-sig rhughes
connman  pavlix
conserverjirka jkastner
crossfirelimb
custodia cheimes simo
cyrus-sasl   jjelen plautrba
denyhostsausil tibbs
device-mapper-multipath agk bmarzins cfeist kzak lvm-team mauelsha mbroz 
mcsontos mornfall msnitzer pjones prajnoha
distcc   grover limb
dlm  agk teigland
dmapdmikep
dovecot  mhlavink
ebnetd   tagoh
fence-virt   lon rmccabe
firebird cicku makowski
fishpoll averi marionline
flumotionlkundrak sergiomb thomasvs
foghorn  rohara
freeipa  abbra ipa-maint jhrozek mkosek pvoborni rcritten simo 
tkrizek
freenx-serverathimm moceap
freeradius   nkondras
freight-toolsnhorman
fsniper  jhrozek
gadget   erikos
gammulaxathom sergiomb
globus-gatekeeperellert
globus-gram-job-manager-fork ellert
globus-gram-job-manager-lsf ellert
globus-gram-job-manager-pbs ellert
globus-gram-job-manager-sge ellert
globus-gridftp-server ellert
globus-scheduler-event-generator ellert
gpsd fab mlichvar ttorling
gsi-openssh  ellert
gssproxy rharwood simo
hdapsd   ttorcz
hsqldb   fnasser jjohnstn mizdebsk
httpdjkaluza jorton luhliarik
hylafax+ faxguy
icecast  besser82 ixs ppisar
ices ixs
iguanaIR hobbes1069 leamas
iipsrv   trasher
inadyn-mtmooninite s4504kr
incron   kevin ralph strobert
ipmitool branto jridky praveenp
ipmiutil arcress
ipxripd  buc
irda-utils   buc
isns-utils   cleech grover
ixpdimm_sw   djbw jhli rutvijk
jabberd  adrian dmaphy mcepl
jenkins  mizdebsk msrb
jettyeclipse-sig kdaniel mizdebsk msimacek
kexec-tools  baoquan yangrr
kgb-bot  averi
krb5 abbra nalin npmccallum rharwood sbose simo
ksh  kdudka mhlavink svashisht
lcgdmaalvarez adev andreamanzi rocha
leafnode mcepl
libvirt  berrange clalance crobinso jforbes laine libvirt-maint 
osier veillard
linuxptp mlichvar
lizardfs jdieter
lm_sensors   jcapik jwrdegoede pknirsch
lvm2 agk bmarzins bmr cfeist kzak lvm-team mauelsha mbroz 
mcsontos mornfall msnitzer pjones prajnoha zkabelac
mailgraphmarcusk
mcstrans dwalsh mgrepl plautrba txtoth
mdadmagk dledford jsorensen mbroz xiao
milter-regex pghmcfc
mipv6-daemon tgraf
miredo   jens
mod_fcgidpghmcfc
mon  filabrazilska janfrode lkundrak lucilanga scenek
mongodb  hhorak jpacner maxamillion mskalick strobert tdawson
mrtg vcrhonek
mt-daapd jfsaucier
nas  ppisar rdieter
net-toolsmruprich mruprich zdohnal
newscachebuc
nordugrid-arc 

Re: Wyland is a disaster

[Howard Howell]

On Wed, 2018-01-24 at 14:29 -0500, Przemek Klosowski wrote:
> On 01/23/2018 06:56 PM, Howard Howell wrote:
> > Due to that last line, issued su and password and ran it again:
> > # lshw
> > Segmentation fault (core dumped)
> 
> ok, great---so now do 'gdb lshw', type 'r' in gdb, and see where it
> crashes.
> 
> You may need to debuginfo-install few packages if gdb says it can't
> find 
> debugging symbols, and you may need to install also some -source 
> packages because the recent changes in packaging and dnf fail to do
> so. 
> Then, report whether the crash happens reliably in a single location,
> or 
> is random as it would be if your hardware is flaky.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
It did not crash.  Here are the last 2 lines it output:

configuration: autonegotiation=off broadcast=yes driver=tun
driverversion=1.6 duplex=full link=no multicast=yes port=twisted pair
speed=10Mbit/s
WARNING: output may be incomplete or inaccurate, you should run this
program as super-user.
[Inferior 1 (process 3063) exited normally]

The things I would point out are that Terminal is in a window, and when
that crash occured I had just run the command, and it may not have
terminated fully.  The command lshw seems to be multithreaded.

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

Re: Build flag injection for qmake

[Rex Dieter]

Kevin Kofler wrote:

> Rex Dieter wrote:
>> It should capture all of CFLAGS, CXXFLAGS, LDFLAGS , see
>> https://src.fedoraproject.org/rpms/qt5/blob/master/f/macros.qt5
>> where it pulls from %{optflags} and %{?__global_ldflags} as appropriate
> 
> It will capture CFLAGS, CXXFLAGS, LDFLAGS from the environment, but it
> will not pick up the correct defaults from the specfile if the specfile
> does not export the environment variables.
> 
> You are using rpm --eval %{?_qt5_qmake_flags} from the shell script to get
> the flags. That spawns a separate instance of RPM, which will not see any
> defines/globals in the specfile. So %{optflags} and %{?__global_ldflags}
> will be the global RPM defaults, unaffected by any settings in the
> specfile. The only way flags from the specfile will be picked up is
> through the *FLAGS environment variables, because those override the
> %{optflags} and/or %{?__global_ldflags} in the definition of
> %{_qt5_qmake_flags}.

caveats accepted.  (requiring use of exported *FLAGS environment vars)

Better ideas or implementations welcome (I have none at the moment)

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

Re: Build flag injection for qmake

[Kevin Kofler]

Rex Dieter wrote:
> It should capture all of CFLAGS, CXXFLAGS, LDFLAGS , see
> https://src.fedoraproject.org/rpms/qt5/blob/master/f/macros.qt5
> where it pulls from %{optflags} and %{?__global_ldflags} as appropriate

It will capture CFLAGS, CXXFLAGS, LDFLAGS from the environment, but it will 
not pick up the correct defaults from the specfile if the specfile does not 
export the environment variables.

You are using rpm --eval %{?_qt5_qmake_flags} from the shell script to get 
the flags. That spawns a separate instance of RPM, which will not see any 
defines/globals in the specfile. So %{optflags} and %{?__global_ldflags} 
will be the global RPM defaults, unaffected by any settings in the specfile. 
The only way flags from the specfile will be picked up is through the *FLAGS 
environment variables, because those override the %{optflags} and/or 
%{?__global_ldflags} in the definition of %{_qt5_qmake_flags}.

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

Non-responsive maintainer: joost

[Richard Shaw]

Per the policy I am asking here if anyone knows how to get in touch with
joost (jo...@cnoc.nl).

I have bug reports for both fpc and lazarus that have gone for weeks
without any response and it's preventing me from building cqrlog on armv7hl
in rawhide due to lazbuild and hedgewars has a segmentation fault due to a
bug in fpc.

I have tried direct emails with no response.


The following bugs have not been addressed:
fpc: needs bootstrap for armhfp
https://bugzilla.redhat.com/show_bug.cgi?id=1491788

SIGSEGV during game shutdown with hedgewars 0.9.23 (hwengine)
https://bugzilla.redhat.com/show_bug.cgi?id=1526848

CQRLOG fails to build for armv7hl on F26 & 27
https://bugzilla.redhat.com/show_bug.cgi?id=1529988

lazbuild binary not working on Rawhide for arm
https://bugzilla.redhat.com/show_bug.cgi?id=1517323


fedora-active-user shows no activity in 2018...

Last login in FAS:
   joost 2017-12-31
Last action on koji:
   Sat, 19 Aug 2017 package list entry revoked: lazarus in
module-package-list by pkgdb
Last package update on bodhi:
   2017-03-29 08:48:02 on package fpc-3.0.2-1.fc26 lazarus-1.6.4-2.fc26
Last actions performed according to fedmsg:
  - joost commented on bodhi update docker-1.13.1-44.git584d391.fc27
(karma: 1) on 2017-12-31 11:36:45 ()
  - hobbes1...@gmail.com filed a new bug RHBZ#1529988 'CQRLOG fails to
build for armv7hl on F26...' on 2017-12-31 11:02:30 ()
  - jrei...@bitwagon.com commented on RHBZ#1526848 'SIGSEGV during game
shutdown with hedgew...' on 2017-12-18 11:19:14 ()
  - mattia.ve...@email.it updated 'cc' on RHBZ#1526848 'SIGSEGV during game
shutdown with hedgew...' on 2017-12-18 04:30:24 ()
  - fwei...@redhat.com commented on RHBZ#1526848 'SIGSEGV during game
shutdown with hedgew...' on 2017-12-18 01:39:08 ()
  - airl...@redhat.com updated 'cc', 'component', and 'assigned_to' on
RHBZ#1526848 'SIGSEGV during game shutdown with hedgew...' on 2017-12-18
01:17:32 ()
  - vasc...@gmail.com filed a new bug RHBZ#1525820 'Need update lazarus to
1.8.0' on 2017-12-14 00:21:33 ()
  - hobbes1...@gmail.com commented on RHBZ#1517323 'lazbuild binary not
working on Rawhide f...' on 2017-11-24 09:33:54 ()
  - hobbes1...@gmail.com filed a new bug RHBZ#1517323 'lazbuild binary not
working on Rawhide f...' on 2017-11-24 09:33:23 ()
  - jkurik commented on RHBZ#1390060 'cqrlog does not start on raspberry pi
3' on 2017-11-16 13:04:26 ()
Last email on mailing list:

Thanks,
Richard
FAS: hobbes1069
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Package Review] python-testinfra & python-anyconfig

[Brett Lentz]

Hello -

I'm looking to get two package requests reviewed. I'm happy to do review swaps,
if anyone has packages they need reviewed.

Here's my two review requests:
https://bugzilla.redhat.com/show_bug.cgi?id=1538341
https://bugzilla.redhat.com/show_bug.cgi?id=1538658

Thanks!

---Brett.



signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Removal of systemd-units

[Kevin Kofler]

Igor Gnatenko wrote:
> It's been 6 years since systemd-units package was merged to systemd, but
> package maintainers still use it. EL7 has same guidelines as Fedora, so it
> is safe to make it compliant with Guidelines even there. This is very safe
> change.
> 
> It's just 198 packages and we are just going to fix them for you in
> following days. Once those dependencies are removed, we plan to remove
> Provides: systemd- units from systemd package.
> 
> Any objections?

Why is it such a problem to keep a one-line virtual Provides in your 
specfile? Removing it will require adding at least as many changelog lines, 
so it doesn't even save lines in the specfile overall. It's just a pointless 
compatibility breakage.

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

Re: -z defs linker flag activated in Fedora rawhide

[Tom Hughes]

On 25/01/18 15:58, Florian Weimer wrote:

On 01/25/2018 04:37 PM, Petr Pisar wrote:

On 2018-01-25, Daniel P  Berrangé  wrote:

Not neccessarily - with perl, the APIs used by extensions are actually
in libperl.so, not /usr/bin/perl, and the extensions link to libperl.so
So perl binary modules ought to still build without undefined symbols,
as IIUC they're not relying on things in /usr/bin/perl


Perl fails too
.

While extensions link to libperl.so that itself links to libpthread.so
that defines pthread_getspecific symbol, the extensions linking fails
because they use dTHX macro, provided by included thread.h via perl.h,
that expands to pthread_getspecific.

In other words it looks like -z defs requires that all used symbols
are provided by directly linked libraries. I.e. we will have to patch
Perl so that extensions add -lptrhread to the linker flags.


Interesting.  This leads to:

$ eu-readelf --symbols=.dynsym /usr/lib64/perl5/auto/POSIX/POSIX.so | 
grep specific
    52:   0 NOTYPE  GLOBAL DEFAULT    UNDEF 
pthread_getspecific


So the symbol version is missing, and there is no guarantee for 
compatibility with future glibc versions. 8-(


This is exactly the kind of problem -z defs intends to catch.


There seems to be a similar issue with perl extensions that use C++ 
failing to link due to missing libstdc++ symbols, eg:


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

I think in that case the issue is that libgdal is linked to libstdc++ 
but the perl GDAL.so module was wound up with direct references to 
symbols in libstdc++ but isn't linking to it directly.


So I think that needs a fix in gdal rather than changing the default 
libraries linked by perl.


In fact I guess the link should really use g++ not gcc? Not sure how 
easy that is to do in a perl extension build...


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 01/25/2018 04:37 PM, Petr Pisar wrote:

On 2018-01-25, Daniel P  Berrangé  wrote:

Not neccessarily - with perl, the APIs used by extensions are actually
in libperl.so, not /usr/bin/perl, and the extensions link to libperl.so
So perl binary modules ought to still build without undefined symbols,
as IIUC they're not relying on things in /usr/bin/perl


Perl fails too
.

While extensions link to libperl.so that itself links to libpthread.so
that defines pthread_getspecific symbol, the extensions linking fails
because they use dTHX macro, provided by included thread.h via perl.h,
that expands to pthread_getspecific.

In other words it looks like -z defs requires that all used symbols
are provided by directly linked libraries. I.e. we will have to patch
Perl so that extensions add -lptrhread to the linker flags.


Interesting.  This leads to:

$ eu-readelf --symbols=.dynsym /usr/lib64/perl5/auto/POSIX/POSIX.so | 
grep specific
   52:   0 NOTYPE  GLOBAL DEFAULTUNDEF 
pthread_getspecific


So the symbol version is missing, and there is no guarantee for 
compatibility with future glibc versions. 8-(


This is exactly the kind of problem -z defs intends to catch.

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

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 01/25/2018 04:51 PM, Richard Hughes wrote:

On 25 January 2018 at 14:52, Florian Weimer  wrote:

../src/fu-device-locker.c:49:1: internal compiler error: in
ix86_expand_prologue, at config/i386/i386.c:14572

Yes, this is: https://bugzilla.redhat.com/show_bug.cgi?id=1538648


Agreed.


I can perhaps put a workaround in redhat-rpm-config, which should make it
much less likely that this compiler bug is encountered.


Should I avoid building my packages on rawhide until that workaround
is done? This seems kinda late in the cycle to be playing compiler
whack-a-mole...


rawhide should have a workaround in place, see my other message.

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

Re: -z defs linker flag activated in Fedora rawhide

[Richard Hughes]

On 25 January 2018 at 14:52, Florian Weimer  wrote:
>> ../src/fu-device-locker.c:49:1: internal compiler error: in
>> ix86_expand_prologue, at config/i386/i386.c:14572
> Yes, this is: https://bugzilla.redhat.com/show_bug.cgi?id=1538648

Agreed.

> I can perhaps put a workaround in redhat-rpm-config, which should make it
> much less likely that this compiler bug is encountered.

Should I avoid building my packages on rawhide until that workaround
is done? This seems kinda late in the cycle to be playing compiler
whack-a-mole...

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

Re: internal compiler error: in ix86_expand_prologue, at config/i386/i386.c:14572

[Sérgio Basto]

On Thu, 2018-01-25 at 15:15 +0100, Michael Schwendt wrote:
> Are recent GCC changes we need to be aware of?
> 
> i686 build ends due to various internal compiler errors.
> The same code has built fine before a few months ago.
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1020693
> https://kojipkgs.fedoraproject.org//work/tasks/8584/24438584/build.lo
> g

yeah same here I guess 

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


-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Sérgio Basto]

On Thu, 2018-01-25 at 14:50 +, Peter Robinson wrote:
> On Thu, Jan 25, 2018 at 2:21 PM, Michael Cronenworth  > wrote:
> > On 01/25/2018 02:41 AM, Richard W.M. Jones wrote:
> > > 
> > > I think the -z defs change should be reverted.  It breaks very
> > > long-
> > > standing expected behaviour of linkers and there's been no proper
> > > justification for doing it.
> > 
> > 
> > +1
> > 
> > This should go through a Fedora Change workflow. I am unaware of a
> > Fedora
> > Change for this.
> 
> It did [1], and I'm fairly certain it was referenced on this thread
> already too.
> 
> [1] https://fedoraproject.org/wiki/Changes/BINUTILS2291#Scope

2016-11-15  Fedora 25 Release
2017-02-28  Branch Fedora 26 from Rawhide (Rawhide becomes future F27)

2017-07-11  Fedora 26 Release
2017-08-15  Branch Fedora 27 from Rawhide (Rawhide becomes future F28)

2017-11-14  Fedora 27 Release
2018-02-20  Branch Fedora 28 from Rawhide (Rawhide becomes future F29)

Can we do branch more early ? (like Branch Fedora 27 , but not at same
time of EOL of previous release  because I going crazy , every time I
rebuild something in rawhide it won't build because some new feature . 

This -z breaks openv (on python2 module), clamav (I guess  , kodi , and
god knows what more ... 

This rawhide in open since 2017-08-15 , after 5 months , we decide add 
this breaking feature , more gcc8 and his new lessons that abs(of
unsigned ) is redundant so we won't build it . 

so +1 (-z defs change should be reverted)


-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: internal compiler error: in ix86_expand_prologue, at config/i386/i386.c:14572

[Florian Weimer]

After consulting with Jakub, I switched rawhide to generic GCC tuning on 
i686, as was the intent when we dropped the Atom tuning for Fedora 26.


See: 

This should paper over most instances of the compiler bug in question. 
(GCC itself has been built with generic tuning, adding a fair amount of 
coverage testing.)


This should unblock rawhide development again.

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

Re: -z defs linker flag activated in Fedora rawhide

[Petr Pisar]

On 2018-01-25, Daniel P  Berrangé  wrote:
> Not neccessarily - with perl, the APIs used by extensions are actually
> in libperl.so, not /usr/bin/perl, and the extensions link to libperl.so
> So perl binary modules ought to still build without undefined symbols,
> as IIUC they're not relying on things in /usr/bin/perl
>
Perl fails too
.

While extensions link to libperl.so that itself links to libpthread.so
that defines pthread_getspecific symbol, the extensions linking fails
because they use dTHX macro, provided by included thread.h via perl.h,
that expands to pthread_getspecific.

In other words it looks like -z defs requires that all used symbols
are provided by directly linked libraries. I.e. we will have to patch
Perl so that extensions add -lptrhread to the linker flags.

I don't say this not a bug in Perl, but just that Perl is affected.

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

Re: Problems debugging problems... formerly Re: Wyland is a disaster

[Jonathan Wakely]

On 24/01/18 15:06 -0700, stan wrote:

On Wed, 24 Jan 2018 14:37:30 -0500
Przemek Klosowski  wrote:


For instance, I observed a reliable desktop session crash on exiting
Pan newsreader. I don't know how to debug it because it crashes the
session and I get logged out.


I think this is because the C++ used in Pan is incompatible with
current versions of g++ being used.


That's a funny way to say the package is buggy.


More specifically, when I saw this
issue in F25, I was able to end it by compiling the src.rpm with
optimization set to O0.  This type of thing also occurred in firefox
when the latest C++ was released, as it made some things commonly used
in earlier versions errors.


Yes, firefox code was buggy, it plays lots of nasty undefined tricks.

"It worked OK until now" doesn't mean something isn't a bug if you're
not following the rules of the language.

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

Re: -z defs linker flag activated in Fedora rawhide

[Michael Cronenworth]

On 01/25/2018 08:50 AM, Peter Robinson wrote:

It did [1], and I'm fairly certain it was referenced on this thread already too.

[1]https://fedoraproject.org/wiki/Changes/BINUTILS2291#Scope


That's poorly advertised. I would not associate a Binutils version update with a 
LDFLAGS change.


The change should be broken into two changes. Disappointing that FESCo did not 
mandate that. Members should use this thread as an example they need improvement.

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

Re: libcdio soname bump in rawhide

[Michael Schwendt]

On Thu, 25 Jan 2018 15:24:38 +0100, Adrian Reber wrote:

> /usr/include/qt5/QtGui/qstatictext.h:70:18: note:   no known conversion for 
> argument 1 from 'QString' to 'const QStaticText&'
> 
> Which does not seem to be libcdio related. Is this a know error
> in audacious-plugins?

It is due to Qt 5.10 and fixed by:
https://src.fedoraproject.org/rpms/audacious-plugins/c/2d2eb8305f973f399a862beab84ac34c788ef4ec?branch=master
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Upstream installs AppData file in /usr/share/appdata

[Richard Hughes]

It's not a huge deal, appstream searches both locations. Metainfo is best,
but a low priority fix IMHO. Richard

On 25 Jan 2018 14:42, "Neal Gompa"  wrote:

On Thu, Jan 25, 2018 at 9:39 AM, Samuel Rakitničan
 wrote:
> Hi,
>
> I have a package where upstream installs AppData file in
/usr/share/appdata, but the Fedora Packaging Guidelines says it should be
installed to /usr/share/metainfo. I am wondering how to approach this;
should I submit a PR upstream, should I change it locally or should I leave
it unchanged. Are there any compatibility reasons to keep
/usr/share/appdata upstream?
>

Submit a PR upstream to fix it, and use that patch to change it locally.

--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 01/25/2018 04:04 PM, Fabio Valentini wrote:

Yes, this is:https://bugzilla.redhat.com/show_bug.cgi?id=1538648

I can perhaps put a workaround in redhat-rpm-config, which should make it
much less likely that this compiler bug is encountered.  Rebuilding gcc
takes 15+ hours, unfortunately, and untagging it will only revert to a
version which miscompiles OpenSSH and RPM. 8-(



Honestly, if the "-z defs" change leads to such


The above is a unrelated compiler bug, not related to -z defs.

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

Re: -z defs linker flag activated in Fedora rawhide

[Fabio Valentini]

On Thu, Jan 25, 2018 at 3:52 PM, Florian Weimer  wrote:
> On 01/25/2018 03:45 PM, Richard Hughes wrote:
>>
>> On 25 January 2018 at 14:28, Richard Hughes  wrote:
>>>
>>> Was there a test mass rebuild? If so, how many packages need fixes? I
>>> got bitten by this just now and it would have been nice to fix the
>>> problems upstream before Fedora rebuilds just started failing.
>>
>>
>> Replying to myself, trying to fix it (by adding the "missing" private
>> library to the plugins) and rebuilding I triggered a gcc bug on i386:
>>
>> *** WARNING *** there are active plugins, do not report this as a bug
>> unless you can reproduce it without enabling any plugins.
>> Event| Plugins
>> PLUGIN_FINISH_UNIT   | Generate final annotations
>> PLUGIN_START_UNIT| Generate global annotations
>> PLUGIN_ALL_PASSES_END| Generate per-function annotations
>> ../src/fu-device-locker.c: In function
>> 'fu_device_locker_class_intern_init':
>> ../src/fu-device-locker.c:49:1: internal compiler error: in
>> ix86_expand_prologue, at config/i386/i386.c:14572
>>   G_DEFINE_TYPE (FuDeviceLocker, fu_device_locker, G_TYPE_OBJECT)
>
>
> Yes, this is: https://bugzilla.redhat.com/show_bug.cgi?id=1538648
>
> I can perhaps put a workaround in redhat-rpm-config, which should make it
> much less likely that this compiler bug is encountered.  Rebuilding gcc
> takes 15+ hours, unfortunately, and untagging it will only revert to a
> version which miscompiles OpenSSH and RPM. 8-(

Honestly, if the "-z defs" change leads to such massive problems,
maybe it really should be considered to revert this change for f28 -
if only to give upstream developers and package maintainers more time
for fixes. I can imagine overworked maintainers with dozens of broken
packages ignoring the issues or just putting the "%undef" into their
packages without investigating (which would cost more time), possibly
obscuring real issues. I think enabling this change again right after
the f28 mass rebuild and branching would be the best, giving
maintainers the most time.

Fabio

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

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 01/25/2018 03:45 PM, Richard Hughes wrote:

On 25 January 2018 at 14:28, Richard Hughes  wrote:

Was there a test mass rebuild? If so, how many packages need fixes? I
got bitten by this just now and it would have been nice to fix the
problems upstream before Fedora rebuilds just started failing.


Replying to myself, trying to fix it (by adding the "missing" private
library to the plugins) and rebuilding I triggered a gcc bug on i386:

*** WARNING *** there are active plugins, do not report this as a bug
unless you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_UNIT   | Generate final annotations
PLUGIN_START_UNIT| Generate global annotations
PLUGIN_ALL_PASSES_END| Generate per-function annotations
../src/fu-device-locker.c: In function 'fu_device_locker_class_intern_init':
../src/fu-device-locker.c:49:1: internal compiler error: in
ix86_expand_prologue, at config/i386/i386.c:14572
  G_DEFINE_TYPE (FuDeviceLocker, fu_device_locker, G_TYPE_OBJECT)


Yes, this is: https://bugzilla.redhat.com/show_bug.cgi?id=1538648

I can perhaps put a workaround in redhat-rpm-config, which should make 
it much less likely that this compiler bug is encountered.  Rebuilding 
gcc takes 15+ hours, unfortunately, and untagging it will only revert to 
a version which miscompiles OpenSSH and RPM. 8-(


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

Re: -z defs linker flag activated in Fedora rawhide

[Peter Robinson]

On Thu, Jan 25, 2018 at 2:21 PM, Michael Cronenworth  wrote:
> On 01/25/2018 02:41 AM, Richard W.M. Jones wrote:
>>
>> I think the -z defs change should be reverted.  It breaks very long-
>> standing expected behaviour of linkers and there's been no proper
>> justification for doing it.
>
>
> +1
>
> This should go through a Fedora Change workflow. I am unaware of a Fedora
> Change for this.

It did [1], and I'm fairly certain it was referenced on this thread already too.

[1] https://fedoraproject.org/wiki/Changes/BINUTILS2291#Scope
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Richard Hughes]

On 25 January 2018 at 14:28, Richard Hughes  wrote:
> Was there a test mass rebuild? If so, how many packages need fixes? I
> got bitten by this just now and it would have been nice to fix the
> problems upstream before Fedora rebuilds just started failing.

Replying to myself, trying to fix it (by adding the "missing" private
library to the plugins) and rebuilding I triggered a gcc bug on i386:

*** WARNING *** there are active plugins, do not report this as a bug
unless you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_UNIT   | Generate final annotations
PLUGIN_START_UNIT| Generate global annotations
PLUGIN_ALL_PASSES_END| Generate per-function annotations
../src/fu-device-locker.c: In function 'fu_device_locker_class_intern_init':
../src/fu-device-locker.c:49:1: internal compiler error: in
ix86_expand_prologue, at config/i386/i386.c:14572
 G_DEFINE_TYPE (FuDeviceLocker, fu_device_locker, G_TYPE_OBJECT)
 ^

Other architectures build fine:
https://koji.fedoraproject.org/koji/taskinfo?taskID=24438792

I've also did a test build of the "fix" on our upstream Travis CI,
which has now started failing on clang, but not gcc:
https://travis-ci.org/hughsie/fwupd/jobs/333283947

What a giant waste of time.

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

Re: [HEADS UP] Removal of systemd-units

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-01-25 at 15:10 +0100, Igor Gnatenko wrote:
> It's been 6 years since systemd-units package was merged to systemd, but
> package maintainers still use it. EL7 has same guidelines as Fedora, so it is
> safe to make it compliant with Guidelines even there. This is very safe
> change.
> 
> It's just 198 packages and we are just going to fix them for you in following
> days. Once those dependencies are removed, we plan to remove Provides:
> systemd-
> units from systemd package.

Actually it turned out to be much more complicated because almost all of those
packages were not touched for decades...

So my proposal is to file a bugs for each of those packages asking maintainers
to fix it up:

* Remove dependency on systemd-sysv along with systemd-sysv-convert executions
* Remove Requires(post,preun,postun): systemd-units and replace them with
%{?systemd_requires}
* Add BuildRequires: systemd where macro from previous point is used
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpp7O8ACgkQaVcUvRu8
X0zL0A/+LMNVNwLLq/KgKN1Cx8HBL1wCERq0SAlVo1z1LO4IfpiKDJ6vQWal4mqc
iGAH9prjuC3dIkOp5l8B/ejVmCeDkmlfQuQ90t7KFxiiaDi17X3NBY615cyqynfz
7x1Mgi7E6alKlSyd631PNp2oMZNH/AdZA8FHsvcXK0PY/2uE0sofXdnslZHhzl9/
59dYjnH6J0Udyg2uGTbyr1i+ie0z3cnhqwq1k7ltuLC4+mhqdEWk+g1gqj+nLFq0
phI0zeJX5zrZCTZa3fTswDJY1rklp0T8OKQHqbzyxCy/2PfnlnlY19XOyamriOOK
K/gOaJL05XrH4KH2yL2t5Jd1AsXKy0WwY9Is62vtEirBPSlhQ7+xzLMiDVxhvWap
U46h420lP7wCKSkzENAs8ns7sFMyImCtHNtZ88qDeHqKE35vv0qfO2gEOr1iLqgG
WYV2NDj2mPjlihHF/WG3o0olOsk8inprQ+3qZstg+ogwlcDIlc4Lh0w6JuWQ/QrF
toGbcny8Tea5nA3C8YfCXKjp+vqSDCHcWD7Dxky98xFSD818yQTzoy2X8BhZuYb4
NrCfCjmaeboB8bh/Klqz+5KhSKouhwgPfukjoht9QKnOr/G1DX6dQuMJ9ZgBar8O
F1+uN2kGgnhbrKcB+cGT+mEYEvoQa2PjCxE5Bh2Sb7cSisQSU5M=
=dEN1
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Upstream installs AppData file in /usr/share/appdata

[Neal Gompa]

On Thu, Jan 25, 2018 at 9:39 AM, Samuel Rakitničan
 wrote:
> Hi,
>
> I have a package where upstream installs AppData file in /usr/share/appdata, 
> but the Fedora Packaging Guidelines says it should be installed to 
> /usr/share/metainfo. I am wondering how to approach this; should I submit a 
> PR upstream, should I change it locally or should I leave it unchanged. Are 
> there any compatibility reasons to keep /usr/share/appdata upstream?
>

Submit a PR upstream to fix it, and use that patch to change it locally.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Upstream installs AppData file in /usr/share/appdata

[Samuel Rakitničan]

Hi,

I have a package where upstream installs AppData file in /usr/share/appdata, 
but the Fedora Packaging Guidelines says it should be installed to 
/usr/share/metainfo. I am wondering how to approach this; should I submit a PR 
upstream, should I change it locally or should I leave it unchanged. Are there 
any compatibility reasons to keep /usr/share/appdata upstream?

https://fedoraproject.org/w/index.php?title=Packaging%3AAppData=revision=501456=486600
https://pagure.io/packaging-committee/issue/704
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: internal compiler error: in ix86_expand_prologue, at config/i386/i386.c:14572

[Florian Weimer]

On 01/25/2018 03:25 PM, Marek Polacek wrote:

On Thu, Jan 25, 2018 at 03:15:05PM +0100, Michael Schwendt wrote:

Are recent GCC changes we need to be aware of?

i686 build ends due to various internal compiler errors.
The same code has built fine before a few months ago.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1020693
https://kojipkgs.fedoraproject.org//work/tasks/8584/24438584/build.log


Filed as
https://bugzilla.redhat.com/show_bug.cgi?id=1538648
Can anybody provide a preprocessed source file?


I think I got it.

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

Re: -z defs linker flag activated in Fedora rawhide

[Richard Hughes]

On 25 January 2018 at 14:21, Michael Cronenworth  wrote:
> This should go through a Fedora Change workflow. I am unaware of a Fedora
> Change for this.

Was there a test mass rebuild? If so, how many packages need fixes? I
got bitten by this just now and it would have been nice to fix the
problems upstream before Fedora rebuilds just started failing.

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

Re: internal compiler error: in ix86_expand_prologue, at config/i386/i386.c:14572

[Marek Polacek]

On Thu, Jan 25, 2018 at 03:15:05PM +0100, Michael Schwendt wrote:
> Are recent GCC changes we need to be aware of?
> 
> i686 build ends due to various internal compiler errors.
> The same code has built fine before a few months ago.
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1020693
> https://kojipkgs.fedoraproject.org//work/tasks/8584/24438584/build.log

Filed as
https://bugzilla.redhat.com/show_bug.cgi?id=1538648
Can anybody provide a preprocessed source file?

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

Re: libcdio soname bump in rawhide

[Adrian Reber]

On Thu, Jan 18, 2018 at 10:25:56PM +0100, Adrian Reber wrote:
> libcdio upstream released the 2.0 version a few weeks ago and I will
> updated rawhide to the latest libcdio version. It comes with a new
> soname and I will also rebuild all dependencies.

libcdio and libcdio-paranoia have been updated in rawhide and all
dependencies (except audacious-plugins) have been rebuilt successfully.

The audacious-plugins build failed with:

info_bar.cc: In member function 'virtual void 
InfoBar::paintEvent(QPaintEvent*)':
info_bar.cc:259:61: error: no match for 'operator=' (operand types are 
'QStaticText' and 'QString')
  width () - ps.VisWidth - ps.Height - ps.Spacing);
 ^
In file included from /usr/include/qt5/QtGui/QStaticText:1:0,
 from info_bar.h:23,
 from info_bar.cc:22:
/usr/include/qt5/QtGui/qstatictext.h:68:18: note: candidate: QStaticText& 
QStaticText::operator=(QStaticText&&)
 QStaticText =(QStaticText &) Q_DECL_NOTHROW { swap(other); 
return *this; }
  ^~~~
/usr/include/qt5/QtGui/qstatictext.h:68:18: note:   no known conversion for 
argument 1 from 'QString' to 'QStaticText&&'
/usr/include/qt5/QtGui/qstatictext.h:70:18: note: candidate: QStaticText& 
QStaticText::operator=(const QStaticText&)
 QStaticText =(const QStaticText &);
  ^~~~
/usr/include/qt5/QtGui/qstatictext.h:70:18: note:   no known conversion for 
argument 1 from 'QString' to 'const QStaticText&'

Which does not seem to be libcdio related. Is this a know error
in audacious-plugins?

Adrian


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Michael Cronenworth]

On 01/25/2018 02:41 AM, Richard W.M. Jones wrote:

I think the -z defs change should be reverted.  It breaks very long-
standing expected behaviour of linkers and there's been no proper
justification for doing it.


+1

This should go through a Fedora Change workflow. I am unaware of a Fedora Change for 
this.

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

internal compiler error: in ix86_expand_prologue, at config/i386/i386.c:14572

[Michael Schwendt]

Are recent GCC changes we need to be aware of?

i686 build ends due to various internal compiler errors.
The same code has built fine before a few months ago.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1020693
https://kojipkgs.fedoraproject.org//work/tasks/8584/24438584/build.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[HEADS UP] Removal of systemd-units

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It's been 6 years since systemd-units package was merged to systemd, but
package maintainers still use it. EL7 has same guidelines as Fedora, so it is
safe to make it compliant with Guidelines even there. This is very safe change.

It's just 198 packages and we are just going to fix them for you in following
days. Once those dependencies are removed, we plan to remove Provides: systemd-
units from systemd package.

Any objections?

389-admin
389-ds-base
3proxy
Canna
OpenIPMI
Pound
abrt
accountsservice
accumulo
aiccu
am-utils
amanda
apcupsd
apg
aprsd
apt
argus
asterisk
at
audio-entropyd
audit
authd
autofs
bdii
beanstalkd
bip
bitlbee
bwbar
cachefilesd
certmonger
cherokee
cmst
colord
connman
conserver
crossfire
custodia
cyrus-sasl
denyhosts
device-mapper-multipath
distcc
dlm
dmapd
dovecot
ebnetd
fence-virt
firebird
fishpoll
flumotion
foghorn
freeipa
freenx-server
freeradius
freight-tools
fsniper
gadget
gammu
globus-gatekeeper
globus-gram-job-manager-fork
globus-gram-job-manager-lsf
globus-gram-job-manager-pbs
globus-gram-job-manager-sge
globus-gridftp-server
globus-scheduler-event-generator
gpsd
gsi-openssh
gssproxy
hdapsd
hsqldb
httpd
hylafax+
icecast
ices
iguanaIR
iipsrv
inadyn-mt
incron
ipmitool
ipmiutil
ipxripd
irda-utils
isns-utils
ixpdimm_sw
jabberd
jenkins
jetty
kexec-tools
kgb-bot
krb5
ksh
lcgdm
leafnode
libvirt
linuxptp
lizardfs
lm_sensors
lvm2
mailgraph
mcstrans
mdadm
milter-regex
mipv6-daemon
miredo
mod_fcgid
mon
mongodb
mrtg
mt-daapd
nas
net-tools
newscache
nordugrid-arc
nordugrid-arc-gangliarc
novacom-server
nsca
nsd
nss-pam-ldapd
ntop
ntp
numad
nut
nuttcp
oddjob
olpc-utils
opendnssec
openerp
openhpi-subagent
openssh
openvpn
openvswitch
ostree
pads
pdns
phodav
php
pki-core
plague
portreserve
pptp
proftpd
psacct
pure-ftpd
qemu
qpid-cpp
racoon2
radvd
rarpd
rbldnsd
rhnmd
rhnsd
rng-tools
root
rpm-ostree-toolbox
rsync
rwall
salt
samba
sanlock
sblim-sfcb
scsi-target-utils
sems
ser2net
shinken
sks
smartmontools
smokeping
snmptt
soundmodem
spamass-milter
spamassassin
spice-vdagent
spindown
squidGuard
sssd
stud
stunnel
syslog-ng
system-config-printer
tftp
tlsdate
tntnet
tomcat
trousers
uptimed
util-linux
uucp
uwsgi
varnish
vdr-epg-daemon
voms
vtun
whatsup
wicd
xinetd
yaws
yum-updatesd
znc
zvbi
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpp5WUACgkQaVcUvRu8
X0yDKw/+MRbamvgLQw4OOzbWUX31bJQ8LMA2IkZGjLXH5nUWFNGNHSxlu/034SRx
XG9HRq/+aNJ/psAq9zzZKQ2ueP+Zg+HfKqNU0Tt5gGe7gAUnNroMbjC3z8ln3sU3
jdxy4LBXEyqpq8tkUk4eGzcF2d+XZs0KrJ5NIqHNsVUiD377DtRqg1Ag2dIxitpe
BkNsk6KTUDMDKJSLRij2ETHtkggORF9kxzmBssOdvzMG5jubkmRIBiX5Nhzvsont
OQp2E7x+oSmtd2DQ5jh5gMi7T0J0w+ZDRNx+E/fX9pgCL37ACuny9IbEAk3jWzeo
QkGXktl3/9fVsDbebUj78SRX75YtrxDu9jb4HHueXjtTTin2fBLPB0Da52S9ITli
307BGrlzVEm4LcJV/y93OO6y4VQWyJ/7x2IcsHAOONMWA8QY63RXtrClXy98yRTG
NPr/bltKNsFYLQvRLZYxYfLSOw8aiFi0dN6ThHNe3leuzqN0ZdR15RgU/PNQtJZ5
CHy3bBGu894pKFQ9ZCKnVcu3QKNqikhKcuoPTbvrMlOG4GJvlDnwazrW2cLYcMf6
FarPcX56zU6s+nfQWeU95sZFQVRseujwfPgXLMVQRLOBXdAAKmT5m0LIcBv7U9pw
SERCVcsJu5cfMMGM1RFrILEwxTV8zx9KhnYYgX884Ae0l5K6v5A=
=/GVE
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: EPEL support in "master" branch (aka speeding up Fedora development)

[Tomasz Kłoczko]

On 25 January 2018 at 08:26, Vít Ondruch  wrote:
> Just to illustrate what this is about, these are 3 PR trying to fix the
> branches for next RHEL:
>
> https://src.fedoraproject.org/rpms/rubygem-ruby-rc4/pull-request/1
> https://src.fedoraproject.org/rpms/rubygem-Ascii85/pull-request/1
> https://src.fedoraproject.org/rpms/rubygem-nokogiri/pull-request/1
>
> Non of them is correct, because they are not maintained. If there were no
> branches, it would be much better.

So as you said, main problem here is related to the fact that
something is not maintained.
With or without branches first you need to solve that issue :)

How branches may help solve such problem?
In unexpected way .. if on the master and other branches will be clean
version of the spec, with standardized format/indentation it will be
way easier to allocate time someone who is not assigned to exact
packages but for example to whole group of ruby packages to have look
on your pull requests -> decide is this something which can be
committed or not and eventually send build(s) request(s).

Current Fedora model of the git permissions is well prepared to switch
to branches model because on top of the assignment some people to
single packages there are some number of proven packagers.
Giving those people better platform of the specs in clean and standard
looking form lowers effort on trying understand about what is proposed
change.

There is really big number of packages in case which strict assignment
of the packages does not make any sense because those packages are
very simple or they are very slowly changing.
You can find such packages even in core part of the distribution.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Neal Gompa]

On Thu, Jan 25, 2018 at 6:33 AM, Daniel P. Berrangé  wrote:
> On Thu, Jan 25, 2018 at 08:40:29AM +, Tom Hughes wrote:
>> On 25/01/18 07:31, Remi Collet wrote:
>> > Le 22/01/2018 à 16:24, Florian Weimer a écrit :
>> > > I updated redhat-rpm-config to instruct ld to reject linking shared
>> > > objects with undefined symbols.  Such undefined symbols break symbol
>> > > versioning because the are not necessarily bound to the correct symbol
>> > > version at run time.  (rhbz#1535422)
>> >
>> > So this break all the PHP stack build...
>> >
>> > (all php extensions are dl open plugins, relying on symbol from the engine)
>>
>> Yes it broke all the nodejs binary modules as well, so I fixed them.
>>
>> Doubtless it will do the same for perl, ruby, python, etc.
>
> Not neccessarily - with perl, the APIs used by extensions are actually
> in libperl.so, not /usr/bin/perl, and the extensions link to libperl.so
> So perl binary modules ought to still build without undefined symbols,
> as IIUC they're not relying on things in /usr/bin/perl
>

As I understand it, it's the same way for most Python extensions, too.
Just not the ones that rely on ctypes (aka dlopen), like
python-libarchive-c, and whatnot.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Daniel P . Berrangé]

On Thu, Jan 25, 2018 at 08:40:29AM +, Tom Hughes wrote:
> On 25/01/18 07:31, Remi Collet wrote:
> > Le 22/01/2018 à 16:24, Florian Weimer a écrit :
> > > I updated redhat-rpm-config to instruct ld to reject linking shared
> > > objects with undefined symbols.  Such undefined symbols break symbol
> > > versioning because the are not necessarily bound to the correct symbol
> > > version at run time.  (rhbz#1535422)
> > 
> > So this break all the PHP stack build...
> > 
> > (all php extensions are dl open plugins, relying on symbol from the engine)
> 
> Yes it broke all the nodejs binary modules as well, so I fixed them.
> 
> Doubtless it will do the same for perl, ruby, python, etc.

Not neccessarily - with perl, the APIs used by extensions are actually
in libperl.so, not /usr/bin/perl, and the extensions link to libperl.so
So perl binary modules ought to still build without undefined symbols,
as IIUC they're not relying on things in /usr/bin/perl


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Vít Ondruch]

Dne 25.1.2018 v 09:40 Tom Hughes napsal(a):
> On 25/01/18 07:31, Remi Collet wrote:
>> Le 22/01/2018 à 16:24, Florian Weimer a écrit :
>>> I updated redhat-rpm-config to instruct ld to reject linking shared
>>> objects with undefined symbols.  Such undefined symbols break symbol
>>> versioning because the are not necessarily bound to the correct symbol
>>> version at run time.  (rhbz#1535422)
>>
>> So this break all the PHP stack build...
>>
>> (all php extensions are dl open plugins, relying on symbol from the
>> engine)
>
> Yes it broke all the nodejs binary modules as well, so I fixed them.
>
> Doubtless it will do the same for perl, ruby, python, etc.

I have not yet met any issues with Ruby. Just saying 


V.

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

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 925  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 815  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 787  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 397  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 127  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  46  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  28  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6e4ce19598   
monit-5.25.1-1.el6
  18  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fde8252ab7   
python-bottle-0.12.13-1.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2ba6bfc5d8   
wordpress-4.9.2-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-1049ca4872   
GraphicsMagick-1.3.28-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

rpkg-1.51-3.el6
youtube-dl-2018.01.21-1.el6

Details about builds:



 rpkg-1.51-3.el6 (FEDORA-EPEL-2018-291460ab7d)
 Python library for interacting with rpm+git

Update Information:

- Add compose-id and signing-intent arguments - Change type of compose id from
string to int




 youtube-dl-2018.01.21-1.el6 (FEDORA-EPEL-2018-41888d4ac2)
 A small command-line program to download online videos

Update Information:

Update to the latest upstream.

References:

  [ 1 ] Bug #1529821 - youtube-dl-2018.01.21 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1529821

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

Re: FESCo Elections - January 2018 - Result announcement

[Matthew Miller]

On Thu, Jan 25, 2018 at 01:47:13AM +0100, Jan Kurik wrote:
> The elections for FESCo - January 2018 have concluded, and
> the results are shown below.

Congratulations everyone. And I especially want to thank the people who
ran but didn't make the cutoff. This was an excellent slate of
candidates with long history of Fedora contribution and great ideas for
the future. 


-- 
Matthew Miller

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

Re: koschei interpertation; was: Re: -z defs linker flag activated in Fedora rawhide

[Michael Šimáček]

On 2018-01-23 20:06, R P Herrold wrote:

On Tue, 23 Jan 2018, Daniel P. Berrange wrote:


What needs to be done for this ?  I see my package "libvirt" present
in its UI

   https://apps.fedoraproject.org/koschei/package/libvirt

but it says

   "Package is currently ineligible for scheduling due to following reasons:


looking at the 'EPEL 7' tab, I see:

Base buildroot for EPEL 7 is not installable.

Dependency problems:
nothing provides requested redhat-release-everything

Hunh?



That's a bug in koschei, which will be fixed in the next release.

Michael Simacek


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


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

Re: Re: EPEL support in "master" branch (aka speeding up Fedora development)

[nicolas . mailhot]

- Mail original -
De: "Tomasz Kłoczko"  ?

> What I'm trying to say is that IMO I probably know why up to now it was not
> possible to introduce common indentation in RH and Fedora as well.
> (bad news)
> I know probably as well why now it will be  even harder.
> .. because (as result)
> […]
> In other words on this area way bigger some "human/ego" obstacles than all
> those technical ones. Am I close?

Look, there's no need to assume nefarious intent. Once a spec works, packagers 
will find something else to fill their life with (something else may be another 
form of Fedora activity), and only return to it when an update is needed 
(usually, with the minimal amount of spec changes), or if there is a huge 
problem in the issue tracker. Need for updates can be predicted quite a long 
time in advance if they know their upstream and big problems are rare because 
anyone sensible won't choose to package a software that fails more often than 
he can cope with.

And, mostly, because Fedora packagers are nice people, they still feel 
responsible. That means they do not like someone else touching their specs, 
because, at minima, that forces them to drop their other activities, to check 
the changes are ok (because they feel responsible), and potentially deal with 
the fallout (if the changes have side effects). Worse, if you change too many 
of their specs at once, they may find out they are over-committed, and need to 
allocate yet more time to find someone to hand over some or all the changed 
specs. Lastly, if they are currently working on a change, it may require them 
to rebase their work.

Add to this they do not trust you, because they do not know you, and will 
suspect if they see you change too many specs at once it's just fire and forget 
scripting with no proper testing and no QA on the result, leaving *them* to 
deal with the problems when they asked nothing and their spec worked in the 
first place.

So if you want to setup a Fedora spec cleanup office, that's great but it takes 
more than deep rpm knowledge of one person:
— you need to recruit enough technical people the cleanup office can still 
function when you are unavailable (bus factor)
– you need to setup procedures with QA to properly check the effects of each 
mass spec change, with enough technical guys your side to fix the fallout QA 
finds, all that fast enough there is no long broken period during which 
original packagers are yelled at and distro development crawls to a stop
– you need to setup communication to announce your changes, explain them, and 
give an account of the result
— you need to make sure Fedora documentation is in sync with the changes you're 
making
— you need to plan, for the right least invasive time in the Fedora release 
cycle, to do those changes

And, mostly, you need to build trust. Trust is achieved by being publicly 
successful several times. Trust is destroyed by doing changes without assuming 
their effects, or by doing changes blind, because surely someone will complain 
if you make a mistake (yes they will complain. They will also not trust you 
afterwards).

The bar you need to pass is *way* higher than any other distro-wide change 
because other distro-wide changes usually bring functional improvements (that 
people understand, and want), other distro-wide changes are usually driven by a 
particular package (so it's a matter of packagers helping one of their own), 
other distro-wide changes rarely require touching hundreds of specs, while 
cleanups are highly invasive with no immediate functional benefit to anyone. 
While the problems they can trigger are very immediate.

Regards,

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

Re: Summary/Minutes from today's FESCo Meeting (2018-01-12)

[Dodji Seketeli]

Kevin Kofler  a écrit:

> Justin Forbes wrote:
>> * #1810 Let's flip the switch on January 15th: gating in Fedora
>>   (jforbes, 16:15:51)
>>   * LINK: https://pagure.io/fesco/issue/1810   (jforbes, 16:16:05)
>>   * LINK: https://src.fedoraproject.org/rpms/waiverdb   (pingou,
>> 16:24:22)
>>   * AGREED: Issue #1810: Let's flip the switch on January 15th: gating
>> in Fedora is approved (+8,0,-0)  (jforbes, 16:25:08)
>
> Uh, `dist.abicheck` produces a lot of false positives on:
>
> * libraries that are internal and that nothing should depend on (e.g., in 
> QupZilla, package `qupzilla`),
> * APIs explicitly documented as "private, can change at any version", as 
> common in all Qt modules (e.g., in QtWebEngine, package `qt5-qtwebengine`).

For these two cases you can add a suppression specification file to your
package, telling dist.abicheck to not consider those libraries.  The
file needs to end with the .abignore extension.  This is similar to the
suppression mechanism of the Valgrind tool.

The syntax of a suppression specification file is documented at
https://sourceware.org/libabigail/manual/libabigail-concepts.html#suppression-specifications.

You can test all this by using the fedabipkgdiff[1] tool on your package
(before pushing it to koji) to compare its ABI against the one of the
already-released versions.

[1]: https://sourceware.org/libabigail/manual/fedabipkgdiff.html

> My packages often fail `dist.abicheck`.

If you feel like they shouldn't fail despite the suppression
specification mechanism, then please file a bug and we'll see what we
can do.  This ought to work.

Cheers,

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

Re: -z defs linker flag activated in Fedora rawhide

[Tom Hughes]

On 25/01/18 09:17, Neal Gompa wrote:

On Thu, Jan 25, 2018 at 4:13 AM, Richard W.M. Jones  wrote:

On Thu, Jan 25, 2018 at 09:03:34AM +, Tom Hughes wrote:

On 25/01/18 08:41, Richard W.M. Jones wrote:

On Thu, Jan 25, 2018 at 08:31:29AM +0100, Remi Collet wrote:

Le 22/01/2018 à 16:24, Florian Weimer a écrit :

I updated redhat-rpm-config to instruct ld to reject linking shared
objects with undefined symbols.  Such undefined symbols break symbol
versioning because the are not necessarily bound to the correct symbol
version at run time.  (rhbz#1535422)


So this break all the PHP stack build...

(all php extensions are dl open plugins, relying on symbol from the engine)


I think the -z defs change should be reverted.  It breaks very long-
standing expected behaviour of linkers and there's been no proper
justification for doing it.


Other than detecting cases where shared libraries were missing
NEEDED entries for other shared objects that they use?


I can't remember now what it's called but there's another way to do
that which all other distros except Fedora use.



-Wl,--as-needed and -Wl,--no-undefined

c.f.: http://gitweb.mageia.org/software/rpm/rpm-setup/tree/build.macros.in#n221

openSUSE uses the same approach, but apparently the file doesn't
render on their VCS due to not being UTF-8. :/


But --no-undefined is a synonym for -z defs! They are literally listed 
together in the ld manual page.


The --as-needed varies the algorithm for which shared libraries to mark
as dependencies but doesn't change the behaviour for undefined symbols
as far as I can see.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Neal Gompa]

On Thu, Jan 25, 2018 at 4:13 AM, Richard W.M. Jones  wrote:
> On Thu, Jan 25, 2018 at 09:03:34AM +, Tom Hughes wrote:
>> On 25/01/18 08:41, Richard W.M. Jones wrote:
>> >On Thu, Jan 25, 2018 at 08:31:29AM +0100, Remi Collet wrote:
>> >>Le 22/01/2018 à 16:24, Florian Weimer a écrit :
>> >>>I updated redhat-rpm-config to instruct ld to reject linking shared
>> >>>objects with undefined symbols.  Such undefined symbols break symbol
>> >>>versioning because the are not necessarily bound to the correct symbol
>> >>>version at run time.  (rhbz#1535422)
>> >>
>> >>So this break all the PHP stack build...
>> >>
>> >>(all php extensions are dl open plugins, relying on symbol from the engine)
>> >
>> >I think the -z defs change should be reverted.  It breaks very long-
>> >standing expected behaviour of linkers and there's been no proper
>> >justification for doing it.
>>
>> Other than detecting cases where shared libraries were missing
>> NEEDED entries for other shared objects that they use?
>
> I can't remember now what it's called but there's another way to do
> that which all other distros except Fedora use.
>

-Wl,--as-needed and -Wl,--no-undefined

c.f.: http://gitweb.mageia.org/software/rpm/rpm-setup/tree/build.macros.in#n221

openSUSE uses the same approach, but apparently the file doesn't
render on their VCS due to not being UTF-8. :/



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Richard W.M. Jones]

On Thu, Jan 25, 2018 at 09:03:34AM +, Tom Hughes wrote:
> On 25/01/18 08:41, Richard W.M. Jones wrote:
> >On Thu, Jan 25, 2018 at 08:31:29AM +0100, Remi Collet wrote:
> >>Le 22/01/2018 à 16:24, Florian Weimer a écrit :
> >>>I updated redhat-rpm-config to instruct ld to reject linking shared
> >>>objects with undefined symbols.  Such undefined symbols break symbol
> >>>versioning because the are not necessarily bound to the correct symbol
> >>>version at run time.  (rhbz#1535422)
> >>
> >>So this break all the PHP stack build...
> >>
> >>(all php extensions are dl open plugins, relying on symbol from the engine)
> >
> >I think the -z defs change should be reverted.  It breaks very long-
> >standing expected behaviour of linkers and there's been no proper
> >justification for doing it.
> 
> Other than detecting cases where shared libraries were missing
> NEEDED entries for other shared objects that they use?

I can't remember now what it's called but there's another way to do
that which all other distros except Fedora use.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Tom Hughes]

On 25/01/18 08:41, Richard W.M. Jones wrote:

On Thu, Jan 25, 2018 at 08:31:29AM +0100, Remi Collet wrote:

Le 22/01/2018 à 16:24, Florian Weimer a écrit :

I updated redhat-rpm-config to instruct ld to reject linking shared
objects with undefined symbols.  Such undefined symbols break symbol
versioning because the are not necessarily bound to the correct symbol
version at run time.  (rhbz#1535422)


So this break all the PHP stack build...

(all php extensions are dl open plugins, relying on symbol from the engine)


I think the -z defs change should be reverted.  It breaks very long-
standing expected behaviour of linkers and there's been no proper
justification for doing it.


Other than detecting cases where shared libraries were missing NEEDED 
entries for other shared objects that they use?


It found one of those in my packages certainly.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Richard W.M. Jones]

On Thu, Jan 25, 2018 at 08:31:29AM +0100, Remi Collet wrote:
> Le 22/01/2018 à 16:24, Florian Weimer a écrit :
> > I updated redhat-rpm-config to instruct ld to reject linking shared
> > objects with undefined symbols.  Such undefined symbols break symbol
> > versioning because the are not necessarily bound to the correct symbol
> > version at run time.  (rhbz#1535422)
> 
> So this break all the PHP stack build...
> 
> (all php extensions are dl open plugins, relying on symbol from the engine)

I think the -z defs change should be reverted.  It breaks very long-
standing expected behaviour of linkers and there's been no proper
justification for doing it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Tom Hughes]

On 25/01/18 07:31, Remi Collet wrote:

Le 22/01/2018 à 16:24, Florian Weimer a écrit :

I updated redhat-rpm-config to instruct ld to reject linking shared
objects with undefined symbols.  Such undefined symbols break symbol
versioning because the are not necessarily bound to the correct symbol
version at run time.  (rhbz#1535422)


So this break all the PHP stack build...

(all php extensions are dl open plugins, relying on symbol from the engine)


Yes it broke all the nodejs binary modules as well, so I fixed them.

Doubtless it will do the same for perl, ruby, python, etc.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1537517] perl-threads-shared-1.58 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-threads-shared-1.58-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-22e63cffa4

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1538075] perl-String-Print-0.93 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-String-Print-0.93-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-450e4e3b4b

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1537837] perl-Sereal-4.005 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Sereal-4.005-1.fc27 has been pushed to the Fedora 27 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-4226b2da54

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1537516] perl-threads-2.21 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-threads-2.21-1.fc27 has been pushed to the Fedora 27 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-b77c61238c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1537838] perl-Sereal-Decoder-4.005 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Sereal-Decoder-4.005-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-388dcbc66a

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1537839] perl-Sereal-Encoder-4.005 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Sereal-Encoder-4.005-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-97901a35d7

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1536730] perl-DateTime-TimeZone-2.16 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-DateTime-TimeZone-2.17-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-82beb331e5

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1537829] perl-DateTime-TimeZone-2.17 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-DateTime-TimeZone-2.17-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-82beb331e5

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: EPEL support in "master" branch (aka speeding up Fedora development)

[Vít Ondruch]

Just to illustrate what this is about, these are 3 PR trying to fix the
branches for next RHEL:

https://src.fedoraproject.org/rpms/rubygem-ruby-rc4/pull-request/1
https://src.fedoraproject.org/rpms/rubygem-Ascii85/pull-request/1
https://src.fedoraproject.org/rpms/rubygem-nokogiri/pull-request/1

Non of them is correct, because they are not maintained. If there were
no branches, it would be much better.


V.

Dne 20.1.2018 v 12:27 Igor Gnatenko napsal(a):
> Hello,
>
> I know that many of you like to have just one branch which builds
> everywhere
> (starting from el6), but this really slows down development of Fedora
> for many
> years. Let me show some examples:
>
> * File-triggers are not supported by el6/el7 RPM, so every package
> which has
> icons should have some number of scriptlets conditionalized  by %if
> 0%{?rhel}
> && 0%{?rhel} <= 7.
> * Rich dependencies are not supported by el6/el7 RPM and YUM, so
> anyone who
> wants to use them need to have same conditionals.
> * Some of dependency generators do not exist on el*, so instead of having
> BuildRequires: python3dist(foo) you need to wrap it with conditions
> again and
> I'm working on change proposal which eliminates need of writing runtime
> requirements, so one more place of conditionals.
>
> Given all these, it is very hard to get any new feature in
> "production" because
> everyone wants to support 10 years old thing (even if they don't think
> so).
>
> Even if people hope next version of EL will be better in this, it
> doesn't mean
> that el6/el7 can be fixed easily.
>
>
> Why I'm writing this? I want to hear from you if you think it would be
> good to
> prohibit (or advise, or whatever mechanism would work) usage if
> conditionals in
> (at least) master branch to allow us to develop features faster. Thoughts?
> Suggestions?
> ___ > devel mailing list -- 
> devel@lists.fedoraproject.org > To unsubscribe
send an email to devel-le...@lists.fedoraproject.org



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org