F28: Mismatch between the program and library build versions detected, gcc-c++, wxGTK3

[Wolfgang Stoeggl]

Hello,
a recent F28 update build of poedit [1] shows the following message after 
starting:

Warning: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1012,wx 
containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1013,wx 
containers,compatible with 2.8).

Additional info:
poedit-2.1-1.fc28 has been built using gcc-c++ 8.1.1-5.fc28
wxGTK3-3.0.4-1.fc28 has been built using gcc-c++ 8.0.1-0.16.fc28

The above message disappears, when wxGTK3 is rebuilt using current gcc-c++ 
8.1.1-5.fc28, which has just been tested using a rebuild of wxGTK3 on copr [2].

However, there are several other packages depending on wxGTK3 and it looks like 
this ABI mismatch issue in F28 needs some coordination to be solved for wxGTK3 
and dependent packages.

Best regards
Wolfgang

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2018-c9997803a6
[2] https://copr.fedorainfracloud.org/coprs/c72578/wxGTK3/build/780540/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WOOGIEVDBGDLQ2S5BZEE4AC4LBC7IL7M/

[Guidelines change] Changes to the packaging guidelines

[Jason L Tibbitts III]

Here are the recent changes to the packaging guidelines.

-

The packaging guidelines for enabling services by default were
significantly revised to emphasize that services starting by default
should fail only in exceptional conditions, and to provide additional
guidance for services related to hardware enablement.
 
 * https://fedoraproject.org/wiki/Packaging:DefaultServices
 * https://pagure.io/packaging-committee/issue/777

-

The Python guidelines were modified to mention the %pypi_source macro
(available in all Fedora and EPEL releases) which conveniently expands
to the proper source URL for the package at PyPi.

 * https://fedoraproject.org/wiki/Packaging:Python#Source_Files_from_PyPI
 * https://pagure.io/packaging-committee/issue/759

-

The Python guidelines were modified to indicate that packages must not
own the top-level __pycache__ directory.

 * https://fedoraproject.org/wiki/Packaging:Python#Byte_compiling
 * https://pagure.io/packaging-committee/issue/782

-

A small change was made to the Java packaging guidelines to specify a
dependency on javapackages-filesystem instead of javapackages-tools.

 * https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires
 * https://pagure.io/packaging-committee/issue/781
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/HP4LRC2RJNMOMXITZZYJ6FLF2RITY6H6/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HP4LRC2RJNMOMXITZZYJ6FLF2RITY6H6/

Reminder: Fedora 29 self-contained change deadline

[Ben Cotton]

Hello everyone,

This is your reminder that the deadline for self-contained changes is
24 July 2018. The full Fedora 29 schedule is available at
https://fedoraproject.org/wiki/Releases/29/Schedule

Changes not marked with the "ChangeReadyForWrangler" category by the
deadline will be moved to Fedora 30.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/SQLY7ZJKFMKGV22SAYBANRPH6KPUHUJF/

[Guidelines change] Changes to the packaging guidelines

[Jason L Tibbitts III]

Here are the recent changes to the packaging guidelines.

-

The packaging guidelines for enabling services by default were
significantly revised to emphasize that services starting by default
should fail only in exceptional conditions, and to provide additional
guidance for services related to hardware enablement.
 
 * https://fedoraproject.org/wiki/Packaging:DefaultServices
 * https://pagure.io/packaging-committee/issue/777

-

The Python guidelines were modified to mention the %pypi_source macro
(available in all Fedora and EPEL releases) which conveniently expands
to the proper source URL for the package at PyPi.

 * https://fedoraproject.org/wiki/Packaging:Python#Source_Files_from_PyPI
 * https://pagure.io/packaging-committee/issue/759

-

The Python guidelines were modified to indicate that packages must not
own the top-level __pycache__ directory.

 * https://fedoraproject.org/wiki/Packaging:Python#Byte_compiling
 * https://pagure.io/packaging-committee/issue/782

-

A small change was made to the Java packaging guidelines to specify a
dependency on javapackages-filesystem instead of javapackages-tools.

 * https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires
 * https://pagure.io/packaging-committee/issue/781
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/HP4LRC2RJNMOMXITZZYJ6FLF2RITY6H6/

Re: Unannounced soname bump (Rawhide): net-snmp (libnetsnmp.so.30 -> libnetsnmp.so.35)

[Adam Williamson]

On Tue, 2018-07-24 at 13:49 -0700, Adam Williamson wrote:
> net-snmp was updated from 5.7.3-41 to 5.8-1 in Rawhide on 2018-07-20.
> This update bumped the soname of libnetsnmp (in the net-snmp-libs
> subpackage) from libnetsnmp.so.30 to libnetsnmp.so.35.
> This soname bump was not announced, as it is supposed to be.
> 
> This library has many dependencies, and from a quick survey, few or
> none of them appears to have been rebuilt. Here's the list of all
> packages depending on libnetsnmp.so.30 from the current compose:
> 
> OpenIPMI-0:2.0.25-6.fc29.x86_64
> collectd-snmp-0:5.8.0-14.fc29.x86_64
> corosync-0:2.99.3-1.fc29.x86_64
> cyrus-imapd-0:3.0.7-8.fc29.x86_64
> foghorn-0:0.1.6-20.fc29.x86_64
> ifstat-0:1.1-27.fc29.x86_64
> keepalived-0:2.0.5-2.fc29.x86_64
> lldpd-0:1.0.1-2.fc29.x86_64
> mbrowse-0:0.4.3-17.fc29.x86_64
> nagios-plugins-snmp-disk-proc-0:1.3.1-7.fc29.x86_64
> ntop-0:5.0.1-15.fc28.x86_64
> nut-0:2.7.4-18.fc29.x86_64
> openhpi-0:3.8.0-3.fc29.x86_64
> openhpi-libs-0:3.8.0-3.fc29.x86_64
> openhpi-subagent-0:2.3.4-35.fc29.x86_64
> opensips-snmpstats-0:2.3.4-2.fc29.x86_64
> php-snmp-0:7.2.8-1.fc29.x86_64
> ptpd-0:2.3.1-12.235e9b4.fc29.x86_64
> quagga-0:1.2.2-4.fc29.x86_64
> rsyslog-snmp-0:8.36.0-1.fc29.x86_64
> tog-pegasus-libs-2:2.14.1-44.fc29.x86_64
> tog-pegasus-test-2:2.14.1-44.fc29.x86_64
> zabbix-proxy-mysql-0:3.0.16-1.fc29.x86_64
> zabbix-proxy-pgsql-0:3.0.16-1.fc29.x86_64
> zabbix-proxy-sqlite3-0:3.0.16-1.fc29.x86_64
> zabbix-server-mysql-0:3.0.16-1.fc29.x86_64
> zabbix-server-pgsql-0:3.0.16-1.fc29.x86_64
> 
> These and their dependencies are now all broken.
> 
> Once again, folks, *please* announce your soname bumps, and co-ordinate 
> rebuilds.

tibbs and I have now rebuilt most of the above (except ntop, which is
broken and which I don't care enough to fix). I also rebuilt the
remaining packages which needed rebuilding for the unannounced
libconfig soname bump.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y2GFRLXRYQ7EVROWQNPO6ZDJK6ETCOFM/

[Bug 1593318] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse () method

[bugzilla]

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

Jeff Fearn  changed:

   What|Removed |Added

 CC||jfe...@redhat.com



-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/JDBCNS74ZML7J2MFCLDAGBDUBXUM4O76/

[Bug 1605410] perl-Inline-Python: FTBFS in Fedora rawhide

[bugzilla]

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

Igor Gnatenko  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NEXTRELEASE
Last Closed||2018-07-24 18:39:28



--- Comment #5 from Igor Gnatenko  ---
There has been at least one successfull build after this bug got created.

perl-Inline-Python-0.56-6.fc29:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1118550

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/Z53YTBCGJUYTNK37F7VCIUOZDSDIOUE4/

Re: Intent to retire denyhosts

[Jason L Tibbitts III]

> "CA" == Chris Adams  writes:

CA> Just as an FYI: I'm not sure fail2ban supports that out of the box,
CA> but it is easy enough to:

True, but denyhosts has the concept of a central synchronization server
which can be shared by all installations globally.  The original
incarnation (by the original denyhosts developer) was not open source
but the current one (which I used to host) is completely free.

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

Re: Unannounced soname bump: libconfig

[Rex Dieter]

Fabio Valentini wrote:

> On Tue, Jul 24, 2018 at 9:06 PM Rex Dieter  wrote:
>>
>> Richard W.M. Jones wrote:
>>
>> >
>> > This build:
>> >
>> >   https://koji.fedoraproject.org/koji/buildinfo?buildID=1130189
>> >
>> > changed the soname from libconfig.so.9 to libconfig.so.11 thus
>> > breaking a number of packages.
>>
>> Hopefully this will help for posterity,
>> 
https://src.fedoraproject.org/rpms/libconfig/c/f8828aa23cf8f75ee4600b1f7f3dbf89390dabff?branch=master
> 
> Related to this week's regular unannounced soname bump:
> https://pagure.io/packaging-committee/issue/784
> You may want to weigh in and support my proposal to strongly
> discourage using globs in this case.

I'm not sure I can support this being a MUST (yet), SHOULD (aka best 
practice) at least is a step in the right direction.

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

/results_* and /*.rpm in .gitignore (was: Source tarballs are being placed in git?)

[Tim Landscheidt]

Todd Zullinger  wrote:

> […]

> For example, the rpmlint's .gitignore contains the
> following¹:

> /*.rpm
> /results_rpmlint/
> /rpmlint-*/
> /rpmlint-*.tar.gz

> […]

Apropos: Many .gitignores only reference the source files,
i. e. not /results_${name} or /${name}-*.rpm.  Therefore I
usually add the latter two to .git/info/exclude and I wonder
how others handle this.

Will fedpkg (and its backend) always create results_${name}
and ${name}-*.rpm in the top directory or is the destination
configurable?  If the former, it would make sense to add
them to .gitignore "for everybody", e. g. recommend that in
the Packaging Guidelines.  If not, I'd find it useful to
have "fedpkg clone" add them to the initial
.git/info/exclude.

Are there other approaches to have a clean "git status" dur-
ing "normal" packaging development, tests, etc.?

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

Unannounced soname bump (Rawhide): net-snmp (libnetsnmp.so.30 -> libnetsnmp.so.35)

[Adam Williamson]

net-snmp was updated from 5.7.3-41 to 5.8-1 in Rawhide on 2018-07-20.
This update bumped the soname of libnetsnmp (in the net-snmp-libs
subpackage) from libnetsnmp.so.30 to libnetsnmp.so.35.
This soname bump was not announced, as it is supposed to be.

This library has many dependencies, and from a quick survey, few or
none of them appears to have been rebuilt. Here's the list of all
packages depending on libnetsnmp.so.30 from the current compose:

OpenIPMI-0:2.0.25-6.fc29.x86_64
collectd-snmp-0:5.8.0-14.fc29.x86_64
corosync-0:2.99.3-1.fc29.x86_64
cyrus-imapd-0:3.0.7-8.fc29.x86_64
foghorn-0:0.1.6-20.fc29.x86_64
ifstat-0:1.1-27.fc29.x86_64
keepalived-0:2.0.5-2.fc29.x86_64
lldpd-0:1.0.1-2.fc29.x86_64
mbrowse-0:0.4.3-17.fc29.x86_64
nagios-plugins-snmp-disk-proc-0:1.3.1-7.fc29.x86_64
ntop-0:5.0.1-15.fc28.x86_64
nut-0:2.7.4-18.fc29.x86_64
openhpi-0:3.8.0-3.fc29.x86_64
openhpi-libs-0:3.8.0-3.fc29.x86_64
openhpi-subagent-0:2.3.4-35.fc29.x86_64
opensips-snmpstats-0:2.3.4-2.fc29.x86_64
php-snmp-0:7.2.8-1.fc29.x86_64
ptpd-0:2.3.1-12.235e9b4.fc29.x86_64
quagga-0:1.2.2-4.fc29.x86_64
rsyslog-snmp-0:8.36.0-1.fc29.x86_64
tog-pegasus-libs-2:2.14.1-44.fc29.x86_64
tog-pegasus-test-2:2.14.1-44.fc29.x86_64
zabbix-proxy-mysql-0:3.0.16-1.fc29.x86_64
zabbix-proxy-pgsql-0:3.0.16-1.fc29.x86_64
zabbix-proxy-sqlite3-0:3.0.16-1.fc29.x86_64
zabbix-server-mysql-0:3.0.16-1.fc29.x86_64
zabbix-server-pgsql-0:3.0.16-1.fc29.x86_64

These and their dependencies are now all broken.

Once again, folks, *please* announce your soname bumps, and co-ordinate 
rebuilds.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YB7ELNTQWV2NE42G2AE52EAXLVW7RM6U/

Re: Intent to retire denyhosts

[Chris Adams]

Once upon a time, Jason L Tibbitts III  said:
> In general, fail2ban is simply a far better choice.  The primary feature
> it appears to lack is the ability to synchronize lists of blocked hosts
> between machines.  (And I could be quite wrong about that.)

Just as an FYI: I'm not sure fail2ban supports that out of the box, but
it is easy enough to:

- set fail2ban to use syslog
- replicate the fail2ban "Ban" messages between hosts
- configure a fail2ban filter to match the Ban messages
- configure a fail2ban jail to react to 1 hit on the Ban messages

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

Intent to retire denyhosts

[Jason L Tibbitts III]

Denyhosts is a daemon which watches for failed ssh login attempts and
blocks them.  I have long maintained denyhosts in Fedora and while I did
not originally agree with it being branched to EPEL, I have done light
maintenance on EPEL7 as well.  The EPEL6 branch is, however, very old.

The upstream project is mostly moribund.  The software does not support
reading from the systemd journal; I spent some effort trying to make
that work but the core logic is very poorly suited to doing it properly.
It did sort of work but was never in an upstreamable state.

The software also primarily works by modifying /etc/hosts.deny, which
was rendered useless when tcp_wrappers support was removed from our
openssh packaging.  It can support iptables, but doesn't properly
support firewalld and in any case requires manual configuration to set
this up.

In general, fail2ban is simply a far better choice.  The primary feature
it appears to lack is the ability to synchronize lists of blocked hosts
between machines.  (And I could be quite wrong about that.)

My intent is to retire denyhosts in rawhide, EPEL7 and EPEL6 in a week,
but I will happily hand it over to someone who wishes to maintain it
properly moving forward.  I may even be willing to stay on as a
comaintainer in that case, at least for a bit.  If you do wish to take
over maintenance, there are a few open bugs and an update to 3.0 or
3.1beta (released in 2015) would probably be needed, as well as a switch
to python3.

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

Re: Source tarballs are being placed in git?

[Gerald B. Cox]

On Tue, Jul 24, 2018 at 10:07 AM, Artur Iwicki 
wrote:

> That section of the guide is a bit poorly worded. You should *not* use
> "git add" on source tarballs. These should be added only via means of
> "fedpkg new-sources $FILES; git add ./sources". I believe what the guide
> means under "new source files" is e.g. when upstream does not provide an
> icon or a .desktop or an .appdata.xml file (or a systemd .service or
> whatever) and you add your own. This does not include "new upstream release
> tarball".
>
> I'll try to think of some way to make that more clear and submit a
> suggestion to change the guide text.
>

Thanks for the clarification and taking the initiative to get it fixed.  As
far as "poorly worded", that's a candidate
for understatement of the day... LOL

It uses the exact same wording - "new source files" in both statements with
absolutely no differentiation:

- Stage any small patches or new source files for commit:
- Upload new source files to the lookaside cache:
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7P6XXOEE3KFBWLP2DPEIBNTVZ54CGPNJ/

Re: Unannounced soname bump: libconfig

[Fabio Valentini]

On Tue, Jul 24, 2018 at 9:06 PM Rex Dieter  wrote:
>
> Richard W.M. Jones wrote:
>
> >
> > This build:
> >
> >   https://koji.fedoraproject.org/koji/buildinfo?buildID=1130189
> >
> > changed the soname from libconfig.so.9 to libconfig.so.11 thus
> > breaking a number of packages.
>
> Hopefully this will help for posterity,
> https://src.fedoraproject.org/rpms/libconfig/c/f8828aa23cf8f75ee4600b1f7f3dbf89390dabff?branch=master

Related to this week's regular unannounced soname bump:
https://pagure.io/packaging-committee/issue/784
You may want to weigh in and support my proposal to strongly
discourage using globs in this case.

Fabio

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

Re: Source tarballs are being placed in git?

[Todd Zullinger]

Daniel P. Berrangé wrote:
> On Tue, Jul 24, 2018 at 01:32:45PM -0400, Todd Zullinger wrote:
>> Artur Iwicki wrote:
>>> That section of the guide is a bit poorly worded. You should *not* use "git 
>>> add" on source tarballs. These should be added only via means of "fedpkg 
>>> new-sources $FILES; git add ./sources". I believe what the guide means 
>>> under "new source files" is e.g. when upstream does not provide an icon or 
>>> a .desktop or an .appdata.xml file (or a systemd .service or whatever) and 
>>> you add your own. This does not include "new upstream release tarball".
>>> 
>>> I'll try to think of some way to make that more clear and submit a 
>>> suggestion to change the guide text.
>> 
>> Somewhat tangentially, it may be worth recommending that the
>> .gitignore be edited suitably for the project as one of the
>> first steps in maintainence.
>> 
>> By default 'fedpkg sources' will add the files being added
>> to the lookaside cache to the .gitignore, but it will never
>> remove older files, leading to an unnecessarily large
>> .gitignore file.
> 
> It probably isn't unreasonable to file an RFE against fedpkg to request
> more intelligent behaviour.  eg given a tarball filename in majority of
> cases it is likely quite straightforward to identify the base name
> eg match the filename against something like this
> 
>(\w+)-(\d+(\.\d+)*).(zip|tar.\w+|tgz)
> 
> And replace the 2nd part of the regex match with '*' to form the rule
> to add to the .gitignore file.

Yeah, perhaps someone will get bored and do that.  Years
ago, I submitted a patch to fedpkg/rpkg to have it resepct
the existing .gitignore, such that if you have a pattern
which matches the source being added, fedpkg won't add
another entry.

Another option would be to have fedpkg use the package N-V-R
to construct a gitignore entry and use that instead of the
filename if the filename matches the pattern.  I don't think
it would be too hard to generate a pattern using a regex
either, I just haven't been bothered enough to work on a
patch.

-- 
Todd
~~
I personally think we developed language because of our deep need to
complain.
-- Lily Tomlin



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

Re: Unannounced soname bump: libconfig

[Rex Dieter]

Richard W.M. Jones wrote:

> 
> This build:
> 
>   https://koji.fedoraproject.org/koji/buildinfo?buildID=1130189
> 
> changed the soname from libconfig.so.9 to libconfig.so.11 thus
> breaking a number of packages.

Hopefully this will help for posterity,
https://src.fedoraproject.org/rpms/libconfig/c/f8828aa23cf8f75ee4600b1f7f3dbf89390dabff?branch=master

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

Re: Source tarballs are being placed in git?

[Tomasz Torcz]

On Tue, Jul 24, 2018 at 07:06:49PM +0100, Daniel P. Berrangé wrote:
> On Tue, Jul 24, 2018 at 01:32:45PM -0400, Todd Zullinger wrote:
> > Artur Iwicki wrote:
> > > That section of the guide is a bit poorly worded. You should *not* use 
> > > "git add" on source tarballs. These should be added only via means of 
> > > "fedpkg new-sources $FILES; git add ./sources". I believe what the guide 
> > > means under "new source files" is e.g. when upstream does not provide an 
> > > icon or a .desktop or an .appdata.xml file (or a systemd .service or 
> > > whatever) and you add your own. This does not include "new upstream 
> > > release tarball".
> > > 
> > > I'll try to think of some way to make that more clear and submit a 
> > > suggestion to change the guide text.
> > 
> > Somewhat tangentially, it may be worth recommending that the
> > .gitignore be edited suitably for the project as one of the
> > first steps in maintainence.
> > 
> > By default 'fedpkg sources' will add the files being added
> > to the lookaside cache to the .gitignore, but it will never
> > remove older files, leading to an unnecessarily large
> > .gitignore file.
> 
> It probably isn't unreasonable to file an RFE against fedpkg to request
> more intelligent behaviour.  eg given a tarball filename in majority of
> cases it is likely quite straightforward to identify the base name
> eg match the filename against something like this
> 
>(\w+)-(\d+(\.\d+)*).(zip|tar.\w+|tgz)
> 
> And replace the 2nd part of the regex match with '*' to form the rule
> to add to the .gitignore file.

  Can't this be inferred from Sources: line? Just like rpmbuild does?

-- 
Tomasz TorczThere exists no separation between gods and men:
xmpp: zdzich...@chrome.pl   one blends softly casual into the other.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7HHH2OS2Y22MVE3UGLXGRUCDEHKUODNB/

Re: Intel's Clear Linux optimizations

[Chris Murphy]

On Mon, Jul 23, 2018 at 11:56 PM, Samuel Sieb  wrote:
> On 07/23/2018 10:04 PM, Chris Murphy wrote:
>>
>> Available Packages
>> kernel.src4.18.0-0.rc0.git10.1.fc28
>> pac23-High_Performance_Clear_LInux_kernel_for_Fedora
>
>
> This is what I get:
>
> # dnf list --all kernel
> Installed Packages
> kernel.x86_64 4.16.11-300.fc28
> @updates
> kernel.x86_64 4.17.4-200.fc28
> @updates-testing
> kernel.x86_64 4.17.7-200.fc28
> @updates
> Available Packages
> kernel.src4.18.0-0.rc0.git10.1.fc28
> pac23-High_Performance_Clear_LInux_kernel_for_Fedora
> kernel.x86_64 4.18.0-0.rc0.git10.1.fc28
> pac23-High_Performance_Clear_LInux_kernel_for_Fedora
>
> That last one is highlighted in blue.  The problem is that it seems to only
> show packages that would be an upgrade, even though "--all" should override
> that.  Try adding "--showduplicates", that gives me:
>
> # dnf list --all --showduplicates kernel
> Installed Packages
> kernel.x86_64 4.16.11-300.fc28
> @updates
> kernel.x86_64 4.17.4-200.fc28
> @updates-testing
> kernel.x86_64 4.17.7-200.fc28
> @updates
> Available Packages
> kernel.x86_64 4.16.3-301.fc28fedora
> kernel.x86_64 4.16.11-300.fc28
> @updates
> kernel.x86_64 4.17.4-200.fc28
> @updates-testing
> kernel.x86_64 4.17.7-200.fc28
> @updates
> kernel.x86_64 4.17.7-200.fc28updates
> kernel.src4.18.0-0.rc0.git10.1.fc28
> pac23-High_Performance_Clear_LInux_kernel_for_Fedora
> kernel.x86_64 4.18.0-0.rc0.git10.1.fc28
> pac23-High_Performance_Clear_LInux_kernel_for_Fedora
>
> Now it shows me the old one from the initial fedora release repo as well.


[chris@f28h ~]$ sudo dnf list --all --showduplicates kernel
[sudo] password for chris:
Last metadata expiration check: 0:39:32 ago on Tue 24 Jul 2018 11:21:48 AM MDT.
Installed Packages
kernel.x86_64 4.17.3-200.fc28   @@commandline
kernel.x86_64 4.17.4-200.fc28   @@commandline
kernel.x86_64 4.17.6-200.fc28   @@commandline
kernel.x86_64 4.17.7-200.fc28   @@commandline
kernel.x86_64 4.18.0-0.rc3.git1.1.fc29  @@commandline
kernel.x86_64 4.18.0-0.rc4.git2.1.fc29  @@commandline
kernel.x86_64 4.18.0-0.rc5.git1.1.fc29  @@commandline
Available Packages
kernel.x86_64 4.16.3-301.fc28   fedora
kernel.x86_64 4.17.3-200.fc28   @@commandline
kernel.x86_64 4.17.4-200.fc28   @@commandline
kernel.x86_64 4.17.6-200.fc28   @@commandline
kernel.x86_64 4.17.7-200.fc28   @@commandline
kernel.x86_64 4.17.7-200.fc28   updates
kernel.src4.18.0-0.rc0.git10.1.fc28
pac23-High_Performance_Clear_LInux_kernel_for_Fedora
kernel.x86_64 4.18.0-0.rc0.git10.1.fc28
pac23-High_Performance_Clear_LInux_kernel_for_Fedora
kernel.x86_64 4.18.0-0.rc3.git1.1.fc29  @@commandline
kernel.x86_64 4.18.0-0.rc4.git2.1.fc29  @@commandline
kernel.x86_64 4.18.0-0.rc5.git1.1.fc29  @@commandline
[chris@f28h ~]$ sudo dnf install kernel-4.18.0-0.rc0.git10.1.fc28.x86_64
Last metadata expiration check: 0:42:59 ago on Tue 24 Jul 2018 11:21:48 AM MDT.
Dependencies resolved.

 Package
Arch   Version   Repository
Size

Installing:
 kernel x86_64 4.18.0-0.rc0.git10.1.fc28
pac23-High_Performance_Clear_LInux_kernel_for_Fedora  48 k
Installing dependencies:
 kernel-core
x86_64 4.18.0-0.rc0.git10.1.fc28
pac23-High_Performance_Clear_LInux_kernel_for_Fedora  26 M
 kernel-modules
x86_64 4.18.0-0.rc0.git10.1.fc28
pac23-High_Performance_Clear_LInux_kernel_for_Fedora  29 M

Transaction Summary

Install  3 Packages

Total download size: 54 M
Installed size: 91 M
Is this ok [y/N]:


OK so it has to be explicitly named. I'm not sure what happens if
there ends up being a name conflict with two enabled repos though, I
guess I'd have to disablerepo for updates and u-t to force it to use
the one in the copr.


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

Re: Source tarballs are being placed in git?

[Daniel P . Berrangé]

On Tue, Jul 24, 2018 at 01:32:45PM -0400, Todd Zullinger wrote:
> Artur Iwicki wrote:
> > That section of the guide is a bit poorly worded. You should *not* use "git 
> > add" on source tarballs. These should be added only via means of "fedpkg 
> > new-sources $FILES; git add ./sources". I believe what the guide means 
> > under "new source files" is e.g. when upstream does not provide an icon or 
> > a .desktop or an .appdata.xml file (or a systemd .service or whatever) and 
> > you add your own. This does not include "new upstream release tarball".
> > 
> > I'll try to think of some way to make that more clear and submit a 
> > suggestion to change the guide text.
> 
> Somewhat tangentially, it may be worth recommending that the
> .gitignore be edited suitably for the project as one of the
> first steps in maintainence.
> 
> By default 'fedpkg sources' will add the files being added
> to the lookaside cache to the .gitignore, but it will never
> remove older files, leading to an unnecessarily large
> .gitignore file.

It probably isn't unreasonable to file an RFE against fedpkg to request
more intelligent behaviour.  eg given a tarball filename in majority of
cases it is likely quite straightforward to identify the base name
eg match the filename against something like this

   (\w+)-(\d+(\.\d+)*).(zip|tar.\w+|tgz)

And replace the 2nd part of the regex match with '*' to form the rule
to add to the .gitignore file.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LHUKHTQ2WD42WKGODDFRTSUGRIOBQ7TL/

Re: Source tarballs are being placed in git?

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 24, 2018 at 05:07:50PM -, Artur Iwicki wrote:
> That section of the guide is a bit poorly worded. You should *not*
> use "git add" on source tarballs. These should be added only via
> means of "fedpkg new-sources $FILES; git add ./sources".

Actually "fedpkg new-sources" already does "git add" for you.
I consider this an anti-feature (it "break" 'git diff', making
'git diff HEAD' or such necessary), but anyway, calling
'git add sources' is not necessary.

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

Re: [HEADS UP] gcc/gcc-c++ removal from buildroot and more

[Kevin Fenzi]

On 07/23/2018 01:47 AM, Vít Ondruch wrote:

> 
> The question is not about Fedora comps, but about comps from the Koji
> repository:
> 
> https://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/
> 
> specifically:
> 
> https://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/repodata/db824c6dd6664943bcec0a8fcd3bda7fc855e5a787623c0da6d49deb79438fc7-comps.xml
> 
> Where are these coming from? How to fix them? I'd love to see the
> examples above to behave correctly, i.e. to not install gcc.

As you can see if you look it notes those are generated by koji.

koji has a 'groups' concept. It uses different groups for different
things. There's a srpm-build group that it uses when building the
initial src.rpm, there's a build group it uses for building, etc.

We had removed gcc/gcc-c++ from the f29-build tags groups, but not the
f29/rawhide tag. I have now done so, so this should hopefully be fixed
in a few here.

> 
> I opened releng ticket to track this: https://pagure.io/releng/issue/7649

Marked it fixed now. Thanks!

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 Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RXCL5SM753MDJL6DOCH2ID6HLL5QWL36/

Re: Source tarballs are being placed in git?

[Todd Zullinger]

Artur Iwicki wrote:
> That section of the guide is a bit poorly worded. You should *not* use "git 
> add" on source tarballs. These should be added only via means of "fedpkg 
> new-sources $FILES; git add ./sources". I believe what the guide means under 
> "new source files" is e.g. when upstream does not provide an icon or a 
> .desktop or an .appdata.xml file (or a systemd .service or whatever) and you 
> add your own. This does not include "new upstream release tarball".
> 
> I'll try to think of some way to make that more clear and submit a suggestion 
> to change the guide text.

Somewhat tangentially, it may be worth recommending that the
.gitignore be edited suitably for the project as one of the
first steps in maintainence.

By default 'fedpkg sources' will add the files being added
to the lookaside cache to the .gitignore, but it will never
remove older files, leading to an unnecessarily large
.gitignore file.

It's much more legible to use git's pattern matching
facilities to match the source files.

For example, the rpmlint's .gitignore contains the
following¹:

/*.rpm
/results_rpmlint/
/rpmlint-*/
/rpmlint-*.tar.gz

This keeps 'fedpkg source' from needing to add each new
tarball to the file.  More importantly, it makes it harder
to accidentally add a tarball to git.

The additional rules are convenient for ignoring other files
and directories which are often present in the work tree but
are never intended to tbe committed.

Refer to gitignore(5) for details on the pattern matching
rules.

¹ https://src.fedoraproject.org/rpms/rpmlint/blob/master/f/.gitignore

-- 
Todd
~~
If people are good only because they fear punishment, and hope for
reward, then we are a sorry lot indeed.
-- Albert Einstein



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

[Bug 1590332] Upgrade perl-Devel-CheckLib to 1.13

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Devel-CheckLib-1.13-1.
   ||fc28
 Resolution|--- |ERRATA
Last Closed||2018-07-24 13:29:04



--- Comment #3 from Fedora Update System  ---
perl-Devel-CheckLib-1.13-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/GVC5QN6OOHU6AB7273MCCF4WNNFBOGNI/

[Bug 1599722] perl-Test-mysqld-1.0011 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Test-mysqld-1.0012-1.fc28 has been pushed to the Fedora 28 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-bd9ce56f46

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/4JCWD2UQTMGUYUQHOSXM7N2VR3K5VR2V/

Fedora testing-20180724.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZLJDOFCYM7SCKGPFSYTRHVWPXUPMYBGI/

Fedora updates-20180724.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)

Installed system changes in test x86_64 AtomicHost-dvd_ostree-iso 
install_default: 
Filesystem for mount /sysroot changed from 
/dev/mapper/fedora--atomic_ibm--p8--kvm--03--guest--02-root to 
/dev/mapper/fedora_ibm--p8--kvm--03--guest--02-root
Previous test data: https://openqa.fedoraproject.org/tests/259817#downloads
Current test data: https://openqa.fedoraproject.org/tests/260029#downloads

Installed system changes in test x86_64 AtomicHost-dvd_ostree-iso 
install_default@uefi: 
Filesystem for mount /sysroot changed from 
/dev/mapper/fedora--atomic_ibm--p8--kvm--03--guest--02-root to 
/dev/mapper/fedora_ibm--p8--kvm--03--guest--02-root
Previous test data: https://openqa.fedoraproject.org/tests/259818#downloads
Current test data: https://openqa.fedoraproject.org/tests/260030#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LREC5Y7HZLWZDB7DWFQTQ6OEURFMUJ7K/

Re: [atomic-announce] Fedora Atomic Host Two Week Release Announcement: 28.20180722.0

[Sinny Kumari]

On Tue, Jul 24, 2018 at 9:42 PM,  wrote:

>
> A new Fedora Atomic Host update is available via an OSTree update:
>
> Version: 28.20180722.0
> Commit(x86_64): 106a7095fd46741948ba60dbd05866
> 68ae7abe6336671444ec790d7541a88778
> Commit(aarch64): e4cb87910b0729293453004293c1aa
> c3d676b8683f4147a6fb3975092b53810f
> Commit(ppc64le): 8f316b541744eafb126c06128e1af6
> 14f6ab5dccd72a8b722db4b0e295194115
>
>
> We are releasing images from multiple architectures but please note
> that x86_64 architecture is the only one that undergoes automated
> testing at this time.
>
> Existing systems can be upgraded in place via e.g. `atomic host upgrade`.
>
> Corresponding image media for new installations can be downloaded from:
>
> https://getfedora.org/en/atomic/download/
>
> Alternatively, image artifacts can be found at the following links:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/aarch64/images/Fedora-
> AtomicHost-28-20180723.0.aarch64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/aarch64/images/Fedora-
> AtomicHost-28-20180723.0.aarch64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/aarch64/iso/Fedora-AtomicHost
> -ostree-aarch64-28-20180723.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/ppc64le/images/Fedora-
> AtomicHost-28-20180723.0.ppc64le.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/ppc64le/images/Fedora-
> AtomicHost-28-20180723.0.ppc64le.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost
> -ostree-ppc64le-28-20180723.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/x86_64/images/Fedora-
> AtomicHost-28-20180723.0.x86_64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/x86_64/images/Fedora-
> AtomicHost-28-20180723.0.x86_64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/x86_64/images/Fedora-
> AtomicHost-Vagrant-28-20180723.0.x86_64.vagrant-libvirt.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/x86_64/images/Fedora-
> AtomicHost-Vagrant-28-20180723.0.x86_64.vagrant-virtualbox.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-
> ostree-x86_64-28-20180723.0.iso
>
> Respective signed CHECKSUM files can be found here:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/aarch64/images/Fedora-
> AtomicHost-28-20180723.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/aarch64/iso/Fedora-AtomicHost
> -28-20180723.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/ppc64le/images/Fedora-
> AtomicHost-28-20180723.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost
> -28-20180723.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/x86_64/images/Fedora-
> AtomicHost-28-20180723.0-x86_64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-A
> tomic-28-20180723.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-
> 28-20180723.0-x86_64-CHECKSUM
>
> For direct download, the "latest" targets are always available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest
> https://getfedora.org/atomic_raw_x86_64_latest
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest
>
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest
> https://getfedora.org/atomic_raw_aarch64_latest
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest
>
> ppc64le:
> https://getfedora.org/atomic_qcow2_ppc64le_latest
> https://getfedora.org/atomic_raw_ppc64le_latest
> https://getfedora.org/atomic_dvd_ostree_ppc64le_latest
>
> Filename fetching URLs are available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest_filename
> https://getfedora.org/atomic_raw_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename
>
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest_filename
> https://getfedora.org/atomic_raw_aarch64_latest_filename
> 

Re: Source tarballs are being placed in git?

[Artur Iwicki]

That section of the guide is a bit poorly worded. You should *not* use "git 
add" on source tarballs. These should be added only via means of "fedpkg 
new-sources $FILES; git add ./sources". I believe what the guide means under 
"new source files" is e.g. when upstream does not provide an icon or a .desktop 
or an .appdata.xml file (or a systemd .service or whatever) and you add your 
own. This does not include "new upstream release tarball".

I'll try to think of some way to make that more clear and submit a suggestion 
to change the guide text.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ATPYGXDWE5NUPTSVL7GCBQ2IXOPVLJ4B/

Source tarballs are being placed in git?

[Gerald B. Cox]

I received an email this AM from a fellow packager:




*Please, do not put source tarballs in git. This is not what is supposed to
happen. Package sources are managed with fedpkg, they are just added to the
lookaside cache and to the .gitignore file so you don't add them by mistake
to the repository.https://fedoraproject.org/wiki/Package_maintenance_guide
How did you
manage to add them to the commit even if they are already in .gitignore?*

The package is megatools.  The procedure I used was from the maintenance
guide -
yet apparently, these files ended up in a place where they weren't suppose
to be.

The commands I used were:

   - *Stage any small patches or new source files for commit:*

*git add (somefile)
*

*Details *

*git does not consider all files in the working directory to be a part of
the git repository by default (handy, for keeping other files around that
are relevant, like the source tree). This tells git to start considering
these files as part of the repository locally. When you 'commit' and 'push'
later, this change is communicated to the server. *

   - * Upload new source files to the lookaside cache:*

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

Fedora Atomic Host Two Week Release Announcement: 28.20180722.0

[noreply]

A new Fedora Atomic Host update is available via an OSTree update:

Version: 28.20180722.0
Commit(x86_64): 106a7095fd46741948ba60dbd0586668ae7abe6336671444ec790d7541a88778
Commit(aarch64): 
e4cb87910b0729293453004293c1aac3d676b8683f4147a6fb3975092b53810f
Commit(ppc64le): 
8f316b541744eafb126c06128e1af614f6ab5dccd72a8b722db4b0e295194115


We are releasing images from multiple architectures but please note
that x86_64 architecture is the only one that undergoes automated
testing at this time.

Existing systems can be upgraded in place via e.g. `atomic host upgrade`.

Corresponding image media for new installations can be downloaded from:

https://getfedora.org/en/atomic/download/

Alternatively, image artifacts can be found at the following links:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180723.0.aarch64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180723.0.aarch64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-28-20180723.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180723.0.ppc64le.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180723.0.ppc64le.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-28-20180723.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180723.0.x86_64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180723.0.x86_64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-28-20180723.0.x86_64.vagrant-libvirt.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-28-20180723.0.x86_64.vagrant-virtualbox.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-28-20180723.0.iso

Respective signed CHECKSUM files can be found here:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180723.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-28-20180723.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180723.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-28-20180723.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180723.0-x86_64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180723.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-28-20180723.0-x86_64-CHECKSUM

For direct download, the "latest" targets are always available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest
https://getfedora.org/atomic_raw_x86_64_latest
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
https://getfedora.org/atomic_dvd_ostree_x86_64_latest

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest
https://getfedora.org/atomic_raw_aarch64_latest
https://getfedora.org/atomic_dvd_ostree_aarch64_latest

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest
https://getfedora.org/atomic_raw_ppc64le_latest
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest

Filename fetching URLs are available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest_filename
https://getfedora.org/atomic_raw_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest_filename
https://getfedora.org/atomic_raw_aarch64_latest_filename
https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest_filename
https://getfedora.org/atomic_raw_ppc64le_latest_filename
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest_filename

For more 

Re: dnf history - change in how rpmdb checksum is computed

[Jeff Johnson]

This thread was about compatibility between dnf and yum: rpm itself has no 
usage case identifying whether an rpmdb has been changed.

But you are correct that installation of a package by any tool -- including dnf 
and rpm atm -- needlessly causes yum to warn that the rpmdb has changed which 
is rather silly IMHO.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZMU4CE2ZSHOSQCCG7AW6FXREDGCU3MNF/

Unannounced soname bump: libconfig

[Richard W.M. Jones]

This build:

  https://koji.fedoraproject.org/koji/buildinfo?buildID=1130189

changed the soname from libconfig.so.9 to libconfig.so.11 thus
breaking a number of packages.

I can't find any announcement.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6GLSDAET22F2YC7WNTCNW4OXCU72Z4CQ/

[rpms/perl-Inline-Python] New Commits To "rpms/perl-Inline-Python" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-Inline-Python on branch
master, which you are following:
9a4c87cda2fadd03764d3ec850a5c6fe036a45e8Igor GnatenkoAdd missing 
BuildRequires on gcc



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Inline-Python/commits/master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/2Z3MEP2WFP42VVB7D7E5WXOINMHNR3XD/

Correcting licenses in several packages I maintain

[Zdenek Dohnal]

Hi,

I reviewed licenses in files for my packages, so I added several
corrections of license tags:

cups:

- from GPLv2

- to GPLv2+ and LGPLv2+ with exceptions and AML

cups-filters:

- from GPLv2 and GPLv2+ and GPLv3 and GPLv3+ and LGPLv2+ and MIT

- to GPLv2 and GPLv2+ and GPLv3 and GPLv3+ and LGPLv2+ and MIT and BSD
with advertising

hplip:

- from GPLv2+ and MIT and BSD
- to GPLv2+ and MIT and BSD and IJG and Public Domain and GPLv2+ with
exceptions and ISC

qpdf:
- from Artistic 2.0
- to (Artistic 2.0 or ASL 2.0) and MIT

sane-backends:
- from GPLv2+ and GPLv2+ with exceptions and Public Domain
- to GPLv2+ and GPLv2+ with exceptions and Public Domain and IJG and
LGPLv2+ and MIT

sane-frontends:
- from GPLv2+
- to GPLv2+ and LGPLv2+ and GPLv2+ with exceptions

vim:
- from Vim
- to Vim and MIT
-- 

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




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 Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SG6M3D6N5BJRIPH4WFGNMT4TX4Y4R43E/

Re: build failed on s390x, other archs building okay

[Dan Horák]

On Tue, 24 Jul 2018 10:12:22 -0400
"Kaleb S. KEITHLEY"  wrote:

> Is this a spurious failure or ???

looks like an infrastructure problem with build<->hub communication


Dan
 
> ...
> Task info:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=28564187 ...
> buildArch (glusterfs-4.1.2-1.fc29.1.src.rpm, s390x): free -> FAILED:
> Fault:  "/usr/lib/python2.7/site-packages/koji/daemon.py", line 1244, in
> runTask\nresponse = (handler.run(),)\n  File
> "/usr/lib/python2.7/site-packages/koji/tasks.py", line 307, in run\n
> return koji.util.call_with_argcheck(self.handler, self.params,
> self.opts)\n  File "/usr/lib/python2.7/site-packages/koji/util.py",
> line 209, in call_with_argcheck\nreturn func(*args, **kwargs)\n
> File "/usr/sbin/kojid", line 1195, in handler\nfn =
> self.localPath("work/%s" % pkg)\n  File
> "/usr/lib/python2.7/site-packages/koji/tasks.py", line 477, in
> localPath\nfsrc = six.moves.urllib.request.urlopen(url)\n  File
> "/usr/lib64/python2.7/urllib2.py", line 154, in urlopen\nreturn
> opener.open(url, data, timeout)\n  File
> "/usr/lib64/python2.7/urllib2.py", line 435, in open\nresponse =
> meth(req, response)\n  File "/usr/lib64/python2.7/urllib2.py", line
> 548, in http_response\n\'http\', request, response, code, msg,
> hdrs)\n File "/usr/lib64/python2.7/urllib2.py", line 473, in
> error\nreturn self._call_chain(*args)\n  File
> "/usr/lib64/python2.7/urllib2.py", line 407, in _call_chain\n
> result = func(*args)\n  File "/usr/lib64/python2.7/urllib2.py", line
> 556, in http_error_default\n raise HTTPError(req.get_full_url(),
> code, msg, hdrs, fp)\nHTTPError: HTTP Error 503: Backend fetch
> failed\n'>
> 
> 
> thanks,
> 
> --
> 
> Kaleb
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/O2BNTIJT3KVZIZN4UO2JKSPXFOSTV6LI/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IYRIY4PLAVF6K45KZB5YRCMEKIPNKSIT/

build failed on s390x, other archs building okay

[Kaleb S. KEITHLEY]

Is this a spurious failure or ???

...
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=28564187
...
buildArch (glusterfs-4.1.2-1.fc29.1.src.rpm, s390x): free -> FAILED:
Fault: 


thanks,

--

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

[rpms/perl-Authen-Krb5-Admin] New Commits To "rpms/perl-Authen-Krb5-Admin" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-Authen-Krb5-Admin on 
branch
master, which you are following:
9a9a51e82b1b0cbfbcad58cbb694f4d1d378006fIgor GnatenkoAdd missing 
BuildRequires on gcc



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Authen-Krb5-Admin/commits/master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/PS7SRR3XLH6OC7KPEPN2KHGFQN54U27A/

Re: RFC: Pass --auto-features=enabled in meson

[Igor Gnatenko]

On Tue, Jul 24, 2018 at 3:43 PM Stephen Gallagher 
wrote:

> On Mon, Jul 23, 2018 at 10:28 PM  wrote:
>
>> On Mon, Jul 23, 2018 at 8:27 PM, Josh Boyer 
>> wrote:
>> > My biggest objection here is that it blindly enables things, which
>> > continues to make our package set a web of inter-dependencies and
>> > makes any attempts at minimization harder.  I don't think we should
>> > default to building everything in here.  I understand autotools might
>> > do that, but I wouldn't necessarily call autotools a best practice to
>> > begin with...
>>
>> It's a bit confusing, but Igor is proposing that we *disable* auto
>> feature detection by passing -Dauto_features=enabled. Um, what? Yes,
>> the options are enabled, auto (default), and disabled, where both
>> enabled and disabled turn off auto feature detection. enabled is used
>> to fail the build whenever an auto dependency is missing, and disabled
>> is used to allow the build to proceed without that feature.
>>
>> -Dauto_features=auto is the meson default, and it's what we currently
>> suffer with autotools: features get silently enabled or disabled
>> depending on which BuildRequires are present in the spec file. This is
>> the status quo, and it's a disaster. Auto dependencies are good if
>> you're building packages locally and don't want to install unnecessary
>> dependencies (hence a good default behavior), but very bad if you're a
>> Linux distribution building packages for other people to use and now
>> have a broken or inferior package due to a desireable dependency being
>> disabled by mistake. I'm pretty sure there's no argument for keeping
>> this behavior when building Fedora packages.
>>
>> We had originally forbidden the use of meson's auto features in GNOME
>> due to this problem (the automagic dependencies problem [1]), which
>> annoyed the Meson developers and led to the creation of this
>> -Dauto_features option. Now it's safe to recommend using auto features,
>> because we assume distros will build with -Dauto_features=enabled. With
>> this setting, if you want to disable a feature that's recommended by
>> upstream, you'll now have to explicitly disable it, which is surely
>> what we want to avoid features disappearing by mistake.
>>
>> Then on the other end of the spectrum, -Dauto_features=disabled would
>> disable all auto features... that would make packagers responsible for
>> constantly monitoring the upstream feature set with every release and
>> making choices about what to enable or disable. It sounds like you
>> might be advocating this option, but that does not seem at all
>> practical to me. Packagers sometimes know better than upstream which
>> features should be enabled in Fedora, but not usually. And packagers
>> might sometimes audit the upstream feature list after new releases to
>> see if new features should be enabled... but that seems like a rarity
>> to me. If we use -Dauto_features=disabled, a bunch of important
>> features will go missing, and Fedora will suffer from that. So let's
>> trust upstream by default, and override where it makes sense.
>>
>>
>
> Thank you for the detailed explanation, Michael. That does make it much
> clearer. So the effect of this change (which should probably be proposed as
> a System-Wide Change to FESCo, since it affects the default build flags[*])
> is to make the build deterministic by not quietly suppressing some of the
> output if their build dependencies are unsatisfied. This then forces
> packagers to use explicit enablement and disablement flags if they want to
> diverge from upstream.
>

I don't think this has anything to do with system-wide changes. It affects
only components which use meson. However I might submit self-contained one
if you feel strongly about this.


> I don't think this will really have a meaningful impact on the dependency
> creep, other than to make it more accurately represent the upstream
> preferred state. We can then choose to diverge as needed.
>
> I'm in favor of this change, but as I said above, I'd like to see this go
> through the Change process since it potentially impacts anything using
> meson to build.
>
>
> [*] This is minimally-invasive, so I'd be willing to consider it as a late
> proposal for F29.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XJI7GUKAS4IQLWN2H3MCPKTGQLSW5DBA/
>
-- 

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

Re: In the OpenShift Origin/CRI-O/Kubernetes effort we have a dilemma.

[Dusty Mabe]

On 06/29/2018 08:42 AM, Stephen Gallagher wrote:
> 
> 
> On Fri, Jun 29, 2018 at 8:32 AM Daniel Walsh  > wrote:
> 
> Users of OpenSHift Origin require CRI-O 1.10 right now.  But Kubernetes
> users want to try out the latest packages for kubernetes 1.11 which
> would require CRI-O 1.11.  Origin might not be ready to move to
> Kubernetes 1.11 for a while.
> 
> Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.*
> releases in the same Fedora 28.
> 
> I believe this is what Modularity was designed to fix.
> 
> Can I do this with Modularity?  If I can how do I use fedpkg to make
> this happen?'
> 
> 
> 
> Yes you can, we can help you get set up in #fedora-modularity on Freenode if 
> you like.
> 
> The basics are documented at 
> https://docs.fedoraproject.org/fedora-project/subprojects/fesco/en-US/making-modules/adding-new-modules.html
> 

Did we decide to convert the CRI-O / kube stack to a module?

If it needs a self contained change request the deadline is today!

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

Re: RFC: Pass --auto-features=enabled in meson

[Stephen Gallagher]

On Mon, Jul 23, 2018 at 10:28 PM  wrote:

> On Mon, Jul 23, 2018 at 8:27 PM, Josh Boyer 
> wrote:
> > My biggest objection here is that it blindly enables things, which
> > continues to make our package set a web of inter-dependencies and
> > makes any attempts at minimization harder.  I don't think we should
> > default to building everything in here.  I understand autotools might
> > do that, but I wouldn't necessarily call autotools a best practice to
> > begin with...
>
> It's a bit confusing, but Igor is proposing that we *disable* auto
> feature detection by passing -Dauto_features=enabled. Um, what? Yes,
> the options are enabled, auto (default), and disabled, where both
> enabled and disabled turn off auto feature detection. enabled is used
> to fail the build whenever an auto dependency is missing, and disabled
> is used to allow the build to proceed without that feature.
>
> -Dauto_features=auto is the meson default, and it's what we currently
> suffer with autotools: features get silently enabled or disabled
> depending on which BuildRequires are present in the spec file. This is
> the status quo, and it's a disaster. Auto dependencies are good if
> you're building packages locally and don't want to install unnecessary
> dependencies (hence a good default behavior), but very bad if you're a
> Linux distribution building packages for other people to use and now
> have a broken or inferior package due to a desireable dependency being
> disabled by mistake. I'm pretty sure there's no argument for keeping
> this behavior when building Fedora packages.
>
> We had originally forbidden the use of meson's auto features in GNOME
> due to this problem (the automagic dependencies problem [1]), which
> annoyed the Meson developers and led to the creation of this
> -Dauto_features option. Now it's safe to recommend using auto features,
> because we assume distros will build with -Dauto_features=enabled. With
> this setting, if you want to disable a feature that's recommended by
> upstream, you'll now have to explicitly disable it, which is surely
> what we want to avoid features disappearing by mistake.
>
> Then on the other end of the spectrum, -Dauto_features=disabled would
> disable all auto features... that would make packagers responsible for
> constantly monitoring the upstream feature set with every release and
> making choices about what to enable or disable. It sounds like you
> might be advocating this option, but that does not seem at all
> practical to me. Packagers sometimes know better than upstream which
> features should be enabled in Fedora, but not usually. And packagers
> might sometimes audit the upstream feature list after new releases to
> see if new features should be enabled... but that seems like a rarity
> to me. If we use -Dauto_features=disabled, a bunch of important
> features will go missing, and Fedora will suffer from that. So let's
> trust upstream by default, and override where it makes sense.
>
>

Thank you for the detailed explanation, Michael. That does make it much
clearer. So the effect of this change (which should probably be proposed as
a System-Wide Change to FESCo, since it affects the default build flags[*])
is to make the build deterministic by not quietly suppressing some of the
output if their build dependencies are unsatisfied. This then forces
packagers to use explicit enablement and disablement flags if they want to
diverge from upstream.

I don't think this will really have a meaningful impact on the dependency
creep, other than to make it more accurately represent the upstream
preferred state. We can then choose to diverge as needed.

I'm in favor of this change, but as I said above, I'd like to see this go
through the Change process since it potentially impacts anything using
meson to build.


[*] This is minimally-invasive, so I'd be willing to consider it as a late
proposal for F29.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XJI7GUKAS4IQLWN2H3MCPKTGQLSW5DBA/

sharutils license corrected

[Petr Pisar]

I corrected sharutils' license tag from:

GPLv3+ and (LGPLv3+ or BSD) and LGPLv2+ and Public Domain and GFDL

to:

GPLv3+ and (GPLv3+ and BSD) and (LGPLv3+ or BSD) and LGPLv2+ and Public Domain 
and GFDL

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

Re: Haskell failures: relocation refers to local symbol "" [1], which is defined in a discarded section

[Miro Hrončok]

On 24.7.2018 11:53, Nick Clifton wrote:

Hi Florian,


Linking dist/build/tests-asn1-encoding/tests-asn1-encoding ...
/tmp/ghc8eea_0/ghc_2.o(.gnu.build.attributes..text.startup+0x18): error: relocation 
refers to local symbol "" [11], which is defined in a discarded section
    section group signature: "(null)"


This should now be fixed.  (binutils-2.31.1-3.fc29)

The problem was an extension of the problem originally reported in BZ 1600431.
The gold linker is complaining about relocations from the annobin notes to
discarded code sections.  This particular version of the problem arose because
I patched annobin to create section groups containing both the notes and the
code, but I did not update the patch to gold to allow it to detect these
sections.  Anyway it should all be fixed now.



Thanks.

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

Re: Haskell failures: relocation refers to local symbol "" [1], which is defined in a discarded section

[Nick Clifton]

Hi Florian,

>> Linking dist/build/tests-asn1-encoding/tests-asn1-encoding ...
>> /tmp/ghc8eea_0/ghc_2.o(.gnu.build.attributes..text.startup+0x18): error: 
>> relocation refers to local symbol "" [11], which is defined in a discarded 
>> section
>>    section group signature: "(null)"

This should now be fixed.  (binutils-2.31.1-3.fc29)

The problem was an extension of the problem originally reported in BZ 1600431.
The gold linker is complaining about relocations from the annobin notes to
discarded code sections.  This particular version of the problem arose because
I patched annobin to create section groups containing both the notes and the
code, but I did not update the patch to gold to allow it to detect these
sections.  Anyway it should all be fixed now.

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

Re: Intel's Clear Linux optimizations

[Manas Mangaonkar]

>  It's just a little tricky
>  installing packages that have the same name, but lower > version numbers
than what is in the main Fedora repos.

I will update the documentation,thanks.

On Tue, 24 Jul 2018, 13:56 Samuel Sieb,  wrote:

> On 07/23/2018 11:53 PM, Manas Mangaonkar wrote:
> > This was my first repo/package sorry if i messed up somewhere.
>
> I don't personally have any interest in this package, but I don't see
> anything wrong with how it's setup.  It's just a little tricky
> installing packages that have the same name, but lower version numbers
> than what is in the main Fedora repos.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ESOLNDCNSAZQJ2YUE5XMSP3FIBK7S6CX/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5BTBMTFSQYMW3YG27PAARXWC2RRYEVAM/

sisu license correction

[Michael Šimáček]

sisu license tag has been corrected from:
EPL-1.0
to:
EPL-1.0 and BSD
because of bundled objectweb-asm

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

Re: dnf history - change in how rpmdb checksum is computed

[Michal Novotny]

I would like to see dnf history not being messed up by direct installations
with `rpm -i`.

While `dnf history` is a great feature, it would be even greater if the
related functionality
was implemented directly in rpmdb and both rpm and dnf used that db.
Meaning that
any consistency checks would be in that db too.

Just an idea.

clime

On Tue, Jul 24, 2018 at 12:40 AM Jeff Johnson  wrote:

> The real problem is that both E:N-V-R.A and N-E:V-R.A  are equally
> imprecise.
>
> The concept of "reproducible builds/installs" requires much more complete
> identifiers for serious work. But that was not the question asked in this
> thread.
>
> So calculating both checksums, on rearranged plaintext items, for
> compatibility, kinda misses the underlying need to verify system installs
> on hundreds of machines.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G5PQ6DZKLVJJYPJCQG2VVQQMRAITETJ3/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CVZAQ5IQATEMD6NTDUAQ47A2HWI6VMCV/

Re: Intel's Clear Linux optimizations

[Samuel Sieb]

On 07/23/2018 11:53 PM, Manas Mangaonkar wrote:

This was my first repo/package sorry if i messed up somewhere.


I don't personally have any interest in this package, but I don't see 
anything wrong with how it's setup.  It's just a little tricky 
installing packages that have the same name, but lower version numbers 
than what is in the main Fedora repos.

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

Re: Fedora 29 Self-Contained Change: xfce 4.1

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 23, 2018 at 09:51:21PM -0400, Ben Cotton wrote:
> == Summary ==
> Xfce desktop environment has utilized GTK-2 up until version 4.12.x
> which is currently available in Fedora. Significant work has been
> completed to migrate the DE to GTK-3 completely.  The obvious benefit
> to this migration is the use of a modern and actively maintained
> toolkit.
> 
> Xfce 4.13 is a development release leading up to the eventual 4.14
> stable release, however 4.13 components have proven to be very stable,
> provide features users want and the 4.14 release is unscheduled
> currently. This change proposal is submitted to sync fedora packages
> with latest upstream releases.

The "How to test" section could use some love.

BTW. The Change page is at https://fedoraproject.org/wiki/Changes/xfce-4.13,
this was missing from the announcement email.

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

Re: RFC: Pass --auto-features=enabled in meson

[Igor Gnatenko]

On Tue, Jul 24, 2018 at 4:23 AM Josh Boyer 
wrote:

> On Mon, Jul 23, 2018 at 6:40 PM Igor Gnatenko
>  wrote:
> >
> > Hello,
> >
> > meson 0.47.0 has new option type - feature (tri-state option -
> enabled/disabled/auto). It is quite common that in autofoo and less in
> cmake worlds people rely on auto-detection of dependencies and enabling
> features based on those.
> >
> > I believe that for distribution we should make sure that all default
> features are enabled and if not, packager should explicitly disable
> feature. For instance when I was testing some RPM patches for new
> compression types, it was disabling some default feature because the
> configure script was written in a wrong way.
> >
> > It would be nice if we could have some standardized way of specifying
> options for buildsystems which would convert into autofoo/cmake/meson way
> of specifying parameters but this is topic for another discussion.
> >
> > Thoughts? Objections?
>
> My biggest objection here is that it blindly enables things, which
> continues to make our package set a web of inter-dependencies and
> makes any attempts at minimization harder.  I don't think we should
> default to building everything in here.  I understand autotools might
> do that, but I wouldn't necessarily call autotools a best practice to
> begin with...
>

It is opposite, autofoo has everything "automatic" by default, so if you
miss some dependency in buildroot (or a wrong version, or wrong check) - it
will silently disable this feature. And no one will notice, except for the
users.

There is no impact on any minimization work: if packager decides that we
should disable some feature, he just passes -Dfeature=disabled and removes
necessary buildrequires or whatsoever.

So the main difference which this option makes is: if some of checks fail
for default option it is not silently disabled, but it will raise error.


> > Unless there is strong opposition, I'm going to switch this parameter in
> %meson macro and you would be able to change its value by redefining
> %__meson_auto_features.
>
> Can we discuss this more?  I would really like to see Fedora become a
> bit more explicit about things overall.
>
> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BQ7VEPCIUXTFI4SE7IW5BS2637RXILNH/
>
-- 

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

Re: Intel's Clear Linux optimizations

[Manas Mangaonkar]

This was my first repo/package sorry if i messed up somewhere.

On Tue, 24 Jul 2018, 12:11 Samuel Sieb,  wrote:

> On 07/23/2018 10:04 PM, Chris Murphy wrote:
> > Available Packages
> > kernel.src4.18.0-0.rc0.git10.1.fc28
> > pac23-High_Performance_Clear_LInux_kernel_for_Fedora
>
> This is what I get:
>
> # dnf list --all kernel
> Installed Packages
> kernel.x86_64 4.16.11-300.fc28
> @updates
> kernel.x86_64 4.17.4-200.fc28
> @updates-testing
> kernel.x86_64 4.17.7-200.fc28
> @updates
> Available Packages
> kernel.src4.18.0-0.rc0.git10.1.fc28
> pac23-High_Performance_Clear_LInux_kernel_for_Fedora
> kernel.x86_64 4.18.0-0.rc0.git10.1.fc28
> pac23-High_Performance_Clear_LInux_kernel_for_Fedora
>
> That last one is highlighted in blue.  The problem is that it seems to
> only show packages that would be an upgrade, even though "--all" should
> override that.  Try adding "--showduplicates", that gives me:
>
> # dnf list --all --showduplicates kernel
> Installed Packages
> kernel.x86_64 4.16.11-300.fc28
> @updates
> kernel.x86_64 4.17.4-200.fc28
> @updates-testing
> kernel.x86_64 4.17.7-200.fc28
> @updates
> Available Packages
> kernel.x86_64 4.16.3-301.fc28
> fedora
> kernel.x86_64 4.16.11-300.fc28
> @updates
> kernel.x86_64 4.17.4-200.fc28
> @updates-testing
> kernel.x86_64 4.17.7-200.fc28
> @updates
> kernel.x86_64 4.17.7-200.fc28
> updates
> kernel.src4.18.0-0.rc0.git10.1.fc28
> pac23-High_Performance_Clear_LInux_kernel_for_Fedora
> kernel.x86_64 4.18.0-0.rc0.git10.1.fc28
> pac23-High_Performance_Clear_LInux_kernel_for_Fedora
>
> Now it shows me the old one from the initial fedora release repo as well.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/S3TAGCNLQORSEUAVJD3J24OABPG7UIGE/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WQVNYQOSTPEBWGCB24QGESHQ3RFZ24NB/