Re: systemd package bloat

[Rahul Sundaram]

Hi

On Fri, Nov 6, 2015 at 11:23 AM, Reindl Harald wrote:

>
> the same way as other packages to it?
>
> * see php
> * see httpd
>

More useful if you could submit a spec file patch

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi should strip subjects

[Haïkel]

Again, what you're saying makes sense but if you don't file tickets,
it won't get fixed.

Here's bodhi bug tracker.
https://github.com/fedora-infra/bodhi/issues

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F24: no rsyslog forwarding

[Rahul Sundaram]

Hi

On Fri, Nov 6, 2015 at 12:20 PM, Reindl Harald  wrote:

> to say it in other words: i did not ask for "probably", just pointed out
> that Rawhide is currently broken, that probably systemd or probably rsyslog
> is broken in the one or other direction is clear


Can you file a bug report?

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora Rawhide 20151106 compose check report

[Fedora compose checker]

Missing expected images:

Cloud disk raw i386
Cloud disk raw x86_64
Cloud_atomic disk raw x86_64
Generic boot i386
Generic boot x86_64

No images in this compose but not Rawhide 20151105

No images in Rawhide 20151105 but not this.
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1277708] Please build perl-Canary-Stability for EPEL 5-7 and Fedora 22

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-Canary-Stability-2006-1.el6 has been pushed to the Fedora EPEL 6 testing
repository. If problems still persist, please make note of it in this bug
report.
If you want to test the update, you can install it with
$ su -c 'yum --enablerepo=epel-testing update perl-Canary-Stability'
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-fef73dac9e

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Retire a package from Fedora i686 (not x86_64)

[bitlord]

On Sat, 7 Nov 2015 04:29:48 +0100
Ralf Corsepius  wrote:

> On 11/06/2015 10:00 PM, Kevin Kofler wrote:
> > Germano Massullo wrote:  
> >> For example, SSE3 instructions set is one of the minimum
> >> requirements and 99% of 32 bit only CPUs do not support it. Only
> >> Pentium 4 >= Prescott architecture supports it.  
> >
> > I think building it with SSE3 is better than excluding the
> > architecture entirely. And FYI, requiring SSE3 is not really
> > allowed even for x86_64 (you are allowed to assume only SSE2), so
> > by that argument, there is no architecture left.  
> ACK. Does anybody know if there are any x86_64/64bit-CPUs which do
> not support sse3?
> 
> I don't see sse3 in /proc/cpuinfo of any machine I have, but I also 
> don't see any runtime error/warning from darktable.
> 

SSE3 is reported as 'pni' (Prescott New Instructions) 

> > Of course, a better solution would be to fix the package to work on
> > all CPUs you support.  
> ACK.
> 
> > But if upstream doesn't care, it's going to be a problem. :-(  
> Exactly - That's the actual problem. Upstream does not care and
> Fedora seems unable to address this issue.
> 
> Ralf
> 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Ralf Corsepius]

On 11/07/2015 04:55 AM, Reindl Harald wrote:



Am 06.11.2015 um 20:11 schrieb Germano Massullo:

For example, SSE3 instructions set is one of the minimum requirements
and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >=
Prescott architecture supports it


seriously?


Probably.


with that argumentation Fedora would drop i686 at all
No. darktable handles the situation on sse3-less CPUs gracefully at 
run-time.


The actually problem is darktable wanting to be compiled with -msse3, 
which means being compiled with a Fedora incompatible instruction set, 
on both i386 and x86_64.



well, i don't have any non x86_64 machien but the argumentation is bous
You are right, these days in professional PC-usage, i686ers likely are 
rare and hard to find.


But in personal (private) PC-usage, the situation is different. There, 
5/6-year old 32bit PCs are still wide spread and will be supported by 
Windows for many years. Also consider, people are using Linux on such 
machines to extend these machines life time.


Feel free to drop the i386, if you want drop the end-user/desktop market 
and to leave this market to Ubuntu, Debian and other distributions.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Ralf Corsepius]

On 11/07/2015 05:03 AM, Reindl Harald wrote:



Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:

On 06/11/15 07:29 PM, Ralf Corsepius wrote:

But if upstream doesn't care, it's going to be a problem. :-(

Exactly - That's the actual problem. Upstream does not care and Fedora
seems unable to address this issue.

Ralf


According to my system, it has SSSE3. Is it SSE3?

That's what my question actually was about.

I see ssse3 on all my x86_64ers, I see sse3 on my 32bit atoms, but I 
don't know if ssse3 implies sse3 and I don't know what -msse3 actually 
does to the instruction set when being used on x86_64ers and which 
impact it has (-msse3 is not part of Fedora's gcc implicit CFLAGS).



any system not older than 10 years has SSE3  and frankly systems older
than 10 years are hardly a traget for Fedora at all


So, Fedora or Linux as a resort to escape Windows on old HW is not a 
Fedora target anymore?


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1277708] Please build perl-Canary-Stability for EPEL 5-7 and Fedora 22

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-Canary-Stability-2006-1.el7 has been pushed to the Fedora EPEL 7 testing
repository. If problems still persist, please make note of it in this bug
report.
If you want to test the update, you can install it with
$ su -c 'yum --enablerepo=epel-testing update perl-Canary-Stability'
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-f4b121591f

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 139  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-6828   
chicken-4.9.0.1-4.el6
 121  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 115  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
  47  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8148   
optipng-0.7.5-5.el6
  47  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
  35  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-68a2c2db36   
python-pymongo-3.0.3-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-ba19b1c7eb   
php-horde-horde-5.2.8-1.el6 php-horde-imp-6.2.11-1.el6 
php-horde-ingo-3.2.7-1.el6 php-horde-passwd-5.0.4-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-22dfcb9feb   
drupal7-7.41-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-cb0897945f   
lxc-1.0.7-4.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-28606b6d1d   
perl-HTML-Scrubber-0.15-1.el6.1
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-5d63583df0   
metis-5.1.0-7.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e195439195   
drupal7-jquery_update-2.7-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-967595b7c1   
wildmagic5-5.13-12.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8fc6f35cc9   
MUMPS-5.0.1-4.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-d47ae2d16b   
owncloud-7.0.11-1.el6


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

MUMPS-5.0.1-4.el6
dpm-dsi-1.9.5-11.el6
drupal7-jquery_update-2.7-1.el6
dssp-2.2.1-6.el6
globus-common-16.0-1.el6
globus-gridftp-server-9.0-2.el6
layla-fonts-1.6-2.el6
metis-5.1.0-7.el6
owncloud-7.0.11-1.el6
perl-Canary-Stability-2006-1.el6
php-hamcrest-1.2.2-1.el6
php-nette-tester-1.6.1-1.el6
php-tecnickcom-tc-lib-barcode-1.5.0-1.el6
php-tecnickcom-tc-lib-color-1.6.2-1.el6
rubygem-sequel-4.27.0-2.el6
socket_wrapper-1.1.5-1.el6
wildmagic5-5.13-12.el6

Details about builds:



 MUMPS-5.0.1-4.el6 (FEDORA-EPEL-2015-8fc6f35cc9)
 A MUltifrontal Massively Parallel sparse direct Solver

Update Information:

  MUMPS-5.0.1-4.fc23  - Hardened builds on https://www.drupal.org/node/2598426)

References:

  [ 1 ] Bug #1273670 - drupal7-jquery_update-2.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1273670




 dssp-2.2.1-6.el6 (FEDORA-EPEL-2015-d51ab8cf60)
 Protein secondary structure assignment

Update Information:

Use __global_ldflags and Boost paths unconditionally per review

References:

  [ 1 ] Bug #1203749 - Review Request: dssp - Protein secondary structure 
assignment
https://bugzilla.redhat.com/show_bug.cgi?id=1203749




 globus-common-16.0-1.el6 (FEDORA-EPEL-2015-50bdd6df66)
 Globus Toolkit - Common Library

Update Information:

globus-common-16.0-1.el6  - GT6 update (add globus_extension_get_module_version)
globus-gridftp-server-9.0-2.el6  - GT6 update (Home directory fixes) - GT6
update (add SITE STORATTR command and associated DSI api)  dpm-dsi-1.9.5-11.el6
- Rebuilt for globus-gridftp-server 9.0




 globus-gridftp-server-9.0-2.el6 (FEDORA-EPEL-2015-50bdd6df66)
 Globus Toolkit - Globus GridFTP Server

Update Information:

globus-common-16.0-1.el6  - GT6 update (add globus_extension_get_module_version)
globus-gridftp-server-9.0-2.el6  - GT6 update (Home directory fixes) - GT6
update (add SITE STORATTR command and associated DSI api)  dpm-dsi-1.9.5-11.el6
- Rebuilt for globus-gridftp-server 9.0

Re: Retire a package from Fedora i686 (not x86_64)

[Germano Massullo]

Il 07/11/2015 04:29, Ralf Corsepius ha scritto:
> I don't see sse3 in /proc/cpuinfo of any machine I have, but I also
> don't see any runtime error/warning from darktable.
Because SSE3 is shown as "pni", Prescott New Instructions [1] [2]

[1]: https://en.wikipedia.org/wiki/SSE3
[2]:
http://unix.stackexchange.com/questions/43539/what-do-the-flags-in-proc-cpuinfo-mean

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:

On 06/11/15 07:29 PM, Ralf Corsepius wrote:

But if upstream doesn't care, it's going to be a problem. :-(

Exactly - That's the actual problem. Upstream does not care and Fedora
seems unable to address this issue.

Ralf


According to my system, it has SSSE3. Is it SSE3?
Taken from A10-7400P laptop


any system not older than 10 years has SSE3 and frankly systems older 
than 10 years are hardly a traget for Fedora at all




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Luya Tshimbalanga]

On 06/11/15 07:29 PM, Ralf Corsepius wrote:
> On 11/06/2015 10:00 PM, Kevin Kofler wrote:
>> Germano Massullo wrote:
>>> For example, SSE3 instructions set is one of the minimum
>>> requirements and
>>> 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott
>>> architecture supports it.
>>
>> I think building it with SSE3 is better than excluding the architecture
>> entirely. And FYI, requiring SSE3 is not really allowed even for
>> x86_64 (you
>> are allowed to assume only SSE2), so by that argument, there is no
>> architecture left.
> ACK. Does anybody know if there are any x86_64/64bit-CPUs which do not
> support sse3?
>
> I don't see sse3 in /proc/cpuinfo of any machine I have, but I also
> don't see any runtime error/warning from darktable.
>
>> Of course, a better solution would be to fix the package to work on
>> all CPUs
>> you support.
> ACK.
>
>> But if upstream doesn't care, it's going to be a problem. :-(
> Exactly - That's the actual problem. Upstream does not care and Fedora
> seems unable to address this issue.
>
> Ralf
>
According to my system, it has SSSE3. Is it SSE3?
Taken from A10-7400P laptop.

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 243  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 139  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-6813   
chicken-4.9.0.1-4.el7
  47  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8155   
nagios-4.0.8-1.el7
  35  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-925e9374c9   
python-pymongo-3.0.3-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-234553a060   
mediawiki123-1.23.11-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-b3471305ee   
php-horde-horde-5.2.8-1.el7 php-horde-imp-6.2.11-1.el7 
php-horde-ingo-3.2.7-1.el7 php-horde-passwd-5.0.4-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-02bd65205b   
drupal7-7.41-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-ad1b660a4d   
php-ZendFramework-1.12.16-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-3cdbf28493   
lxc-1.0.7-4.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-97e247eb19   
perl-HTML-Scrubber-0.15-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-22f9be240b   
qemu-2.0.0-1.el7.6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-f5273e10c1   
rabbitmq-server-3.3.5-12.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-f75cdd1774   
metis-5.1.0-7.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-4b33ee7c84   
wildmagic5-5.13-12.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-d6eaf22c8d   
MUMPS-5.0.1-4.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e1379fc854   
owncloud-8.0.9-1.el7


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

MUMPS-5.0.1-4.el7
darktable-1.6.9-2.el7
dpm-dsi-1.9.5-11.el7
drupal7-jquery_update-2.7-1.el7
fontawesome-fonts-4.4.0-2.el7
gajim-0.16.4-3.el7
globus-common-16.0-1.el7
globus-gridftp-server-9.0-2.el7
layla-fonts-1.6-2.el7
metis-5.1.0-7.el7
owncloud-8.0.9-1.el7
perl-Canary-Stability-2006-1.el7
php-composer-installers-1.0.22-1.el7
php-composer-semver-1.1.0-1.el7
php-deepend-Mockery-0.9.3-1.el7
php-guzzlehttp-psr7-1.2.1-1.el7
php-hamcrest-1.2.2-1.el7
php-nette-tester-1.6.1-1.el7
php-tecnickcom-tc-lib-barcode-1.5.0-1.el7
php-tecnickcom-tc-lib-color-1.6.2-1.el7
python-nbxmpp-0.5.3-1.el7
statscache-0.0.4-1.el7
wildmagic5-5.13-12.el7
yad-0.31.2-1.el7
yad-0.31.3-1.el7

Details about builds:



 MUMPS-5.0.1-4.el7 (FEDORA-EPEL-2015-d6eaf22c8d)
 A MUltifrontal Massively Parallel sparse direct Solver

Update Information:

  MUMPS-5.0.1-4.fc23  - Hardened builds on https://bugzilla.redhat.com/show_bug.cgi?id=1273670




 fontawesome-fonts-4.4.0-2.el7 (FEDORA-EPEL-2015-23c4eb81d6)
 Iconic font set

Update Information:

This update ships version 4.4.0 with many more new icons and additionally
includes Embedded OpenType font files as an option for use on the web.




 gajim-0.16.4-3.el7 (FEDORA-EPEL-2015-006703c52f)
 Jabber client written in PyGTK

Update Information:

Gajim 0.16.4 is an upstream bugfix release. To see the changelog and the list of
fixed bugs, visit http://gajim.org/.




 globus-common-16.0-1.el7 (FEDORA-EPEL-2015-74142a285a)
 Globus Toolkit - Common Library

Update Information:

globus-common-16.0-1.el7  - GT6 update (add globus_extension_get_module_version)
globus-gridftp-server-9.0-2.el7  - GT6 update (Home directory fixes) - GT6
update (add SITE STORATTR command and associated DSI api)  dpm-dsi-1.9.5-11.el7
- Rebuilt for globus-gridftp-server 9.0




 globus-gridftp-server-9.0-2.el7 (FEDORA-EPEL-2015-74142a285a)
 Globus Toolkit - Globus GridFTP Server

Re: Retire a package from Fedora i686 (not x86_64)

[Ralf Corsepius]

On 11/06/2015 09:50 PM, Stuart Gathman wrote:

On 11/06/2015 02:11 PM, Germano Massullo wrote:


For example, SSE3 instructions set is one of the minimum requirements
and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >=
Prescott architecture supports it.


For that kind of thing, add a runtime test for required CPU features at
startup.

That's what they actually do.

cf. https://bugzilla.redhat.com/show_bug.cgi?id=1278064#c14
$ darktable
[dt_init] unfortunately we depend on SSE3 instructions at this time.
[dt_init] please contribute a backport patch (or buy a newer processor).



That may not be necessary if the app already fails in a friendly way on
old CPUs (as opposed to hanging or mysterious crashes).


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Ralf Corsepius]

On 11/06/2015 10:00 PM, Kevin Kofler wrote:

Germano Massullo wrote:

For example, SSE3 instructions set is one of the minimum requirements and
99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott
architecture supports it.


I think building it with SSE3 is better than excluding the architecture
entirely. And FYI, requiring SSE3 is not really allowed even for x86_64 (you
are allowed to assume only SSE2), so by that argument, there is no
architecture left.
ACK. Does anybody know if there are any x86_64/64bit-CPUs which do not 
support sse3?


I don't see sse3 in /proc/cpuinfo of any machine I have, but I also 
don't see any runtime error/warning from darktable.



Of course, a better solution would be to fix the package to work on all CPUs
you support.

ACK.


But if upstream doesn't care, it's going to be a problem. :-(
Exactly - That's the actual problem. Upstream does not care and Fedora 
seems unable to address this issue.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 06.11.2015 um 20:11 schrieb Germano Massullo:

For example, SSE3 instructions set is one of the minimum requirements
and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >=
Prescott architecture supports it


seriously?

with that argumentation Fedora would drop i686 at all
well, i don't have any non x86_64 machien but the argumentation is bous



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1272796] ctstream-24 is available

[bugzilla]

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



--- Comment #16 from Fedora Update System  ---
ctstream-24-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1278707] New: perl-SQL-SplitStatement: Failed test t/95-script.t

[bugzilla]

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

Bug ID: 1278707
   Summary: perl-SQL-SplitStatement: Failed test t/95-script.t
   Product: Fedora
   Version: rawhide
 Component: perl-SQL-SplitStatement
  Assignee: emman...@seyman.fr
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org



Description of problem:
Package perl-SQL-SplitStatement fails to build from source in rawhide.

Version-Release number of selected component (if applicable):
1.00020-3.fc24

Steps to Reproduce:
koji build --scratch f24 perl-SQL-SplitStatement-1.00020-3.fc24.src.rpm

Additional info:
This package is tracked by Koschei. See:
https://apps.fedoraproject.org/koschei/package/perl-SQL-SplitStatement

Test failed with new perl-Getopt-Long 3.48

The similar command is called in the test 
$ perl -Ilib bin/sql-split -s --# -f --### -E t/data/create_table.sql 

Current result:
Unknown option: E
Usage:
sql-split [ OPTIONS ] [ FILE(S) ]
sql-split --man

Expected result:
perl -Ilib bin/sql-split -s --# -f --### -E t/data/create_table.sql
CREATE TABLE foo (
foo_field_1 VARCHAR,
foo_field_2 VARCHAR
)--#CREATE TABLE bar (
bar_field_1 VARCHAR,
bar_field_2 VARCHAR
)--#

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1278707] perl-SQL-SplitStatement: Failed test t/95-script.t

[bugzilla]

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



--- Comment #1 from Jitka Plesnikova  ---
The temporary fix for the test is replacing using "-E" by "--empty"

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1278707] perl-SQL-SplitStatement: Failed test t/95-script.t

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com



--- Comment #2 from Petr Pisar  ---
Getopt-Long 3.48 fixed gnu_getopt compatibility mode. In that mode, it consider
"--fo bar" as an option and a positional argument because gnut_getopt mode
would requires "--foo=bar" syntax to make the "bar" a value of "foo" option.

If sql-split uses that mode, you have to call it as -E=t/data/create_table.sql.
If not, it's probably a regressions in the Getopt::Long.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

rawhide report: 20151106 changes

[Fedora Rawhide Report]

Compose started at Fri Nov  6 05:15:03 UTC 2015
Broken deps for i386
--
[IQmol]
IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2
[alliance]
alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2
[eclipse-jbosstools]
eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires 
osgi(org.eclipse.tm.terminal)
[fawkes]
fawkes-core-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10
fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so
fawkes-plugin-xmlrpc-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10
[gcc-python-plugin]
gcc-python2-debug-plugin-0.14-4.fc23.i686 requires gcc = 0:5.1.1-4.fc23
gcc-python2-plugin-0.14-4.fc23.i686 requires gcc = 0:5.1.1-4.fc23
gcc-python3-debug-plugin-0.14-4.fc23.i686 requires gcc = 0:5.1.1-4.fc23
gcc-python3-plugin-0.14-4.fc23.i686 requires gcc = 0:5.1.1-4.fc23
[gnash]
1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_serialization.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-klash-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-plugin-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
[golang-github-kraman-libcontainer]
golang-github-kraman-libcontainer-devel-0-0.4.gitd700e5b.fc24.noarch 
requires golang(github.com/docker/docker/pkg/netlink)
[golang-github-kubernetes-heapster]
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/google/cadvisor/info/v1)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/google/cadvisor/client)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/schema)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/registry)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/pkg)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/machine)

git commits mess up

[Germano Massullo]

I have done some mistakes in [1]

1) I edited the file once to remove 32 bit CPU support, then I have done
the push to master
2) I saw that I have forgotten to add changelog, so I edited the file
again, I made a new push to master
3) I started merging the F21 branch to the master and I got the conflict

I have found a solution like [2], but I am afraid of making things get
worse...

Thank you for your time

[1]: http://pkgs.fedoraproject.org/cgit/darktable.git/tree/darktable.spec
[2]:
http://stackoverflow.com/questions/881092/how-to-merge-a-specific-commit-in-git
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What license is this?

[Neal Gompa]

Err, to answer your question, the License tag should read "BSD".

On Fri, Nov 6, 2015 at 8:59 AM, Neal Gompa  wrote:

> 3-clause BSD. https://opensource.org/licenses/BSD-3-Clause
>
> On Fri, Nov 6, 2015 at 8:58 AM, Neal Becker  wrote:
>
>> I'm trying to package python-cycler for matplotlib.  It has the attached
>> LICENSE file.  What should I put for license: tag?
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What license is this?

[Christian Dersch]

It's 3 clause BSD (as you can see with licensecheck), In license tag: BSD

On 11/06/2015 02:58 PM, Neal Becker wrote:
> I'm trying to package python-cycler for matplotlib.  It has the attached 
> LICENSE file.  What should I put for license: tag?
> 
> 
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: git commits mess up

[Germano Massullo]

Thank you, I was trying to solve with [1] but your
>  $ git checkout master -- darktable.spec  # solve the conflict by taking the 
> file as it is in master
is the key of success :-)

[1]:
https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Kevin Kofler]

Michael Catanzaro wrote:
> I miss QtWebKit. :(
> 
> For those not familiar with the history, QtWebKit was deleted from the
> upstream WebKit project about three years ago after the maintainers
> said they no longer had the resources to continue maintaining it
> upstream. It now lives on KDE.org but it's based on an ancient WebKit
> revision.

It actually lives at qt.io, and is deprecated there. Qt 5.5 is the last 
release series that includes it. Qt 5.6 will no longer include it in the 
tarballs. (We will likely keep QtWebKit 5.5 or a git snapshot available, 
similarly to how this is done with webkitgtk 2.4, but security updates will 
be limited to what we can backport ourselves.)

The situation for Konqueror is even worse because it is stuck on Qt 4 (but 
then again, the Qt 5 QtWebKit is not significantly more modern than the Qt 4 
one (we ship the unofficial "QtWebKit 2.3" release branch for Qt 4, which 
matches what early Qt 5 shipped)).

> I don't know what the security story is there, but I imagine
> not good, and I guess that's why you switched to Firefox?

The reasons they switched (I was against it) include that, and compatibility 
with some websites. The big issue is that Firefox does not integrate at all 
into KDE Plasma. I think Fedora KDE should really have sat out that one 
release cycle on Konqueror and targeted QtWebEngine for F24.

> Now bundling is allowed, you can bring in QtWebEngine, and try porting
> Rekonq to use that. It's sad to be forced to switch to Chromium
> bundleland, but Chromium works well and comes with a top-class sandbox,
> so Rekonq would immediately become about 3252389724x more secure than
> Firefox or Epiphany. Unless you're willing to use QtWebEngine, I see no
> future for Qt-based web browsers. :/

QtWebEngine is definitely the plan for F24. The most likely browser 
candidate (if Konqueror and/or Rekonq don't get a sudden revival of upstream 
activity) is probably Qupzilla, which already has experimental QtWebEngine 
support, and which has some amount of KDE integration. (It uses Qt, it 
should get KDE file dialogs through the KDE/Plasma Qt platform plugin, it 
explicitly supports KWallet through the QtKeychain abstraction.)

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Germano Massullo]

For example, SSE3 instructions set is one of the minimum requirements and
99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott
architecture supports it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1278707] perl-SQL-SplitStatement: Failed test t/95-script.t

[bugzilla]

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



--- Comment #3 from Jitka Plesnikova  ---
If you add 'no_ignore_case' to Getopt::Long::Configure in bin/sql-split, it
will fix the issue.

Due to the last changes in Getopt::Long 2.48, the bundling is disabled when
gnu_compat is enabled. And it causes that single character options are not
treated case-sensitive.

See:
https://metacpan.org/source/JV/Getopt-Long-2.48//lib/Getopt/Long.pm#L897

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1277222] perl-Unicode-Normalize error yumex-dnf

[bugzilla]

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

juanramon...@hotmail.es changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NOTABUG
Last Closed||2015-11-06 12:04:11



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[EPEL-devel] I need a copy of mod_security-2.5.12-2.el6.x86_64

[Harriman, Chad (SAA)]

I have the repo for EPEL synced on my satellite server and the upgrade to 2.7 
broke.  I need to downgrade but I do not have the 
mod_security-2.5.12-2.el6.x86_64 package.
How do I obtain a copy to downgrade?
Chad Harriman
Principal Systems Engineer
U.S. Senate Sergeant At Arms
chad_harri...@saa.senate.gov
(w) 202-224-1592
(c) 202-213-6413

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

Re: [EPEL-devel] I need a copy of mod_security-2.5.12-2.el6.x86_64

[Athmane Madjoudj]

Hi,

On Fri, Nov 6, 2015 at 1:25 PM, Harriman, Chad (SAA) <
chad_harri...@saa.senate.gov> wrote:

> I have the repo for EPEL synced on my satellite server and the upgrade to
> 2.7 broke.  I need to downgrade but I do not have
> the mod_security-2.5.12-2.el6.x86_64 package.
> How do I obtain a copy to downgrade?
>

I guess, you could rebuild EL5 package (it's 2.6.8 + security pacthes),
rules for 2.5 should run fine with 2.6.x.

AFAIK, we don't keep the old version of the package in the repo.


Best regards.

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

Re: [389-devel] Please review: [389 Project] #48257: Fix coverity issues - 08/24/2015

[Rich Megginson]

On 11/05/2015 05:09 PM, Noriko Hosoi wrote:

https://fedorahosted.org/389/ticket/48257

https://fedorahosted.org/389/attachment/ticket/48257/0001-Ticket-48257-Fix-coverity-issues-08-24-2015.patch 




Once this ticket is closed, is it okay to respin nunc_stans which is 
going to be version 0.1.6?


Yes.  After every "batch" of commits to nunc-stans the version should be 
bumped, where "batch" can be a single commit if no other commits are 
planned for the immediate future.




Current: rpm/389-ds-base.spec.in:%global nunc_stans_ver 0.1.5

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


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

Re: [389-devel] please review: Ticket 48335 - lib389 - Add support for SASL and TLS

[Mark Reynolds]

On 11/05/2015 05:42 PM, Rob Crittenden wrote:

Mark Reynolds wrote:

https://fedorahosted.org/389/ticket/48335

https://fedorahosted.org/389/attachment/ticket/48335/0001-Ticket-48335-Add-SASL-support-to-lib389.patch

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

It looks like the only saslmethod support is gssapi. I think I'd
document that in the method header.

Okay I'll add that


What about autobind? Should that be supported as well?
This can be done via a separate ticket - there was no immediate need for 
it (yet)


Thanks,
Mark


rob


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

Re: Retire a package from Fedora i686 (not x86_64)

[Tom Hughes]

On 06/11/15 14:18, Germano Massullo wrote:


I just removed 32bit CPU support from Darktable's spec file due
technical reasons.
Are there any other things I need to clean up in Fedora infrastructure?


Well you should start by reading the relevant guidelines:

https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: packaging golang guidelines (like etcd, consul)

[Adam Goode]

On Mon, Nov 02, 2015 at 09:05:09AM -0500, Matthew Miller wrote:
> On Sun, Nov 01, 2015 at 05:44:42PM +0100, Jan Chaloupka wrote:
> > >are there some fedora guidelines for golang apps?
> > >are there macros and helpers for rpm?
> > https://fedoraproject.org/wiki/PackagingDrafts/Go
> 
> This needs help in going from a draft to real guidelines.
> 

I am also trying to figure this out. Looking at actual
packaged golang things in Fedora, I see quite a difference
between the drafts and what I see in specfiles. There
are a lot of macros copied everywhere.

Is there any more up to date guidance? It would be an
improvement to even just copy/paste emails of discussions
into the bottom of the wiki draft.


Adam
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F24: no rsyslog forwarding

[Reindl Harald]

who is responsible that nothing is forwarded to the traditional syslog?
systemd or rsyslog?

/var/lib/rsyslog/imjournal.state exists and get re-created when it is 
deleted

__

imjournal is configured

$ModLoad imjournal
$MainMsgQueueSize 10
$WorkDirectory /var/lib/rsyslog
$IMJournalStateFile imjournal.state
__

[root@rawhide ~]# cat /var/lib/rsyslog/imjournal.state
s=fd7c18c2f779473fa1b001f7c110f006;i=3b0;b=d7cb147743824c819a33714632f29e16;m=112d9776;t=523e0539c0a26;x=3ff5b07833c8f9c


[root@rawhide ~]# rpm -q rsyslog
rsyslog-8.12.0-2.fc24.x86_64

[root@rawhide ~]# rpm -qa | grep systemd
systemd-227-3.fc24.x86_64
systemd-libs-227-3.fc24.x86_64




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

What is Source0 tag for this?

[Neal Becker]

What is syntax for Source0 tag for git tag v0.9.0 tarball for this?

https://github.com/matplotlib/cycler/tree/v0.9.0

And how can I verify it works?

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What is Source0 tag for this?

[Igor Gnatenko]

https://github.com/matplotlib/cycler/archive/v%{version}/%{name}-%{version}.tar.gz

On Fri, Nov 6, 2015, 4:09 PM Neal Becker  wrote:

> What is syntax for Source0 tag for git tag v0.9.0 tarball for this?
>
> https://github.com/matplotlib/cycler/tree/v0.9.0
>
> And how can I verify it works?
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 

-Igor Gnatenko
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: packaging golang guidelines (like etcd, consul)

[Jakub Cajka]

- Original Message -
> From: "Adam Goode" 
> To: devel@lists.fedoraproject.org
> Cc: "Matthew Miller" 
> Sent: Friday, November 6, 2015 3:47:42 PM
> Subject: Re: packaging golang guidelines (like etcd, consul)
> 
> On Mon, Nov 02, 2015 at 09:05:09AM -0500, Matthew Miller wrote:
> > On Sun, Nov 01, 2015 at 05:44:42PM +0100, Jan Chaloupka wrote:
> > > >are there some fedora guidelines for golang apps?
> > > >are there macros and helpers for rpm?
> > > https://fedoraproject.org/wiki/PackagingDrafts/Go
> > 
> > This needs help in going from a draft to real guidelines.
> > 
> 
> I am also trying to figure this out. Looking at actual
> packaged golang things in Fedora, I see quite a difference
> between the drafts and what I see in specfiles. There
> are a lot of macros copied everywhere.
>

Could you please elaborate. 

> 
> Is there any more up to date guidance? It would be an
> improvement to even just copy/paste emails of discussions
> into the bottom of the wiki draft.
>

This(https://fedoraproject.org/wiki/PackagingDrafts/Go) 
should be most up to date. For discussion see FPC ticket
https://fedorahosted.org/fpc/ticket/382.

Any input will be welcomed.

Jakub

> 
> 
> Adam
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [EPEL-devel] mod_passenger missing from EPEL 6

[Orion Poplawski]

On 11/05/2015 11:30 PM, Rob Nelson wrote:

Hello,

I have previously installed mod_passenger from EPEL 6:

server1$ yum list mod_passenger
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
  * base: centos.den.host-engine.com 
  * epel: mirror.steadfast.net 
  * extras: mirror.unl.edu 
  * updates: centos.host-engine.com 
Installed Packages
mod_passenger.x86_64
3.0.21-11.el6 @epel

However, it no longer exists in EPEL:

server2$ yum list mod_passenger
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
  * base: mirror.cs.uwp.edu 
  * extras: mirror.steadfast.net 
  * updates: mirror.acsnet.com 
Error: No matching Packages to list

I cannot find any notice of this being an orphaned or removed RPM in the
mail list archives since ~April when server1 above was provisioned. Did
I miss something obvious, or is there a notice of this change somewhere
else?

Thank you,

Rob Nelson


Not sure there was an announcement, although it would have been good if 
there was.  As for the reason:


http://pkgs.fedoraproject.org/cgit/rubygem-passenger.git/tree/dead.package?h=el6

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: What is Source0 tag for this?

[Sérgio Basto]

On Sex, 2015-11-06 at 10:08 -0500, Neal Becker wrote:
> What is syntax for Source0 tag for git tag v0.9.0 tarball for this?
> 
> https://github.com/matplotlib/cycler/tree/v0.9.0
> 
> And how can I verify it works?

https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Tags

and 

spectool -g cycler.spec


-- 
Sérgio M. B.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

systemd package bloat

[Reindl Harald]

it's one thing that there is a common tarball containing everything, but 
26 MB, 821 files including /usr/bin/machinectl and 
/usr/lib/systemd/systemd-machined useless on tiny virtual machines is 
too much and the beast is growing slightly


F21: 22 MB
F22: 24 MB
F23: 26 MB

there should be *really* subpackages instead a monoloithic one



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

bodhi should strip subjects

[Reindl Harald]

don't get me wrong, but subjects above 1 KB are a joke and typically 
spammers which try to bypass contentfilters by put the payload in the 
subject header


Nov  4 16:27:42 mail-gw postfix/cleanup[27083]: 3nrX0s6JB2z28: reject: 
header Subject: [Fedora Update] [comment] 
extra-cmake-modules-5.15.0-1.fc23 kf5-5.15.0-1.fc23 
kf5-attica-5.15.0-1.fc23 kf5-baloo-5.15.0-1.fc23 
kf5-bluez-qt-5.15.0-1.fc23 kf5-frameworkintegration-5.15.0-1.fc2 from 
bastion01.fedoraproject.org[209.132.181.2]; 
from= to= proto=ESMTP 
helo=: 5.7.1 Administrative Prohibition 
(Subject-Header Too Long)


Nov  4 16:45:14 mail-gw postfix/smtpd[31719]: NOQUEUE: reject: RCPT from 
mail.drinksector.com[188.64.185.207]: 554 5.7.1 
: Sender address rejected: Administrative 
Prohibition (Sender); from= 
to= proto=ESMTP helo=


Nov  4 17:06:34 mail-gw postfix/cleanup[29157]: 3nrXsk3jCFz28: reject: 
header Subject: [Fedora Update] [comment] 
extra-cmake-modules-5.15.0-1.fc23 kf5-5.15.0-1.fc23 
kf5-attica-5.15.0-1.fc23 kf5-baloo-5.15.0-1.fc23 
kf5-bluez-qt-5.15.0-1.fc23 kf5-frameworkintegration-5.15.0-1.fc2 from 
bastion01.fedoraproject.org[209.132.181.2]; 
from= to= proto=ESMTP 
helo=: 5.7.1 Administrative Prohibition 
(Subject-Header Too Long)


Nov  4 21:55:58 mail-gw postfix/cleanup[29702]: 3nrgHf3yZ7z2B: reject: 
header Subject: [Fedora Update] [comment] 
extra-cmake-modules-5.15.0-1.fc23 kf5-5.15.0-1.fc23 
kf5-attica-5.15.0-1.fc23 kf5-baloo-5.15.0-1.fc23 
kf5-bluez-qt-5.15.0-1.fc23 kf5-frameworkintegration-5.15.0-1.fc2 from 
bastion01.fedoraproject.org[209.132.181.2]; 
from= to= proto=ESMTP 
helo=: 5.7.1 Administrative Prohibition 
(Subject-Header Too Long)




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd package bloat

[Haïkel]

2015-11-06 16:35 GMT+01:00 Reindl Harald :
> it's one thing that there is a common tarball containing everything, but 26
> MB, 821 files including /usr/bin/machinectl and
> /usr/lib/systemd/systemd-machined useless on tiny virtual machines is too
> much and the beast is growing slightly
>
> F21: 22 MB
> F22: 24 MB
> F23: 26 MB
>
> there should be *really* subpackages instead a monoloithic one
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Excellent idea, please file a ticket and it'd be appreciated if you
could send patches.

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd package bloat

[Matthew Miller]

On Fri, Nov 06, 2015 at 04:48:34PM +0100, Haïkel wrote:
> Excellent idea, please file a ticket and it'd be appreciated if you
> could send patches.

Well, see 

However, it probably _is_ the case that a specfile showing how this
would actually work would be a helpful exercise.

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] Ongoing rebuild of Python3.5 in Rawhide

[Jujens]

On 11/04/2015 12:23 PM, Robert Kuska wrote:
> There is ongoing rebuild of Python3.5 in rawhide's side-tag f24-python3.
> 
> I would like to ask all maintainers to rebuild their packages (which
> depend on python3) within the f24-python3 side-tag.
> 
> To rebuild your package simply run:
> `fedpkg build --target f24-python3`
> 
> You can find all packages that were already rebuilt here:
> 
> http://taiga.cloud.fedoraproject.org/project/rkuska-python35-rebuild/kanban
> 
> Feel free to add your package once your build pass successfully. Side-tag
> will be merged hopefully by the end of the week, mass rebuild will follow
> to avoid breakage of rawhide.
> 
> Tracking bug to link rebuild related bugs to:
> https://bugzilla.redhat.com/show_bug.cgi?id=1269756
> 
> 
> 
> https://fedoraproject.org/wiki/Changes/python3.5
> --
> Robert Kuska
> {rkuska}
> 
Hi,

I rebuilt most of my packages with the f24-python3 side tag yesterday.
However, I had to modify the spec file for two of them (python-svgwrite
and python-snappy) and I built them for rawhide today.

From what I understand, the f24-python3 side tag will be merge in
rawhide in some time, so if my package in rawhide have a higher version
in rawhide than in f214-python3, it may cause trouble. So I wander if I
should rebuilt them again with the f24-python3 tag to include my latest
modifications in f24-python3?

Regards,
-- 
Julien Enselme aka Jujens
http://www.jujens.eu/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd package bloat

[Reindl Harald]

Am 06.11.2015 um 17:19 schrieb Matthew Miller:

On Fri, Nov 06, 2015 at 04:48:34PM +0100, Haïkel wrote:

Excellent idea, please file a ticket and it'd be appreciated if you
could send patches.


Well, see 

However, it probably _is_ the case that a specfile showing how this
would actually work would be a helpful exercise.


the same way as other packages to it?

* see php
* see httpd

see kernel with "kernel" just a metapackage pulls all otehr subpackages 
but you can "dnf remove kernel kernel-modules" on virtual machines while 
no upgrade path at all is broken because existing and initial 
installations are unchanged




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora Release Tools team - some house keeping and process changes

[Amanda Carter]

For anyone who isn't already aware, I've partnered with the Fedora release 
tooling folks to help organize work and communication into and out of the team. 
The team is focused on tooling & process in support of the release engineering 
functions of Fedora. The core team consists of Adam Miller, Kushal Das, Dennis 
Gilmore, Luke Macken & Sayan Chowdhury with special guest appearances as 
needed. I've been working with the team for a couple of months now on a trial 
basis and we're making it more official post-F23. We're making a few changes in 
our process to make things more transparent and predictable...

* moving our project work into Taiga [1] & using its kanban board to track what 
we're doing
* publishing our commitments for Fedora releases and our priority pipeline [2] 
so that it's easier to see what's planned (this includes being more diligent 
about filing changes for bigger items)
* regular meetings with some stakeholders to make sure that we're getting the 
right input to the team (I am always open to hear from anyone so shout at me if 
you need to)
* regular backlog grooming meetings with the team to review our priorities on a 
weekly or biweekly basis
* monthly live demos of our completed work

This is still unfolding and we're working out kinks and getting into the swing 
of things, so please bear with us as we do. I wanted to get this note out to 
you all (and feel free to forward) to make sure that everyone was aware of the 
changes and can get engaged in the process. If you have questions, feedback or 
need to reach out at any time, please let me know.

Thanks in advance!

-- 
Amanda Carter

[1] 
http://taiga.cloud.fedoraproject.org/project/acarter-fedora-docker-atomic-tooling/kanban
[2] https://fedoraproject.org/wiki/ReleaseEngineering/PriorityPipeline

PS - adding tflink here b/c I assume I need to be a member of the qa list 
before my message will be sent and I'm waiting for approval there; let me know 
if I need to resend please?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F24: no rsyslog forwarding

[Subhendu Ghosh]

On Nov 6, 2015 9:52 AM, "Reindl Harald"  wrote:
>
> who is responsible that nothing is forwarded to the traditional syslog?
> systemd or rsyslog?
>

Journald is probably hold the log socket and not forwarding to syslog

> /var/lib/rsyslog/imjournal.state exists and get re-created when it is
deleted
> __
>
> imjournal is configured
>
> $ModLoad imjournal
> $MainMsgQueueSize 10
> $WorkDirectory /var/lib/rsyslog
> $IMJournalStateFile imjournal.state
> __
>
> [root@rawhide ~]# cat /var/lib/rsyslog/imjournal.state
>
s=fd7c18c2f779473fa1b001f7c110f006;i=3b0;b=d7cb147743824c819a33714632f29e16;m=112d9776;t=523e0539c0a26;x=3ff5b07833c8f9c
>
>
> [root@rawhide ~]# rpm -q rsyslog
> rsyslog-8.12.0-2.fc24.x86_64
>
> [root@rawhide ~]# rpm -qa | grep systemd
> systemd-227-3.fc24.x86_64
> systemd-libs-227-3.fc24.x86_64
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What license is this?

[Neal Gompa]

3-clause BSD. https://opensource.org/licenses/BSD-3-Clause

On Fri, Nov 6, 2015 at 8:58 AM, Neal Becker  wrote:

> I'm trying to package python-cycler for matplotlib.  It has the attached
> LICENSE file.  What should I put for license: tag?
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F24: no rsyslog forwarding

[Reindl Harald]

Am 06.11.2015 um 18:15 schrieb Subhendu Ghosh:


On Nov 6, 2015 9:52 AM, "Reindl Harald" > wrote:
 >
 > who is responsible that nothing is forwarded to the traditional syslog?
 > systemd or rsyslog?
 >

Journald is probably hold the log socket and not forwarding to syslog


it does not need to Forward the old way hence "ForwardToSyslog=no" and 
instead "$ModLoad imjournal" which is nothing new but don't work at 
Rawhide currecntly while it dooes on F20/F21/F22/f23


http://www.rsyslog.com/doc/v8-stable/configuration/modules/imjournal.html

to say it in other words: i did not ask for "probably", just pointed out 
that Rawhide is currently broken, that probably systemd or probably 
rsyslog is broken in the one or other direction is clear



 > /var/lib/rsyslog/imjournal.state exists and get re-created when it is
deleted
 > __
 >
 > imjournal is configured
 >
 > $ModLoad imjournal
 > $MainMsgQueueSize 10
 > $WorkDirectory /var/lib/rsyslog
 > $IMJournalStateFile imjournal.state
 > __
 >
 > [root@rawhide ~]# cat /var/lib/rsyslog/imjournal.state
 >
s=fd7c18c2f779473fa1b001f7c110f006;i=3b0;b=d7cb147743824c819a33714632f29e16;m=112d9776;t=523e0539c0a26;x=3ff5b07833c8f9c
 >
 >
 > [root@rawhide ~]# rpm -q rsyslog
 > rsyslog-8.12.0-2.fc24.x86_64
 >
 > [root@rawhide ~]# rpm -qa | grep systemd
 > systemd-227-3.fc24.x86_64
 > systemd-libs-227-3.fc24.x86_64




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Pete Walter]

06.11.2015, 17:18, "Germano Massullo" :
> I just removed 32bit CPU support from Darktable's spec file due
> technical reasons.

It is hard to help if you just say "due to technical reasons". What are they?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

What license is this?

[Neal Becker]

I'm trying to package python-cycler for matplotlib.  It has the attached 
LICENSE file.  What should I put for license: tag?Copyright (c) 2015, matplotlib project
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice, this
  list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.

* Neither the name of the matplotlib project nor the names of its
  contributors may be used to endorse or promote products derived from
  this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: git commits mess up

[Kalev Lember]

On 11/06/2015 02:01 PM, Germano Massullo wrote:

1) I edited the file once to remove 32 bit CPU support


Why are you trying to remove 32 bit support in the first place?

--
Kalev
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Retire a package from Fedora i686 (not x86_64)

[Germano Massullo]

I just removed 32bit CPU support from Darktable's spec file due
technical reasons.
Are there any other things I need to clean up in Fedora infrastructure?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [EPEL-devel] I need a copy of mod_security-2.5.12-2.el6.x86_64

[Ken Dreyer]

Yeah, the Koji build has been deleted as well:
http://koji.fedoraproject.org/koji/buildinfo?buildID=242226

It would be a good idea to update your rules for 2.7. That
mod_security-2.5.12-2.el6 build is over four years old and subject to
several CVEs...

CVE-2013-5705
apache2/modsecurity.c in ModSecurity before 2.7.6 allows remote
attackers to bypass rules by using chunked transfer coding with a
capitalized Chunked value in the Transfer-Encoding HTTP header.

CVE-2013-2765
The ModSecurity module before 2.7.4 for the Apache HTTP Server allows
remote attackers to cause a denial of service (NULL pointer
dereference, process crash, and disk consumption) via a POST request
with a large body and a crafted Content-Type header.

CVE-2013-1915
ModSecurity before 2.7.3 allows remote attackers to read arbitrary
files, send HTTP requests to intranet servers, or cause a denial of
service (CPU and memory consumption) via an XML external entity
declaration in conjunction with an entity reference, aka an XML
External Entity (XXE) vulnerability.

CVE-2012-4528
The mod_security2 module before 2.7.0 for the Apache HTTP Server
allows remote attackers to bypass rules, and deliver arbitrary POST
data to a PHP application, via a multipart request in which an invalid
part precedes the crafted data.

CVE-2012-2751
ModSecurity before 2.6.6, when used with PHP, does not properly handle
single quotes not at the beginning of a request parameter value in the
Content-Disposition field of a request with a multipart/form-data
Content-Type header, which allows remote attackers to bypass filtering
rules and perform other attacks such as cross-site scripting (XSS)
attacks. NOTE: this vulnerability exists because of an incomplete fix
for CVE-2009-5031.

- Ken

On Fri, Nov 6, 2015 at 9:02 AM, Athmane Madjoudj
 wrote:
> Hi,
>
> On Fri, Nov 6, 2015 at 1:25 PM, Harriman, Chad (SAA)
>  wrote:
>>
>> I have the repo for EPEL synced on my satellite server and the upgrade to
>> 2.7 broke.  I need to downgrade but I do not have the
>> mod_security-2.5.12-2.el6.x86_64 package.
>> How do I obtain a copy to downgrade?
>
>
> I guess, you could rebuild EL5 package (it's 2.6.8 + security pacthes),
> rules for 2.5 should run fine with 2.6.x.
>
> AFAIK, we don't keep the old version of the package in the repo.
>
>
> Best regards.
>
> -- Athmane
>
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel
>
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] mod_passenger missing from EPEL 6

[Rob Nelson]

That explains it. Thank you!


Rob Nelson
rnels...@gmail.com

On Fri, Nov 6, 2015 at 10:10 AM, Orion Poplawski 
wrote:

> On 11/05/2015 11:30 PM, Rob Nelson wrote:
>
>> Hello,
>>
>> I have previously installed mod_passenger from EPEL 6:
>>
>> server1$ yum list mod_passenger
>> Loaded plugins: fastestmirror
>> Loading mirror speeds from cached hostfile
>>   * base: centos.den.host-engine.com 
>>   * epel: mirror.steadfast.net 
>>   * extras: mirror.unl.edu 
>>   * updates: centos.host-engine.com 
>> Installed Packages
>> mod_passenger.x86_64
>> 3.0.21-11.el6 @epel
>>
>> However, it no longer exists in EPEL:
>>
>> server2$ yum list mod_passenger
>> Loaded plugins: fastestmirror
>> Loading mirror speeds from cached hostfile
>>   * base: mirror.cs.uwp.edu 
>>   * extras: mirror.steadfast.net 
>>   * updates: mirror.acsnet.com 
>> Error: No matching Packages to list
>>
>> I cannot find any notice of this being an orphaned or removed RPM in the
>> mail list archives since ~April when server1 above was provisioned. Did
>> I miss something obvious, or is there a notice of this change somewhere
>> else?
>>
>> Thank you,
>>
>> Rob Nelson
>>
>
> Not sure there was an announcement, although it would have been good if
> there was.  As for the reason:
>
>
> http://pkgs.fedoraproject.org/cgit/rubygem-passenger.git/tree/dead.package?h=el6
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA/CoRA DivisionFAX: 303-415-9702
> 3380 Mitchell Lane  or...@cora.nwra.com
> Boulder, CO 80301  http://www.cora.nwra.com
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel
>
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] epel-devel Digest, Vol 31, Issue 11

[Harriman, Chad (SAA)]

Thanks!
Chad







On 11/6/15, 1:19 PM, "epel-devel-boun...@lists.fedoraproject.org on behalf of 
epel-devel-requ...@lists.fedoraproject.org" 
<epel-devel-boun...@lists.fedoraproject.org on behalf of 
epel-devel-requ...@lists.fedoraproject.org> wrote:

>Send epel-devel mailing list submissions to
>   epel-devel@lists.fedoraproject.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>   https://admin.fedoraproject.org/mailman/listinfo/epel-devel
>or, via email, send a message with subject or body 'help' to
>   epel-devel-requ...@lists.fedoraproject.org
>
>You can reach the person managing the list at
>   epel-devel-ow...@lists.fedoraproject.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of epel-devel digest..."
>
>
>Today's Topics:
>
>   1. Re:  mod_passenger missing from EPEL 6 (Orion Poplawski)
>   2.  I need a copy of mod_security-2.5.12-2.el6.x86_64
>  (Harriman, Chad (SAA))
>   3. Re:  I need a copy of mod_security-2.5.12-2.el6.x86_64
>  (Athmane Madjoudj)
>   4. Re:  mod_passenger missing from EPEL 6 (Rob Nelson)
>   5. Re:  I need a copy of mod_security-2.5.12-2.el6.x86_64
>  (Ken Dreyer)
>
>
>--
>
>Message: 1
>Date: Fri, 6 Nov 2015 08:10:36 -0700
>From: Orion Poplawski <or...@cora.nwra.com>
>To: EPEL Development List <epel-devel@lists.fedoraproject.org>
>Subject: Re: [EPEL-devel] mod_passenger missing from EPEL 6
>Message-ID: <563cc2ec.5030...@cora.nwra.com>
>Content-Type: text/plain; charset=utf-8; format=flowed
>
>On 11/05/2015 11:30 PM, Rob Nelson wrote:
>> Hello,
>>
>> I have previously installed mod_passenger from EPEL 6:
>>
>> server1$ yum list mod_passenger
>> Loaded plugins: fastestmirror
>> Loading mirror speeds from cached hostfile
>>   * base: centos.den.host-engine.com <http://centos.den.host-engine.com>
>>   * epel: mirror.steadfast.net <http://mirror.steadfast.net>
>>   * extras: mirror.unl.edu <http://mirror.unl.edu>
>>   * updates: centos.host-engine.com <http://centos.host-engine.com>
>> Installed Packages
>> mod_passenger.x86_64
>> 3.0.21-11.el6 @epel
>>
>> However, it no longer exists in EPEL:
>>
>> server2$ yum list mod_passenger
>> Loaded plugins: fastestmirror
>> Loading mirror speeds from cached hostfile
>>   * base: mirror.cs.uwp.edu <http://mirror.cs.uwp.edu>
>>   * extras: mirror.steadfast.net <http://mirror.steadfast.net>
>>   * updates: mirror.acsnet.com <http://mirror.acsnet.com>
>> Error: No matching Packages to list
>>
>> I cannot find any notice of this being an orphaned or removed RPM in the
>> mail list archives since ~April when server1 above was provisioned. Did
>> I miss something obvious, or is there a notice of this change somewhere
>> else?
>>
>> Thank you,
>>
>> Rob Nelson
>
>Not sure there was an announcement, although it would have been good if 
>there was.  As for the reason:
>
>http://pkgs.fedoraproject.org/cgit/rubygem-passenger.git/tree/dead.package?h=el6
>
>-- 
>Orion Poplawski
>Technical Manager 303-415-9701 x222
>NWRA/CoRA DivisionFAX: 303-415-9702
>3380 Mitchell Lane  or...@cora.nwra.com
>Boulder, CO 80301  http://www.cora.nwra.com
>
>
>--
>
>Message: 2
>Date: Fri, 6 Nov 2015 12:25:59 +
>From: "Harriman, Chad (SAA)" <chad_harri...@saa.senate.gov>
>To: "epel-devel@lists.fedoraproject.org"
>   <epel-devel@lists.fedoraproject.org>
>Subject: [EPEL-devel] I need a copy of
>   mod_security-2.5.12-2.el6.x86_64
>Message-ID: <559048e5-567d-41ad-ba64-b596868bd...@saa.senate.gov>
>Content-Type: text/plain; charset="utf-8"
>
>I have the repo for EPEL synced on my satellite server and the upgrade to 2.7 
>broke.  I need to downgrade but I do not have the 
>mod_security-2.5.12-2.el6.x86_64 package.
>How do I obtain a copy to downgrade?
>Chad Harriman
>Principal Systems Engineer
>U.S. Senate Sergeant At Arms
>chad_harri...@saa.senate.gov
>(w) 202-224-1592
>(c) 202-213-6413
>
>-- next part --
>An HTML attachment was scrubbed...
>URL: 
><http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20151106/81b7ce43/attachment-0001.html>
>
>--
>
>Message: 3
>Date: Fri, 6 Nov 2015 17:02:11 +0100
>From: Athmane Madjoudj <athm...@fedoraproject.org>
>To: EPEL Development List <epel-devel@lists.fedoraproject.org>
>Subject: Re: [EPEL-devel] I need a copy of
>   mod_security-2.5.12-2.el6.x86_64
>Message-ID:
>   

Re: Retire a package from Fedora i686 (not x86_64)

[Pete Walter]

06.11.2015, 22:11, "Germano Massullo" :For example, SSE3 instructions set is one of the minimum requirements and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott architecture supports it. Prescott is 11 years old. I would expect vast majority of people who are currently running 32 bit Fedora to have newer computers. I would go even as far as to say that nobody who has an older than a 11 year old computer would even try to launch Darktable. And your solution is to just kill it off, because a few ancient computers can't run it?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Michael Catanzaro]

On Fri, 2015-11-06 at 20:07 +0100, Kevin Kofler wrote:
> QtWebEngine is definitely the plan for F24. The most likely browser 
> candidate (if Konqueror and/or Rekonq don't get a sudden revival of
> upstream 
> activity) is probably Qupzilla, which already has experimental
> QtWebEngine 
> support, and which has some amount of KDE integration. (It uses Qt,
> it 
> should get KDE file dialogs through the KDE/Plasma Qt platform
> plugin, it 
> explicitly supports KWallet through the QtKeychain abstraction.)

Best of luck with this. It's important to have a well-integrated web
browser based on a modern rendering engine. I expect you'll have that in the 
KDE spin before we do in Workstation.

Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: git commits mess up

[Mathieu Bridon]

Hi,

On Fri, 2015-11-06 at 14:01 +0100, Germano Massullo wrote:
> I have done some mistakes in [1]
> 
> 1) I edited the file once to remove 32 bit CPU support, then I have
> done the push to master
> 2) I saw that I have forgotten to add changelog, so I edited the file
> again, I made a new push to master
> 3) I started merging the F21 branch to the master and I got the
> conflict
> 
> I have found a solution like [2], but I am afraid of making things
> get worse...

Assuming you want to have exactly the same thing in F21 and master, and
keep the two branches in sync in the future, here is something that can
get you out of this situation:

First, you need to cleanup the master branch, as you committed some
merge conflict indicators (the << === and >>> lines).

So just remove those lines, as well as the "Release: 2%{?dist}" line
(you bumped the release to 3, you don't want to also keep the line
setting it to 2)

Then commit on master.

At this point, you can do this:

 $ git checkout f21
 $ git merge master                       # this causes a merge conflict
 $ git checkout master -- darktable.spec  # solve the conflict by taking the 
file as it is in master
 $ git commit

At this point, the changes that were in master are now also in f21.

But you're not finished, if you really want to keep the branches in
sync from now on, here's the trick:

 $ git checkout master
 $ git merge f21

Now, both master and f21 are pointing to the exact same commit. So just
push and build.

Next time you make a change in master, just merge it in f21 and you
won't have any conflict any more. :)


-- 
Mathieu
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Stuart Gathman]

On 11/06/2015 02:11 PM, Germano Massullo wrote:


For example, SSE3 instructions set is one of the minimum requirements 
and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= 
Prescott architecture supports it.


For that kind of thing, add a runtime test for required CPU features at 
startup.  If you don't want to touch the original code, just add an 
introducer that checks current hardware, then execs the app in /usr/libexec.


That may not be necessary if the app already fails in a friendly way on 
old CPUs (as opposed to hanging or mysterious crashes).

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

Germano Massullo wrote:
> For example, SSE3 instructions set is one of the minimum requirements and
> 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott
> architecture supports it.

I think building it with SSE3 is better than excluding the architecture 
entirely. And FYI, requiring SSE3 is not really allowed even for x86_64 (you 
are allowed to assume only SSE2), so by that argument, there is no 
architecture left.

Of course, a better solution would be to fix the package to work on all CPUs 
you support. But if upstream doesn't care, it's going to be a problem. :-( 
We have a similar issue with QtWebEngine, because Chromium/V8 upstream 
requires SSE2 in their JIT and there is no interpreter fallback. (They are 
now working on an "interpreter" mode, but it is not a real interpreter 
fallback either, some stuff still uses the JIT.)

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Kevin Kofler]

Michael Catanzaro wrote:

> On Fri, 2015-11-06 at 20:07 +0100, Kevin Kofler wrote:
>> QtWebEngine is definitely the plan for F24. The most likely browser
>> candidate (if Konqueror and/or Rekonq don't get a sudden revival of
>> upstream
>> activity) is probably Qupzilla, which already has experimental
>> QtWebEngine
>> support, and which has some amount of KDE integration. (It uses Qt,
>> it
>> should get KDE file dialogs through the KDE/Plasma Qt platform
>> plugin, it
>> explicitly supports KWallet through the QtKeychain abstraction.)
> 
> Best of luck with this. It's important to have a well-integrated web
> browser based on a modern rendering engine. I expect you'll have that in
> the KDE spin before we do in Workstation.

I suspect Qupzilla might actually feel more integrated into GNOME than 
Firefox. You have the Adwaita-Qt theme, the Qt platform plugin system 
supports GTK+ file dialogs, QtKeychain supports gnome-keyring, and Qupzilla 
should also pick up GNOME's fd.o icon theme unlike Firefox.

You could try it with the version we currently have, but beware that it's 
still a QtWebKit version, not the shiny new QtWebEngine stuff. (By the way, 
QtWebEngine support in Qupzilla is apparently no longer experimental. So 
it's just a matter of packaging now.)

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Browser choice in live images

[Kevin Kofler]

Two small corrections about Qupzilla:

I wrote:
> QtWebEngine is definitely the plan for F24. The most likely browser
> candidate (if Konqueror and/or Rekonq don't get a sudden revival of
> upstream activity) is probably Qupzilla, which already has experimental
> QtWebEngine support, and which has some amount of KDE integration. (It

As I pointed out elsewhere in the thread, QtWebEngine support is actually no 
longer experimental, and the current versions are QtWebEngine-only.

> uses Qt, it should get KDE file dialogs through the KDE/Plasma Qt platform
> plugin, it explicitly supports KWallet through the QtKeychain
> abstraction.)

I checked the code and Qupzilla does not use the QtKeychain library, it has 
its own plugin system for that, but yes, it supports both KWallet and
gnome-keyring.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [EPEL-devel] I need a copy of mod_security-2.5.12-2.el6.x86_64

[James Hogarth]

On 6 November 2015 at 21:08, Volker Fröhlich  wrote:
> Am 06.11.2015 um 13:25 schrieb Harriman, Chad (SAA):
>>
>> I have the repo for EPEL synced on my satellite server and the upgrade
>> to 2.7 broke.  I need to downgrade but I do not have
>> the mod_security-2.5.12-2.el6.x86_64 package.
>> How do I obtain a copy to downgrade?
>> Chad Harriman
>> Principal Systems Engineer
>> U.S. Senate Sergeant At Arms
>> /chad_harri...@saa.senate.gov/
>> (w) 202-224-1592
>> (c) 202-213-6413
>>
>>
>>
>> ___
>> epel-devel mailing list
>> epel-devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/epel-devel
>>
>
> By rebuilding the package from commit
> c50316f2698149cea63cd08510321495c6ce1a29 in the el6 branch of the
> mod_security git repo.
>
> I did that for you. I can understand if you don't trust me, but it takes me
> a lot more time to explain it than to do it.
>
> If you like to, you can inspect the src.rpm file I built from that commit
> and build it in mock yourself or do it on COPR.
>
> http://www.geofrogger.net/review/mod_security-debuginfo-2.5.12-2.el6.x86_64.rpm
> http://www.geofrogger.net/review/mod_security-2.5.12-2.el6.x86_64.rpm
> http://www.geofrogger.net/review/mod_security-2.5.12-2.el6.src.rpm
>


Do bear in mind the list of CVEs already provided before rolling this
out however...
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel