date:20160602

On Thu, Jun 2, 2016 at 5:33 PM gil  wrote:

>
>
> Il 02/06/2016 23:20, Chris Murphy ha scritto:
> > On Thu, Jun 2, 2016 at 3:03 PM, Christopher 
> wrote:
> >> So, it would seem at some point, without me noticing (certainly my
> fault,
> >> for not paying attention enough), the Hadoop packages got orphaned
> and/or
> >> retired? in Fedora.
> >>
> >> This is a big problem for me, because the main package I work on is
> >> dependent upon Hadoop.
> >>
> >> What's the state of Hadoop in Fedora these days? Are there packaging
> >> problems? Not enough support from upstream Apache community? Missing
> >> dependencies in Fedora? Not enough time to work on it? No interest from
> >> users?
> >
> > Looks like packages it depended on were orphaned, almost a year ago (?)
> >
> >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BTYJNZV5LKLJYS2QZDSVX3CRECNLERTV/
> >
> no,  cause of nc6 motivation: "2016-05-31: Retired orphaned package,
> because it was orphaned
> more than six weeks."
> .g
>
>
Ugh. Wish I had noticed. Is there a quick way to get it unretired? It's
still an essential dependency of some packages which are not retired, or
even orphaned.
--
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

2016-06-02 Thread Zbigniew Jędrzejewski-Szmek

On Tue, May 31, 2016 at 04:07:28PM -0400, Eric Griffith wrote:
> On May 31, 2016 15:44, "Adam Williamson"  wrote:
> >
> > On Tue, 2016-05-31 at 15:26 -0400, Eric Griffith wrote:
> > > What if the Anaconda team changed it so the "Make this user an
> > > administrator" checkbox also enabled linger?
> >
> > anaconda team is (rightly) opposed to anything like this, in terms of
> > magic code in anaconda that changes things. All that box does is put
> > the user in the wheel group (and maybe tell PolicyKit they're an admin,
> > I forget if that's a separate thing or not). It does not and will not
> > do anything else. Anything else has to be achieved in terms of saying
> > 'wheel members / PK admins can do X'.
> 
> Fair enough, reasonable position. Would this avenue be reasonable /
> acceptable / possible, then? Can logind read and respond to policykit? Such
> as "members of wheel can linger"? I'm not familiar enough with the
> internals of either logind or policykit to know how interconnected they can
> be.

logind already uses polkit. Current polkit policy installed by systemd
in fact is already more permissive than what you propose: it allows
*any* user to enable lingering for themselves. So enabling it for
wheel-members/other-admin-users wouldn't make much sense. But if the
current policy was ever changed (either upstream or locally), using
this kind of policy would make a lot of sense.

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

2016-06-02 Thread Zbigniew Jędrzejewski-Szmek

On Tue, May 31, 2016 at 03:04:52PM -0600, Orion Poplawski wrote:
> On 05/29/2016 05:14 PM, Chris Murphy wrote:
> > On Fri, May 27, 2016 at 5:03 PM, Paul Wouters  wrote:
> > 
> >> If there is a systematic
> >> problem of badly written code leaving orphaned code running when
> >> a user logs out, then that broken code should be fixed instead of
> >> adding another layer of process management. systemd is not capable
> >> of interpreting the user's intent.
> > 
> > That isn't working. Users are constantly running into restart and
> > shutdown delays. Troubleshooting this to find out what process is
> > holding things up is totally non-obvious. Identifying the process is
> > half the problem, and then getting it fixed and released to Fedora can
> > be months, by which time some other process is affected.
> 
> But the delays in system shutdown/restart were introduced by systemd in the
> first place.  I would argue that these delays are much too long.

Set DefaultTimeoutStartSec= in /etc/systemd/systemd.conf.

The default default has to be fairly high because of the wide range
of hardware that people are using (e.g. a 10 year old uni-processor
machine swapping to a slow rotational disk).

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

[Bug 1342314] New: perl-System-Command-1.118 is available

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

Bug ID: 1342314
   Summary: perl-System-Command-1.118 is available
   Product: Fedora
   Version: rawhide
 Component: perl-System-Command
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 1.118
Current version/release in rawhide: 1.117-3.fc25
URL: http://search.cpan.org/dist/System-Command/

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

-- 
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 1342310] New: perl-Moose-2.1804 is available

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

Bug ID: 1342310
   Summary: perl-Moose-2.1804 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Moose
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
mmasl...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org



Latest upstream release: 2.1804
Current version/release in rawhide: 2.1803-1.fc25
URL: http://search.cpan.org/dist/Moose/

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

-- 
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 1342306] perl-Config-IniFiles-2.90 is available

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



--- Comment #3 from Upstream Release Monitoring 
 ---
Patches were not touched. All were applied properly

-- 
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 1342306] perl-Config-IniFiles-2.90 is available

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



--- Comment #2 from Upstream Release Monitoring 
 ---
Created attachment 1164287
  --> https://bugzilla.redhat.com/attachment.cgi?id=1164287=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 1342306] New: perl-Config-IniFiles-2.90 is available

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

Bug ID: 1342306
   Summary: perl-Config-IniFiles-2.90 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Config-IniFiles
  Keywords: FutureFeature, Triaged
  Assignee: tcall...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
tcall...@redhat.com



Latest upstream release: 2.90
Current version/release in rawhide: 2.89-2.fc25
URL: http://search.cpan.org/dist/Config-IniFiles/

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

-- 
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 1342306] perl-Config-IniFiles-2.90 is available

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Patching or scratch build for perl-Config-IniFiles-2.89 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

Re: systemd 230 change - KillUserProcesses defaults to yes

On Thu, 2016-06-02 at 18:01 -0400, Sam Varshavchik wrote:
> Gerd Hoffmann writes:
> 
> > On Do, 2016-06-02 at 10:07 -0400, Matthias Clasen wrote:
> > > 
> > > You are misinformed. This is not about 'obviously broken' windowing
> > > apps. Applications that have X or wayland connections get killed
> > > reliably when the session ends, because that connection is going away.
> > 
> > No.
> > 
> > It's sort-of default behavior, a bit simliar to how terminal apps get
> > zapped by SIGHUP when the terminal closes.  But it isn't enforced at
> > all, apps can keep running when the X or wayland connection goes away,
> > either just a short moment (firefox saving open tabs to disk, then exit)
> > or even longer in case they are running some kind of batch job which
> > they can finish without user interaction.  Or they keep on trying to
> > read from the closed connection due to some stupid bug ...
> 
> ssh into a box, and start emacs. Close emacs. Logout from the shell. The  
> shell logs out, but the ssh sesssion remains. The terminal session doesn't  
> end because gconfd-2 is still running in the background.
> 
> Why does some kind of a configuration framework API need a freaking daemon  
> to run in the background? And why is that bloody thing still running after I  
> logout, and especially since neither the client, nor the server, runs the  
> Gnome desktop?
> 
> Back when emacs converted to GTK, the switch to GTK made sense. Both emacs  
> and Gnome, after all, were GNU projects. But now, years later, with Gnome  
> jumping the shark it all winds up breaking unrelated stuff, like tmux and  
> screen, that has nothing to do with Gnome.

gconf has been deprecated for like...five years?...now, so I'd say
yelling and screaming about GNOME is kind of missing the point here.
The more salient question being, why hasn't emacs-gtk or whatever moved
off gconf yet?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
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

2016-06-02 Thread Sam Varshavchik

Gerd Hoffmann writes:

On Do, 2016-06-02 at 10:07 -0400, Matthias Clasen wrote:
>
> You are misinformed. This is not about 'obviously broken' windowing
> apps. Applications that have X or wayland connections get killed
> reliably when the session ends, because that connection is going away.

No.

It's sort-of default behavior, a bit simliar to how terminal apps get
zapped by SIGHUP when the terminal closes.  But it isn't enforced at
all, apps can keep running when the X or wayland connection goes away,
either just a short moment (firefox saving open tabs to disk, then exit)
or even longer in case they are running some kind of batch job which
they can finish without user interaction.  Or they keep on trying to
read from the closed connection due to some stupid bug ...

ssh into a box, and start emacs. Close emacs. Logout from the shell. The  
shell logs out, but the ssh sesssion remains. The terminal session doesn't  
end because gconfd-2 is still running in the background.

Why does some kind of a configuration framework API need a freaking daemon  
to run in the background? And why is that bloody thing still running after I  
logout, and especially since neither the client, nor the server, runs the  
Gnome desktop?

Back when emacs converted to GTK, the switch to GTK made sense. Both emacs  
and Gnome, after all, were GNU projects. But now, years later, with Gnome  
jumping the shark it all winds up breaking unrelated stuff, like tmux and  
screen, that has nothing to do with Gnome.

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

Schedule for Friday's FESCo Meeting (2016-06-03)

2016-06-02 Thread Kalev Lember

Following is the list of topics that will be discussed in the FESCo
meeting Friday at 16:00UTC in #fedora-meeting on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2016-06-03 16:00 UTC'


Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1573 Docker Layered Image maintainer guildelines, naming
guidelines and review
.fesco 1573
https://fedorahosted.org/fesco/ticket/1573

#topic #1576 Evaluate Workstation graphical upgrade Change status
.fesco 1576
https://fedorahosted.org/fesco/ticket/1576

#topic #1578 F25 System Wide Change: Use /etc/repos.d as default reposdir
.fesco 1578
https://fedorahosted.org/fesco/ticket/1578

= New business =

#topic #1580 Systemd changes - Request - KillUserProcess behavior change
.fesco 1580
https://fedorahosted.org/fesco/ticket/1580

#topic #1581 Unresponsive maintainer: asaf
.fesco 1581
https://fedorahosted.org/fesco/ticket/1581

#topic #1582 Reassign nodejs packages owned by 'patches' to
group::nodejs-sig
.fesco 1582
https://fedorahosted.org/fesco/ticket/1582

= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

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/fesco,
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: systemd 230 change - KillUserProcesses defaults to yes

2016-06-02 Thread Sam Varshavchik


Lennart Poettering writes:


Well. Let's say you are responsible for the Linux desktops of a large
security-senstive company (let's say bank, whatever), and the desktops
are installed as fixed workstations, which different employees using
them at different times. They log in, they do some "important company
stuff", and then they log out again. Now, it's a large company, so it
doesn't have the closest control on every single employee, and
sometimes employees leave the company. Sometimes even the employees
browse to the wrong web sites, catch a browser exploit and suddenly
start runing spam bots under their user identity, without even
knowing.

In all of these cases you really want to make sure that whatever the
user did ends – really ends – by the time he logs out. So that the


Nice theory. But there's a problem with this proposal.

If an unprivileged program, like tmux, or screen, or nohup, can do whatever  
dbus/ibus thingy it needs to do in order to elevate itself to a new  
"session", and make arrangements to prevent itself from getting nuked from  
high orbit by KillUserProcesses, then the same thing can obviously be done  
by any other process. Like the same rogue spambot that's being discussed  
here. The rogue spambout in question can simply talk to systemd itself, and  
arrange for it not to be killed when the user logs out. Just like any other  
process. There goes the added "security" we were hoping to achieve, here.


This KillUserProcesses feature offers no real "security" benefit here  
whatsoever. I am confident that any professional, who's actually making some  
bread in information security, will reach this conclusion without taking  
much time; just a brief, cursory analysis. The claim that KillUserProcesses  
implements any kind of system security is quite funny. And this doesn't  
exactly give me a warm and fuzzy feeling – who knows what other things that  
are also thought to be enforcing system security are lurking inside the  
systemd monolith…


Anyway, in order for this to be truly effective security, it should not be  
possible for any ordinary process, like tmux, screen, or nohup, without them  
being privileged binaries in some way (either via s[gu]id, capabilities(7),  
or selinux)[*].


Well, good luck with that.

[*] Not 100% true, actually. There are ways to come up with fairly bullet- 
proof framework for privileged processes on Linux, without relying on system- 
level support like suid/capabilities/selinux, but this is veering more off- 
topic than this already is.




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

Re: Hadoop?

On Thu, Jun 2, 2016 at 5:21 PM Chris Murphy  wrote:

> On Thu, Jun 2, 2016 at 3:03 PM, Christopher 
> wrote:
> > So, it would seem at some point, without me noticing (certainly my fault,
> > for not paying attention enough), the Hadoop packages got orphaned and/or
> > retired? in Fedora.
> >
> > This is a big problem for me, because the main package I work on is
> > dependent upon Hadoop.
> >
> > What's the state of Hadoop in Fedora these days? Are there packaging
> > problems? Not enough support from upstream Apache community? Missing
> > dependencies in Fedora? Not enough time to work on it? No interest from
> > users?
>
>
> Looks like packages it depended on were orphaned, almost a year ago (?)
>
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BTYJNZV5LKLJYS2QZDSVX3CRECNLERTV/
>
>
Forgive me, but I have a really hard time parsing those massive reports
(especially when they appear in an active list like this).

But, it looks like that was due to  erlang-jsx being orphaned, which
affected libthrift-java, which affected accumulo and a bunch of others. It
looks like erlang-jsx was picked back up, and in any case, I'm pretty sure
it was an optional dependency of libthrift-java, so it could have been
fixed by the thrift developer (by dropping erlang support) even if
erlang-jsx was dropped.

So, I don't think that report a year ago caused the situation we're in
today.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Hadoop?

2016-06-02 Thread gil




Il 02/06/2016 23:20, Chris Murphy ha scritto:

On Thu, Jun 2, 2016 at 3:03 PM, Christopher  wrote:

So, it would seem at some point, without me noticing (certainly my fault,
for not paying attention enough), the Hadoop packages got orphaned and/or
retired? in Fedora.

This is a big problem for me, because the main package I work on is
dependent upon Hadoop.

What's the state of Hadoop in Fedora these days? Are there packaging
problems? Not enough support from upstream Apache community? Missing
dependencies in Fedora? Not enough time to work on it? No interest from
users?


Looks like packages it depended on were orphaned, almost a year ago (?)

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BTYJNZV5LKLJYS2QZDSVX3CRECNLERTV/

no,  cause of nc6 motivation: "2016-05-31: Retired orphaned package, 
because it was orphaned

more than six weeks."
.g
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Hadoop?

2016-06-02 Thread Chris Murphy

On Thu, Jun 2, 2016 at 3:03 PM, Christopher  wrote:
> So, it would seem at some point, without me noticing (certainly my fault,
> for not paying attention enough), the Hadoop packages got orphaned and/or
> retired? in Fedora.
>
> This is a big problem for me, because the main package I work on is
> dependent upon Hadoop.
>
> What's the state of Hadoop in Fedora these days? Are there packaging
> problems? Not enough support from upstream Apache community? Missing
> dependencies in Fedora? Not enough time to work on it? No interest from
> users?


Looks like packages it depended on were orphaned, almost a year ago (?)

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BTYJNZV5LKLJYS2QZDSVX3CRECNLERTV/


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

Hadoop?

So, it would seem at some point, without me noticing (certainly my fault,
for not paying attention enough), the Hadoop packages got orphaned and/or
retired? in Fedora.

This is a big problem for me, because the main package I work on is
dependent upon Hadoop.

What's the state of Hadoop in Fedora these days? Are there packaging
problems? Not enough support from upstream Apache community? Missing
dependencies in Fedora? Not enough time to work on it? No interest from
users?

Whatever the issue is... I'd like to help wherever I can... I'd like to
keep this stuff going.
--
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

Thanks.. I forgot an important part.

5. People comment about the broken cycle and then various people
nitpick that comment in some fashion that doesn't improve anything but
'proves' that they are 'correcter' than the commenter. Overall
everyone involved feels worse off.

On 2 June 2016 at 16:31, Howard Chu  wrote:
> Stephen John Smoogen wrote:
>>
>> 1. There is a problem for a certain group that systemd people care
>> about (usually desktop but not always).
>> 2. Systemd puts in a fix for that problem.
>
>
> In this timeline, your step (2) is crucially missing a piece. Systemd has
> put in a *change* but it has been shown *not* to address the actual problem.
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RYKLRYGPNGA6USK4RMDV6FDXTHYIJXZ7/
>
> It's also quite obviously *not* an actual fix, it is a bandaid at best and
> the real problems remain in other code.
>
> Whether or not there's any actual security benefit to the change is a pure
> non-sequitur. The fact remains that the original problem that prompted the
> change hasn't been fixed, while numerous legitimate use cases spanning 30+
> years of practice get broken. This is *not* good software engineering, by
> any measure.
>
>> 3. Someone who isn't using the system that way gets affected and
>> asks/complains/bitches about the fix (depending on the person).
>> 4. Communication goes down hill with the following items you can
>> checkmark regularly:
>>   A. Someone 'representing' systemd says its right and it is dragging
>> the neanderthals into the light of 21st century computing.
>>   B. Someone 'representing' grognards says its right and it doesn't
>> want know-it-all eggheads pissing on it all the time.
>>   C. Someone 'explains' how this fixes a security problem.
>>   D. Someone 'explains' how it causes a security problem.
>>   E. Both sides tear apart each others arguments.
>>   F. Both sides yells, screams, throws insults, emails 'anonymous'
>> death threats to people in the other side.
>>   G. Both sides say they are going to take their toys and go home.
>>   H. Eventually FESCO has to play adult and tell the groups to work
>> together or no one gets to play.
>>
>> I am guessing we are hitting E and will be going to F soon. G will
>> come sometime after F24 is released (usually 2-3 weeks after release).
>> H. will happen after the deadline for features in F25 occurs.
>>
>> [PS I do not condone or think that any of the steps are good or should
>> be done. It just seems to be the standard bingo for this software.
>> Someone might also be able to put dnf or GNOME into similar
>> categories. ]
>>
>>
>
>
> --
>   -- Howard Chu
>   CTO, Symas Corp.   http://www.symas.com
>   Director, Highland Sun http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



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

Re: Fedora retirement guidelines

2016-06-02 Thread James Hogarth

On 2 June 2016 at 21:39, Neal Gompa  wrote:

> On Thu, Jun 2, 2016 at 3:21 PM, James Hogarth 
> wrote:
> > Right now the retirement guidelines state that you should only retire in
> > branched (prior to freeze) and up to master...
> >
> > But I just had a user bitten by a change in behaviour between dnf and yum
> > that was discovered here:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1096506
> >
> > This is the bug raised with my package:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1342249
> >
> > It seems very unintuitive to the user, and wasn't initially apparent to
> me
> > until I look at all open dnf bugs and did a "find on page" for "obsolete"
> >
> > For now I've opened a rel-eng ticket to get the letsencrypt packages
> > properly removed from the F23 repos so that a dnf install letsencrypt,
> like
> > F24 behaviour, will install certbot.
> >
> > I guess the real question is - is the dnf behaviour correct, and if the
> dnf
> > behaviour isn't going to change should we allow packagers to retire from
> a
> > released branch?
>
> The DNF behavior is not correct, as something that has a Provides line
> should be considered equivalent, even if it also has an Obsoletes
> line. Since this is *not* how DNF behaves currently, it should be
> corrected ASAP.
>
>
>
>
It was pointed out to me on #fedora-admin that I was incorrect in thinking
my package could be pulled from the F23 repos - they remain stable and
untouched.

At least now I'm aware of the issue and can direct anyone who does a dnf
install letsencrypt that they need to do dnf install certbot on F23 ... but
it will remain broken behaviour on F23 until F23 retires or dnf gets an
update for sane behaviour.

So there's no need to review retirement process of guidelines - but that
dnf bug is a pretty irritating and unintuitive one.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora retirement guidelines

2016-06-02 Thread Neal Gompa

On Thu, Jun 2, 2016 at 3:21 PM, James Hogarth  wrote:
> Right now the retirement guidelines state that you should only retire in
> branched (prior to freeze) and up to master...
>
> But I just had a user bitten by a change in behaviour between dnf and yum
> that was discovered here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1096506
>
> This is the bug raised with my package:
> https://bugzilla.redhat.com/show_bug.cgi?id=1342249
>
> It seems very unintuitive to the user, and wasn't initially apparent to me
> until I look at all open dnf bugs and did a "find on page" for "obsolete"
>
> For now I've opened a rel-eng ticket to get the letsencrypt packages
> properly removed from the F23 repos so that a dnf install letsencrypt, like
> F24 behaviour, will install certbot.
>
> I guess the real question is - is the dnf behaviour correct, and if the dnf
> behaviour isn't going to change should we allow packagers to retire from a
> released branch?

The DNF behavior is not correct, as something that has a Provides line
should be considered equivalent, even if it also has an Obsoletes
line. Since this is *not* how DNF behaves currently, it should be
corrected ASAP.


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
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

2016-06-02 Thread Howard Chu

Stephen John Smoogen wrote:

1. There is a problem for a certain group that systemd people care
about (usually desktop but not always).
2. Systemd puts in a fix for that problem.

In this timeline, your step (2) is crucially missing a piece. Systemd has put
in a *change* but it has been shown *not* to address the actual problem.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RYKLRYGPNGA6USK4RMDV6FDXTHYIJXZ7/

It's also quite obviously *not* an actual fix, it is a bandaid at best and the
real problems remain in other code.

Whether or not there's any actual security benefit to the change is a pure
non-sequitur. The fact remains that the original problem that prompted the
change hasn't been fixed, while numerous legitimate use cases spanning 30+
years of practice get broken. This is *not* good software engineering, by any
measure.

3. Someone who isn't using the system that way gets affected and
asks/complains/bitches about the fix (depending on the person).
4. Communication goes down hill with the following items you can
checkmark regularly:
A. Someone 'representing' systemd says its right and it is dragging
the neanderthals into the light of 21st century computing.
B. Someone 'representing' grognards says its right and it doesn't
want know-it-all eggheads pissing on it all the time.
C. Someone 'explains' how this fixes a security problem.
D. Someone 'explains' how it causes a security problem.
E. Both sides tear apart each others arguments.
F. Both sides yells, screams, throws insults, emails 'anonymous'
death threats to people in the other side.
G. Both sides say they are going to take their toys and go home.
H. Eventually FESCO has to play adult and tell the groups to work
together or no one gets to play.

I am guessing we are hitting E and will be going to F soon. G will
come sometime after F24 is released (usually 2-3 weeks after release).
H. will happen after the deadline for features in F25 occurs.

[PS I do not condone or think that any of the steps are good or should
be done. It just seems to be the standard bingo for this software.
Someone might also be able to put dnf or GNOME into similar
categories. ]

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bugzilla email address sync

On Thu, Jun 2, 2016 at 3:44 AM Pierre-Yves Chibon 
wrote:

> On Wed, Jun 01, 2016 at 04:37:26PM -0600, 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. ;)
>
> In the future FAS3 will have a distinct bugzilla_email field allowing
> anyone to
> use an email for their bugzilla account and a different one for their @fp.o
> alias.
>
>
>
That sounds neat. What's the timeline for FAS3?
--
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

2016-06-02 Thread Przemek Klosowski


On 06/02/2016 02:19 PM, Paul Wouters wrote:

On Jun 1, 2016, at 09:48, Lennart Poettering wrote:

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.

You are redefining the meaning of (a graphical) logout. It simply means another 
user can use the mouse, keyboard and screen of this device. It makes no 
statement on whether the machines resources are shared or not.

It allows you to kill anything that has to do with the user controlling the screen, 
keyboard and mouse but the killing should be limited to those processes. And then we are 
back at "just fix those broken processes".
Actually, we have the capacity for dual login (switching users), where 
the first session is still active, and the new user runs his display 
session on a different console which grabs the mouse, keyboard and 
screen devices. The proposed change, as I understand it now, allows the 
processes from the first session to continue running.
--
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

On 2 June 2016 at 15:17, Justin Brown  wrote:
> On Thu, Jun 2, 2016 at 1:26 PM, Ivan Chavero  wrote:
>> Well, if i'm writing a malware i'll make sure it uses systemd-run so it
> keeps on running.
>
> The point of the feature is not to prevent users from running anything in
> the background. It's that *anything* the user runs has proper systemd
> confinement, so it's obvious and manageable by the administrator. Without
> this feature, the only reliable way to achieve the same thing is to reboot
> every system.
>
>> This default is nonsense the only thing that it really does is break stuff
>> that relies on processes being executed after the user closes his session.
>> Yes, there's an obscure systemd-run command that only the systemd devs know
>> and can make your programs run forever but what's wrong with "&" or just
>> running "screen" to create a persistent session??
>
> Maybe it's obscure to you, but it's foolish to suggest that it will forever
> be so. What's wrong with your shell understanding that "&" needs more
> sophisticated handling than fork/exec* these days? There's no reason why
> shells can't handle this for you, or you can setup your shell to handle it
> for you. There's already been discussion about creating wrapper scripts in
> Fedora for screen and tmux that automatically handle execution via
> system-run, so I'm unsure what the issue is.
>

Mostly because that is a naive view of the amount of work that will
need to be done. It has to be more than a wrapper script, it will take
a bunch of patches to many applications for it to work. Those projects
need to be aware of this change or some patch needs to be held in
every OS when the upstream says 'screw this'

This isn't a sentence that these things can't happen. Supposedly
various ports to MacOS-X (and possibly other OS's) have carried
various patches to work with init systems that do something similar.
So it is possible. However the want to do any of that was short cut
from the beginning because of the standard cycle of systemd
squabbling.

1. There is a problem for a certain group that systemd people care
about (usually desktop but not always).
2. Systemd puts in a fix for that problem.
3. Someone who isn't using the system that way gets affected and
asks/complains/bitches about the fix (depending on the person).
4. Communication goes down hill with the following items you can
checkmark regularly:
 A. Someone 'representing' systemd says its right and it is dragging
the neanderthals into the light of 21st century computing.
 B. Someone 'representing' grognards says its right and it doesn't
want know-it-all eggheads pissing on it all the time.
 C. Someone 'explains' how this fixes a security problem.
 D. Someone 'explains' how it causes a security problem.
 E. Both sides tear apart each others arguments.
 F. Both sides yells, screams, throws insults, emails 'anonymous'
death threats to people in the other side.
 G. Both sides say they are going to take their toys and go home.
 H. Eventually FESCO has to play adult and tell the groups to work
together or no one gets to play.

I am guessing we are hitting E and will be going to F soon. G will
come sometime after F24 is released (usually 2-3 weeks after release).
H. will happen after the deadline for features in F25 occurs.

[PS I do not condone or think that any of the steps are good or should
be done. It just seems to be the standard bingo for this software.
Someone might also be able to put dnf or GNOME into similar
categories. ]

-- 
Stephen J Smoogen.
--
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

2016-06-02 Thread Ivan Chavero

- Original Message -
> From: "Justin Brown" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, June 2, 2016 1:17:22 PM
> Subject: Re: systemd 230 change - KillUserProcesses defaults to yes
> 
> On Thu, Jun 2, 2016 at 1:26 PM, Ivan Chavero < ichav...@redhat.com > wrote:
> > Well, if i'm writing a malware i'll make sure it uses systemd-run so it
> keeps on running.
> 
> The point of the feature is not to prevent users from running anything in the
> background. It's that *anything* the user runs has proper systemd
> confinement, so it's obvious and manageable by the administrator. Without
> this feature, the only reliable way to achieve the same thing is to reboot
> every system.

Why does user activity need to have systemd confinment? 

A well crafted script can kill user processes if desired. This is 
pretty basic Unix system administration stuff.

> 
> > This default is nonsense the only thing that it really does is break stuff
> > that relies on processes being executed after the user closes his session.
> > Yes, there's an obscure systemd-run command that only the systemd devs
> > know and can make your programs run forever but what's wrong with "&" or
> > just running "screen" to create a persistent session??
> 
> Maybe it's obscure to you, but it's foolish to suggest that it will forever
> be so. 

Actually it's not obscure to me i can read manuals (BTW typical ad-hominem 
argument), 
and i follow systemd development because it's an important part of Linux 
systems.
If the change of every Unix manual and textbook is required to remove this from
obscurity, i'm pretty sure it will remain like that for a while...

> What's wrong with your shell understanding that "&" needs more
> sophisticated handling than fork/exec* these days? There's no reason why
> shells can't handle this for you, or you can setup your shell to handle it
> for you. There's already been discussion about creating wrapper scripts in
> Fedora for screen and tmux that autmatically handle execution via
> system-run, so I'm unsure what the issue is.

Really??
I'm a little speachless here, you're suggesting that shell developers should 
change the
behaviour of their software because of this default!!

¿What's the issue? There are a lot of users that expect their processes to 
behave 
in a certain way and this introduces a big change in this behaviour, this will 
break
a lot of stuff.

BTW i'm not a systemd hater, i think it does pretty cool stuff but sometimes 
developers take decisions that have bigger repercussions than the use case they
are trying to solve.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora retirement guidelines

2016-06-02 Thread James Hogarth

Right now the retirement guidelines state that you should only retire in
branched (prior to freeze) and up to master...

But I just had a user bitten by a change in behaviour between dnf and yum
that was discovered here:
https://bugzilla.redhat.com/show_bug.cgi?id=1096506

This is the bug raised with my package:
https://bugzilla.redhat.com/show_bug.cgi?id=1342249

It seems very unintuitive to the user, and wasn't initially apparent to me
until I look at all open dnf bugs and did a "find on page" for "obsolete"

For now I've opened a rel-eng ticket to get the letsencrypt packages
properly removed from the F23 repos so that a dnf install letsencrypt, like
F24 behaviour, will install certbot.

I guess the real question is - is the dnf behaviour correct, and if the dnf
behaviour isn't going to change should we allow packagers to retire from a
released branch?
--
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

2016-06-02 Thread Justin Brown

On Thu, Jun 2, 2016 at 1:26 PM, Ivan Chavero  wrote:
> Well, if i'm writing a malware i'll make sure it uses systemd-run so it
keeps on running.

The point of the feature is not to prevent users from running anything in
the background. It's that *anything* the user runs has proper systemd
confinement, so it's obvious and manageable by the administrator. Without
this feature, the only reliable way to achieve the same thing is to reboot
every system.

> This default is nonsense the only thing that it really does is break
stuff that relies on processes being executed after the user closes his
session. Yes, there's an obscure systemd-run command that only the systemd
devs know and can make your programs run forever but what's wrong with "&"
or just running "screen" to create a persistent session??

Maybe it's obscure to you, but it's foolish to suggest that it will forever
be so. What's wrong with your shell understanding that "&" needs more
sophisticated handling than fork/exec* these days? There's no reason why
shells can't handle this for you, or you can setup your shell to handle it
for you. There's already been discussion about creating wrapper scripts in
Fedora for screen and tmux that automatically handle execution via
system-run, so I'm unsure what the issue is.
--
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

2016-06-02 Thread Matthias Clasen

On Thu, 2016-06-02 at 14:19 -0400, Paul Wouters wrote:
> > 
> > On Jun 1, 2016, at 09:48, Lennart Poettering wrote:
> > 
> > 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.
> 
> You are redefining the meaning of (a graphical) logout. It simply
> means another user can use the mouse,
> keyboard and screen of this device. It makes no statement on whether
> the machines resources are shared or not.   
> 
> It allows you to kill anything that has to do with the user
> controlling the screen, keyboard and mouse but the killing should be
> limited to those processes. And then we are back at "just fix those
> broken processes".

I think the discussion is starting to go in circles. It is pretty clear
that we have different opinions about the desired behavior of logout.

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

2016-06-02 Thread Ivan Chavero


> On Thursday, June 02, 2016 13:04:44 Lennart Poettering wrote:
> > On Wed, 01.06.16 07:20, Adam Williamson (adamw...@fedoraproject.org) wrote:
> > > On Wed, 2016-06-01 at 15:48 +0200, Lennart Poettering wrote:
> > > > 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.
> > > 
> > > I don't think you've yet explained exactly why this constitutes a
> > > 'security problem'. Could you please do so?
> > 
> > Well. Let's say you are responsible for the Linux desktops of a large
> > security-senstive company (let's say bank, whatever), and the desktops
> > are installed as fixed workstations, which different employees using
> > them at different times. They log in, they do some "important company
> > stuff", and then they log out again. Now, it's a large company, so it
> > doesn't have the closest control on every single employee, and
> > sometimes employees leave the company. Sometimes even the employees
> > browse to the wrong web sites, catch a browser exploit and suddenly
> > start runing spam bots under their user identity, without even
> > knowing.

Well, if i'm writing a malware i'll make sure it uses systemd-run so it 
keeps on running.

> > 
> > In all of these cases you really want to make sure that whatever the
> > user did ends – really ends – by the time he logs out. So that the
> > employee can't do stuff there except when logged in, and that he can't
> > do stuff there even long after he left the company, and that the spam
> > bot he caught gets killed as soon as he logs out.
> 
> Then what prevents the user from keeping a session forever?

Nothing, because this is not the proper solution to the security problem.

> 
> > This is really just one example. This model I think really needs to be
> > the default everywhere. On desktops and on servers: unless the admin
> > permitted it explicitly, there should not be user code running. If you
> > allow your intern user access to a webserver to quickly check our the
> > resource consumption of some service that doesn't mean that he shall
> > be allowed to run stuff there forever, just because he once had the
> > login privilege for the server. And even more: after you disabled his
> > user account and logged him out, he really should be gone.
> 
> What exactly do you mean by "logged him out"?
> 
> You must be a privileged user to do that.  If you are a privileged user,
> killing his/her processes is just one more command on top of that...
> 
> Kamil
> 
> > Yes, UNIX is pretty much a swiss cheese: it's really hard to secure a
> > system properly so that somebody who once had access won't have access
> > anymore at a later point. However, we need to start somewhere, and
> > actually defining a clear lifecycle is a good start.
> > 
> > Pretty much all more modern OS designs tend to have such a clear
> > lifecycle btw: when the user is logged out, he's *really* logged
> > out. And it's completely OK if certain users get excludeded from that,
> > but if so, then the admin needs to sign off on that, and thus a
> > privilege check needs to be enforced.
> > 


This default is nonsense the only thing that it really does is break stuff that
relies on processes being executed after the user closes his session. Yes, 
there's
an obscure systemd-run command that only the systemd devs know and can make your
programs run forever but what's wrong with "&" or just running "screen" to 
create
a persistent session?? 
I know you're gonna start with the "there's been 40 years since Unix was 
designed" 
argument, Unix was designed with simplicity in mind, this default is not simple
it adds another layer of complexity that is not really needed, breaks stuff and
makes ALL THE WORLD change the way they work.

Going back to the bank example, the change of KillUserProcesses should be 
decided
by the security team or the system administrator instead of magically be there.

And no, the argument of "you should learn systemd" does not apply here, this 
changes the way Linux behaves and it's not obvious to the user and believe me
nobody outside of the people that have their eyes on systemd reads this 
document: https://github.com/systemd/systemd/blob/master/NEWS#L29

The change of KillUserProcesses to "yes" should be done in a use case basis not 
the
upstream dev team, this changes the way Linux behaves in a very aggressive way
and can lead to a lot of bug reports, break scripts and could make people stop
using Linux with systemd because you should not break the "least surprise" 
principle.

It's easier to remove just one commit [1] than to make EVERYBODY change the way 
they work...



Cheers,
Ivan

[1] 
https://github.com/systemd/systemd/pull/3005/commits/97e5530cf2076a2b4fc55755917262607aaa6338
--
devel mailing list
devel@lists.fedoraproject.org

jplesnik pushed to perl-XML-XPath (master). "1.37 bump"

From 3c2deaeb90898e751a1efa51ce923737c5155ff7 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 2 Jun 2016 16:48:43 +0200
Subject: 1.37 bump

---
 .gitignore  | 1 +
 perl-XML-XPath.spec | 7 +--
 sources | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index c0dc1f5..2d8f719 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,4 @@ XML-XPath-1.13.tar.gz
 /XML-XPath-1.34.tar.gz
 /XML-XPath-1.35.tar.gz
 /XML-XPath-1.36.tar.gz
+/XML-XPath-1.37.tar.gz
diff --git a/perl-XML-XPath.spec b/perl-XML-XPath.spec
index 1a3e728..6efa672 100644
--- a/perl-XML-XPath.spec
+++ b/perl-XML-XPath.spec
@@ -1,6 +1,6 @@
 Name:   perl-XML-XPath
-Version:1.36
-Release:2%{?dist}
+Version:1.37
+Release:1%{?dist}
 Summary:XPath parser and evaluator for Perl
 # XML/XPath.pm, XML/XPath/PerlSAX.pm, REAME: GPL+ or Artistic
 # Others: Artistic 2.0
@@ -76,6 +76,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jun 02 2016 Jitka Plesnikova  - 1.37-1
+- 1.37 bump
+
 * Mon May 16 2016 Jitka Plesnikova  - 1.36-2
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index c356235..16c9330 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a5289ed7c9259e80d7a003f85e4626ac  XML-XPath-1.36.tar.gz
+72103d045298f8d7fb945d8b1ae31313  XML-XPath-1.37.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-XML-XPath.git/commit/?h=master=3c2deaeb90898e751a1efa51ce923737c5155ff7
--
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 XML-XPath-1.37.tar.gz for perl-XML-XPath

72103d045298f8d7fb945d8b1ae31313  XML-XPath-1.37.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-XML-XPath/XML-XPath-1.37.tar.gz/md5/72103d045298f8d7fb945d8b1ae31313/XML-XPath-1.37.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

Re: systemd 230 change - KillUserProcesses defaults to yes

2016-06-02 Thread Paul Wouters

> On Jun 1, 2016, at 09:48, Lennart Poettering wrote:
> 
> 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.

You are redefining the meaning of (a graphical) logout. It simply means another 
user can use the mouse,
keyboard and screen of this device. It makes no statement on whether the 
machines resources are shared or not.   

It allows you to kill anything that has to do with the user controlling the 
screen, keyboard and mouse but the killing should be limited to those 
processes. And then we are back at "just fix those broken processes".

As others pointed out, the security feature does not really apply if the user 
is allowed to use any and all resources while logged in.

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

xavierb requested branch el6 for package perl-Data-Password

xavierb requested branch el6 for package perl-Data-Password
https://admin.fedoraproject.org/pkgdb/package/perl-Data-Password/
--
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

xavierb requested branch epel7 for package perl-Data-Password

xavierb requested branch epel7 for package perl-Data-Password
https://admin.fedoraproject.org/pkgdb/package/perl-Data-Password/
--
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

2016-06-02 Thread Przemek Klosowski


On 06/02/2016 12:37 PM, Tom Rivers wrote:
The potential problem I see with changing the default behavior of 
systemd is that it is non-intuitive and could be potentially harmful 
if the user is not aware of it.  Consider the following example.  I 
routinely use screen when I connect to the systems I manage remotely 
specifically when I try to apply updates.  I do this because if my VPN 
connection or my Internet connection is interrupted, the update 
process will not die with my login session.  Incidentally, I learned 
to use screen when applying updates the hard way many years ago when a 
killed update wreaked havoc with a system of mine and I found screen 
to be an excellent solution. 
Yes, and to make things worse, many systems with elevated 
security/sensitivity enforce idle session timeout that just looks at 
keyboard activity---so they tend to abort long-running jobs, such as 
updates.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

ppisar set the koschei monitoring flag of perl-MojoX-JSON-RPC to True

ppisar set the koschei monitoring flag of perl-MojoX-JSON-RPC to True

--
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-Test-Compile (el6). "1.3.0 bump"

From efd581a8f63a38d2660b6250626ef5143d6b9bfa Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Fri, 27 May 2016 14:29:04 +0200
Subject: 1.3.0 bump

---
 .gitignore |  15 ++
 Makefile   |  21 
 perl-Test-Compile.spec | 144 +
 sources|   1 +
 4 files changed, 160 insertions(+), 21 deletions(-)
 create mode 100644 .gitignore
 delete mode 100644 Makefile
 create mode 100644 perl-Test-Compile.spec

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..6e263a3
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,15 @@
+Test-Compile-0.13.tar.gz
+/Test-Compile-0.14.tar.gz
+/Test-Compile-0.15.tar.gz
+/Test-Compile-0.16.tar.gz
+/Test-Compile-0.17.tar.gz
+/Test-Compile-0.18.tar.gz
+/Test-Compile-0.19.tar.gz
+/Test-Compile-0.20.tar.gz
+/Test-Compile-0.21.tar.gz
+/Test-Compile-0.22.tar.gz
+/Test-Compile-0.23.tar.gz
+/Test-Compile-0.24.tar.gz
+/Test-Compile-v1.2.0.tar.gz
+/Test-Compile-v1.2.1.tar.gz
+/Test-Compile-v1.3.0.tar.gz
diff --git a/Makefile b/Makefile
deleted file mode 100644
index df46d90..000
--- a/Makefile
+++ /dev/null
@@ -1,21 +0,0 @@
-# Makefile for source rpm: perl-Test-Compile
-# $Id$
-NAME := perl-Test-Compile
-SPECFILE = $(firstword $(wildcard *.spec))
-
-define find-makefile-common
-for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ; 
then if [ -f $$d/CVS/Root -a -w $$/Makefile.common ] ; then cd $$d ; cvs -Q 
update ; fi ; echo "$$d/Makefile.common" ; break ; fi ; done
-endef
-
-MAKEFILE_COMMON := $(shell $(find-makefile-common))
-
-ifeq ($(MAKEFILE_COMMON),)
-# attept a checkout
-define checkout-makefile-common
-test -f CVS/Root && { cvs -Q -d $$(cat CVS/Root) checkout common && echo 
"common/Makefile.common" ; } || { echo "ERROR: I can't figure out how to 
checkout the 'common' module." ; exit -1 ; } >&2
-endef
-
-MAKEFILE_COMMON := $(shell $(checkout-makefile-common))
-endif
-
-include $(MAKEFILE_COMMON)
diff --git a/perl-Test-Compile.spec b/perl-Test-Compile.spec
new file mode 100644
index 000..2b8127b
--- /dev/null
+++ b/perl-Test-Compile.spec
@@ -0,0 +1,144 @@
+# Real version
+%global cpan_version v1.3.0
+
+Name:   perl-Test-Compile
+Version:%(echo '%{cpan_version}' | tr -d 'v')
+Release:1%{?dist}
+Summary:Check whether Perl module files compile correctly
+License:GPL+ or Artistic
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/Test-Compile/
+Source0:
http://search.cpan.org/CPAN/authors/id/E/EG/EGILES/Test-Compile-%{cpan_version}.tar.gz
+BuildArch:  noarch
+BuildRequires:  coreutils
+BuildRequires:  findutils
+BuildRequires:  make
+BuildRequires:  perl
+BuildRequires:  perl(ExtUtils::MakeMaker)
+# Run-time
+# Devel::CheckOS is needed only on VMS. See Changes.
+BuildRequires:  perl(File::Spec)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(Test::Builder)
+BuildRequires:  perl(UNIVERSAL::require)
+BuildRequires:  perl(version)
+BuildRequires:  perl(warnings)
+# Tests
+# Test::More version is described in Changes
+BuildRequires:  perl(Test::More) >= 0.88
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+
+%{?perl_default_filter}
+
+%description
+Test::Compile lets you check the validity of a Perl module file or Perl script
+file, and report its results in standard Test::Simple fashion.
+
+%prep
+%setup -q -n Test-Compile-%{cpan_version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} +
+%{_fixperms} %{buildroot}/*
+
+%check
+make test
+
+%files
+%license LICENSE
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Fri Sep 25 2015 Jitka Plesnikova  - 1.3.0-1
+- 1.3.0 bump
+
+* Tue Dec 09 2014 Jitka Plesnikova  - 1.2.1-1
+- 1.2.1 bump
+
+* Fri Nov 14 2014 Jitka Plesnikova  - 1.2.0-1
+- 1.2.0 bump
+
+* Mon Feb 25 2013 Petr Šabata  - 0.24-1
+- 0.24 bump (docs only)
+
+* Thu Feb 14 2013 Fedora Release Engineering  
- 0.23-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
+
+* Thu Jan 24 2013 Petr Šabata  - 0.23-1
+- 0.23 bump
+
+* Wed Oct 31 2012 Petr Šabata  - 0.22-1
+- 0.22 bumpity
+
+* Thu Sep 13 2012 Jitka Plesnikova  - 0.21-1
+- 0.21 bump
+- Remove the filter of ::Internal module. It is no longer 'beta' and could
+  be used directly to test a CPAN distribution.
+
+* Thu Aug 09 2012 Petr Šabata  - 0.20-1
+- 0.20 bump
+
+* Wed Aug 08 2012 Petr Šabata  - 0.19-2
+- Filter the ::Internal module from requires too
+
+* Mon Aug 06 2012 Petr Šabata  - 0.19-1
+- 0.19 bump
+
+* Fri Jul 20 2012 Fedora Release Engineering

jplesnik pushed to perl-DBIx-Class-EncodedColumn (master). "0.00015 bump"

From 2d21f31af85f80f4ed1698d319219f04a1ac9cad Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 2 Jun 2016 16:16:49 +0200
Subject: 0.00015 bump

---
 .gitignore |  1 +
 perl-DBIx-Class-EncodedColumn.spec | 11 +--
 sources|  2 +-
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 998ae07..391cce1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ DBIx-Class-EncodedColumn-0.9.tar.gz
 /DBIx-Class-EncodedColumn-0.00010.tar.gz
 /DBIx-Class-EncodedColumn-0.00011.tar.gz
 /DBIx-Class-EncodedColumn-0.00013.tar.gz
+/DBIx-Class-EncodedColumn-0.00015.tar.gz
diff --git a/perl-DBIx-Class-EncodedColumn.spec 
b/perl-DBIx-Class-EncodedColumn.spec
index b36ae6d..914dff5 100644
--- a/perl-DBIx-Class-EncodedColumn.spec
+++ b/perl-DBIx-Class-EncodedColumn.spec
@@ -1,6 +1,6 @@
 Name:   perl-DBIx-Class-EncodedColumn
-Version:0.00013
-Release:5%{?dist}
+Version:0.00015
+Release:1%{?dist}
 Summary:Automatically encode columns
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/DBIx-Class-EncodedColumn/
@@ -8,7 +8,9 @@ Source0:
http://search.cpan.org/CPAN/authors/id/W/WR/WREIS/DBIx-Class-Enc
 BuildArch:  noarch
 # Build
 BuildRequires:  perl
+BuildRequires:  perl-generators
 BuildRequires:  perl(base)
+BuildRequires:  perl(Capture::Tiny)
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(Config)
 BuildRequires:  perl(CPAN)
@@ -19,6 +21,8 @@ BuildRequires:  perl(Fcntl)
 BuildRequires:  perl(File::Find)
 BuildRequires:  perl(File::Path)
 BuildRequires:  perl(File::Spec)
+BuildRequires:  perl(IO::All)
+BuildRequires:  perl(Pod::Markdown)
 BuildRequires:  perl(strict)
 BuildRequires:  perl(vars)
 BuildRequires:  perl(warnings)
@@ -73,6 +77,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jun 02 2016 Jitka Plesnikova  - 0.00015-1
+- 0.00015 bump
+
 * Tue May 17 2016 Jitka Plesnikova  - 0.00013-5
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 822f0e3..4c95aba 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6c3bb0ee68be15ae26ce53cd60b5bbd9  DBIx-Class-EncodedColumn-0.00013.tar.gz
+08c984958e0cd04774245aa609041362  DBIx-Class-EncodedColumn-0.00015.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-DBIx-Class-EncodedColumn.git/commit/?h=master=2d21f31af85f80f4ed1698d319219f04a1ac9cad
--
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

2016-06-02 Thread Richard W.M. Jones

On Wed, Jun 01, 2016 at 10:25:32AM +0100, Tom Hughes wrote:
> On 01/06/16 10:20, Bastien Nocera 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".
> >
> >Really? The only times I ever used it was to access serial consoles with
> >a better emulation than separate apps.
> 
> You've obviously never had to run something that's going to take
> hours or days to complete on a remote server and not wanted it to
> abort half way through because of a network glitch then.
> 
> That's when I use screen, either just setting running something in
> the background, or leaving it connected but knowing it will continue
> if anything goes wrong and I can just reattach from a new login.

I'm using 'screen /dev/ttyUSBX 115200' to monitor serial consoles
while I'm logged out :-)

Rich.

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

jplesnik uploaded DBIx-Class-EncodedColumn-0.00015.tar.gz for perl-DBIx-Class-EncodedColumn

08c984958e0cd04774245aa609041362  DBIx-Class-EncodedColumn-0.00015.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-DBIx-Class-EncodedColumn/DBIx-Class-EncodedColumn-0.00015.tar.gz/md5/08c984958e0cd04774245aa609041362/DBIx-Class-EncodedColumn-0.00015.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

Re: systemd 230 change - KillUserProcesses defaults to yes

2016-06-02 Thread Allan Gardner

On Thu, Jun 2, 2016 at 7:14 AM, Björn Persson  wrote:
> Lennart Poettering  wrote:
>
>> And even more: after you disabled his
>> user account and logged him out, he really should be gone.
>
> After you disabled his user account, he really should be gone. If he's
> just logged out, he will be back tomorrow. Logging out is one thing.
> Disabling a user account is another. Kill any lingering processes when
> disabling the account, not every time the user logs out.
>
> A single command that both disables a user account and kills any
> processes running as that user might be handy. Anyone who thinks it's
> needed can write such a tool.

I looked and so far there does not seem to be a one-command solution.

But 3 steps suffice:
1. Disable the account so that they cannot make new sessions:

usermod -L --expiredate 1 

2. Set the pid limit of the user's cgroup to 0, so that they cannot
fork new processes:

systemctl set-property user-.slice TasksMax=0

3. Kill the user's processes:

loginctl kill-user --signal=SIGKILL 

This could be wrapped up in a single command like "loginctl kickban
". I'm guessing a lot of sysadmins would appreciate it.

There's some trickiness involved, in that usermod does not handle
networked setups like sssd, but perfect is the enemy of good.

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

Re: Fedora 24-20160602.n.0 compose check report

On Thu, 2016-06-02 at 11:06 -0600, Chris Murphy wrote:
> On Thu, Jun 2, 2016 at 9:19 AM, Adam Williamson
> <adamw...@fedoraproject.org> wrote:
> > On Thu, 2016-06-02 at 14:28 +, Fedora compose checker wrote:
> > > Missing expected images:
> > > 
> > > Kde live i386
> > > Kde live x86_64
> > > Cloud_base raw-xz i386
> > > 
> > > Failed openQA tests: 3/70 (x86_64), 2/16 (i386), 1/2 (arm)
> > > 
> > > ID: 20162 Test: x86_64 Workstation-live-iso install_default@uefi
> > > URL: https://openqa.fedoraproject.org/tests/20162
> > 
> > This is kind of an interesting one I haven't managed to look into yet:
> > I think what's going on is that initial-setup is not behaving as
> > expected because there's no network connection, but I haven't worked
> > out why there's no network connection yet. Will look into it when I
> > can.
> 
> Did this fail happen with 20160531.n.0? Or is it new in 20160602.n.0?
> I can't reproduce with 0531.

You can see previous results in the openQA web UI (this is a new
feature in the last month or two). Click the 'Previous results' tab. It
passed several times but failed in the same way on 05-28; I've seen the
same failure a few times, so I think it's some kind of intermittent
failure case. It may also be in some way related to the way openQA sets
up networking in the VMs (it uses qemu user networking by default), or
it may not...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: Update notice FEDORA-EPEL-2016-(several) is broken, or a bad duplicate, skipping.

On 2 June 2016 at 09:24, Michael Mol  wrote:
> Ran a yum check-update on a staleish host this morning, saw these. They ask
> that I contact the epel-testing and epel-testing-source repository owners,
> which appear to be this list.
>
>
> Update notice FEDORA-EPEL-2016-7a12df64c2 (from epel-testing) is broken, or a
> bad duplicate, skipping.
> You should report this problem to the owner of the epel-testing repository.
> Update notice FEDORA-EPEL-2016-4a34feb770 (from epel-testing) is broken, or a
> bad duplicate, skipping.
> Update notice FEDORA-EPEL-2016-68173ad9aa (from epel-testing) is broken, or a
> bad duplicate, skipping.
> Update notice FEDORA-EPEL-2016-3ad7519632 (from epel-testing) is broken, or a
> bad duplicate, skipping.
> Update notice FEDORA-EPEL-2016-d116318f11 (from epel-testing) is broken, or a
> bad duplicate, skipping.
> Update notice FEDORA-EPEL-2016-a3e8d9b435 (from epel-testing) is broken, or a
> bad duplicate, skipping.
> Update notice FEDORA-EPEL-2016-7a12df64c2 (from epel-testing-source) is
> broken, or a bad duplicate, skipping.

OK I have replicated it in EPEL-7


Update notice FEDORA-EPEL-2016-68173ad9aa (from epel-testing) is
broken, or a bad duplicate, skipping.
Update notice FEDORA-EPEL-2016-3ad7519632 (from epel-testing) is
broken, or a bad duplicate, skipping.
Update notice FEDORA-EPEL-2016-d116318f11 (from epel-testing) is
broken, or a bad duplicate, skipping.
Update notice FEDORA-EPEL-2016-a3e8d9b435 (from epel-testing) is
broken, or a bad duplicate, skipping.

It does not seem to break yum update.. will try to figure out what is
causing this.

Thnaks.


-- 
Stephen J Smoogen.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: Fedora 24-20160602.n.0 compose check report

2016-06-02 Thread Chris Murphy

On Thu, Jun 2, 2016 at 9:19 AM, Adam Williamson
<adamw...@fedoraproject.org> wrote:
> On Thu, 2016-06-02 at 14:28 +, Fedora compose checker wrote:
>> Missing expected images:
>>
>> Kde live i386
>> Kde live x86_64
>> Cloud_base raw-xz i386
>>
>> Failed openQA tests: 3/70 (x86_64), 2/16 (i386), 1/2 (arm)
>>
>> ID: 20162 Test: x86_64 Workstation-live-iso install_default@uefi
>> URL: https://openqa.fedoraproject.org/tests/20162
>
> This is kind of an interesting one I haven't managed to look into yet:
> I think what's going on is that initial-setup is not behaving as
> expected because there's no network connection, but I haven't worked
> out why there's no network connection yet. Will look into it when I
> can.

Did this fail happen with 20160531.n.0? Or is it new in 20160602.n.0?
I can't reproduce with 0531.



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

jplesnik pushed to perl-XML-LibXML (f24). "2.0125 bump"

From 101c7909eaf6034f29439e58b34b934175c17b03 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 2 Jun 2016 15:32:16 +0200
Subject: 2.0125 bump

---
 .gitignore   | 1 +
 perl-XML-LibXML.spec | 5 -
 sources  | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 7dd18b8..aebf8e8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -42,3 +42,4 @@ XML-LibXML-1.70.tar.gz
 /XML-LibXML-2.0122.tar.gz
 /XML-LibXML-2.0123.tar.gz
 /XML-LibXML-2.0124.tar.gz
+/XML-LibXML-2.0125.tar.gz
diff --git a/perl-XML-LibXML.spec b/perl-XML-LibXML.spec
index 1c8459e..0427c9b 100644
--- a/perl-XML-LibXML.spec
+++ b/perl-XML-LibXML.spec
@@ -7,7 +7,7 @@ Name:   perl-XML-LibXML
 # https://bugzilla.redhat.com/show_bug.cgi?id=469480
 # it might not be needed anymore
 # this module is maintained, the other is not
-Version:2.0124
+Version:2.0125
 Release:1%{?dist}
 Epoch:  1
 Summary:Perl interface to the libxml2 library
@@ -129,6 +129,9 @@ fi
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jun 02 2016 Jitka Plesnikova  - 1:2.0125-1
+- 2.0125 bump
+
 * Mon Feb 29 2016 Jitka Plesnikova  - 1:2.0124-1
 - 2.0124 bump
 
diff --git a/sources b/sources
index 3621bf2..02dd7a3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-30436b85454fba3ae5f6494df598e65c  XML-LibXML-2.0124.tar.gz
+a0c1ff8588e1b08cd6323f478b3dfc31  XML-LibXML-2.0125.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-XML-LibXML.git/commit/?h=f24=101c7909eaf6034f29439e58b34b934175c17b03
--
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-XML-LibXML (master). "2.0125 bump"

From 3b0501e09c1a93b39de5cba57bf602e2a2515575 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 2 Jun 2016 15:25:42 +0200
Subject: 2.0125 bump

---
 .gitignore   | 1 +
 perl-XML-LibXML.spec | 7 +--
 sources  | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 7dd18b8..aebf8e8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -42,3 +42,4 @@ XML-LibXML-1.70.tar.gz
 /XML-LibXML-2.0122.tar.gz
 /XML-LibXML-2.0123.tar.gz
 /XML-LibXML-2.0124.tar.gz
+/XML-LibXML-2.0125.tar.gz
diff --git a/perl-XML-LibXML.spec b/perl-XML-LibXML.spec
index e1799f5..988b60a 100644
--- a/perl-XML-LibXML.spec
+++ b/perl-XML-LibXML.spec
@@ -7,8 +7,8 @@ Name:   perl-XML-LibXML
 # https://bugzilla.redhat.com/show_bug.cgi?id=469480
 # it might not be needed anymore
 # this module is maintained, the other is not
-Version:2.0124
-Release:2%{?dist}
+Version:2.0125
+Release:1%{?dist}
 Epoch:  1
 Summary:Perl interface to the libxml2 library
 Group:  Development/Libraries
@@ -129,6 +129,9 @@ fi
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jun 02 2016 Jitka Plesnikova  - 1:2.0125-1
+- 2.0125 bump
+
 * Mon May 16 2016 Jitka Plesnikova  - 1:2.0124-2
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 3621bf2..02dd7a3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-30436b85454fba3ae5f6494df598e65c  XML-LibXML-2.0124.tar.gz
+a0c1ff8588e1b08cd6323f478b3dfc31  XML-LibXML-2.0125.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-XML-LibXML.git/commit/?h=master=3b0501e09c1a93b39de5cba57bf602e2a2515575
--
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 XML-LibXML-2.0125.tar.gz for perl-XML-LibXML

a0c1ff8588e1b08cd6323f478b3dfc31  XML-LibXML-2.0125.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-XML-LibXML/XML-LibXML-2.0125.tar.gz/md5/a0c1ff8588e1b08cd6323f478b3dfc31/XML-LibXML-2.0125.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

Re: systemd 230 change - KillUserProcesses defaults to yes

2016-06-02 Thread Tom Rivers


On 6/2/2016 7:04 AM, Lennart Poettering wrote:

In all of these cases you really want to make sure that whatever the
user did ends – really ends – by the time he logs out.


I apologize if this has already been brought up, but I didn't see this 
particular point raised in the replies I've read and I wanted to be sure 
it is mentioned.


The potential problem I see with changing the default behavior of 
systemd is that it is non-intuitive and could be potentially harmful if 
the user is not aware of it.  Consider the following example.  I 
routinely use screen when I connect to the systems I manage remotely 
specifically when I try to apply updates.  I do this because if my VPN 
connection or my Internet connection is interrupted, the update process 
will not die with my login session.  Incidentally, I learned to use 
screen when applying updates the hard way many years ago when a killed 
update wreaked havoc with a system of mine and I found screen to be an 
excellent solution.


Currently screen is a utility whose purpose is, in part, to allow a user 
to disconnect from a running process in a safe way that will allow it to 
keep running and be resumed in the future from another session 
entirely.  Now that will only be valid if the user knows whether or not 
systemd is configured on the system in question to not automatically 
reap these kinds of processes.  This would have the effect of 
transforming what is clear and precise documentation of a well known and 
widely used utility into something that relies on another set of system 
configuration settings that are arguably not as intuitive.


For the record, I am not trying to say I am opposed to increasing system 
security and progress in general in the slightest - both are laudable 
goals.  What I am trying to say is that there is a lot of merit in 
making sure things are not made unnecessarily more complex and difficult 
to discern unnecessarily.  Whatever needs to be done to increase 
security needs to be done while embracing the notion of not pulling the 
rug out from under legitimate uses of programs whose indiscriminate and 
unexpected reaping could cause disastrous results.



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

Re: [Modularity] WG meeting time

2016-06-02 Thread Jan Kurik

On Tue, May 31, 2016 at 9:37 PM, Jan Kurik  wrote:
> On Wed, May 4, 2016 at 3:03 AM, Langdon White  wrote:
>> Hi,
>>
>> Unfortunately, I heard from some of the new voting members that the current
>> Modularity WG meeting time is not doable for them. Please use the link below
>> to help us figure out a new time.
>>
>> http://whenisgood.net/hzd7x2b
>>
>> Langdon
>>
>> PS: haven't actually used whenisgood to schedule a meeting before.. so.. if
>> i made any mistakes.. apologies :)
>
> Hi WG members,
>
> on the last meeting I have volunteered to follow up with the "meeting
> time" issue.
> So, I have asked Langdon to provide me with results from the voting on
> whenisgood. The following times are the ones when most people are
> available (Timezone: US/Eastern):
>
> * Monday - 11:00 AM
> * Tuesday - 07:00 AM
> * Tuesday - 10:00 AM
> * Tuesday - 11:00 AM <- this is the most preferred time
> * Thursday - 10:00 AM
> * Thursday - 11:00 AM
> * Friday - 11:00AM
>
> As the "Tuesday - 11:00 AM" time is the most preferred one, I would
> like to propose this as the new time for our meeting. On the upcoming
> meeting this Thursday (2016-Jun-02) we can have a discussion whether
> it is acceptable for all the members of this WG and make a final
> decision.

Hi everybody,

on the meeting today [1] we have agreed to move the regular Modularity
WG meeting from Thursday to Tuesday, while keeping the same time.
The new meeting time [2] is now scheduled on Tuesday at 15:00 UTC.
This meeting time applies immediately, so the next WG meeting is on
Tuesday 2016-Jun-07.

[1] 
https://meetbot.fedoraproject.org/fedora-meeting/2016-06-02/modularity_wg.2016-06-02-15.00.html
[2] https://apps.fedoraproject.org/calendar/meeting/3924/

Regards,
Jan

> Regards,
> Jan
>
> --
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic



-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

On 2 June 2016 at 12:03, 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.
>

You are both right and wrong :)

Right because of: EPEL does not conflict with RHEL packages that are
not in certain base channels.
Wrong because of: Satellite is not one of those base channels.






-- 
Stephen J Smoogen.
___
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

2016-06-02 Thread Ray Strode

Hi,

> I don't think we need to change Fedora 24 for this. Unless I misunderstood, 
> this
> systemd change has not been pushed to Fedora 24 (nor proposed for it). We're
> prepping for how to deal with things in Fedora 25.

No, I was the one misunderstanding things.  I thought the systemd
change got pushed into F24 in early May, but reading through my IRC
logs, that was just miscommunication.

Of course the systemd change was going to address a bug we have with
lingering processes at log out, so we'll probably have to come up with
some other fix for f24 at some point, but we can do it as a
post-release update.

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

jplesnik pushed to perl-version (f24). "0.9917 bump"

From e54e9a3482c5a89ca0ab2ad25b7aa4e8db48c13b Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 2 Jun 2016 14:55:53 +0200
Subject: 0.9917 bump

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

diff --git a/.gitignore b/.gitignore
index 5c4d88f..9932c41 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,3 +13,4 @@ version-0.88.tar.gz
 /version-0.9914.tar.gz
 /version-0.9915.tar.gz
 /version-0.9916.tar.gz
+/version-0.9917.tar.gz
diff --git a/perl-version.spec b/perl-version.spec
index 9767f1c..e057781 100644
--- a/perl-version.spec
+++ b/perl-version.spec
@@ -1,7 +1,7 @@
 Name:   perl-version
 Epoch:  5
-Version:0.99.16
-%global module_version 0.9916
+Version:0.99.17
+%global module_version 0.9917
 Release:1%{?dist}
 Summary:Perl extension for Version Objects
 License:GPL+ or Artistic
@@ -90,6 +90,9 @@ make test
 %{_mandir}/man3/version::Internals.3pm*
 
 %changelog
+* Thu Jun 02 2016 Jitka Plesnikova  - 5:0.99.17-1
+- 0.9917 bump
+
 * Mon Mar 21 2016 Jitka Plesnikova  - 5:0.99.16-1
 - 0.9916 bump
 
diff --git a/sources b/sources
index 83f5591..77efcb5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-cc90aae6413f8d1400fb912dff42efbd  version-0.9916.tar.gz
+2f43d77d529818caed72995f37789e9b  version-0.9917.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-version.git/commit/?h=f24=e54e9a3482c5a89ca0ab2ad25b7aa4e8db48c13b
--
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

2016-06-02 Thread Matthew Miller

On Thu, Jun 02, 2016 at 01:04:44PM +0200, Lennart Poettering wrote:
> Well. Let's say you are responsible for the Linux desktops of a large
> security-senstive company (let's say bank, whatever), and the desktops
> are installed as fixed workstations, which different employees using
> them at different times. They log in, they do some "important company

I definitely see the use of the option.

However, the above isn't the target for _any_ of the Fedora Editions,
except _maybe_ "Developer in a large organization" for Workstation, and
even then I think it's not likely to be the above.

> This is really just one example. This model I think really needs to be
> the default everywhere. On desktops and on servers: unless the admin
> permitted it explicitly, there should not be user code running. If you
> allow your intern user access to a webserver to quickly check our the
> resource consumption of some service that doesn't mean that he shall
> be allowed to run stuff there forever, just because he once had the
> login privilege for the server. And even more: after you disabled his
> user account and logged him out, he really should be gone.

"On desktops and on servers: unless the admin permitted it explicitly,
there should not be user code running" is a fine statement of policy,
but it's _definitely_ policy, not fact, or even generalized best
practice. 

Disabling user accounts and logging someone out seems like a separate
management problem not necessarily addressed by this anyway (how do you
ensure logout on all systems?).

-- 
Matthew Miller

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

Re: Task Result Namespaces

2016-06-02 Thread Tim Flink

On Thu, 2 Jun 2016 07:46:33 -0400 (EDT)
Kamil Paral  wrote:

> > 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.*,  
> 
> Agreed. Once we have dist-git checks implemented, we can ask docker
> maintainers to keep it and maintain it in their repo. If they don't
> want, we can keep it in our domain (same as anyone will be able to
> run any test against any package in their personal space).

It seems really weird to have one effectively package-specific in qa.*
but there are worse things.

> > 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,  
> 
> More on this below.
> 
> > 2. create additional dist.* namespace where tasks like abicheck
> >and/or rpmgrill would be, or  
> 
> What is the use case for "dist."? Which tasks would go there and
> which would not? Is this just about "scratch" not sounding that good?

I'm pretty anti-fas-name on the release blocking checks (will detail
below) so in my mind, dist.* is a good place to put things which need
to be run on all the packages/updates/composes etc. - something that is
pretty much global. Other ideas on how to split that stuff up are
welcome, though.

Having scratch.* be the catch-all also allows us to say "scratch.*
probably isn't important" while having another option for where to put
results. I think of it as kinda similar to the concept of a scratch
build in koji.

> > 3. change semantics of qa.* to 'anything Fedora QA maintains or
> >important, not package-specific, tasks".  
> 
> Personally, I always considered our namespaces to have two functions:
> 1. show ownership - it's clear who owns qa.depcheck, or
> fas.ksinny.abicheck, or group.workstation.gnome-startup

Why is it important to show ownership? In some cases (mostly
non-release-blocking stuff), I can kind of see a case for this but for
abicheck in particular, I don't see the point. We don't encode the
maintainer(s) into package names for fedora, why should we for
checks/tests/tasks?

From a more (perhaps overly) cynical PoV, I suspect that we're going to
get the lion's share of complaints about failing tasks, no matter what
the namespace happens to be.

I don't really have an issue with the group names. If that name changes
or the task is handed off to some other group, I think that there will
be bigger changes afoot where changing filters etc. aren't the biggest
concern.

FWIW, I don't remember the concept of ownership coming up in the
original discussions of namespaces - mostly "security" and being able
to tell which results are more important in terms of release blocking
vs. package blocking.

> 2. increase
> security and eliminate mistakes - by allowing certain people or
> groups to write results only into their own namespace, we reduce
> attack vectors (random people can't send fake results for
> qa.depcheck) and we eliminate mistakes (people will not create a
> thousand test cases in "qa." by accident)

I think this is the primary use case for namespaces, honestly.

> I didn't intend namespaces to reflect task importance in any way,
> e.g. to put all gating tasks into "qa.". It sounds tempting, but it's
> likely to violate the two functions mentioned above. For release
> critical tasks, it's possible that we will take their ownership and
> maintain them, but I don't think it's going to happen for all of
> them. I don't see a problem in Bodhi or some releng tools monitoring
> qa.depcheck, qa.upgradepath and fas.ksinny.abicheck. It's all about
> trust, and the exact testcase name doesn't matter. You can't trust a
> random person that he/she will maintain the task and quickly fix all
> issues, but once you know who you're dealing with and that he/she is
> willing and capable of doing that work, it doesn't matter whether the
> namespace is "qa." or "fas.".

Let's pretend that everyone who maintains task-abicheck decides to go on
vacation for a month. One week into that month, task-abicheck breaks
horribly and is no longer producing results that we can believe. If
we're relying on results from task-abicheck to do things like gate
non-rawhide builds moving into stable tags, I really don't think that
the attitude will be "oh well, none of the

jplesnik pushed to perl-version (master). "0.9917 bump"

From c5b1bafaf2d3594f2d1fe2e3981855601b430d04 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 2 Jun 2016 14:50:30 +0200
Subject: 0.9917 bump

---
 .gitignore| 1 +
 perl-version.spec | 9 ++---
 sources   | 2 +-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/.gitignore b/.gitignore
index 5c4d88f..9932c41 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,3 +13,4 @@ version-0.88.tar.gz
 /version-0.9914.tar.gz
 /version-0.9915.tar.gz
 /version-0.9916.tar.gz
+/version-0.9917.tar.gz
diff --git a/perl-version.spec b/perl-version.spec
index d45dd11..f78804c 100644
--- a/perl-version.spec
+++ b/perl-version.spec
@@ -1,8 +1,8 @@
 Name:   perl-version
 Epoch:  5
-Version:0.99.16
-%global module_version 0.9916
-Release:365%{?dist}
+Version:0.99.17
+%global module_version 0.9917
+Release:1%{?dist}
 Summary:Perl extension for Version Objects
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/version/
@@ -90,6 +90,9 @@ make test
 %{_mandir}/man3/version::Internals.3pm*
 
 %changelog
+* Thu Jun 02 2016 Jitka Plesnikova  - 5:0.99.17-1
+- 0.9917 bump
+
 * Sat May 14 2016 Jitka Plesnikova  - 5:0.99.16-365
 - Increase release to favour standalone package
 
diff --git a/sources b/sources
index 83f5591..77efcb5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-cc90aae6413f8d1400fb912dff42efbd  version-0.9916.tar.gz
+2f43d77d529818caed72995f37789e9b  version-0.9917.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-version.git/commit/?h=master=c5b1bafaf2d3594f2d1fe2e3981855601b430d04
--
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

2016-06-02 Thread 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

jplesnik uploaded version-0.9917.tar.gz for perl-version

2f43d77d529818caed72995f37789e9b  version-0.9917.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-version/version-0.9917.tar.gz/md5/2f43d77d529818caed72995f37789e9b/version-0.9917.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

Re: systemd 230 change - KillUserProcesses defaults to yes

2016-06-02 Thread Chris Murphy

On Thu, Jun 2, 2016 at 9:01 AM, Ray Strode  wrote:

>
> Of course, starting in Fedora 24, we no longer have a session bus.
> It's a user bus now.  So the bus won't go away until the last user
> session (for a user) ends, and those background services won't go away
> until they lose their bus connections, since they still rely on
> dbus-daemon to cut the cord when the session ends.  While those
> background services are waiting for their bus connection to disappear,
> they're keeping the session alive (but in a "closing" state).

Sounds familiar. While it's not reproducible in a VM, on two baremetal
systems I can reproduce 1m30s restart/shutdown delays on defaut clean
installations.

> To me, KillUserProcesses=yes is better from a theoretical
> it-should-have-always-done-this-if-it-could-have standpoint, and it's
> better from real world
> it-eliminates-a-class-of-bugs-that-has-plagued-us standpoint.

KillUserProcesses=yes isn't solving the problem I'm easily able to
reproduce, because it isn't killing the gdm owned session-c1.scope,
which appears to hang due to ibus-daemon not quitting.

There's a gdm owned ibus-daemon process, and a chris owned one. With
the default of KillUserProcesses=no, restart shutdown and logout are
delayed. If I set it to yes, the logout problem is fixed, but the
restart and shutdown delays aren't fixed.

>
> I don't like that it requires users to have to change workflows, so
> that's a negative and I understand why the change is controversial.
>
> We may want to consider reverting the user bus change for F24 and
> revisit in F25, not sure.

Well it's uncertain to me whether the testers so far are just
desensitized to restart delays or if they're just not encountering it,
and it's a conditional problem. If it's encountered broadly and is
fixable some reasonable time after release (a month? two?) fine. But
already I'm in the habit of rebooting Fedora 24 with 'sudo reboot -f'
because I don't have 30 seconds of patience in me let alone nearly two
minutes. But I think we're stuck between a rock and hard place between
excessive restart delays and reversion this late in the game.

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

2016-06-02 Thread Stephen Gallagher

On 06/02/2016 11:36 AM, Jóhann B. Guðmundsson wrote:
> On 06/02/2016 03:13 PM, Stephen Gallagher wrote:
> 
>> I don't think we need to change Fedora 24 for this. Unless I misunderstood, 
>> this
>> systemd change has not been pushed to Fedora 24 (nor proposed for it). We're
>> prepping for how to deal with things in Fedora 25.
> 
> You should not so easily dismiss and rule out core/baseOS ( and even other )
> components adapting similar or same updating rebase scheme as the kernel
> community is using as ( and has prove to be working ).
> 
> There where upcoming changes in systemd that prevented this back in 2013 when 
> I
> wrote this [1] proposal and we discussed it but those road blocks are no more
> afaik hence there is nothing preventing systemd from adapting an rebase scheme
> similar/same to the one that the kernel community is using.
> 

I'm not saying that upstream systemd wouldn't or couldn't rebase, I was saying
that my understanding was that there was no plans for the KillUserProcesses
default to be changed post-release in any Fedora. That would be a significant
violation of the stable update policy, which I'm pretty certain the systemd
maintainers are aware of.

I should also have been more specific with the term "this" in my last email; I
was referring to whether we needed to revert the user bus change because of
systemd. By my current understanding, that would not be necessary.

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

jplesnik pushed to perl-File-ChangeNotify (master). "0.26 bump"

From a1460f6b2b90f918012381106be2b0645b871e9a Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 2 Jun 2016 14:20:23 +0200
Subject: 0.26 bump

---
 .gitignore  |  1 +
 perl-File-ChangeNotify.spec | 31 ++-
 sources |  2 +-
 3 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/.gitignore b/.gitignore
index 5c0ae40..d4ed499 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ File-ChangeNotify-0.13.tar.gz
 /File-ChangeNotify-0.22.tar.gz
 /File-ChangeNotify-0.23.tar.gz
 /File-ChangeNotify-0.24.tar.gz
+/File-ChangeNotify-0.26.tar.gz
diff --git a/perl-File-ChangeNotify.spec b/perl-File-ChangeNotify.spec
index 322e669..29d4320 100644
--- a/perl-File-ChangeNotify.spec
+++ b/perl-File-ChangeNotify.spec
@@ -1,14 +1,14 @@
 Name:   perl-File-ChangeNotify
 Summary:Watch for changes to files, cross-platform style
-Version:0.24
-Release:8%{?dist}
+Version:0.26
+Release:1%{?dist}
 License:Artistic 2.0
 Source0:
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/File-ChangeNotify-%{version}.tar.gz
 
 URL:http://search.cpan.org/dist/File-ChangeNotify
 BuildArch:  noarch
 # Build
 BuildRequires:  perl
-BuildRequires:  perl(Module::Build) >= 0.37
+BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires:  perl(strict)
 BuildRequires:  perl(warnings)
 # Runtime
@@ -20,12 +20,13 @@ BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(Linux::Inotify2) >= 1.2
 BuildRequires:  perl(List::MoreUtils)
 BuildRequires:  perl(Module::Pluggable::Object)
-BuildRequires:  perl(Moose)
-BuildRequires:  perl(Moose::Util::TypeConstraints)
-BuildRequires:  perl(MooseX::Params::Validate) >= 0.08
-BuildRequires:  perl(MooseX::SemiAffordanceAccessor)
+BuildRequires:  perl(Module::Runtime)
+BuildRequires:  perl(Moo) >= 1.006
+BuildRequires:  perl(Moo::Role)
 BuildRequires:  perl(namespace::autoclean)
 BuildRequires:  perl(Time::HiRes)
+BuildRequires:  perl(Type::Utils)
+BuildRequires:  perl(Types::Standard)
 # Tests only
 BuildRequires:  perl(base)
 BuildRequires:  perl(Data::Dumper)
@@ -36,6 +37,7 @@ BuildRequires:  perl(FindBin)
 BuildRequires:  perl(lib)
 BuildRequires:  perl(Test::Exception)
 BuildRequires:  perl(Test::More) >= 0.96
+BuildRequires:  perl(Test::Requires)
 # Optional tests only
 BuildRequires:  perl(Test::Without::Module)
 Requires:   perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo 
$version))
@@ -47,25 +49,28 @@ Watch for changes to files, easily, cleanly, and across 
different platforms.
 %setup -q -n File-ChangeNotify-%{version}
 
 %build
-perl Build.PL --installdirs vendor
-./Build
+perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
+make %{?_smp_mflags}
 
 %install
-./Build install --destdir %{buildroot} --create_packlist=0
-%{_fixperms} %{buildroot}/*
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+%{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-./Build test
+make test
 
 %files
 %license LICENSE
-%doc Changes README
+%doc Changes README.md
 %exclude %{perl_vendorlib}/File/ChangeNotify/Watcher/KQueue.pm
 %{perl_vendorlib}/*
 %exclude %{_mandir}/man3/File::ChangeNotify::Watcher::KQueue.3pm*
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jun 02 2016 Jitka Plesnikova  - 0.26-1
+- 0.26 bump
+
 * Mon May 16 2016 Jitka Plesnikova  - 0.24-8
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 3371685..7f54de2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-959f1e52d854b4a94f357545d291edca  File-ChangeNotify-0.24.tar.gz
+f9b96bb0210ed894159b12360331f8e0  File-ChangeNotify-0.26.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-File-ChangeNotify.git/commit/?h=master=a1460f6b2b90f918012381106be2b0645b871e9a
--
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 File-ChangeNotify-0.26.tar.gz for perl-File-ChangeNotify

f9b96bb0210ed894159b12360331f8e0  File-ChangeNotify-0.26.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-File-ChangeNotify/File-ChangeNotify-0.26.tar.gz/md5/f9b96bb0210ed894159b12360331f8e0/File-ChangeNotify-0.26.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

Re: systemd 230 change - KillUserProcesses defaults to yes

2016-06-02 Thread Jóhann B . Guðmundsson


On 06/02/2016 03:13 PM, Stephen Gallagher wrote:


I don't think we need to change Fedora 24 for this. Unless I misunderstood, this
systemd change has not been pushed to Fedora 24 (nor proposed for it). We're
prepping for how to deal with things in Fedora 25.


You should not so easily dismiss and rule out core/baseOS ( and even 
other ) components adapting similar or same updating rebase scheme as 
the kernel community is using as ( and has prove to be working ).


There where upcoming changes in systemd that prevented this back in 2013 
when I wrote this [1] proposal and we discussed it but those road blocks 
are no more afaik hence there is nothing preventing systemd from 
adapting an rebase scheme similar/same to the one that the kernel 
community is using.


JBG

1. 
https://fedoraproject.org/wiki/User:Johannbg/Systemd/systemd-rebase#DRAFT_Systemd_Rebasing

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

[Bug 1342096] perl-XML-XPath-1.37 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-XML-XPath-1.37-1.fc25
 Resolution|--- |RAWHIDE
Last Closed||2016-06-02 11:27:26



-- 
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 1342160] perl-BSSolv-0.01-11.git1e18c32.fc25 FTBFS: BSSolv.xs:19:22: fatal error: repo_deb.h: No such file or directory

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

Igor Gnatenko  changed:

   What|Removed |Added

 CC||ppi...@redhat.com
  Flags|needinfo?(ignatenko@redhat. |needinfo?(ppi...@redhat.com
   |com)|)



--- Comment #2 from Igor Gnatenko  ---
(In reply to Petr Pisar from comment #1)
> Igor, disabling support for Debian repositories in libsolv was intentional?

hm, actually yes. Didn't know that it would affect any packages.. Should I
enable it back? Which distversions?

-- 
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: Fedora 24-20160602.n.0 compose check report

On Thu, 2016-06-02 at 14:28 +, Fedora compose checker wrote:
> Missing expected images:
> 
> Kde live i386
> Kde live x86_64
> Cloud_base raw-xz i386
> 
> Failed openQA tests: 3/70 (x86_64), 2/16 (i386), 1/2 (arm)
> 
> ID: 20162 Test: x86_64 Workstation-live-iso install_default@uefi
> URL: https://openqa.fedoraproject.org/tests/20162

This is kind of an interesting one I haven't managed to look into yet:
I think what's going on is that initial-setup is not behaving as
expected because there's no network connection, but I haven't worked
out why there's no network connection yet. Will look into it when I
can.

> ID: 20173 Test: arm Minimal-raw_xz-raw.xz base_services_start_arm
> URL: https://openqa.fedoraproject.org/tests/20173

We think this is just due to the console login code not waiting long
enough on ARM (ARM tests are very slow as they run in software
emulation).

> ID: 20212 Test: x86_64 universal install_scsi_updates_img
> URL: https://openqa.fedoraproject.org/tests/20212

This is the intermittent Python crash we hit every so often.

> ID: 20232 Test: x86_64 universal install_cyrillic_language
> URL: https://openqa.fedoraproject.org/tests/20232

This is a test bug (missing a needle for 'user qwerty logged in'), will
fix that. Should be passing.

> ID: 20235 Test: i386 universal install_package_set_minimal
> URL: https://openqa.fedoraproject.org/tests/20235

This is some kind of weird bug that happens every so often, where way
too much text gets typed into the root password confirmation dialog.
Now I look at it it's actually a bit strange because usually these bugs
are caused when a timing issue with the test actions means some text
destined for one place is typed into another, but there's really no
possibility of that at the relevant point, so I don't know where the
extra characters are *coming* from - it's possible it may even be a
valid anaconda bug. But it's a tricky one to investigate so it'll need
to wait till someone has time.

> ID: 20243 Test: i386 universal upgrade_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/20243

This is the good ol' kernel-PAE / kernel issue that's been around for a
while, https://bugzilla.redhat.com/show_bug.cgi?id=1333591 .
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
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

2016-06-02 Thread Stephen Gallagher

On 06/02/2016 11:01 AM, Ray Strode wrote:
> Hi,
> 
> On Wed, Jun 1, 2016 at 10:58 AM, Matthias Clasen  wrote:
>> 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.
> 
> This is definitely true. It's a class of bug that's hit us over and
> over again. (in addition to gconf, ibus, and pulseaudio above, you
> could add bonobo-activation-server, evolution-data-server, gam_server
> off the top of my head).  The problem is that background services
> don't generally take display connections, since they don't need to
> display anything.  So they don't die when the display goes away.
> 
> We tried to fix this a long time ago with the introduction of dbus
> into the desktop.  The idea was the session dbus-daemon daemon would
> define the scope of the session, and services would grab a bus
> connection if they wanted to be scoped to the session.
> 
> Of course, starting in Fedora 24, we no longer have a session bus.
> It's a user bus now.  So the bus won't go away until the last user
> session (for a user) ends, and those background services won't go away
> until they lose their bus connections, since they still rely on
> dbus-daemon to cut the cord when the session ends.  While those
> background services are waiting for their bus connection to disappear,
> they're keeping the session alive (but in a "closing" state).
> 
> To me, KillUserProcesses=yes is better from a theoretical
> it-should-have-always-done-this-if-it-could-have standpoint, and it's
> better from real world
> it-eliminates-a-class-of-bugs-that-has-plagued-us standpoint.
> 
> I don't like that it requires users to have to change workflows, so
> that's a negative and I understand why the change is controversial.
> 
> We may want to consider reverting the user bus change for F24 and
> revisit in F25, not sure.
> 

I don't think we need to change Fedora 24 for this. Unless I misunderstood, this
systemd change has not been pushed to Fedora 24 (nor proposed for it). We're
prepping for how to deal with things in Fedora 25.

So to Smooge's point, I think we should leave this as-is and avoid any new
fallout during Final Freeze. We have months to address things in Fedora 25.



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

[Bug 1339835] perl-DBIx-RunSQL: 0.14 release available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DBIx-RunSQL-0.14-1.fc2 |perl-DBIx-RunSQL-0.14-1.fc2
   |4   |4
   |perl-DBIx-RunSQL-0.14-1.fc2 |perl-DBIx-RunSQL-0.14-1.fc2
   |2   |2
   ||perl-DBIx-RunSQL-0.14-1.fc2
   ||3



-- 
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 1339669] Please update perl-libintl to 1.22 or later for Fedora 23

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



--- Comment #4 from Fedora Update System  ---
perl-libintl-1.24-1.fc23 has been pushed to the Fedora 23 stable repository. If
problems still persist, please make note of it in this bug report.

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

[Bug 1339669] Please update perl-libintl to 1.22 or later for Fedora 23

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-libintl-1.24-1.fc23
 Resolution|--- |ERRATA
Last Closed||2016-06-02 10:56:17



-- 
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 1339024] perl-Lingua-Translit-0.26 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Lingua-Translit-0.26-1 |perl-Lingua-Translit-0.26-1
   |.fc24   |.fc24
   |perl-Lingua-Translit-0.26-1 |perl-Lingua-Translit-0.26-1
   |.fc22   |.fc22
   ||perl-Lingua-Translit-0.26-1
   ||.fc23



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

On 2 June 2016 at 11:01, Ray Strode  wrote:
> Hi,
>


>
> We may want to consider reverting the user bus change for F24 and
> revisit in F25, not sure.

I believe we are less than a week from releasing F24... if there is a
need to do this how far back does testing need to go? Are we back to
alpha? beta? gamma?

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



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

[Bug 1339024] perl-Lingua-Translit-0.26 is available

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



--- Comment #18 from Fedora Update System  ---
perl-Lingua-Translit-0.26-1.fc23 has been pushed to the Fedora 23 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1339835] perl-DBIx-RunSQL: 0.14 release available

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



--- Comment #13 from Fedora Update System  ---
perl-DBIx-RunSQL-0.14-1.fc23 has been pushed to the Fedora 23 stable
repository. If problems still persist, please make note of it in this bug
report.

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

Re: systemd 230 change - KillUserProcesses defaults to yes

2016-06-02 Thread Ray Strode

Hi,

On Wed, Jun 1, 2016 at 10:58 AM, Matthias Clasen  wrote:
> 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.

This is definitely true. It's a class of bug that's hit us over and
over again. (in addition to gconf, ibus, and pulseaudio above, you
could add bonobo-activation-server, evolution-data-server, gam_server
off the top of my head).  The problem is that background services
don't generally take display connections, since they don't need to
display anything.  So they don't die when the display goes away.

We tried to fix this a long time ago with the introduction of dbus
into the desktop.  The idea was the session dbus-daemon daemon would
define the scope of the session, and services would grab a bus
connection if they wanted to be scoped to the session.

Of course, starting in Fedora 24, we no longer have a session bus.
It's a user bus now.  So the bus won't go away until the last user
session (for a user) ends, and those background services won't go away
until they lose their bus connections, since they still rely on
dbus-daemon to cut the cord when the session ends.  While those
background services are waiting for their bus connection to disappear,
they're keeping the session alive (but in a "closing" state).

To me, KillUserProcesses=yes is better from a theoretical
it-should-have-always-done-this-if-it-could-have standpoint, and it's
better from real world
it-eliminates-a-class-of-bugs-that-has-plagued-us standpoint.

I don't like that it requires users to have to change workflows, so
that's a negative and I understand why the change is controversial.

We may want to consider reverting the user bus change for F24 and
revisit in F25, not sure.

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

2016-06-02 Thread Gerd Hoffmann

  Hi,

> In all of these cases you really want to make sure that whatever the
> user did ends – really ends – by the time he logs out.

Sure, there are valid use cases for that.  The admin will probably also
turn off lingering then, right?

So, what is problem with simply allowing screen + tmux continue to run
in case lingering is enabled, by simply letting the usual SIGHUP logic
do it's job for processes which have a controlling terminal?

cheers,
  Gerd

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

[Bug 1342160] perl-BSSolv-0.01-11.git1e18c32.fc25 FTBFS: BSSolv.xs:19:22: fatal error: repo_deb.h: No such file or directory

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ignate...@redhat.com
  Flags||needinfo?(ignatenko@redhat.
   ||com)



--- Comment #1 from Petr Pisar  ---
Igor, disabling support for Debian repositories in libsolv was intentional?

-- 
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 1342160] New: perl-BSSolv-0.01-11.git1e18c32.fc25 FTBFS: BSSolv.xs:19 :22: fatal error: repo_deb.h: No such file or directory

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

Bug ID: 1342160
   Summary: perl-BSSolv-0.01-11.git1e18c32.fc25 FTBFS:
BSSolv.xs:19:22: fatal error: repo_deb.h: No such file
or directory
   Product: Fedora
   Version: rawhide
 Component: perl-BSSolv
  Assignee: strzi...@gmail.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, strzi...@gmail.com



perl-BSSolv-0.01-11.git1e18c32.fc25 fails to build in F25:

+ make -j4
Running Mkbootstrap for BSSolv ()
"/usr/bin/perl" "/usr/share/perl5/vendor_perl/ExtUtils/xsubpp"  -typemap
'/usr/share/perl5/ExtUtils/typemap' -typemap
'/builddir/build/BUILD/perl-BSSolv-0.01/typemap'  BSSolv.xs > BSSolv.xsc
chmod 644 "BSSolv.bs"
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- BSSolv.bs
blib/arch/auto/BSSolv/BSSolv.bs 644
cp BSSolv.pm blib/lib/BSSolv.pm
mv BSSolv.xsc BSSolv.c
gcc -c  -I/usr/include/solv -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64
-mtune=generic -fwrapv -fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g   -DVERSION=\"0.01\"
-DXS_VERSION=\"0.01\" -fPIC "-I/usr/lib64/perl5/CORE"   BSSolv.c
BSSolv.xs:19:22: fatal error: repo_deb.h: No such file or directory
 #include "repo_deb.h"
  ^
compilation terminated.
Makefile:334: recipe for target 'BSSolv.o' failed

Difference between working and failing build root is:

libsolv-devel 0.6.21-1.fc25 > 0.6.21-2.fc25
libsolv 0.6.21-1.fc25 > 0.6.21-2.fc25
curl 7.49.0-1.fc25 > 7.49.1-1.fc25
python3-setuptools 20.9.0-1.fc25 > 21.2.2-1.fc25
shadow-utils 2:4.2.1-9.fc25 > 2:4.2.1-10.fc25
libcurl 7.49.0-1.fc25 > 7.49.1-1.fc25

This is probably caused by libsolve change

"Modify enabled/disabled features".

-- 
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 1339024] perl-Lingua-Translit-0.26 is available

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



--- Comment #17 from Fedora Update System  ---
perl-Lingua-Translit-0.26-1.fc22 has been pushed to the Fedora 22 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1339835] perl-DBIx-RunSQL: 0.14 release available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DBIx-RunSQL-0.14-1.fc2 |perl-DBIx-RunSQL-0.14-1.fc2
   |4   |4
   ||perl-DBIx-RunSQL-0.14-1.fc2
   ||2



-- 
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 1339024] perl-Lingua-Translit-0.26 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Lingua-Translit-0.26-1 |perl-Lingua-Translit-0.26-1
   |.fc24   |.fc24
   ||perl-Lingua-Translit-0.26-1
   ||.fc22



-- 
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 1339835] perl-DBIx-RunSQL: 0.14 release available

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



--- Comment #12 from Fedora Update System  ---
perl-DBIx-RunSQL-0.14-1.fc22 has been pushed to the Fedora 22 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1331527] Please build perl-Data-Password for EPEL

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

Xavier Bachelot  changed:

   What|Removed |Added

  Flags||needinfo?(andr...@bawue.net
   ||)



--- Comment #1 from Xavier Bachelot  ---
Hi,

I've requested the EPEL 6 and 7 branches, please approve :
https://admin.fedoraproject.org/pkgdb/package/requests/5804
https://admin.fedoraproject.org/pkgdb/package/requests/5805

Regards,
Xavier

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

On Thu, 2016-06-02 at 13:04 +0200, Lennart Poettering wrote:
> On Wed, 01.06.16 07:20, Adam Williamson (adamw...@fedoraproject.org) wrote:
> 
> > On Wed, 2016-06-01 at 15:48 +0200, Lennart Poettering wrote:
> > > 
> > > 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.
> > 
> > I don't think you've yet explained exactly why this constitutes a
> > 'security problem'. Could you please do so?
> 
> Well. Let's say you are responsible for the Linux desktops of a large
> security-senstive company (let's say bank, whatever), and the desktops
> are installed as fixed workstations, which different employees using
> them at different times. They log in, they do some "important company
> stuff", and then they log out again. Now, it's a large company, so it
> doesn't have the closest control on every single employee, and
> sometimes employees leave the company. Sometimes even the employees
> browse to the wrong web sites, catch a browser exploit and suddenly
> start runing spam bots under their user identity, without even
> knowing.

These are all bad things, yes. Yet there is a large logic gap right here.

> In all of these cases you really want to make sure that whatever the
> user did ends – really ends – by the time he logs out.

Er...why? Why is it OK for the employee to be running malicious code
(spambots, rootkits, whatever you like) just so long as they're logged
in? How is making sure the evil code only runs while the employee is
logged in helping in any significant way?

>  So that the
> employee can't do stuff there except when logged in, and that he can't
> do stuff there even long after he left the company, and that the spam
> bot he caught gets killed as soon as he logs out.

I guess a spambot that only runs 9-5 is slightly better than one that
runs 24x7, but it hardly seems like the ideal fix for the problem. As
for 'after he left the company', well, killing everyone's processes
every time they log out is an awfully large hammer to solve the problem
of killing someone's processes the *one time* they leave the company.

> This is really just one example. This model I think really needs to be
> the default everywhere. On desktops and on servers: unless the admin
> permitted it explicitly, there should not be user code running. If you
> allow your intern user access to a webserver to quickly check our the
> resource consumption of some service that doesn't mean that he shall
> be allowed to run stuff there forever, just because he once had the
> login privilege for the server. And even more: after you disabled his
> user account and logged him out, he really should be gone.
> 
> Yes, UNIX is pretty much a swiss cheese: it's really hard to secure a
> system properly so that somebody who once had access won't have access
> anymore at a later point. However, we need to start somewhere, and
> actually defining a clear lifecycle is a good start.
> 
> Pretty much all more modern OS designs tend to have such a clear
> lifecycle btw: when the user is logged out, he's *really* logged
> out. And it's completely OK if certain users get excludeded from that,
> but if so, then the admin needs to sign off on that, and thus a
> privilege check needs to be enforced.

I think the design has a lot to be said for it, especially if you're
starting from scratch and don't have decades of existing expectations
and workflows to deal with. But I'm not hugely convinced by the
'security' aspect of it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
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

2016-06-02 Thread Gerd Hoffmann

On Do, 2016-06-02 at 10:07 -0400, Matthias Clasen wrote:
> On Thu, 2016-06-02 at 10:02 -0400, Paul Wouters wrote:
> > 
> > People aren't agreeing with you. So making it a default seems like a
> > bad
> > idea. People do seem to agree on "obviously broken windoing apps"
> > that
> > are left lingering. Why can't we just let those get killed?
> > 
> 
> You are misinformed. This is not about 'obviously broken' windowing
> apps. Applications that have X or wayland connections get killed
> reliably when the session ends, because that connection is going away.

No.

It's sort-of default behavior, a bit simliar to how terminal apps get
zapped by SIGHUP when the terminal closes.  But it isn't enforced at
all, apps can keep running when the X or wayland connection goes away,
either just a short moment (firefox saving open tabs to disk, then exit)
or even longer in case they are running some kind of batch job which
they can finish without user interaction.  Or they keep on trying to
read from the closed connection due to some stupid bug ...

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

[Bug 1342150] perl-MojoX-JSON-RPC-0.08-5.fc25 FTBFS: Can' t locate object method "is_debug" via package "Mojo::Log" at t/../lib/ MojoX/JSON/RPC/Client.pm line 106

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
External Bug ID||CPAN 114580



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

Fedora 24-20160602.n.0 compose check report

2016-06-02 Thread Fedora compose checker

Missing expected images:

Kde live i386
Kde live x86_64
Cloud_base raw-xz i386

Failed openQA tests: 3/70 (x86_64), 2/16 (i386), 1/2 (arm)

ID: 20162   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/20162
ID: 20173   Test: arm Minimal-raw_xz-raw.xz base_services_start_arm
URL: https://openqa.fedoraproject.org/tests/20173
ID: 20212   Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/20212
ID: 20232   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/20232
ID: 20235   Test: i386 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/20235
ID: 20243   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/20243

Passed openQA tests: 67/70 (x86_64), 14/16 (i386), 1/2 (arm)

-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1342150] perl-MojoX-JSON-RPC-0.08-5.fc25 FTBFS: Can' t locate object method "is_debug" via package "Mojo::Log" at t/../lib/ MojoX/JSON/RPC/Client.pm line 106

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

Petr Pisar  changed:

   What|Removed |Added

Summary|perl-MojoX-JSON-RPC-0.08-5. |perl-MojoX-JSON-RPC-0.08-5.
   |fc25 FTBFS: |fc25 FTBFS: Can't locate
   ||object method "is_debug"
   ||via package "Mojo::Log" at
   ||t/../lib/MojoX/JSON/RPC/Cli
   ||ent.pm line 106



-- 
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 1342150] New: perl-MojoX-JSON-RPC-0.08-5.fc25 FTBFS:

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

Bug ID: 1342150
   Summary: perl-MojoX-JSON-RPC-0.08-5.fc25 FTBFS:
   Product: Fedora
   Version: rawhide
 Component: perl-MojoX-JSON-RPC
  Assignee: emman...@seyman.fr
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org



perl-MojoX-JSON-RPC-0.08-5.fc25 fails to build in F25 for me because tests
fail:

+ make test
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness"
"-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')"
t/*.t t/*/*.t t/*/*/*.t
Can't locate object method "is_debug" via package "Mojo::Log" at
t/../lib/MojoX/JSON/RPC/Client.pm line 106.
# Looks like your test exited with 255 just after 2.
t/basic.t .. 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 34/36 subtests 
Can't locate object method "is_debug" via package "Mojo::Log" at
t/../lib/MojoX/JSON/RPC/Client.pm line 106.
# Looks like your test exited with 255 just after 1.
t/exception.t .. 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 2/3 subtests 
Can't locate object method "is_debug" via package "Mojo::Log" at
t/../lib/MojoX/JSON/RPC/Client.pm line 106.
# Looks like your test exited with 255 just after 1.
t/lite_app.t ... 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 1/2 subtests 

This is caused probably by upgrading perl-Mojolicious from 6.61 to 6.62.

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

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-DBIx-Class-EncodedColu
   ||mn-0.00015-1.fc25
 Resolution|--- |RAWHIDE
Last Closed||2016-06-02 10:25:24



-- 
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 1340201] Please build perl-Test-Compile for EPEL 6