Re: rawhide buildroot creation changes

[Neal Gompa]

On Sat, Oct 10, 2015 at 4:03 PM, Richard W.M. Jones 
wrote:

> On Sat, Oct 10, 2015 at 03:54:41PM -0400, Neal Gompa wrote:
> > On Sat, Oct 10, 2015 at 3:52 PM, Richard W.M. Jones 
> > wrote:
> > > Are we using a branch of koji?
> >
> > ​Is this part of the mysterious Koji 2.0 codebase that I can't seem to
> find
> > anywhere?​
>
> I don't know - was that question directed to me?
>
>
​Sorry, no. I didn't mean to direct it at you. I'm just really puzzled why
I can't find anything useful (codewise, roadmap, etc.) on Koji 2.0. I've
been doing research on buildsystems for other projects for a while now, and
it's very frustrating that I can't find anything about what's going on with
Koji.​



> The koji.git here:
>
>   https://git.fedorahosted.org/cgit/koji/
>
> is certainly getting lots of updates.  It doesn't reference dnf, but
> maybe it doesn't need to (however it does reference yum a lot).
>
> (BTW is anyone else disturbed by the relatively massive user icons
> that are now shown on git.fedorahosted.org?  Seems to be a recent
> change).
>
> Rich.
>

​That's... certainly strange. Though, no stranger than the Fedora cgit
theming disappearing from all of Fedora's cgit instances for a while. I
can't actually recall if fedorahosted also had the Fedora cgit theme on it
or not...​


>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html




-- 
真実はいつも一つ！/ 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: rawhide buildroot creation changes

[Kevin Fenzi]

On Sat, 10 Oct 2015 15:54:41 -0400
Neal Gompa  wrote:

> On Sat, Oct 10, 2015 at 3:52 PM, Richard W.M. Jones
>  wrote:

...snip...

> > So I was having a look at how to change this in the configuration,
> > but I don't understand how the dnf.conf is generated at all.  There
> > seems to be no reference to dnf at all in upstream koji.
> >
> > Are we using a branch of koji?

We are using koji git head + some patches. 
srpm at: 

http://infrastructure.fedoraproject.org/repo/builder-rpms/21/SRPMS/koji-1.10.0-2.fc21.2.fed.livecd.3.src.rpm

> ​Is this part of the mysterious Koji 2.0 codebase that I can't seem
> to find anywhere?​

Koji 2.0 does not exist yet that I know of in any code form. 

Upstream developers have just started gathering what they want to do in
2.0... 0 code has been written that I know of. 

kevin




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

Self Introduction: Nuno Dias

[Nuno Dias]

 Hi,

 Following the procedure from "Join the package collection
maintainers", let me introduce myself, 

 I usually create rpms to my use, and after some years doing that, I
realised that maybe I should contribute, I use Linux every day, I
started with RedHat some year ago, and now Fedora is my Desktop.

 The package I requested to review can be see in this link
 https://bugzilla.redhat.com/show_bug.cgi?id=1270531

 This is a Twitter, Facebook & Tumblr client.

 Because it's my first package in Fedora, I need a sponsor.

Thanks,
Nuno
-- 
Nuno Dias 

-- 
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: rawhide buildroot creation changes

[Richard W.M. Jones]

On Fri, Oct 09, 2015 at 09:58:39PM +0100, Richard W.M. Jones wrote:
> On Fri, Oct 09, 2015 at 10:47:22AM -0500, Dennis Gilmore wrote:
> > as of this morning US time we have changed the way rawhide buildroots are 
> > created in koji.  rawhide is now using dnf to install the packages into the 
> > buildroot. this means that in f24 and on dnf will be used to create the 
> > buildroot. as well as manage the updates on your system.
> 
> One thing that would be very helpful would be to enable keepcache=1 in
> the dnf configuration?  This is consistent with what yum was doing in
> the old config, and in particular lets supermin pull out the pristine
> RPMs of the installed packages, so we can build the libguestfs appliance.

So I was having a look at how to change this in the configuration, but
I don't understand how the dnf.conf is generated at all.  There seems
to be no reference to dnf at all in upstream koji.

Are we using a branch of koji?

Thanks,

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: retire lesstif in f24 and beyond

[Zbigniew Jędrzejewski-Szmek]

On Sat, Oct 10, 2015 at 07:20:22AM +0200, Ralf Corsepius wrote:
> On 10/09/2015 09:17 PM, Stephen John Smoogen wrote:
> >On 8 October 2015 at 17:04, Kevin Kofler  wrote:
> >>Christopher Meng wrote:
> >>>IMO motif should 'Obsoletes' lesstif in Fedora since motif is free now.
> >>
> >>The reason we kept lesstif even after OpenMotif was finally freed is because
> >>OpenMotif only implements the Motif 2 API, whereas lesstif implemented the
> >>Motif 1 API. Back then, a lot of Motif applications did not compile with
> >>Motif 2.
> >>
> >
> >A lot of applications still do not mainly because by the time
> >OpenMotif was out.. "Motif" was dead except for legacy computer code
> >that a lot of research institutes still use. It looks from the amount
> >of porting that has been done in this thread that a lot of those
> >problems are easier to fix now?
> >
> > From the people who did the porting was it a quick fix or a bunch of 
> > patches?
> 
> As far as the packages I touched are concerned, the "porting effort"
> was very low.
> 
> The effort basically was reflecting the packaging dep-naming changes
> into the specs.
> 
> I did not have to apply any changes to the packages' source code. My
> guess is, on the code-level, today's "Motif" is sufficiently
> backward compatible, the packages already saw testing against Motif
> or even been developed on Motif (and then ported to lesstif)[1]. I
> point, I which makes me wonder, is Fedora seemingly being late in
> the switch to Motif in comparison to other distros.
> 
> A problem hiding is package installation conflicts between the
> *-devel package of different versions of the lesstif, openmotif and
> motif packages. Therefore, I tried to stay with lesstif on fedora <
> 24 and switch to motif only on fedora >= 24.
> 
> I know, we are late in the release schedule, but I am considering to
> switching at least Inventor to motif on fc23, as well - It's
> unimportant enough to most users, but is important to me ;)

I think that in a case of leaf package like that it totally makes
sense to switch even this late before release. Removal of
a dependency on lesstif seems important enough.

Zbyszek
-- 
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: rawhide buildroot creation changes

[Richard W.M. Jones]

On Sat, Oct 10, 2015 at 03:54:41PM -0400, Neal Gompa wrote:
> On Sat, Oct 10, 2015 at 3:52 PM, Richard W.M. Jones 
> wrote:
> > Are we using a branch of koji?
> 
> ​Is this part of the mysterious Koji 2.0 codebase that I can't seem to find
> anywhere?​

I don't know - was that question directed to me?

The koji.git here:

  https://git.fedorahosted.org/cgit/koji/

is certainly getting lots of updates.  It doesn't reference dnf, but
maybe it doesn't need to (however it does reference yum a lot).

(BTW is anyone else disturbed by the relatively massive user icons
that are now shown on git.fedorahosted.org?  Seems to be a recent
change).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rawhide buildroot creation changes

[Orion Poplawski]

On 10/10/2015 04:24 AM, Rex Dieter wrote:

Tom Hughes wrote:


On 10/10/15 10:59, Rex Dieter wrote:

Dennis Gilmore wrote:


as of this morning US time we have changed the way rawhide buildroots
are
created in koji.  rawhide is now using dnf to install the packages into
the buildroot. this means that in f24 and on dnf will be used to create
the buildroot. as well as manage the updates on your system.

We will not be making the same change to f22 or f23 in koji,  yum will
continue to create the buildroot there.  please report to Release
Engineering
[1][2][3] any issue you encounter as a result of this change.


Seems all (most?) rawhide builds are failing now.

https://fedorahosted.org/rel-eng/ticket/6273


That's the only one I've had that failed in that way. I had another
koschei report but that was in the actual build when running tests and
passed when run again as a manual scratch build.


OK, I see *some* f24 buildds succeeding now that I've looked closer... My
problematic pkg was qt5-qttools, but seems that it's actually working now on
my 3rd try.

Still, *something* is going funny, we really do want reliably reproducible
builds.

-- Rex



Looks to be a problem only on arm builders.  I've noted that in the reports.

--
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
--
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 1270076] perl-Log-Report-1.08 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-Log-Report-1.08-1.fc21 has been pushed to the Fedora 21 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 'dnf --enablerepo=updates-testing update perl-Log-Report'
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2015-6d5c41bb1b

-- 
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: rawhide buildroot creation changes

[Neal Gompa]

On Sat, Oct 10, 2015 at 3:52 PM, Richard W.M. Jones 
wrote:

> On Fri, Oct 09, 2015 at 09:58:39PM +0100, Richard W.M. Jones wrote:
> > On Fri, Oct 09, 2015 at 10:47:22AM -0500, Dennis Gilmore wrote:
> > > as of this morning US time we have changed the way rawhide buildroots
> are
> > > created in koji.  rawhide is now using dnf to install the packages
> into the
> > > buildroot. this means that in f24 and on dnf will be used to create the
> > > buildroot. as well as manage the updates on your system.
> >
> > One thing that would be very helpful would be to enable keepcache=1 in
> > the dnf configuration?  This is consistent with what yum was doing in
> > the old config, and in particular lets supermin pull out the pristine
> > RPMs of the installed packages, so we can build the libguestfs appliance.
>
> So I was having a look at how to change this in the configuration, but
> I don't understand how the dnf.conf is generated at all.  There seems
> to be no reference to dnf at all in upstream koji.
>
> Are we using a branch of koji?
>
> Thanks,
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/


​Is this part of the mysterious Koji 2.0 codebase that I can't seem to find
anywhere?​


-- 
真実はいつも一つ！/ 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: Summary/Minutes from today's FESCo Meeting (2015-10-07)

[Orion Poplawski]

On 10/09/2015 11:30 PM, Neal Gompa wrote:

Though, I don't quite understand what the purpose for sonames
are in the first place, if they aren't really designed for supporting
parallel installable stuff...


They signal a break in ABI.  Applications must be recompiled to link to 
the new version because they would not work with the new version otherwise.


--
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
--
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: Self Introduction: Nuno Dias

[Haïkel]

2015-10-10 21:38 GMT+02:00 Nuno Dias :
>  Hi,
>
>  Following the procedure from "Join the package collection
> maintainers", let me introduce myself,
>
>  I usually create rpms to my use, and after some years doing that, I
> realised that maybe I should contribute, I use Linux every day, I
> started with RedHat some year ago, and now Fedora is my Desktop.
>
>  The package I requested to review can be see in this link
>  https://bugzilla.redhat.com/show_bug.cgi?id=1270531
>
>  This is a Twitter, Facebook & Tumblr client.
>
>  Because it's my first package in Fedora, I need a sponsor.
>
> Thanks,
> Nuno
> --
> Nuno Dias 
>

Welcome into Fedora!
My sponsoring queue is already full, but I'll leave some comments in
your review.

Some recommendations to get sponsored faster:
* help decreasing the reviewing queue by providing *informal* reviews
for new packages
http://fedoraproject.org/PackageReviewStatus/NEW.html
* providing patches to fix existing packages may encourage a sponsor
to sponsor you.

Don't forget to link back your reviews and patches to your initial review

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

Query: %cmake not doing out-of-tree builds?

[Neal Gompa]

Hello all,

Over the last few weeks, I've been working on a number of packages that use
CMake for the build system for various distros, and I've noticed something
rather peculiar. Of all the distros I've built packages for (Fedora/CentOS,
openSUSE, Mageia, Debian, and Ubuntu), only Fedora/CentOS does not
automatically do CMake building in a subdirectory such that the build
artifacts don't mix in with the source tree. Essentially, the %cmake macro
doesn't enforce builds are out-of-tree.

Is there a particular reason for 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: rawhide buildroot creation changes

[Richard W.M. Jones]

On Fri, Oct 09, 2015 at 09:58:39PM +0100, Richard W.M. Jones wrote:
> On Fri, Oct 09, 2015 at 10:47:22AM -0500, Dennis Gilmore wrote:
> > as of this morning US time we have changed the way rawhide buildroots are 
> > created in koji.  rawhide is now using dnf to install the packages into the 
> > buildroot. this means that in f24 and on dnf will be used to create the 
> > buildroot. as well as manage the updates on your system.
> 
> One thing that would be very helpful would be to enable keepcache=1 in
> the dnf configuration?  This is consistent with what yum was doing in
> the old config, and in particular lets supermin pull out the pristine
> RPMs of the installed packages, so we can build the libguestfs appliance.

I opened:

https://fedorahosted.org/rel-eng/ticket/6274

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Query: %cmake not doing out-of-tree builds?

[Haïkel]

2015-10-10 22:25 GMT+02:00 Neal Gompa :
> Hello all,
>
> Over the last few weeks, I've been working on a number of packages that use
> CMake for the build system for various distros, and I've noticed something
> rather peculiar. Of all the distros I've built packages for (Fedora/CentOS,
> openSUSE, Mageia, Debian, and Ubuntu), only Fedora/CentOS does not
> automatically do CMake building in a subdirectory such that the build
> artifacts don't mix in with the source tree. Essentially, the %cmake macro
> doesn't enforce builds are out-of-tree.
>
> Is there a particular reason for this?
>

According Rex who implemented the %cmake macro
https://www.redhat.com/archives/fedora-packaging/2007-March/msg00044.html

I must admit that I agree that out-of-tree builds is not  very useful
in RPM packaging case, as you always scratch the build directory.
Implementing out-of-tree builds who result in having to move between
directories during package building which could error-prone.

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: ipset unmaintained

[Haïkel]

Done, fails to build in rawhide due to an unrelated ARM builder failure.

> DEBUG util.py:393:  Config error: releasever not given and can not be 
> detected from the installroot.
https://kojipkgs.fedoraproject.org//work/tasks/3255/11403255/root.log

F23 update submitted.
-- 
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: rawhide buildroot creation changes

[Richard W.M. Jones]

On Sat, Oct 10, 2015 at 02:28:21PM -0600, Kevin Fenzi wrote:
> On Sat, 10 Oct 2015 21:03:32 +0100
> "Richard W.M. Jones"  wrote:
> 
> > (BTW is anyone else disturbed by the relatively massive user icons
> > that are now shown on git.fedorahosted.org?  Seems to be a recent
> > change).
> 
> Odd. I'm not sure how that happened, it was definitely not intended. 
> 
> Can you file an infrastructure ticket on it so we actually you know,
> know about it and can fix it?

Here you go:

https://fedorahosted.org/fedora-infrastructure/ticket/4921

Wasn't sure what Component to use, so I guessed
'SCM (Source Code Management)'.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Query: %cmake not doing out-of-tree builds?

[Haïkel]

2015-10-11 2:14 GMT+02:00 Neal Gompa :
>
> I pretty much wound up doing that, but I wanted to know if there was a
> reason for not having it built into the macro like Mageia and SUSE do.
>
>

Fedora's %cmake macros came first many years ago before Suse's version.

Again:
1. it has little value for packaging, we don't reuse the sources
between two package builds.
If your CMake script is broken (no install rules), you should fix it.
I may be mistaken but it seems that you're trying to fix a package by
trial and errors: detecting generated files and then install them by
hand rather than patching your CMake script. Install rules are fairly
easy to write with CMake, and these patches could be upstreamed. [1]

Yes, out-of-tree builds is a nice feature of CMake but it's
interesting as a developer, not as a packager. We have very different
workflows, explaining why this is less important for packaging.

2. it is error-prone to implicitly move to a different directory.
Put yourself in a new packager's shoes: you want to copy a file from
sources (very common example: license file) and is not aware that the
%cmake macros moves you to a different directory, then, you get to
waste time trying to "debug" this.

3. As Orion stated, you can do an out-of-tree build explicitly, which is fine.

This is the typical example where simple design is better than
"smart". As a sponsor, I appreciate that the Fedora macro just do what
it's expected to do, nothing more (least-surprise principle). Mentees
have to learn a lot of concepts, read a lot of guidelines, do not add
them the burden of "smart" macros with unexpected behaviours. It will
save you *one* line in a spec, it could save many hours for many
newbies.
If you want my opinion, implementing a cmake template in rpmdev-tools
with out-of-tree build support would be a better alternative.

Regards,
H.

[1] this discussion reminded me of a very nice introduction to RPM
packaging from Matthias Saou about RPM packaging (The Fight), the
first step being "Know your enemy : The source!".
http://freshrpms.net/docs/fight/
-- 
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: rawhide buildroot creation changes

[Kevin Fenzi]

On Sat, 10 Oct 2015 16:27:30 -0400
Neal Gompa  wrote:

> ​What about createrepo_c? Are we using that now for Koji instead of
> createrepo?​

No.

kevin


pgpMr0EAuYoCC.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: rawhide buildroot creation changes

[Kevin Fenzi]

On Sat, 10 Oct 2015 21:32:40 +0100
"Richard W.M. Jones"  wrote:

> Here you go:
> 
> https://fedorahosted.org/fedora-infrastructure/ticket/4921
> 
> Wasn't sure what Component to use, so I guessed
> 'SCM (Source Code Management)'.

Thanks. We will get it sorted... 

kevin



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

ipset unmaintained

[Xose Vazquez Perez]

Hi,

Can anyone update it ?
https://bugzilla.redhat.com/1145913

-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: Query: %cmake not doing out-of-tree builds?

[Neal Gompa]

On Sat, Oct 10, 2015 at 7:52 PM, Orion Poplawski 
wrote:

> On 10/10/2015 02:25 PM, Neal Gompa wrote:
>
>> Hello all,
>>
>> Over the last few weeks, I've been working on a number of packages that
>> use CMake for the build system for various distros, and I've noticed
>> something rather peculiar. Of all the distros I've built packages for
>> (Fedora/CentOS, openSUSE, Mageia, Debian, and Ubuntu), only
>> Fedora/CentOS does not automatically do CMake building in a subdirectory
>> such that the build artifacts don't mix in with the source tree.
>> Essentially, the %cmake macro doesn't enforce builds are out-of-tree.
>>
>> Is there a particular reason for this?
>>
>
> Freedom, baby!
>
> But you certainly can do it if you want:
>
> mkdir build
> cd build
> %cmake ..
>
> Which I do think should be pretty much the standard.
>
> --
> 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
>
>
​I pretty much wound up doing that, but I wanted to know if there was a
reason for not having it built into the macro like Mageia and SUSE do.​




-- 
真実はいつも一つ！/ 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: Query: %cmake not doing out-of-tree builds?

[Neal Gompa]

On Sat, Oct 10, 2015 at 9:31 PM, Haïkel  wrote:

> 2015-10-11 2:14 GMT+02:00 Neal Gompa :
> >
> > I pretty much wound up doing that, but I wanted to know if there was a
> > reason for not having it built into the macro like Mageia and SUSE do.
> >
> >
>
> Fedora's %cmake macros came first many years ago before Suse's version.
>
> Again:
> 1. it has little value for packaging, we don't reuse the sources
> between two package builds.
> If your CMake script is broken (no install rules), you should fix it.
> I may be mistaken but it seems that you're trying to fix a package by
> trial and errors: detecting generated files and then install them by
> hand rather than patching your CMake script. Install rules are fairly
> easy to write with CMake, and these patches could be upstreamed. [1]
>
> Yes, out-of-tree builds is a nice feature of CMake but it's
> interesting as a developer, not as a packager. We have very different
> workflows, explaining why this is less important for packaging.
>
>
​I've considered doing that, but some of the upstreams I've tentatively
talked to about it didn't want to, considering Fedora to be "too special"
when SUSE/Mageia/Debian/etc "play nice" with theirs. But the rationale is
nice to know.​



> 2. it is error-prone to implicitly move to a different directory.
> Put yourself in a new packager's shoes: you want to copy a file from
> sources (very common example: license file) and is not aware that the
> %cmake macros moves you to a different directory, then, you get to
> waste time trying to "debug" this.
>
>
​I can certainly see that. I tend to agree when it's put like that.​



> 3. As Orion stated, you can do an out-of-tree build explicitly, which is
> fine.
>
> This is the typical example where simple design is better than
> "smart". As a sponsor, I appreciate that the Fedora macro just do what
> it's expected to do, nothing more (least-surprise principle). Mentees
> have to learn a lot of concepts, read a lot of guidelines, do not add
> them the burden of "smart" macros with unexpected behaviours. It will
> save you *one* line in a spec, it could save many hours for many
> newbies.
> If you want my opinion, implementing a cmake template in rpmdev-tools
> with out-of-tree build support would be a better alternative.
>
>
​Actually, I think all our rpmdevtools templates need some work. ​

It would be good if we had templates that put things in place and
implemented the best practices we use today by default. Currently,
rpmdevtools seems to be stuck in RPM 4.8 or something like that in terms of
defaults. We don't use %make_build, %{buildroot} is not the default, we
don't generate Python specs in compliance with our own guidelines, and we
don't have templates for CMake, Gradle, PHP (composer), among many others.

I don't even know *what* our guidelines are for how to build packages that
use some of these systems.



> Regards,
> H.
>
> [1] this discussion reminded me of a very nice introduction to RPM
> packaging from Matthias Saou about RPM packaging (The Fight), the
> first step being "Know your enemy : The source!".
> http://freshrpms.net/docs/fight/
>
>



-- 
真実はいつも一つ！/ 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: rawhide buildroot creation changes

[Richard W.M. Jones]

On Sat, Oct 10, 2015 at 09:12:34PM +0100, Richard W.M. Jones wrote:
> On Sat, Oct 10, 2015 at 04:07:41PM -0400, Neal Gompa wrote:
> > On Sat, Oct 10, 2015 at 4:03 PM, Richard W.M. Jones 
> > wrote:
> > 
> > > On Sat, Oct 10, 2015 at 03:54:41PM -0400, Neal Gompa wrote:
> > > > On Sat, Oct 10, 2015 at 3:52 PM, Richard W.M. Jones 
> > > > wrote:
> > > > > Are we using a branch of koji?
> > > >
> > > > ​Is this part of the mysterious Koji 2.0 codebase that I can't seem to
> > > find
> > > > anywhere?​
> > >
> > > I don't know - was that question directed to me?
> > >
> > >
> > ​Sorry, no. I didn't mean to direct it at you.  I'm just really puzzled why
> > I can't find anything useful (codewise, roadmap, etc.) on Koji 2.0. I've
> > been doing research on buildsystems for other projects for a while now, and
> > it's very frustrating that I can't find anything about what's going on with
> > Koji.​
> 
> No problem - I'm confused too about whether dnf support is included in
> that version of koji from git.

Oh I see now.  dnf support comes from mock.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rawhide buildroot creation changes

[Kevin Fenzi]

On Sat, 10 Oct 2015 21:03:32 +0100
"Richard W.M. Jones"  wrote:

> (BTW is anyone else disturbed by the relatively massive user icons
> that are now shown on git.fedorahosted.org?  Seems to be a recent
> change).

Odd. I'm not sure how that happened, it was definitely not intended. 

Can you file an infrastructure ticket on it so we actually you know,
know about it and can fix it?

kevin


pgp4tqVyDlhF6.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: rawhide buildroot creation changes

[Neal Gompa]

On Sat, Oct 10, 2015 at 4:07 PM, Kevin Fenzi  wrote:

> On Sat, 10 Oct 2015 15:54:41 -0400
> Neal Gompa  wrote:
>
> > On Sat, Oct 10, 2015 at 3:52 PM, Richard W.M. Jones
> >  wrote:
>
> ...snip...
>
> > > So I was having a look at how to change this in the configuration,
> > > but I don't understand how the dnf.conf is generated at all.  There
> > > seems to be no reference to dnf at all in upstream koji.
> > >
> > > Are we using a branch of koji?
>
> We are using koji git head + some patches.
> srpm at:
>
>
> http://infrastructure.fedoraproject.org/repo/builder-rpms/21/SRPMS/koji-1.10.0-2.fc21.2.fed.livecd.3.src.rpm
>
> > ​Is this part of the mysterious Koji 2.0 codebase that I can't seem
> > to find anywhere?​
>
> Koji 2.0 does not exist yet that I know of in any code form.
>
> Upstream developers have just started gathering what they want to do in
> 2.0... 0 code has been written that I know of.
>
> kevin
>
>
​What about createrepo_c? Are we using that now for Koji instead of
createrepo?​

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

[Kevin Fenzi]

On Fri, 09 Oct 2015 14:30:02 -0400
Lyude  wrote:

> Hello! Although my legal name is Chandler, please just call me Lyude
> ;).

Hello. :) 

> I've been a Linux user for a couple years now, and as of the past few
> years have became a developer and am working on making a career out of
> it. I'm currently interning for Red Hat and hoping to get a full time
> job at the end of my internship.I've contributed to numerous projects
> such as Wayland, Weston, libinput, various Xorg drivers and the Linux
> kernel. I'm currently working on getting my ps2emu-tools package into
> Fedora. It's a set of tools that allow you to record PS/2 devices such
> as laptop touchpads, and use the userio kernel module to replay them
> on another machine for debugging kernel drivers without needing the
> physical device in front of you. The userio patches are still in the
> middle of review on the LKML, but you can find the bugzilla for my
> package here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1245351

Nice. Welcome to the fun... 

kevin


pgpO2jsDox95Y.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: Query: %cmake not doing out-of-tree builds?

[Orion Poplawski]

On 10/10/2015 02:25 PM, Neal Gompa wrote:

Hello all,

Over the last few weeks, I've been working on a number of packages that
use CMake for the build system for various distros, and I've noticed
something rather peculiar. Of all the distros I've built packages for
(Fedora/CentOS, openSUSE, Mageia, Debian, and Ubuntu), only
Fedora/CentOS does not automatically do CMake building in a subdirectory
such that the build artifacts don't mix in with the source tree.
Essentially, the %cmake macro doesn't enforce builds are out-of-tree.

Is there a particular reason for this?


Freedom, baby!

But you certainly can do it if you want:

mkdir build
cd build
%cmake ..

Which I do think should be pretty much the standard.

--
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
--
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: rawhide buildroot creation changes

[Richard W.M. Jones]

On Sat, Oct 10, 2015 at 04:07:41PM -0400, Neal Gompa wrote:
> On Sat, Oct 10, 2015 at 4:03 PM, Richard W.M. Jones 
> wrote:
> 
> > On Sat, Oct 10, 2015 at 03:54:41PM -0400, Neal Gompa wrote:
> > > On Sat, Oct 10, 2015 at 3:52 PM, Richard W.M. Jones 
> > > wrote:
> > > > Are we using a branch of koji?
> > >
> > > ​Is this part of the mysterious Koji 2.0 codebase that I can't seem to
> > find
> > > anywhere?​
> >
> > I don't know - was that question directed to me?
> >
> >
> ​Sorry, no. I didn't mean to direct it at you.  I'm just really puzzled why
> I can't find anything useful (codewise, roadmap, etc.) on Koji 2.0. I've
> been doing research on buildsystems for other projects for a while now, and
> it's very frustrating that I can't find anything about what's going on with
> Koji.​

No problem - I'm confused too about whether dnf support is included in
that version of koji from git.

> ​That's... certainly strange. Though, no stranger than the Fedora cgit
> theming disappearing from all of Fedora's cgit instances for a while. I
> can't actually recall if fedorahosted also had the Fedora cgit theme on it
> or not...​

The massive icons are slightly disturbing :-)

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: Query: %cmake not doing out-of-tree builds?

[Neal Gompa]

On Sat, Oct 10, 2015 at 4:49 PM, Haïkel  wrote:

> 2015-10-10 22:25 GMT+02:00 Neal Gompa :
> > Hello all,
> >
> > Over the last few weeks, I've been working on a number of packages that
> use
> > CMake for the build system for various distros, and I've noticed
> something
> > rather peculiar. Of all the distros I've built packages for
> (Fedora/CentOS,
> > openSUSE, Mageia, Debian, and Ubuntu), only Fedora/CentOS does not
> > automatically do CMake building in a subdirectory such that the build
> > artifacts don't mix in with the source tree. Essentially, the %cmake
> macro
> > doesn't enforce builds are out-of-tree.
> >
> > Is there a particular reason for this?
> >
>
> According Rex who implemented the %cmake macro
> https://www.redhat.com/archives/fedora-packaging/2007-March/msg00044.html
>
> I must admit that I agree that out-of-tree builds is not  very useful
> in RPM packaging case, as you always scratch the build directory.
> Implementing out-of-tree builds who result in having to move between
> directories during package building which could error-prone.
>
> Regards,
> H.
>

It has come up for me as somewhat problematic, as when builds fail, it's
hard to tell what happened to the generated and pristine data, because it
seems quite a few of these make the assumption it is going to be out of
tree and happily do things that make no sense for in-source builds. What's
worse, at least one of them doesn't even implement a proper install target,
so that makes things somewhat challenging.

At the end of the day, it's just strange to me that our CMake building is
in-source instead of out of source, since the whole *point* of CMake in the
first place is to be used for out-of-source builds.


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

Fedora Rawhide 20151010 compose check report

[Fedora compose checker]

No missing expected images.

Images in this compose but not Rawhide 20151009:

Design_suite live x86_64
Cloud docker x86_64
Kde disk raw armhfp
Kde live i386
Scientific_kde live x86_64
Scientific_kde live i386
Design_suite live i386
Kde live x86_64

No images in Rawhide 20151009 but not this.

Failed openQA tests: 11 of 52

ID: 5360Test: x86_64 kde_live default_install
ID: 5355Test: i386 workstation_live default_install
ID: 5354Test: i386 kde_live default_install
ID: 5348Test: i386 universal upgrade_desktop_32bit
ID: 5333Test: x86_64 universal server_simple_free_space@uefi
ID: 5331Test: x86_64 universal server_delete_partial@uefi
ID: 5328Test: x86_64 universal european_language_install
ID: 5324Test: x86_64 universal upgrade_desktop_64bit
ID: 5323Test: x86_64 universal upgrade_minimal_64bit
ID: 5312Test: x86_64 universal server_repository_http_variation
ID: 5309Test: x86_64 universal server_delete_pata

Passed openQA tests: 41 of 52
-- 
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

Re: ipset unmaintained

[Haïkel]

2015-10-10 22:37 GMT+02:00 Xose Vazquez Perez :
> Hi,
>
> Can anyone update it ?
> https://bugzilla.redhat.com/1145913
>
> -thanks-
>

Please start the unresponsive maintainer process.
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

Meanwhile, I'll update it in rawhide.

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

Fedora 23 Branched 20151010 compose check report

[Fedora compose checker]

No missing expected images.

Images in this compose but not 23 Branched 20151009:

Workstation disk raw armhfp

Images in 23 Branched 20151009 but not this:

Cloud docker x86_64

Failed openQA tests: 10 of 52

ID: 5361Test: x86_64 generic_boot default_install@uefi
ID: 5304Test: i386 workstation_live default_install
ID: 5301Test: x86_64 kde_live default_install
ID: 5300Test: i386 kde_live default_install
ID: 5296Test: i386 universal upgrade_desktop_32bit
ID: 5292Test: i386 universal server_software_raid
ID: 5290Test: i386 universal server_repository_http_graphical
ID: 5281Test: x86_64 universal server_simple_free_space@uefi
ID: 5279Test: x86_64 universal server_delete_partial@uefi
ID: 5272Test: x86_64 universal upgrade_desktop_64bit

Passed openQA tests: 42 of 52
-- 
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

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

[Alec Leamas]

On 09/10/15 21:13, Stephen Gallagher wrote:

> I completely, wholeheartedly agree with you here. However, the
> unfortunate fact of life is that we can lead a horse to water but
> cannot make them drink. Our previous policy was essentially holding
> the horse's head under the water until it drained the pond or drowned
> in it. I feel we can do better by being more moderate. The Unbundling
> SIG mentioned elsewhere in this thread is probably a more productive
> approach.

First, I generally agree that leaving the final decision to the packager
under the kind of umbrella proposed is the right thing to do.

That said, question is if we are leading the horse to the water? IMHO,
the proposed rules is more like pointing out the general direction to
the water for the poor horse (that's me, a mere mortal packager).

Perhaps Kevin K has a point in that these rules doesn't even require a
motivation from the packager when bundling. What if we required some
kind of process, still leaving the final decision to the packager? E.
g., requiring that all bundling should be at least reported to the FPC,
with a revised set of standard questions dealt with? Perhaps requiring
that FPC (or some other body) should be given the chance to give some
piece of advice before the bundled package is committed?

Whatever. But if we take bundling seriously, why not require some kind
of process? Not so complicated that it's simply avoided (as often
today), but still something which makes a packager think twice?


Cheers!

--alec

PS Sorry for not being able to match Stephens horse-drowning metaphor :) DS
-- 
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: "Unbundling SIG" was [Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)]

[Haïkel]

2015-10-10 1:31 GMT+02:00 Kevin Kofler :
> Matthew Miller wrote:
>> When the packager has reasoned belief that debundling is actively bad
>> in some way for this package, I think we should trust the packager. I
>> know not everyone on this thread agrees, but in general, Fedora
>> *always* places a high level of trust in our packagers to make the
>> right call in all sorts of situations. Here, perhaps some of the
>> current (former?) pages on the rationale for unbundling could be moved
>> into the Unbundling SIG's space and used as guidance.
>
> I am worried that a lot of packagers will just refuse to do anything that
> upstream does not support, either:
> * because they ARE upstream, or
> * because they are too worried about offending upstream, or
> * because they are too lazy and/or too busy to rebase patches.
> And the often-cited fact that there are more and more upstreams not
> supporting unbundling only makes this WORSE and is actually a reason for
> MORE strictness in downstream policies, not less!
>
> The new policy does not require any kind of rationale for refusing, just
> saying "no" is enough to block everything.
>

In short: packagers are not to be trusted, that's the bottom line of
your argumentation.

Being putting down stricter guidelines without any means of enforcing
them, you're not solving anything.
FESCo choose to trust contributors to do the right thing and being honest.

>> Obviously we're not Debian, but I think this part from their Getting
>> Started guide applies to volunteer software projects in general:
>>
>> * We all are volunteers.
>>  * You cannot impose on others what to do.
>>  * You should be motivated to do things by yourself.
>>
>> 
>
> I find it funny that you are citing Debian in an attempt to support your
> point, because Debian actually has a "no bundled libraries" policy at least
> as strict as our old one.
>
> Kevin Kofler
>

Wrong, it's even more "laxist" than our current one.
https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
https://fedoraproject.org/wiki/User:Tibbs/BundlingDraft2

You know the difference? Debian trusts maintainers to do the right
thing by default.
If we can't trust Fedora maintainers, then we have another problem to solve.

Besides, you're not answering the question, Matthew changed the topic
to focus the discussion on the Unbundling SIG proposal.
I think it's a better idea to have a focused group leading that effort
and I hope closely with FPC.

I envision their mission being:
* work on detecting bundled libraries in the current packages collection
* work with package maintainers and upstream developers to reduce bundling.
* document
* cooperate with FPC to apply best practices
* cooperate with security team when CVE is discovered in a bundled lib
(filing tickets or apply fix as provenpackagers)
* provides metrics to follow the progress of that effort.

If you care about reducing bundling, this is a far more effective
solution than stricter guidelines.

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: Proposal to reduce anti-bundling requirements

[Haïkel]

2015-10-10 1:12 GMT+02:00 Kevin Kofler :
> Ian Malone wrote:
>> I'm actually all for unbundling, but going it alone is not guaranteed
>> to be simple. "Oh, hey, that deprecated function has been removed."
>
> Then you try to port the application to the new APIs, and if it's not
> possible, you revert the library commit that removed the old API.
>
> Kevin Kofler
>

And what happens if the library is consumed by other packages
requiring the new API?

Let's keep Ian example:
You keep the deprecated function in the new library despite upstream's
decision. Since we keep shipping it, developers will keep using it in
their new software, making it incompatible with other distro.
We only had one problem, now we have more problems.

Engineering is not science, as previously stated, it's about compromises.

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: rawhide buildroot creation changes

[Rex Dieter]

Dennis Gilmore wrote:

> as of this morning US time we have changed the way rawhide buildroots are
> created in koji.  rawhide is now using dnf to install the packages into
> the buildroot. this means that in f24 and on dnf will be used to create
> the buildroot. as well as manage the updates on your system.
> 
> We will not be making the same change to f22 or f23 in koji,  yum will
> continue to create the buildroot there.  please report to Release
> Engineering
> [1][2][3] any issue you encounter as a result of this change.

Seems all (most?) rawhide builds are failing now.

https://fedorahosted.org/rel-eng/ticket/6273

-- Rex

-- 
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: rawhide buildroot creation changes

[Tom Hughes]

On 10/10/15 10:59, Rex Dieter wrote:

Dennis Gilmore wrote:


as of this morning US time we have changed the way rawhide buildroots are
created in koji.  rawhide is now using dnf to install the packages into
the buildroot. this means that in f24 and on dnf will be used to create
the buildroot. as well as manage the updates on your system.

We will not be making the same change to f22 or f23 in koji,  yum will
continue to create the buildroot there.  please report to Release
Engineering
[1][2][3] any issue you encounter as a result of this change.


Seems all (most?) rawhide builds are failing now.

https://fedorahosted.org/rel-eng/ticket/6273


That's the only one I've had that failed in that way. I had another 
koschei report but that was in the actual build when running tests and 
passed when run again as a manual scratch build.


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: Proposal to reduce anti-bundling requirements

[Reindl Harald]

Am 10.10.2015 um 11:27 schrieb Haïkel:

Engineering is not science


really?


as previously stated, it's about compromises


well, that can end in something like "the cleverer give in until he 
becomes the dumber itself" in german "Der Klügere gibt solange nach bis 
er selbst der Dümmere ist"




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: rawhide buildroot creation changes

[Rex Dieter]

Tom Hughes wrote:

> On 10/10/15 10:59, Rex Dieter wrote:
>> Dennis Gilmore wrote:
>>
>>> as of this morning US time we have changed the way rawhide buildroots
>>> are
>>> created in koji.  rawhide is now using dnf to install the packages into
>>> the buildroot. this means that in f24 and on dnf will be used to create
>>> the buildroot. as well as manage the updates on your system.
>>>
>>> We will not be making the same change to f22 or f23 in koji,  yum will
>>> continue to create the buildroot there.  please report to Release
>>> Engineering
>>> [1][2][3] any issue you encounter as a result of this change.
>>
>> Seems all (most?) rawhide builds are failing now.
>>
>> https://fedorahosted.org/rel-eng/ticket/6273
> 
> That's the only one I've had that failed in that way. I had another
> koschei report but that was in the actual build when running tests and
> passed when run again as a manual scratch build.

OK, I see *some* f24 buildds succeeding now that I've looked closer... My 
problematic pkg was qt5-qttools, but seems that it's actually working now on 
my 3rd try.

Still, *something* is going funny, we really do want reliably reproducible 
builds.

-- Rex

-- 
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: Proposal to reduce anti-bundling requirements

[Reindl Harald]

Am 10.10.2015 um 12:46 schrieb Haïkel:

2015-10-10 12:17 GMT+02:00 Reindl Harald :


Am 10.10.2015 um 11:27 schrieb Haïkel:


Engineering is not science


really?


as previously stated, it's about compromises


well, that can end in something like "the cleverer give in until he becomes
the dumber itself" in german "Der Klügere gibt solange nach bis er selbst
der Dümmere ist"


Compromising is not the same thing as giving in.


boundaries blurring


If you can't tell the difference, then that explains a lot.


and that from the "you have everytime and to anybody in any context be 
nice and never be personal" preacher explains a lot too!




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 1270504] perl-File-Path-2.12 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1081592
  --> https://bugzilla.redhat.com/attachment.cgi?id=1081592=edit
[patch] Update to 2.12 (#1270504)

-- 
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 1270504] New: perl-File-Path-2.12 is available

[bugzilla]

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

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



Latest upstream release: 2.12
Current version/release in rawhide: 2.11-1.fc24
URL: http://search.cpan.org/dist/File-Path/

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

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

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

-- 
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 1270507] New: perl-Net-SSH2-0.56 is available

[bugzilla]

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

Bug ID: 1270507
   Summary: perl-Net-SSH2-0.56 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Net-SSH2
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, psab...@redhat.com



Latest upstream release: 0.56
Current version/release in rawhide: 0.55-1.fc24
URL: http://search.cpan.org/dist/Net-SSH2/

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

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

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

-- 
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 1270502] perl-experimental-0.016 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
Scratch build completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=11398337

-- 
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 1270504] perl-File-Path-2.12 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
Scratch build failed
http://koji.fedoraproject.org/koji/taskinfo?taskID=11398349

-- 
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: Proposal to reduce anti-bundling requirements

[Haïkel]

2015-10-10 12:17 GMT+02:00 Reindl Harald :
>
>
> Am 10.10.2015 um 11:27 schrieb Haïkel:
>>
>> Engineering is not science
>
>
> really?
>
>> as previously stated, it's about compromises
>
>
> well, that can end in something like "the cleverer give in until he becomes
> the dumber itself" in german "Der Klügere gibt solange nach bis er selbst
> der Dümmere ist"
>
>

Compromising is not the same thing as giving in.
If you can't tell the difference, then that explains a lot.

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

rawhide report: 20151010 changes

[Fedora Rawhide Report]

Compose started at Sat Oct 10 05:15:02 UTC 2015
Broken deps for i386
--
[CableSwig]
CableSwig-3.20.0-13.fc23.i686 requires gccxml
[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
[bro]
bro-2.3.2-6.fc23.i686 requires libjemalloc.so.1
[bwm-ng]
bwm-ng-0.6-18.fc24.i686 requires libstatgrab.so.6
[fence-agents]
fence-agents-common-4.0.20-1.fc24.i686 requires pexpect
[gammaray]
gammaray-qt5-2.3.0-2.fc24.i686 requires qt5-qtbase(x86-32) = 0:5.5.0
[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-prometheus-prometheus]
golang-github-prometheus-prometheus-devel-0.15.0-1.fc24.noarch requires 
golang(gopkg.in/fsnotify.v1)
[grace]
grace-5.1.25-2.fc23.i686 requires libXm.so.2
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[js-of-ocaml]
js-of-ocaml-2.4-8.fc23.i686 requires ocaml(runtime) = 0:4.02.2
js-of-ocaml-2.4-8.fc23.i686 requires ocaml(Lwt_list) = 
0:0ce891783d3177cd33ebd9ed60d4b62d
js-of-ocaml-2.4-8.fc23.i686 requires ocaml(Lwt) = 
0:6f62eda62952a3e464e9c34a825cf0de
[mintmenu]
mintmenu-5.6.4-1.fc24.noarch requires yumex
[moon-buggy]

[Bug 1270501] New: perl-DateTime-Format-RFC3339-v1.2.0 is available

[bugzilla]

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

Bug ID: 1270501
   Summary: perl-DateTime-Format-RFC3339-v1.2.0 is available
   Product: Fedora
   Version: rawhide
 Component: perl-DateTime-Format-RFC3339
  Keywords: FutureFeature, Triaged
  Assignee: dd...@cpan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org



Latest upstream release: v1.2.0
Current version/release in rawhide: 1.0.5-4.fc23
URL: http://search.cpan.org/dist/DateTime-Format-RFC3339/

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

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

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

-- 
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 1270503] perl-ExtUtils-CBuilder-0.280224 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1081588
  --> https://bugzilla.redhat.com/attachment.cgi?id=1081588=edit
[patch] Update to 0.280224 (#1270503)

-- 
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 1270500] New: perl-DateTime-Format-Atom-v1.2.0 is available

[bugzilla]

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

Bug ID: 1270500
   Summary: perl-DateTime-Format-Atom-v1.2.0 is available
   Product: Fedora
   Version: rawhide
 Component: perl-DateTime-Format-Atom
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com



Latest upstream release: v1.2.0
Current version/release in rawhide: 1.0.2-3.fc23
URL: http://search.cpan.org/dist/DateTime-Format-Atom/

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

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

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

-- 
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 1270502] New: perl-experimental-0.016 is available

[bugzilla]

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

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



Latest upstream release: 0.016
Current version/release in rawhide: 0.015-1.fc24
URL: http://search.cpan.org/dist/experimental/

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

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

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

-- 
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 1270500] perl-DateTime-Format-Atom-v1.2.0 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Failed to kick off scratch build.

cmd:  spectool -g /var/tmp/thn-wbns0m/perl-DateTime-Format-Atom.spec
return code:  22
stdout:
Getting
http://www.cpan.org/authors/id/I/IK/IKEGAMI/DateTime-Format-Atom-vv1.2.0.tar.gz
to ./DateTime-Format-Atom-vv1.2.0.tar.gz

stderr:
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found

-- 
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 1270501] perl-DateTime-Format-RFC3339-v1.2.0 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Failed to kick off scratch build.

cmd:  spectool -g /var/tmp/thn-hVftTg/perl-DateTime-Format-RFC3339.spec
return code:  22
stdout:
Getting
http://www.cpan.org/modules/by-module/DateTime/DateTime-Format-RFC3339-vv1.2.0.tar.gz
to ./DateTime-Format-RFC3339-vv1.2.0.tar.gz

stderr:
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found

-- 
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 1270503] New: perl-ExtUtils-CBuilder-0.280224 is available

[bugzilla]

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

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



Latest upstream release: 0.280224
Current version/release in rawhide: 0.280223-3.fc23
URL: http://search.cpan.org/dist/ExtUtils-CBuilder/

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

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

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

-- 
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 1270502] perl-experimental-0.016 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1081587
  --> https://bugzilla.redhat.com/attachment.cgi?id=1081587=edit
[patch] Update to 0.016 (#1270502)

-- 
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 1270508] perl-PPIx-Regexp-0.042 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1081596
  --> https://bugzilla.redhat.com/attachment.cgi?id=1081596=edit
[patch] Update to 0.042 (#1270508)

-- 
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 1270508] New: perl-PPIx-Regexp-0.042 is available

[bugzilla]

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

Bug ID: 1270508
   Summary: perl-PPIx-Regexp-0.042 is available
   Product: Fedora
   Version: rawhide
 Component: perl-PPIx-Regexp
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.042
Current version/release in rawhide: 0.041-1.fc23
URL: http://search.cpan.org/dist/PPIx-Regexp/

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

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

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

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

F-23 Branched report: 20151010 changes

[Fedora Branched Report]

Compose started at Sat Oct 10 07:15:03 UTC 2015
Broken deps for armhfp
--
[389-ds-base]
389-ds-base-1.3.4.4-1.fc23.armv7hl requires librpmio.so.3
389-ds-base-1.3.4.4-1.fc23.armv7hl requires librpm.so.3
[CableSwig]
CableSwig-3.20.0-13.fc23.armv7hl requires gccxml
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[moon-buggy]
moon-buggy-1.0.51-14.fc23.armv7hl requires libesd.so.0
[netbeans-platform]
1:netbeans-platform-harness-7.0.1-11.fc22.armv7hl requires cobertura >= 
0:1.9.3
[nodejs-grunt-contrib-copy]
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) < 0:0.2
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) >= 0:0.1.0
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(chalk) >= 
0:0.5.1
[oat]
oat-appraiser-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api
oat-client-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api
[oozie]
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.pig:pig)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-serde)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-metastore)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-exec)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-common)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-cli)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:webhcat-java-client)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:hcatalog-server-extensions)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:hcatalog-pig-adapter)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:hcatalog-core)
[openstack-swift]
openstack-swift-2.3.0-2.fc23.noarch requires python-pyeclib
[pyjigdo]
pyjigdo-0.4.0.3-9.fc23.noarch requires fuseiso
[python-fiat]
python-fiat-1.5.0-2.fc23.noarch requires ScientificPython
[vdr-live]
vdr-live-0.3.0-21.20150213git6ea279a.fc23.armv7hl requires 
libtntnet.so.12
vdr-live-0.3.0-21.20150213git6ea279a.fc23.armv7hl requires 
libcxxtools.so.9
[vfrnav]
vfrnav-20141211-1.fc22.armv7hl requires libgps.so.21
vfrnav-utils-20141211-1.fc22.armv7hl requires libgdal.so.1



Broken deps for i386
--
[389-ds-base]
389-ds-base-1.3.4.4-1.fc23.i686 requires librpmio.so.3
389-ds-base-1.3.4.4-1.fc23.i686 requires librpm.so.3
[CableSwig]
CableSwig-3.20.0-13.fc23.i686 requires gccxml
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[moon-buggy]
moon-buggy-1.0.51-14.fc23.i686 requires libesd.so.0
[netbeans-platform]
1:netbeans-platform-harness-7.0.1-11.fc22.i686 requires cobertura >= 
0:1.9.3
[nodejs-grunt-contrib-copy]
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) < 0:0.2
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) >= 0:0.1.0
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(chalk) >= 
0:0.5.1
[oat]
oat-appraiser-1.6.0-16.fc22.i686 requires tomcat-servlet-3.0-api
oat-client-1.6.0-16.fc22.i686 requires tomcat-servlet-3.0-api
[openstack-swift]
openstack-swift-2.3.0-2.fc23.noarch requires python-pyeclib
[pure]
pure-0.62-2.fc22.i686 requires libLLVM-3.5.so
[pyjigdo]
pyjigdo-0.4.0.3-9.fc23.noarch requires fuseiso
[python-fiat]
python-fiat-1.5.0-2.fc23.noarch requires ScientificPython
[spark]
spark-0.9.1-0.3.rc3.fc21.i686 requires 

[Bug 1270508] perl-PPIx-Regexp-0.042 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
Scratch build completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=11398406

-- 
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 1270503] perl-ExtUtils-CBuilder-0.280224 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
Scratch build completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=11398339

-- 
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: [EPEL-devel] crlibm and libscs for EPEL 7?

[Rich Rauenzahn]

On 10/9/2015 1:54 AM, Dominik 'Rathann' Mierzejewski wrote:
You could ask to become the maintainer in EPEL: 
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer 


That looks like quite an involved process with an uncertain outcome ...

The process may look involved at first, but it's usually not that much
work after the initial formalities. Why do you think the outcome is
uncertain?


There are a lot of caveats listed in the requirements to be approved as 
a package maintainer after the initial formalities (some of which I 
started!).  Finding a sponsor, contributing in "other ways" than just 
supporting the specific packages that I need.  I don't want to commit to 
things I wouldn't be able to follow through on.



Is that the only viable option at the moment?  Adopt it myself?

I'm afraid that's how it works for most packages. People who use the
software and have the skills to maintain it usually do it.

You can also pay someone to maintain it for you. ;)


Don't have that ability (pay) in the position I'm in at my company, and 
realistically, I can just check the rpm I built into our ansible 
repository.  Or rewrite my software to not use pyinterval.


I've re-built/modified some rpm packages, but don't profess to be 
anywhere near an expert level.  More in the amateur realm, but enough to 
modify an existing rpm to build on newer platforms or to swap out 
versions of source.


I'll give it more consideration and get back to you.

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