Re: [Heads-up] libical 3.0.0 to reach rawhide, replacing libical-glib
On Mon, 2017-11-13 at 10:01 -0800, Kevin Fenzi wrote: > Orage (the Xfce calendar app) is also broken if you have time to take a > look: > > https://bugzilla.redhat.com/show_bug.cgi?id=1512302 > https://bugzilla.xfce.org/show_bug.cgi?id=13997 Hi, sure, I'll reply on the Red Hat bug. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Heads-up] libical 3.0.0 to reach rawhide, replacing libical-glib
On Tue, 2017-11-14 at 01:36 +0100, Michael Schwendt wrote: > Dunno yet what's the reason. Haven't had a look at it except for unpacking > libical-devel in hope that its %doc section would contain a file that sums > up the API changes. No such file in there. And the "Using Libical" guide > claims it's from 2001, but comes with a fresh timestamp and doesn't tell > about the changes either. Hi, the sum of changes is part of the release notes, which can be found here: https://github.com/libical/libical/releases > vcal_manager.c: In function 'vcal_manager_event_dump': > vcal_manager.c:398:30: warning: implicit declaration of function > 'icaltime_from_timet'; did you mean 'icaltime_as_timet'? [-Wimplicit- > function-declaration] > icalproperty_vanew_dtstamp(icaltime_from_timet(time(NULL), TRUE), > (void*)0)); In your case replace icaltime_from_timet() with icaltime_from_timet_with_zone() where the last argument, the zone to use, will be NULL. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: -Wl,--as-needed by default
On 11/14/2017 03:54 AM, Philip Kovacs wrote:
One concern is that -Wl,--as-needed requires greater accuracy with the ordering
of objects and
libraries as you link. Also, if a package uses a library indirectly, i.e. A uses C
via B: A -> B -> C,--as-needed will peel away C and break A unless A explicitly
mentions its need for C.
I think ld no longer links against symbols in indirect dependencies.
#include
int
main()
{
return (int) &EVP_rc4;
}
/usr/bin/ld: /tmp/ccV4cmYY.o: undefined reference to symbol
'EVP_rc4@@OPENSSL_1_1_0'
//usr/lib64/libcrypto.so.1.1: error adding symbols: DSO missing from
command line
collect2: error: ld returned 1 exit status
Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Minor schedule procedure tweak (rain dates and such)
On 3 November 2017 at 05:55, Matthew Miller wrote: > It turns out that the "Rain Date" concept is confusing to some people > (particularly where that idiom is not familiar). I propose that for F28 > and onward, we keep the basic concept, but ditch that term. Instead, we > use: > > * Release Date Target 1 > * Release Date Target 2 (a week later). > > As now, these will exist for both Beta and Final, and final will only > be pushed back if Beta Target 2 is missed. > > Then (and also new), if the Beta does slip past Target 2, we add a new > "Target 3". If Beta slips to Target 3, Final slips to Target 2 (and we > don't yet add a Target 3). If beta slips to Target 4, we cross off > Final Target 2 and add Final Target 3. > The mismatch in the numbering here feels inherently confusing to me. How about if the numbers were aligned, and then the first Beta target date was called something like "Preferred Beta Target" or "Beta Target 0"? That would give: * Beta Target 0 (preferred): missing this shortens the Beta testing period, but doesn't necessarily cause the Final release to slip * Beta Target 1: missing this means Final Target 2 is the earliest release date that will be considered * Beta Target 2: missing this means defining new Beta Target 3 and Final Target 3 dates * Final Target 1: releasing on this date requires hitting Beta Target 0 or Beta Target 1 * Final Target 2: fallback release target if Beta Target 1 and/or Final Target 1 are missed Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora-Modular 27-20171114.n.0 compose check report
Missing expected images: Docker_base docker x86_64 Server dvd arm Failed openQA tests: 18/94 (x86_64), 4/19 (i386) Old failures (same test failed in 27-20171113.n.1): ID: 169977 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/169977 ID: 169991 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/169991 ID: 169997 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/169997 ID: 16 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/16 ID: 170004 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/170004 ID: 170005 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/170005 ID: 170041 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/170041 ID: 170042 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/170042 ID: 170043 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/170043 ID: 170044 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/170044 ID: 170046 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/170046 ID: 170047 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/170047 ID: 170048 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/170048 ID: 170057 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/170057 ID: 170058 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/170058 ID: 170059 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/170059 ID: 170063 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/170063 ID: 170064 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/170064 ID: 170069 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/170069 ID: 170082 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/170082 ID: 170083 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/170083 ID: 170086 Test: i386 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/170086 Soft failed openQA tests: 2/94 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in 27-20171113.n.1): ID: 169989 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/169989 ID: 169994 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/169994 Passed openQA tests: 68/94 (x86_64), 15/19 (i386) New passes (same test did not pass in 27-20171113.n.1): ID: 169979 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/169979 ID: 170027 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/170027 ID: 170056 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/170056 ID: 170073 Test: i386 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/170073 Installed system changes in test x86_64 Server-boot-iso install_default@uefi: System load changed from 0.06 to 0.17 Previous test data: https://openqa.fedoraproject.org/tests/169760#downloads Current test data: https://openqa.fedoraproject.org/tests/169975#downloads Installed system changes in test i386 Server-dvd-iso install_default: System load changed from 0.35 to 0.16 Previous test data: https://openqa.fedoraproject.org/tests/169783#downloads Current test data: https://openqa.fedoraproject.org/tests/169998#downloads Installed system changes in test x86_64 universal install_package_set_kde: System load changed from 0.18 to 0.07 Previous test data: https://openqa.fedoraproject.org/tests/169836#downloads Current test data: https://openqa.fedoraproject.org/tests/170051#downloads Installed system changes in test i386 universal install_package_set_kde: System load changed from 0.18 to 0.06 Previous test data: https://openqa.fedoraproject.org/tests/169856#downloads Current test data: https://openqa.fedoraproject.org/tests/170071#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: -Wl,--as-needed by default
One concern is that -Wl,--as-needed requires greater accuracy with the ordering
of objects and
libraries as you link. Also, if a package uses a library indirectly, i.e. A
uses C via B: A -> B -> C,--as-needed will peel away C and break A unless A
explicitly mentions its need for C. Of course that should be the case already,
but you're going to see a number of weaknesses in the variouspackages revealed
by adding --as-needed.
On Monday, November 13, 2017 5:48 PM, Tomasz Kłoczko
wrote:
On 13 November 2017 at 22:01, Tomasz Kłoczko wrote:
[..]
> In other words -Wl,--as-needed should be used everywhere WITHOUT exceptions.
> Easiest way apply this globally in Fedora is add --as-needed in
> /usr/lib/rpm/redhat/redhat-hardened-ld spec file by apply patch:
>
> --- /usr/lib/rpm/redhat/redhat-hardened-ld.orig
> +++ /usr/lib/rpm/redhat/redhat-hardened-ld
> @@ -2,4 +2,4 @@
> + %{!static:%{!shared:%{!r:-pie}}}
>
> *link:
> -+ -z now
> ++ -z now --as-needed
Just created pull request with above change:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/3#request_diff
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Modular 27 compose report: 20171114.n.0 changes
OLD: Fedora-Modular-27-20171113.n.1 NEW: Fedora-Modular-27-20171114.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0.00 B Size of dropped packages:0.00 B Size of upgraded packages: 0.00 B Size of downgraded packages: 0.00 B Size change of upgraded packages: 0.00 B Size change of downgraded packages: 0.00 B = ADDED IMAGES = Image: Container_Base docker armhfp Path: Server/armhfp/images/Fedora-Modular-Container-Base-27_Modular-20171114.n.0.armhfp.tar.xz = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Heads-up] libical 3.0.0 to reach rawhide, replacing libical-glib
On Mon, 13 Nov 2017 15:04:55 +0100, Milan Crha wrote: > > The upgrade seems to be API incompatible, so more than rebuilding > > dependencies is necessary. > > Hi, > that's true. libical upstream removed some deprecated symbols, most > notably icaltimetype::is_utc. Dunno yet what's the reason. Haven't had a look at it except for unpacking libical-devel in hope that its %doc section would contain a file that sums up the API changes. No such file in there. And the "Using Libical" guide claims it's from 2001, but comes with a fresh timestamp and doesn't tell about the changes either. libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -I../../../src/common -I../../../src/common -I../../../src/gtk -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/atk-1.0 -pthread -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -Wno-unused-function -Wno-pointer-sign -Wall -I/usr/include/enchant -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -c plugin.c -o vcalendar_la-plugin.o >/dev/null 2>&1 vcal_manager.c: In function 'vcal_manager_event_dump': vcal_manager.c:398:30: warning: implicit declaration of function 'icaltime_from_timet'; did you mean 'icaltime_as_timet'? [-Wimplicit-function-declaration] icalproperty_vanew_dtstamp(icaltime_from_timet(time(NULL), TRUE), (void*)0)); ^~~ icaltime_as_timet vcal_manager.c:398:30: error: incompatible type for argument 1 of 'icalproperty_vanew_dtstamp' In file included from vcal_manager.c:35:0: /usr/include/libical/ical.h:3306:35: note: expected 'struct icaltimetype' but argument is of type 'int' LIBICAL_ICAL_EXPORT icalproperty *icalproperty_vanew_dtstamp(struct icaltimetype v, ...); ^~ vcal_manager.c:426:30: error: incompatible type for argument 1 of 'icalproperty_vanew_created' icalproperty_vanew_created(icaltime_from_timet(time(NULL), TRUE), (void*)0)); ^~~ In file included from vcal_manager.c:35:0: /usr/include/libical/ical.h:3246:35: note: expected 'struct icaltimetype' but argument is of type 'int' LIBICAL_ICAL_EXPORT icalproperty *icalproperty_vanew_created(struct icaltimetype v, ...); ^~ vcal_manager.c:428:35: error: incompatible type for argument 1 of 'icalproperty_vanew_lastmodified' icalproperty_vanew_lastmodified(icaltime_from_timet(time(NULL), TRUE), (void*)0)); ^~~ In file included from vcal_manager.c:35:0: /usr/include/libical/ical.h:3371:35: note: expected 'struct icaltimetype' but argument is of type 'int' LIBICAL_ICAL_EXPORT icalproperty *icalproperty_vanew_lastmodified(struct icaltimetype v, ...); ^~~ vcalendar.c: In function 'create_meeting_from_message_cb_ui': vcalendar.c:160:54: warning: implicit declaration of function 'icaltime_from_timet'; did you mean 'icaltime_as_timet'? [-Wimplicit-function-declaration] gchar *dtstart = g_strdup(icaltime_as_ical_string(icaltime_from_timet(t, FALSE))); ^~~ icaltime_as_timet vcalendar.c:160:54: error: incompatible type for argument 1 of 'icaltime_as_ical_string' In file included from vcalendar.c:30:0: /usr/include/libical/ical.h:171:33: note: expected 'const struct icaltimetype' but argument is of type 'int' LIBICAL_ICAL_EXPORT const char *icaltime_as_ical_string(const struct icaltimetype tt); ^~~ vcalendar.c:161:52: error: incompatible type for argument 1 of 'icaltime_as_ical_string' gchar *dtend = g_strdup(icaltime_as_ical_string(icaltime_from_timet(t2, FALSE))); ^~~ In file included from vcalendar.c:30:0: /usr/include/libical/ical.h:171:33: note: expected 'const struct icaltimetype' but argument is of type 'int' LIBICAL_ICAL_EXPORT const char *icaltime_as_ical_string(const struct icaltimetype tt); ^~~ make[5]: *** [Makefile:666: vcalendar_la-vcal_manager.lo] Error 1 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedor
Re: RFC: -Wl,--as-needed by default
On 13 November 2017 at 22:01, Tomasz Kłoczko wrote:
[..]
> In other words -Wl,--as-needed should be used everywhere WITHOUT exceptions.
> Easiest way apply this globally in Fedora is add --as-needed in
> /usr/lib/rpm/redhat/redhat-hardened-ld spec file by apply patch:
>
> --- /usr/lib/rpm/redhat/redhat-hardened-ld.orig
> +++ /usr/lib/rpm/redhat/redhat-hardened-ld
> @@ -2,4 +2,4 @@
> + %{!static:%{!shared:%{!r:-pie}}}
>
> *link:
> -+ -z now
> ++ -z now --as-needed
Just created pull request with above change:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/3#request_diff
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: RFC: -Wl,--as-needed by default
On 13 November 2017 at 10:52, Björn 'besser82' Esser
wrote:
[..]
> that specific flag should be in LDFLAGS, but there are reasons, we do
> NOT have it in there, because it will likely break any binaries built
> from or containing FORTRAN sources. They will simply SEGFAULT, because
> `-Wl,--as-needed` causes some needed runtime libraries NOT being linked
> with them, because the linker thinks they are not needed / would over
> link.
If it is still any issue related to the Fortran it is nothing more
than just plain bug.
However AFAIK only reason of any issues related to use -Wl,--as-needed
is using WRONG list -l parameters (lack of some -l) and this
needs to be not treated by apply some workaround but but by apply
necessary fixes in -l linking parameters.
I've been personally involved in fixing many such problems in more
than last decade and I was one of the many similar people fixing
similar issues across many packages.
If it is still something left it will be IMO not more than few
packages in all Fedora packages.
In some packages using --as-needed will cause reduction of SONAME
dependencies by more than half!!!
In other words -Wl,--as-needed should be used everywhere WITHOUT exceptions.
Easiest way apply this globally in Fedora is add --as-needed in
/usr/lib/rpm/redhat/redhat-hardened-ld spec file by apply patch:
--- /usr/lib/rpm/redhat/redhat-hardened-ld.orig
+++ /usr/lib/rpm/redhat/redhat-hardened-ld
@@ -2,4 +2,4 @@
+ %{!static:%{!shared:%{!r:-pie}}}
*link:
-+ -z now
++ -z now --as-needed
BTW: many packages are fiddling with LDFLAGS adding redundantly
-Wl,-z,now. All those modifications can be now dropped.
As well all packages which already are injecting -Wl,--as-needed can be cleaned.
[tkloczko@domek SPECS.fedora]$ grep LDFLAGS *| grep -c -- --as-needed
150
[tkloczko@domek SPECS.fedora]$ grep LDFLAGS *| grep -c -- -z,now
106
On top of this IMO it would be good to add in binutils ld modification
which will be reporting all dropped during linking -l as a
warning
Such warnings could be used on keep clean build frameworks.
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
[Fedocal] Reminder meeting : Modularity WG (once every two weeks)
Dear all, You are kindly invited to the meeting: Modularity WG (once every two weeks) on 2017-11-14 from 10:00:00 to 11:00:00 US/Eastern At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Working Group. More information available at: [Modularity Working Group wiki page](https://fedoraproject.org/wiki/Modularity_Working_Group) The agenda for the meeting is available at [modularity-wg-agendas pad](https://board.net/p/modularity-wg-agendas). Source: https://apps.fedoraproject.org/calendar/meeting/5249/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Modular bikeshed compose report: changes
___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Heads-up] libical 3.0.0 to reach rawhide, replacing libical-glib
On 11/13/2017 06:04 AM, Milan Crha wrote: > On Mon, 2017-11-13 at 14:47 +0100, Michael Schwendt wrote: >> The upgrade seems to be API incompatible, so more than rebuilding >> dependencies is necessary. > > Hi, > that's true. libical upstream removed some deprecated symbols, most > notably icaltimetype::is_utc. It's replaced with icaltime_is_utc() > function (available for a long time) and instead of writing to > icaltimetype::is_utc one should set the timezone properly, thus when it > had been set to 1 the icaltimetype::zone should be > icaltimezone_get_utc_timezone(), when set to 0, then to something else. > >> Claws Mail doesn't rebuild. > > I do not see that failed build in koji, do you have a build log from > there, please? I can help with patches, as I already did with > kdepimlibs (a bug filled, patch attached). I do not have commit rights > for all those still failing packages, thus my help ability is slightly > limited. Orage (the Xfce calendar app) is also broken if you have time to take a look: https://bugzilla.redhat.com/show_bug.cgi?id=1512302 https://bugzilla.xfce.org/show_bug.cgi?id=13997 kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora-Modular 27-20171113.n.1 compose check report
Missing expected images: Docker_base docker x86_64 Server dvd arm Failed openQA tests: 21/94 (x86_64), 5/19 (i386) New failures (same test did not fail in 27-20171113.n.0): ID: 169764 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/169764 ID: 169812 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/169812 ID: 169841 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/169841 ID: 169858 Test: i386 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/169858 Old failures (same test failed in 27-20171113.n.0): ID: 169762 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/169762 ID: 169776 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/169776 ID: 169782 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/169782 ID: 169784 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/169784 ID: 169789 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/169789 ID: 169790 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/169790 ID: 169826 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/169826 ID: 169827 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/169827 ID: 169828 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/169828 ID: 169829 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/169829 ID: 169831 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/169831 ID: 169832 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/169832 ID: 169833 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/169833 ID: 169842 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/169842 ID: 169843 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/169843 ID: 169844 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/169844 ID: 169848 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/169848 ID: 169849 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/169849 ID: 169854 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/169854 ID: 169867 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/169867 ID: 169868 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/169868 ID: 169871 Test: i386 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/169871 Soft failed openQA tests: 2/94 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in 27-20171113.n.0): ID: 169774 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/169774 ID: 169779 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/169779 Passed openQA tests: 65/94 (x86_64), 14/19 (i386) Installed system changes in test i386 Server-dvd-iso install_default: System load changed from 0.05 to 0.35 Previous test data: https://openqa.fedoraproject.org/tests/169458#downloads Current test data: https://openqa.fedoraproject.org/tests/169783#downloads Installed system changes in test x86_64 universal install_package_set_minimal: System load changed from 0.22 to 0.11 Previous test data: https://openqa.fedoraproject.org/tests/169470#downloads Current test data: https://openqa.fedoraproject.org/tests/169795#downloads Installed system changes in test x86_64 universal install_package_set_kde: System load changed from 0.05 to 0.18 Previous test data: https://openqa.fedoraproject.org/tests/169511#downloads Current test data: https://openqa.fedoraproject.org/tests/169836#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: american-fuzzy-lop contains exploit samples which trigger ClamAV
On Mon, Nov 13, 2017 at 02:44:14PM +, Sérgio Basto wrote:
> On Mon, 2017-11-13 at 14:25 +, Richard W.M. Jones wrote:
> > (Thanks to Patrick for bringing this issue to my attention.)
> >
> > American Fuzzy Lop ("afl", Fedora package american-fuzzy-lop) is an
> > instrumentation-driven fuzzer for binary formats. ClamAV is a
> > (Windows?) virus scanner.
> >
> > Afl's documentation comes with some demonstration vulerabilities
> > found
> > by afl. These are shipped in the source tarball and SRPM and also
> > installed as a %doc section in the binary
> > (/usr/share/doc/american-fuzzy-lop/vuln_samples/).
> >
> > Unfortunately some of these samples trigger ClamAV
> > "Win.Exploit.CVE_2015_0076-1 FOUND".
> >
> > In this particular case it appears to be one or more of these files:
> >
> > jxrlib-crash2.jxr
> > jxrlib-crash3.jxr
> > jxrlib-crash4.jxr
> > jxrlib-crash.jxr
> > msie-jxr-mem-leak.jxr
> >
> > which contain a badly formatted JPEG XR file that triggered a mild
> > CVE
> > in Windows:
> >
> > https://technet.microsoft.com/en-us/library/security/ms15-029.aspx
> >
> > (so this is not a false positive or over-active virus scanner).
> >
> > I'm inclined to ignore this and point people to this posting if there
> > are any bugs filed. But maybe there is some Fedora policy which
> > applies here?
>
> I'm the clamav packager maintainer is anything related with this 2
> CVE(s) [1] ?
No I don't think so. It's not an exploit in ClamAV, it's an exploit
in Windows that ClamAV is identifying (correctly).
Rich.
> I was waiting for a new stable release .
>
> Thanks,
>
> [1]
> https://bugzilla.redhat.com/show_bug.cgi?id=1483911
> https://bugzilla.redhat.com/show_bug.cgi?id=1472778
>
> > Rich.
> >
> > --
> > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com
> > /~rjones
> > Read my programming and virtualization blog: http://rwmj.wordpress.co
> > m
> > 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
> --
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
--
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
Armadillo soname bump heads-up
Hello there, I plan to upgrade the armadillo package (armadillo, armadillo-devel) to its latest version in EPEL6/EPEL7/F27/rawhide, which incurs a soname bump. There are only three dependent packages: gdal mlpack mmseq I will be working with a provenpackager (Mukundan) in order to rebuild the affected downstream packages. We've already made a COPR for testing: https://copr.fedorainfracloud.org/coprs/rcurtin/arma-epel6/ This is related to the SuperLU soname bump recently: https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/message/A44NWTRWSMIB6OGAEV57JKWQ2HZMXMYZ/ Please let me know if there are any problems. Otherwise we will get started in the next few days. Thanks, Ryan -- Ryan Curtin| "I just ran out of it, you see." r...@ratml.org | - Howard Beale ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Tagging large packages (texlive) takes a very long time
On 11/13/2017 01:02 AM, Richard W.M. Jones wrote: > It looks as if the texlive saga continues! > > https://koji.fedoraproject.org/koji/taskinfo?taskID=23085154 > > Started yesterday evening and still going 15 hours later. > It has picked an armv7 host this time. I canceled and started a new one. It wasn't done this morning, and we looked and it turns out we are hitting a bug in koji where it's seeing duplicate NVR's for some subpackages from the partially imported build, but not failing correctly. Kalev has started a new one with subpackages bumped properly. We have hopes for this build. ;) kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Modular 27 compose report: 20171113.n.1 changes
OLD: Fedora-Modular-27-20171113.n.0 NEW: Fedora-Modular-27-20171113.n.1 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0.00 B Size of dropped packages:0.00 B Size of upgraded packages: 0.00 B Size of downgraded packages: 0.00 B Size change of upgraded packages: 0.00 B Size change of downgraded packages: 0.00 B = ADDED IMAGES = = DROPPED IMAGES = Image: Container_Base docker armhfp Path: Server/armhfp/images/Fedora-Modular-Container-Base-27_Modular-20171113.n.0.armhfp.tar.xz = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: american-fuzzy-lop contains exploit samples which trigger ClamAV
On Mon, 2017-11-13 at 14:25 +, Richard W.M. Jones wrote:
> (Thanks to Patrick for bringing this issue to my attention.)
>
> American Fuzzy Lop ("afl", Fedora package american-fuzzy-lop) is an
> instrumentation-driven fuzzer for binary formats. ClamAV is a
> (Windows?) virus scanner.
>
> Afl's documentation comes with some demonstration vulerabilities
> found
> by afl. These are shipped in the source tarball and SRPM and also
> installed as a %doc section in the binary
> (/usr/share/doc/american-fuzzy-lop/vuln_samples/).
>
> Unfortunately some of these samples trigger ClamAV
> "Win.Exploit.CVE_2015_0076-1 FOUND".
>
> In this particular case it appears to be one or more of these files:
>
> jxrlib-crash2.jxr
> jxrlib-crash3.jxr
> jxrlib-crash4.jxr
> jxrlib-crash.jxr
> msie-jxr-mem-leak.jxr
>
> which contain a badly formatted JPEG XR file that triggered a mild
> CVE
> in Windows:
>
> https://technet.microsoft.com/en-us/library/security/ms15-029.aspx
>
> (so this is not a false positive or over-active virus scanner).
>
> I'm inclined to ignore this and point people to this posting if there
> are any bugs filed. But maybe there is some Fedora policy which
> applies here?
I'm the clamav packager maintainer is anything related with this 2
CVE(s) [1] ?
I was waiting for a new stable release .
Thanks,
[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1483911
https://bugzilla.redhat.com/show_bug.cgi?id=1472778
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com
> /~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.co
> m
> 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
--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
american-fuzzy-lop contains exploit samples which trigger ClamAV
(Thanks to Patrick for bringing this issue to my attention.)
American Fuzzy Lop ("afl", Fedora package american-fuzzy-lop) is an
instrumentation-driven fuzzer for binary formats. ClamAV is a
(Windows?) virus scanner.
Afl's documentation comes with some demonstration vulerabilities found
by afl. These are shipped in the source tarball and SRPM and also
installed as a %doc section in the binary
(/usr/share/doc/american-fuzzy-lop/vuln_samples/).
Unfortunately some of these samples trigger ClamAV
"Win.Exploit.CVE_2015_0076-1 FOUND".
In this particular case it appears to be one or more of these files:
jxrlib-crash2.jxr
jxrlib-crash3.jxr
jxrlib-crash4.jxr
jxrlib-crash.jxr
msie-jxr-mem-leak.jxr
which contain a badly formatted JPEG XR file that triggered a mild CVE
in Windows:
https://technet.microsoft.com/en-us/library/security/ms15-029.aspx
(so this is not a false positive or over-active virus scanner).
I'm inclined to ignore this and point people to this posting if there
are any bugs filed. But maybe there is some Fedora policy which
applies here?
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: [Heads-up] libical 3.0.0 to reach rawhide, replacing libical-glib
On Mon, 2017-11-13 at 14:47 +0100, Michael Schwendt wrote: > The upgrade seems to be API incompatible, so more than rebuilding > dependencies is necessary. Hi, that's true. libical upstream removed some deprecated symbols, most notably icaltimetype::is_utc. It's replaced with icaltime_is_utc() function (available for a long time) and instead of writing to icaltimetype::is_utc one should set the timezone properly, thus when it had been set to 1 the icaltimetype::zone should be icaltimezone_get_utc_timezone(), when set to 0, then to something else. > Claws Mail doesn't rebuild. I do not see that failed build in koji, do you have a build log from there, please? I can help with patches, as I already did with kdepimlibs (a bug filled, patch attached). I do not have commit rights for all those still failing packages, thus my help ability is slightly limited. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20171113.n.0 compose check report
Missing expected images: Server dvd i386 Workstation live i386 Server boot i386 Kde live i386 Failed openQA tests: 21/128 (x86_64), 1/2 (arm) New failures (same test did not fail in Rawhide-20171112.n.0): ID: 169607 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/169607 ID: 169718 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/169718 Old failures (same test failed in Rawhide-20171112.n.0): ID: 169608 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/169608 ID: 169614 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/169614 ID: 169615 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/169615 ID: 169616 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/169616 ID: 169618 Test: x86_64 Workstation-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/169618 ID: 169627 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/169627 ID: 169630 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/169630 ID: 169643 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/169643 ID: 169644 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/169644 ID: 169690 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/169690 ID: 169691 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/169691 ID: 169692 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/169692 ID: 169693 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/169693 ID: 169695 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/169695 ID: 169696 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/169696 ID: 169697 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/169697 ID: 169708 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/169708 ID: 169712 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/169712 ID: 169713 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/169713 ID: 169714 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/169714 Soft failed openQA tests: 4/128 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test did not soft fail in Rawhide-20171112.n.0): ID: 169633 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/169633 Old soft failures (same test soft failed in Rawhide-20171112.n.0): ID: 169632 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/169632 ID: 169706 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/169706 ID: 169707 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/169707 Passed openQA tests: 90/128 (x86_64) New passes (same test did not pass in Rawhide-20171112.n.0): ID: 169631 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/169631 Skipped openQA tests: 11 of 130 Installed system changes in test x86_64 Server-boot-iso install_default@uefi: System load changed from 0.27 to 0.13 Previous test data: https://openqa.fedoraproject.org/tests/169192#downloads Current test data: https://openqa.fedoraproject.org/tests/169590#downloads Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: System load changed from 0.20 to 0.06 Previous test data: https://openqa.fedoraproject.org/tests/169196#downloads Current test data: https://openqa.fedoraproject.org/tests/169594#downloads Installed system changes in test x86_64 Everything-boot-iso install_default@uefi: System load changed from 0.01 to 0.18 Previous test data: https://openqa.fedoraproject.org/tests/169214#downloads Current test data: https://openqa.fedoraproject.org/tests/169612#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 1 services(s) removed since previous compose: dnfdaemon.service System load changed from 0.84 to 1.09 Previous test data: https://openqa.fedoraproject.org/tests/169234#downloads Current test data: https://openqa.fedoraproject.org/test
Re: herbstluftwm
each wm for its own good no wonder such a variety of window managers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Heads-up] libical 3.0.0 to reach rawhide, replacing libical-glib
On Wed, 01 Nov 2017 12:26:12 +0100, Milan Crha wrote: > Hello, > I'd like to give a heads up about a plan to update libical to its 3.0.0 > release in rawhide once I figure out some details about its build. This > release also obsoletes libical-glib package, the project had been added > into libical itself. > > I currently plan to push the update on Monday, November 6th. The upgrade seems to be API incompatible, so more than rebuilding dependencies is necessary. Claws Mail doesn't rebuild. And since texlive is waiting for a rebuild due to poppler SONAME breakage, temporarily one would need to set %build_manual to 0 in claws-mail.spec file. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: -Wl,--as-needed by default
On Mon, Nov 13, 2017 at 7:21 AM, Michael Catanzaro wrote: > On Mon, Nov 13, 2017 at 5:06 AM, Daniel P. Berrange > wrote: >> >> What % of our distro involves fortran though ? Could this be as simple as >> enabling it by default, but having an easy way via an RPM macro to opt-out >> of it in the handleful of packages that matter wrt fortran. > > > If Debian/Ubuntu/openSUSE (didn't know about openSUSE) can all handle it, > I'm sure Fedora can find a way. > > I'll just add: it's pretty annoying that, right now, when I touch linker > flags, there's no easy way to know if my application will link or not on > other distros, because Fedora is more permissive. > In Mageia, we have probably some of the strictest linker flags of all the distributions (that I know of). Many applications that build or link fine in Fedora need fixing in Mageia because we don't permit underlinking[1] or overlinking[2], and we apply several fixers in configure and brp scripts. We've also designed our flags setup so that you can set a macro to override as needed, so for things like FORTRAN, you can change this easily. I'd like to see these make their way into Fedora. [1]: https://wiki.mageia.org/en/Underlinking_issues_in_packaging [2]: https://wiki.mageia.org/en/Overlinking_issues_in_packaging -- 真実はいつも一つ！/ 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: RFC: -Wl,--as-needed by default
On Mon, Nov 13, 2017 at 5:06 AM, Daniel P. Berrange wrote: What % of our distro involves fortran though ? Could this be as simple as enabling it by default, but having an easy way via an RPM macro to opt-out of it in the handleful of packages that matter wrt fortran. If Debian/Ubuntu/openSUSE (didn't know about openSUSE) can all handle it, I'm sure Fedora can find a way. I'll just add: it's pretty annoying that, right now, when I touch linker flags, there's no easy way to know if my application will link or not on other distros, because Fedora is more permissive. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: -Wl,--as-needed by default
On Mon, Nov 13, 2017 at 11:52:14AM +0100, Björn 'besser82' Esser wrote: > Am Montag, den 13.11.2017, 11:02 +0100 schrieb Igor Gnatenko: > > Hello, > > > > I'm interested why we still don't have this flag in our CFLAGS? It > > seems that > > other distributions like openSUSE enable it by default and it helps > > in many > > cases to avoid over-linking (for example, see thread about poppler). > > > > Are there any reasons not to add it? > > > Hello Igor, > > that specific flag should be in LDFLAGS, but there are reasons, we do > NOT have it in there, because it will likely break any binaries built > from or containing FORTRAN sources. They will simply SEGFAULT, because > `-Wl,--as-needed` causes some needed runtime libraries NOT being linked > with them, because the linker thinks they are not needed / would over > link. What % of our distro involves fortran though ? Could this be as simple as enabling it by default, but having an easy way via an RPM macro to opt-out of it in the handleful of packages that matter wrt fortran. 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: 'texlive-pdftex-bin' broken dependencies
On Mon, Nov 13, 2017 at 10:45:53AM +0100, Antonio Trande wrote: > Hi all. > > This broken dependency is on rawhide since three days at least: > > > nothing provides libpoppler.so.71()(64bit) needed by texlive-xetex- > > bin-6:svn41091-36.20160520.fc28.7.x86_64 > > Root log: > https://koji.fedoraproject.org/koji/getfile?taskID=23096680&volume=DEFAULT&name=root.log Since Thursday morning last week actually. See this thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UD34J2SBTEZJS66RBH7BD6JNR26EMAIZ/#BU3EO3CBEKOUGZAHRT7LYMAM4QV6KCJF Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: -Wl,--as-needed by default
Am Montag, den 13.11.2017, 11:02 +0100 schrieb Igor Gnatenko: > Hello, > > I'm interested why we still don't have this flag in our CFLAGS? It > seems that > other distributions like openSUSE enable it by default and it helps > in many > cases to avoid over-linking (for example, see thread about poppler). > > Are there any reasons not to add it? Hello Igor, that specific flag should be in LDFLAGS, but there are reasons, we do NOT have it in there, because it will likely break any binaries built from or containing FORTRAN sources. They will simply SEGFAULT, because `-Wl,--as-needed` causes some needed runtime libraries NOT being linked with them, because the linker thinks they are not needed / would over link. Cheers, Björn signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: herbstluftwm
On 11/11/17, mastaiza wrote: > somebody take this beautiful wm Last time I updated this package, it said will remain inactive. Notwithstanding now I can see a higher version available now. -- Yours sincerely, Christopher Meng http://awk.io ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changes Policy & Fedora Release Life Cycle - request for review
Dne 10.11.2017 v 18:18 Matthew Miller napsal(a): > On Fri, Nov 10, 2017 at 05:27:25PM +0100, Jan Kurik wrote: >> [1] https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle > Do we really want to have a window after branch where > Bodhi isn't active? Bit of OT, but I'd appreciate if Bodhi was enabled even for Rawhide ;) (Sorry, couldn't help myself) > > > And, on a even bigger note, the F27 July-to-October experiment worked > reasonably well (with the large remainer of the still-outstanding > Modular Server) but I don't think we want to do that again. I'd like to > suggest that if the April/May release slips into July, or the > October/November release slips into January, we *automatically* skip > the next target date for a _longer_ cycle to bring us back to schedule > rather than a short one. > > I like this idea. V. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
RFC: -Wl,--as-needed by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, I'm interested why we still don't have this flag in our CFLAGS? It seems that other distributions like openSUSE enable it by default and it helps in many cases to avoid over-linking (for example, see thread about poppler). Are there any reasons not to add it? - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAloJbcoACgkQaVcUvRu8 X0wsARAAgAY3UQGZyTnsyJiqgO0e5YTXN3FmFaZLQD1hFl7s7vtCVVOzOWTnKpP7 eamxRbr9qAr94yvULDejqAgbyWeqeKXLIayakengZuvN1StBA9cPn2DOk5pP2pJj MpBBwYrpr+WuQx4zOO6ZMWUNvyCJGoqp7wP6DsflkWQ+Phy0LXS06Sze6JFK75fv Fyzv+csyNLb/E9D571vHdGTnKPU4v4xYQFUAioQiB1ZKHjaeCv/oXCIoLNpaKd8+ uufD6byzczu+lvjAO2KdF8tJScF2s3cPJVvTQ8LbFerC8Hj4BXLlg2kGvbxodknl BMSlFj+A+RXkbAqw+uq6YXa9/a+c4L/rA+RBpQehhMe/70upCwutAMoT/xjPkCAm hfD3YHML/XDE7zsPLAwzipLpO9sgFJO/ZTOWsktfIxX+C5qGPQggvnRPFw81PwlG w2AFknmIAhhCOOiD73qpnB6HcJ3w9YMr/OD8R/TFiWvfy8RUBOnoJ9PreThKS0YD Xs7YM8kgTld2MOfUjNix0Q+W7yQ7NocUMmBIZdbb9EU/KltYWXoYtuuAQtshdSaa +Qdfz4jmOFJIn6rn7xQIz5PaHyMDCW4cD+9+Ix3efDYY8CtNZ4wlW12u0jgWq/xj /aZPlJSN93YoM8Y/7s2OwVnj6AQNexmGhL6Zk6XU245arU8Qbx0= =1/es -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Using devtoolset for EPEL builds
On Fri, Oct 21, 2016 at 12:01 AM, Peter Robinson wrote: >>> I need/want/would like to build new node 6 for EL6, but gcc is too old. >>> For that reason, I'd like to use devtoolset-4-gcc, but the build fails >>> (obviously) because the package doesn't exist. >>> >>> So, is there a way to make that work somehow? >>> I am not sure about enabling external repos during build, maybe someone >>> will be wiser. >> >> >> This has already been discussed several times: >> https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/message/KSEYFHCLVPK6DZBDOOPMK46AO65V2SM2/ >> https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/message/7HWJYGXFOMEROUYY2TQKZLKC2MSAAA7R/ >> https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/message/YQLNZYT5ATELGMHNGET7QCOG3S3UIYT5/ >> >> There are some potential roadblocks, but it comes down to someone writing up >> an official proposal and going through the full approval process. > > So one of the major blockers for me for WRT to using DTS in builds it > that it is currently x86_64 only but with the next release, (DTS 6.0) > it will support all the RHEL architectures [1] which certainly make it > easier to support across platforms. We obviously don't want to deal > with it prior to GA and I have no idea when the intended GA is it's > certainly worth discussing further now as to what are the > requirements, advantages, potential issues etc. I think this is now worth revisiting, at least for EL7, now DTS is out and supports key architectures. Thoughts? https://developers.redhat.com/blog/2017/10/25/announcing-release-software-collections-developer-toolset-new-compilers/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HEADS UP] protobuf 3.4.1 is coming
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, I'm going to build protobuf 3.4.1 in Rawhide later today and rebuild all dependent packages. There are no incompatible changes as I can see. Just sending heads-up. - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAloJbN4ACgkQaVcUvRu8 X0wRwBAAwkj8erGMEUeuWUsUgwAsSGkbTfMYZ1XOkQoQKbDdkitMAgZKx5j0v4hj h8B6l6FKF1qtZ4dIUWUUcr8oR4ziRH1B3W5/yB+EyyMon+Ul7sBynomictXWdO5/ wJMSOECG1ZQ2q5cYNRrLL4EjHi4QT9lLElgUDhp6XGz7186wyuh2kzn7p4Sy/UCG d9C/gmi5zv6uBDJJE2lwLFAgnn/174AgmShwCoxoP+G7bn/6e+l/MHMt9tyXgdiF +tYAgcdslrNK6afRaDjkLrxpzHuYXnJHqyRAwvrGnHdojLsO4iMjUcJKMZxjLLsv BeRL7H6hJeRbDNUg/Fti7hm1XoYQKl3Ofheo9p9fQAPESpXDAd958X4VpCtBwaIV irQm7S6mCtR8pFvJEg9rK6l6PCMV0IOhnZtNrqvfNf8QuNTmxMNL1Gg5qcsBUR4D EcA3q5rysdV4HklfyrlaLDojmMo4kP3gSm2oYIPZ3CgV6xi0Wc7mVsCzya9PRh5/ 9gVrhsbFJw6U/ny7UHxb/QbjDHuv9jLQ6n43+NvOBsMMPZHwB/71xi/Ez/3gLPSn +7TIbEJGADebBuh8/Eu26EcqT1UB/SapyB2wRjjzggkI/38oAFaJzOoJrRDIkecm vHti5Ub1jlBH5upQncSJfjmaa40IrxpXPjfKe19l3UEbs2Fe7JM= =5sfQ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
'texlive-pdftex-bin' broken dependencies
Hi all. This broken dependency is on rawhide since three days at least: > nothing provides libpoppler.so.71()(64bit) needed by texlive-xetex- > bin-6:svn41091-36.20160520.fc28.7.x86_64 Root log: https://koji.fedoraproject.org/koji/getfile?taskID=23096680&volume=DEFAULT&name=root.log -- -- Antonio Trande sagitter AT fedoraproject dot org See my vCard. <> signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Tagging large packages (texlive) takes a very long time
It looks as if the texlive saga continues! https://koji.fedoraproject.org/koji/taskinfo?taskID=23085154 Started yesterday evening and still going 15 hours later. It has picked an armv7 host this time. 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
