Re: tomcat-native orphaned

[Peter Boy]

I appreciate very much we’ll keep tomcat-native in the Fedora repositories, 
thanks to Lorenzo. Although, I don’t grasp how Java Keystores could be a 
replacement. 




> Am 22.07.2015 um 05:05 schrieb Nico Kadel-Garcia :
> 
> On Wed, Jul 15, 2015 at 11:30 AM, Lorenzo Dalrio
>  wrote:
>> Taken. :)
> 
> Is there really a need for it? Given that tomcat has good support for
> java "keystore", even keystores with poorly passphrased keys, is there
> really a need for this package?
> 
> 


—
Dr. Peter Boy
Universität Bremen
Mary-Somerville-Str. 5
28359 Bremen
Germany

p...@zes.uni-bremen.de
www.zes.uni-bremen.de



Are you looking for a web content management system for scientific research 
organizations?
Have a look at http://www.scientificcms.org

-- 
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: F-23 Branched report: 20150720 changes

[Parag Nemade]

Hi,

On Wed, Jul 22, 2015 at 10:38 AM, Milan Crha  wrote:

> On Wed, 2015-07-22 at 06:48 +0200, Milan Crha wrote:
> > Furthermore, I run my rawhide machine today and tried `dnf update`,
> > which didn't offer me the update of the evolution-data-server. I'd
> > expect to have it offered after two days of the koji build.
> >
> > Maybe I missed some policy/update change?
> >
>
> Hi again,
> it looks like a dnf issue, see below. Even manual update from
> dnf-1.0.1-3.fc23.noarch to dnf-1.0.2-2.fc24.noarch didn't help.
> Bye,
> Milan
>
> $ dnf list evolution
> Fedora - Rawhide - Developmental packages for t 792 kB/s |  43 MB 00:55
> Last metadata expiration check performed 0:00:47 ago on Tue Jul 21
> 23:49:59 2015.
> Installed Packages
> evolution.x86_64  3.17.3-1.fc23
> @System
> Available Packages
> evolution.i6863.17.4-1.fc24
> rawhide
> evolution.x86_64  3.17.4-1.fc24
> rawhide
> $ su
> Password:
> # dnf update
> Fedora - Rawhide - Developmental packages for t 784 kB/s |  43 MB 00:55
> Last metadata expiration check performed 0:00:35 ago on Tue Jul 21
> 23:51:51 2015.
> Dependencies resolved.
> Nothing to do.
> Complete!
>


You need to check broken dependencies as
 # dnf update evolution --best
Last metadata expiration check performed 0:01:32 ago on Thu Jul 23 05:44:09
2015.
Error: package gnome-shell-3.17.3-2.fc23.x86_64 requires
libcamel-1.2.so.53()(64bit), but none of the providers can be installed

I think you need to build gnome-shell update that will depend on new
evolution update.

Regards,
Parag.
-- 
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: F-23 Branched report: 20150720 changes

[Milan Crha]

On Wed, 2015-07-22 at 06:48 +0200, Milan Crha wrote:
> Furthermore, I run my rawhide machine today and tried `dnf update`,
> which didn't offer me the update of the evolution-data-server. I'd
> expect to have it offered after two days of the koji build.
> 
> Maybe I missed some policy/update change?
> 

Hi again,
it looks like a dnf issue, see below. Even manual update from
dnf-1.0.1-3.fc23.noarch to dnf-1.0.2-2.fc24.noarch didn't help.
Bye,
Milan

$ dnf list evolution
Fedora - Rawhide - Developmental packages for t 792 kB/s |  43 MB 00:55
Last metadata expiration check performed 0:00:47 ago on Tue Jul 21 23:49:59 
2015.
Installed Packages
evolution.x86_64  3.17.3-1.fc23  @System
Available Packages
evolution.i6863.17.4-1.fc24  rawhide
evolution.x86_64  3.17.4-1.fc24  rawhide
$ su
Password: 
# dnf update
Fedora - Rawhide - Developmental packages for t 784 kB/s |  43 MB 00:55
Last metadata expiration check performed 0:00:35 ago on Tue Jul 21 23:51:51 
2015.
Dependencies resolved.
Nothing to do.
Complete!
-- 
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: F-23 Branched report: 20150720 changes

[Milan Crha]

On Mon, 2015-07-20 at 08:58 -0600, Kevin Fenzi wrote:
> Should be fixed for tomorrows composes I would expect.

Hi,
doesn't seem to. I made an update for rawhide and f23 branch with
evolution-data-server on Monday morning CEST. I know it breaks some
dependencies, because there had been done soname version bump, but I
didn't receive any notice of it yet. The usually arrive the next day.

Furthermore, I run my rawhide machine today and tried `dnf update`,
which didn't offer me the update of the evolution-data-server. I'd
expect to have it offered after two days of the koji build.

Maybe I missed some policy/update change?
Bye,
Milan
-- 
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: tomcat-native orphaned

[Nico Kadel-Garcia]

On Wed, Jul 15, 2015 at 11:30 AM, Lorenzo Dalrio
 wrote:
> Taken. :)

Is there really a need for it? Given that tomcat has good support for
java "keystore", even keystores with poorly passphrased keys, is there
really a need for this package?


> 2015-07-14 23:11 GMT+02:00 Ville Skyttä :
>> I've just released ownership of tomcat-native and there are no
>> co-maintainers, go grab it if you like.
>> --
>> 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Orphaning vaspview

[Dominik 'Rathann' Mierzejewski]

Hello, everyone!

I've just orphaned vaspview (f23+ only). It's been a very low maintenance
package so far, even though upstream made no releases since the package
entered Fedora.

However, it's FTBFS with latest gcc recently and I've been unable to
fix it myself. I don't use it and I have no contact with anyone who
does anymore. Feel free to pick it up.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
-- 
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: Hosting End-Of-Life Fedora Base images?

[Adam Miller]

On Tue, Jul 21, 2015 at 2:52 PM, Richard W.M. Jones  wrote:
> On Tue, Jul 21, 2015 at 11:05:19AM -0500, Adam Miller wrote:
>> On Mon, Jul 20, 2015 at 2:33 PM, Chris Murphy  
>> wrote:
>> > Isn't it true the install media ISOs are available indefinitely? And
>> > if so the security cat is already out of the bag, so that's not a very
>> > good argument. I'd say if we wanted to do something better it would be
>> > an image that's usable for both VM and containers, and would be the
>> > state of that version at the time it went EOL, i.e. it has all
>> > available updates baked into it. And then de-emphasize the original
>> > ISO as the way to run older versions of Fedora.
>>
>> It is true that install media ISOs are available forever, but we don't
>> go backwards in time and create vagrant boxes or IaaS cloud qcow
>> images of old EOL'd Fedora releases that went EOL before those
>> technologies existed and/or became popular.
>
> I am actually, for virt-builder.  There's a bunch of reasons to do
> this.  Whether they are good or not, you can decide, but here they
> are:
>
>  - Test images for detection of old versions of Fedora/RHEL/etc
>(for virt-inspector and other monitoring tools).
>
>  - Test images for virt-v2v.
>
>  - Environments for reproducing old bugs (however I would generally
>reject a bug report if it referred to some ancient / EOL'd Fedora).
>

Which is totally fine.

I'm not saying that nobody should do it, I'm saying that Fedora
Release Engineering does not currently, nor have they ever, do this in
an official context as an official deliverable from the Fedora
Project.

My question to the group is, "should we be doing this as an official
deliverable of the Fedora Project?" and not, "should anyone ever do
this?"

All the bits are available and people can do with them what they
please (within Trademark Guidelines of course), but I'm just trying to
get a feel for if people want to see this done in an official
capacity.

-AdamM

> 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
> 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: Hosting End-Of-Life Fedora Base images?

[Richard W.M. Jones]

On Tue, Jul 21, 2015 at 11:05:19AM -0500, Adam Miller wrote:
> On Mon, Jul 20, 2015 at 2:33 PM, Chris Murphy  wrote:
> > Isn't it true the install media ISOs are available indefinitely? And
> > if so the security cat is already out of the bag, so that's not a very
> > good argument. I'd say if we wanted to do something better it would be
> > an image that's usable for both VM and containers, and would be the
> > state of that version at the time it went EOL, i.e. it has all
> > available updates baked into it. And then de-emphasize the original
> > ISO as the way to run older versions of Fedora.
> 
> It is true that install media ISOs are available forever, but we don't
> go backwards in time and create vagrant boxes or IaaS cloud qcow
> images of old EOL'd Fedora releases that went EOL before those
> technologies existed and/or became popular.

I am actually, for virt-builder.  There's a bunch of reasons to do
this.  Whether they are good or not, you can decide, but here they
are:

 - Test images for detection of old versions of Fedora/RHEL/etc
   (for virt-inspector and other monitoring tools).

 - Test images for virt-v2v.

 - Environments for reproducing old bugs (however I would generally
   reject a bug report if it referred to some ancient / EOL'd Fedora).

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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Hosting End-Of-Life Fedora Base images?

[Petr Spacek]

On 21.7.2015 19:47, Corey Sheldon wrote:
> +1 for not  allowing EOL
> 
> Corey W Sheldon
> Freelance IT Consultant, Multi-Discipline Tutor
> Ameridea LLC, Co-Founder, CTO
> (p) +1 (310) 909-7672
> 
> "One must never underestimate the power of boredom...from which
> creativity and laziness are borne, which can spark great works of chaos and
> genius."
> 
> Find Me  on any of the sites  I teach /frequent:
> https://gist.github.com/linux-modder/ac5dc6fa211315c633c9
> ---
> Tox:
> core...@toxme.se
> 9357BC6A5944A08AFC7D1EFFD61F6A73B9EABF8B2FB84ACF1DAC9A1A4D0A4705FFCCD0E5499B
> PGP: 718BF597
>  FP: 2930
> 99EB 083D D332 0752 88C4 E958 C5D6 718B F597
> ---
> 
> On Tue, Jul 21, 2015 at 12:12 PM, Daniel P. Berrange 
> wrote:
> 
>> On Tue, Jul 21, 2015 at 11:05:19AM -0500, Adam Miller wrote:
>>> On Mon, Jul 20, 2015 at 2:33 PM, Chris Murphy 
>> wrote:
 Isn't it true the install media ISOs are available indefinitely? And
 if so the security cat is already out of the bag, so that's not a very
 good argument. I'd say if we wanted to do something better it would be
 an image that's usable for both VM and containers, and would be the
 state of that version at the time it went EOL, i.e. it has all
 available updates baked into it. And then de-emphasize the original
 ISO as the way to run older versions of Fedora.
>>>
>>> It is true that install media ISOs are available forever, but we don't
>>> go backwards in time and create vagrant boxes or IaaS cloud qcow
>>> images of old EOL'd Fedora releases that went EOL before those
>>> technologies existed and/or became popular. I don't see why we would
>>> start doing so now for docker images.
>>
>> The security downsides of officially distributed docker images for EOL
>> versions are already mentioned, and i think that alone should be enough
>> to kill the idea. Beyond that though, making these EOL images available
>> is going to consume a non-zero amount of maintainer time for at least
>> one person, thus inevitably diverting resources away from making current
>> non-EOL Fedora better.
>>
>> Avoiding maintainer time being sucked up on old releases is why we EOL
>> them in the first place, and the rationale for existence of long term
>> support alternatives like RHEL & CentOS. So I don't think we should
>> consider cloud images any differently in that respect. Fedora is about
>> being at the cutting edge and that's where we should focus our limited
>> resources, even for cloud images.
>>
>> If people want cloud images with older software versions than are in the
>> current supported Fedora, they should be looking for cloud images from
>> CentOS/RHEL instead.

All EOL software should die by a violent death.

We have enough nightmares caused by buggy software which is not-yet EOL,
please do not add another pile of ...

-- 
Petr Spacek  @  Red Hat
-- 
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: Hosting End-Of-Life Fedora Base images?

[Corey Sheldon]

+1 for not  allowing EOL

Corey W Sheldon
Freelance IT Consultant, Multi-Discipline Tutor
Ameridea LLC, Co-Founder, CTO
(p) +1 (310) 909-7672

"One must never underestimate the power of boredom...from which
creativity and laziness are borne, which can spark great works of chaos and
genius."

Find Me  on any of the sites  I teach /frequent:
https://gist.github.com/linux-modder/ac5dc6fa211315c633c9
---
Tox:
core...@toxme.se
9357BC6A5944A08AFC7D1EFFD61F6A73B9EABF8B2FB84ACF1DAC9A1A4D0A4705FFCCD0E5499B
PGP: 718BF597
 FP: 2930
99EB 083D D332 0752 88C4 E958 C5D6 718B F597
---

On Tue, Jul 21, 2015 at 12:12 PM, Daniel P. Berrange 
wrote:

> On Tue, Jul 21, 2015 at 11:05:19AM -0500, Adam Miller wrote:
> > On Mon, Jul 20, 2015 at 2:33 PM, Chris Murphy 
> wrote:
> > > Isn't it true the install media ISOs are available indefinitely? And
> > > if so the security cat is already out of the bag, so that's not a very
> > > good argument. I'd say if we wanted to do something better it would be
> > > an image that's usable for both VM and containers, and would be the
> > > state of that version at the time it went EOL, i.e. it has all
> > > available updates baked into it. And then de-emphasize the original
> > > ISO as the way to run older versions of Fedora.
> >
> > It is true that install media ISOs are available forever, but we don't
> > go backwards in time and create vagrant boxes or IaaS cloud qcow
> > images of old EOL'd Fedora releases that went EOL before those
> > technologies existed and/or became popular. I don't see why we would
> > start doing so now for docker images.
>
> The security downsides of officially distributed docker images for EOL
> versions are already mentioned, and i think that alone should be enough
> to kill the idea. Beyond that though, making these EOL images available
> is going to consume a non-zero amount of maintainer time for at least
> one person, thus inevitably diverting resources away from making current
> non-EOL Fedora better.
>
> Avoiding maintainer time being sucked up on old releases is why we EOL
> them in the first place, and the rationale for existence of long term
> support alternatives like RHEL & CentOS. So I don't think we should
> consider cloud images any differently in that respect. Fedora is about
> being at the cutting edge and that's where we should focus our limited
> resources, even for cloud images.
>
> If people want cloud images with older software versions than are in the
> current supported Fedora, they should be looking for cloud images from
> CentOS/RHEL instead.
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
> --
> 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: Improving our processes for new contributors.

[Neal Gompa]

On Tue, Jul 21, 2015 at 11:32 AM, Kevin Fenzi  wrote:

> On Tue, 21 Jul 2015 16:23:34 +0200
> Miroslav Suchý  wrote:
>
> > Dne 21.7.2015 v 15:23 Neal Gompa napsal(a):
> > > It's extraordinarily slow right now, and builders don't have the
> > > level of availability needed to support it being part of the review
> > > process.
> >
> > While this was true in past, this changed a lot in past two months.
> > Occasionally we have issues with PPC64LE builders as they are quite
> > new to us. However Intel builders are very stable and there is lot of
> > them there now (28 right now). You can hardly see some queue there.
> > All task are processed immediately.
>
> Yeah, I was going to ask for more details about this also.
>
> Where do you see the slowness in the process? Uploading? Building?
>
> kevin
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​Accessing the Copr site is as slow as trying to search our Bugzilla (which
is very slow indeed). Opening up pages describing Copr repos is slow too. I
occasionally get browser timeouts accessing Copr. As for builds, those seem
to be okay, but everything else is obnoxiously slow.

If I want to be *really* nitpicky, it's also not picking up my
libravatar.org avatar either. ​

​And it's definitely not my internet connection, as I can easily pull down
a Fedora Server DVD ISO in less than 10 minutes.​


-- 
真実はいつも一つ！/ 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: Hosting End-Of-Life Fedora Base images?

[Daniel P. Berrange]

On Tue, Jul 21, 2015 at 11:05:19AM -0500, Adam Miller wrote:
> On Mon, Jul 20, 2015 at 2:33 PM, Chris Murphy  wrote:
> > Isn't it true the install media ISOs are available indefinitely? And
> > if so the security cat is already out of the bag, so that's not a very
> > good argument. I'd say if we wanted to do something better it would be
> > an image that's usable for both VM and containers, and would be the
> > state of that version at the time it went EOL, i.e. it has all
> > available updates baked into it. And then de-emphasize the original
> > ISO as the way to run older versions of Fedora.
> 
> It is true that install media ISOs are available forever, but we don't
> go backwards in time and create vagrant boxes or IaaS cloud qcow
> images of old EOL'd Fedora releases that went EOL before those
> technologies existed and/or became popular. I don't see why we would
> start doing so now for docker images.

The security downsides of officially distributed docker images for EOL
versions are already mentioned, and i think that alone should be enough
to kill the idea. Beyond that though, making these EOL images available
is going to consume a non-zero amount of maintainer time for at least
one person, thus inevitably diverting resources away from making current
non-EOL Fedora better.

Avoiding maintainer time being sucked up on old releases is why we EOL
them in the first place, and the rationale for existence of long term
support alternatives like RHEL & CentOS. So I don't think we should
consider cloud images any differently in that respect. Fedora is about
being at the cutting edge and that's where we should focus our limited
resources, even for cloud images.

If people want cloud images with older software versions than are in the
current supported Fedora, they should be looking for cloud images from
CentOS/RHEL instead.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
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: F23 Self Contained Change: RPM MPI Requires Provides

[Sandro Mani]

On 21.07.2015 18:03, Orion Poplawski wrote:

On 07/21/2015 09:45 AM, Sandro Mani wrote:


On 21.07.2015 17:41, Orion Poplawski wrote:

On 07/17/2015 09:50 AM, Sandro Mani wrote:

Yep - I'm now building things in copr [1].


[1] https://copr.fedoraproject.org/coprs/smani/rpm-mpi-hooks-testing/

Great.  Looks like you need to build a newer openmpi package in your copr
since I updating it to 1.8.7 in rawhide.

Yes - I'm having some problems with yum in copr not resolving the
dependencies, i.e.

DEBUG util.py:378:  Error: Package: blacs-openmpi-2.0.2-8.1.fc24.x86_64
(coprbecloudfedoraprojectorg_results_smani_rpmmpihookstesting_fedorarawhidex86_64_)

DEBUG util.py:378: Requires:
libmpi_mpifh.so.2()(64bit)(openmpi-x86_64)
DEBUG util.py:378: Available: openmpi-1.8.6-1.2.fc24.x86_64
(coprbecloudfedoraprojectorg_results_smani_rpmmpihookstesting_fedorarawhidex86_64_)

DEBUG util.py:378: libmpi_mpifh.so.2()(64bit)(openmpi-x86_64)
DEBUG util.py:378: Available: openmpi-devel-1.8.6-1.2.fc24.x86_64
(coprbecloudfedoraprojectorg_results_smani_rpmmpihookstesting_fedorarawhidex86_64_)

DEBUG util.py:378: libmpi_mpifh.so.2()(64bit)(openmpi-x86_64)
DEBUG util.py:378: Available: openmpi-1.8.7-1.fc24.i686 (fedora)
DEBUG util.py:378: Not found
DEBUG util.py:378: Available: openmpi-devel-1.8.7-1.fc24.i686
(fedora)
DEBUG util.py:378: Not found

but cannot reproduce this locally (neither with dnf nor with yum-deprecated).
Haven't had time to investigate properly yet though (oh and the -devel
packages definitely should not be providing the libraries).

Again, you need to build a new openmpi in your copr that's newer than the
1.8.7-1 in Fedora now.

For the -devel issue, we need:

%__mpi_magic^(setuid )?(setgid )?(sticky )?ELF (32|64)-bit.*$
%__mpi_flagsexeonly

to match the %__elf_* options.
Ahh sorry didn't realize that this was related to the version mismatch. 
Ok thanks!

--
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: Geeqie... I'll take it -- but I'd like co-maintainers! [was Re: Orphaned Geeqie]

[Digimer]

On 20/07/15 02:57 PM, Matthew Miller wrote:
> On Mon, Jul 20, 2015 at 01:16:08PM +0200, Michael Schwendt wrote:
>> If you're interested in this image viewer, feel free to adopt the
>> package.
> 
> I am interested, and I'll pick it up. However, I'd definitely
> appreciate co-maintainers, and particularly someone who could generate
> security patches if need be, given the state of upstream.

As a user, I am very grateful, thank you!

-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
-- 
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: help for optimize cpptasks

[gil]

sorry fot the noise ...
forgot Konsole output
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=10427445

Il 21/07/2015 18:03, gil ha scritto:

hi
i try to import lz4-java
It use bundle code of lz4 (and some part of xxhash ...)
but i need an help for optimized the compile-jni task
at the moment i done these changes

  depends="install-cpptasks,generate-headers" unless="${skip.jni}">




  
-  
+  
  
  
  
-  
+  
  
  
-  
+  
+  
+  
+  
+  
+  
+  

  

my work is available here:
https://gil.fedorapeople.org/lz4-java-1.3.0-1.fc22.src.rpm
https://gil.fedorapeople.org/lz4-java.spec

thanks in advance
gil
Konsole outpu


-- 
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: Hosting End-Of-Life Fedora Base images?

[Adam Miller]

On Mon, Jul 20, 2015 at 2:33 PM, Chris Murphy  wrote:
> Isn't it true the install media ISOs are available indefinitely? And
> if so the security cat is already out of the bag, so that's not a very
> good argument. I'd say if we wanted to do something better it would be
> an image that's usable for both VM and containers, and would be the
> state of that version at the time it went EOL, i.e. it has all
> available updates baked into it. And then de-emphasize the original
> ISO as the way to run older versions of Fedora.

It is true that install media ISOs are available forever, but we don't
go backwards in time and create vagrant boxes or IaaS cloud qcow
images of old EOL'd Fedora releases that went EOL before those
technologies existed and/or became popular. I don't see why we would
start doing so now for docker images.

-AdamM

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

help for optimize cpptasks

[gil]

hi
i try to import lz4-java
It use bundle code of lz4 (and some part of xxhash ...)
but i need an help for optimized the compile-jni task
at the moment i done these changes

  depends="install-cpptasks,generate-headers" unless="${skip.jni}">




  
-  
+  
  
  
  
-  
+  
  
  
-  
+  
+  
+  
+  
+  
+  
+  

  

my work is available here:
https://gil.fedorapeople.org/lz4-java-1.3.0-1.fc22.src.rpm
https://gil.fedorapeople.org/lz4-java.spec

thanks in advance
gil
Konsole outpu
--
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: F23 Self Contained Change: RPM MPI Requires Provides

[Orion Poplawski]

On 07/21/2015 09:45 AM, Sandro Mani wrote:
> 
> 
> On 21.07.2015 17:41, Orion Poplawski wrote:
>> On 07/17/2015 09:50 AM, Sandro Mani wrote:
>>> Yep - I'm now building things in copr [1].
>>>
>>>
>>> [1] https://copr.fedoraproject.org/coprs/smani/rpm-mpi-hooks-testing/
>> Great.  Looks like you need to build a newer openmpi package in your copr
>> since I updating it to 1.8.7 in rawhide.
> Yes - I'm having some problems with yum in copr not resolving the
> dependencies, i.e.
> 
> DEBUG util.py:378:  Error: Package: blacs-openmpi-2.0.2-8.1.fc24.x86_64
> (coprbecloudfedoraprojectorg_results_smani_rpmmpihookstesting_fedorarawhidex86_64_)
> 
> DEBUG util.py:378: Requires:
> libmpi_mpifh.so.2()(64bit)(openmpi-x86_64)
> DEBUG util.py:378: Available: openmpi-1.8.6-1.2.fc24.x86_64
> (coprbecloudfedoraprojectorg_results_smani_rpmmpihookstesting_fedorarawhidex86_64_)
> 
> DEBUG util.py:378: libmpi_mpifh.so.2()(64bit)(openmpi-x86_64)
> DEBUG util.py:378: Available: openmpi-devel-1.8.6-1.2.fc24.x86_64
> (coprbecloudfedoraprojectorg_results_smani_rpmmpihookstesting_fedorarawhidex86_64_)
> 
> DEBUG util.py:378: libmpi_mpifh.so.2()(64bit)(openmpi-x86_64)
> DEBUG util.py:378: Available: openmpi-1.8.7-1.fc24.i686 (fedora)
> DEBUG util.py:378: Not found
> DEBUG util.py:378: Available: openmpi-devel-1.8.7-1.fc24.i686
> (fedora)
> DEBUG util.py:378: Not found
> 
> but cannot reproduce this locally (neither with dnf nor with yum-deprecated).
> Haven't had time to investigate properly yet though (oh and the -devel
> packages definitely should not be providing the libraries).

Again, you need to build a new openmpi in your copr that's newer than the
1.8.7-1 in Fedora now.

For the -devel issue, we need:

%__mpi_magic^(setuid )?(setgid )?(sticky )?ELF (32|64)-bit.*$
%__mpi_flagsexeonly

to match the %__elf_* options.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
-- 
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: F23 Self Contained Change: RPM MPI Requires Provides

[Sandro Mani]

On 21.07.2015 17:41, Orion Poplawski wrote:

On 07/17/2015 09:50 AM, Sandro Mani wrote:

Yep - I'm now building things in copr [1].


[1] https://copr.fedoraproject.org/coprs/smani/rpm-mpi-hooks-testing/

Great.  Looks like you need to build a newer openmpi package in your copr
since I updating it to 1.8.7 in rawhide.
Yes - I'm having some problems with yum in copr not resolving the 
dependencies, i.e.


DEBUG util.py:378:  Error: Package: blacs-openmpi-2.0.2-8.1.fc24.x86_64 
(coprbecloudfedoraprojectorg_results_smani_rpmmpihookstesting_fedorarawhidex86_64_)
DEBUG util.py:378: Requires: 
libmpi_mpifh.so.2()(64bit)(openmpi-x86_64)
DEBUG util.py:378: Available: openmpi-1.8.6-1.2.fc24.x86_64 
(coprbecloudfedoraprojectorg_results_smani_rpmmpihookstesting_fedorarawhidex86_64_)
DEBUG util.py:378: libmpi_mpifh.so.2()(64bit)(openmpi-x86_64)
DEBUG util.py:378: Available: openmpi-devel-1.8.6-1.2.fc24.x86_64 
(coprbecloudfedoraprojectorg_results_smani_rpmmpihookstesting_fedorarawhidex86_64_)
DEBUG util.py:378: libmpi_mpifh.so.2()(64bit)(openmpi-x86_64)
DEBUG util.py:378: Available: openmpi-1.8.7-1.fc24.i686 (fedora)
DEBUG util.py:378: Not found
DEBUG util.py:378: Available: openmpi-devel-1.8.7-1.fc24.i686 
(fedora)
DEBUG util.py:378: Not found

but cannot reproduce this locally (neither with dnf nor with yum-deprecated). 
Haven't had time to investigate properly yet though (oh and the -devel packages 
definitely should not be providing the libraries).



--
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: F23 Self Contained Change: RPM MPI Requires Provides

[Orion Poplawski]

On 07/17/2015 09:50 AM, Sandro Mani wrote:
> Yep - I'm now building things in copr [1].
> 
> 
> [1] https://copr.fedoraproject.org/coprs/smani/rpm-mpi-hooks-testing/

Great.  Looks like you need to build a newer openmpi package in your copr
since I updating it to 1.8.7 in rawhide.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
-- 
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: Improving our processes for new contributors.

[Kevin Fenzi]

On Tue, 21 Jul 2015 16:23:34 +0200
Miroslav Suchý  wrote:

> Dne 21.7.2015 v 15:23 Neal Gompa napsal(a):
> > It's extraordinarily slow right now, and builders don't have the
> > level of availability needed to support it being part of the review
> > process.
> 
> While this was true in past, this changed a lot in past two months.
> Occasionally we have issues with PPC64LE builders as they are quite
> new to us. However Intel builders are very stable and there is lot of
> them there now (28 right now). You can hardly see some queue there.
> All task are processed immediately.

Yeah, I was going to ask for more details about this also. 

Where do you see the slowness in the process? Uploading? Building? 

kevin


pgphcYX6STyQh.pgp
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: Fedora developer portal - proof of concept

[Petr Stodulka]

On 21.7.2015 16:04, Josh Boyer wrote:
The site is specifically targeted at developers. The URL will likely 
be something like developers.fedoraproject.org. This isn't a generic, 
front-page site. Given the targeted nature of it, I think it's 
perfectly fine to say Fedora is built for developers. I mean, you 
wouldn't want a developer coming to this page and seeing "Fedora is 
built for everyone" and then a bunch of text explaining that. josh 

Agree
--
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: Fedora developer portal - proof of concept

[Máirín Duffy]

On 07/21/2015 10:48 AM, Adam Samalik wrote:

"There is no C and C++" - Sory guys, again, the homepage is just filled up with 
random stuff. C and C++ will be definitely a part of the content! I promise I will use 
Lorem Ipsum more often to avoid these unpleasant situations :-)


I don't know if this content is similarly random then, but with the 
aforementioned target audiences in mind, I'm not sure what's up with the 
Fedora.next section (far right on the nav bar) and the content under 
that. I'm not sure of the context in which the target audience devs 
would need this info?


Another suggestion - I think the language-specific documentation was a 
core and valuable feature in the proposal but it's a bit hidden in this 
design. Under the runtimes/frameworks section on the front, maybe add a 
button for each one "More info for $LANG/FRAMEWORK developers" that 
would drive users to those lang/framework-specific pages (similar to how 
you did 'learn more' for the tools.) Having these accessible only from a 
drop-down menu obscures them a lot unfortunately.


I think the main thing the site is missing is a narrative for how/why 
you'd want to use it. I know you don't have final content, but I think 
users are really going to need more guidance to understand how/why 
they're going to use the site. I think a good next step is developing 
that narrative.


You might also get more helpful / useful feedback by reposting part of 
the proposal on the wiki here on list so folks can get more of an idea 
of the background / context around the site. It was in your footnotes 
but not everybody reads all of those :)


~m
--
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: Fedora developer portal - proof of concept

[Adam Samalik]

Thank you all for the feedback!

The site is just a prototype to see how the technology works and to be able to 
preview the content in a better way than reading markdown from the git repo.

"Fedora is made for developers" - To be honest, I wasn't trying to write 
something great, I just added a line of text to fill the space up. The homepage 
itself is very far away from the final state. The main purpose [of the 
currently deployed version] of this prototype is to be able to preview the 
content from git.

"There is no C and C++" - Sory guys, again, the homepage is just filled up with 
random stuff. C and C++ will be definitely a part of the content! I promise I 
will use Lorem Ipsum more often to avoid these unpleasant situations :-)

Thanks again for the feedback! Any ideas and more feedback is very very 
welcome! Please feel free to get engaged in any way. Git repos and the project 
wiki are mentioned in Petr's first email. Everything on the current prototype 
might be (and probably will be) changed according to your feedback.

Adam

- Original Message -
From: "Josh Boyer" 
To: "Máirín Duffy" 
Cc: "Development discussions related to Fedora" 
, "Fedora Environment and Stacks Working Group 
mailing list" 
Sent: Tuesday, 21 July, 2015 4:05:03 PM
Subject: Re: Fedora developer portal - proof of concept

On Tue, Jul 21, 2015 at 10:03 AM, Máirín Duffy  wrote:
>
>
> On 07/21/2015 09:51 AM, Josh Boyer wrote:
>>
>> I'm curious how this is going to be tied into the Fedora Hubs work?
>> If it isn't, I'm curious why not :)
>
>
> So Fedora Hubs' main audiences are folks who are contributing to Fedora,
> whether they are new or experienced Fedora contributors.
>
> It's my understanding that the developer.fpo site is more focused towards:
>
> - developers who may develop apps for Linux but do not exclusively focus on
> Fedora in terms of as a target for their own applications
>
> - developers who may want to or do use Fedora, and while they happen to be
> developers but don't actually develop Fedora itself.
>
> That being said, there is no reason why we couldn't have a hub tied to
> developer.fpo that aggregates info from developer.fpo and provides a social
> space for Fedora contributors who also fit into the developer.fpo audience.
>
> Hope that makes sense?

Yes, thank you.

josh
-- 
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: COPR fail to build on F20

[Miroslav Suchý]

Dne 18.7.2015 v 04:11 Timotheus Pokorra napsal(a):
>> DEBUG util.py:378:  failure: repodata/repomd.xml from updates: [Errno 256]
>> > No more mirrors to try.
>> > DEBUG util.py:378:
>> > http://infrastructure.fedoraproject.org/pub/fedora/linux/updates/20/i386/repodata/repomd.xml:
>> > [Errno 14] HTTP Error 404 - Not Found
> F20 has reached end of life:
> https://fedoraproject.org/wiki/End_of_life
> 
> Please target F22 instead.

We removed F20 target from Copr today.

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
-- 
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: Improving our processes for new contributors.

[Miroslav Suchý]

Dne 21.7.2015 v 15:23 Neal Gompa napsal(a):
> It's extraordinarily slow right now, and builders don't have the level of 
> availability needed to support it being part
> of the review process.

While this was true in past, this changed a lot in past two months. 
Occasionally we have issues with PPC64LE builders as
they are quite new to us. However Intel builders are very stable and there is 
lot of them there now (28 right now). You
can hardly see some queue there. All task are processed immediately.

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
-- 
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: Integration of pkdb2 with anitya (howto?)

[José Matos]

On Tuesday 21 July 2015 13:15:30 Jakub Jelen wrote:
> These are the crypted buttons under "Monitoring:" label. Changing it 
> from "No Monitoring" to something else triggers the bug creation ("Bugs 
> only"), or possibly the scratch build ("Bugs & Build").

Thank you. I would never found that without your help. :-)

My problem is that that symbology/notation is not used elsewhere in any of the 
different fedora sites. At least none that I am aware of. :-)

-- 
José Abílio
-- 
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: Fedora developer portal - proof of concept

[Máirín Duffy]

(resending with my fpo email; my rht email isn't sub'ed to devel@)

On 07/21/2015 09:51 AM, Josh Boyer wrote:

I'm curious how this is going to be tied into the Fedora Hubs work?
If it isn't, I'm curious why not :)


So Fedora Hubs' main audiences are folks who are contributing to Fedora, 
whether they are new or experienced Fedora contributors.


It's my understanding that the developer.fpo site is more focused towards:

- developers who may develop apps for Linux but do not exclusively focus 
on Fedora in terms of as a target for their own applications


- developers who may want to or do use Fedora, and while they happen to 
be developers but don't actually develop Fedora itself.


That being said, there is no reason why we couldn't have a hub tied to 
developer.fpo that aggregates info from developer.fpo and provides a 
social space for Fedora contributors who also fit into the developer.fpo 
audience.


Hope that makes sense?

~m
--
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: Fedora developer portal - proof of concept

[Josh Boyer]

On Tue, Jul 21, 2015 at 10:03 AM, Máirín Duffy  wrote:
>
>
> On 07/21/2015 09:51 AM, Josh Boyer wrote:
>>
>> I'm curious how this is going to be tied into the Fedora Hubs work?
>> If it isn't, I'm curious why not :)
>
>
> So Fedora Hubs' main audiences are folks who are contributing to Fedora,
> whether they are new or experienced Fedora contributors.
>
> It's my understanding that the developer.fpo site is more focused towards:
>
> - developers who may develop apps for Linux but do not exclusively focus on
> Fedora in terms of as a target for their own applications
>
> - developers who may want to or do use Fedora, and while they happen to be
> developers but don't actually develop Fedora itself.
>
> That being said, there is no reason why we couldn't have a hub tied to
> developer.fpo that aggregates info from developer.fpo and provides a social
> space for Fedora contributors who also fit into the developer.fpo audience.
>
> Hope that makes sense?

Yes, thank you.

josh
-- 
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: Fedora developer portal - proof of concept

[Josh Boyer]

On Tue, Jul 21, 2015 at 10:00 AM, Neal Gompa  wrote:
> On Tue, Jul 21, 2015 at 9:57 AM, Jonathan Wakely  wrote:
>>
>> On 21/07/15 15:45 +0200, Petr Hracek wrote:
>>>
>>> Feel free to send us any comment or improvements. We would like to
>>> improve Fedora for developers.
>>> Just contents are missing.
>>
>>
>> Under "The latest stable runtimes and frameworks Packaged in Fedora
>> and ready to use!" would it be worth mentioning C and C++?
>>
>> GCC 5 is the first compiler to default to the latest C11 standard, and we
>> ship more of the latest C++ standard library extensions than any
>> other compiler.
>>
>> There's a lot happening in that space, and not everyone gets excited
>> by shiny dynamic languages ;-)
>>
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
>
> Personally, I'm a little uncomfortable with the phrasing "Fedora is made for
> developers". It implies that we don't do anything to make it great for
> non-developers, which is not true at all. Is there a better way we can word
> this?

The site is specifically targeted at developers.  The URL will likely
be something like developers.fedoraproject.org.  This isn't a generic,
front-page site.  Given the targeted nature of it, I think it's
perfectly fine to say Fedora is built for developers.  I mean, you
wouldn't want a developer coming to this page and seeing "Fedora is
built for everyone" and then a bunch of text explaining that.

josh
-- 
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: Fedora developer portal - proof of concept

[Neal Gompa]

On Tue, Jul 21, 2015 at 9:57 AM, Jonathan Wakely  wrote:

> On 21/07/15 15:45 +0200, Petr Hracek wrote:
>
>> Feel free to send us any comment or improvements. We would like to
>> improve Fedora for developers.
>> Just contents are missing.
>>
>
> Under "The latest stable runtimes and frameworks Packaged in Fedora
> and ready to use!" would it be worth mentioning C and C++?
>
> GCC 5 is the first compiler to default to the latest C11 standard, and we
> ship more of the latest C++ standard library extensions than any
> other compiler.
>
> There's a lot happening in that space, and not everyone gets excited
> by shiny dynamic languages ;-)
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


​Personally, I'm a little uncomfortable with the phrasing "Fedora is made
for developers". It implies that we don't do anything to make it great for
non-developers, which is not true at all. ​Is there a better way we can
word this?


-- 
真実はいつも一つ！/ 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: Fedora developer portal - proof of concept

[Jonathan Wakely]

On 21/07/15 15:45 +0200, Petr Hracek wrote:
Feel free to send us any comment or improvements. We would like to 
improve Fedora for developers.

Just contents are missing.


Under "The latest stable runtimes and frameworks Packaged in Fedora
and ready to use!" would it be worth mentioning C and C++?

GCC 5 is the first compiler to default to the latest C11 standard, and 
we ship more of the latest C++ standard library extensions than any

other compiler.

There's a lot happening in that space, and not everyone gets excited
by shiny dynamic languages ;-)

--
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: Hosting End-Of-Life Fedora Base images?

[Jon]

If they are out of support, I don't think they should be easy to access.





On Tue, Jul 21, 2015 at 8:16 AM, Neal Gompa  wrote:

> On Mon, Jul 20, 2015 at 3:33 PM, Chris Murphy 
> wrote:
>
>> Isn't it true the install media ISOs are available indefinitely? And
>> if so the security cat is already out of the bag, so that's not a very
>> good argument. I'd say if we wanted to do something better it would be
>> an image that's usable for both VM and containers, and would be the
>> state of that version at the time it went EOL, i.e. it has all
>> available updates baked into it. And then de-emphasize the original
>> ISO as the way to run older versions of Fedora.
>>
>>
>> Chris Murphy
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>>
>
> ​I tend to agree with the rest of the choir here in saying we shouldn't
> make it easier for people to use EOL releases. It will likely add
> unnecessary burdens onto us and our systems when people come to ask about
> EOL Fedora releases in Docker. Not to mention, we should be encouraging
> people to move up, not stay put.
>
> Honestly, I think if people need a platform that lasts a long time, they
> should be looking at CentOS with EPEL, SCLs, and/or other repos depending
> on what they need.​
>
>
> --
> 真実はいつも一つ！/ 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
>



-- 

-Jon Disnard
-- 
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: Improving our processes for new contributors.

[Parag Nemade]

Hi,

On Tue, Jul 21, 2015 at 6:14 PM, Miroslav Suchý  wrote:

> Dne 11.7.2015 v 23:38 Jonathan Underwood napsal(a):
> > Thoughts from the COPR folks?
>
> I like the idea of adding Copr as intermediate step for new contributors.
> Copr is outer ring of Fedora and it definitely
> make sense for newbies to go from outer ring to ring0. Step by step.
>
> Additionally we have in plan to run fedora-review consequently after each
> build, which hopefully will lead to better
> quality of spec files and resulting RPMs.
>
>
> Regarding long wait for sponsor: We have little over 120 sponsors right
> now. And there is little over 210 reviews
> waiting for sponsors.
> If every sponsor would take 2 reviews right now, the queue would be empty.
> So our current process still can work.
> However I am aware that sponsoring somebody is very irregular task. I am
> sponsor too. It happen that I sponsor 2
> contributors in one month, but sometimes there are months where I focus on
> something else and I forgot on my sponsor
> duties. I assume other sponsors have it similar.
> I would welcome if somebody can write cron script which would mine data
> from BZ and send me email that:
>
> Dear sponsor,
> it seems that you did not sponsor anybody for 3 months. We have 120 new
> contributors waiting for sponsor.
> Please consider taking some bug from:
>   https://bugzilla.redhat.com/show_bug.cgi?id=177841
>
> Sincerely your Watchmen
>
>
What above is said is from sponsor side. I will suggest similar for
contributor side. Implement a script which search FE-NEEDSPONSOR package
review bugs where package has not already under review. This script will
check package submission date and then submit a comment every month till 3
months like

Dear contributor,
Its one/two/three month since this package review is submitted and you are
in need of a sponsor. Have you started reviewing other packages reviews? if
yes please post the link to your reviews in the next comment.
Have you also run fedora-review on your package submissions? if yes and
found any issues in review.txt then try to fix them or ask on devel list or
#fedora-devel irc channel for help.

something like this. This will make sure contributor realize what he need
to do next after his submission. Thus, contributor will not loose interest
in packaging.

Regards,
Parag.
-- 
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: Fedora developer portal - proof of concept

[Josh Boyer]

On Tue, Jul 21, 2015 at 9:45 AM, Petr Hracek  wrote:
> Hi Fedora devels and other folks,
>
> Adam Samalik and me we create a first proof of concept Fedora Developer
> Portal.
> Testing instance is already available here [1].
>
> Fedora Developer Portal is a new place for developers and not only for them,
> providing information about tools, projects, technologies
> and other features that are packaged in Fedora.
>
> This page would be mainly used for developers building on Fedora and help
> them with tools.
> But of course other users can use main technologies developed on Fedora.
> It is plan to have reference to this portal from [2].
>
> What is possible structure of Fedora Developer Portal is on [3] page under
> section 'Structure'.
>
> If anyone is interested with helping us to create this portal please clone
> repository [4]
> and provide any contents.
> We will review it together with other colleagues and add it to this Page.
>
> UX design is going to be discussed and reviewed by Mairin. Thanks for your
> help.

I'm curious how this is going to be tied into the Fedora Hubs work?
If it isn't, I'm curious why not :)

josh
-- 
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 developer portal - proof of concept

[Petr Hracek]

Hi Fedora devels and other folks,

Adam Samalik and me we create a first proof of concept Fedora Developer 
Portal.

Testing instance is already available here [1].
*
**Fedora Developer Portal* is a new place for developers and not only 
for them, providing information about tools, projects, technologies

and other features that are packaged in Fedora.

This page would be mainly used for developers building on Fedora and 
help them with tools.

But of course other users can use main technologies developed on Fedora.
It is plan to have reference to this portal from [2].

What is possible structure of Fedora Developer Portal is on [3] page 
under section *'Structure'.


*If anyone is interested with helping us to create this portal please 
clone repository [4]

and provide any contents.
We will review it together with other colleagues and add it to this Page.

UX design is going to be discussed and reviewed by Mairin. Thanks for 
your help.


Some discussion about this portal is on Env&Stack mailing list.

What Fedora developer portal should cover at all is here [3] and can be 
extended of course.

GitHub repository for content is [4].
GitHub repository for website is [5].

Feel free to send us any comment or improvements. We would like to 
improve Fedora for developers.

Just contents are missing.

[1] https://developer-phracek.rhcloud.com/
[2] https://getfedora.org/
[3] https://fedoraproject.org/wiki/Websites/Developer
[4] https://github.com/developer-portal/content
[5] https://github.com/developer-portal/website

--
Petr Hracek
Software Engineer
Developer Experience
Red Hat, Inc
Mob: +420777056169
email: phra...@redhat.com

-- 
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: Geeqie... I'll take it -- but I'd like co-maintainers! [was Re: Orphaned Geeqie]

[Jonathan Wakely]

On 21/07/15 14:28 +0100, Jonathan Wakely wrote:

On 21/07/15 09:10 -0400, Matthew Miller wrote:

On Tue, Jul 21, 2015 at 11:07:56AM +0100, Jonathan Wakely wrote:

For example this can't be right:
  if (rgb1[0] == rgb1[1] == rgb1[2]) {


Ouch. *Digs back in memory* -- so if rgb1[0] and rgb1[1] are equal and
rgb1[2] is 1, or if rgb1[0] and rgb1[1] are *not* equal and rgb[2] is
0, this will be true, and in all other cases false. Perfectly valid
code!


Full marks! :-)

If that's really what the author intended then it's far too
clever/subtle to go without a comment, but I suspect it's just a bug.


GCC has warned about this since at least 4.3.6 (which is old):

eq.c:3: warning: suggest parentheses around comparison in operand of ==

--
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: Geeqie... I'll take it -- but I'd like co-maintainers! [was Re: Orphaned Geeqie]

[Jonathan Wakely]

On 21/07/15 09:10 -0400, Matthew Miller wrote:

On Tue, Jul 21, 2015 at 11:07:56AM +0100, Jonathan Wakely wrote:

For example this can't be right:
   if (rgb1[0] == rgb1[1] == rgb1[2]) {


Ouch. *Digs back in memory* -- so if rgb1[0] and rgb1[1] are equal and
rgb1[2] is 1, or if rgb1[0] and rgb1[1] are *not* equal and rgb[2] is
0, this will be true, and in all other cases false. Perfectly valid
code!


Full marks! :-)

If that's really what the author intended then it's far too
clever/subtle to go without a comment, but I suspect it's just a bug.


--
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: Improving our processes for new contributors.

[Neal Gompa]

On Tue, Jul 21, 2015 at 8:44 AM, Miroslav Suchý  wrote:

> Dne 11.7.2015 v 23:38 Jonathan Underwood napsal(a):
> > Thoughts from the COPR folks?
>
> I like the idea of adding Copr as intermediate step for new contributors.
> Copr is outer ring of Fedora and it definitely
> make sense for newbies to go from outer ring to ring0. Step by step.
>
> Additionally we have in plan to run fedora-review consequently after each
> build, which hopefully will lead to better
> quality of spec files and resulting RPMs.
>
>
> Regarding long wait for sponsor: We have little over 120 sponsors right
> now. And there is little over 210 reviews
> waiting for sponsors.
> If every sponsor would take 2 reviews right now, the queue would be empty.
> So our current process still can work.
> However I am aware that sponsoring somebody is very irregular task. I am
> sponsor too. It happen that I sponsor 2
> contributors in one month, but sometimes there are months where I focus on
> something else and I forgot on my sponsor
> duties. I assume other sponsors have it similar.
> I would welcome if somebody can write cron script which would mine data
> from BZ and send me email that:
>
> Dear sponsor,
> it seems that you did not sponsor anybody for 3 months. We have 120 new
> contributors waiting for sponsor.
> Please consider taking some bug from:
>   https://bugzilla.redhat.com/show_bug.cgi?id=177841
>
> Sincerely your Watchmen
>
> --
> Miroslav Suchy, RHCA
> Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

In principle, I agree that Copr is probably a good proving ground, but Copr
needs a lot of work right now to make that doable. It's extraordinarily
slow right now, and builders don't have the level of availability needed to
support it being part of the review process. It needs to become as good as
OpenSUSE's Open Build Service and Canonical's PPAs before we can have any
serious usage of it for this kind of work.

-- 
Neal Gompa (FAS: ngompa)
-- 
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: Hosting End-Of-Life Fedora Base images?

[Neal Gompa]

On Mon, Jul 20, 2015 at 3:33 PM, Chris Murphy 
wrote:

> Isn't it true the install media ISOs are available indefinitely? And
> if so the security cat is already out of the bag, so that's not a very
> good argument. I'd say if we wanted to do something better it would be
> an image that's usable for both VM and containers, and would be the
> state of that version at the time it went EOL, i.e. it has all
> available updates baked into it. And then de-emphasize the original
> ISO as the way to run older versions of Fedora.
>
>
> Chris Murphy
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​I tend to agree with the rest of the choir here in saying we shouldn't
make it easier for people to use EOL releases. It will likely add
unnecessary burdens onto us and our systems when people come to ask about
EOL Fedora releases in Docker. Not to mention, we should be encouraging
people to move up, not stay put.

Honestly, I think if people need a platform that lasts a long time, they
should be looking at CentOS with EPEL, SCLs, and/or other repos depending
on what they need.​


-- 
真実はいつも一つ！/ 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

Unified file selection dialogs

[Richard Marko]

Hi,

I'm currently working with toolchains that are composed of number of
apps that all use different file selection dialogs. This gets annoying
pretty quickly as one has to learn how to use multiple file choosers.
Some of these provide bookmarks that are quite handy but when there are
multiple user has to save the same bookmarks in various file choosers.
Recently used directories won't work either.

Are there any ongoing efforts to fix this situation?
What would be a proper solution to this problem?

I've only found one blogpost discussing this topic:

http://straightedgelinux.com/blog/opinions/filechoosers/index.html

Cheers,

-- 
Richard
irc: impure_hate

-- 
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: Geeqie... I'll take it -- but I'd like co-maintainers! [was Re: Orphaned Geeqie]

[Matthew Miller]

On Tue, Jul 21, 2015 at 11:07:56AM +0100, Jonathan Wakely wrote:
> For example this can't be right:
>if (rgb1[0] == rgb1[1] == rgb1[2]) {

Ouch. *Digs back in memory* -- so if rgb1[0] and rgb1[1] are equal and
rgb1[2] is 1, or if rgb1[0] and rgb1[1] are *not* equal and rgb[2] is
0, this will be true, and in all other cases false. Perfectly valid
code!

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

rawhide report: 20150721 changes

[Fedora Rawhide Report]

Compose started at Tue Jul 21 05:15:04 UTC 2015
New package: compat-libvpx1-1.3.0-1.fc24
 Compat package with libvpx libraries

New package: dropbox-api-command-1.17-5.fc24
 Dropbox API wrapper command

New package: gap-pkg-crystcat-1.1.6-1.fc24
 Crystallographic groups catalog

New package: gdouros-anaktoria-fonts-6.00-1.fc24
 A font based on "Grecs du roi" and the "First Folio Edition of 
Shakespeare"

New package: gdouros-aroania-fonts-6.00-1.fc24
 A font based on Victor Julius Scholderer's "New Hellenic"

New package: perl-DBIx-Class-Schema-Diff-1.03-2.fc24
 Identify differences between two DBIx::Class schemas

New package: php-guzzlehttp-promises-1.0.1-3.fc24
 Guzzle promises library

New package: php-guzzlehttp-psr7-1.1.0-3.fc24
 PSR-7 message implementation

New package: php-zendframework-zend-diactoros-1.1.2-1.fc24
 PSR HTTP Message implementations

New package: python-jupyter_core-4.0.2-1.fc24
 Core Jupyter functionality

New package: python-nbformat-4.0.0-2.fc24
 The Jupyter Notebook format

New package: python-pathlib-1.0.1-1.fc24
 Object-oriented filesystem paths

New package: python-traitlets-4.0.0-1.fc24
 A lightweight derivative of Enthought Traits for configuring 
Python objects

New package: qmasterpassword-1.1-3.fc24
 Stateless graphical Master Password Manager

Removed package:  mediascrapper-0.1-14.fc23
Removed package:  pfscalibration-1.5-10.fc23
Removed package:  pfstmo-1.5-9.fc23

Updated Packages:

BEDTools-2.24.0-5.fc24
--
* Sat Jul 18 2015 Adam Huffman  - 2.24.0-5
- Re-enable 32-bit and ARM builds


Size change: 21 bytes

Singular-3.1.6-16.fc24
--
* Sun Jul 19 2015 pcpa  - 3.1.6-16
- Disable polymake due to broken dependency cycle
- Correct previous perl warning that is now an error
- Use interactive bash on wrappers to work with other login shells (#1243580)

* Tue Jun 16 2015 Fedora Release Engineering  
- 3.1.6-15
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild


Size change: -125 bytes

abrt-2.6.2-1.fc24
-
* Fri Jul 17 2015 Jakub Filak  2.6.2-1
- switch to Python 3
- reassign components of certain Kernel oopses to xorg-x11-drv-*
- de-prioritize post-mortem processes
- applet: do not crash if the new problem has no command_line
- abrt-hook-ccpp: do not crash if generate_core_backtrace fails
- cli: enable authentication for all commands


Size change: -8926 bytes

adwaita-qt-0.3-1.fc24
-
* Mon Jul 20 2015 Martin Briza  - 0.3-1
- Updated to the latest release
- Added a Qt5 build


Size change: 572347 bytes

ahkab-0.18-1.fc24
-
* Sat Jul 18 2015 Kiara Navarro  - 0.18-1
- Bump to lastest version
- Add Four and Fft support
- Add PWL waveforms


Size change: 929907 bytes

audacity-2.1.1-1.fc24
-
* Sun Jul 19 2015 David Timms  - 2.1.1-1
- Release of Audacity 2.1.1.

* Wed Jul 08 2015 David Timms  - 2.1.1-0.4.rc2
- Update to 2.1.1rc3 for testing.


Size change: -5101 bytes

babeltrace-1.2.4-1.fc24
---
* Sun Jul 19 2015 Peter Robinson  1.2.4.1
- Update to 1.2.4

* Sun Jul 19 2015 Peter Robinson  1.2.1-5
- Fix FTBFS, use %license

* Wed Jun 17 2015 Fedora Release Engineering  
- 1.2.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild


Size change: 10205 bytes

bijiben-3.17.4-1.fc24
-
* Sun Jul 19 2015 David King  - 3.17.4-1
- Update to 3.17.4


Size change: 1023 bytes

bmon-3.7-1.fc24
---
* Sun Jul 19 2015 Peter Robinson  3.7-1
- Update to 3.7 release

* Wed Jun 17 2015 Fedora Release Engineering  
- 3.6-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild


Size change: 4135 bytes

bwm-ng-0.6-18.fc24
--

Size change: -1105 bytes

calibre-2.32.1-1.fc24
-
* Sat Jul 18 2015 Kevin Fenzi  2.32.1-1
- Update to 2.32.1. Fixes bug #1244180

* Fri Jul 17 2015 Kevin Fenzi  2.32.0-1
- Update to 2.32.0. Fixed bug #1244180


Size change: -44192 bytes

certmonger-0.78.3-1.fc24

* Mon Jul 20 2015 Nalin Dahyabhai  0.78.3-1
- call poptGetOptArg() correctly, to fix parsing of the -R flag to scep-submit
  and the -O and -o flags to dogtag-submit (#1244914)


Size change: -36777 bytes

checkpolicy-2.4-1.fc24
--
* Mon Jul 20 2015 Petr Lautrbach  2.4-1
- Update to 2.4 release


Size change: -1273 bytes

cinnamon-2.6.13-2.fc24
--
* Mon Jul 20 2015 Leigh Scott  - 2.6.13-2
- remove nautilus from menu
- remove other useless crap from menu


Size change: 661 bytes

clutter-gst3-3.0.8-1.fc24
-
* Sun Jul 19 2015 David King  - 3.0.8-1
- Update to 3.0.8


Size change: -1795 bytes

cmdtest-0.16-1.fc24
---
* Sun Jul 19 2015 Michel Alexandre Salim  - 0.16-1
- Update to 0.16


Size change: -5985 bytes

Re: Improving our processes for new contributors.

[Miroslav Suchý]

Dne 11.7.2015 v 23:38 Jonathan Underwood napsal(a):
> Thoughts from the COPR folks?

I like the idea of adding Copr as intermediate step for new contributors. Copr 
is outer ring of Fedora and it definitely
make sense for newbies to go from outer ring to ring0. Step by step.

Additionally we have in plan to run fedora-review consequently after each 
build, which hopefully will lead to better
quality of spec files and resulting RPMs.


Regarding long wait for sponsor: We have little over 120 sponsors right now. 
And there is little over 210 reviews
waiting for sponsors.
If every sponsor would take 2 reviews right now, the queue would be empty. So 
our current process still can work.
However I am aware that sponsoring somebody is very irregular task. I am 
sponsor too. It happen that I sponsor 2
contributors in one month, but sometimes there are months where I focus on 
something else and I forgot on my sponsor
duties. I assume other sponsors have it similar.
I would welcome if somebody can write cron script which would mine data from BZ 
and send me email that:

Dear sponsor,
it seems that you did not sponsor anybody for 3 months. We have 120 new 
contributors waiting for sponsor.
Please consider taking some bug from:
  https://bugzilla.redhat.com/show_bug.cgi?id=177841

Sincerely your Watchmen

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
-- 
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: Granting a capability to a service

[Andrew Lutomirski]

On Jul 21, 2015 4:18 AM, "Florian Weimer"  wrote:
>
> On 07/20/2015 07:30 PM, Andrew Lutomirski wrote:
>
> >> (b) Make a copy of the file, put it in a directory which only the
> >> service user can read (or ship it with 750 permissions and the service
> >> group controlling it), and set fscaps.  The downside is the large
binary
> >> size (it has to be a copy, a link won't work).  And the service user
> >> could still run the service with command line options that allow
> >> privilege escalation.
> >>
> >
> > If you set inheritable fscaps but not permitted, this should be
reasonably
> > safe.
>
> Empirically, this causes the capability to end up in the P set, not the
> E set, which means that the application still needs to be capability to
> enable it.  So it really doesn't help that much in the Go case, sadly.
> Although it is fairly close.

Try 2: set the capability in the inheritable set and set the effective
bit.  (The effective fscap is a single bit, not a mask.  You still program
it with "=ei" because the syntax is wrong.)

--Andy

>
> --
> Florian Weimer / Red Hat Product Security
> --
> 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: anybody running dhcpd & LDAP ?

[Jiri Popelka]

On 21.7.2015 13:29, Alexander Bokovoy wrote:
> On Tue, 21 Jul 2015, Jiri Popelka wrote:
>> dhcpd upstream is going to merge some LDAP related patches that various
>> distributions use and I've been asked if I can help with testing.
>> Original message:
>> "We are now finishing the work on adding some of the LDAP patches into
>> our code base. We have tried our patch to verify that it builds but we
>> don't have a set up to verify that the LDAP portion works correctly. (As
>> this continues to be classified as contributed code we don't have the
>> time to properly verify it.)"
> Is this discussed anywhere publicly? I was unable to find any discussion
> on dhcp-users@ or dhcp-workers@ mailing lists. Where can I find patches?

My srpm in the COPR is the only place so far. The patch was sent to me
before they push it into the public repo and release 4.3.3-beta.

> We have a design and half-baked implementation fleshed out for
> FreeIPA/dhcpd integration (FreeIPA is LDAP store at one side).
> See
>  https://www.freeipa.org/page/DHCP_Integration_Design
>  https://fedorahosted.org/freeipa/ticket/939
>  https://bitbucket.org/Firstyear/freeipa-dhcp
> 
> Looking at your srpm from the COPR, I can see that you included the
> patches William Brown developed as part of the work above, which is
> good.

Yes and I first asked William, but he hasn't replied yet, so I'm trying
wider audience here.
https://bugzilla.redhat.com/show_bug.cgi?id=1150542#c3

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

F-23 Branched report: 20150721 changes

[Fedora Branched Report]

Compose started at Tue Jul 21 07:15:02 UTC 2015
New package: compat-libvpx1-1.3.0-1.fc23
 Compat package with libvpx libraries

New package: felix-scr-1.6.2-3.fc23
 Apache Felix Declarative Services Runtime

New package: gdouros-anaktoria-fonts-6.00-1.fc23
 A font based on "Grecs du roi" and the "First Folio Edition of 
Shakespeare"

New package: gdouros-aroania-fonts-6.00-1.fc23
 A font based on Victor Julius Scholderer's "New Hellenic"

New package: nodejs-esprima-fb-15001.1.0-4.fc23
 Facebook-specific fork of the esprima project

New package: nodejs-process-nextick-args-1.0.2-1.fc23
 The process.nextTick() but always with args

New package: nodejs-util-deprecate-1.0.1-1.fc23
 The Node.js `util.deprecate()` function with browser support

New package: perl-DBIx-Class-Schema-Diff-1.03-2.fc23
 Identify differences between two DBIx::Class schemas

New package: perl-Test-LWP-UserAgent-0.029-1.fc23
 LWP::UserAgent suitable for simulating and testing network calls

New package: python-jupyter_core-4.0.2-1.fc23
 Core Jupyter functionality

New package: python-nbformat-4.0.0-2.fc23
 The Jupyter Notebook format

New package: python-traitlets-4.0.0-1.fc23
 A lightweight derivative of Enthought Traits for configuring 
Python objects

Removed package:  pfscalibration-1.5-10.fc23
Removed package:  pfstmo-1.5-9.fc23

Updated Packages:

abrt-2.6.2-1.fc23
-
* Fri Jul 17 2015 Jakub Filak  2.6.2-1
- switch to Python 3
- reassign components of certain Kernel oopses to xorg-x11-drv-*
- de-prioritize post-mortem processes
- applet: do not crash if the new problem has no command_line
- abrt-hook-ccpp: do not crash if generate_core_backtrace fails
- cli: enable authentication for all commands
- Resolves: #1192080


Size change: -7798 bytes

adwaita-qt-0.3-1.fc23
-
* Mon Jul 20 2015 Martin Briza  - 0.3-1
- Updated to the latest release
- Added a Qt5 build


Size change: 573453 bytes

bouncycastle-1.52-7.fc23

* Thu Jul 16 2015 Michael Simacek  - 1.52-7
- Re-add geenric Export-Package


Size change: 109 bytes

certmonger-0.78.3-1.fc23

* Mon Jul 20 2015 Nalin Dahyabhai  0.78.3-1
- call poptGetOptArg() correctly, to fix parsing of the -R flag to scep-submit
  and the -O and -o flags to dogtag-submit (#1244914)


Size change: -35673 bytes

cinnamon-2.6.13-2.fc23
--
* Mon Jul 20 2015 Leigh Scott  - 2.6.13-2
- remove nautilus from menu
- remove other useless crap from menu


Size change: 660 bytes

dnf-langpacks-0.12.0-1.fc23
---
* Mon Jul 20 2015 Parag Nemade  - 0.12.0-1
- update to 0.12.0 release


Size change: 373 bytes

drupal7-date_ical-3.5-1.fc23

* Mon Jul 20 2015 Shawn Iwinski  - 3.5-1
- Update to 3.5 (RHBZ #1244984)


Size change: 214 bytes

drupal7-feeds-2.0-0.13.beta1.fc23
-
* Mon Jul 20 2015 Shawn Iwinski  - 2.0-0.13.beta1
- Update to 2.0-beta1 (RHBZ #1242139)


Size change: 28326 bytes

eclipse-pydev-4.2.0-2.fc23
--
* Mon Jul 20 2015 Mat Booth  - 1:4.2.0-2
- Fix perms on native lib to fix binary stripping
- Generate debuginfo


Size change: 150 bytes

eog-3.17.3-1.fc23
-
* Mon Jul 20 2015 David King  - 3.17.3-1
- Update to 3.17.3
- Preserve timestamps during install


Size change: -369 bytes

evolution-3.17.4-1.fc23
---
* Mon Jul 20 2015 Milan Crha  - 3.17.4-1
- Update to 3.17.4


Size change: 47239 bytes

evolution-data-server-3.17.4-1.fc23
---
* Mon Jul 20 2015 Milan Crha  - 3.17.4-1
- Update to 3.17.4


Size change: 13853 bytes

evolution-ews-3.17.4-1.fc23
---
* Mon Jul 20 2015 Milan Crha  - 3.17.4-1
- Update to 3.17.4


Size change: 396 bytes

evolution-mapi-3.17.4-1.fc23

* Mon Jul 20 2015 Milan Crha  - 3.17.4-1
- Update to 3.17.4


Size change: 149 bytes

extlinux-bootloader-1.1-5.fc23
--
* Mon Jul 20 2015 Peter Robinson  1.1-5
- Use python3


Size change: 98 bytes

freemarker-2.3.19-11.fc23
-
* Thu Jul 02 2015 gil cattaneo  2.3.19-11
- fix FTBFS
- adapt to current guideline
- fix some rpmlint problems
- enable javadoc task
- enable maven-upload task for generate pom file
- Fix paths to jython

* Wed Jun 17 2015 Fedora Release Engineering  
- 2.3.19-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild


Size change: 5577 bytes

gdk-pixbuf2-2.31.5-1.fc23
-
* Mon Jul 20 2015 David King  - 2.31.5-1
- Update to 2.31.5
- Use pkgconfig for some BuildRequires


Size change: 34235 bytes

gedit-3.17.2-1.fc23
---
* Mon Jul 20 2015 David King  - 2:3.17.2-1
- Update to 3.17.2
- Preserve timestamps during install


Size change: -37153 bytes

gnome-calen

Re: anybody running dhcpd & LDAP ?

[Alexander Bokovoy]

On Tue, 21 Jul 2015, Jiri Popelka wrote:

dhcpd upstream is going to merge some LDAP related patches that various
distributions use and I've been asked if I can help with testing.
Original message:
"We are now finishing the work on adding some of the LDAP patches into
our code base. We have tried our patch to verify that it builds but we
don't have a set up to verify that the LDAP portion works correctly. (As
this continues to be classified as contributed code we don't have the
time to properly verify it.)"

Is this discussed anywhere publicly? I was unable to find any discussion
on dhcp-users@ or dhcp-workers@ mailing lists. Where can I find patches?

We have a design and half-baked implementation fleshed out for
FreeIPA/dhcpd integration (FreeIPA is LDAP store at one side).
See
 https://www.freeipa.org/page/DHCP_Integration_Design
 https://fedorahosted.org/freeipa/ticket/939
 https://bitbucket.org/Firstyear/freeipa-dhcp

Looking at your srpm from the COPR, I can see that you included the
patches William Brown developed as part of the work above, which is
good.


I haven't tried dhcpd with LDAP myself, but I promised to ask if there's
any volunteer with such experience.

Jiri, I think we can arrange something with FreeIPA. Perhaps Jan (in
CC:) could set you up an environment?


In case you're willing to help testing it, 'dnf copr enable
jpopelka/dhcp-ldap-auth' is all you need to do to enable the testing
repo (https://copr.fedoraproject.org/coprs/jpopelka/dhcp-ldap-auth/).
Then please send feedback to me (CC s...@isc.org).


--
/ Alexander Bokovoy
--
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: Granting a capability to a service

[Florian Weimer]

On 07/20/2015 07:30 PM, Andrew Lutomirski wrote:

>> (b) Make a copy of the file, put it in a directory which only the
>> service user can read (or ship it with 750 permissions and the service
>> group controlling it), and set fscaps.  The downside is the large binary
>> size (it has to be a copy, a link won't work).  And the service user
>> could still run the service with command line options that allow
>> privilege escalation.
>>
> 
> If you set inheritable fscaps but not permitted, this should be reasonably
> safe.

Empirically, this causes the capability to end up in the P set, not the
E set, which means that the application still needs to be capability to
enable it.  So it really doesn't help that much in the Go case, sadly.
Although it is fairly close.

-- 
Florian Weimer / Red Hat Product Security
-- 
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: Integration of pkdb2 with anitya (howto?)

[Jakub Jelen]

On 07/21/2015 01:03 PM, José Matos wrote:

Hi,
according to https://fedoraproject.org/wiki/Upstream_release_monitoring

to have a package monitored we should:

   1) Add the project to anitya.
   2) Map the project to a Fedora package in anitya.
   3) Enable the monitoring flag for that package in pkgdb2.
These are the crypted buttons under "Monitoring:" label. Changing it 
from "No Monitoring" to something else triggers the bug creation ("Bugs 
only"), or possibly the scratch build ("Bugs & Build").

Steps 1 and 2 are easy but I can not find way to set any flag on pkgdb2.

As an example, in https://admin.fedoraproject.org/pkgdb/package/armadillo/

I see that armadillo is not monitored and it has information in Anitya (I added 
it) but I do not see any place/flag/whatever to add the monitoring to armadillo.

What am I missing? :-)

Regards,


--
Jakub Jelen
Associate Software Engineer
Security Technologies
Red Hat

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

[Sérgio Basto]

On Ter, 2015-07-21 at 12:36 +0200, Michael Schwendt wrote:
> http://pkgs.fedoraproject.org/cgit/pyorbit.git/plain/dead.package
> 
> > last user has been retired, package EOL
> 
> Error: nothing provides pyorbit(x86-64) >= 2.0.1 needed by 
> gnome-python2-bonobo-2.28.1-16.fc23.x86_64
> 
> What's the full story here? Where has this been discussed/announced?

I would also like to know what is the plan . 

References :
https://lists.fedoraproject.org/pipermail/devel/2015-July/212391.html

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

Integration of pkdb2 with anitya (howto?)

[José Matos]

Hi,
according to https://fedoraproject.org/wiki/Upstream_release_monitoring

to have a package monitored we should:

  1) Add the project to anitya.
  2) Map the project to a Fedora package in anitya.
  3) Enable the monitoring flag for that package in pkgdb2.

Steps 1 and 2 are easy but I can not find way to set any flag on pkgdb2.

As an example, in https://admin.fedoraproject.org/pkgdb/package/armadillo/

I see that armadillo is not monitored and it has information in Anitya (I added 
it) but I do not see any place/flag/whatever to add the monitoring to armadillo.

What am I missing? :-)

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

Orphaned SoundConverter

[Michael Schwendt]

Hello, everyone!

Package "soundconverter" will still have the initial owner, but over
the past five years I've been the only one to work on the package.
I really would have liked the occasional commit from someone else.

It has not been a low-maintenance package. Lots of bugs, race-conditions,
debugging and fixing required. Upstream contact has been good.

What else could be interesting for someone who would like to take
over?

The current version is based on Python 2 and GStreamer 0.10.x.
There is a bit of work already on creating a version based on
Python 3 and GStreamer 1.0.x API, but nothing usable yet.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

anybody running dhcpd & LDAP ?

[Jiri Popelka]

dhcpd upstream is going to merge some LDAP related patches that various
distributions use and I've been asked if I can help with testing.
Original message:
"We are now finishing the work on adding some of the LDAP patches into
our code base. We have tried our patch to verify that it builds but we
don't have a set up to verify that the LDAP portion works correctly. (As
this continues to be classified as contributed code we don't have the
time to properly verify it.)"

I haven't tried dhcpd with LDAP myself, but I promised to ask if there's
any volunteer with such experience.

In case you're willing to help testing it, 'dnf copr enable
jpopelka/dhcp-ldap-auth' is all you need to do to enable the testing
repo (https://copr.fedoraproject.org/coprs/jpopelka/dhcp-ldap-auth/).
Then please send feedback to me (CC s...@isc.org).

Thank you.
--
Jiri


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

pyorbit

[Michael Schwendt]

http://pkgs.fedoraproject.org/cgit/pyorbit.git/plain/dead.package

> last user has been retired, package EOL

Error: nothing provides pyorbit(x86-64) >= 2.0.1 needed by 
gnome-python2-bonobo-2.28.1-16.fc23.x86_64

What's the full story here? Where has this been discussed/announced?
-- 
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: updating f22 llvm to 3.5.2 release?

[Michel Alexandre Salim]

Hi Jens,

Any update on the proposed llvm35 package? One of my package (Pure) is
affected as it uses the old JIT that is dropped in 3.6, and upstream has
only just started rewriting for mcjit.

If you need a reviewer just ping.

Thanks,

-- 
Michel

On Wed, May 20, 2015 at 7:09 PM Jens Petersen  wrote:

> Hi,
>
> I opened https://bugzilla.redhat.com/show_bug.cgi?id=1221923
> about this too but thought it would be good to ask here.
>
> F22 currently has llvm-3.5.0 (F23 is now on 3.6.0):
> I believe there is a newer 3.5.2 bugfix release -
> would it make sense to make a F22 update for that?
> Is there any expected risk with doing that?
>
> Anyway for F23 I probably have to make a llvm35 package
> again for building ghc-7.10 on armv7 (and ideally aarch64).
> 3.5.0 has a critical bug that breaks ghc, so it would
> be based on 3.5.2 anyway.
>
> Jens
> --
> 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: Geeqie... I'll take it -- but I'd like co-maintainers! [was Re: Orphaned Geeqie]

[Jonathan Wakely]

On 20/07/15 23:49 +0200, Michael Schwendt wrote:

and xcf-pixbuf-loader is in a poor state
at Fedora and upstream, too:

https://lists.fedoraproject.org/pipermail/devel/2014-November/204608.html
http://pkgs.fedoraproject.org/cgit/xcf-pixbuf-loader.git/log/


That is also lost in the gitorious.org vortex, and the code looks very
smelly in places.

For example this can't be right:

   if (rgb1[0] == rgb1[1] == rgb1[2]) {

Presumably that's meant to be:

   if (rgb1[0] == rgb1[1] && rgb1[0] == rgb1[2]) {

Elsewhere it should be checking the return value of fread() and
fseek() for errors, instead of assuming the input file is always
valid.

There also seem to be memory leaks and temporary files not removed on
error.

Yuck.

--
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: Granting a capability to a service

[Florian Weimer]

On 07/21/2015 06:22 AM, Steve Grubb wrote:

> Sure, there are cases where you know that. But let's take 'ping' as an 
> example 
> of what I'm talking about. It should never have children. If it does, its 
> been 
> exploited.

You can't know that.  ping performs name resolution, and it's perfectly
fine for a NSS module to create a subprocess (with the appropriate clone
flags etc., to avoid interfering with the process handling).  In fact,
this approach could well be used to enhance security, and may be
required if the NSS module uses complex libraries such as OpenSSL.  (See
nss_ldap vs nss_ldapd for reasons for this kind of process separation.)

-- 
Florian Weimer / Red Hat Product Security
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct