Summary/Minutes from today's FESCo Meeting (2016-05-27)

[Parag Nemade]

===
#fedora-meeting: FESCO (2016-05-27)
===


Meeting started by paragan at 16:01:04 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2016-05-27/fesco.2016-05-27-16.01.log.html
.



Meeting summary
---
* init process  (paragan, 16:01:04)

* #1568  F25 Self Contained Changes  (paragan, 16:04:15)
  * LINK: https://fedorahosted.org/fesco/ticket/1568   (paragan,
16:04:15)
  * AGREED: Approved all 3 Self Contained Changes (8, 0, 0)  (paragan,
16:08:58)

* #1573 Docker Layered Image maintainer guildelines, naming guidelines
  and review  (paragan, 16:09:18)
  * LINK: https://fedorahosted.org/fesco/ticket/1573   (paragan,
16:09:19)
  * AGREED: revisit this ticket next week.  (paragan, 16:19:05)

* #1576 Evaluate Workstation graphical upgrade Change status  (paragan,
  16:19:26)
  * LINK: https://fedorahosted.org/fesco/ticket/1576   (paragan,
16:19:26)
  * AGREED: tenative plan is to have this change implemented on release
day and update it monday with further details and revisit this
ticket next meeting (6, 0, 0)  (paragan, 16:31:25)

* #1578 F25 System Wide Change: Use /etc/repos.d as default reposdir
  (paragan, 16:31:50)
  * LINK: https://fedorahosted.org/fesco/ticket/1578   (paragan,
16:31:50)
  * AGREED: revisit this ticket next week so that kalev-afk can get
feedback on this  (paragan, 16:43:56)

* #1579 F25 System Wide Change: Parallel Installable Debuginfo
  (paragan, 16:44:25)
  * LINK: https://fedorahosted.org/fesco/ticket/1579   (paragan,
16:44:26)
  * AGREED: F25 System Wide Change: Parallel Installable Debuginfo (8,
0, 0)  (paragan, 16:47:19)

* Next week's chair  (paragan, 16:48:03)
  * kalev to chair for next week meeting  (paragan, 16:49:05)

* Open Floor  (paragan, 16:49:18)

Meeting ended at 16:55:28 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* paragan (63)
* nirik (32)
* kalev-afk (30)
* maxamillion (26)
* dgilmore (26)
* zodbot (17)
* sgallagh (16)
* jsmith (13)
* number80 (3)
* kalev (0)
* jwb (0)




Generated by `MeetBot`_ 0.1.4
--
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

[Ben Rosser]

On Fri, May 27, 2016 at 1:41 PM, Rich Mattes  wrote:

> On Fri, May 27, 2016 at 12:20 PM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > On Fri, May 27, 2016 at 06:15:08PM +0200, Björn Persson wrote:
> >> Dominique Martinet  wrote:
> >> > Just noticed this change on rawhide...
> >> > https://github.com/systemd/systemd/blob/master/NEWS#L29
> >> >   * systemd-logind will now by default terminate user processes that
> are
> >> > part of the user session scope unit (session-XX.scope) when the
> user
> >> > logs out. This behavior is controlled by the KillUserProcesses=
> >> > setting in logind.conf, and the previous default of "no" is now
> >> > changed to "yes". This means that user sessions will be properly
> >> > cleaned up after, but additional steps are necessary to allow
> >> > intentionally long-running processes to survive logout.
> >>
> >> This sounds very much like a system-wide Change. Where can I find the
> >> Change proposal?
> >
> > It's not a Fedora-specific change. See the other parts of the thread
> > for links to upstream discussions (in particular the mail from Michal).
> >
>
> I don't see anything in the Changes policy[1] that limits it to
> Fedora-specific changes.  In fact, changes like this are exactly what
> the policy seems to capture:
>   "Complex system wide changes involve system-wide defaults, critical
> path components, or other changes that are not eligible as self
> contained changes."
>
> This is a system-wide default change in a critpath component, which
> qualifies twice!  But seriously, large changes in new upstream
> releases are often captured by the change process (boost updates,
> glibc and gcc updates, etc.)  Using the change process in this case
> would let us coordinate efforts and address and answer technical
> questions like "how do you indicate that you want a process to persist
> after logout," "can we/how do we modify programs that rely on this
> behavior to do the right thing (screen, tmux, etc.)," and "does it
> make sense to deviate from upstream in any fedora products," in
> addition to philosophical questions like what a "logout" really means
> or should mean, before the change landed.
>
> Rich
>
> [1] https://fedoraproject.org/wiki/Changes/Policy
> --
>

I agree; just because the change happened upstream in systemd doesn't mean
that this shouldn't be evaluated in Fedora itself before being turned on by
default.

This absolutely seems like the kind of thing that should be a system-wide
change proposal (for F25, I guess).

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

F25 Self Contained Change: Koji Generates Installation Media

[Jan Kurik]

= Proposed Self Contained Change: Koji Generates Installation Media =
https://fedoraproject.org/wiki/Changes/KojiInstallMedia

Change owner(s):
* Jay Greguske 

Extend Koji with a new feature that allows users to create
installation media for various architectures.

== Detailed Description ==
This is a significant enabler for generating DVD media, other ISOs,
and images more efficiently. It also allows other tools such as mash
or pungi to offload much of the heavy-lifting to the build system.
Longer term, we may be able to reduce the number of tools needed to
manufacture Fedora releases.

== Scope ==
Proposal owners:
* to implement this change

Release engineering:
* This feature does require coordination with release engineering
(e.g. changes to installer image generation or update package
delivery.)
-- 
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

Schedule for Friday's FESCo Meeting (2016-05-27)

[Parag Nemade]

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-05-27 16:00 UTC'


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

= Followups =

#topic #1568 F25 Self Contained Changes
.fesco 1568
https://fedorahosted.org/fesco/ticket/1568

#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

= New business =

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

#topic #1579 F25 System Wide Change: Parallel Installable Debuginfo
.fesco 1579
https://fedorahosted.org/fesco/ticket/1579

= 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

[Zbigniew Jędrzejewski-Szmek]

On Fri, May 27, 2016 at 08:51:23AM -0400, Nico Kadel-Garcia wrote:
> This breaks the storage of ssh-agent credentials for te one-time
> enabling of SSH credentials for access on running hosts. 

You mean you start ssh-agent somewhere during the first login and then
access it from any process from further sessions? You can get a setup
to work like this by running the agent in a service, like any long
running service.

> Gods alone know what else it will break.

File the bugs, we'll deal with them one at a time.

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

[Chris Adams]

Once upon a time, Tom Hughes  said:
> On 27/05/16 15:25, Chris Adams wrote:
> >When you "clean up" by killing things that are designed to run after
> >logout, you are being over-zealous.  It is incumbent upon you to fix
> >your cleanup methods to handle this case, not the thousands of users
> >to change their process to avoid your broken methods.
> 
> But that's effectively calling for the impossible - if there has
> historically been no way for things to announce that they are
> expected to remain after exit then there's no way to magically
> identify them now.
> 
> What would be good would be if screen and similar programs could
> learn to do the necessary magic automatically rather than having to
> be wrapped in systemd-run by the user.

And that's what I'm suggesting.  Before making this the default in
systemd, the systemd developers should come up with a way for processes
to make some type of notification, and then get patches into the common
things (screen and tmux at least, with freely-licensed example code for
others to use) to handle this.  Only then should the default be changed.

Flipping the switch and saying everybody has to change their behavior to
match is rude.  Working with people to transparently handle very common
work processes is much more acceptable.
-- 
Chris Adams 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora 24-20160527.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Workstation live i386
Cloud_base raw-xz x86_64
Xfce raw-xz armhfp
Cloud_base raw-xz i386
Atomic raw-xz x86_64
Minimal raw-xz armhfp
Workstation live x86_64

Failed openQA tests: 8/66 (x86_64), 4/16 (i386)

ID: 19199   Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/19199
ID: 19202   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/19202
ID: 19208   Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/19208
ID: 19211   Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/19211
ID: 19217   Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/19217
ID: 19219   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/19219
ID: 19243   Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/19243
ID: 19256   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/19256
ID: 19260   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/19260
ID: 19274   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/19274
ID: 19275   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/19275
ID: 19276   Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/19276

Passed openQA tests: 57/66 (x86_64), 12/16 (i386)

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

Re: systemd 230 change - KillUserProcesses defaults to yes

[Lennart Poettering]

On Fri, 27.05.16 08:09, Chris Adams (li...@cmadams.net) wrote:

> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > Also note that running jobs in a systemd service has advantages on the
> > server: better accounting, more transparency, logs are easier to read.
> > The (old) default of allowing left-over session processes to live on
> > seems especially bad on a server with multiple users.
> 
> Starting a one-off task under screen and detaching is an age-old server
> management process.  Breaking that is not acceptable IMHO.

And it is still supported.

In my view it was actually quite strange of UNIX that it by default
let arbitrary user code stay around unrestricted after logout. It has
been discussed for ages now among many OS people, that this should
possible but certainly not be the default, but nobody dared so far to
flip the switch to turn it from a default to an option. Not cleaning
up user sessions after logout is not only ugly and somewhat hackish
but also a security problem.

systemd 230 now finally flipped the switch and finally by default
cleans everything up correctly when the user logs out. But we do so in
a very conservative way actually:

 a) there's a compile time switch to turn this off globally
(--without-kill-user-processes, not used in Fedora)
 
 b) there's a runtime switch to turn this off locally on the system
(in logind.conf)

 c) there's a way to opt-out invidually for each user and each task
from the cleanup logic, via systemd-run/loginctl linger. This
operation goes through PK, and thus can be configured in a more
strict or more open policy, depending on whhat the admin prefers.

I am pretty sure we should consider it our duty as Fedora developers
to improve the Linux platform, and I am pretty sure that properly
cleaning up processes on logout is a step towards that, not against
it.

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Chris Adams]

Once upon a time, Lennart Poettering  said:
> I am pretty sure we should consider it our duty as Fedora developers
> to improve the Linux platform, and I am pretty sure that properly
> cleaning up processes on logout is a step towards that, not against
> it.

When you "clean up" by killing things that are designed to run after
logout, you are being over-zealous.  It is incumbent upon you to fix
your cleanup methods to handle this case, not the thousands of users
to change their process to avoid your broken methods.
-- 
Chris Adams 
--
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

[Nico Kadel-Garcia]

On Fri, May 27, 2016 at 5:51 AM, Dominique Martinet
 wrote:
> Hi,
>
> Just noticed this change on rawhide...
> https://github.com/systemd/systemd/blob/master/NEWS#L29
>   * systemd-logind will now by default terminate user processes that are
> part of the user session scope unit (session-XX.scope) when the user
> logs out. This behavior is controlled by the KillUserProcesses=
> setting in logind.conf, and the previous default of "no" is now
> changed to "yes". This means that user sessions will be properly
> cleaned up after, but additional steps are necessary to allow
> intentionally long-running processes to survive logout.
>
> While the user is logged in at least once, user@.service is running,
> and any service that should survive the end of any individual login
> session can be started at a user service or scope using systemd-run.
> systemd-run(1) man page has been extended with an example which shows
> how to run screen in a scope unit underneath user@.service. The same
> command works for tmux.
>
> After the user logs out of all sessions, user@.service will be
> terminated too, by default, unless the user has "lingering" enabled.
> To effectively allow users to run long-term tasks even if they are
> logged out, lingering must be enabled for them. See loginctl(1) for
> details. The default polkit policy was modified to allow users to
> set lingering for themselves without authentication.
>
> Previous defaults can be restored at compile time by the
> --without-kill-user-processes option to "configure".
>
>
> So, now, I've read this and I could possibly remember to use systemd-run
> or to set myself as lingering... Except that I don't want to have to go
> through the pain of remembering to either change the system config on
> all my servers or always starting stuff with systemd-run if it's a bit
> long and I think I might want to ^Z/bg/disown it to let it finish.

This breaks the storage of ssh-agent credentials for te one-time
enabling of SSH credentials for access on running hosts. Gods alone
know what else it will break.
--
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

[Zbigniew Jędrzejewski-Szmek]

On Fri, May 27, 2016 at 11:51:42AM +0200, Dominique Martinet wrote:
> Hi,
> 
> Just noticed this change on rawhide...
> https://github.com/systemd/systemd/blob/master/NEWS#L29
>   * systemd-logind will now by default terminate user processes that are
> part of the user session scope unit (session-XX.scope) when the user
> logs out. This behavior is controlled by the KillUserProcesses=
> setting in logind.conf, and the previous default of "no" is now
> changed to "yes". This means that user sessions will be properly
> cleaned up after, but additional steps are necessary to allow
> intentionally long-running processes to survive logout.
[...]

> Sure, this change will work for the whole probably targetted audience of
> simple desktop users on shared workstations where we probably want to
> kill lingering processes; but how much is that compared to servers ?
That's always debatable, but I'd say that there are orders of magnitude
more desktops than servers into which random users can log in to run jobs.
Also note that running jobs in a systemd service has advantages on the
server: better accounting, more transparency, logs are easier to read.
The (old) default of allowing left-over session processes to live on
seems especially bad on a server with multiple users.

> I know that if this gets through I will have to change the system
> default on all my servers... And while the big batches of thousands of
> compute nodes are automated there's still quite a few places to update,
> especially since this will be the first time we need to change
> logind.conf so it's not just adding a line to a file already propagated
It's two lines: [Login]\nKillUserProcesses=no. But please consider
switching to the new mode of using systemd-run instead.

Zbyszek

PS. You asked if this was discusses on systemd-devel: it was on the
bugtracker. See https://github.com/systemd/systemd/pull/3005,
and also https://bugs.freedesktop.org/show_bug.cgi?id=94508.
--
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

[Tom Hughes]

On 27/05/16 14:02, Zbigniew Jędrzejewski-Szmek wrote:


It's two lines: [Login]\nKillUserProcesses=no. But please consider
switching to the new mode of using systemd-run instead.


How do I run screen with systemd-run?

I tried "systemd-run --user -t screen" but as soon as I detach from the 
screen session it seems to get killed.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
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

[Tom Hughes]

On 27/05/16 15:25, Chris Adams wrote:

Once upon a time, Lennart Poettering  said:

I am pretty sure we should consider it our duty as Fedora developers
to improve the Linux platform, and I am pretty sure that properly
cleaning up processes on logout is a step towards that, not against
it.


When you "clean up" by killing things that are designed to run after
logout, you are being over-zealous.  It is incumbent upon you to fix
your cleanup methods to handle this case, not the thousands of users
to change their process to avoid your broken methods.


But that's effectively calling for the impossible - if there has 
historically been no way for things to announce that they are expected 
to remain after exit then there's no way to magically identify them now.


What would be good would be if screen and similar programs could learn 
to do the necessary magic automatically rather than having to be wrapped 
in systemd-run by the user.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
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

[Michal Schmidt]

On 05/27/2016 11:51 AM, Dominique Martinet wrote:
> Just noticed this change on rawhide...
> https://github.com/systemd/systemd/blob/master/NEWS#L29
>   * systemd-logind will now by default terminate user processes that are
> part of the user session scope unit (session-XX.scope) when the user
> logs out. This behavior is controlled by the KillUserProcesses=
> setting in logind.conf, and the previous default of "no" is now
> changed to "yes". This means that user sessions will be properly
> cleaned up after, but additional steps are necessary to allow
> intentionally long-running processes to survive logout.
> 
> While the user is logged in at least once, user@.service is running,
> and any service that should survive the end of any individual login
> session can be started at a user service or scope using systemd-run.
> systemd-run(1) man page has been extended with an example which shows
> how to run screen in a scope unit underneath user@.service. The same
> command works for tmux.
> 
> After the user logs out of all sessions, user@.service will be
> terminated too, by default, unless the user has "lingering" enabled.
> To effectively allow users to run long-term tasks even if they are
> logged out, lingering must be enabled for them. See loginctl(1) for
> details. The default polkit policy was modified to allow users to
> set lingering for themselves without authentication.
> 
> Previous defaults can be restored at compile time by the
> --without-kill-user-processes option to "configure".
...
> I did not see any discussion about this particular setting in the
> systemd-devel mailing list

The commit that made the change:
  https://github.com/systemd/systemd/commit/97e5530cf20
referenced two bugreports:
  https://bugs.freedesktop.org/show_bug.cgi?id=94508
  https://github.com/systemd/systemd/issues/2900

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

Re: systemd 230 change - KillUserProcesses defaults to yes

[Chris Adams]

Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> Also note that running jobs in a systemd service has advantages on the
> server: better accounting, more transparency, logs are easier to read.
> The (old) default of allowing left-over session processes to live on
> seems especially bad on a server with multiple users.

Starting a one-off task under screen and detaching is an age-old server
management process.  Breaking that is not acceptable IMHO.
-- 
Chris Adams 
--
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

[Zbigniew Jędrzejewski-Szmek]

On Fri, May 27, 2016 at 08:09:33AM -0500, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > Also note that running jobs in a systemd service has advantages on the
> > server: better accounting, more transparency, logs are easier to read.
> > The (old) default of allowing left-over session processes to live on
> > seems especially bad on a server with multiple users.
> 
> Starting a one-off task under screen and detaching is an age-old server
> management process.  Breaking that is not acceptable IMHO.

This change was done for a reason: left-over session processes
are causing real problems.
You still can start a one-off task under screen, you just need to
invoke it in one the different ways described in
https://www.freedesktop.org/software/systemd/man/systemd-run.html#Examples

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

[Zbigniew Jędrzejewski-Szmek]

On Fri, May 27, 2016 at 02:16:45PM +0100, Tom Hughes wrote:
> On 27/05/16 14:02, Zbigniew Jędrzejewski-Szmek wrote:
> 
> >It's two lines: [Login]\nKillUserProcesses=no. But please consider
> >switching to the new mode of using systemd-run instead.
> 
> How do I run screen with systemd-run?
> 
> I tried "systemd-run --user -t screen" but as soon as I detach from
> the screen session it seems to get killed.

See https://www.freedesktop.org/software/systemd/man/systemd-run.html#Examples
(example 5).

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

[Chris Adams]

Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> You still can start a one-off task under screen, you just need to
> invoke it in one the different ways described in
> https://www.freedesktop.org/software/systemd/man/systemd-run.html#Examples

This should not be made a default unless programs like screen can be
modified to notify systemd directly not to kill them.  Another popular
use for screen is to not lose a session due to an accidental disconnect;
having to change the way you run screen _every time_ is not acceptable.
-- 
Chris Adams 
--
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

[Tom Hughes]

On 27/05/16 14:19, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, May 27, 2016 at 02:16:45PM +0100, Tom Hughes wrote:

On 27/05/16 14:02, Zbigniew Jędrzejewski-Szmek wrote:


It's two lines: [Login]\nKillUserProcesses=no. But please consider
switching to the new mode of using systemd-run instead.


How do I run screen with systemd-run?

I tried "systemd-run --user -t screen" but as soon as I detach from
the screen session it seems to get killed.


See https://www.freedesktop.org/software/systemd/man/systemd-run.html#Examples
(example 5).


Which works fine except that the scope remains even after the screen has 
exited... Well that and it's a pain to alias screen to that because you 
only want to do it when it will be starting a new session. That can be 
solved with a bit of hackery though ;-)


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
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

[Zbigniew Jędrzejewski-Szmek]

On Fri, May 27, 2016 at 03:26:45PM +0100, Tom Hughes wrote:
> On 27/05/16 14:19, Zbigniew Jędrzejewski-Szmek wrote:
> >On Fri, May 27, 2016 at 02:16:45PM +0100, Tom Hughes wrote:
> >>On 27/05/16 14:02, Zbigniew Jędrzejewski-Szmek wrote:
> >>
> >>>It's two lines: [Login]\nKillUserProcesses=no. But please consider
> >>>switching to the new mode of using systemd-run instead.
> >>
> >>How do I run screen with systemd-run?
> >>
> >>I tried "systemd-run --user -t screen" but as soon as I detach from
> >>the screen session it seems to get killed.
> >
> >See 
> >https://www.freedesktop.org/software/systemd/man/systemd-run.html#Examples
> >(example 5).
> 
> Which works fine except that the scope remains even after the screen
> has exited...
Hm, it shouldn't I think. Seems to work fine here. How
are you running the command and what exactly remains behind?

> Well that and it's a pain to alias screen to that
> because you only want to do it when it will be starting a new
> session. That can be solved with a bit of hackery though ;-)

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

Fedora 24 compose report: 20160527.n.0 changes

[Fedora Branched Report]

OLD: Fedora-24-20160526.n.1
NEW: Fedora-24-20160527.n.0

= SUMMARY =
Added images:10
Dropped images:  6
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0.00 B
Size of dropped packages:0.00 B
Size of upgraded packages:   0.00 B
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   0.00 B
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =
Image: Xfce live x86_64
Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-24-20160527.n.0.iso
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-24-20160527.n.0.iso
Image: Mate live i386
Path: Spins/i386/iso/Fedora-MATE_Compiz-Live-i386-24-20160527.n.0.iso
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-24-20160527.n.0.iso
Image: Security live i386
Path: Labs/i386/iso/Fedora-Security-Live-i386-24-20160527.n.0.iso
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-24-20160527.n.0.iso
Image: Astronomy_KDE live i386
Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-24-20160527.n.0.iso
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-24-20160527.n.0.iso
Image: Xfce live i386
Path: Spins/i386/iso/Fedora-Xfce-Live-i386-24-20160527.n.0.iso
Image: SoaS live i386
Path: Spins/i386/iso/Fedora-SoaS-Live-i386-24-20160527.n.0.iso

= DROPPED IMAGES =
Image: LXDE live x86_64
Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-24-20160526.n.1.iso
Image: Cinnamon live i386
Path: Spins/i386/iso/Fedora-Cinnamon-Live-i386-24-20160526.n.1.iso
Image: Atomic vagrant-virtualbox x86_64
Path: 
CloudImages/x86_64/images/Fedora-Atomic-Vagrant-24-20160526.n.1.x86_64.vagrant-virtualbox.box
Image: Atomic vagrant-libvirt x86_64
Path: 
CloudImages/x86_64/images/Fedora-Atomic-Vagrant-24-20160526.n.1.x86_64.vagrant-libvirt.box
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-24-20160526.n.1.iso
Image: LXDE live i386
Path: Spins/i386/iso/Fedora-LXDE-Live-i386-24-20160526.n.1.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
Broken deps for armhfp
--
[IBSimu]
IBSimu-1.0.5-11.b.fc23.armv7hl requires libgsl.so.0
[IQmol]
IQmol-2.3.0-9.fc24.armv7hl requires libOpenMeshCore.so.3.2
IQmol-2.3.0-9.fc24.armv7hl requires libboost_iostreams.so.1.58.0
IQmol-2.3.0-9.fc24.armv7hl requires libboost_serialization.so.1.58.0
[ape]
ape-2.2.0-2.fc22.armv7hl requires libgsl.so.0
[coot]
coot-0.8.2-1.fc24.armv7hl requires libgsl.so.0
[copr-backend]
copr-backend-1.82-1.fc24.noarch requires logstash
[eclipse-jbosstools]
eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires 
osgi(org.eclipse.tm.terminal)
eclipse-jbosstools-common-4.2.2-1.fc22.noarch requires 
osgi(org.eclipse.core.runtime.compatibility)
[ghc-hakyll]
ghc-hakyll-4.5.4.0-7.fc24.armv7hl requires 
ghc(pandoc-1.13.2-5daa6928a0f3f238eb06eedacf1dc959)
ghc-hakyll-4.5.4.0-7.fc24.armv7hl requires 
ghc(pandoc-citeproc-0.7.4-97833e501509af64400c86e487e01c90)
ghc-hakyll-4.5.4.0-7.fc24.armv7hl requires 
libHShighlighting-kate-0.5.11.1-ghc7.8.4.so
ghc-hakyll-4.5.4.0-7.fc24.armv7hl requires 
libHSpandoc-1.13.2-ghc7.8.4.so
ghc-hakyll-4.5.4.0-7.fc24.armv7hl requires 
libHSpandoc-citeproc-0.7.4-ghc7.8.4.so
ghc-hakyll-4.5.4.0-7.fc24.armv7hl requires 
libHSpandoc-types-1.12.4.1-ghc7.8.4.so
ghc-hakyll-4.5.4.0-7.fc24.armv7hl requires 
libHStexmath-0.8.0.1-ghc7.8.4.so
ghc-hakyll-devel-4.5.4.0-7.fc24.armv7hl requires 
ghc-devel(pandoc-1.13.2-5daa6928a0f3f238eb06eedacf1dc959)
ghc-hakyll-devel-4.5.4.0-7.fc24.armv7hl requires 
ghc-devel(pandoc-citeproc-0.7.4-97833e501509af64400c86e487e01c90)
[ghmm]
ghmm-0.7-12.svn2286.fc22.armv7hl requires libgsl.so.0
[gnome-software]
gnome-software-3.20.2-2.fc24.armv7hl requires libxdg-app.so.0
[golang-github-kraman-libcontainer]
golang-github-kraman-libcontainer-devel-0-0.7.gitd700e5b.fc24.noarch 
requires golang(github.com/docker/docker/pkg/netlink)
[golang-github-kubernetes-heapster]
golang-github-kubernetes-heapster-devel-0.16.1-3.fc24.noarch requires 
golang(github.com/google/cadvisor/client)
golang-github-kubernetes-heapster-devel-0.16.1-3.fc24.noarch requires 
golang(github.com/google/cadvisor/info/v1)
[golang-github-samalba-dockerclient]
golang-github-samalba-dockerclient-devel-0-0.3.gitc37a52f.fc24.noarch 
requires golang(github.com/docker/docker/pkg/timeutils)
[js-of-ocaml]
js-of-ocaml-2.4-8.fc23.armv7hl requires ocaml(Lwt) = 
0:6f62eda62952a3e464e9c34a825cf0de
js-of-ocaml-2.4-8.fc23.armv7hl requires ocaml(Lwt_list) = 
0:0ce891783d3177cd33ebd9ed60d4b62d
js-of-ocaml-2.4-8.fc23.armv7hl requires ocaml(runtime) = 0:4.02.2
[leksah-server

systemd 230 change - KillUserProcesses defaults to yes

[Dominique Martinet]

Hi,

Just noticed this change on rawhide...
https://github.com/systemd/systemd/blob/master/NEWS#L29
  * systemd-logind will now by default terminate user processes that are
part of the user session scope unit (session-XX.scope) when the user
logs out. This behavior is controlled by the KillUserProcesses=
setting in logind.conf, and the previous default of "no" is now
changed to "yes". This means that user sessions will be properly
cleaned up after, but additional steps are necessary to allow
intentionally long-running processes to survive logout.

While the user is logged in at least once, user@.service is running,
and any service that should survive the end of any individual login
session can be started at a user service or scope using systemd-run.
systemd-run(1) man page has been extended with an example which shows
how to run screen in a scope unit underneath user@.service. The same
command works for tmux.

After the user logs out of all sessions, user@.service will be
terminated too, by default, unless the user has "lingering" enabled.
To effectively allow users to run long-term tasks even if they are
logged out, lingering must be enabled for them. See loginctl(1) for
details. The default polkit policy was modified to allow users to
set lingering for themselves without authentication.

Previous defaults can be restored at compile time by the
--without-kill-user-processes option to "configure".


So, now, I've read this and I could possibly remember to use systemd-run
or to set myself as lingering... Except that I don't want to have to go
through the pain of remembering to either change the system config on
all my servers or always starting stuff with systemd-run if it's a bit
long and I think I might want to ^Z/bg/disown it to let it finish.

Thinking further when my users get that update I don't see myself
telling them to do that when they want to start a screen/tmux/nohup-job,
users do not read every update changelogs (tbh I don't either unless
there's a problem); and they probably wouldn't think of systemd if they
ever get that particular issue.. heck they probably don't even know what
systemd and logind are (even if yes, they are "advanced" enough to ssh
into other servers to run *long* tasks that must continue overnight/when
the user logs out ; it doesn't mean they know what they're using
exactly)


Sure, this change will work for the whole probably targetted audience of
simple desktop users on shared workstations where we probably want to
kill lingering processes; but how much is that compared to servers ?


I know that if this gets through I will have to change the system
default on all my servers... And while the big batches of thousands of
compute nodes are automated there's still quite a few places to update,
especially since this will be the first time we need to change
logind.conf so it's not just adding a line to a file already propagated



Anyway, I don't really want to start (yet) a(nother) troll on systemd, I
appreciate it's also brought good things; I'd just like the default
values to be sane for most of the users.
I did not see any discussion about this particular setting in the
systemd-devel mailing list so I have hope that it is still open to
change, but I'd rather start with a community where there are more
admins who will likely agree that this change will do more harm than
good.

Even if nothing comes out of it, at least more people will be aware of
the issue and will be able to prepare to avoid most of the chaos that
will come if this stays like this...


Thanks for reading,
-- 
Dominique Martinet
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Packages to be Retired because of Broken Dependencies (2016-05-27)

[opensource]

The following packages have broken dependencies and will be retired
on 2016-05-31 (Final Freeze for Fedora 24) unless someone fixes them. If you
know for sure that the package should be retired, please do so now with a
proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please fix the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

  Package(co)maintainers  Status Change 
===
IBSimu stevetraylen   13 weeks ago  
IQmol  jussilehtola   13 weeks ago  
apejussilehtola   13 weeks ago  
cadvisor   jchaloup, eparis, golang-  13 weeks ago  
   sig, lsm5, vbatts
coot   timfenn13 weeks ago  
copr-backend   msuchy, frostyx, praiskup  13 weeks ago  
eclipse-jbosstools marcusk, galileo, goldmann,13 weeks ago  
   group::eclipse-sig   
ghc-hakyll petersen, haskell-sig, 13 weeks ago  
   mathstuf 
ghmm   mycae  13 weeks ago  
gnome-software rhughes, group::gnome-sig, 13 weeks ago  
   kalev, vicodan   
golang-github-kraman-  fpokorny, golang-sig,  13 weeks ago  
libcontainer   jchaloup, lsm5   
golang-github-kubernetes-  fpokorny, jchaloup 13 weeks ago  
heapster
golang-github-samalba- fpokorny, golang-sig,  13 weeks ago  
dockerclient   jchaloup 
js-of-ocamlscottt 13 weeks ago  
leksah-server  petersen, haskell-sig  13 weeks ago  
lv2-fil-pluginsbsjones13 weeks ago  
pdf-stapleraarem, raphgro 13 weeks ago  
python-gbpclient   apevec, rkukura13 weeks ago  
razorqttieugene, heliocastro, 13 weeks ago  
   ttorling 
riak   peter, erlang-sig  13 weeks ago  
source-to-imagehumaton, jchaloup, mfojtik 13 weeks ago  
ugene  yalgaer13 weeks ago  
vdsm   fsimonce, agk, bronhaim,   13 weeks ago  
   danken, dougsland, group 
   ::virtmaint-sig  
xmms-scrobbler ixs13 weeks ago  

The following packages require above mentioned packages:
Affected (co)maintainers
aarem: pdf-stapler
agk: vdsm
apevec: python-gbpclient
bronhaim: vdsm
bsjones: lv2-fil-plugins
danken: vdsm
dougsland: vdsm
eparis: cadvisor
erlang-sig: riak
fpokorny: golang-github-samalba-dockerclient, 
golang-github-kubernetes-heapster, golang-github-kraman-libcontainer
frostyx: copr-backend
fsimonce: vdsm
galileo: eclipse-jbosstools
golang-sig: golang-github-samalba-dockerclient, cadvisor, 
golang-github-kraman-libcontainer
goldmann: eclipse-jbosstools
group::eclipse-sig: eclipse-jbosstools
group::gnome-sig: gnome-software
group::virtmaint-sig: vdsm
haskell-sig: leksah-server, ghc-hakyll
heliocastro: razorqt
humaton: source-to-image
ixs: xmms-scrobbler
jchaloup: golang-github-samalba-dockerclient, 
golang-github-kubernetes-heapster, source-to-image, cadvisor, 
golang-github-kraman-libcontainer
jussilehtola: IQmol, ape
kalev: gnome-software
lsm5: cadvisor, golang-github-kraman-libcontainer
marcusk: eclipse-jbosstools
mathstuf: ghc-hakyll
mfojtik: source-to-image
msuchy: copr-backend
mycae: ghmm
peter: riak
petersen: leksah-server, ghc-hakyll
praiskup: copr-backend
raphgro: pdf-stapler
rhughes: gnome-software
rkukura: python-gbpclient
scottt: js-of-ocaml
stevetraylen: IBSimu
tieugene: razorqt
timfenn: coot
ttorling: razorqt
vbatts: cadvisor
vicodan: gnome-software
yalgaer: ugene

With broken deps (branched) (24): ape cadvisor coot copr-backend
eclipse-jbosstools ghc-hakyll ghmm gnome-software
golang-github-kraman-libcontainer
golang-github-kubernetes-heapster
golang-github-samalba-dockerclient IBSimu 

Re: Packages to be Retired because of Broken Dependencies (2016-05-27)

[Kalev Lember]

On 05/27/2016 10:53 AM, opensou...@till.name wrote:
> The following packages have broken dependencies and will be retired
> on 2016-05-31 (Final Freeze for Fedora 24) unless someone fixes them. If you
> know for sure that the package should be retired, please do so now with a
> proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

> gnome-software rhughes, group::gnome-sig, 13 weeks ago  
>kalev, vicodan   

This is just a temporary snafu; xdg-app got retired a bit too early.
Should be fixed after next F24 stable push, hopefully by tomorrow, when
https://bodhi.fedoraproject.org/updates/FEDORA-2016-8a483bb84c goes stable.

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

jdeparser license changes

[gil]

Hi

jdeparser package changes from (CDDL or GPLv2 with exceptions) and MIT 
to ASL 2.0


regards

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

[Tom Hughes]

On 27/05/16 15:48, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, May 27, 2016 at 03:26:45PM +0100, Tom Hughes wrote:
>
>> Which works fine except that the scope remains even after the screen
>> has exited...
>
> Hm, it shouldn't I think. Seems to work fine here. How
> are you running the command and what exactly remains behind?

So I'm trying this in F23 currently, so F24 might be different, but basically I 
did:

systemd-run --scope --user /bin/screen

and got a scope like this:

% systemctl --user status run-17952.scope
● run-17952.scope - /bin/screen
   Loaded: loaded (/run/user/2067/systemd/user/run-17952.scope; static; vendor 
preset: enabled)
  Drop-In: /run/user/2067/systemd/user/run-17952.scope.d
   └─50-Description.conf
   Active: active (running) since Fri 2016-05-27 16:01:41 BST; 33s ago
   CGroup: /user.slice/user-2067.slice/user@2067.service/run-17952.scope
   ├─17952 /bin/screen
   ├─17953 /bin/SCREEN
   └─17954 /bin/zsh

then hit ctrl-D to exit screen and was left with:

% systemctl --user status run-17952.scope
● run-17952.scope - /bin/screen
   Loaded: loaded (/run/user/2067/systemd/user/run-17952.scope; static; vendor 
preset: enabled)
  Drop-In: /run/user/2067/systemd/user/run-17952.scope.d
   └─50-Description.conf
   Active: active (running) since Fri 2016-05-27 16:01:41 BST; 39s ago

Tom

-- 
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
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

[Tom Hughes]

On 27/05/16 16:04, Tom Hughes wrote:

On 27/05/16 15:48, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, May 27, 2016 at 03:26:45PM +0100, Tom Hughes wrote:


Which works fine except that the scope remains even after the screen
has exited...


Hm, it shouldn't I think. Seems to work fine here. How
are you running the command and what exactly remains behind?


So I'm trying this in F23 currently, so F24 might be different, but basically I 
did:


Confirmed the same in rawhide - the scope now has a hash in the name 
instead of a number but otherwise the same behaviour.


Note that there is a systemd update pending in rawhide but it has broken 
dependencies.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
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

[Zbigniew Jędrzejewski-Szmek]

On Fri, May 27, 2016 at 09:36:58AM -0500, Chris Adams wrote:
> Once upon a time, Tom Hughes  said:
> > On 27/05/16 15:25, Chris Adams wrote:
> > >When you "clean up" by killing things that are designed to run after
> > >logout, you are being over-zealous.  It is incumbent upon you to fix
> > >your cleanup methods to handle this case, not the thousands of users
> > >to change their process to avoid your broken methods.
> > 
> > But that's effectively calling for the impossible - if there has
> > historically been no way for things to announce that they are
> > expected to remain after exit then there's no way to magically
> > identify them now.
> > 
> > What would be good would be if screen and similar programs could
> > learn to do the necessary magic automatically rather than having to
> > be wrapped in systemd-run by the user.
> 
> And that's what I'm suggesting.  Before making this the default in
> systemd, the systemd developers should come up with a way for processes
> to make some type of notification, and then get patches into the common
> things (screen and tmux at least, with freely-licensed example code for
> others to use) to handle this.  Only then should the default be changed.

https://github.com/tmux/tmux/issues/428
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora lists From munging/DMARC (Was: audio problems)

[Chris Adams]

Once upon a time, Andrew Lutomirski  said:
> Unfortunately, gmail and others are blazing ahead with breaking
> everything before ARC will be ready.

To be fair, Google is just enforcing what others ask them to enforce.
Yahoo is the one that is setting a DMARC record that says to reject
messages with bad signatures.
-- 
Chris Adams 
--
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

[Andrew Lutomirski]

On Fri, May 27, 2016 at 8:04 AM, Tom Hughes  wrote:
> On 27/05/16 15:48, Zbigniew Jędrzejewski-Szmek wrote:
>> On Fri, May 27, 2016 at 03:26:45PM +0100, Tom Hughes wrote:
>>
>>> Which works fine except that the scope remains even after the screen
>>> has exited...
>>
>> Hm, it shouldn't I think. Seems to work fine here. How
>> are you running the command and what exactly remains behind?
>
> So I'm trying this in F23 currently, so F24 might be different, but basically 
> I did:
>
> systemd-run --scope --user /bin/screen
>
> and got a scope like this:
>
> % systemctl --user status run-17952.scope
> ● run-17952.scope - /bin/screen
>Loaded: loaded (/run/user/2067/systemd/user/run-17952.scope; static; 
> vendor preset: enabled)
>   Drop-In: /run/user/2067/systemd/user/run-17952.scope.d
>└─50-Description.conf
>Active: active (running) since Fri 2016-05-27 16:01:41 BST; 33s ago
>CGroup: /user.slice/user-2067.slice/user@2067.service/run-17952.scope
>├─17952 /bin/screen
>├─17953 /bin/SCREEN
>└─17954 /bin/zsh
>
> then hit ctrl-D to exit screen and was left with:
>
> % systemctl --user status run-17952.scope
> ● run-17952.scope - /bin/screen
>Loaded: loaded (/run/user/2067/systemd/user/run-17952.scope; static; 
> vendor preset: enabled)
>   Drop-In: /run/user/2067/systemd/user/run-17952.scope.d
>└─50-Description.conf
>Active: active (running) since Fri 2016-05-27 16:01:41 BST; 39s ago
>
> Tom

Either the scope code is buggy or has IMO very strange behavior:

$ systemd-run --user --scope echo foo
Running scope as unit run-4980.scope.
foo

$ systemctl --user status run-4980.scope
● run-4980.scope - /usr/bin/echo foo
   Loaded: loaded (/run/user/1000/systemd/user/run-4980.scope; static;
vendor preset: enabled)
  Drop-In: /run/user/1000/systemd/user/run-4980.scope.d
   └─50-Description.conf
   Active: active (running) since Fri 2016-05-27 08:16:03 PDT; 14s ago

Shouldn't the default be to remove the scope when all its processes
are gone?  The manpage for systemd-run says:

   --remain-after-exit
   After the service or scope process has terminated, keep the service
   around until it is explicitly stopped. This is useful to collect
   runtime information about the service after it finished running.
   Also see RemainAfterExit= in systemd.service(5).

and I did *not* set that flag.  At the very least, the manpage
description of --scope should IMO be improved and the recommendation
to use it for long-running processes should be reconsidered.

Now let's try the service mode:

$ systemctl status --user run-5457.service
● run-5457.service - /bin/sleep 30
   Loaded: loaded (/run/user/1000/systemd/user/run-5457.service;
static; vendor preset: enabled)
  Drop-In: /run/user/1000/systemd/user/run-5457.service.d
   └─50-Description.conf, 50-ExecStart.conf
   Active: active (running) since Fri 2016-05-27 08:24:03 PDT; 5s ago
 Main PID: 5458 (sleep)
   CGroup: /user.slice/user-1000.slice/user@1000.service/run-5457.service
   └─5458 /bin/sleep 30

Then, after a while:

$ systemctl status --user run-5457.service
● run-5457.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)


Meanwhile, it's entirely unclear to me whether --scope will allow
screen to survive past when all user sessions are logged out and how
this interacts with "linger".  The linger docs are not very good IMO.


Anyway, ISTM the best fix would be for tmux and screen to learn how to
start *services* (not scopes) when they start a whole new session.

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

[Adam Williamson]

On Fri, 2016-05-27 at 15:54 +, Zbigniew Jędrzejewski-Szmek wrote:
> 
> The problem was that samba-client-libs was dependent on
> libsystemd-daemon.so, which has been replaced by libsystemd.so.
> It was recompiled on the 23rd, but it's not available in rawhide.
> Something strange is going on here.

Composes have been failing for the last few days. Packages don't reach
the repos until a compose succeeds - a 'compose' builds an entire tree
of repositories and deliverables, and syncs it to the primary mirror
when it completes, so if composes are failing, the mirrors do not get
updated.

We got a 24 compose for the first time in a few days today, so I guess
Rawhide should not be far behind.

It's easy to know when this is the case, as the 'compose report' mails
are sent to this very list...there is always a 'compose report' when a
compose completes, so if you don't see one for a few days, it means
composes are failing. The last Rawhide compose was 20160524.n.0 (which
presumably ran just too early to get the samba rebuild).
-- 
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: Fedora lists From munging/DMARC (Was: audio problems)

[Andrew Lutomirski]

On Fri, May 27, 2016 at 9:03 AM, Chris Adams  wrote:
> Once upon a time, Andrew Lutomirski  said:
>> Unfortunately, gmail and others are blazing ahead with breaking
>> everything before ARC will be ready.
>
> To be fair, Google is just enforcing what others ask them to enforce.
> Yahoo is the one that is setting a DMARC record that says to reject
> messages with bad signatures.

If we're going to be fair to Google, we need to look at a bit bigger
of a picture.  Google is well aware of these problems:

https://sites.google.com/site/oauthgoog/mlistsdkim

They proposed X-Original-Authentication-Results as a partial workaround.

Alas, they never followed through.  Google Groups, for example, sets
X-Original-Authentication-Results on forwarded messages, but Gmail is
unable to parse the header.  This doesn't even work within an
organization.  I have some aliases to my work email that are managed
through Google Apps for Domains, and valid strict DMARC emails to the
aliases get classified as spam because Gmail (for domains) doesn't
trust the X-Original-Authentication-Results header from Groups (for
domains on the same domain)!

And Google has surely known of this problem for a long time, and
they're a founding member of DMARC.  So, no, I don't think they really
get much credit here.  They allowed a bad spec to be published and
*implemented* it without bothering to make it functional, even in
their own (paid!) products.

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

[Christopher]

On Fri, May 27, 2016 at 9:58 AM Lennart Poettering 
wrote:

> On Fri, 27.05.16 08:09, Chris Adams (li...@cmadams.net) wrote:
>
> > Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > > Also note that running jobs in a systemd service has advantages on the
> > > server: better accounting, more transparency, logs are easier to read.
> > > The (old) default of allowing left-over session processes to live on
> > > seems especially bad on a server with multiple users.
> >
> > Starting a one-off task under screen and detaching is an age-old server
> > management process.  Breaking that is not acceptable IMHO.
>
> And it is still supported.
>
> In my view it was actually quite strange of UNIX that it by default
> let arbitrary user code stay around unrestricted after logout. It has
> been discussed for ages now among many OS people, that this should
> possible but certainly not be the default, but nobody dared so far to
> flip the switch to turn it from a default to an option. Not cleaning
> up user sessions after logout is not only ugly and somewhat hackish
> but also a security problem.
>
> [snip]

Apologies for a metaphor, but...

Imagine a map of a terrain, and a transparent plastic overlay containing
landmarks. Most of the time, people find it valuable to view the map with
the overlay laid on top of it. But, sometimes it's useful to remove the
overlay and look at the natural terrain. It would be a mistake to think
that the only perspective is the one with the overlay on top... and it
would be a big mistake to glue the overlay down so that particular
perspective is effectively enforced.

The "login" concept here seems to me nothing more than a conceptual overlay
of what's going on underneath (running user processes). Sure, it's a
convenient way of describing a particular experience with a computer. But,
it's not the only way to describe that experience. One could also describe
it as a a graph of arbitrary processes.

It seems to me that what's happening is that systemd is now enforcing this
"login session" perspective... metaphorically speaking, gluing the
transparent overlay onto the map (but don't worry! they also provide a
special adhesive remover!). This makes it that much harder for people to
make use of what's underneath without viewing it through the overlay...
which, as it turns out, is a *very* common thing to do (screen, tmux,
nohup, etc.).

Whether or not this as default is a good thing in the long run, I don't
know. I can see pros and cons (ease of cleanup / unexpected behavior for a
big group of folks). However, I am concerned that it seems the conceptual
perspective of a "login" is now being enforced within the internals. I
think it's a mistake to think that the internals *must* match our human
experience/understanding from the outside (the experience of a "login"
session/environment), and this change appears to be stepping in that
direction.

Perhaps one intermediate compromise is to, instead of requiring the use of
system-run, users should be able to have a whitelist of processes (like
screen, tmux, etc.) which are not killed as "cleanup". (Clearly, "screen"
is intentionally long-running, and should never be treated as "leftovers"
from a login session. I'm sure there are others which would fall under this
scenario too.)
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora 24 Final Freeze (2016-05-31)

[Dennis Gilmore]

Hi all,

Tuesday May 31st 2016 is an important day on the Fedora 24 schedule[1], with 
significant cut-offs. 

Tuesday is the Final Freeze[2]. This means that only packages which
fix accepted blocker or freeze exception bugs[3][4] will be marked as
'stable' and included in the Final composes. Other builds will remain
in updates-testing until the Final release is approved, at which point
the Final freeze is lifted and packages can move to the 'updates' repository, 
pending updates will be pushed before final release as zero day updates.

The final stable push before freeze will happen shortly after 2016-05-31 
00:00:00 Please get all updates you want included requested for stable in 
bodhi[5] before then.

Regards

Dennis

[1] https://fedoraproject.org/wiki/Releases/24/Schedule
[2] https://fedoraproject.org/wiki/Milestone_freezes
[3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[5] https://bodhi.fedoraproject.org/

signature.asc
Description: This is a digitally signed message part.
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org
--
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

[Rich Mattes]

On Fri, May 27, 2016 at 12:20 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Fri, May 27, 2016 at 06:15:08PM +0200, Björn Persson wrote:
>> Dominique Martinet  wrote:
>> > Just noticed this change on rawhide...
>> > https://github.com/systemd/systemd/blob/master/NEWS#L29
>> >   * systemd-logind will now by default terminate user processes that are
>> > part of the user session scope unit (session-XX.scope) when the user
>> > logs out. This behavior is controlled by the KillUserProcesses=
>> > setting in logind.conf, and the previous default of "no" is now
>> > changed to "yes". This means that user sessions will be properly
>> > cleaned up after, but additional steps are necessary to allow
>> > intentionally long-running processes to survive logout.
>>
>> This sounds very much like a system-wide Change. Where can I find the
>> Change proposal?
>
> It's not a Fedora-specific change. See the other parts of the thread
> for links to upstream discussions (in particular the mail from Michal).
>

I don't see anything in the Changes policy[1] that limits it to
Fedora-specific changes.  In fact, changes like this are exactly what
the policy seems to capture:
  "Complex system wide changes involve system-wide defaults, critical
path components, or other changes that are not eligible as self
contained changes."

This is a system-wide default change in a critpath component, which
qualifies twice!  But seriously, large changes in new upstream
releases are often captured by the change process (boost updates,
glibc and gcc updates, etc.)  Using the change process in this case
would let us coordinate efforts and address and answer technical
questions like "how do you indicate that you want a process to persist
after logout," "can we/how do we modify programs that rely on this
behavior to do the right thing (screen, tmux, etc.)," and "does it
make sense to deviate from upstream in any fedora products," in
addition to philosophical questions like what a "logout" really means
or should mean, before the change landed.

Rich

[1] https://fedoraproject.org/wiki/Changes/Policy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Chris Murphy]

On Fri, May 27, 2016 at 7:19 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Fri, May 27, 2016 at 08:09:33AM -0500, Chris Adams wrote:
>> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
>> > Also note that running jobs in a systemd service has advantages on the
>> > server: better accounting, more transparency, logs are easier to read.
>> > The (old) default of allowing left-over session processes to live on
>> > seems especially bad on a server with multiple users.
>>
>> Starting a one-off task under screen and detaching is an age-old server
>> management process.  Breaking that is not acceptable IMHO.
>
> This change was done for a reason: left-over session processes
> are causing real problems.
> You still can start a one-off task under screen, you just need to
> invoke it in one the different ways described in
> https://www.freedesktop.org/software/systemd/man/systemd-run.html#Examples


I have to agree, but there is a difference in expectations depending
on the system.

Fedora Workstation, I expect all processes launched by/owned by me, to
be quit on logout. Actually what I expect is by telling GNOME I'm
logging out, restarting, or shutting down, that it should send a quit
message to all applications. Those applications should be able to
interrupt this if there's unsaved data and prompt the user; but better
than this would be applications that can save their own state because
an application cancelling a reboot is archaic. But often this doesn't
work, processes continue to keep the user-session alive because they
won't stop running. So we keep seeing these problems on Fedora were
the system won't reboot for 1m30s which is the systemd timeout for
user sessions that haven't yet quit.

So it's a problem.

Fedora Server, I expect to login, run tmux, start sessions, detach,
and log out and I expect those tmux sessions to keep running. If this
workflow is going to change I need some super clean and obvious way to
know the right new way to do things or I'll just get annoyed and
cranky. Running tmux as a systemd service? I don't know how that'll
work, and I'm very skeptical that the user should get dinged with a
workflow change just because there are some stubborn programs floating
around that won't quit without delay.

It seems to  me systemd should be able to know the difference between
a program that's zombie or unresponsive but isn't doing anything or is
unresponsive but is doing something; and if not then some way for
programs to say "hey wait just a minute, I need to clean things up" or
whatever, rather than just abruptly killing them.


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

Fedora Rawhide-20160527.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Kde live i386
Server dvd i386
Server boot x86_64
Server dvd x86_64
Kde live x86_64
Cloud_base raw-xz x86_64
Cloud_base raw-xz i386
Server boot i386
Atomic raw-xz x86_64
Kde raw-xz armhfp
Minimal raw-xz armhfp

Failed openQA tests: 2/6 (x86_64), 1/1 (i386)

ID: 19280   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/19280
ID: 19281   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/19281
ID: 19286   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/19286
Skipped openQA tests: 4 of 7
-- 
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

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.20-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Data-Alias-1.20-2.fc24.i686 requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Data-Alias-1.20-2.fc24.armv7hl requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org

Broken dependencies: perl-TryCatch

[buildsys]

perl-TryCatch has broken dependencies in the rawhide tree:
On x86_64:
perl-TryCatch-1.003002-9.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-TryCatch-1.003002-9.fc24.x86_64 requires 
perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-TryCatch-1.003002-9.fc24.i686 requires libperl.so.5.22
perl-TryCatch-1.003002-9.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-TryCatch-1.003002-9.fc24.armv7hl requires libperl.so.5.22
perl-TryCatch-1.003002-9.fc24.armv7hl requires 
perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org

Re: DNF Issue, packages being incorrectly removed - was: Re: corebird

[Gerald B. Cox]

On Fri, May 27, 2016 at 11:15 AM, James Hogarth 
wrote:

> On the bug you said a dnf reinstall ... that's not the best thing to do...
> you need to dnf mark installed as per the earlier comments on the bug


Wouldn't the reinstall accomplish that?  I agree, the solution in the
release notes is concise, easy and quick - and the impact of having some
extra
packages on a system isn't that big of deal (at least not to me) - but if
you reinstall, the package would be marked as user installed wouldn't it?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: DNF Issue, packages being incorrectly removed - was: Re: corebird

[James Hogarth]

On 27 May 2016 17:29, "Gerald B. Cox"  wrote:
>
>
> On Fri, May 27, 2016 at 12:41 AM, Charalampos Stratakis <
cstra...@redhat.com> wrote:
>>
>> It is actually documented here:
https://fedoraproject.org/wiki/Common_F24_bugs#DNF_might_remove_essential_system_packages_if_you_used_PackageKit_.28GNOME_Software.2C_KDE_Apper.29_in_the_past
>>
>
>
> Thanks, I updated Bug 1259865 with this information.  People who aren't
upgrading in the near future to F24 might not see it otherwise.
>
> That was the point in my question... that yes, the issue had been fixed
going forward, but the mess still remained.  The bug report didn't have
> clear guidance.  Now it does.
>

On the bug you said a dnf reinstall ... that's not the best thing to do...
you need to dnf mark installed as per the earlier comments on the bug
--
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

[Alexander Bokovoy]

On Fri, 27 May 2016, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, May 27, 2016 at 09:05:04AM -0700, Adam Williamson wrote:

It's easy to know when this is the case, as the 'compose report' mails
are sent to this very list...there is always a 'compose report' when a
compose completes, so if you don't see one for a few days, it means
composes are failing. The last Rawhide compose was 20160524.n.0 (which
presumably ran just too early to get the samba rebuild).


Oh, I just thought that maybe we have no broken deps so no reason to
send the report :P

:) No, I was getting broken deps reports almost every day. I've rebuilt
samba couple days ago after fixing your patch so we should be fine once
composes start working. The patch also merged upstream.
--
/ Alexander Bokovoy
--
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

[Andrew Lutomirski]

On Fri, May 27, 2016 at 8:28 AM, Andrew Lutomirski  wrote:
>
> Either the scope code is buggy or has IMO very strange behavior:
>
> $ systemd-run --user --scope echo foo
> Running scope as unit run-4980.scope.
> foo
>
> $ systemctl --user status run-4980.scope
> ● run-4980.scope - /usr/bin/echo foo
>Loaded: loaded (/run/user/1000/systemd/user/run-4980.scope; static;
> vendor preset: enabled)
>   Drop-In: /run/user/1000/systemd/user/run-4980.scope.d
>└─50-Description.conf
>Active: active (running) since Fri 2016-05-27 08:16:03 PDT; 14s ago
>

I played with this a bit.  At least for now, I can get useful behavior
like this:

$ systemd-run --user --service-type=forking /bin/bash -c "/bin/sleep 20 &"
Running as unit run-7737.service.

The service will continue to exist until the whole process tree goes
away.  Shouldn't this be the *default* for --scope (and for tmux,
screen, and nohup)?

Also, ISTM someone (systemd?) should supply a really simple DSO that
programs can use to indicate their desire to create a long-running
process tree like this.
--
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

[Kevin Fenzi]

On Fri, 27 May 2016 15:54:34 +
Zbigniew Jędrzejewski-Szmek  wrote:

> The problem was that samba-client-libs was dependent on
> libsystemd-daemon.so, which has been replaced by libsystemd.so.
> It was recompiled on the 23rd, but it's not available in rawhide.
> Something strange is going on here.

It's simply that rawhide has failed to compose for the last now 4 days. 

It's being worked on... ;) 

The last issue I saw was that tmux (used by anaconda) grew a dep that
lorax removes from the install, so the installer wouldn't work. 

kevin


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

Re: systemd 230 change - KillUserProcesses defaults to yes

[Zbigniew Jędrzejewski-Szmek]

On Fri, May 27, 2016 at 04:06:36PM +0100, Tom Hughes wrote:
> On 27/05/16 16:04, Tom Hughes wrote:
> >On 27/05/16 15:48, Zbigniew Jędrzejewski-Szmek wrote:
> >>On Fri, May 27, 2016 at 03:26:45PM +0100, Tom Hughes wrote:
> >>
> >>>Which works fine except that the scope remains even after the screen
> >>>has exited...
> >>
> >>Hm, it shouldn't I think. Seems to work fine here. How
> >>are you running the command and what exactly remains behind?
> >
> >So I'm trying this in F23 currently, so F24 might be different, but 
> >basically I did:
> 
> Confirmed the same in rawhide - the scope now has a hash in the name
> instead of a number but otherwise the same behaviour.
> 
> Note that there is a systemd update pending in rawhide but it has
> broken dependencies.

The problem was that samba-client-libs was dependent on
libsystemd-daemon.so, which has been replaced by libsystemd.so.
It was recompiled on the 23rd, but it's not available in rawhide.
Something strange is going on here.

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

[Zbigniew Jędrzejewski-Szmek]

On Fri, May 27, 2016 at 09:05:04AM -0700, Adam Williamson wrote:
> It's easy to know when this is the case, as the 'compose report' mails
> are sent to this very list...there is always a 'compose report' when a
> compose completes, so if you don't see one for a few days, it means
> composes are failing. The last Rawhide compose was 20160524.n.0 (which
> presumably ran just too early to get the samba rebuild).

Oh, I just thought that maybe we have no broken deps so no reason to
send the report :P

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

[Björn Persson]

Dominique Martinet  wrote:
> Just noticed this change on rawhide...
> https://github.com/systemd/systemd/blob/master/NEWS#L29
>   * systemd-logind will now by default terminate user processes that are
> part of the user session scope unit (session-XX.scope) when the user
> logs out. This behavior is controlled by the KillUserProcesses=
> setting in logind.conf, and the previous default of "no" is now
> changed to "yes". This means that user sessions will be properly
> cleaned up after, but additional steps are necessary to allow
> intentionally long-running processes to survive logout.

This sounds very much like a system-wide Change. Where can I find the
Change proposal?

Björn Persson


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

Re: DNF Issue, packages being incorrectly removed - was: Re: corebird

[Gerald B. Cox]

On Fri, May 27, 2016 at 12:41 AM, Charalampos Stratakis  wrote:

> It is actually documented here:
> https://fedoraproject.org/wiki/Common_F24_bugs#DNF_might_remove_essential_system_packages_if_you_used_PackageKit_.28GNOME_Software.2C_KDE_Apper.29_in_the_past
>
>

Thanks, I updated Bug 1259865 with this information.  People who aren't
upgrading in the near future to F24 might not see it otherwise.

That was the point in my question... that yes, the issue had been fixed
going forward, but the mess still remained.  The bug report didn't have
clear guidance.  Now it does.
--
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

[Martin Kolman]

On Fri, 2016-05-27 at 18:15 +0200, Björn Persson wrote:
> Dominique Martinet  wrote:
> > 
> > Just noticed this change on rawhide...
> > https://github.com/systemd/systemd/blob/master/NEWS#L29
> >   * systemd-logind will now by default terminate user processes
> > that are
> > part of the user session scope unit (session-XX.scope) when the
> > user
> > logs out. This behavior is controlled by the KillUserProcesses=
> > setting in logind.conf, and the previous default of "no" is now
> > changed to "yes". This means that user sessions will be
> > properly
> > cleaned up after, but additional steps are necessary to allow
> > intentionally long-running processes to survive logout.
> This sounds very much like a system-wide Change. Where can I find the
> Change proposal?
> 
> Björn Persson
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject
> .org
Also I could see separate Workstation & Server changes - as the impact
of this change is IMHO much bigger than on the Workstation where it
actually might have benefits in some cases.
--
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

[Neal Becker]

Zbigniew Jędrzejewski-Szmek wrote:

> On Fri, May 27, 2016 at 08:09:33AM -0500, Chris Adams wrote:
>> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
>> > Also note that running jobs in a systemd service has advantages on the
>> > server: better accounting, more transparency, logs are easier to read.
>> > The (old) default of allowing left-over session processes to live on
>> > seems especially bad on a server with multiple users.
>> 
>> Starting a one-off task under screen and detaching is an age-old server
>> management process.  Breaking that is not acceptable IMHO.
> 
> This change was done for a reason: left-over session processes
> are causing real problems.
> You still can start a one-off task under screen, you just need to
> invoke it in one the different ways described in
> https://www.freedesktop.org/software/systemd/man/systemd-run.html#Examples
> 
> Zbyszek
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Similarly, we need a way to fix x2go
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora lists From munging/DMARC (Was: audio problems)

[Andrew Lutomirski]

On Thu, May 26, 2016 at 8:19 AM, Kevin Fenzi  wrote:
> On Mon, 23 May 2016 16:42:05 +0200
> Dominique Martinet  wrote:
>
> ...snip...
>
>> The question is, should fedora's lists be configured to rewrite the
>> from ? I'm pretty sure mailman 3.1 can handle it, if we want it to.
>>
>> I haven't seen any discussion about this, has it ever been brought up?
>> Do the admins have any opinion on it?
>
> As an admin, I'd prefer not to...
>
> I suppose given enough people affected we could look into it.
> In any case if someone wants some change like that, please file an
> infrastructure ticket and we can discuss it there.

There's a thing called "authenticated receive chain" that Google is
helping develop that's supposed to help fix this problem.
Unfortunately, gmail and others are blazing ahead with breaking
everything before ARC will be ready.
--
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

[Zbigniew Jędrzejewski-Szmek]

On Fri, May 27, 2016 at 06:15:08PM +0200, Björn Persson wrote:
> Dominique Martinet  wrote:
> > Just noticed this change on rawhide...
> > https://github.com/systemd/systemd/blob/master/NEWS#L29
> >   * systemd-logind will now by default terminate user processes that are
> > part of the user session scope unit (session-XX.scope) when the user
> > logs out. This behavior is controlled by the KillUserProcesses=
> > setting in logind.conf, and the previous default of "no" is now
> > changed to "yes". This means that user sessions will be properly
> > cleaned up after, but additional steps are necessary to allow
> > intentionally long-running processes to survive logout.
> 
> This sounds very much like a system-wide Change. Where can I find the
> Change proposal?

It's not a Fedora-specific change. See the other parts of the thread
for links to upstream discussions (in particular the mail from Michal).

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

[Nico Kadel-Garcia]

On Fri, May 27, 2016 at 9:13 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Fri, May 27, 2016 at 08:51:23AM -0400, Nico Kadel-Garcia wrote:
>> This breaks the storage of ssh-agent credentials for te one-time
>> enabling of SSH credentials for access on running hosts.
>
> You mean you start ssh-agent somewhere during the first login and then
> access it from any process from further sessions? You can get a setup
> to work like this by running the agent in a service, like any long
> running service.

It's a historically useful way to require an authorized user to
actually log into the system and unlock the key. It's similar to the
requirement of secure Kerberos servers and Java keystore systems to
have a user attend the startup of the daemons, in order to unlock the
protected credentials on request and prevent unauthorized use of the
service from a stolen backup or disk image.

>> Gods alone know what else it will break.
>
> File the bugs, we'll deal with them one at a time.

If I could list all the bugs caused by this change, in advance, in all
of Fedora userland, I'd be paid a lot more.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: DNF Issue, packages being incorrectly removed - was: Re: corebird

[Charalampos Stratakis]

It is actually documented here: 
https://fedoraproject.org/wiki/Common_F24_bugs#DNF_might_remove_essential_system_packages_if_you_used_PackageKit_.28GNOME_Software.2C_KDE_Apper.29_in_the_past

- Original Message -
From: "Nico Kadel-Garcia" 
To: "Development discussions related to Fedora" 
Sent: Friday, May 27, 2016 8:17:01 AM
Subject: Re: DNF Issue, packages being incorrectly removed - was: Re: corebird

On Thu, May 26, 2016 at 1:03 PM, Gerald B. Cox  wrote:
>
> On Thu, May 26, 2016 at 3:02 AM, Michal Luscon  wrote:
>>
>> This might have been caused by
>> https://bugzilla.redhat.com/show_bug.cgi?id=1259865
>>
>> .
>>
>> Michal
>
>
> Yes, Kevin mentioned that and it is in the other thread (corebird).  I'm
> just wondering if this is something that will be resolved
> with the upgrade to F24.

Just don't use "dnf autoremove" it is not, and cannot be, your friend
except to perhaps provide a *guideline*, of removable packages. Never
run it without manual review of the target packages.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: DNF Issue, packages being incorrectly removed - was: Re: corebird

[Nico Kadel-Garcia]

On Thu, May 26, 2016 at 1:03 PM, Gerald B. Cox  wrote:
>
> On Thu, May 26, 2016 at 3:02 AM, Michal Luscon  wrote:
>>
>> This might have been caused by
>> https://bugzilla.redhat.com/show_bug.cgi?id=1259865
>>
>> .
>>
>> Michal
>
>
> Yes, Kevin mentioned that and it is in the other thread (corebird).  I'm
> just wondering if this is something that will be resolved
> with the upgrade to F24.

Just don't use "dnf autoremove" it is not, and cannot be, your friend
except to perhaps provide a *guideline*, of removable packages. Never
run it without manual review of the target packages.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: DNF Issue, packages being incorrectly removed - was: Re: corebird

[Igor Gnatenko]

Guys, this issue has been fixed in F24's PackageKit (libhif actually).

-Igor Gnatenko
On May 27, 2016 8:33 AM, "Dan Book"  wrote:

> On Fri, May 27, 2016 at 2:17 AM, Nico Kadel-Garcia 
> wrote:
>
>> On Thu, May 26, 2016 at 1:03 PM, Gerald B. Cox  wrote:
>> >
>> > On Thu, May 26, 2016 at 3:02 AM, Michal Luscon 
>> wrote:
>> >>
>> >> This might have been caused by
>> >> https://bugzilla.redhat.com/show_bug.cgi?id=1259865
>> >>
>> >> .
>> >>
>> >> Michal
>> >
>> >
>> > Yes, Kevin mentioned that and it is in the other thread (corebird).  I'm
>> > just wondering if this is something that will be resolved
>> > with the upgrade to F24.
>>
>> Just don't use "dnf autoremove" it is not, and cannot be, your friend
>> except to perhaps provide a *guideline*, of removable packages. Never
>> run it without manual review of the target packages.
>>
>
> For whatever reason, autoremove is the default behavior of dnf unless you
> disable clean_requirements_on_remove, so you can expect this issue to hit
> new users.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

jboss-parent license changes

[gil]

Hi

now jboss-parent package changes from Public Domain to Creative Commons 
Zero 1.0 Universal (CC0)


regards

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

Re: DNF Issue, packages being incorrectly removed - was: Re: corebird

[Dan Book]

On Fri, May 27, 2016 at 2:17 AM, Nico Kadel-Garcia  wrote:

> On Thu, May 26, 2016 at 1:03 PM, Gerald B. Cox  wrote:
> >
> > On Thu, May 26, 2016 at 3:02 AM, Michal Luscon 
> wrote:
> >>
> >> This might have been caused by
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1259865
> >>
> >> .
> >>
> >> Michal
> >
> >
> > Yes, Kevin mentioned that and it is in the other thread (corebird).  I'm
> > just wondering if this is something that will be resolved
> > with the upgrade to F24.
>
> Just don't use "dnf autoremove" it is not, and cannot be, your friend
> except to perhaps provide a *guideline*, of removable packages. Never
> run it without manual review of the target packages.
>

For whatever reason, autoremove is the default behavior of dnf unless you
disable clean_requirements_on_remove, so you can expect this issue to hit
new users.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

jboss-modules license changes

[gil]

Hi

now jboss-modules package changes from LGPLv2+ to ASL 2.0 and xpp

regards

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

jboss-logmanager license changes

[gil]

Hi

now jboss-logmanager package changes from LGPLv2+ to ASL 2.0

regards

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

[Paul Wouters]

On Fri, 27 May 2016, Chris Murphy wrote:


It seems to  me systemd should be able to know the difference between
a program that's zombie or unresponsive but isn't doing anything or is
unresponsive but is doing something; and if not then some way for
programs to say "hey wait just a minute, I need to clean things up" or
whatever, rather than just abruptly killing them.


That invention is otherwise known as "unix signals".

systemd should not be the process police. 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.

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

[Bug 1340296] perl-B-Generate-1.54 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-B-Generate-1.54-1.fc23 has been pushed to the Fedora 23 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-8759e3847f

-- 
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 1340296] perl-B-Generate-1.54 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-B-Generate-1.54-1.fc24 has been pushed to the Fedora 24 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-0a52d8292e

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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 446  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 208  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  75  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-785fc9a2ea   
dropbear-2016.72-1.el7
  27  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4f1d69369e   
openvas-cli-1.4.4-1.el7 openvas-gsa-6.0.10-3.el7 openvas-libraries-8.0.7-2.el7 
openvas-manager-6.0.8-2.el7 openvas-scanner-5.0.5-3.el7
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-91016c3760   
cacti-0.8.8h-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04311b3bab   
websvn-2.3.3-13.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e5732b714e   
phpMyAdmin-4.4.15.6-1.el7


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

bash-completion-extras-2.1-10.el7
cherrytree-0.37.0-1.el7
dkms-2.2.0.3-34.git.9e0394d.el7
fedfind-2.4.7-1.el7
globus-xio-udt-driver-1.21-1.el7
ndisc6-1.0.3-1.el7
pagure-2.1.1-1.el7
pdc-client-1.0.0-1.el7
perl-Test-Compile-1.3.0-1.el7
phpMyAdmin-4.4.15.6-1.el7
python-resultsdb_api-1.2.2-3.el7
salt-2015.5.10-1.el7

Details about builds:



 bash-completion-extras-2.1-10.el7 (FEDORA-EPEL-2016-1db95de7a7)
 Additional programmable completions for Bash

Update Information:

remove files that conflict with base bash-completion package

References:

  [ 1 ] Bug #1339420 - bash-completion-extras provides files provided by RHEL 
bash-completion package
https://bugzilla.redhat.com/show_bug.cgi?id=1339420




 cherrytree-0.37.0-1.el7 (FEDORA-EPEL-2016-11e86c3db7)
 Hierarchical note taking application

Update Information:

update cherrytree to 0.37.0

References:

  [ 1 ] Bug #1340299 - cherrytree-0.37.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1340299




 dkms-2.2.0.3-34.git.9e0394d.el7 (FEDORA-EPEL-2016-85c7928830)
 Dynamic Kernel Module Support Framework

Update Information:

Multiprocessor build support and bugfixes.

References:

  [ 1 ] Bug #1334103 - RFE:  Use parallel build on multiprocessor systems
https://bugzilla.redhat.com/show_bug.cgi?id=1334103
  [ 2 ] Bug #912300 - DKMS do not preserve timestamps when copying source into 
build directory, this may cause some pkgs re-build failures or at least extra 
work.
https://bugzilla.redhat.com/show_bug.cgi?id=912300




 fedfind-2.4.7-1.el7 (FEDORA-EPEL-2016-2c5223703c)
 Fedora Finder finds Fedora

Update Information:

This update provides the latest release of
[fedfind](https://www.happyassassin.net/fedfind). It fixes handling of two week
Atomic compose IDs in `fedfind.release.get_release`.




 globus-xio-udt-driver-1.21-1.el7 (FEDORA-EPEL-2016-fc95f3b088)
 Globus Toolkit - Globus XIO UDT Driver

Update Information:

Add GLOBUS_XIO_UDT_STUNSERVER environment variable override




 ndisc6-1.0.3-1.el7 (FEDORA-EPEL-2016-778921a916)
 IPv6 diagnostic tools

Update Information:

New upstream and push to epel7 as well

References:

  [ 1 ] Bug #1310352 - Update to latest version / epel7
https://bugzilla.redhat.com/show_bug.cgi?id=1310352

[Bug 1340201] Please build perl-Test-Compile for EPEL 6

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Test-Compile-1.3.0-1.el7 has been pushed to the Fedora EPEL 7 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-aaab2eef56

-- 
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 1337905] perl-Net-Pcap-0.18 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Net-Pcap-0.18-1.fc25   |perl-Net-Pcap-0.18-1.fc25
   ||perl-Net-Pcap-0.18-1.fc24
 Resolution|--- |ERRATA
Last Closed||2016-05-27 23:32:43



-- 
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 1337905] perl-Net-Pcap-0.18 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Net-Pcap-0.18-1.fc24 has been pushed to the Fedora 24 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 1338396] perl-CPAN-Perl-Releases-2.78 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-CPAN-Perl-Releases-2.78-1.fc24 has been pushed to the Fedora 24 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 1338396] perl-CPAN-Perl-Releases-2.78 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-CPAN-Perl-Releases-2.7 |perl-CPAN-Perl-Releases-2.7
   |8-1.fc25|8-1.fc25
   ||perl-CPAN-Perl-Releases-2.7
   ||8-1.fc24
 Resolution|--- |ERRATA
Last Closed||2016-05-27 23:32:38



-- 
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 1339028] perl-Pod-Usage-1.69 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Pod-Usage-1.69-1.fc24 has been pushed to the Fedora 24 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 1339028] perl-Pod-Usage-1.69 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Pod-Usage-1.69-1.fc25  |perl-Pod-Usage-1.69-1.fc25
   ||perl-Pod-Usage-1.69-1.fc24
 Resolution|--- |ERRATA
Last Closed||2016-05-27 23:32:02



-- 
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 1315525] perl-Net-DNS-1.06 is available

[bugzilla]

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



--- Comment #6 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 1315525] perl-Net-DNS-1.06 is available

[bugzilla]

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



--- Comment #4 from Upstream Release Monitoring 
 ---
Patching or scratch build for perl-Net-DNS-1.04 failed.

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

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

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Net-DNS-1.05 is|perl-Net-DNS-1.06 is
   |available   |available



--- Comment #3 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.06
Current version/release in rawhide: 1.04-5.fc25
URL: http://search.cpan.org/dist/Net-DNS/

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

-- 
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 1315525] perl-Net-DNS-1.06 is available

[bugzilla]

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



--- Comment #5 from Upstream Release Monitoring 
 ---
Created attachment 1162575
  --> https://bugzilla.redhat.com/attachment.cgi?id=1162575=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

jplesnik uploaded Config-Model-Tester-2.055.tar.gz for perl-Config-Model-Tester

[notifications]

9dba265e629ccc8141d84d398340a3d0  Config-Model-Tester-2.055.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Config-Model-Tester/Config-Model-Tester-2.055.tar.gz/md5/9dba265e629ccc8141d84d398340a3d0/Config-Model-Tester-2.055.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

jplesnik pushed to perl-Config-Model-Tester (master). "2.055 bump"

[notifications]

From a1663e862f8adf93ed519f15fdc6e8198c55c475 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Fri, 27 May 2016 10:12:07 +0200
Subject: 2.055 bump

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

diff --git a/.gitignore b/.gitignore
index 8c1e8b5..a5c9da5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /Config-Model-Tester-2.052.tar.gz
 /Config-Model-Tester-2.053.tar.gz
 /Config-Model-Tester-2.054.tar.gz
+/Config-Model-Tester-2.055.tar.gz
diff --git a/perl-Config-Model-Tester.spec b/perl-Config-Model-Tester.spec
index a8c29d8..fec5310 100644
--- a/perl-Config-Model-Tester.spec
+++ b/perl-Config-Model-Tester.spec
@@ -1,6 +1,6 @@
 Name:   perl-Config-Model-Tester
-Version:2.054
-Release:3%{?dist}
+Version:2.055
+Release:1%{?dist}
 Summary:Test framework for Config::Model
 License:LGPLv2
 Group:  Development/Libraries
@@ -62,6 +62,9 @@ perl Build.PL installdirs=vendor
 %{_mandir}/man3/*
 
 %changelog
+* Fri May 27 2016 Jitka Plesnikova  - 2.055-1
+- 2.055 bump
+
 * Wed May 18 2016 Jitka Plesnikova  - 2.054-3
 - Perl 5.24 re-rebuild of bootstrapped packages
 
diff --git a/sources b/sources
index f7b81d9..4c74500 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1c4347fd657829ff85b67f9a967f0b7b  Config-Model-Tester-2.054.tar.gz
+9dba265e629ccc8141d84d398340a3d0  Config-Model-Tester-2.055.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Config-Model-Tester.git/commit/?h=master=a1663e862f8adf93ed519f15fdc6e8198c55c475
--
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 1340294] perl-Config-Model-Tester-2.055 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Config-Model-Tester-2.
   ||055-1.fc25



-- 
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 1340294] perl-Config-Model-Tester-2.055 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2016-05-27 04:23:59



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

ppisar pushed to perl-RDF-Trine (master). "Fix loading optional database backends (..more)"

[notifications]

From 43ca1248e7de5e62dfebea5f6436b6e5b9972983 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 27 May 2016 12:40:34 +0200
Subject: Fix loading optional database backends

If some backends were not installed, the code was aborted by
Module::Load::Conditional loading the RDF::Trine::Store::DBI.
---
 ...ine-1.014-Make-database-backends-optional.patch | 27 ++
 perl-RDF-Trine.spec|  7 --
 2 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/RDF-Trine-1.014-Make-database-backends-optional.patch 
b/RDF-Trine-1.014-Make-database-backends-optional.patch
index d1e3c39..f096d2e 100644
--- a/RDF-Trine-1.014-Make-database-backends-optional.patch
+++ b/RDF-Trine-1.014-Make-database-backends-optional.patch
@@ -1,6 +1,6 @@
-From 2b139e2b6d7b872edb1bc4341e54d10c01607453 Mon Sep 17 00:00:00 2001
+From a7aa7c801bcbccdbd054c77b2a886342e115a926 Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
-Date: Thu, 24 Mar 2016 14:44:28 +0100
+Date: Fri, 27 May 2016 12:38:45 +0200
 Subject: [PATCH] Make database backends optional
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
@@ -8,23 +8,32 @@ Content-Transfer-Encoding: 8bit
 
 Signed-off-by: Petr Písař 
 ---
- lib/RDF/Trine/Store/DBI.pm | 6 +++---
- 1 file changed, 3 insertions(+), 3 deletions(-)
+ lib/RDF/Trine/Store/DBI.pm | 15 ---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
 
 diff --git a/lib/RDF/Trine/Store/DBI.pm b/lib/RDF/Trine/Store/DBI.pm
-index bd59ccb..33cfe74 100644
+index bd59ccb..877a3e4 100644
 --- a/lib/RDF/Trine/Store/DBI.pm
 +++ b/lib/RDF/Trine/Store/DBI.pm
-@@ -57,9 +57,9 @@ use RDF::Trine::Iterator;
+@@ -57,9 +57,18 @@ use RDF::Trine::Iterator;
  use Log::Log4perl;
  
  use RDF::Trine::Error;
 -use RDF::Trine::Store::DBI::mysql;
 -use RDF::Trine::Store::DBI::SQLite;
 -use RDF::Trine::Store::DBI::Pg;
-+eval { use RDF::Trine::Store::DBI::mysql };
-+eval { use RDF::Trine::Store::DBI::SQLite };
-+eval { use RDF::Trine::Store::DBI::Pg };
++BEGIN {
++  # Make database backends optional.
++  # Plain "eval {use Foo}" does not work because this code is itself
++  # loaded by Module::Load::Conditional.
++  for my $store (qw(mysql SQLite Pg)) {
++  Module::Load::Conditional::can_load(autoload => 1,
++  modules => {
++  "RDF::Trine::Store::DBI::$store" => undef
++  }
++  );
++  }
++}
  
  ##
  
diff --git a/perl-RDF-Trine.spec b/perl-RDF-Trine.spec
index 0773785..41255bd 100644
--- a/perl-RDF-Trine.spec
+++ b/perl-RDF-Trine.spec
@@ -1,6 +1,6 @@
 Name:   perl-RDF-Trine
 Version:1.014
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:RDF Framework for Perl
 # README:   GPLv+ or Artistic
 # lib/RDF/Trine.pm: GPLv+ or Artistic
@@ -18,7 +18,7 @@ Patch0: RDF-Trine-1.014-Disable-release-code.patch
 Patch1: RDF-Trine-1.014-Make-database-backends-optional.patch
 # Avoid TryCatch that does not work with perl-5.24 (bug #1339244),
 # 
-Patch2:RDF-Trine-1.014-Use-Error-instead-of-TryCatch.patch
+Patch2: RDF-Trine-1.014-Use-Error-instead-of-TryCatch.patch
 BuildArch:  noarch
 BuildRequires:  coreutils
 BuildRequires:  findutils
@@ -249,6 +249,9 @@ make test
 %{_mandir}/man3/Test::RDF::Trine::Store.*
 
 %changelog
+* Fri May 27 2016 Petr Pisar  - 1.014-3
+- Fix loading optional database backends
+
 * Wed May 25 2016 Petr Pisar  - 1.014-2
 - Avoid TryCatch that does not work with perl-5.24 (bug #1339244)
 - Perl 5.24 rebuild
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-RDF-Trine.git/commit/?h=master=43ca1248e7de5e62dfebea5f6436b6e5b9972983
--
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 1340443] New: perl-Log-Report-1.16 is available

[bugzilla]

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

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



Latest upstream release: 1.16
Current version/release in rawhide: 1.15-2.fc25
URL: http://search.cpan.org/dist/Log-Report/

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

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

ppisar pushed to perl-Log-Report (master). "1.16 bump"

[notifications]

From a59f6fd0bd5d10d0731c1a1b9a0fd48b2b3e7581 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 27 May 2016 14:30:53 +0200
Subject: 1.16 bump

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

diff --git a/.gitignore b/.gitignore
index 3997df6..8a63834 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,3 +12,4 @@
 /Log-Report-1.12.tar.gz
 /Log-Report-1.13.tar.gz
 /Log-Report-1.15.tar.gz
+/Log-Report-1.16.tar.gz
diff --git a/perl-Log-Report.spec b/perl-Log-Report.spec
index 6536682..163b586 100644
--- a/perl-Log-Report.spec
+++ b/perl-Log-Report.spec
@@ -1,6 +1,6 @@
 Name:   perl-Log-Report
-Version:1.15
-Release:2%{?dist}
+Version:1.16
+Release:1%{?dist}
 Summary:Report a problem with exceptions and translation support
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -219,6 +219,9 @@ make test
 %{_mandir}/man3/MojoX::Log::Report.*
 
 %changelog
+* Fri May 27 2016 Petr Pisar  - 1.16-1
+- 1.16 bump
+
 * Tue May 17 2016 Jitka Plesnikova  - 1.15-2
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index cf13ba8..ca74407 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-043616214e1a6ec085b2d15da45dd55e  Log-Report-1.15.tar.gz
+3c545b8a2f0e70469456048d8409f092  Log-Report-1.16.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Log-Report.git/commit/?h=master=a59f6fd0bd5d10d0731c1a1b9a0fd48b2b3e7581
--
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: Problems with scripts in a common spec file

[Tomas Orsava]

Hi!

On 05/26/2016 07:38 PM, John Dennis wrote:

On 05/26/2016 08:24 AM, Tomas Orsava wrote:

Hi,

those are very good questions to which you should be able to find
answers on the Python RPM Porting Guide [0]. You are right that this
should be better covered in the packaging guidelines, sadly the process
of changing them is rather problematic so no one yet had the time to
update them.

[0] http://python-rpm-porting.readthedocs.io/en/latest/


Thanks Tomas, I was aware of this document as well. However I believe 
both documents contain the same mistake.


Here is the problem:

Only the python3-XXX package installs the (Py3) script. Unless the 
python2-XXX package requires the script neither the script nor the Py3 
modules/packages required by the (Py3) script will be installed when 
you install either the python-XXX or python2-XXX package (assuming the 
virtual provides of python-XXX points to python2-XXX as is currently 
the case).


I think the python2-XXX package in the examples is missing something 
like this:


Requires: %{_bindir}/sample-exec

Make sense?

I believe there is a misunderstanding. In your first message you said 
"But the guidelines require the py3 version of the script in the py2 
package." That is incorrect.


The guidelines only require you to package the Python 3 version of the 
script. They are not very clear on where you should put it, but the only 
logical place is of course the Python 3 subpackage (or a new subpackage 
with only the executable script that relies on the Python 3 subpackage).


You should never put the Python 3 executable in the Python 2 subpackage.

Kind regards,
Tomas
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Broken dependencies: perl-Scope-Upper

[buildsys]

perl-Scope-Upper has broken dependencies in the rawhide tree:
On x86_64:
perl-Scope-Upper-0.28-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Scope-Upper-0.28-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Scope-Upper-0.28-2.fc24.i686 requires libperl.so.5.22
perl-Scope-Upper-0.28-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Scope-Upper-0.28-2.fc24.armv7hl requires libperl.so.5.22
perl-Scope-Upper-0.28-2.fc24.armv7hl requires 
perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

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

Broken dependencies: rt

[buildsys]

rt has broken dependencies in the rawhide tree:
On x86_64:
perl-RT-Test-4.4.0-1.fc25.noarch requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-RT-Test-4.4.0-1.fc25.noarch requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-RT-Test-4.4.0-1.fc25.noarch requires perl(:MODULE_COMPAT_5.22.1)
On x86_64:
rt-4.4.0-1.fc25.noarch requires perl(:MODULE_COMPAT_5.22.1)
On i386:
rt-4.4.0-1.fc25.noarch requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
rt-4.4.0-1.fc25.noarch requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-RDF-Trine

[buildsys]

perl-RDF-Trine has broken dependencies in the rawhide tree:
On x86_64:
perl-Test-RDF-Trine-Store-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Test-RDF-Trine-Store-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Test-RDF-Trine-Store-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On x86_64:
perl-RDF-Trine-mysql-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-RDF-Trine-mysql-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-RDF-Trine-mysql-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On x86_64:
perl-RDF-Trine-sqlite-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-RDF-Trine-sqlite-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-RDF-Trine-sqlite-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On x86_64:
perl-RDF-Trine-postgresql-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-RDF-Trine-postgresql-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-RDF-Trine-postgresql-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On x86_64:
perl-RDF-Trine-redis-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-RDF-Trine-redis-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-RDF-Trine-redis-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On x86_64:
perl-RDF-Trine-1.014-1.fc25.noarch requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-RDF-Trine-1.014-1.fc25.noarch requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-RDF-Trine-1.014-1.fc25.noarch requires perl(:MODULE_COMPAT_5.22.1)
On x86_64:
perl-RDF-Trine-redland-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-RDF-Trine-redland-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-RDF-Trine-redland-1.014-1.fc25.noarch requires 
perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-Algorithm-Permute

[buildsys]

perl-Algorithm-Permute has broken dependencies in the rawhide tree:
On x86_64:
perl-Algorithm-Permute-0.12-21.fc24.x86_64 requires 
libperl.so.5.22()(64bit)
perl-Algorithm-Permute-0.12-21.fc24.x86_64 requires 
perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Algorithm-Permute-0.12-21.fc24.i686 requires libperl.so.5.22
perl-Algorithm-Permute-0.12-21.fc24.i686 requires 
perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Algorithm-Permute-0.12-21.fc24.armv7hl requires libperl.so.5.22
perl-Algorithm-Permute-0.12-21.fc24.armv7hl requires 
perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-TryCatch

[buildsys]

perl-TryCatch has broken dependencies in the rawhide tree:
On x86_64:
perl-TryCatch-1.003002-9.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-TryCatch-1.003002-9.fc24.x86_64 requires 
perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-TryCatch-1.003002-9.fc24.i686 requires libperl.so.5.22
perl-TryCatch-1.003002-9.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-TryCatch-1.003002-9.fc24.armv7hl requires libperl.so.5.22
perl-TryCatch-1.003002-9.fc24.armv7hl requires 
perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-Task-Moose

[buildsys]

perl-Task-Moose has broken dependencies in the rawhide tree:
On x86_64:
perl-Task-Moose-0.03-11.fc24.noarch requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Task-Moose-0.03-11.fc24.noarch requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Task-Moose-0.03-11.fc24.noarch requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-Coro-Multicore

[buildsys]

perl-Coro-Multicore has broken dependencies in the rawhide tree:
On x86_64:
perl-Coro-Multicore-0.02-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Coro-Multicore-0.02-2.fc24.x86_64 requires 
perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Coro-Multicore-0.02-2.fc24.i686 requires libperl.so.5.22
perl-Coro-Multicore-0.02-2.fc24.i686 requires 
perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Coro-Multicore-0.02-2.fc24.armv7hl requires libperl.so.5.22
perl-Coro-Multicore-0.02-2.fc24.armv7hl requires 
perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-Coro

[buildsys]

perl-Coro has broken dependencies in the rawhide tree:
On x86_64:
perl-Coro-6.49-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Coro-6.49-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Coro-6.49-2.fc24.i686 requires libperl.so.5.22
perl-Coro-6.49-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Coro-6.49-2.fc24.armv7hl requires libperl.so.5.22
perl-Coro-6.49-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.20-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Data-Alias-1.20-2.fc24.i686 requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Data-Alias-1.20-2.fc24.armv7hl requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

--
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 1340434] New: Upgrade perl-App-GitHooks to 1.8.0

[bugzilla]

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

Bug ID: 1340434
   Summary: Upgrade perl-App-GitHooks to 1.8.0
   Product: Fedora
   Version: rawhide
 Component: perl-App-GitHooks
  Keywords: FutureFeature
  Assignee: dd...@cpan.org
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org



Latest Fedora delivers 1.7.3 version. Upstream release 1.8.0. When you have
free time, please upgrade it.

Also please enable release monitoring
 to
receive notifications about new releases automatically.

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

jplesnik pushed to perl-Test-Compile (epel7). "1.3.0 bump"

[notifications]

From 90fc94e0723245d096ba1f6412731c3970174547 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 |  3 +++
 perl-Test-Compile.spec | 25 +
 sources|  2 +-
 3 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/.gitignore b/.gitignore
index ec6eb35..6e263a3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,6 @@ Test-Compile-0.13.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/perl-Test-Compile.spec b/perl-Test-Compile.spec
index 98d1b59..2b8127b 100644
--- a/perl-Test-Compile.spec
+++ b/perl-Test-Compile.spec
@@ -1,12 +1,18 @@
+# Real version
+%global cpan_version v1.3.0
+
 Name:   perl-Test-Compile
-Version:0.24
+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-%{version}.tar.gz
+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
@@ -15,6 +21,7 @@ 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
@@ -28,7 +35,7 @@ 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-%{version}
+%setup -q -n Test-Compile-%{cpan_version}
 
 %build
 perl Makefile.PL INSTALLDIRS=vendor
@@ -43,11 +50,21 @@ find %{buildroot} -type f -name .packlist -exec rm -f {} +
 make test
 
 %files
-%doc Changes LICENSE README
+%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)
 
diff --git a/sources b/sources
index 24e97e0..ef19f68 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-52c2b3d0bbd918b1a498e3df5c7fa9d3  Test-Compile-0.24.tar.gz
+c7e8c9255d818823d440ac640527e7f8  Test-Compile-v1.3.0.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Test-Compile.git/commit/?h=epel7=90fc94e0723245d096ba1f6412731c3970174547
--
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 1340436] New: perl-ExtUtils-H2PM-0.10 is available

[bugzilla]

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

Bug ID: 1340436
   Summary: perl-ExtUtils-H2PM-0.10 is available
   Product: Fedora
   Version: rawhide
 Component: perl-ExtUtils-H2PM
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org



Latest upstream release: 0.10
Current version/release in rawhide: 0.09-8.fc25
URL: http://search.cpan.org/dist/ExtUtils-H2PM/

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

-- 
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 1340443] perl-Log-Report-1.16 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Log-Report-1.16-1.fc25
 Resolution|--- |RAWHIDE
Last Closed||2016-05-27 08:37:01



--- Comment #1 from Petr Pisar  ---
A bug fix release suitable for Fedora ≥ 25.

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

jplesnik requested branch el6 for package perl-Test-Compile

[notifications]

jplesnik requested branch el6 for package perl-Test-Compile
https://admin.fedoraproject.org/pkgdb/package/perl-Test-Compile/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar pushed to perl-RDF-NS (master). "20160409 bump"

[notifications]

From 1db7007fde559797550fd88a9bb616ccdcba5635 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 27 May 2016 14:12:07 +0200
Subject: 20160409 bump

---
 .gitignore   |  1 +
 .rpmlint |  2 ++
 RDF-NS-20150725-Do-not-use-usr-bin-env.patch | 26 --
 RDF-NS-20160409-Do-not-use-usr-bin-env.patch | 26 ++
 perl-RDF-NS.spec | 11 +--
 sources  |  2 +-
 6 files changed, 35 insertions(+), 33 deletions(-)
 create mode 100644 .rpmlint
 delete mode 100644 RDF-NS-20150725-Do-not-use-usr-bin-env.patch
 create mode 100644 RDF-NS-20160409-Do-not-use-usr-bin-env.patch

diff --git a/.gitignore b/.gitignore
index 6dd8582..fbb3e68 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /RDF-NS-20150725.tar.gz
+/RDF-NS-20160409.tar.gz
diff --git a/.rpmlint b/.rpmlint
new file mode 100644
index 000..ac93ab1
--- /dev/null
+++ b/.rpmlint
@@ -0,0 +1,2 @@
+from Config import *
+addFilter("spelling-error .* http");
diff --git a/RDF-NS-20150725-Do-not-use-usr-bin-env.patch 
b/RDF-NS-20150725-Do-not-use-usr-bin-env.patch
deleted file mode 100644
index 1ed8976..000
--- a/RDF-NS-20150725-Do-not-use-usr-bin-env.patch
+++ /dev/null
@@ -1,26 +0,0 @@
-From 19a77a005e16353b643b568c86467914421c32f1 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
-Date: Fri, 8 Apr 2016 15:34:06 +0200
-Subject: [PATCH] Do not use /usr/bin/env
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Signed-off-by: Petr Písař 

- bin/rdfns | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/bin/rdfns b/bin/rdfns
-index c9af67a..34dacb1 100755
 a/bin/rdfns
-+++ b/bin/rdfns
-@@ -1,4 +1,4 @@
--#!/usr/bin/env perl
-+#!perl
- #ABSTRACT: look up common URI namespaces and prefixes
- #PODNAME: rdfns
- 
--- 
-2.5.5
-
diff --git a/RDF-NS-20160409-Do-not-use-usr-bin-env.patch 
b/RDF-NS-20160409-Do-not-use-usr-bin-env.patch
new file mode 100644
index 000..fff7028
--- /dev/null
+++ b/RDF-NS-20160409-Do-not-use-usr-bin-env.patch
@@ -0,0 +1,26 @@
+From 6c147bce4ed5370a5ee171b31a6b2a3093971ced Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
+Date: Fri, 27 May 2016 14:07:13 +0200
+Subject: [PATCH] Do not use /usr/bin/env
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Petr Písař 
+---
+ script/rdfns | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/script/rdfns b/script/rdfns
+index c9af67a..34dacb1 100755
+--- a/script/rdfns
 b/script/rdfns
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env perl
++#!perl
+ #ABSTRACT: look up common URI namespaces and prefixes
+ #PODNAME: rdfns
+ 
+-- 
+2.5.5
+
diff --git a/perl-RDF-NS.spec b/perl-RDF-NS.spec
index 2c4be74..95af692 100644
--- a/perl-RDF-NS.spec
+++ b/perl-RDF-NS.spec
@@ -1,5 +1,5 @@
 Name:   perl-RDF-NS
-Version:20150725
+Version:20160409
 Release:1%{?dist}
 Summary:Popular RDF name space prefixes from prefix.cc
 License:GPL+ or Artistic
@@ -7,7 +7,7 @@ Group:  Development/Libraries
 URL:http://search.cpan.org/dist/RDF-NS/
 Source0:
http://www.cpan.org/authors/id/V/VO/VOJ/RDF-NS-%{version}.tar.gz
 # Fix shell bang
-Patch0: RDF-NS-20150725-Do-not-use-usr-bin-env.patch
+Patch0: RDF-NS-20160409-Do-not-use-usr-bin-env.patch
 BuildArch:  noarch
 BuildRequires:  coreutils
 BuildRequires:  perl
@@ -15,7 +15,6 @@ BuildRequires:  perl-generators
 BuildRequires:  perl(Module::Build::Tiny) >= 0.039
 BuildRequires:  perl(strict)
 BuildRequires:  perl(warnings)
-BuildRequires:  sed
 # Run-time:
 BuildRequires:  perl(base)
 BuildRequires:  perl(Carp)
@@ -46,9 +45,6 @@ includes all these prefixes as defined at specific snapshots 
in time.
 %setup -q -n RDF-NS-%{version}
 %patch0 -p1
 chmod -x lib/App/rdfns.pm
-# Fix script installation, 
-mv bin script
-sed -i -e 's/^bin\//script\//' MANIFEST
 
 %build
 perl Build.PL --installdirs=vendor
@@ -70,5 +66,8 @@ perl Build.PL --installdirs=vendor
 %{_mandir}/man3/*
 
 %changelog
+* Fri May 27 2016 Petr Pisar  - 20160409-1
+- 20160409 bump
+
 * Fri Apr 08 2016 Petr Pisar  20150725-1
 - Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index a8c2d02..70044fa 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8c7e907682a7b18cb6900d4fae6d3fc3  RDF-NS-20150725.tar.gz
+7d3716263403651d004636c95d86c287  RDF-NS-20160409.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-RDF-NS.git/commit/?h=master=1db7007fde559797550fd88a9bb616ccdcba5635
--
Fedora Extras Perl SIG

[Bug 1340201] Please build perl-Test-Compile for EPEL 6

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-Test-Compile-1.3.0-1.el7 has been submitted as an update to Fedora EPEL 7.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-aaab2eef56

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

ppisar uploaded RDF-NS-20160409.tar.gz for perl-RDF-NS

[notifications]

7d3716263403651d004636c95d86c287  RDF-NS-20160409.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-RDF-NS/RDF-NS-20160409.tar.gz/md5/7d3716263403651d004636c95d86c287/RDF-NS-20160409.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