date:20180124

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Sereal-4.005-1.fc26 has been pushed to the Fedora 26 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-75ae24ba46

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

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

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-threads-shared-1.58-1.fc26 has been pushed to the Fedora 26 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-6fe92b98df

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

[Bug 1537516] perl-threads-2.21 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-threads-2.21-1.fc26 has been pushed to the Fedora 26 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-0f208aa267

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

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

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Sereal-Decoder-4.005-1.fc26 has been pushed to the Fedora 26 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-f285645d8d

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

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

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Sereal-Encoder-4.005-1.fc26 has been pushed to the Fedora 26 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-e115ca7d2f

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

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

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-DateTime-TimeZone-2.17-1.fc26 has been pushed to the Fedora 26 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-658002dca0

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

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

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
perl-DateTime-TimeZone-2.17-1.fc26 has been pushed to the Fedora 26 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-658002dca0

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

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

2018-01-24 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1053  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 815  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 397  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 295  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 127  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  64  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  28  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8d57a2487b   
monit-5.25.1-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-28611aa33f   
python-bottle-0.12.13-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73feedd767   
wordpress-4.9.2-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-11ba3bced1   
clamav-0.99.2-18.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ce6223e559   
GraphicsMagick-1.3.28-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9eb18da891   
moodle-3.1.10-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-c0d5d190b0   
transmission-2.92-12.el7


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

cacti-1.1.33-1.el7
gnome-shell-extension-freon-33-1.el7
knot-resolver-1.5.3-1.el7
konversation-1.5.1-4.el7
lcov-1.13-1.el7
purple-discord-0-15.20171227git9b7c3ad.el7
purple-libsteam-1.6.1-19.20171225git7f761df.el7
python-betamax-0.7.1-1.el7
rpkg-1.51-3.el7
youtube-dl-2018.01.21-1.el7

Details about builds:



 cacti-1.1.33-1.el7 (FEDORA-EPEL-2018-b40716c230)
 An rrd based graphing tool

Update Information:

- Update to 1.1.33  Release notes:
https://www.cacti.net/release_notes.php?version=1.1.29
https://www.cacti.net/release_notes.php?version=1.1.30
https://www.cacti.net/release_notes.php?version=1.1.31
https://www.cacti.net/release_notes.php?version=1.1.32
https://www.cacti.net/release_notes.php?version=1.1.33




 gnome-shell-extension-freon-33-1.el7 (FEDORA-EPEL-2018-fb1a11b7a5)
 GNOME Shell extension to display system temperature, voltage, and fan speed

Update Information:

Bump to upstream version 33, which fixes typos in the Russian and Ukrainian
locales, and fixes an instability issue that could cause GNOME Shell to crash.




 knot-resolver-1.5.3-1.el7 (FEDORA-EPEL-2018-24ac4ff7df)
 Caching full DNS Resolver

Update Information:

Knot Resolver 1.5.3 (2018-01-23)   Bugfixes
 - fix the hints module on some systems, e.g. Fedora.   Symptom:
`undefined symbol: engine_hint_root_file`   Knot Resolver 1.5.2 (2018-01-22)
  Security  - fix CVE-2018-102:
insufficient DNSSEC validation, allowing   attackers to deny existence of some
data by forging packets.   Some combinations pointed out in RFC 6840 sections
4.1 and 4.3   were not taken into account.  Bugfixes  - memcached: fix
fallout from module rename in 1.5.1   Knot Resolver 1.5.1 (2017-12-12)
  Incompatible changes  -
script supervisor.py was removed, please migrate to a real process manager -
module ketcd was renamed to etcd for consistency - module kmemcached was renamed
to memcached for consistency  Bugfixes  - fix SIGPIPE crashes (#271) -
tests: work around out-of-space for platforms with larger memory pages - lua:
fix mistakes in bindings affecting 1.4.0 and 1.5.0 (and 1.99.1-alpha),
potentially causing problems in dns64 and workarounds modules - predict module:
various fixes (!399)  Improvements  - add priming module to
implement RFC 8109, enabled by default (#220) - add modules helping with system
time problems, enabled by default;   for details see documentation of
detect_time_skew and detect_time_jump

References:

  [ 1 ] Bug #1537462 - CVE-2018-102 knot-resolver: Insufficient DNSSEC 
validation

[Bug 1511251] perl-User-Identity-0.99 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-User-Identity-0.99-1.f
   ||c28
 Resolution|--- |RAWHIDE
   Assignee|tcall...@redhat.com |jples...@redhat.com
Last Closed||2018-01-25 02:33:28



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

Re: -z defs linker flag activated in Fedora rawhide

2018-01-24 Thread Remi Collet

Le 22/01/2018 à 16:24, Florian Weimer a écrit :
> I updated redhat-rpm-config to instruct ld to reject linking shared
> objects with undefined symbols.  Such undefined symbols break symbol
> versioning because the are not necessarily bound to the correct symbol
> version at run time.  (rhbz#1535422)

So this break all the PHP stack build...

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


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

Re: Unannounced SONAME bump in tinyxml2

2018-01-24 Thread Josh Boyer

On Wed, Jan 24, 2018 at 11:15 AM, Matthew Miller
 wrote:
> On Wed, Jan 24, 2018 at 10:05:56AM +0100, Dan Horák wrote:
>> > +1 - I'd say a mail to the list *and* directly to each affected
>> > maintainer. devel@ is a firehose and some maintainers may not keep up
>> > with it.
>> isn't devel-announce better fit than devel? Because its description [1]
>> lists "- ABI changes or rawhide package changes that require maintainer
>> coordination. "
>
> I think that's probably a judgment call based on how many people will
> be affected. If we put too much on devel-announce, it'll have the same
> firehose-of-information problem as devel.

Isn't it also moderated?  Which would mean the moderator has to be
paying attention and let it through...

I like devel +maintainers directly.

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

Re: FESCo Elections - January 2018 - Result announcement

2018-01-24 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Jan 25, 2018 at 01:47:13AM +0100, Jan Kurik wrote:
> The results for the elections are as follows:
> 
>   # votes |  name
> - +--
>  703  | Kevin Fenzi (nirik)
>  579  | Adam Miller (maxamillion)
>  512  | Jared Smith (jsmith)
>  503  | Josh Boyer ( jwboyer/jwb )
>  483  | Zbigniew Jędrzejewski-Szmek (zbyszek)
> - +--
>  469  | Justin Forbes (jforbes)
>  420  | Dominik Mierzejewski (rathann)
> 
> 
> Congratulations to the winning candidates, and thank you all
> candidates for running this elections!

Big thanks to everyone who voted and congratulations to all elected.

> A total of 143 ballots were cast,

Pfff, that's low compared to many recent elections. Doing the
elections twice certainly didn't help, but even so... Let's hope
it's just a fluke.

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

Council Elections - January 2018 - Result announcement

Greetings, all!

The elections for Council - January 2018 have concluded, and
the results are shown below.

Council is electing 2 seats this time.
A total of 142 ballots were cast, meaning a candidate
could accumulate up to 710 votes (142 * 5).

The results for the elections are as follows:

  # votes |  name
- +--
 459  | Dennis Gilmore (dgilmore / ausil)
 350  | Nick Bebout (nb)
- +--
 334  | Langdon White (langdon)
 309  | Jona Azizaj (jonatoni)
 239  | Russ Herrold (herrold / orc_fedo)


Congratulations to the winning candidates, and thank you all
candidates for running this elections!

[1] https://admin.fedoraproject.org/voting/about/council-january-2018

-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

FESCo Elections - January 2018 - Result announcement

Greetings, all!

The elections for FESCo - January 2018 have concluded, and
the results are shown below.

FESCo is electing 5 seats this time.
A total of 143 ballots were cast, meaning a candidate
could accumulate up to 1001 votes (143 * 7).

The results for the elections are as follows:

  # votes |  name
- +--
 703  | Kevin Fenzi (nirik)
 579  | Adam Miller (maxamillion)
 512  | Jared Smith (jsmith)
 503  |  Josh Boyer ( jwboyer/jwb )
 483  | Zbigniew Jędrzejewski-Szmek (zbyszek)
- +--
 469  | Justin Forbes (jforbes)
 420  | Dominik Mierzejewski (rathann)


Congratulations to the winning candidates, and thank you all
candidates for running this elections!

[1] https://admin.fedoraproject.org/voting/about/fesco-january-2018
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Mindshare Elections - January 2018 - Result announcement

Greetings, all!

The elections for Mindshare - January 2018 have concluded, and
the results are shown below.

Mindshare is electing 2 seats this time.
A total of 124 ballots were cast, meaning a candidate
could accumulate up to 620 votes (124 * 5).

The results for the elections are as follows:

  # votes |  name
- +--
 344  | Jared Smith (jsmith)
 325  | Nick Bebout (nb)
- +--
 302  | Jona Azizaj (jonatoni)
 280  |  Gabriele Trombini (mailga)
 235  |  Radka Janek (rhea)


Congratulations to the winning candidates, and thank you all
candidates for running this elections!

[1] https://admin.fedoraproject.org/voting/about/mindshare-january-2018

-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Council Elections - January 2018 - Result announcement

Greetings, all!

The elections for Council - January 2018 have concluded, and
the results are shown below.

Council is electing 2 seats this time.
A total of 142 ballots were cast, meaning a candidate
could accumulate up to 710 votes (142 * 5).

The results for the elections are as follows:

  # votes |  name
- +--
 459  | Dennis Gilmore (dgilmore / ausil)
 350  | Nick Bebout (nb)
- +--
 334  | Langdon White (langdon)
 309  | Jona Azizaj (jonatoni)
 239  | Russ Herrold (herrold / orc_fedo)


Congratulations to the winning candidates, and thank you all
candidates for running this elections!

[1] https://admin.fedoraproject.org/voting/about/council-january-2018

-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: microcode updates and spectre variant 2

2018-01-24 Thread Justin Forbes

On Wed, Jan 24, 2018 at 12:13 PM, Chris Murphy  wrote:
> Intel has pulled the 20180108 microcode due to some CPUs crashing
> (uncommanded reboots are a crash), and they have reverted latest
> recommended to 20171117. And they appear to be recommending no longer
> deploying the 20180108 microcode, but I can't tell if they are
> directing this to firmware oems or OS deployment.
>
> https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/
> https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?v=t
>
This is true, though from what I have been told, the issues are in
relation to IBRS which Fedora is not using yet.   This is one of the
reasons we have not pulled in those patches just yet. Retpolines give
us most of the mitigation required and shouldn't cause issues with the
microcode we are shipping.  I know that Intel is working on updates to
the microcode and Fedora will pick those up when they are available.
Once those are in place, we can look at enabling IBRS for additional
mitigation where required.

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

Re: Build flag injection for qmake

Florian Weimer wrote:

>> * Adapt packages to use the wrapper. this can take the form of explicitly
>> setting QMAKE (or equivalent), adjusting PATH to prefer the qt5 wrapper
>> dir, or patching, or some combination of the above.
>> 
>> In the specific case of pcp, it supports QMAKE, so it's a one liner,
>> something like this appears to achieve what we want:
>> 
>> diff --git a/pcp.spec b/pcp.spec
>> index 72a7583..71d59a6 100644
>> --- a/pcp.spec
>> +++ b/pcp.spec
>> @@ -2089,6 +2089,7 @@ updated policy package.
>>   rm -Rf $RPM_BUILD_ROOT
>>   
>>   %build
>> +export QMAKE=%{qmake_qt5_wrapper}
>>   %if !%{disable_python2} && 0%{?default_python} != 3
>>   export PYTHON=python%{?default_python}
>>   %endif
> 
> I doubt that this will work for pcp because it fails building with -z
> defs and therefore has to use:
> 
> %undefine _strict_symbol_defs_build

Adding my export + your undefine yielded a successful scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=24422357

proof of concept appears to be a success.

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

Re: Build flag injection for qmake

Florian Weimer wrote:

> On 01/24/2018 10:05 PM, Rex Dieter wrote:
>> Rex Dieter wrote:
>> 
>>> Florian Weimer wrote:
>> 
>> Oh, *indirectly* calls qmake, that may be trickier.  Which package?
>> 
 pcp: https://bugzilla.redhat.com/show_bug.cgi?id=1538187
>>> ...
 I don't want to copy this solution in the dozen or so packages which
 need this (and I probably would have missed QMAKE_STRIP).  Surely it
 would make sense to provide a generic solution?
>>>
>>> If something is needed more broadly, I agree.   I'll take a closer look
>>> at pcp and see if I can come up with a better generic solution.
>> 
>> This is the best I've come up with so far:
>> * Qt packaging providing a qmake wrapper. first horriblish iteration:
>> 
https://src.fedoraproject.org/rpms/qt5/c/d9172949ad3ad54908de9ecfd41bf125f8f83447
> 
> Thanks for working on this.
> 
> I'm not sure if the use of eval is correct.  I would have expected
> something like this instead:
> 
> exec $QMAKE $QMAKE_FLAGS "$@"
> 
>> * Adapt packages to use the wrapper. this can take the form of explicitly
>> setting QMAKE (or equivalent), adjusting PATH to prefer the qt5 wrapper
>> dir, or patching, or some combination of the above.
>> 
>> In the specific case of pcp, it supports QMAKE, so it's a one liner,
>> something like this appears to achieve what we want:
>> 
>> diff --git a/pcp.spec b/pcp.spec
>> index 72a7583..71d59a6 100644
>> --- a/pcp.spec
>> +++ b/pcp.spec
>> @@ -2089,6 +2089,7 @@ updated policy package.
>>   rm -Rf $RPM_BUILD_ROOT
>>   
>>   %build
>> +export QMAKE=%{qmake_qt5_wrapper}
>>   %if !%{disable_python2} && 0%{?default_python} != 3
>>   export PYTHON=python%{?default_python}
>>   %endif
> 
> I doubt that this will work for pcp because it fails building with -z
> defs and therefore has to use:
> 
> %undefine _strict_symbol_defs_build
> 
> But the qmake wrapper will not see this directive in the spec file and
> pass the full set of linker flags.  At least that's what I expect, I
> haven't tried it.
> 
> I suspect we need something that captures the contents of CFLAGS etc.
> which is called from %build in different environment variables, and also
> sets QMAKE.

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

Unfortunately, setting QMAKE is not a standard thing to rely on (as far as I 
know).  Do you have any docs or evidence to the contrary?

-- Rex

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

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

2018-01-24 Thread stan

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

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

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

On the other hand, it could be completely unrelated to your problem.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Build flag injection for qmake


On 01/24/2018 10:05 PM, Rex Dieter wrote:

Rex Dieter wrote:


Florian Weimer wrote:



Oh, *indirectly* calls qmake, that may be trickier.  Which package?



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

...

I don't want to copy this solution in the dozen or so packages which
need this (and I probably would have missed QMAKE_STRIP).  Surely it
would make sense to provide a generic solution?


If something is needed more broadly, I agree.   I'll take a closer look at
pcp and see if I can come up with a better generic solution.


This is the best I've come up with so far:
* Qt packaging providing a qmake wrapper. first horriblish iteration:
https://src.fedoraproject.org/rpms/qt5/c/d9172949ad3ad54908de9ecfd41bf125f8f83447


Thanks for working on this.

I'm not sure if the use of eval is correct.  I would have expected 
something like this instead:


exec $QMAKE $QMAKE_FLAGS "$@"


* Adapt packages to use the wrapper. this can take the form of explicitly
setting QMAKE (or equivalent), adjusting PATH to prefer the qt5 wrapper dir,
or patching, or some combination of the above.

In the specific case of pcp, it supports QMAKE, so it's a one liner,
something like this appears to achieve what we want:

diff --git a/pcp.spec b/pcp.spec
index 72a7583..71d59a6 100644
--- a/pcp.spec
+++ b/pcp.spec
@@ -2089,6 +2089,7 @@ updated policy package.
  rm -Rf $RPM_BUILD_ROOT
  
  %build

+export QMAKE=%{qmake_qt5_wrapper}
  %if !%{disable_python2} && 0%{?default_python} != 3
  export PYTHON=python%{?default_python}
  %endif


I doubt that this will work for pcp because it fails building with -z 
defs and therefore has to use:


%undefine _strict_symbol_defs_build

But the qmake wrapper will not see this directive in the spec file and 
pass the full set of linker flags.  At least that's what I expect, I 
haven't tried it.


I suspect we need something that captures the contents of CFLAGS etc. 
which is called from %build in different environment variables, and also 
sets QMAKE.


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

Re: Build flag injection for qmake

Rex Dieter wrote:

> Florian Weimer wrote:

 Oh, *indirectly* calls qmake, that may be trickier.  Which package?

>> pcp: https://bugzilla.redhat.com/show_bug.cgi?id=1538187
> ...
>> I don't want to copy this solution in the dozen or so packages which
>> need this (and I probably would have missed QMAKE_STRIP).  Surely it
>> would make sense to provide a generic solution?
> 
> If something is needed more broadly, I agree.   I'll take a closer look at
> pcp and see if I can come up with a better generic solution.

This is the best I've come up with so far:
* Qt packaging providing a qmake wrapper. first horriblish iteration:
https://src.fedoraproject.org/rpms/qt5/c/d9172949ad3ad54908de9ecfd41bf125f8f83447

* Adapt packages to use the wrapper. this can take the form of explicitly 
setting QMAKE (or equivalent), adjusting PATH to prefer the qt5 wrapper dir, 
or patching, or some combination of the above.

In the specific case of pcp, it supports QMAKE, so it's a one liner, 
something like this appears to achieve what we want:

diff --git a/pcp.spec b/pcp.spec
index 72a7583..71d59a6 100644
--- a/pcp.spec
+++ b/pcp.spec
@@ -2089,6 +2089,7 @@ updated policy package.
 rm -Rf $RPM_BUILD_ROOT

 %build
+export QMAKE=%{qmake_qt5_wrapper}
 %if !%{disable_python2} && 0%{?default_python} != 3
 export PYTHON=python%{?default_python}
 %endif

How's that sound? 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1224812] Missing dependency: perl(GD)

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

Matěj Cepl  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |INSUFFICIENT_DATA
Last Closed||2018-01-24 16:03:23



--- Comment #4 from Matěj Cepl  ---
Right, I have no idea either.

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

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

On 24 January 2018 at 11:32, Samuel Rakitničan <
srakitni...@fedoraproject.org> wrote:

> > 1) easier to test upgrades between Fedora versions
> >
> > As each Fedora major release may have in updates only security and
> critical
> > fixes and ABI (libraries SONAME changes) will be completely locked down
> it
> > will be easier work on a set of test units testing upgrades on top of
> > different sets of installed packages.
>
> Doesn't relate to packages which rarely see an update if at all
>

But *why* asking for troubles and really not keep as REALLY stable what
STABLE in distro releases SHOULD be? (even +updates)
I'm really sure that there are much more interesting things touch ABI up to
the EOS. Isn't it?

> 2) more people (packagers and regular end users) will be focused on
> testing
> > of latest Fedora version
>
> Do you have some results of a testing or you just assume this would be the
> case
>

Yes. Out of my 7 years working and leading PLD more than half I've spend
working on two PLD version (const devel and stable).
All necessary changes ni CVS have been kept on ***branches***. Today with
git it will be way easier than +10 years ago.
Is it enough?

Minimal overhead on maintaining all packages where in only two flat CVS
modules SOURCES and SPECS.
I'm not suggesting to repeat this because current Fedora git model is good
enough with additional ACLs control.
Remember that it was only few of us actively working every day on whole
distribution.
Even with so imaginable small man/hours resources we been able to punch
first 3K (without perl/php packages) source packages barrier when at this
time in RH was still IIRC still less than 1k.
When poldek was in first quite usable version (credits to Paweł Gajda)
quite quickly was possible to reach high level of rpm dependencies
consistency or few types of conflicts checked on top of really wide/broad
set of packages without tying to test everything.
Common and strictly guarded spec files indentation/format was FUNDAMENTAL
to reach very high level of replace ability on maintaining already CLEAN
specs files.

Will divert here (again as I'm quite often doing) to specs
format/indentation ..

When only recently I've spotted that core Fedora packages (those which are
in RHEL) are maintained by (probably) ONLY RH employees (even as secondary
admins), and we are talking about at maybe few hundredths people strong
team I'm 100% sure why FPG parts about "common specs format" are only empty
wish.
Why? Because communication factor grows with factorial number of people.
In so big team always will be someone who "I didn't know that is is now new
rule" or "I don't like this".
Those people are probably quite often are so busy that they are "running
with empty barrows on transporting bricks between place where truck
unloaded bricks and construction place because they always says that we are
so busy that we don't have time to load and unload those bricks" (old
communist time joke).

Because many specs are really complicated because it was no proper peer
review as result some isolated woks on packages.
This at the end created highly over complicated (by what was dine in the
past). This on next level as consequence caused probably as well some
number of bad cases on moving packages between people. And finally decision
"we cannot loose straight control on this core Fedora distribution packages
because only few on this world knows how to maintan each package".
This caused as result limited level of Fedora<->RH trust.

No .. I know that if it is true it is pure bollocks. When I was working PLD
I've been controlling ALL packages. Everyone of us in PLD was able to do
this using only "sense of broken patterns". Each day review new changes
took me only up to 1h. Rest of the free time I've been spending on adding
second the same batch (if not more) my own changes.
Yes, I'm good on finding those "broken patterns" and in PLD I was only one
and this is why (ONLY) PLD started going down when other people in PLD
started thinking on monetize whole project (all without telling me even
single word about this).
Yea I was young, naive and still idealist .. who did't?

What I'm trying to say is that IMO I probably know why up to now it was not
possible to introduce common indentation in RH and Fedora as well.
(bad news)
I know probably as well why now it will be  even harder.
.. because (as result)
a) some people may loose some responsibilities
b) it will be no more "my little precious" spec files
c) some people by this may loose some part of they "uniqueness"
.
.
Choose something ..

In other words on this area way bigger some "human/ego" obstacles than all
those technical ones. Am I close?
If not .. try to think why (probably as first but up to now not last) PLD
was able to attract attract some people with quite basic technical skills
when after few year we reached things which even RH with thousands
technical employees is not able after +10 years still is not able to reach.
More .. even with

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

2018-01-24 Thread mcatanzaro

On Wed, Jan 24, 2018 at 1:37 PM, Przemek Klosowski 
 wrote:

Can anyone suggest ways of debugging this?


Run coredumpctl to see what processes crashed. There should be at least 
a gnome-shell crash, maybe also a gnome-session crash, maybe also an 
XWayland crash. Usually only the gnome-shell and gnome-session crashes 
are interesting. Use 'coredumpctl gdb' to get backtraces for each crash 
in gdb. Be sure to install the debuginfo via the dnf command that gdb 
will suggest and then restart gdb each time, to get a high-quality 
backtrace.


Once you have a backtrace, you have all you need for a quality crash 
report. Skip Red Hat Bugzilla and go straight to upstream for best 
results. The gnome-shell crash should be reported at 
https://gitlab.gnome.org/GNOME/gnome-shell/issues (yes, it's a new 
issue tracker, I'm afraid you just missed being first!). If there's 
also a gnome-session crash, that should be reported at 
https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-session.


Hope that helps,

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

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

2018-01-24 Thread Przemek Klosowski


On 01/21/2018 07:23 AM, Tom Hughes wrote:
Not really. It's a grab bag of different things that may or not be 
related to Wayland.


I think this problem is compounded by the fact that Wayland and several 
other system features such as Gnome session setup are very integrated, 
and it's hard to debug them.


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


This is a pretty serious issue in my opinion, because if I can crash the 
entire desktop session then it's not unreasonable to expect fuzzing 
issues with serious security implications (e.g. snooping on your desktop 
session from code running in the browser).


I tried to run strace on the pan process and save results to the disk 
file, but it was inconclusive; whatever kills the login session seems to 
happen outside of the pan process.


Can anyone suggest ways of debugging this?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1224812] Missing dependency: perl(GD)

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



--- Comment #3 from Paul Howarth  ---
Don't know how you managed to get this behavior in 2015 but it seems OK now:

# yum install lcov
Loaded plugins: fastestmirror
base   
   
  | 3.6 kB  00:00:00 
epel/x86_64/metalink   
   
  |  14 kB  00:00:00 
epel   
   
  | 4.7 kB  00:00:00 
extras 
   
  | 3.4 kB  00:00:00 
updates
   
  | 3.4 kB  00:00:00 
(1/4): epel/x86_64/group_gz
   
  | 266 kB  00:00:01 
(2/4): epel/x86_64/updateinfo  
   
  | 877 kB  00:00:01 
(3/4): epel/x86_64/primary_db  
   
  | 6.2 MB  00:00:02 
(4/4): updates/7/x86_64/primary_db 
   
  | 5.3 MB  00:00:04 
Loading mirror speeds from cached hostfile
 * base: repo1.ash.innoscale.net
 * epel: epel.mirror.constant.com
 * extras: repo1.ash.innoscale.net
 * updates: repo1.ash.innoscale.net
Resolving Dependencies
--> Running transaction check
---> Package lcov.noarch 0:1.10-4.el7 will be installed
--> Processing Dependency: perl(Digest::MD5) for package:
lcov-1.10-4.el7.noarch
--> Processing Dependency: perl(GD::Image) for package: lcov-1.10-4.el7.noarch
--> Running transaction check
---> Package perl-Digest-MD5.x86_64 0:2.52-3.el7 will be installed
--> Processing Dependency: perl(Digest::base) >= 1.00 for package:
perl-Digest-MD5-2.52-3.el7.x86_64
---> Package perl-GD.x86_64 0:2.49-3.el7 will be installed
--> Processing Dependency: gd >= 2.0.28 for package: perl-GD-2.49-3.el7.x86_64
--> Processing Dependency: libpng15.so.15()(64bit) for package:
perl-GD-2.49-3.el7.x86_64
--> Processing Dependency: libjpeg.so.62()(64bit) for package:
perl-GD-2.49-3.el7.x86_64
--> Processing Dependency: libgd.so.2()(64bit) for package:
perl-GD-2.49-3.el7.x86_64
--> Processing Dependency: libfontconfig.so.1()(64bit) for package:
perl-GD-2.49-3.el7.x86_64
--> Processing Dependency: libXpm.so.4()(64bit) for package:
perl-GD-2.49-3.el7.x86_64
--> Processing Dependency: libX11.so.6()(64bit) for package:
perl-GD-2.49-3.el7.x86_64
--> Running transaction check
---> Package fontconfig.x86_64 0:2.10.95-11.el7 will be installed
--> Processing Dependency: fontpackages-filesystem for package:
fontconfig-2.10.95-11.el7.x86_64
--> Processing Dependency: font(:lang=en) for package:
fontconfig-2.10.95-11.el7.x86_64
---> Package gd.x86_64 0:2.0.35-26.el7 will be installed
---> Package libX11.x86_64 0:1.6.5-1.el7 will be installed
--> Processing Dependency: libX11-common >= 1.6.5-1.el7 for package:
libX11-1.6.5-1.el7.x86_64
--> Processing Dependency: libxcb.so.1()(64bit) for package:
libX11-1.6.5-1.el7.x86_64
---> Package libXpm.x86_64 0:3.5.12-1.el7 will be installed
---> Package libjpeg-turbo.x86_64 0:1.2.90-5.el7 will be installed
---> Package libpng.x86_64 2:1.5.13-7.el7_2 will be installed
---> Package perl-Digest.noarch 0:1.17-245.el7 will be installed
--> Running transaction check
---> Package fontpackages-filesystem.noarch 0:1.44-8.el7 will be installed
---> Package libX11-common.noarch 0:1.6.5-1.el7 will be installed
---> Package libxcb.x86_64 0:1.12-1.el7 will be installed
--> Processing Dependency: libXau.so.6()(64bit) for package:
libxcb-1.12-1.el7.x86_64
---> Package lyx-fonts.noarch 0:2.2.3-1.el7 will be installed
--> Running transaction check
---> Package libXau.x86_64 0:1.0.8-2.1.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=
 Package   Arch

Re: Wyland is a disaster

2018-01-24 Thread Przemek Klosowski


On 01/23/2018 06:56 PM, Howard Howell wrote:

Due to that last line, issued su and password and ran it again:
# lshw
Segmentation fault (core dumped)


ok, great---so now do 'gdb lshw', type 'r' in gdb, and see where it crashes.

You may need to debuginfo-install few packages if gdb says it can't find 
debugging symbols, and you may need to install also some -source 
packages because the recent changes in packaging and dnf fail to do so. 
Then, report whether the crash happens reliably in a single location, or 
is random as it would be if your hardware is flaky.

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

Re: Using project version in soname: is it OK?

2018-01-24 Thread Alois Mahdal

Hi,

On 01/20/2018 01:15 AM, Patrick Monnerat wrote:
> On 01/19/2018 11:07 PM, Alois Mahdal wrote:
>> Hi Fedora!
>>
>> TL;DR: What do experienced C/C++ packagers think about this PR,
>> considering potential future appearance in Fedora?
>>
>>  https://github.com/naelstrof/slop/pull/94
>>
> Using the project version for soname is usually a bad idea, because
> soname is related to ABI compatibility, while project releases are not.
> 
> If you upgrade a package containing a shared library with an soname
> depending on the project version, you'll break the compatibility with
> compiled programs using the shared library, even if the ABI has not
> effectively changed.
> 
> That's why you better avoid changing the soname when not needed.
> Please note also that setting an soname is generally a developer's task,
> not a packager one.
> 
> Libtool implements a "version info" feature from which the soname is
> derived. The derivation itself is platform-dependent.
> There's some hints and explanation in libtool doc:
> https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
> 
> With this convention, the real soname computation can be performed
> properly on each platform, depending on the system supported ABI
> compatibility.

Thanks a lot for explanation and links, Patrick!
aL.

PS: The discussion in said PR has been resolved in favor of the PR; it
seems that it's not so bad in this case: the project already builds
library with soname `libslopy.so`, which is much worse.


-- 
Alois Mahdal 
Platform QE Engineer at Red Hat, Inc.
#brno, #daemons, #preupgrade
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

2018-01-24 Thread Howard Howell

On Tue, 2018-01-23 at 19:52 -0500, Jared K. Smith wrote:
> On Tue, Jan 23, 2018 at 6:56 PM, Howard Howell 
> wrote:
> > Due to that last line, issued su and password and ran it again:
> > 
> > # lshw
> > 
> > Segmentation fault (core dumped)
> > 
> > #
> 
> Due to the fact that you're having segfaults in command-line programs
> as well, I'm tempted to say you've got a bigger (hardware?) problem
> on your hands, and that Wayland crashing is just a symptom of that
> larger issue.
> 
> --
> Jared Smith
> 
That's the first real crash from command line.
Regards,
Les H___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Plan to remove libxml2-static

2018-01-24 Thread Richard W.M. Jones

On Wed, Jan 24, 2018 at 10:04:36AM +0100, Igor Gnatenko wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hello,
> 
> is anybody against of removal of libxml2-static package? It is not used by any
> Fedora package.

Static libraries are useful occasionally, especially as Neal said for
initramfses, but for other cases too.  *Why* do you want to remove
libxml2-static?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Build flag injection for qmake

Florian Weimer wrote:

> On 01/24/2018 07:18 PM, Rex Dieter wrote:
>> Rex Dieter wrote:
>> 
>>> Rex Dieter wrote:
>>>
 Florian Weimer wrote:

> I have a package which indirectly calls qmake (from Qt5).  Is there a
> way to inject the standard build flags using environment variables, or
> do I have to patch the invocation of the qmake command itself to pass
> the flags, similar to what %{qmake_qt5} does?

 %{qmake_qt5} already does that in general.   it will use any existing
 values for environment variables CFLAGS, CXXFLAGS, LDFLAGS.

 In short, set CFLAGS, CXXFLAGS, and/or LDFLAGS prior to calling
 %{qmake_qt5}
>>>
>>> Oh, *indirectly* calls qmake, that may be trickier.  Which package?
> 
> pcp: https://bugzilla.redhat.com/show_bug.cgi?id=1538187
...
> I don't want to copy this solution in the dozen or so packages which
> need this (and I probably would have missed QMAKE_STRIP).  Surely it
> would make sense to provide a generic solution?

If something is needed more broadly, I agree.   I'll take a closer look at 
pcp and see if I can come up with a better generic solution.

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

Re: Build flag injection for qmake


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

Rex Dieter wrote:


Rex Dieter wrote:


Florian Weimer wrote:


I have a package which indirectly calls qmake (from Qt5).  Is there a
way to inject the standard build flags using environment variables, or
do I have to patch the invocation of the qmake command itself to pass
the flags, similar to what %{qmake_qt5} does?


%{qmake_qt5} already does that in general.   it will use any existing
values for environment variables CFLAGS, CXXFLAGS, LDFLAGS.

In short, set CFLAGS, CXXFLAGS, and/or LDFLAGS prior to calling
%{qmake_qt5}


Oh, *indirectly* calls qmake, that may be trickier.  Which package?


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

I doubt that setting the QMAKE variable works; the required shell 
quoting would be pretty horrible (three or four levels).



I found some qt(4), examples of using a qmake wrapper, but the principle is
the same, one is:
https://marc.info/?l=fedora-extras-commits=145585036023552=2


I don't want to copy this solution in the dozen or so packages which 
need this (and I probably would have missed QMAKE_STRIP).  Surely it 
would make sense to provide a generic solution?


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

Re: Build flag injection for qmake

Rex Dieter wrote:

> Rex Dieter wrote:
> 
>> Florian Weimer wrote:
>> 
>>> I have a package which indirectly calls qmake (from Qt5).  Is there a
>>> way to inject the standard build flags using environment variables, or
>>> do I have to patch the invocation of the qmake command itself to pass
>>> the flags, similar to what %{qmake_qt5} does?
>> 
>> %{qmake_qt5} already does that in general.   it will use any existing
>> values for environment variables CFLAGS, CXXFLAGS, LDFLAGS.
>> 
>> In short, set CFLAGS, CXXFLAGS, and/or LDFLAGS prior to calling
>> %{qmake_qt5}
> 
> Oh, *indirectly* calls qmake, that may be trickier.  Which package?

I found some qt(4), examples of using a qmake wrapper, but the principle is 
the same, one is:
https://marc.info/?l=fedora-extras-commits=145585036023552=2

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

Re: microcode updates and spectre variant 2

2018-01-24 Thread Chris Murphy

Intel has pulled the 20180108 microcode due to some CPUs crashing
(uncommanded reboots are a crash), and they have reverted latest
recommended to 20171117. And they appear to be recommending no longer
deploying the 20180108 microcode, but I can't tell if they are
directing this to firmware oems or OS deployment.

https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/
https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?v=t


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

Re: Build flag injection for qmake

Rex Dieter wrote:

> Florian Weimer wrote:
> 
>> I have a package which indirectly calls qmake (from Qt5).  Is there a
>> way to inject the standard build flags using environment variables, or
>> do I have to patch the invocation of the qmake command itself to pass
>> the flags, similar to what %{qmake_qt5} does?
> 
> %{qmake_qt5} already does that in general.   it will use any existing
> values for environment variables CFLAGS, CXXFLAGS, LDFLAGS.
> 
> In short, set CFLAGS, CXXFLAGS, and/or LDFLAGS prior to calling
> %{qmake_qt5}

Oh, *indirectly* calls qmake, that may be trickier.  Which package?

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

Re: Build flag injection for qmake

Florian Weimer wrote:

> I have a package which indirectly calls qmake (from Qt5).  Is there a
> way to inject the standard build flags using environment variables, or
> do I have to patch the invocation of the qmake command itself to pass
> the flags, similar to what %{qmake_qt5} does?

%{qmake_qt5} already does that in general.   it will use any existing values 
for environment variables CFLAGS, CXXFLAGS, LDFLAGS.

In short, set CFLAGS, CXXFLAGS, and/or LDFLAGS prior to calling %{qmake_qt5}

Does that help?

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

Re: Unannounced SONAME bump in tinyxml2

2018-01-24 Thread Matthew Miller

On Wed, Jan 24, 2018 at 10:05:56AM +0100, Dan Horák wrote:
> > +1 - I'd say a mail to the list *and* directly to each affected
> > maintainer. devel@ is a firehose and some maintainers may not keep up
> > with it.
> isn't devel-announce better fit than devel? Because its description [1]
> lists "- ABI changes or rawhide package changes that require maintainer
> coordination. "

I think that's probably a judgment call based on how many people will
be affected. If we put too much on devel-announce, it'll have the same
firehose-of-information problem as devel.

-- 
Matthew Miller

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

Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc

2018-01-24 Thread Adam Jackson

On Tue, 2018-01-23 at 09:17 +0100, Florian Weimer wrote:
> On 01/23/2018 08:59 AM, Yaakov Selkowitz wrote:
> > Is this another reason to move the headers out of
> > /usr/include/tirpc,
> > once glibc no longer provides conflicting headers?
> 
> Seems worth a try.  Unlike /usr/include/rpcsvc, /usr/include/rpc was 
> exclusively used by glibc.

tirpc could also do #pragma GCC system_header I bet.

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

Re: Re: Proposed Fedora packaging guideline: More Go packaging


De: "Jakub Cajka" 

> Very nice list, it would be nice to have it as sub-wiki page of guidelines. I 
> have took liberty to add
> few points.

Ok, I put it here so people have a place to work on it 
https://fedoraproject.org/wiki/More_Go_packaging#Go_developer_guidance:_making_your_software_third-party-friendly

It can be moved later wherever you feel is more appropriate

Regards,

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

Re: Plan to remove libxml2-static

2018-01-24 Thread Igor Gnatenko

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-01-24 at 14:35 +, Tomasz Kłoczko wrote:
> On 24 January 2018 at 11:21, Tomasz Kłoczko 
> wrote:
> [..]
> >  Fact that those libraries are listed in:
> > 
> > Libs.private:   -lz  -llzma   -lm
> > 
> >   does not mean that some devel packages are needed. Libs.private is
> > used on STATIC linking!!! Use static linking in Fedora is highly
> > REDUCED
> >   So far I did not found even single source code build frameworks
> > querying for Libs.private.
> >   *ALL* of them are asking for "libs".
> 
> Because above I'm not sure is it not will be good add to
> /usr/lib/rpm/pkgconfigdeps.sh remove Libs.private from .pc files.

Thanks for keep replying in same thread about random problems (while they are
not problems in any way) after **2** people asked you to stay on topic.

I'm going to repeat once more, throwing tens of random things in one totally
unrelated thread is not going to help anyone. If you are not satisfied with
anything, make proposal. Discuss each proposal in separate thread. Otherwise
you are just wasting time of everyone who wants to find (for example, what was
conclusion about removal of libxml2-static) outcome of particular thread.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpooz4ACgkQaVcUvRu8
X0wOvQ//Y2ER6AhwCB0IYdIgTfn8BqFot99P4A9H9GpI9PG6ljDcah7cNwVe7S2z
wxz0bSWMYL6OtRgUxE8cZUYkYVGvDb0hEtCdroerF47slm/asnGKPBlZEgx+dmrX
ebibR8o58DlC/igtdh3VYex+AqYO7LIFvB15rdk1mf/0VOGfzlw8XW/6Zj9MtWdF
O6KS/OieqeXPPK8QZAkRKja2BR34OCb6bN6ohc+R2WMwtFvpsCAT/o7wvgDnpnqX
uuKCT2SYN5bxW5wYy2KSQX+BXta6g+ezktfA6HRzRhD8/Mu67m5P92VLkS8/YM7P
CuSelaX38Nvgq5dblSzWT4DcrPxxCxlsE9FuTAHH2nPgTx50TjpSsoNu3e2o9IDK
FkeN+/XQ3cm0E/op0ms2DPIdJQxkOI0mfDLqDz5ztQMoZXdETcikIyHmZnzLPF/A
2WLXkB7Rs6qJvGaF6nMXHpdhrl8WYgSKTeRWg15caWWL+SbZ1e9Qw6oiBFeSUhpx
7u8L8d3c6un/AQYbrhyDr9KfDpqbMNNoRzNsLAx5Z4jJPp421SGN8ogLyRZAuU0V
TXyjBvkQVz9zcuWXM3JN2WcQbwB/B70zWvy6L1VjE9aqMw/QCdlprqR6iezKd5y+
blJ3MrFiRzIpAkNhpKjjlv9SAnclwMjVs2gMLbOYLSwd+681QrQ=
=eyCe
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

2018-01-24 Thread Richard Shaw

I've tried to mostly stay out of this discussion because I to *NOT*
consider myself an expert.

I've been a Fedora package maintainer for several years now and have
learned more than I ever thought I would but I am not:
- a programmer
- an expert git user
- a *nix guru

>From my simplistic point of view I basically have two workflows:

- An end user application which I keep updated to the same version across
all supported Fedora releases (including EPEL where appropriate)

This obviously has the highest likelihood of having conditionals,
especially with an EPEL branch. I pretty much feel the same as Kevin here.
I merge all the branches, otherwise I have to fake upload sources multiple
times, let it calculate the hash and figure out it's already uploaded which
just seems silly, or maybe checkout "sources" from the master branch which
I have learned how to do, but again, I'm not a git expert and to my
knowledge this isn't documented.

The wiki even suggests the method Kevin and I use as the "proper" way...
https://fedoraproject.org/wiki/Package_maintenance_guide#Working_with_branches

- A library where I generally don't push major updates across branches
(without a really good reason)

The best personal example I can think of is OpenImageIO, currently rawhide
is on 1.8.x and Fedora 26 & 27 are on 1.7.x, and EPEL 7 is on 1.5.x, but
was on the same series as Fedora a few releases ago.

Here I only fast-forward merge across branches on the same series/ABI
version, but in the past it included EPEL which means you're more likely to
carry "%if %{rhel}" type conditionals.

If you want packagers (especially those like myself that aren't in IT for
$DAYJOB) to act differently, then the best way is to make sure the workflow
is well documented and that it's the path of least resistance.

As far as obsolete conditionals, I don't personally proactively scrub my
spec files until an update is needed. Here it's would probably be best to
create some automated detection and file a BZ against the package. Maybe
conditionals for Fedora versions N-2 (some people choose to support the
most recently EOL'd version for a little while) and EOL'd EL releases.

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

Build flag injection for qmake

I have a package which indirectly calls qmake (from Qt5).  Is there a 
way to inject the standard build flags using environment variables, or 
do I have to patch the invocation of the qmake command itself to pass 
the flags, similar to what %{qmake_qt5} does?


Would it make to add rpmbuild-qmake or something similar to 
qt5-rpm-macros which get the build flags from CFLAGS/CXX/FLAGS/LDFLAGS 
and pass it to qmake?


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

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

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



--- Comment #2 from Fedora Update System  ---
perl-String-Print-0.93-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-450e4e3b4b

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

[Bug 1224812] Missing dependency: perl(GD)

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



--- Comment #2 from Matěj Cepl  ---
And yes, I agree, it is self-inflicted stupidity.

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

[Bug 1224812] Missing dependency: perl(GD)

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

Matěj Cepl  changed:

   What|Removed |Added

 CC||jose.p.oliveira.oss@gmail.c
   ||om, p...@city-fan.org,
   ||perl-devel@lists.fedoraproj
   ||ect.org,
   ||tcall...@redhat.com
  Component|lcov|perl-GDGraph
   Assignee|mc...@redhat.com|tcall...@redhat.com



--- Comment #1 from Matěj Cepl  ---
What has this to do with lcov?

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

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

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-String-Print-0.93-1.fc
   ||28



--- Comment #1 from Petr Pisar  ---
An enhancement suitable for Fedora ≥ 27.

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

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

2018-01-24 Thread Dominik 'Rathann' Mierzejewski

On Tuesday, 23 January 2018 at 07:36, Igor Gnatenko wrote:
> On Mon, 2018-01-22 at 14:33 -0500, Matthew Miller wrote:
> > On Sat, Jan 20, 2018 at 02:23:16PM +0100, Igor Gnatenko wrote:
> > > What I'm trying to say here is that each time we want to implement
> > > some feature in Fedora, we either need to have some replacement in
> > > EPEL or diverge Fedora branches from EPEL branches. Having
> > > replacement is not always possible, especially if we start utilizing
> > > new (actually 8 years old) features of RPM.
> > 
> > I'd really like to see us tend towards coming up with macros that
> > provide elegant fallbacks on EPEL. (The %license macro is a good
> > example.)
> 
> There is no fallback for rich dependencies. There is no fallback for
> filetriggers.

Just a wild idea, how about:

%if 0%{rhel} && 0%{rhel} < 8
%global recommends Requires
%else
%global recommends Recommends
%endif

and then using

%{recommends}: foo

?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1538065] perl-Log-Report-Optional-1.05 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Log-Report-Optional-1.
   ||05-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-01-24 09:37:21



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 28.

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

[Bug 1538064] perl-Log-Report-1.26 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Log-Report-1.26-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-01-24 09:36:55



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 28.

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

Re: Plan to remove libxml2-static

On 24 January 2018 at 11:21, Tomasz Kłoczko 
wrote:
[..]
>  Fact that those libraries are listed in:
>
> Libs.private:   -lz  -llzma   -lm
>
>   does not mean that some devel packages are needed. Libs.private is
> used on STATIC linking!!! Use static linking in Fedora is highly
> REDUCED
>   So far I did not found even single source code build frameworks
> querying for Libs.private.
>   *ALL* of them are asking for "libs".

Because above I'm not sure is it not will be good add to
/usr/lib/rpm/pkgconfigdeps.sh remove Libs.private from .pc files.

Second widely spread "mistake" related to .pc files is adding to devel
"Requires: pkgconfig"

[tkloczko@domek SPECS.fedora]$ egrep  '^Requires:.*pkgconfig' * | wc -l
909

This is  WRONG by one FUNDAMENTAL fact that pkgconfigdeps.sh script adds
such dependency AUTOMATICALLY!!
Fragment from this script:

---
-R|--requires)
while read filename ; do
case "${filename}" in
*.pc)
i="`expr $i + 1`"
[ $i -eq 1 ] && echo "$pkgconfig"
<<< here
---

BTW: second thing about this script is that first line suggests that it is
bash script when in reality it is PURE POSIX SH sript.
There are TONS of such scripts in Fedora.

back to pkgconfig Require

$ sudo dnf -C repoquery --whatrequires pkgconfig | wc -l
1379

So which one approach is wrong? which one is correct?
Before I point on right solution everyone who will be trying to follow my
way of analyse above myst add two additional conditions/facts:
  - provide by devel pakage .pc file does not mean that such package as
isolated object requires pkgconfig
  - there is only small fraction of the devel packages which may need
"Require: pkgconfig" because inside those devel packages are some shell
scripts like -config script or some m4 macros which are using pkgconf
command from pkgconfig package

So .. what is the answer?
Surprise .. BOTH approaches are WRONG:
BOTH facts should not used as input condition to add manually or
automatically "Requires: pkgconfg" becuse provide m4 macros or -config
scrip does not mean that when "BuildRequires: -devel"will be used in
other packages build procedure any .pc file or pkgconfig command.

Am I right???

So there are two possible solutions:
- if in some spec is used "Build-Requires: -devel" definitelly
MANUALLY should be added:

BuildRequires: pkgconfig

- when is used "BuildRequires: pkgconfig()" it SHOULD or MAY be
treated that during build process pkgconfig will be used.
  So easiest way t deal with this will be as well add to such spec:

BuildRequires: pkgconfig

*If* some will find a way how to add indirect "BuildRequires: pkgconfig"
when "BuildRequires: pkgconfig()" is  used.

Only in this case we are talking about ~2.3k in all {,noarch}.rpm
packages .. BECAUSE (again) pkgconfig should be ONLY used in BuildRequires.

OK .. this is easy to fix (two sed regex + two lines correction
in pkgconfigdeps.sh) -> send all affected packages to the furnace ..
BTW: because above exact chain of logical steps ALL "Requires: pkgconfig"
lines should be removed despite existing rhel/el6/el7/epel %ifings.

Please do not ask anyone I'm right or not (look on: "communal mistakes" )
.. just try to verify above using only and pure LOGIC.
If someone will not crush/disprove above in next few days someone should
take necessary action to remove all those line.
RHEL on next EL6/EL7 update should clean this as well because it will
slightly reduce dependencies between installed rpm packages written in rpm
database.

(kill me) OK .. some kind of bottom small dump of what is bouncing in my
head.

On top of those corrections minimizing only packages dependencies on which
I've been focusing in my free time in last few days I have few other
possible classes of problems.
Are you red alread on your face? OK so ..
After what was done/formed as idea to do mostly by me in PLD many thing and
changing/correcting/fixing using mass changes in mean time probably now
could be added few times more (again .. only related to dependencies).

OK .. II'll only check are you still able to sense pain ;-)

Yes .. we are talking about maybe even +100 possible mass changes.

Now .. if you sill feel the pain I'll try to spread it among other people ..
I cannot do this alone because:
- each such proposal of Mass Change Request will need each time:
  - careful review (because some details or generally whole proposal may be
wrong) ... more eyeballs than better
  - at the end such MCR at least one proven packager will be necessary to
shoot-and-forger at the and such MCR if it will pass whole peer review
process.
  - someone will need to correct/update/add something in FPG or even
rpmlint (something else?)
  - all packagers will be forced learn new things
- I have no proven packager privs and I'm not sure is it still not to early
give me such privs (or give me such privs at all)

Probably many people will be not happy/upset reading about so HUGE possible
of mass changes which may

Re: Starting Boost 1.66.0 rebuilds in f28-boost side tag

2018-01-24 Thread Jonathan Wakely


On 24/01/18 13:51 +, Jonathan Wakely wrote:

On 23/01/18 21:13 +, James Hogarth wrote:

On 23 Jan 2018 15:39, "Jonathan Wakely"  wrote:

As happens for most releases, I'm updating Boost in rawhide and
rebuilding the affected packages in a side tag (f28-boost).

https://fedoraproject.org/wiki/Changes/F28Boost166

If you maintain a package that depends on Boost please coordinate any
updates with me, so that any changes you make in the main f28 target
don't invalidate the rebuilds I'm doing in f28-boost.

I've already identified about a dozen packages that are FTBFS in
rawhide, but only two are due to the Boost update (dssp and domoticz).
The rest are due to package bugs that cause linker errors now the
rpm build flags default to -z defs.

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


Last year I packaged the header only boost library nowide

Do you know if that's been included upstream or if I need to do anything to
align with your update?

It is used for the facter3 update.


The wiki page above lists the new libraries added to Boost, and Nowide
is not among them. According to
http://www.boost.org/community/review_schedule.html it's been accepted
for inclusion, so I assume it will show up in Boost 1.67 or 1.68 (so
in a future version of Fedora).

I doubt boost-nowide needs to be rebuilt, since it's header-only.

facter is being rebuilt in the side tag now:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1020425
If that fails it might mean you need to update boost-nowide to a
version that works with boost-1.66.0


Ah facter failed to build, but only because leatherman and cpp-hocon
haven't been rebuilt yet:

DEBUG util.py:439:  Error:
DEBUG util.py:439:   Problem 1: package leatherman-devel-1.3.0-4.fc28.x86_64 
requires leatherman(x86-64) = 1.3.0-4.fc28, but none of the providers can be 
installed
DEBUG util.py:439:- conflicting requests
DEBUG util.py:439:- nothing provides libboost_system.so.1.64.0()(64bit) 
needed by leatherman-1.3.0-4.fc28.x86_64
DEBUG util.py:439:   Problem 2: package cpp-hocon-devel-0.1.6-3.fc28.x86_64 
requires libcpp-hocon.so.0.1.6()(64bit), but none of the providers can be 
installed
DEBUG util.py:439:- conflicting requests
DEBUG util.py:439:- nothing provides libboost_system.so.1.64.0()(64bit) 
needed by cpp-hocon-0.1.6-3.fc28.x86_64

Those packages weren't tracked in my dependency metadata, so didn't
get rebuilt before facter. I've added the dependencies and will try to
build them again soon.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Starting Boost 1.66.0 rebuilds in f28-boost side tag

2018-01-24 Thread Jonathan Wakely


On 23/01/18 21:13 +, James Hogarth wrote:

On 23 Jan 2018 15:39, "Jonathan Wakely"  wrote:

As happens for most releases, I'm updating Boost in rawhide and
rebuilding the affected packages in a side tag (f28-boost).

https://fedoraproject.org/wiki/Changes/F28Boost166

If you maintain a package that depends on Boost please coordinate any
updates with me, so that any changes you make in the main f28 target
don't invalidate the rebuilds I'm doing in f28-boost.

I've already identified about a dozen packages that are FTBFS in
rawhide, but only two are due to the Boost update (dssp and domoticz).
The rest are due to package bugs that cause linker errors now the
rpm build flags default to -z defs.

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


Last year I packaged the header only boost library nowide

Do you know if that's been included upstream or if I need to do anything to
align with your update?

It is used for the facter3 update.


The wiki page above lists the new libraries added to Boost, and Nowide
is not among them. According to
http://www.boost.org/community/review_schedule.html it's been accepted
for inclusion, so I assume it will show up in Boost 1.67 or 1.68 (so
in a future version of Fedora).

I doubt boost-nowide needs to be rebuilt, since it's header-only.

facter is being rebuilt in the side tag now:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1020425
If that fails it might mean you need to update boost-nowide to a
version that works with boost-1.66.0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Annobin


On 09/27/2017 03:11 PM, Chris Adams wrote:

One thing that is not mentioned: how much information is stored in the
binaries?  How much larger will the resulting binaries be?


We currently see a size increase of about 1% per actually annotated 
executable or DSO in Fedora rawhide.


(But not everything which should be annotated currently is.)

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

Re: Plan to remove libxml2-static

2018-01-24 Thread Jonathan Wakely

On 24/01/18 13:15 +, Tomasz Kłoczko wrote:

On 24 January 2018 at 11:41, Igor Gnatenko Other changes discarded from my set of changes:

Please, don't mix issues / suggestions. I was asking ONLY about
libxml2-static.

And I'm only using your email to show which other changes your radar does
not detected :P

And the request was that you don't do that. Start a new thread for a
separate issue.

I'm using as well such opportunity show broader context that it is not your
generally your fault but probably result that most of the Fedora developers
instead checking simple are assuring that "because no one in Fedora so far
have been doing such correction this guy must be mad/wrong".
Only with with this broader *context* is possible to understand what I'm
trying to do even by junior-Fedora-packager.
Always in each team of scientists/engineers working on something are able
separate "Me/I" from "We" on demand. For most of such people it is the same
so they are not even trying to play with "how such separation may work?"

Here most likely we have typical communal behavior which in the past caused
forming conclusion that "flying objects heavier than air is not possible".
And it was for quite long time "truth" .. until was born someone who didn't
know "that it is not possible" :)

I'm not trying to tell "I'm this only wise guy among idiots".
Even if if may look/sound like this, it is NEVER my intention.

So again .. (other variant)
Please .. don't be nervous because I'm even trying to blame you :)
Please .. really accept that I'm "eating" rpm packages (recently as hobby)
on breakfast at least few times a week .. every week in ~25 years so I have
deeper knowledge about "rpmology" than probably +90% core RH employees
(contributing or not to Fedora).
Whatever I'm doing as a job today I cannot remove from my head what I've
learn NOT reading documentation but by *doing a lot my own experiments*.
In other words in many cases I'm not claiming some things because I'm
guessing or because I've read something.
No I'm using straight my experience because when I've been starting playing
with rpm documentation was ~"symbolical" and I had no at all any fiends
using rpm .. physically in a radius +300km (if not way longer distance). At
this time was only handful people doing thing which at this time attracted
me.
Form one side I was unlucky but from opposite side I was at the same time
extremely .. lucky!!! 8-o

I'm really asking you and other Fedora packagers for ONLY have a bit

closer look of what I'm proposing something
Only this and nothing more :-)

Sorry for above (which off-topic) but I really want to be well understood.
(please do not comment above)

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: Plan to remove libxml2-static

On 24 January 2018 at 11:41, Igor Gnatenko  wrote:
[..]

> > Other changes discarded from my set of changes:
>
> Please, don't mix issues / suggestions. I was asking ONLY about
> libxml2-static.
>

And I'm only using your email to show which other changes your radar does
not detected :P

I'm using as well such opportunity show broader context that it is not your
generally your fault but probably result that most of the Fedora developers
instead checking simple are assuring that "because no one in Fedora so far
have been doing such correction this guy must be mad/wrong".
Only with with this broader *context* is possible to understand what I'm
trying to do even by junior-Fedora-packager.
Always in each team of scientists/engineers working on something are able
separate "Me/I" from "We" on demand. For most of such people it is the same
so they are not even trying to play with "how such separation may work?"

Here most likely we have typical communal behavior which in the past caused
forming conclusion that "flying objects heavier than air is not possible".
And it was for quite long time "truth" .. until was born someone who didn't
know "that it is not possible" :)

I'm not trying to tell "I'm this only wise guy among idiots".
Even if if may look/sound like this, it is NEVER my intention.

So again .. (other variant)
Please .. don't be nervous because I'm even trying to blame you :)
Please .. really accept that I'm "eating" rpm packages (recently as hobby)
on breakfast at least few times a week .. every week in ~25 years so I have
deeper knowledge about "rpmology" than probably +90% core RH employees
(contributing or not to Fedora).
Whatever I'm doing as a job today I cannot remove from my head what I've
learn NOT reading documentation but by *doing a lot my own experiments*.
In other words in many cases I'm not claiming some things because I'm
guessing or because I've read something.
No I'm using straight my experience because when I've been starting playing
with rpm documentation was ~"symbolical"  and I had no at all any fiends
using rpm .. physically in a radius +300km (if not way longer distance). At
this time was only handful people doing thing which at this time attracted
me.
Form one side I was unlucky but from opposite side I was at the same time
extremely .. lucky!!! 8-o

>>>I'm really asking you and other Fedora packagers for ONLY have a bit
closer look of what I'm proposing something
Only this and nothing more :-)

Sorry for above (which off-topic) but I really want to be well understood.
(please do not comment above)

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

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

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



--- Comment #3 from Fedora Update System  ---
perl-threads-shared-1.58-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-6fe92b98df

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

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

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



--- Comment #2 from Fedora Update System  ---
perl-threads-shared-1.58-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-22e63cffa4

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

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

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-threads-shared-1.58-1.
   ||fc28



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

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

[Bug 1537516] perl-threads-2.21 is available

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



--- Comment #2 from Fedora Update System  ---
perl-threads-2.21-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-b77c61238c

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

[Bug 1537516] perl-threads-2.21 is available

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



--- Comment #3 from Fedora Update System  ---
perl-threads-2.21-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-0f208aa267

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

[Bug 1537516] perl-threads-2.21 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-threads-2.21-1.fc28



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable add Fedoras.

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

Re: Proposed Fedora packaging guideline: More Go packaging



- Mail original -
De: "Jakub Cajka"

Hi Jakub,

>> For my part I doubt I'll ever use it in EL6 since I did it
>> for Go and the EL6 Go stack is really too old for a merge to be interesting.
>> Anyway I'll certainly let you know when I feel the time is right (but do not
>> block on me!)

> If we are talking about EPEL6 stack, it is fairly fresh(1.9.2) and stable(it 
> will be on 1.9 for whole of its 
> upstream support), although Go packaging macros are missing.

Yes the core golang package is there but first the other Go macros are not 
available in EL6 and second the software level of many common Go packages is 
very old in EL6.

So, assuming the forge macros just work in EL6, because the little bit of rpm 
lua they need works the same as in EL7 and devel, updating EL6 to the level 
needed for a Go spec to be shared mostly unchanged between EL6/EL7 and devel 
would require:

— making the other Go macros available in EL6 (and I'm far from sure they would 
work unchanged in EL6, the forge part is easy since it's 100% lua but the other 
parts exercise the shell and rpm and other stuff that may behave in a slightly 
different way in such an ancient codebase. Not necessarily a show-stopper but 
definitely something that requires testing and adjusting time by someone)

— updating all the common Go software packages to the same level as in devel. I 
don't say it can't be done (after all I'm doing it for EL7 on hundreds of 
packages) but that's a *lot* more work than just updating a few macro files. 
Especially if it hits bootstraping issues not existing in EL7 and devel.

Therefore, it requires someone with time and motivation, and should really not 
be attempted before EL7 and devel are done and things have settled a bit, and 
by that point will there still be enough interest in upgrading the Go state in 
EL6 for it to be worth the pain?

Of course one could limit oneself to making the macros available (which still 
requires some testing and eventually some code porting), that would enable 
using the same Go spec coding style in EL6 EL7 and devel, if not sharing the 
spec themselves, but the interest of autodeps is severely limited, if you do 
not have a large baseline of packages providing the deps (and the dep version) 
other packages need to build.

That's why I wrote the forge part could be made available in EL6, it depends on 
little except the lua built in rpm, and can be useful as-is, while the Go part 
is something else entirely, as its utility is directly linked to the quantity 
and freshness of Go software packages in the distro.

Regards,

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

[Bug 1511251] perl-User-Identity-0.99 is available

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



--- Comment #5 from Upstream Release Monitoring 
 ---
hotness's scratch build of perl-User-Identity-0.99-1.el7.src.rpm for rawhide
completed http://koji.fedoraproject.org/koji/taskinfo?taskID=24413205

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

[Bug 1511251] perl-User-Identity-0.99 is available

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-User-Identity-0.98 is  |perl-User-Identity-0.99 is
   |available   |available



--- Comment #3 from Upstream Release Monitoring 
 ---
Latest upstream release: 0.99
Current version/release in rawhide: 0.97-3.fc27
URL: http://search.cpan.org/dist/User-Identity/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/6038/

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

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

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

Bug ID: 1538075
   Summary: perl-String-Print-0.93 is available
   Product: Fedora
   Version: rawhide
 Component: perl-String-Print
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.93
Current version/release in rawhide: 0.92-2.fc27
URL: http://search.cpan.org/dist/String-Print/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3343/

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

[Bug 1511251] perl-User-Identity-0.99 is available

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



--- Comment #4 from Upstream Release Monitoring 
 ---
Created attachment 1385549
  --> https://bugzilla.redhat.com/attachment.cgi?id=1385549=edit
[patch] Update to 0.99 (#1511251)

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

Re: Plan to remove libxml2-static

2018-01-24 Thread Neal Gompa

On Wed, Jan 24, 2018 at 4:04 AM, Igor Gnatenko
 wrote:
>
> Hello,
>
> is anybody against of removal of libxml2-static package? It is not used by any
> Fedora package.

I would appreciate it if it wasn't removed. I'm using the
libxml2-static (along with a number of other static libraries) in
experimenting to build a fully static simple package manager for
recovery (initramfs).

-- 
真実はいつも一つ！/ 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: EPEL support in "master" branch (aka speeding up Fedora development)

Igor Gnatenko wrote:
> Why I'm writing this? I want to hear from you if you think it would be
> good to prohibit (or advise, or whatever mechanism would work) usage if
> conditionals in (at least) master branch to allow us to develop features
> faster. Thoughts? Suggestions?

While I would not personally object to banning EPEL conditionals in master 
(though there are others who would), I would most definitely object to 
banning Fedora conditionals in master, and in fact, I would likely stop 
maintaining packages in Fedora dist-git entirely if that were implemented 
and actually enforced. (And if it were implemented and not enforced, I would 
just refuse to follow the rule.)

Fast-forward-mergeability between Fedora branches matters to me. But EPEL is 
indeed a burden to support (because RHEL releases are supported for so long 
and rarely accept backports that allow using newer packaging guidelines) and 
I do not maintain any EPEL branches myself. And you usually don't want to 
track master in EPEL (but maintain the packages more conservatively) anyway. 
So I see the case for keeping those (EPEL) branches separate (from master), 
but not the Fedora ones.

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

[Bug 1538065] New: perl-Log-Report-Optional-1.05 is available

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

Bug ID: 1538065
   Summary: perl-Log-Report-Optional-1.05 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Log-Report-Optional
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.05
Current version/release in rawhide: 1.04-1.fc28
URL: http://search.cpan.org/dist/Log-Report-Optional/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3045/

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

[Bug 1538064] New: perl-Log-Report-1.26 is available

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

Bug ID: 1538064
   Summary: perl-Log-Report-1.26 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Log-Report
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.26
Current version/release in rawhide: 1.25-1.fc28
URL: http://search.cpan.org/dist/Log-Report/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3044/

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

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

Sérgio Basto wrote:
> %if 0%{?fedora}
> BuildRequires: python2-six
> %else
> BuildRequires: python-six
> %endif

BuildRequires: python%{!?rhel:2}-six

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

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

Fabio Valentini wrote:
> My reasoning:
> 
> There are many reasons why .spec files have to diverge between branches,
> including for:
> - mass rebuilds after branching a new fedora release,

That is a limitation in rel-eng tooling: If a mass rebuild is needed after 
branching, it is surely needed in Rawhide too, so what should ideally happen 
is that the commit to mass-rebuild in Rawhide should be fast-forward-merged 
to the branch (when the branches were in sync before the mass rebuild 
commit) instead of bumping the branch separately.

The current mess can be worked around (merge master to the branch, fast-
forward-merge the branch back to the master), but it would be avoidable with 
slightly smarter scripting.

> - rebuilds for .soname changes (usually in rawhide),

That's then just a harmless changelog entry. I don't maintain separate 
branch changelogs for my packages. The changelog is fully accurate only for 
Rawhide, the branches will just have those changes listed even if the build 
never happened for the branch. That is not a catastrophe.

Changelog pedantry is not worth losing the convenience of fast-forwarding 
the branches.

> - bug fixes / patches specific to a certain branch,

These are rare and can be conditionalized. Most patches make sense to apply 
everywhere. Even patches to make the package build with a newer library are 
often written in a way that lets the package still build with the older 
version too. And the few times it is needed, adding a conditional is easy.

> - changed Packaging Guidelines (for example, due to obsolete scriptlets).

At least within Fedora releases, guideline changes are often only made when 
the change works across all supported releases, and IMHO that is how it 
should be. We can easily backport changes to required changes to RPM and 
redhat-rpm-config in updates. But failing that, conditionals can temporarily 
be used, until the old Fedora release goes out of support.

That is more of an issue for EPEL, and I wouldn't object to banning EPEL 
conditionals, but banning Fedora conditionals does not make sense and would 
likely make me stop maintaining packages in the official Fedora dist-git 
entirely.

> All this inevitably leads to diverging %changelogs, Release: tag values -
> and to a lot of conditionals, if the .spec files need to be kept
> "compatible" between branches for some reason.
> 
> In my opinion, the benefit of being able to "merge" (in quotes, because
> merging changelogs doesn't work) newer branches into old ones

I don't understand this obsession about changelogs. I just fast-forward-
merge everything from master into the branches, including the changelog. If 
it lists some rebuild that only happened in Rawhide, or if it doesn't list 
some branch-specific change (after which I usually restore fast-
forwardability using the two-way-merge trick I explained above), so be it.

All the maintainers who keep the branches in sync work that way.

> is dwarfed by the additional burden of maintaining and constantly updating
> all conditionals (which leads to bugs). As Igor mentioned, all rich deps,
> most virtual provides, most scriptlets, etc. have to be wrapped.

Only if you want to support EPEL with the same specfile. I care about fast-
forwardability for Fedora branches only, where that is just not true. (e.g., 
rich deps now just work across all supported Fedora releases).

> As a result, some packagers don't seem to care (or don't have the time) to
> update their packages for changed Guidelines (because adding and
> maintaining all those conditionals correctly is hard, I guess). This leads
> to .spec files for rawhide packages which don't comply with the current
> Packaging Guidelines

I also don't see why this is such a catastrophe. Some of those changes make 
no difference whatsoever to end-users and so there's no rush to make them 
(e.g., changing some package name BuildRequires to a virtual one), others 
are performance improvements of the package update process that are nice, 
but not exactly urgent either (e.g., removing some scriptlet in favor of 
per-transaction file triggers). Our packages have matured so much by now 
that it is rare that packaging guideline changes actually really fix bugs.

> or to bugs or undesired behaviour changes.

And this is why I dislike unnecessary global updates for new cosmetic 
guidelines to begin with. And it will happen the same way no matter whether 
the change is done conditionally or unconditionally, so I don't see how this 
is an issue with conditionals.

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

Update gating: status update and info for owners of blocked updates

2018-01-24 Thread Adam Williamson

Hi folks!

So, I just wrote a note updating the status of the update gating
situation, in the FESCo ticket where turning the gating on was
approved.  If you want all the details (that I know, anyway) of where
we stand and what's going on to try and sort things out, here it is:

https://pagure.io/fesco/issue/1810#comment-490382

Here is the list of updates that are currently blocked because a
blocking test was not run (we think this should only be
`dist.rpmdeplint` now):

https://admin.fedoraproject.org/updates/FEDORA-2018-d7b16276b6 - jridky - 
netpbm-10.81.00-1.fc27
https://admin.fedoraproject.org/updates/FEDORA-2018-d03c2888d4 - spot - 
lapack-3.8.0-4.fc27
https://admin.fedoraproject.org/updates/FEDORA-2018-ccef1ced42 - jridky - 
gimp-2.8.22-3.fc26
https://admin.fedoraproject.org/updates/FEDORA-2018-e6e13349ac - jridky - 
netpbm-10.81.00-1.fc26
https://admin.fedoraproject.org/updates/FEDORA-2018-c2eed6bd99 - psutter - 
iproute-4.14.1-4.fc26
https://admin.fedoraproject.org/updates/FEDORA-2018-22912d80f6 - dwalsh - 
oci-register-machine-0-5.13.git66691c3.fc26
https://admin.fedoraproject.org/updates/FEDORA-2018-95c2176bfc - wsato - 
scap-security-guide-0.1.37-1.fc26
https://admin.fedoraproject.org/updates/FEDORA-2018-32c7201e73 - spot - 
avr-gcc-7.2.0-1.fc27
https://admin.fedoraproject.org/updates/FEDORA-2018-d3be67c603 - wsato - 
scap-security-guide-0.1.37-1.fc27
https://admin.fedoraproject.org/updates/FEDORA-2018-1a4f19f4b9 - dwalsh - 
oci-register-machine-0-5.13.git66691c3.fc27
https://admin.fedoraproject.org/updates/FEDORA-2018-932548462e - rjones - 
ocaml-4.04.0-11.fc26

I'm CCing all those folks. Right now, the only thing you can do to
clear this problem is to un-push and re-push the update. This will
trigger the dist.rpmdeplint test to run again, but will clear all karma
and the 7-day wait clock (I believe). If you don't want to do that, you
will have to wait for one of the other changes discussed in the comment
I posted: the change to allow waiving the absence of a result (at which
point you can just submit a waiver and the update should then be push-
able once Bodhi picks it up), or the change to the actual policy to not
consider 'test missing' a failure, which would make the updates
pushable without you changing anything yourself. Ralph and co. are
working on both those things as a high priority right now, so we should
have updates on that front soon.

I have filed a ticket for the cases where abicheck is overbroad:
https://pagure.io/task-abicheck/issue/8

so that's the place for discussing that issue.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1537837] perl-Sereal-4.005 is available

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



--- Comment #2 from Fedora Update System  ---
perl-Sereal-4.005-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-4226b2da54

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

[Bug 1537837] perl-Sereal-4.005 is available

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



--- Comment #1 from Fedora Update System  ---
perl-Sereal-4.005-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-75ae24ba46

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

Re: Plan to remove libxml2-static

2018-01-24 Thread Igor Gnatenko

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-01-24 at 11:21 +, Tomasz Kłoczko wrote:
> On 24 January 2018 at 09:04, Igor Gnatenko
>  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > Hello,
> > 
> > is anybody against of removal of libxml2-static package? It is not used by
> > any
> > Fedora package.
> 
> It is easy to (simple) check ..
> 
> [tkloczko@domek SPECS.fedora]$ egrep -e 'BuildRequires:.*libxml-static' *
> [tkloczko@domek SPECS.fedora]$

This is exactly what I said, please read my message carefully. I'm asking if
anyone wants it (not from Fedora package).

> 
> Other changes discarded from my set of changes:

Please, don't mix issues / suggestions. I was asking ONLY about libxml2-static.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpocPgACgkQaVcUvRu8
X0wj+hAAg1+vuFjSMX9StQ6m6IF4BqZC3cEy65PJIK1O6dZnElLHvHhLitEhJPcS
PjVWRbfhX+yYdQrvSK4ijmAKYi2/Oj01wiKp0sG8BbhM6Ib1ANxC0mDgkE1pcl0Y
3RUZjDSWf+Kr1NwR5Qhv3cHGxMTBRyZabBb85S+Lp9HAQNhPpoEu9pkuB/JkXzEw
d1NEg9T90NLcfjp8QBH4gD44pFL6SbSMEhYlMRLrFenXVFt2AX4B7GnwyM2iIDzL
ObNlmLcyQu1yVXl85nGAceWUVm+zk+9ae1+BRw6viSC/aMo4oVoAE8VHSla9PJp2
XOweMaZEBalUTXv/rMUns5BI4p6fOZCzCFZ8Xunjp9qsM8tYq4+0Pz9/9kW/v7xp
G4wqpkcJciUxQjLOSltVTSxITTl3mcm7JRB7+4tlNUUXlwYR9axU7suBWh7DAQQw
/WDJEzDWmXZ0FQIeIkH7SvK8yXFGHY4Qs1oRQcsEtRIfEnVUGdZvoh4fAOtyMbV8
0uQMRjWfzgmaYok5UXHByqSDhYiWpz4a0H64Mg3iHOCyhWbv1KQRp0EDeIObp0k4
tZlCgNT8mtM5cVR7i85VoEUDldmdKhMji9kVsPCY+cpVeVAmVDDlawpHSbz8f+gb
a6u/lqfxrQ+aGpa3wYwxyVJ/Ut5RJL5RPIG2lDXg0qH+H1G84qU=
=r5vF
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

2018-01-24 Thread Samuel Rakitničan

> Oh it definitely does.
> 
> I am handling mass rebuilds of Ruby packages or updates of Ruby on
> Rails. This is complex task requiring touching plenty of packages. Due
> to update of Rails in master, I simply cannot contact maintainers of all
> packages and assuring their branches still works. I cannot test the
> .spec files on Rawhide and EPEL just because there is chance somebody is
> going to build the packages on EPEL. At the and, you cannot even trust
> the EPEL macros in Fedora.
> 
> And of course every branch specific branches makes this mass changes
> more complicated, because you simply cannot script it.
> 
> If there were no branch macros and we could consider just Rawhide doing
> such changes, the .spec files in Fedora would be generally i better shape.
> 
> 
> 
> 
> Vít

Maybe a decent compromise would be to make maintainers of such packages 
responsible to fix any incompatibilities introduced by such changes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

2018-01-24 Thread Samuel Rakitničan

> Just FTR: above we have "I think" vs "in practice, it looks not like you
> may think".
> Real engineering is about 1) testing, 2) testing, 3) testing.
> "Assumption" like, "I think" is/should be the real enemy of each
> engineer.
> 
> Stricter use of branching will have yet another effects that for example
> older Fedoras will have less updates.
> IMO those updates should be only about security and critical updates.
> 
> On first look, it may look as the negative side effect because some end
> users/consumers may expect some number of "refreshes" for every Fedora
> release which is still not EOSed like it is now.
> However, as Fedora has short development cycle not releasing those
> "refreshes" for older Fedoras have IMO much greater positive effects:
> 
> 1) easier to test upgrades between Fedora versions
> 
> As each Fedora major release may have in updates only security and critical
> fixes and ABI (libraries SONAME changes) will be completely locked down it
> will be easier work on a set of test units testing upgrades on top of
> different sets of installed packages.

Doesn't relate to packages which rarely see an update if at all.
 
> 2) more people (packagers and regular end users) will be focused on testing
> of latest Fedora version

Do you have some results of a testing or you just assume this would be the case?

> Simple more eyeballs using exact latest Fedora than more likely that after
> hitting sometimes small issue it will be reported to BTS.
> As consequence RH people making own snapshot to start working next major EL
> version may expect that they will have fewer issues to resolve after making
> such snapshot.
> 
> 3) fewer packagers will be spending time on backporting some changes

Doesn't relate to packages which rarely see an update.

> This is as well important because as result those people will have MORE
> time to work on changes on master. In other words, it will allow better
> concentration of limited man/hours resources to make each major Fedora
> release better/more tested.
> 
> 
> There is always cost some changes. There is no "something for nothing".
> IMO in altering general policy about release updates of older Fedora
> version will have the weight of those "good consequences" greater than the
> weight of those "bad effects" which in some people opinion such change may
> introduce.
> Simple it is not possible to make happy everyone and the decisive point
> should be not close to single end-user needs but in point where it is
> possible to have broader/whole view of distribution issues.
> At the moment as master branch is used to make every not EOSed Fedora, it
> forces to use much more complicated by %ifings form of most of the Fedora
> spec files,
> This as consequences make many large-scale distribution changes *much more
> complicated*.
> 
> kloczek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Plan to remove libxml2-static

On 24 January 2018 at 11:21, Tomasz Kłoczko  wrote:
[..]
> It is easy to (simple) check ..
>
> [tkloczko@domek SPECS.fedora]$ egrep -e 'BuildRequires:.*libxml-static' *
> [tkloczko@domek SPECS.fedora]$

Really sorry.
Typo in regexp (s/libxml/libxml2/) but result still is the same:

[tkloczko@domek SPECS.fedora]$ grep -e 'BuildRequires:.*libxml2-static' *
[tkloczko@domek SPECS.fedora]$

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

[Bug 1537837] perl-Sereal-4.005 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC||jples...@redhat.com
   Fixed In Version||perl-Sereal-4.005-1.fc28
   Assignee|ppi...@redhat.com   |jples...@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

Re: Plan to remove libxml2-static

On 24 January 2018 at 09:04, Igor Gnatenko
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello,
>
> is anybody against of removal of libxml2-static package? It is not used by any
> Fedora package.

It is easy to (simple) check ..

[tkloczko@domek SPECS.fedora]$ egrep -e 'BuildRequires:.*libxml-static' *
[tkloczko@domek SPECS.fedora]$


Other changes discarded from my set of changes:

- removed 2nd copy of the libxml2 API documentation (doc/html it is
  the same as in %%{_datadir}/gtk-doc/html/libxml2) and 3rd copy in source xml

  in this case still is (original) copy in devel gzipped xml SOURCE doc

- remove static zlib-devel, xz-devel and pkgconfig Requires in devel
  (none of the libxml2 header files is using zlib or xz headers and
  provide .pc file does not mean that package needs pkgconfig)

 Fact that those libraries are listed in:

Libs.private:   -lz  -llzma   -lm

  does not mean that some devel packages are needed. Libs.private is
used on STATIC linking!!! Use static linking in Fedora is highly
REDUCED
  So far I did not found even single source code build frameworks
querying for Libs.private.
  *ALL* of them are asking for "libs".
  If is used for example in configure.ac are used macros from
/usr/share/aclocal/pkg.m4 or cmake macros from
%{_ibdir}/cmake/libxml2/libxml2-config.cmake which covers probably
~99% of using libxml2.pc none of such uses libxml2 are asking for
libs.private

  This *mistake* is widely spread across MNY Fedora specs. All
Requires manually added in devel should be carefully revived and as
long as  none of the header files are using some *-devel headers many
such dependence is possible to remove.
  Theoretically it is possible to add header files dependencies
generator. When su


- add %%{_libdir}/cmake/libxml2 directory to devel %%files

  [tkloczko@domek libxml2]$ rpm -qf /usr/lib64/cmake/libxml2
  file /usr/lib64/cmake/libxml2 is not owned by any package
  [tkloczko@domek libxml2]$ rpm -qf /usr/lib64/cmake/libxml2/*
  libxml2-devel-2.9.5-2.fc28.x86_64

  It is yet another type of mistake madein MANY Fedora specs.

  [tkloczko@domek SPECS.fedora]$ egrep -e '^%{_.*dir}.*/$' * | wc -l
  13213

  =:-O

  In files should be

  %{_libdir}/cmake/libxml2

  instead (still present):

  %{_libdir}/cmake/libxml2/

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH


> - --
> - -Igor Gnatenko
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpoTCQACgkQaVcUvRu8
> X0yCbhAAku+w8JAHVpftAeDXmTIU6fdF9apBe2Untg7I/A5QLch1PJyLGbEmAxVa
> V5q0odv03MhrnupAqueUppoDSmEq5fVmBFJEgPSr0YITTc4af/TIm5eHbxIylPZJ
> HIkFVUC2b7rlWnlofn9MXFB0PMVg5jeFulm/yWx3GYFfKZtPOJVyVctZnP9trViQ
> LLvV8ufhcj1Kp0xQ+dLpKXhTEc6Xjzj4NuWzEbHpeb1n/CMcfT5YnpRsxuTe3jKO
> tTTEeJBRqjkv0i9jzWI3Pv4f0ezVstWVxgNCMy3IZAI9MbG5mQYSO+0Pf+Fr94CH
> YbLuE87+nv6nLnLR1hhS2pPlqrj065uEfv8eUBdkzonaIh99RsbtfG1V/ufWGusv
> 68oWOue1c6Lx/xyIODksWA1UZewyhy31J7bypPPRT7+Fa8Jo67xr15xxHRV5Cdv4
> 4gMnvHIuoNwqqbAoeJUC7hMNrtzq6+60pfgJsg5yxXtOacGfSfkyy1AvtFogFCR5
> FBvyyyg6AwxKdEDYoPqMVN32uGVUwn9MCTpv8WeP5L6qebpO9pgoecLrbnZuhSi0
> 1dDlsFxJz0X0bL1jWVhmZsxDHAxuqL2XdjFJwNq8o5daMgbGV4Vmr5YNUb0io42i
> CTHAqf0uPhDj2npZ1PXpSFkld7EygEV05kVUNF4bPl6HEBqwzAs=
> =n61B
> -END PGP SIGNATURE-
> ___
> 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

[Bug 1537988] perl-Devel-CheckOS-1.81 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Devel-CheckOS-1.81-1.f
   ||c28
 Resolution|--- |RAWHIDE
Last Closed||2018-01-24 06:07:30



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

Re: -z defs linker flag activated in Fedora rawhide

2018-01-24 Thread Vít Ondruch



Dne 23.1.2018 v 19:03 Daniel P. Berrange napsal(a):
> On Tue, Jan 23, 2018 at 05:56:47PM +, Jonathan Wakely wrote:
>> On 23/01/18 15:38 +0100, Florian Weimer wrote:
>>> We could deactivate -z defs for F28 and reactivate it after the branch
>>> for F29, giving packagers more time to fix issues.
>> I think that might be a good idea (given how late in the F28 process
>> we are) but for many packages it will just mean we have the same
>> problem at the next mass rebuild.
>>
>> Lots of packages don't get rebuilt between releases, so the
>> maintainers won't see any failure for F29 after -z defs becomes the
>> default again, so they won't fix anything.
>>
>> Every package known to have problems now should get added to koschei.
> What needs to be done for this ?  I see my package "libvirt" present
> in its UI
>
>   https://apps.fedoraproject.org/koschei/package/libvirt
>
> but it says
>
>   "Package is currently ineligible for scheduling due to following reasons:
>
> Package is not tracked
> Package dependencies were not resolved yet"
>
> but there's no info about what these reasons really mean, nor how I
> would go about resolving them.

You probably want to go here:

https://apps.fedoraproject.org/koschei/add-packages

And add your packages.

If you want to add the into group, then you want to create the group
prior adding the packages via this link:

https://apps.fedoraproject.org/koschei/add-group


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

Re: ABI gate: internal-only shared object

Jerry James wrote:
> Here's something I didn't expect from the new ABI gate.

Why did you not expect it? I pointed out this exact issue on January 13, 
right after this change was announced, and ~5 days before it was implemented 
without anybody responding to my objection:

https://pagure.io/fesco/issue/1810#comment-488673
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UVMM7O4OEGCNMZ47HN7QYPQDIV2IJZFR/

I wrote there:
> Uh, `dist.abicheck` produces a lot of false positives on:
>
> * libraries that are internal and that nothing should depend on (e.g., in 
> QupZilla, package `qupzilla`),
  ^ That's exactly the case we are in here. ^

> * APIs explicitly documented as "private, can change at any version", as 
> common in all Qt modules (e.g., in QtWebEngine, package
> `qt5-qtwebengine`).
>
> My packages often fail `dist.abicheck`. It is absolutely not realistic to 
> expect it to pass for all updates.

Where do I need to send such information next time for people to actually 
READ it? I sent it both to the FESCo ticket and to the mailing list!

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

Re: Test gating enabled in Bodhi

Rex Dieter wrote:
> Pierre-Yves Chibon wrote:
>> 1. dist.abicheck - to make sure the update's ABI remains stable in a
>>given Fedora release.
> 
> I think it unwise to make item 1 a mandatory item at this point.  I'd
> argue a large number of packages do not provide public api/abi that's
> worth worrying about in this regard.

+1

See:
https://pagure.io/fesco/issue/1810#comment-488673
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UVMM7O4OEGCNMZ47HN7QYPQDIV2IJZFR/

I wrote there:
> Uh, `dist.abicheck` produces a lot of false positives on:
>
> * libraries that are internal and that nothing should depend on (e.g., in 
> QupZilla, package `qupzilla`),
> * APIs explicitly documented as "private, can change at any version", as 
> common in all Qt modules (e.g., in QtWebEngine, package
> `qt5-qtwebengine`).
>
> My packages often fail `dist.abicheck`. It is absolutely not realistic to 
> expect it to pass for all updates.

I don't think gating on this test will EVER be a reasonable thing to do. It 
has just too many false positives. There is no automated way to figure out 
which ABIs are intended to be public and which aren't. And even an API 
"public" at package level can be private at distro level. (Consider a 
library with exactly one package using it. It is always reasonable to bump 
those together in a grouped update. We have several such examples in 
Fedora.)

Adam Williamson wrote:
> Additionally, as Ralph wrote, he has removed abicheck from the list of
> gating tests for now, so you shouldn't need to worry about abicheck
> failures blocking updates, as soon as Bodhi starts applying that
> change.

FYI, it looks like this is already working. (The other thread said it'd take 
only up to 6 hours for Bodhi to pick it up, and indeed, qt5-qtwebengine is 
now showing as passing the gating even though it "fails" the bogus abicheck 
test.)

But why was this check enabled to begin with, when the issues were already 
known (see the above links)? I get the feeling that I am talking to a wall!

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

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

2018-01-24 Thread Daniel P. Berrange

On Tue, Jan 23, 2018 at 02:06:15PM -0500, R P Herrold wrote:
> On Tue, 23 Jan 2018, Daniel P. Berrange wrote:
> 
> > What needs to be done for this ?  I see my package "libvirt" present
> > in its UI
> > 
> >   https://apps.fedoraproject.org/koschei/package/libvirt
> > 
> > but it says
> > 
> >   "Package is currently ineligible for scheduling due to following reasons:
> 
> looking at the 'EPEL 7' tab, I see:
> 
>   Base buildroot for EPEL 7 is not installable. 
> 
> Dependency problems:
> nothing provides requested redhat-release-everything

EPEL is irrelevant for libvirt as it is shipped in base RHEL/CentOS, so
I've never touched anything related to EPEL branches. THe problems I
mention above were listed when I view the rawhide tab.


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: Re: Proposed Fedora packaging guideline: More Go packaging

2018-01-24 Thread Jakub Cajka





- Original Message -
> From: "nicolas mailhot" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, January 23, 2018 7:45:06 PM
> Subject: Re:  Re: Proposed Fedora packaging guideline: More Go packaging
> 
> 
> 
> - Mail original -
> De: "Mátyás Selmeci"
> 
> Hi,
> 
> > This looks pretty cool!
> 
> Thanks for the feedback!
> 
> > One thing I notice in the limitations section of
> > your draft is a lot of "we can't do XXX due to lack of release
> > discipline..."
> 
> > Do you have any recommendations for Go programmers on how to structure
> > their software so that it is easy to package?
> 
> If there is an interest I can add a section on how to make a Go project
> easier to package, sure.
> 
> It won't be earth-shattering, just the Go declination of basic common sense
> rules that are needed in any coding language, that many Go projects already
> apply (unfortunately not all of them):
> 
> — do not change your import path every other month
> — do not make your code accessible through multiple import paths
> – only use smallcaps in your import path (I know some systems are case
> insensitive. Many others are NOT)
> – communicate clearly the canonical import path of the project at the top of
> your README.md
> — if you absolutely need to change your import path fix your code to use the
> new import path do not rely on http redirections
> – that includes testing and example code
> — do not add a .git suffix to your import path
> 
> — use _testdata for all the material needed by unit test

- make sure that all tests and exclusive test dependencies are really only in 
_test.go files

> – put your example code in _examples (with subdirectories if you ship several
> examples). Do not use creative unusual names such as tutorial.
> – do not pepper your subdirectories with .md files. Keep documentation in the
> project root or in a docs root subdirectory if there is too much of it
> — add a one-line summary and a least a § describing what your project does at
> the top of your README.md
> 
> — choose licenses already vetted by Fedora or Debian
> https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses
> – add a licensing file named LICENSE
> — use unmodified plaintext canonical licensing texts, that state the LICENSE
> name at the top of the file
> — if you absolutely want to add an extension to make Windows happy, use
> LICENSE.txt
> — if you absolutely want to name your licensing file something else, please
> do not use something.md
> — do not hide your licensing terms in README.md, do not refer to a license by
> name without providing its text
> 
> – do releases
> — do releases, even for minor fixes. If you haven't felt the need to touch a
> project for months its latest state should be released!
> — do releases, even for projects that can only be called through another
> project. Do not rely on this other project to set code state through
> vendoring (that's easy to do, just propagate the tip project version to the
> ancillary projects at release time, like kubernetes does)
> – use semver for your releases https://semver.org/ Distributors and godep
> will thank you
> – if your project is in git, use a different branch for every major version
> of your project
> — if your project is in git, tag your release x.y.z as x.y.z, or vx.y.z,
> never as vx.y.zprettybeta. Versions and version tags are not the right place
> to document a project maturity.
> — numbers are cheap, never reuse the same number for a pre-release and a
> final release, increase the minor version!
> – please version your import paths with each major release (gopkg.in is good
> for that)

- ideally do major releases in separate branches, so you can do minor 
fixes/releases easily even for older major releases(look at GC) 
- do release whenever you alter your API, extending it, modifying it, removing 
some and document it in the release notes

> 
> – use releases of the projects you depend on
> — never depend on a project that already depends on you (otherwise software
> dependencies stop being a nice directed acyclic graph and you get into
> dependency loop hell. That's a nasic software engineering golden rule, not
> respecting it will bite you sooner or later with or without linux distros,
> despite vendoring)
> – if for some reason, one of the projects you depend on does not release,
> please ask nicely it to do so
> – if for some reason you need a code state in tip which is not in a release,
> please inform the origin you'd like it to do a release, and switch to this
> release as soon as it is available
> – never depend on a commit state somewhere between two releases
> — document the major versions of the stuff you depend on somewhere easy to
> find. If a major version is only usable past as specific minor version,
> document it
> – add a unit test that detects if the project you depend on is missing the
> part that requires being

Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)



- Mail original -
De: "Rafal Luzynski" 
> Hi Rafal
>
>
> > Does that mean it is finally possible for a user to set its default
> > date format to ISO 8601 without switching its language to Danish English?
> > [...]

> No, this was not a part of my work. I was working only on how the
> month names are spelled in different languages. I was not even aware
> that the problem of ISO 8601 date exists. Does it solve your problem
> if you set LC_TIME environment variable to en_DK or some other language?
> It would allow you to keep the rest of the system in your default language.

IIRC this didn't work because instead of just switching datetime to -mm-dd 
it also switched the natural language names of days and months to Danish 
English. Most iso 8601 users want the numeric datetime formats changed 
(yearmonthday, week number and so on), not the natural language  parts. I can 
retest but your suggestion does not look like it would work.

Of course I'm not a glibc localization specialist, I may be wrong, it all looks 
like black magic for a layman like me :(

Regards,

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

Re: Proposed Fedora packaging guideline: More Go packaging

2018-01-24 Thread Jakub Cajka





- Original Message -
> From: "Jason L Tibbitts III" 
> To: "nicolas mailhot" 
> Cc: gol...@lists.fedoraproject.org, "Development discussions related to 
> Fedora" ,
> "Discussion of RPM packaging standards and practices for Fedora" 
> 
> Sent: Tuesday, January 23, 2018 6:00:24 PM
> Subject: Re: Proposed Fedora packaging guideline: More Go packaging
> 
> I wish this message wasn't crossposted everywhere, but I don't want to
> lose any discussion by trimming the CC list.  Sorry if replies generate
> bounces for some.
> 
> > "nm" == nicolas mailhot  writes:
> 
> nm> And the forge macros are now available since
> nm> redhat-rpm-config-73-1.fc28 (I had missed the push due to upstream
> nm> renaming the file). Heartfelt thanks to Jason Tibbitts !
> 
> Please don't forget to let me know when it's time to start thinking
> about pushing this down to F27.  And maybe F26.  And as far as I can
> tell it should work with only minor modification in EPEL7 (via
> epel-rpm-macros).  I don't know about EPEL6, but we really should look
> at it given some of the other discussions about specfile compatibility.
> Some packagers wouldn't ever use it if it doesn't work everywhere.
> 

I think that it would be great to land it also in the EPEL6/7.

JC


> Finally, we should also talk about whether there is any integration or
> automation possible between fedpkg and specfiles configured with these
> macros.
> 
>  - J<
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: More Go packaging

2018-01-24 Thread Jakub Cajka





- Original Message -
> From: "nicolas mailhot" 
> To: "Jason L Tibbitts III" 
> Cc: gol...@lists.fedoraproject.org, "Development discussions related to 
> Fedora" ,
> "Discussion of RPM packaging standards and practices for Fedora" 
> 
> Sent: Tuesday, January 23, 2018 9:28:15 PM
> Subject: Re: Proposed Fedora packaging guideline: More Go packaging
> 
> 
> 
> - Mail original -
> De: "Jason L Tibbitts III"
> 
> > "nm" == nicolas mailhot  writes:
> 
> >nm> And the forge macros are now available since
> >nm> redhat-rpm-config-73-1.fc28 (I had missed the push due to upstream
> >nm> renaming the file). Heartfelt thanks to Jason Tibbitts !
> 
> > Please don't forget to let me know when it's time to start thinking
> > about pushing this down to F27.  And maybe F26.  And as far as I can
> > tell it should work with only minor modification in EPEL7 (via
> > epel-rpm-macros).
> 
> I don't know about EPEL6, but we use it as-is in EL7 and it works just as
> well (except maybe for the %autosetup bits but IIRC that's autosetup which
> is broken in EL7). In fact it has probably been used more heavily in EL7
> than in fedora-devel so far. Maybe it also works in EPEL 6 but I've never
> tried it. I guess it depends mostly on the level of lua support in EL6 rpm
> and rpm-related tools now the forge macro code is lua only. I'm pretty sure
> many of the problems in the early versions of the macro were due to non-lua
> code and its interactions with lua code once the lua-ification started.
> 
> It's a good idea to let people play with it in fedora-devel maybe a month, in
> case I missed something, but from a technical POW I'm prety sure it could be
> merged up to EL7 now. I'll submit fedora-devel specific tweaks later (just
> like I submitted bitkeeper.org support today), right now the code is
> distro-agnostic. For my part I doubt I'll ever use it in EL6 since I did it
> for Go and the EL6 Go stack is really too old for a merge to be interesting.
> Anyway I'll certainly let you know when I feel the time is right (but do not
> block on me!)

If we are talking about EPEL6 stack, it is fairly fresh(1.9.2) and stable(it 
will be on 1.9 for whole of its upstream support), although Go packaging macros 
are missing.

JC

> 
> > Finally, we should also talk about whether there is any integration or
> > automation possible between fedpkg and specfiles configured with these
> > macros.
> 
> I'm afraid my knowledge of recent fedpkg enhancements is too sparse to be of
> any use there. Though I'm not opposed to the idea at all.
> 
> Thanks again!
> 
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)

2018-01-24 Thread Rafal Luzynski

24.01.2018 10:08 nicolas.mail...@laposte.net wrote:
>
>
> Hi Rafal
>
>
> Does that mean it is finally possible for a user to set its default
> date format to ISO 8601 without switching its language to Danish English?
> [...]

No, this was not a part of my work. I was working only on how the
month names are spelled in different languages. I was not even aware
that the problem of ISO 8601 date exists. Does it solve your problem
if you set LC_TIME environment variable to en_DK or some other language?
It would allow you to keep the rest of the system in your default language.

Recently I have suggested to introduce en_EU instead of en_DK, this
could save some people from being confused and ask "what is that Danish
English and why should I use it". But that's a different story.

Regards,

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

Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)


On 01/24/2018 10:08 AM, nicolas.mail...@laposte.net wrote:

Does that mean it is finally possible for a user to set its default date format 
to ISO 8601 without switching its language to Danish English? Windows has been 
allowing that for ages (which is only sensible, since iso 8601 is an 
international standard, and numeric date representation should not depend on a 
particular language).


No, that is an unrelated feature which has not yet been implemented.

Particularly challenging is the choice of week day names and their 
abbreviations.  Do you know what Windows does for them?


I assume that Windows does not use actual ISO 8601, with a 'T' 
separator, and minutes and seconds in the range of 01 … 60 (instead of 
00 … 59).  The later was a mistake, but 'T' is still an integral part of 
ISO 8601 today, but so far, I have not seen anyone requesting ISO 8601 
date format actually wanting it.


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

[Bug 1537992] New: Upgrade perl-Mail-DKIM to 0.52

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

Bug ID: 1537992
   Summary: Upgrade perl-Mail-DKIM to 0.52
   Product: Fedora
   Version: rawhide
 Component: perl-Mail-DKIM
  Assignee: ky...@kylev.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: ky...@kylev.com, perl-devel@lists.fedoraproject.org,
wtog...@gmail.com



Latest Fedora delivers 0.50 version. Upstream released 0.52. When you have free
time, please upgrade it

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

[Bug 1537988] New: perl-Devel-CheckOS-1.81 is available

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

Bug ID: 1537988
   Summary: perl-Devel-CheckOS-1.81 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Devel-CheckOS
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 1.81
Current version/release in rawhide: 1.80-3.fc27
URL: http://search.cpan.org/dist/Devel-CheckOS/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/2824/

-- 
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 Rawhide-20180123.n.1 compose check report

2018-01-24 Thread Fedora compose checker

Missing expected images:

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

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

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

ID: 187574  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/187574
ID: 187599  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/187599
ID: 187628  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/187628
ID: 187629  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/187629
ID: 187682  Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/187682
ID: 187699  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/187699

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

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

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

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

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

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

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

Passed openQA tests: 85/129 (x86_64)

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

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

Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)