Re: systemd 230 change - KillUserProcesses defaults to yes

[Vít Ondruch]

Dne 1.6.2016 v 18:18 Ben Rosser napsal(a):
>
>
> On Wed, Jun 1, 2016 at 10:58 AM, Matthias Clasen  > wrote:
>
> On Wed, 2016-06-01 at 09:59 -0400, Matthew Miller wrote:
>
> >
> > This paints a very specific premise of what a "logout" is, and I'm
> > not
> > sure I agree with it. There are actually many cases where I want to
> > use
> > resources on systems I have accounts on without specifically being
> > logged in — the login session is just a connection in to manage
> > things.
> >
> > Otherwise, we should remove user crontabs, at, and similar.  And
> > there
> > are definitely some systems where that policy has a place, but I
> > don't
> > see it making sense as Fedora default, either system wide or for any
> > of
> > the Editions.
> >
>
> Explicitly marking things to escape the session (nohup, crontab,
> starting system services, etc) is very different from just leaking any
> and all non-terminating processes out of the session.
>
> I am very much in favor of systemd enforcing that the session actually
> ends when I log out, so that I don't accidentally leave processes
> running. Leaking session processes have been a perennial problem that
> we have been battling forever (gconf, ibus, pulseaudio, the list goes
> on...). And they are causing actual problems, from preventing re-login
> to subtly breaking the next session to slowing down shutdown.
>
> That doesn't mean that you can't have user crontabs. As Lennart says,
> using those mechanisms should ideally be a privileged operation
> (with a
> lenient policy on single-user systems).
>
>
> Matthias
> --
>
>
> Why should the policy only be lenient on single-user systems?
>
> Even if I accept for the moment that letting a user keep processes
> running on a system when they log out should be considered
> "privileged", this is a privilege that has more or less always been
> granted to users by default. Why do we suddenly need to change the
> default?

I'd say that the privilege was granted by accident not by design and
this should change now, since systemd introduces infrastructure to fix
this. I consider this reasonable, although it apparently breaks some
forkflows. As long as there is way to change the defaults for
experienced users, I welcome such change. I dare to say that this is
good feature for majority of Fedora users although from the discussion
of experienced users on this list it might seem to break the whole world.


Vít


>
> Sure, providing functionality to *remove* that privilege from a user
> as necessary is a nice feature. But I would strongly be opposed to the
> distribution suddenly changing the status quo here without good reason.
>
> Ben Rosser
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

Schedule for Thursday's FPC Meeting (2016-06-03 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2016-06-03 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. rktime):

2016-06-03 09:00 Fri US/Pacific PDT
2016-06-03 12:00 Fri US/Eastern EDT
2016-06-03 16:00 Fri UTC <-
2016-06-03 17:00 Fri Europe/London  BST
2016-06-03 18:00 Fri Europe/Paris  CEST
2016-06-03 18:00 Fri Europe/Berlin CEST
2016-06-03 21:30 Fri Asia/Calcutta  IST
--new day--
2016-06-04 00:00 Sat Asia/Singapore SGT
2016-06-04 00:00 Sat Asia/Hong_Kong HKT
2016-06-04 01:00 Sat Asia/Tokyo JST
2016-06-04 02:00 Sat Australia/BrisbaneAEST

 Links to all tickets below can be found at: 

https://fedorahosted.org/fpc/report/13

= Followups =

#topic #558 Application/Library distinction and package
splitting
.fpc 558
https://fedorahosted.org/fpc/ticket/558

#topic #566 RPM file triggers
.fpc 566
https://fedorahosted.org/fpc/ticket/566

#topic #610 Packaging guidelines: Check upstream tarball
signatures
.fpc 610
https://fedorahosted.org/fpc/ticket/610

#topic #628 Reserve UID/GID for cassandra
.fpc 628
https://fedorahosted.org/fpc/ticket/628

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://fedorahosted.org/fpc/report/13

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nfs bug - any info on bugzilla 1324635

[Jagga Soorma]

We are running into this issue with CentOS 7.1 and don't have official
support which is why I reached out to the community to see if someone was
aware of the work being done on this private bug.  I can definitely test
out new kernels and provide feedback if that would help and can ask my end
users to duplicate the issue on one of our test nodes.

Thanks.

On Wed, Jun 1, 2016 at 5:41 PM, Ian Kent  wrote:

> On Wed, 2016-06-01 at 17:15 -0700, Jagga Soorma wrote:
> > Hi Guys,
> >
> > Anyone have any information on bugzilla 1324635.  This seems like a
> private
> > bug being tracked by redhat but is major and impacting us.  Basically
> nfs gets
> > impacted with large writes.
>
> It looks to me like there's work being done on it but no-one can reproduce
> the
> problem on demand and no-one is willing to test possible fixes to get
> feedback.
>
> It also looks to me like an extremely difficult problem to resolve so as
> much
> help as possible is needed to get to the bottom of it (if in fact it can be
> resolved in the short(ish) term).
>
> Are you able to help by providing vmcores or testing kernels?
> Have you spoken to RedHat support about it?
>
> Ian
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nfs bug - any info on bugzilla 1324635

[Ian Kent]

On Wed, 2016-06-01 at 17:15 -0700, Jagga Soorma wrote:
> Hi Guys,
> 
> Anyone have any information on bugzilla 1324635.  This seems like a private
> bug being tracked by redhat but is major and impacting us.  Basically nfs gets
> impacted with large writes.

It looks to me like there's work being done on it but no-one can reproduce the
problem on demand and no-one is willing to test possible fixes to get feedback.

It also looks to me like an extremely difficult problem to resolve so as much
help as possible is needed to get to the bottom of it (if in fact it can be
resolved in the short(ish) term).

Are you able to help by providing vmcores or testing kernels?
Have you spoken to RedHat support about it?

Ian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1341875] New: perl-Net-Statsd-Server-0.20 is available

[bugzilla]

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

Bug ID: 1341875
   Summary: perl-Net-Statsd-Server-0.20 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Net-Statsd-Server
  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: 0.20
Current version/release in rawhide: 0.19-3.fc25
URL: http://search.cpan.org/dist/Net-Statsd-Server/

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

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

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

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

-- 
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://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1341875] perl-Net-Statsd-Server-0.20 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
Created attachment 1163843
  --> https://bugzilla.redhat.com/attachment.cgi?id=1163843=edit
Rebase-helper rebase-helper-debug.log log file.
See for details and report the eventual error to rebase-helper
https://github.com/phracek/rebase-helper/issues.

-- 
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://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1341875] perl-Net-Statsd-Server-0.20 is available

[bugzilla]

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



--- Comment #3 from Upstream Release Monitoring 
 ---
Following patches has been unapplied:
['net_statsd_server_makefile.patch']

-- 
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://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1341875] perl-Net-Statsd-Server-0.20 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Patching or scratch build for perl-Net-Statsd-Server-0.19 failed.

-- 
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://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1341375] perl-DBIx-Class-EncodedColumn-0.00015 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-DBIx-Class-EncodedColu |perl-DBIx-Class-EncodedColu
   |mn-0.00014 is available |mn-0.00015 is available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 0.00015
Current version/release in rawhide: 0.00013-5.fc25
URL: http://search.cpan.org/dist/DBIx-Class-EncodedColumn

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

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

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

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

-- 
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://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

nfs bug - any info on bugzilla 1324635

[Jagga Soorma]

Hi Guys,

Anyone have any information on bugzilla 1324635.  This seems like a private
bug being tracked by redhat but is major and impacting us.  Basically nfs
gets impacted with large writes.

Thanks!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1341869] New: perl-Cache-FastMmap-1.44 is available

[bugzilla]

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

Bug ID: 1341869
   Summary: perl-Cache-FastMmap-1.44 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Cache-FastMmap
  Keywords: FutureFeature, Triaged
  Assignee: jpazdzi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jpazdzi...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 1.44
Current version/release in rawhide: 1.43-4.fc25
URL: http://search.cpan.org/dist/Cache-FastMmap/

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

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

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

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

-- 
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://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Bugzilla email address sync

[Jeff Fearn]

On 2/06/2016 09:08, Bruno Wolff III wrote:
> On Thu, Jun 02, 2016 at 09:05:55 +1000,
>  Jeff Fearn  wrote:
>>
>> Hi, we expect to have SAML authentication working in Bugzilla 5, I'm
>> implimenting it for Red Hat customer accounts ATM and also testing with
>> FAS in the hopes we can get it "for free" :)
> 
> What IdPs are you going to support? Is it just going to be a few Redhat
> and Fedora related ones, or a much larger set (e.g. InCommon)?

At this stage we are only looking at RH and Fedora, but the code is
being written generically and allows an arbitrary number of IdPs to be used.

Cheers, Jeff.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bugzilla email address sync

[Bruno Wolff III]

On Thu, Jun 02, 2016 at 09:05:55 +1000,
 Jeff Fearn  wrote:


Hi, we expect to have SAML authentication working in Bugzilla 5, I'm
implimenting it for Red Hat customer accounts ATM and also testing with
FAS in the hopes we can get it "for free" :)


What IdPs are you going to support? Is it just going to be a few Redhat 
and Fedora related ones, or a much larger set (e.g. InCommon)?

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

Re: Bugzilla email address sync

[Kevin Fenzi]

On Thu, 2 Jun 2016 09:05:55 +1000
Jeff Fearn  wrote:

> Hi, we expect to have SAML authentication working in Bugzilla 5, I'm
> implimenting it for Red Hat customer accounts ATM and also testing
> with FAS in the hopes we can get it "for free" :)

Awesome. Great news indeed. :) 

kevin


pgpnhSjY1OU8s.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bugzilla email address sync

[Jeff Fearn]

On 2/06/2016 08:37, Kevin Fenzi wrote:
> On Wed, 01 Jun 2016 22:30:14 +
> Christopher  wrote:
> 
>> Thanks. I opened:
>> https://fedorahosted.org/fedora-infrastructure/ticket/5333 to address
>> the issue more broadly (I figure this would be useful to others, and
>> not just me).
> 
> I don't think there's a more broad solution that will currently
> work. ;) 
> 
> We have requested OpenID bugzilla logins, but that has not yet
> happened. 
> 
> We assume maintainers/qa folks want to use their real address (the one
> they list in fas) in bugzilla. I suppose we could try and fallback to a
> @fedoraproject alias if the real one doesn't exist, but I am not sure
> how hard that would be. 
> 
> Right now we have a list of exceptions to the above assumption (ie,
> people who have told us they do want to use their alias instead of
> their real email address). It happens infrequently enough that
> maintaining those hasn't really been a problem. 

Hi, we expect to have SAML authentication working in Bugzilla 5, I'm
implimenting it for Red Hat customer accounts ATM and also testing with
FAS in the hopes we can get it "for free" :)

Cheers, Jeff.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bugzilla email address sync

[Kevin Fenzi]

On Wed, 01 Jun 2016 22:30:14 +
Christopher  wrote:

> Thanks. I opened:
> https://fedorahosted.org/fedora-infrastructure/ticket/5333 to address
> the issue more broadly (I figure this would be useful to others, and
> not just me).

I don't think there's a more broad solution that will currently
work. ;) 

We have requested OpenID bugzilla logins, but that has not yet
happened. 

We assume maintainers/qa folks want to use their real address (the one
they list in fas) in bugzilla. I suppose we could try and fallback to a
@fedoraproject alias if the real one doesn't exist, but I am not sure
how hard that would be. 

Right now we have a list of exceptions to the above assumption (ie,
people who have told us they do want to use their alias instead of
their real email address). It happens infrequently enough that
maintaining those hasn't really been a problem. 

kevin


pgpx5e_08DyGL.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bugzilla email address sync

[Christopher]

On Wed, Jun 1, 2016 at 5:56 PM Kevin Fenzi  wrote:

> On Wed, 01 Jun 2016 21:51:27 +
> Christopher  wrote:
>
> > I recently updated my FAS account email forwarding address.
> >
> > Then, I got an email with the title "Please fix your
> > bugzilla.redhat.com account"
> >
> > This email was notifying me that my bugzilla.redhat.com account email
> > address did not match my FAS forwarding address.
> >
> > I'd really rather not broadcast my forwarding address on bugzilla
> > more than necessary. I'm subscribed to the mailing lists under my
> > @fedoraproject.org address (recently changed via Postorius).
> >
> > Will setting my bugzilla email address to the @fedoraproject.org make
> > everything happy again, or must the bugzilla address really be the
> > same as my forwarding address?
>
> Normally it must be the same as the address you have in fas.
>
> This is so that our scripts can grant you special groups and such if
> you are a packager or in QA, etc.
>
> However we can add an exception if you want to use your
> fedoraproject.org alias instead there. Just open a fedora
> infrastructure ticket and we can get it sorted out.
>
>
Thanks. I opened: https://fedorahosted.org/fedora-infrastructure/ticket/5333
to address the issue more broadly (I figure this would be useful to others,
and not just me).
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bugzilla email address sync

[Kevin Fenzi]

On Wed, 01 Jun 2016 21:51:27 +
Christopher  wrote:

> I recently updated my FAS account email forwarding address.
> 
> Then, I got an email with the title "Please fix your
> bugzilla.redhat.com account"
> 
> This email was notifying me that my bugzilla.redhat.com account email
> address did not match my FAS forwarding address.
> 
> I'd really rather not broadcast my forwarding address on bugzilla
> more than necessary. I'm subscribed to the mailing lists under my
> @fedoraproject.org address (recently changed via Postorius).
> 
> Will setting my bugzilla email address to the @fedoraproject.org make
> everything happy again, or must the bugzilla address really be the
> same as my forwarding address?

Normally it must be the same as the address you have in fas.

This is so that our scripts can grant you special groups and such if
you are a packager or in QA, etc. 

However we can add an exception if you want to use your
fedoraproject.org alias instead there. Just open a fedora
infrastructure ticket and we can get it sorted out. 

kevin


pgp4Yn2ArSvCN.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Bugzilla email address sync

[Christopher]

I recently updated my FAS account email forwarding address.

Then, I got an email with the title "Please fix your bugzilla.redhat.com
account"

This email was notifying me that my bugzilla.redhat.com account email
address did not match my FAS forwarding address.

I'd really rather not broadcast my forwarding address on bugzilla more than
necessary. I'm subscribed to the mailing lists under my @fedoraproject.org
address (recently changed via Postorius).

Will setting my bugzilla email address to the @fedoraproject.org make
everything happy again, or must the bugzilla address really be the same as
my forwarding address?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Attempting to contact unresponsive maintainers - gabbayo and psss

[Kevin Fenzi]

Greetings, we've been told that the email addresses
for these package maintainers are no longer valid.  I'm starting the
unresponsive maintainer policy to find out if they are still interested
in maintaining their packages (and if so, have them update their email
addresses in FAS).  If they're not interested in maintaining or we
can't locate them I'll have FESCo orphan the packages so that others
can take them over.

If you have a way to contact these maintainers, please let them
know that we'd appreciate knowing what to do with their packages.
Thanks!

gabbayo - former email: ogab...@redhat.com

Point of contact:

rpms/hsakmt -- AMD's HSA thunk library ( master f24 f23 f22 epel7 )

Co-maintainer:

rpms/glew -- The OpenGL Extension Wrangler Library ( master f24 f23
f22 ) 
rpms/pixman -- Pixel manipulation library ( master f24 f23
f22 )

psss - former email: pspli...@redhat.com

Point of contact:

rpms/did -- What did you do last week, month, year? ( master f24
  f23 f22 epel7 el6 ) 
rpms/python-nitrate -- Python API for the Nitrate test case management 
  system ( master f24 f23 f22 epel7 el6) 
rpms/status-report -- Generate status report stats for selected
  date range ( master f24 f23 f22 epel7 el6 )




pgpnspW1webGN.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: jwm

[Przemek Klosowski]

On 06/01/2016 05:34 PM, Bernardo Sulzbach wrote:

On 06/01/2016 06:21 PM, Przemek Klosowski wrote:

So the answer to your question is that the papers say they work 40 hours
per week, but in reality they work more. The employment law doesn't
prescribe the actual number of hours worked by this class of employees,
and the employer can set the work product expectations as they see fit.




So employers who pay extra hours to exempt workers do so without any 
legal obligations? 
I never heard of such situation. Normally, exempt workers might get a 
bonus payout at the end of the year, or receive some award. In some 
industries (e.g. banking, or sales) the bonus might be much bigger than 
the salary, but that's probably not very common in 
engineering/technology fields.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: jwm

[Bernardo Sulzbach]

On 06/01/2016 06:21 PM, Przemek Klosowski wrote:

So the answer to your question is that the papers say they work 40 hours
per week, but in reality they work more. The employment law doesn't
prescribe the actual number of hours worked by this class of employees,
and the employer can set the work product expectations as they see fit.




So employers who pay extra hours to exempt workers do so without any 
legal obligations?

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

Re: jwm

[Przemek Klosowski]

On 05/31/2016 01:31 PM, Bernardo Sulzbach wrote:


I see you write from an @redhat.com address. Are you saying that all 
US-based RedHat developers get 45 hour work weeks or less? I'm talking 
about what the papers say, not the actual amount of work. 
I am not a labor lawyer so this is just my opinion on the legal status, 
but basically US has two categories of workers: exempt and non-exempt. 
The 'exemption' is from the labor rules that require paying overtime 
wages (1.5x the regular rate) for hours above 40hr/week. This is done to 
protect low-wage, mostly blue-collar workers who are 'non-exempt', i.e. 
must be paid overtime. Recently there was a policy change that moved the 
boundary between the categories (from $455/week to $913/week)


Most tech workers are in the 'exempt', or salaried category. I think the 
legal theory is that they are required to turn in a professional work 
product, which is supposed to take 40 hr/week, but if it takes more then 
that's them breaks.


So the answer to your question is that the papers say they work 40 hours 
per week, but in reality they work more. The employment law doesn't 
prescribe the actual number of hours worked by this class of employees, 
and the employer can set the work product expectations as they see fit.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Task Result Namespaces

[Martin Krizek]

Hi,

we have deployed task result namespaces support a while ago and put
our checks (depcheck, upgradepath, rpmlint) into the 'qa' namespace.
With newly added tasks like task-abicheck and task-dockerautotest,
we weren't sure where to put them and so we used the scratch
namespace which is supposed to be used for testing purposes. Now
with those "3rd party" tasks deployed to production, we need to
decide what namespaces should they and other future tasks belong in.

The starting namespaces, and maintainers of tasks belonging to that
namespace, follows:
qa.* - Fedora QA
pkgs..* -  maintainers
fas..* - 
fasgroup..* - fas members belonging to 
scratch.* - anyone

Now, since we maintain task-dockerautotest, it should go into qa.*,
I am not sure though where does task-abicheck belong. I see three
options here:
1. we can create fas group and put it there,
2. create additional dist.* namespace where tasks like abicheck
   and/or rpmgrill would be, or
3. change semantics of qa.* to 'anything Fedora QA maintains or
   important, not package-specific, tasks".

I don't really have strong feelings about either to be honest.

Thoughts? Other proposals?

Thanks,
Martin
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Matthew Miller]

On Wed, Jun 01, 2016 at 03:22:45PM -0500, Justin Brown wrote:
> On the topic of consistency, it makes the most sense to do same as
> /usr/bin/yum currently does for nohup (tmux/screen/etc can become actual
> 

Good call. Yum and dnf take logout inhibitors on the
desktop, which helps in some cases, but not so much with "ssh'd into
server and connection dies".


-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[John Dulaney]

 
> Date: Wed, 1 Jun 2016 15:48:04 +0200
> From: Lennart Poettering 
> Subject: Re: systemd 230 change - KillUserProcesses defaults to yes
> To: Development discussions related to Fedora
>   
> Message-ID: <20160601134804.GB21606@gardel-login>
> Content-Type: text/plain; charset=us-ascii
> 
> On Wed, 01.06.16 12:19, Howard Chu (h...@symas.com) wrote:
> 
> > This is still looking at the problem back-asswards. The problem isn't that
> > screen and tmux are special cases. The problem is that some handful of
> > programs that got spawned in a GUI desktop environment are special cases,
> > not exiting when they should.
> > 
> > Fix the broken programs, don't force every well-behaved program in the
> > universe to change to accommodate your broken GUI environment. This is
> > Programming 101.
> 
> Again, this isn't just work-arounds around broken programs. It's a
> security thing. It's privileged code (logind, PID 1) that enforces a
> clear life-cycle on unprivileged programs.
> 
> Any scheme that relies on unprivileged programs "being nice" doesn't
> fix the inherent security problem: after logout a user should not be
> able consume further runtime resources on the system, regardless if he
> does that because of a bug or on purpose.
> 

Sure, having this as an option to be enabled in specific situations
is nice, but, it ignores how Linux is admined and used in the real
world 90% of the time.  If you're going to enable this by default,
you enable something that may be needed 10% of the time but break
the other 90% of use cases.  A sane default does not break the
majority use.

John.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL conflicts with Satellite 6 packages

[Kevin Fenzi]

On Wed, 1 Jun 2016 12:31:01 -0600
Erinn Looney-Triggs  wrote:

> There are a number of packages in EPEL 6 and 7 that conflict with
> packages provided by either RH Satellite or the katello-agent.
> A quick run through for an up to date (6.1.9) install of satellite on
> RHEL 7:
...snip...

> 
> Possibly others on the client side, I am having a more difficult time
> pulling that list out right now. I was under the impression that for
> good or bad EPEL should not conflict with RHEL packages, I may be
> wrong about this, but I wanted to check.

https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F

So, thats not a channel that EPEL strives to avoid conflicts with. 

We could consider how to better avoid conflicts with that channel, but
I'm not sure there's any easy way there. 

kevin


pgpxXdGM47jUm.pgp
Description: OpenPGP digital signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Chris Murphy]

OK so back to a specific example on Fedora 24 with a restart/shutdown
delay. User gdm owns session-c1.scope, and for some reason I can't
figure out, it won't quit on its own. So it enters a failed state
1m30s after I ask for a restart/shutdown. [1] I edited
/etc/systemd/logind.conf uncommented KillUserProcesses=yes and
rebooted. And at the next reboot, the problem still happens. While the
user session itself is gone, and lsof /home no long shows user chris
processes holding things up, user gdm still is causing the hang.

Since some other user process is the cause of the delay, and
apparently isn't subject to killuserprocesses, at least in this
instance it's not fixing (or papering over) this particular example of
a restart/shutdown delay. I don't know that this is a bug, but I went
ahead and filed it because it seems like killuserprocesses=yes should
apply to user gdm, because that user isn't an excepted user (unless
it's functionally the same as root, in which case the default
#KillExcludeUsers=root is probably why, and now we're just back where
we started where there are wayward processes that are causing restart
hangs and are difficult to identify.



Chris



[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1337307
[2]
https://bugzilla.redhat.com/show_bug.cgi?id=1341837
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Przemek Klosowski]

On 06/01/2016 09:48 AM, Lennart Poettering wrote:

On Wed, 01.06.16 12:19, Howard Chu (h...@symas.com) wrote:


This is still looking at the problem back-asswards. The problem isn't that
screen and tmux are special cases. The problem is that some handful of
programs that got spawned in a GUI desktop environment are special cases,
not exiting when they should.

Fix the broken programs, don't force every well-behaved program in the
universe to change to accommodate your broken GUI environment. This is
Programming 101.

Again, this isn't just work-arounds around broken programs. It's a
security thing. It's privileged code (logind, PID 1) that enforces a
clear life-cycle on unprivileged programs.

Any scheme that relies on unprivileged programs "being nice" doesn't
fix the inherent security problem: after logout a user should not be
able consume further runtime resources on the system, regardless if he
does that because of a bug or on purpose.
As presently designed, it's a usability problem because it collides with 
the often-required idle session timeout. Your desktop session will stay 
up, but any remote connections subject to idle timeout will kill 
long-running jobs on logout. Since in general we can't predict how long 
the command will take (especially the system administration commands), 
we will have to use the convoluted invocation to persist the jobs across 
the unpredictable idle logout, or disable the feature.


It's ironic because as you point out it's a security risk to leave those 
processes running, and yet the sensitive systems are more likely to have 
the idle timeout turned on.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Justin Brown]

I couldn't agree more. Despite Lennart's repeatedly mentioning that this is
substantially -- if not primarily -- a security feature, a lot of people
are disregarding it. I think it's pretty dangerous and counter-productive
in the long-term to have different security settings across the Fedora
products.

SELinux is a great illustration of applying security settings consistently.
Everyone has had problems with SELinux, especially when the target policy
package was less mature. Everyone. Yet, Fedora ships in enforcing mode in
all three products, even though in some people's eyes it's unnecessary for
Workstation. (I don't share this opinion; I like SELinux enforcing
everywhere.) There's another lesson from SELinux as well: Neither RHEL nor
Fedora ship SELinux in Multi-Level Security (MLS) mode, allowing users to
run unconfined_t as a compromise. Nonetheless, we're consistent everywhere
with this setting. While SELinux is still daunting, the consistency of
Fedora's default configuration ameliorates that to some extent.

> Hacky, but it'd work for me if it worked transparently. (Or, make
/usr/bin/tmux et al be shell scripts which do the work.)

On the topic of consistency, it makes the most sense to do same as
/usr/bin/yum currently does for nohup (tmux/screen/etc can become actual
wrappers):

executable="/usr/bin/dnf"
msg="Yum command has been deprecated, redirecting to '$executable $@'.\n"\
"See 'man dnf' and 'man yum2dnf' for more information.\n"\
"To transfer transaction metadata from yum to DNF, run:\n"\
"'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate'\n"

echo -e $msg >&2
exec $executable "$@"



On Wed, Jun 1, 2016 at 2:57 PM, Matthew Miller 
wrote:

> On Wed, Jun 01, 2016 at 02:08:13PM -0400, Solomon Peachy wrote:
> > > Fedora as a distro needs to determine which of these assumptions are
> > > valid *for Fedora* and set the defaults accordingly, as well as
> > > determining if/how to give users the freedom to set them differently.
> > I don't think it's possible to come up with a default that is globally
> > applicable.  Even the current status quo has its problems.
>
> Well, we do end up needing _some_ default, since that's what a default
> is. Theoretically, we could have different defaults for Atomic/Cloud,
> Server, and Workstation depending on needs of the appropriate target
> audiences we've defined — but this is such a big thing that I think
> it's valuable to give some weight to consistency.
>
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2016-05-31)

[Till Maas]

On Wed, Jun 01, 2016 at 02:30:27PM +0100, Sérgio Basto wrote:
> No, I'm implying if we rebuild smb4k in rawhide package will still
> depend on strigi ... (by dep chain ?!? ) . 
> So I think we should retire strigi, fix broken deps of (I guess [1] )
> kdelibs4-devel and after that we can rebuild smb4k in rawhide and fix

AFAICS you do not need to rebuild smb4k once the other packages do not
depend anymore on strigi.

Kind regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Matthew Miller]

On Wed, Jun 01, 2016 at 02:34:01PM -0400, Robert Marcano wrote:
> >I would really like to see a solution whereby tmux and screen _just
> >work_ without any required changes to user behavior. They're basically
> >commands which _indicate_ "I want a new session that persists".
> What about a default shell alias for those commands, Fedora already
> add a few aliases, not sure if there are packaging guidelines for
> that.
> The alias script could check if lingering is enabled and warn the
> user about it.
> The only problem is when people call tmux/screen from an script, I
> don't do it, I start them by hand on a terminal when I want it.
> Probably more people use them as part of a script.

Hacky, but it'd work for me if it worked transparently. (Or, make
/usr/bin/tmux et al be shell scripts which do the work.)

My opinion is that if we can solve tmux, screen, and nohup (and
possibly dtach), we'll hit the majority case, and we can document that
to get this behavior in other cases, either 1) use one of those, 2) use
the systemd-run command, or 3) change the config option.

(Actually, although I am not volunteering, one idea would be for nohup
to move into the systemd fold and be an alias to systemd-run with
special behavior (as telinit is to systemctl).)


-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

pwouters pushed to perl-Net-DNS-SEC (master). "- Require perl(Net::DNS) >= 1.01 as some code moved from here to there"

[notifications]

From 0a264d94cdad6253c41667ab45a9b7cb598a2baf Mon Sep 17 00:00:00 2001
From: Paul Wouters 
Date: Wed, 1 Jun 2016 12:55:08 -0400
Subject: - Require perl(Net::DNS) >= 1.01 as some code moved from here to
 there

---
 perl-Net-DNS-SEC.spec | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/perl-Net-DNS-SEC.spec b/perl-Net-DNS-SEC.spec
index b7af7cc..3db6408 100644
--- a/perl-Net-DNS-SEC.spec
+++ b/perl-Net-DNS-SEC.spec
@@ -1,6 +1,6 @@
 Name:   perl-Net-DNS-SEC
 Version:1.02
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:DNSSEC modules for Perl
 License:MIT
 Group:  Development/Libraries
@@ -43,6 +43,7 @@ BuildRequires:  perl(warnings)
 # Tests only
 BuildRequires:  perl(Test::More)
 BuildRequires:  perl(Time::Local)
+Requires:   perl(Net::DNS) >= 1.01
 Requires:   perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo 
$version))
 Requires:   perl(Crypt::OpenSSL::Random)
 
@@ -77,6 +78,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Wed Jun 01 2016 Paul Wouters  - 1.02-4
+- Require perl(Net::DNS) >= 1.01 as some code moved from here to there
+
 * Sun May 15 2016 Jitka Plesnikova  - 1.02-3
 - Perl 5.24 rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Net-DNS-SEC.git/commit/?h=master=0a264d94cdad6253c41667ab45a9b7cb598a2baf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

pwouters pushed to perl-Net-DNS (master). "- Remove dependancy on perl-Net-DNS-SEC (required code was moved in here)"

[notifications]

From b4f8c8d008c2879a73a1fcc62cc2c93283a5cdf3 Mon Sep 17 00:00:00 2001
From: Paul Wouters 
Date: Wed, 1 Jun 2016 12:52:22 -0400
Subject: - Remove dependancy on perl-Net-DNS-SEC (required code was moved in
 here)

---
 perl-Net-DNS.spec | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/perl-Net-DNS.spec b/perl-Net-DNS.spec
index 6c5b27e..4c703b0 100644
--- a/perl-Net-DNS.spec
+++ b/perl-Net-DNS.spec
@@ -1,6 +1,6 @@
 Name:  perl-Net-DNS
 Version:   1.06
-Release:   2%{?dist}
+Release:   3%{?dist}
 Summary:   DNS resolver modules for Perl
 # lib/Net/DNS/RR/RT.pm: GPL+ or Artistic
 License:   (GPL+ or Artistic) and MIT
@@ -55,10 +55,6 @@ BuildRequires: perl(vars)
 # Win32::TieRegistry is not needed
 # Tests only
 BuildRequires: perl(File::Find)
-%if !%{defined perl_bootstrap}
-# Break build cycle: perl-Net-DNS-SEC → perl-Net-DNS → perl-Net-DNS-SEC
-BuildRequires: perl(Net::DNS::SEC)
-%endif
 BuildRequires: perl(Test::Builder)
 BuildRequires: perl(Test::More)
 # Optional tests:
@@ -71,13 +67,6 @@ Requires:  perl(Digest::SHA) >= 5.23
 Requires:  perl(Encode)
 Requires:  perl(IO::File)
 Requires:  perl(MIME::Base64) >= 2.11
-%if !%{defined perl_bootstrap}
-# Break build cycle: perl-Net-DNS-SEC → perl-Net-DNS → perl-Net-DNS-SEC
-Requires:  perl(Net::DNS::SEC::DSA)
-Requires:  perl(Net::DNS::SEC::ECDSA)
-Requires:  perl(Net::DNS::SEC::Private)
-Requires:  perl(Net::DNS::SEC::RSA)
-%endif
 
 %{?perl_default_filter}
 
@@ -148,6 +137,9 @@ make test
 %{_mandir}/man3/Net::DNS::Nameserver*
 
 %changelog
+* Wed Jun 01 2016 Paul Wouters  - 1.06-3
+- Remove dependancy on perl-Net-DNS-SEC (required code was moved in here)
+
 * Tue May 31 2016 Jitka Plesnikova  - 1.06-2
 - Remove OS_CONF from requires
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Net-DNS.git/commit/?h=master=b4f8c8d008c2879a73a1fcc62cc2c93283a5cdf3
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Matthew Miller]

On Wed, Jun 01, 2016 at 02:08:13PM -0400, Solomon Peachy wrote:
> > Fedora as a distro needs to determine which of these assumptions are
> > valid *for Fedora* and set the defaults accordingly, as well as
> > determining if/how to give users the freedom to set them differently.
> I don't think it's possible to come up with a default that is globally 
> applicable.  Even the current status quo has its problems.

Well, we do end up needing _some_ default, since that's what a default
is. Theoretically, we could have different defaults for Atomic/Cloud,
Server, and Workstation depending on needs of the appropriate target
audiences we've defined — but this is such a big thing that I think
it's valuable to give some weight to consistency.



-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Review swaps

[Jerry James]

I've got a handful of packages awaiting review, and am willing to swap
for reviews with others.  Take your pick:

- gap-pkg-resclasses: https://bugzilla.redhat.com/show_bug.cgi?id=1336005
- gap-pkg-gbnp: https://bugzilla.redhat.com/show_bug.cgi?id=1340513
- gap-pkg-irredsol: https://bugzilla.redhat.com/show_bug.cgi?id=1340551
- python-zope-testrunner: https://bugzilla.redhat.com/show_bug.cgi?id=1341815

Thank you,
-- 
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Intending to un-retire milkytracker and rtmidi for F24 and rawhide

[Till Maas]

On Wed, Jun 01, 2016 at 10:21:34PM +0300, Joonas Sarajärvi wrote:

> I wish to become the point-of-contact for rtmidi and unretire both rtmidi
> and milkytracker.

This should have happened now. Currently it is best to file a ticket on
the releng trac if these kind of unretirements are needed.

Kind regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Package retired by was taken (by me)

[Till Maas]

On Tue, May 31, 2016 at 11:04:18PM +0100, Athmane Madjoudj wrote:

> It seems that s3ql  package  was retired today however I took the
> package on 2016-05-16 and update it week later, see BZ #1249301

If you would like to maintain s3ql and the package it depends on, you
can ask me or releng to get it unretired within two weeks without
needing a re-review.

Kind regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Intending to un-retire milkytracker and rtmidi for F24 and rawhide

[Joonas Sarajärvi]

Hello,

Today I noticed that rtmidi, a dependency of milkytracker, had gotten 
retired and this did also automatically retire milkytracker.


I wish to become the point-of-contact for rtmidi and unretire both 
rtmidi and milkytracker.


At [1] it looks as if a new review is not yet required for these. Should 
I read step four as "edit the original review bug in bugzilla"?


Thanks,
- Joonas

[1] 
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package

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

Re: systemd 230 change - KillUserProcesses defaults to yes

[Robert Marcano]

On 06/01/2016 04:43 AM, Matthew Miller wrote:

On Sun, May 29, 2016 at 06:51:20PM -0600, Chris Murphy wrote:

So there's tmux, screen, curl, wget, and probably quite a few others
that don't necessarily get daemonized that are probably affected.


I would really like to see a solution whereby tmux and screen _just
work_ without any required changes to user behavior. They're basically
commands which _indicate_ "I want a new session that persists".


What about a default shell alias for those commands, Fedora already add 
a few aliases, not sure if there are packaging guidelines for that.


The alias script could check if lingering is enabled and warn the user 
about it.


The only problem is when people call tmux/screen from an script, I don't 
do it, I start them by hand on a terminal when I want it. Probably more 
people use them as part of a script.




It seems fine to have some administrative option which prevents that,
but I think allowing that behavior should be the default. That way,
accidental lingering processes will be cleaned up, but people's
expectations around tmux/screen will still be met.

I liked the suggestion of having those programs become "scope" aware
(https://github.com/tmux/tmux/issues/428) but it looks like upstream
tmux at least is not keen on it. What can we do instead?



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

orion pushed to perl-ExtUtils-F77 (f24). "Perl 5.24 rebuild"

[notifications]

From ef6365b6d957877876bcc6f239c924f72ecb6f4a Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Sat, 14 May 2016 22:50:31 +0200
Subject: Perl 5.24 rebuild

---
 perl-ExtUtils-F77.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-ExtUtils-F77.spec b/perl-ExtUtils-F77.spec
index 3c34ee4..3af3c06 100644
--- a/perl-ExtUtils-F77.spec
+++ b/perl-ExtUtils-F77.spec
@@ -1,6 +1,6 @@
 Name:   perl-ExtUtils-F77
 Version:1.19
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Simple interface to F77 libs
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -47,6 +47,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Sat May 14 2016 Jitka Plesnikova  - 1.19-3
+- Perl 5.24 rebuild
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
1.19-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-ExtUtils-F77.git/commit/?h=f24=ef6365b6d957877876bcc6f239c924f72ecb6f4a
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

orion uploaded ExtUtils-F77-1.20.tar.gz for perl-ExtUtils-F77

[notifications]

df37ee4070908e55d038b2d26d27ef50  ExtUtils-F77-1.20.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-ExtUtils-F77/ExtUtils-F77-1.20.tar.gz/md5/df37ee4070908e55d038b2d26d27ef50/ExtUtils-F77-1.20.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

orion pushed to perl-ExtUtils-F77 (f24). "Update to 1.20 (..more)"

[notifications]

From adf9cc8738431ff328f039b155047b69eef00266 Mon Sep 17 00:00:00 2001
From: Orion Poplawski 
Date: Wed, 1 Jun 2016 09:13:12 -0600
Subject: Update to 1.20

- Specfile cleanup
---
 .gitignore |  1 +
 perl-ExtUtils-F77.spec | 18 --
 sources|  2 +-
 3 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/.gitignore b/.gitignore
index 24197d8..a64cbb0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 ExtUtils-F77-1.16.tar.gz
 /ExtUtils-F77-1.18.tar.gz
 /ExtUtils-F77-1.19.tar.gz
+/ExtUtils-F77-1.20.tar.gz
diff --git a/perl-ExtUtils-F77.spec b/perl-ExtUtils-F77.spec
index 3af3c06..e594226 100644
--- a/perl-ExtUtils-F77.spec
+++ b/perl-ExtUtils-F77.spec
@@ -1,12 +1,10 @@
 Name:   perl-ExtUtils-F77
-Version:1.19
-Release:3%{?dist}
+Version:1.20
+Release:1%{?dist}
 Summary:Simple interface to F77 libs
 License:GPL+ or Artistic
-Group:  Development/Libraries
 URL:http://search.cpan.org/dist/ExtUtils-F77/
 Source0:
http://search.cpan.org/CPAN/authors/id/C/CH/CHM/ExtUtils-F77-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  gcc-gfortran
@@ -26,8 +24,6 @@ OS/compiler combination!
 make %{?_smp_mflags}
 
 %install
-rm -rf $RPM_BUILD_ROOT
-
 make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
@@ -38,15 +34,17 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2>/dev/null \;
 %check
 make test
 
-%clean
-rm -rf $RPM_BUILD_ROOT
-
 %files
-%doc CHANGES COPYING README
+%license COPYING
+%doc CHANGES README
 %{perl_vendorlib}/*
 %{_mandir}/man3/*
 
 %changelog
+* Wed Jun 1 2016 Orion Poplawski  - 1.20-1
+- Update to 1.20
+- Specfile cleanup
+
 * Sat May 14 2016 Jitka Plesnikova  - 1.19-3
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 8392c2b..1a6ffaf 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5f9a0e1dbd6b322ad897a71d7424a32a  ExtUtils-F77-1.19.tar.gz
+df37ee4070908e55d038b2d26d27ef50  ExtUtils-F77-1.20.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-ExtUtils-F77.git/commit/?h=f24=adf9cc8738431ff328f039b155047b69eef00266
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

orion pushed to perl-ExtUtils-F77 (master). "Update to 1.20 (..more)"

[notifications]

From adf9cc8738431ff328f039b155047b69eef00266 Mon Sep 17 00:00:00 2001
From: Orion Poplawski 
Date: Wed, 1 Jun 2016 09:13:12 -0600
Subject: Update to 1.20

- Specfile cleanup
---
 .gitignore |  1 +
 perl-ExtUtils-F77.spec | 18 --
 sources|  2 +-
 3 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/.gitignore b/.gitignore
index 24197d8..a64cbb0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 ExtUtils-F77-1.16.tar.gz
 /ExtUtils-F77-1.18.tar.gz
 /ExtUtils-F77-1.19.tar.gz
+/ExtUtils-F77-1.20.tar.gz
diff --git a/perl-ExtUtils-F77.spec b/perl-ExtUtils-F77.spec
index 3af3c06..e594226 100644
--- a/perl-ExtUtils-F77.spec
+++ b/perl-ExtUtils-F77.spec
@@ -1,12 +1,10 @@
 Name:   perl-ExtUtils-F77
-Version:1.19
-Release:3%{?dist}
+Version:1.20
+Release:1%{?dist}
 Summary:Simple interface to F77 libs
 License:GPL+ or Artistic
-Group:  Development/Libraries
 URL:http://search.cpan.org/dist/ExtUtils-F77/
 Source0:
http://search.cpan.org/CPAN/authors/id/C/CH/CHM/ExtUtils-F77-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  gcc-gfortran
@@ -26,8 +24,6 @@ OS/compiler combination!
 make %{?_smp_mflags}
 
 %install
-rm -rf $RPM_BUILD_ROOT
-
 make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
@@ -38,15 +34,17 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2>/dev/null \;
 %check
 make test
 
-%clean
-rm -rf $RPM_BUILD_ROOT
-
 %files
-%doc CHANGES COPYING README
+%license COPYING
+%doc CHANGES README
 %{perl_vendorlib}/*
 %{_mandir}/man3/*
 
 %changelog
+* Wed Jun 1 2016 Orion Poplawski  - 1.20-1
+- Update to 1.20
+- Specfile cleanup
+
 * Sat May 14 2016 Jitka Plesnikova  - 1.19-3
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 8392c2b..1a6ffaf 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5f9a0e1dbd6b322ad897a71d7424a32a  ExtUtils-F77-1.19.tar.gz
+df37ee4070908e55d038b2d26d27ef50  ExtUtils-F77-1.20.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-ExtUtils-F77.git/commit/?h=master=adf9cc8738431ff328f039b155047b69eef00266
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[EPEL-devel] EPEL conflicts with Satellite 6 packages

[Erinn Looney-Triggs]

There are a number of packages in EPEL 6 and 7 that conflict with
packages provided by either RH Satellite or the katello-agent.
A quick run through for an up to date (6.1.9) install of satellite on
RHEL 7:
bouncycastle.noarch  1.50-1.el7 epel

createrepo_c.x86_64  0.9.0-1.el7epel

createrepo_c-libs.x86_64 0.9.0-1.el7epel

fasterxml-oss-parent.noarch  24-2.el7   epel

hiera.noarch 1:1.3.4-5.el7  epel

jackson-core.noarch  2.6.3-1.el7epel

libqpid-dispatch.x86_64  0.5-2.el7  epel

mod_passenger.x86_64 4.0.53-4.el7   epel

mongodb.x86_64   2.6.11-1.el7   epel

mongodb-server.x86_642.6.11-1.el7   epel

python-BeautifulSoup.noarch  1:3.2.1-7.el7  epel

python-billiard.x86_64   1:3.3.0.20-2.el7   epel

python-bson.x86_64   2.5.2-4.el7epel

python-httplib2.noarch   0.7.7-3.el7epel

python-mongoengine.noarch0.8.8-1.el7epel

python-okaara.noarch 1.0.35-1.el7   epel

python-pymongo.x86_642.5.2-4.el7epel

python-pymongo-gridfs.x86_64 2.5.2-4.el7epel

python-qpid.noarch   0.32-13.el7epel

python-qpid-proton.x86_640.12.1-1.el7   epel

python-qpid-qmf.x86_64   0.32-1.el7 epel

python-simplejson.x86_64 3.3.3-1.el7epel

qpid-cpp-client.x86_64   0.34-6.el7 epel

qpid-cpp-client-devel.x86_64 0.34-6.el7 epel

qpid-cpp-server.x86_64   0.34-6.el7 epel

qpid-cpp-server-linearstore.x86_64   0.34-6.el7 epel

qpid-dispatch-router.x86_64  0.5-2.el7  epel

qpid-proton-c.x86_64 0.12.1-1.el7   epel

qpid-qmf.x86_64  0.32-1.el7 epel

qpid-tools.noarch0.32-9.el7 epel

ruby-shadow.x86_64   1.4.1-23.el7   epel

rubygem-ffi.x86_64   1.9.3-1.el7epel

rubygem-rack.noarch  1:1.6.4-2.el7  epel

rubygem-rack-protection.noarch   1.5.3-3.el7epel

rubygem-rest-client.noarch   1.6.7-4.el7epel

rubygem-rkerberos.x86_64 0.1.3-5.el7epel

v8.x86_641:3.14.5.10-17.el7 epel

Obsoleting Packages
passenger.x86_64 4.0.53-4.el7   epel

rubygem-passenger-native-libs.x86_64 4.0.18-21.el7sat
@rhel-7-server-satellite-6.1-rpms
passenger.x86_64 4.0.53-4.el7   epel

rubygem-passenger-native.x86_64  4.0.18-21.el7sat
@rhel-7-server-satellite-6.1-rpms
passenger.x86_64 4.0.53-4.el7   epel

rubygem-passenger.x86_64 4.0.18-21.el7sat
@rhel-7-server-satellite-6.1-rpms

These packages may/may not clobber satllite, which is a bit of a
delicate flower.

On the client side katello-agent for RHEL 6 (at least) uses the
following packages:
qpid-proton-c
python-qpid-proton

Possibly others on the client side, I am having a more difficult time
pulling that list out right now. I was under the impression that for
good or bad EPEL should not conflict with RHEL packages, I may be wrong
about this, but I wanted to check.

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

Re: Changing -Wp,-D to -D in default cflags

[Jakub Jelinek]

On Wed, Jun 01, 2016 at 11:57:27AM -0600, Orion Poplawski wrote:
> The -D_FORTIFY_SOURCE=2 macro is added with -Wp,-D_FORTIFY_SOURCE=2.  The only
> notes as to why that I can find are:
> 
> commit 1518ff2d14377c05ecf7cf9428e42964516883b4
> Author: Elliot Lee 
> Date:   Wed Feb 9 15:09:11 2005 +
> 
> Fix java builds
> 
> +* Wed Feb 9 2005 Elliot Lee  8.0.33-1
> +- Change -D to -Wp,-D to make java happy
> 
> I've testing building java with just the -D version, and it seems fine:

If it is because of Java, then it surely has been because of gcj, not
openjdk, which didn't exist at that point.
But it could very well be also because of many other languages where
preprocessing isn't performed and -D* makes no sense, -Wp, on the other
side, being a driver option, is something that is accepted for all
languages.

> https://copr.fedorainfracloud.org/coprs/orion/fortify/builds/
> 
> So I'd like to change it back.  The reason is that ccache does not handle -Wp
> options well, and it puts it out of "direct-mode" which triggers an extra run
> of the pre-processor.

Then perhaps fix or nuke ccache?  It is majorly broken anyway, as it
doesn't preprocess with -fdirective-only, therefore breaks lots of
diagnostics etc.

Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Dan Book]

On Wed, Jun 1, 2016 at 2:19 PM, Przemek Klosowski <
przemek.klosow...@nist.gov> wrote:

> On 05/27/2016 12:45 PM, Christopher wrote:
>
>
> It seems to me that what's happening is that systemd is now enforcing this
> "login session" perspective... metaphorically speaking, gluing the
> transparent overlay onto the map (but don't worry! they also provide a
> special adhesive remover!). This makes it that much harder for people to
> make use of what's underneath without viewing it through the overlay...
> which, as it turns out, is a *very* common thing to do (screen, tmux,
> nohup, etc.).
>
> This is a very good observation. The 'login' infrastructure deals with
> authorization to run processes on the computer, which is orthogonal to
> managing characteristics of individual processes, such as whether they are
> transient or persistent. Admitedly, the logout process has to deal with the
> lingering processes: Windows, for instance, throws a dialog box asking to
> terminate the apps. This is somehow a violation of layering which I just
> pointed out above, but I think it is correct in asking for user intent.
>
> In any case, the common use case nowadays is a personal device, where this
> whole issue is somehow moot: there are no multiple users, the user is the
> administrator, and the login session is really from startup to
> shutdown---so the proposed change doesn't change the user-visible behavior
> much, except making the reboot quicker.
>

I think one needs to be careful with even this assumption though. I have
used my server in a hybrid fashion, where I'll log into it both in a
desktop environment and via SSH and use the same tmux window or
backgrounded processes from each. Killing these processes just because I
started them from the desktop instead of via SSH is not an agreeable
default.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Stephen Gallagher]

On 06/01/2016 02:19 PM, Przemek Klosowski wrote:
> On 05/27/2016 12:45 PM, Christopher wrote:
>>
>> It seems to me that what's happening is that systemd is now enforcing this
>> "login session" perspective... metaphorically speaking, gluing the 
>> transparent
>> overlay onto the map (but don't worry! they also provide a special adhesive
>> remover!). This makes it that much harder for people to make use of what's
>> underneath without viewing it through the overlay... which, as it turns out,
>> is a *very* common thing to do (screen, tmux, nohup, etc.).
> This is a very good observation. The 'login' infrastructure deals with
> authorization to run processes on the computer, which is orthogonal to 
> managing
> characteristics of individual processes, such as whether they are  transient 
> or
> persistent. Admitedly, the logout process has to deal with the lingering
> processes: Windows, for instance, throws a dialog box asking to terminate the
> apps. This is somehow a violation of layering which I just pointed out above,
> but I think it is correct in asking for user intent.
> 
> In any case, the common use case nowadays is a personal device, where this 
> whole
> issue is somehow moot: there are no multiple users, the user is the
> administrator, and the login session is really from startup to shutdown---so 
> the
> proposed change doesn't change the user-visible behavior much, except making 
> the
> reboot quicker.
> 
> Actually, how does this proposal deal with network logins? If I SSH to another
> system and run backup in the background, will it kill it when I log out?
>

That's too broad of a question. If the backup is provided by a service running
as a daemon on the system bus or as a system-wide systemd unit and all your
session is doing is telling it to start, it will continue to run.

If you have your user set to "linger", it will continue to run.

If you just have it running in the background, it would have died when you
logged out before this change (depending on shell behavior; some shells reparent
background tasks so it's ambiguous).

If you had it running under a 'screen' session, previously it would have kept
running, now it would exit.

So the "how" makes a big difference.




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Przemek Klosowski]

On 05/27/2016 12:45 PM, Christopher wrote:


It seems to me that what's happening is that systemd is now enforcing 
this "login session" perspective... metaphorically speaking, gluing 
the transparent overlay onto the map (but don't worry! they also 
provide a special adhesive remover!). This makes it that much harder 
for people to make use of what's underneath without viewing it through 
the overlay... which, as it turns out, is a *very* common thing to do 
(screen, tmux, nohup, etc.).
This is a very good observation. The 'login' infrastructure deals with 
authorization to run processes on the computer, which is orthogonal to 
managing characteristics of individual processes, such as whether they 
are  transient or persistent. Admitedly, the logout process has to deal 
with the lingering processes: Windows, for instance, throws a dialog box 
asking to terminate the apps. This is somehow a violation of layering 
which I just pointed out above, but I think it is correct in asking for 
user intent.


In any case, the common use case nowadays is a personal device, where 
this whole issue is somehow moot: there are no multiple users, the user 
is the administrator, and the login session is really from startup to 
shutdown---so the proposed change doesn't change the user-visible 
behavior much, except making the reboot quicker.


Actually, how does this proposal deal with network logins? If I SSH to 
another system and run backup in the background, will it kill it when I 
log out?



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

Re: systemd 230 change - KillUserProcesses defaults to yes

[Solomon Peachy]

On Wed, Jun 01, 2016 at 01:21:06PM -0400, DJ Delorie wrote:
> Fedora as a distro needs to determine which of these assumptions are
> valid *for Fedora* and set the defaults accordingly, as well as
> determining if/how to give users the freedom to set them differently.

I don't think it's possible to come up with a default that is globally 
applicable.  Even the current status quo has its problems.

As an end-user on a multi-user system, I find auto-reaping annoying and 
inconvenient.  I don't want my being disconnected to kill something I 
had running in the background, and I don't want to leave a login window 
open unnecessarily.  Oh, and another pony.

As an end-user on a single-user (GUI) system, I want *everything* to be 
cleaned up when I log out because sometimes my desktop envirionment 
doesn't terminate things cleanly. (Replace "my desktop" with "the guest 
login on my system" if you'd prefer) ...Except when I don't.  Only I 
don't know what I'll need to keep until after it's already running.

Yet as someone who adminsters multi-user systems, I absolutely want 
stuff to be completely cleaned up after the user logs out, in order to 
not waste resources.  If there are long-running jobs then there are 
other mechanisms in place to handle them.

Anyway. I've enabled KillUserProcesses on my personal systems, because 
it solves more headaches than it creates.  

On the other hand, my multi-user systems need screen/nohup/tmux to 
automagically do the right thing before I can turn KillUserProcesses on, 
or I'll have a minor user revolt on my hands..

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.


signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Chris Murphy]

On Wed, Jun 1, 2016 at 3:20 AM, Bastien Nocera  wrote:
>
>
> - Original Message -
>> On Sun, May 29, 2016 at 06:51:20PM -0600, Chris Murphy wrote:
>> > So there's tmux, screen, curl, wget, and probably quite a few others
>> > that don't necessarily get daemonized that are probably affected.
>>
>> I would really like to see a solution whereby tmux and screen _just
>> work_ without any required changes to user behavior. They're basically
>> commands which _indicate_ "I want a new session that persists".
>
> Really? The only times I ever used it was to access serial consoles with
> a better emulation than separate apps.

Really, yes. I use PKA to login to Fedora 23 server where I then run
tmux and then in a session I run weechat. I then disconnect from tmux
and logout, and sometimes it's hours or days before I go log back in
and of course I expect weechat to be there having logged everything
since the last time I looked.

There's no way to make this work on a workstation that gets rebooted
possibly a dozen times a day (the suffering life of testing and dual
boot).


>
>> It seems fine to have some administrative option which prevents that,
>> but I think allowing that behavior should be the default. That way,
>> accidental lingering processes will be cleaned up, but people's
>> expectations around tmux/screen will still be met.
>>
>> I liked the suggestion of having those programs become "scope" aware
>> (https://github.com/tmux/tmux/issues/428) but it looks like upstream
>> tmux at least is not keen on it. What can we do instead?
>
> Patch the applications downstream, or document things with enough details
> and mention it in the release notes.

Really?

I remain unconvinced the 80/20 rule doesn't apply here; where 80% of
the problem this solution is trying to solve relates to DE's not
collapsing its own user session. And the other 20% of the problem is
something an admin could opt in to avoid, apparently for 5 years now,
rather than opt out.



-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Changing -Wp,-D to -D in default cflags

[Orion Poplawski]

The -D_FORTIFY_SOURCE=2 macro is added with -Wp,-D_FORTIFY_SOURCE=2.  The only
notes as to why that I can find are:

commit 1518ff2d14377c05ecf7cf9428e42964516883b4
Author: Elliot Lee 
Date:   Wed Feb 9 15:09:11 2005 +

Fix java builds

+* Wed Feb 9 2005 Elliot Lee  8.0.33-1
+- Change -D to -Wp,-D to make java happy

I've testing building java with just the -D version, and it seems fine:

https://copr.fedorainfracloud.org/coprs/orion/fortify/builds/

So I'd like to change it back.  The reason is that ccache does not handle -Wp
options well, and it puts it out of "direct-mode" which triggers an extra run
of the pre-processor.

Anyone else have any thoughts on the matter, or remember what the issue was?

-- 
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://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1341367] perl-ExtUtils-F77-1.20 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-ExtUtils-F77-1.20-1.fc24 has been submitted as an update to Fedora 24.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-2bd118bda2

-- 
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://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

RE: systemd 230 change - KillUserProcesses defaults to yes

[John Florian]

> -Original Message-
> From: Vít Ondruch [mailto:vondr...@redhat.com]
> Sent: Wednesday, June 01, 2016 06:03
> To: devel@lists.fedoraproject.org
> Subject: Re: systemd 230 change - KillUserProcesses defaults to yes
> 
> 
> How many users logs out if they leave their (single-user) computer? I
> myself lock the computer, so everything keeps running and this problem
> appears to be artificial in this context.
> 
> 
> Vít


Thank you!  While I find this debate interesting and appreciate both sides of 
the argument, I had to wonder the same.  I only log out I because I need to 
reboot.  I only login after that, or when my workstation crashed.  Otherwise, 
it's simply locked.  I wish I could complete what I'm working on in a single 
session, but my workflow is such that I'd be much happier if a single session 
could survive for months (or more but now I'm fantasizing).  I use screen/tmux 
at times, but generally only to multiplex a single TTY when X isn't available 
(e.g., to tail a log in real time while I fiddle in the shell).  Otherwise I'd 
much rather utilize my X window manager.  If the host I'm accessing is not my 
workstation, then it's almost always ssh (in an xterm).

Given all this, it shouldn't be hard to imagine I'd prefer the proposed change 
but I have no qualms in changing the default to suit my purposes -- I've been a 
deviant ever since RHL switched bash from vi mode to emacs mode.  :-)   
(Anybody remember when that occurred? 5.x?)

--
John Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Python package reviewer wanted

[William Moreno]

>
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1328892
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1328951
>
>
I like the atomic host projetc, I will take both reviews


Libre
de virus. www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: gnome-software integration

[Kalev Lember]

On 06/01/2016 06:34 PM, Greg Hellings wrote:
> Would it be better for me to leave only a single appdata.xml file, but
> move it to the xiphos-gtk2 package, then it would be exposed to
> gnome-software users? Then anyone wanting the GTK3 build could install
> through a package manager instead of the app manager?

Sure, sounds like a good plan to me. Just make sure to move the desktop
file as well, it should always be in the same package as the appdata file.

> I'd like to keep it to only one instance of Xiphos appearing in the
> gnome-software interface that will cover the majority of users who are
> just looking for the application. They would get the GTK2 build,
> preferably. Anyone wanting the GTK3 build should be able to get it
> from the command line, directly.

Makes sense to me.

Kalev
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[DJ Delorie]

Lennart Poettering  writes:
> Again, this isn't just work-arounds around broken programs. It's a
> security thing. It's privileged code (logind, PID 1) that enforces a
> clear life-cycle on unprivileged programs.

You're making three invalid assumptions here:

1. You're assuming that such programs are unpriviledged (or undesired)

2. You're assuming that it's PID 1's job to enforce security policy

3. You're assuming that this rule is desired by all users

Fedora as a distro needs to determine which of these assumptions are
valid *for Fedora* and set the defaults accordingly, as well as
determining if/how to give users the freedom to set them differently.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

jplesnik pushed to perl-App-Cme (f24). "1.012 bump"

[notifications]

From 716f942019b6413a25c03324f9fdc79a3a59395a Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Wed, 1 Jun 2016 15:48:49 +0200
Subject: 1.012 bump

---
 .gitignore| 1 +
 perl-App-Cme.spec | 6 +-
 sources   | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 284eb58..009bf62 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 /App-Cme-1.009.tar.gz
 /App-Cme-1.010.tar.gz
 /App-Cme-1.011.tar.gz
+/App-Cme-1.012.tar.gz
diff --git a/perl-App-Cme.spec b/perl-App-Cme.spec
index f79eca2..8abfb1d 100644
--- a/perl-App-Cme.spec
+++ b/perl-App-Cme.spec
@@ -1,5 +1,5 @@
 Name:   perl-App-Cme
-Version:1.011
+Version:1.012
 Release:1%{?dist}
 Summary:Check or edit configuration data with Config::Model
 License:LGPLv2+
@@ -46,6 +46,7 @@ Requires:   perl(Config::Model::FuseUI)
 Requires:   perl(Config::Model::SimpleUI)
 Requires:   perl(Config::Model::TermUI)
 Requires:   perl(Config::Model::TkUI)
+Requires:   perl(Term::ReadLine)
 Requires:   perl(Tk)
 Requires:   perl(Tk::ErrorDialog)
 
@@ -84,6 +85,9 @@ install -D -m 0644 contrib/bash_completion.cme 
%{buildroot}%{_sysconfdir}/bash_c
 %{_sysconfdir}/bash_completion.d
 
 %changelog
+* Wed Jun 01 2016 Jitka Plesnikova  - 1.012-1
+- 1.012 bump
+
 * Fri Apr 22 2016 Jitka Plesnikova  - 1.011-1
 - 1.011 bump
 
diff --git a/sources b/sources
index ee973d9..59a0ff7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ddb4f9bac8b517c531d35f1531fcd573  App-Cme-1.011.tar.gz
+41d121fc366739fca02117815629c1e0  App-Cme-1.012.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-App-Cme.git/commit/?h=f24=716f942019b6413a25c03324f9fdc79a3a59395a
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'approveacls' permission on perl-Archive-Extract (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-Archive-Extract (el6) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Archive-Extract/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchbugzilla' permission on perl-JSON-Any (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on perl-JSON-Any (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-JSON-Any/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[389-devel] Re: Please review/comment: [389 Project] #48833: 389 showing inconsistent values for shadowMax and shadowWarning in 1.3.5.1

[Noriko Hosoi]

Thanks for your comments, William.

On 05/31/2016 07:22 PM, William Brown wrote:

On Tue, 2016-05-31 at 17:48 -0700, Noriko Hosoi wrote:

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

There are 2 proposals.  I'd like to have your thoughts which one would
be preferable.

https://fedorahosted.org/389/attachment/ticket/48833/0001-Ticket-48833-389-showing-inconsistent-values-for-sha.2.patch
git patch file (master) -- second proposal -- this patch allows the
password policy values and shadow account values in sync.
If we choose this option, DS Console Password Policy panel needs to be
modified to support the larger value than INT_MAX.

https://fedorahosted.org/389/attachment/ticket/48833/0001-Ticket-48833-389-showing-inconsistent-values-for-sha.patch
git patch file (master) -- first proposal -- shadow account values won't
be touched if they already exist in an entry.
Restrictions:
1. If objectclass: shadowaccount is set and there is no shadow account
values in an entry, the shadowmax, min, and warning are filled by
calculating them from the password policy values.  The maximum value of
calculated shadowMax is 24855 (== 2^31-1 / (24 * 60 * 60)).
2. Even if the values of the password policy are updated, shadow account
values are not effected.


I'm for option 1. I believe our shadow and password policy should be in sync. 
This prevents admins making mistakes, and allows
clients to gain functionality.

There is no reasonable benefit IMO to having shadow and ldap policy out of sync.
I'm worried there could be administrators who want to have a full 
control on the shadow values with no interest on the DS password 
policy...  I guess the reporter of this ticket is one of them.


Thanks,
--noriko

It also means that a seamless upgrade occurs, where existing sites, with 
existing (bad) shadow data, well begin to get the
benefit of a now *working* shadow value.


Thanks,



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



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

ppisar changed owner of perl-Const-Fast (el6) to 'ppisar'

[notifications]

ppisar changed owner of perl-Const-Fast (el6) to 'ppisar'
https://admin.fedoraproject.org/pkgdb/package/perl-Const-Fast/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'commit' permission on perl-MooseX-Params-Validate (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-MooseX-Params-Validate 
(el6) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-MooseX-Params-Validate/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'approveacls' permission on perl-JSON-Any (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-JSON-Any (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-JSON-Any/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed owner of perl-JSON-Any (el6) to 'ppisar'

[notifications]

ppisar changed owner of perl-JSON-Any (el6) to 'ppisar'
https://admin.fedoraproject.org/pkgdb/package/perl-JSON-Any/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'approveacls' permission on perl-MooseX-Params-Validate (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-MooseX-Params-Validate 
(el6) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-MooseX-Params-Validate/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed owner of perl-MooseX-Params-Validate (el6) to 'ppisar'

[notifications]

ppisar changed owner of perl-MooseX-Params-Validate (el6) to 'ppisar'

https://admin.fedoraproject.org/pkgdb/package/perl-MooseX-Params-Validate/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchbugzilla' permission on perl-MooseX-Params-Validate (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on 
perl-MooseX-Params-Validate (el6) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-MooseX-Params-Validate/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchcommits' permission on perl-Const-Fast (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on perl-Const-Fast (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Const-Fast/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'commit' permission on perl-JSON-Any (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-JSON-Any (el6) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-JSON-Any/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'commit' permission on perl-FCGI (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-FCGI (el6) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-FCGI/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchbugzilla' permission on perl-FCGI (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on perl-FCGI (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-FCGI/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchbugzilla' permission on perl-Const-Fast (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on perl-Const-Fast (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Const-Fast/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchcommits' permission on perl-JSON-Any (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on perl-JSON-Any (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-JSON-Any/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'approveacls' permission on perl-FCGI (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-FCGI (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-FCGI/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchcommits' permission on perl-MooseX-Params-Validate (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on 
perl-MooseX-Params-Validate (el6) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-MooseX-Params-Validate/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'commit' permission on perl-Const-Fast (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-Const-Fast (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Const-Fast/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed owner of perl-FCGI (el6) to 'ppisar'

[notifications]

ppisar changed owner of perl-FCGI (el6) to 'ppisar'
https://admin.fedoraproject.org/pkgdb/package/perl-FCGI/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchcommits' permission on perl-FCGI (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on perl-FCGI (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-FCGI/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

jplesnik pushed to perl-App-Cme (master). "1.012 bump"

[notifications]

From b0d7462858b28807c845f1a579b18e874cc10298 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Wed, 1 Jun 2016 15:41:12 +0200
Subject: 1.012 bump

---
 .gitignore| 1 +
 perl-App-Cme.spec | 8 ++--
 sources   | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 284eb58..009bf62 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 /App-Cme-1.009.tar.gz
 /App-Cme-1.010.tar.gz
 /App-Cme-1.011.tar.gz
+/App-Cme-1.012.tar.gz
diff --git a/perl-App-Cme.spec b/perl-App-Cme.spec
index 80bf9e5..0b6389a 100644
--- a/perl-App-Cme.spec
+++ b/perl-App-Cme.spec
@@ -1,6 +1,6 @@
 Name:   perl-App-Cme
-Version:1.011
-Release:2%{?dist}
+Version:1.012
+Release:1%{?dist}
 Summary:Check or edit configuration data with Config::Model
 License:LGPLv2+
 URL:http://search.cpan.org/dist/App-Cme/
@@ -46,6 +46,7 @@ Requires:   perl(Config::Model::FuseUI)
 Requires:   perl(Config::Model::SimpleUI)
 Requires:   perl(Config::Model::TermUI)
 Requires:   perl(Config::Model::TkUI)
+Requires:   perl(Term::ReadLine)
 Requires:   perl(Tk)
 Requires:   perl(Tk::ErrorDialog)
 
@@ -84,6 +85,9 @@ install -D -m 0644 contrib/bash_completion.cme 
%{buildroot}%{_sysconfdir}/bash_c
 %{_sysconfdir}/bash_completion.d
 
 %changelog
+* Wed Jun 01 2016 Jitka Plesnikova  - 1.012-1
+- 1.012 bump
+
 * Tue May 17 2016 Jitka Plesnikova  - 1.011-2
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index ee973d9..59a0ff7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ddb4f9bac8b517c531d35f1531fcd573  App-Cme-1.011.tar.gz
+41d121fc366739fca02117815629c1e0  App-Cme-1.012.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-App-Cme.git/commit/?h=master=b0d7462858b28807c845f1a579b18e874cc10298
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'approveacls' permission on perl-Const-Fast (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-Const-Fast (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Const-Fast/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

jplesnik uploaded App-Cme-1.012.tar.gz for perl-App-Cme

[notifications]

41d121fc366739fca02117815629c1e0  App-Cme-1.012.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-App-Cme/App-Cme-1.012.tar.gz/md5/41d121fc366739fca02117815629c1e0/App-Cme-1.012.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1315525] perl-Net-DNS-1.06 is available

[bugzilla]

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



--- Comment #12 from Upstream Release Monitoring 
 ---
pwouters's perl-Net-DNS-1.06-3.fc25 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=769837

-- 
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://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchbugzilla' permission on perl-Archive-Extract (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on perl-Archive-Extract 
(el5) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Archive-Extract/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'approveacls' permission on perl-Archive-Extract (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-Archive-Extract (el5) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Archive-Extract/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'commit' permission on perl-Archive-Extract (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-Archive-Extract (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Archive-Extract/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed owner of perl-Archive-Extract (el5) to 'ppisar'

[notifications]

ppisar changed owner of perl-Archive-Extract (el5) to 'ppisar'
https://admin.fedoraproject.org/pkgdb/package/perl-Archive-Extract/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchcommits' permission on perl-Archive-Extract (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on perl-Archive-Extract (el5) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Archive-Extract/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchbugzilla' permission on perl-Archive-Extract (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on perl-Archive-Extract 
(el6) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Archive-Extract/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchcommits' permission on perl-Archive-Extract (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on perl-Archive-Extract (el6) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Archive-Extract/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'commit' permission on perl-Archive-Extract (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-Archive-Extract (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Archive-Extract/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed owner of perl-Archive-Extract (el6) to 'ppisar'

[notifications]

ppisar changed owner of perl-Archive-Extract (el6) to 'ppisar'
https://admin.fedoraproject.org/pkgdb/package/perl-Archive-Extract/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchcommits' permission on perl-Catalyst-Runtime (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on perl-Catalyst-Runtime 
(el6) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Catalyst-Runtime/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchbugzilla' permission on perl-Catalyst-Runtime (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on perl-Catalyst-Runtime 
(el6) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Catalyst-Runtime/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed owner of perl-Catalyst-Runtime (el6) to 'ppisar'

[notifications]

ppisar changed owner of perl-Catalyst-Runtime (el6) to 'ppisar'
https://admin.fedoraproject.org/pkgdb/package/perl-Catalyst-Runtime/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'approveacls' permission on perl-Catalyst-Runtime (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-Catalyst-Runtime (el6) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Catalyst-Runtime/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed ppisar's 'commit' permission on perl-Catalyst-Runtime (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-Catalyst-Runtime (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Catalyst-Runtime/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: gnome-software integration

[Greg Hellings]

On Wed, Jun 1, 2016 at 12:19 PM,   wrote:
> Date: Wed, 1 Jun 2016 17:38:15 +0200
> From: Kalev Lember 
> Subject: Re: gnome-software integration
> To: Development discussions related to Fedora
> 
> Message-ID: 
> Content-Type: text/plain; charset=utf-8
>
> On 06/01/2016 05:24 PM, Greg Hellings wrote:
>> I'm looking into a bug filed against one of my applications (BZ:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1330096). The complaint is
>> that the gnome-software application picks up the xiphos-common package
>> when the user tries to install from there, rather than picking up the
>> actual GUI packages (which are available as xiphos-gtk2 and
>> xiphos-gtk3).
>>
>> I need some advice on the proper way to handle this. First, a little
>> explanation of the three packages.
>>
>> Upstream Xiphos includes some support for building against GTK3 but
>> has no intention of moving to that for its primary support on its
>> current roadmap. Thus, there are occasionally bugs against the GTK3
>> build that are left as low-priority tasks - sometimes these will
>> render the GTK3 build completely unusable. Thus, upstream recommends
>> building only against GTK2.
>>
>> To satisfy both camps, and to allow ease of bug reporting (i.e.
>> identifying if the bug is a regression in GTK3 interfaces vs a bug in
>> Xiphos) and for various other reasons, both xiphos-gtk{2,3} were made
>> available. There are a small number of static or data files which can
>> be shared between the two builds - translations, etc. These are
>> packaged as xiphos-common, which is a dep of both the binary packages.
>>
>> One of those files that is shared between the two is the
>> %{_datadir}/appdata/xiphos.appdata.xml, which appears to be what
>> triggers gnome-software to consider a particular package the GUI
>> app-containing package that ought to be installed.
>
> Don't share that, it's meant to be unique per app, and you have two
> separate apps here.

I really only have one app - Xiphos. It's just been compiled under two
different toolkits. They are supposed to be feature-identical and
complete, which they both are to my knowledge. It's just that one of
them (GTK2) gets routine updates and fixes whereas the other (GTK3)
does not receive the same level of concentration from upstream.

I really only want the GTK2 to be exposed to casual users - which is
what I suspect is the majority of users of the gnome-software
interface. Anyone installing the xiphos-gtk3 should be someone who
knows and wants that specific version.

>
> Instead, create two .appdata files, one for each .desktop file, and put
> both the .desktop and .appdata files in the respective xiphos-gtk2 and
> xiphos-gtk3 subpackages. Something like:
>
> xiphos-gtk2.rpm:
> /usr/bin/xiphos-gtk2
> /usr/share/appdata/xiphos-gtk2.appdata.xml
> /usr/share/applications/xiphos-gtk2.desktop
>
> xiphos-gtk3.rpm:
> /usr/bin/xiphos-gtk3
> /usr/share/appdata/xiphos-gtk3.appdata.xml
> /usr/share/applications/xiphos-gtk3.desktop

Would it be better for me to leave only a single appdata.xml file, but
move it to the xiphos-gtk2 package, then it would be exposed to
gnome-software users? Then anyone wanting the GTK3 build could install
through a package manager instead of the app manager?

>
> --
> Hope this helps,
> Kalev
>
> --
>
> Date: Wed, 01 Jun 2016 11:43:46 -0400
> From: Matthias Clasen 
> Subject: Re: gnome-software integration
> To: Development discussions related to Fedora
> 
> Message-ID: <1464795826.29236.0.ca...@redhat.com>
> Content-Type: text/plain; charset="UTF-8"
>
>
>> xiphos-gtk2.rpm:
>> /usr/bin/xiphos-gtk2
>> /usr/share/appdata/xiphos-gtk2.appdata.xml
>> /usr/share/applications/xiphos-gtk2.desktop
>>
>> xiphos-gtk3.rpm:
>> /usr/bin/xiphos-gtk3
>> /usr/share/appdata/xiphos-gtk3.appdata.xml
>> /usr/share/applications/xiphos-gtk3.desktop
>
> I have to ask though: is it really worth shipping 2 copies of the
> application ? I would suggest to just ship one of them.

There are users who have specifically requested the GTK3 version be
made available, since they try to keep the GTK2 stack off their
systems for a variety of reasons. Since upstream provides both, though
with differing levels of support, upstream and users both ended up
asking for different builds to be available. Upstream is primarily
interested in GTK2 and simply defaults to telling users to install
that version when a bug is first found in the GTK3 version. Some
users, though, only wanted the GTK3 version.

I'd like to keep it to only one instance of Xiphos appearing in the
gnome-software interface that will cover the majority of users who are
just looking for the application. They would get the GTK2 build,
preferably. Anyone wanting the GTK3 build should be able to get it
from the command 

Python package reviewer wanted

[Matthew Barnes]

I have two package review requests that have been stuck in limbo for a 
month and could use some help with.


Both are fairly simple Python packages, part of Project Atomic[1] -- one 
a server, the other its CLI counterpart.


If anyone has some cycles to spare on this I'd be grateful.

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

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

Matthew Barnes


[1] http://www.projectatomic.io/blog/2016/05/introducing_commissaire/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

jplesnik pushed to perl-Check-ISA (master). "0.05 bump"

[notifications]

From f46c2f414e9fed7058a512b5af02d9e28193494f Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Wed, 1 Jun 2016 15:16:44 +0200
Subject: 0.05 bump

---
 .gitignore  |  1 +
 perl-Check-ISA.spec | 21 +
 sources |  2 +-
 3 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/.gitignore b/.gitignore
index 0f00371..e504f82 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 Check-ISA-0.04.tar.gz
+/Check-ISA-0.05.tar.gz
diff --git a/perl-Check-ISA.spec b/perl-Check-ISA.spec
index bd285b6..8389b9b 100644
--- a/perl-Check-ISA.spec
+++ b/perl-Check-ISA.spec
@@ -1,26 +1,28 @@
-Name:   perl-Check-ISA 
-Version:0.04 
-Release:22%{?dist}
+Name:   perl-Check-ISA
+Version:0.05
+Release:1%{?dist}
 # see lib/Check/ISA.pm
 License:GPL+ or Artistic
-Summary:DWIM, correct checking of an object's class 
-Source: 
http://search.cpan.org/CPAN/authors/id/N/NU/NUFFIN/Check-ISA-%{version}.tar.gz 
+Summary:DWIM, correct checking of an object's class
+Source: 
http://search.cpan.org/CPAN/authors/id/M/MA/MANWAR/Check-ISA-%{version}.tar.gz
 Url:http://search.cpan.org/dist/Check-ISA
 BuildArch:  noarch
 
 BuildRequires: make
 BuildRequires: perl
-BuildRequires: perl(ExtUtils::MakeMaker) >= 6.76 
+BuildRequires: perl-generators
+BuildRequires: perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
 # Run-time
 BuildRequires: perl(constant)
 BuildRequires: perl(IO::Handle)
 BuildRequires: perl(Scalar::Util)
 BuildRequires: perl(Sub::Exporter)
-BuildRequires: perl(warnings)
 BuildRequires: perl(warnings::register)
 # Tests
 BuildRequires: perl(base)
+BuildRequires: perl(ok)
 BuildRequires: perl(Test::More)
 BuildRequires: perl(Test::use::ok)
 # Optional tests
@@ -50,11 +52,14 @@ make pure_install DESTDIR=%{buildroot}
 make test
 
 %files
-%doc Changes 
+%doc Changes
 %{perl_vendorlib}/*
 %{_mandir}/man3/*.3*
 
 %changelog
+* Wed Jun 01 2016 Jitka Plesnikova  - 0.05-1
+- 0.05 bump
+
 * Mon May 16 2016 Jitka Plesnikova  - 0.04-22
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 44bce80..c257f56 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7d118aadd4069b4287f309482776a2bd  Check-ISA-0.04.tar.gz
+f3f48c831397970c9246af66c1e9bf81  Check-ISA-0.05.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Check-ISA.git/commit/?h=master=f46c2f414e9fed7058a512b5af02d9e28193494f
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org