Re: systemd 230 change - KillUserProcesses defaults to yes

On Sun, May 29, 2016 at 06:51:20PM -0600, Chris Murphy wrote: > So there's tmux, screen, curl, wget, and probably quite a few others > that don't necessarily get daemonized that are probably affected. I would really like to see a solution whereby tmux and screen _just work_ without any required ch

F25 Self Contained Change: The GNU C Library version 2.24

= Proposed Self Contained Change: The GNU C Library version 2.24 = https://fedoraproject.org/wiki/Changes/GLIBC224 Change owner(s): * Carlos O'Donell Switch glibc in Fedora 25 to glibc version 2.24. == Detailed Description == The GNU C Library version 2.24 will be released at the beginning of A

Re: systemd 230 change - KillUserProcesses defaults to yes

- Original Message - > On Sun, May 29, 2016 at 06:51:20PM -0600, Chris Murphy wrote: > > So there's tmux, screen, curl, wget, and probably quite a few others > > that don't necessarily get daemonized that are probably affected. > > I would really like to see a solution whereby tmux and s

Re: systemd 230 change - KillUserProcesses defaults to yes

On 01/06/16 10:20, Bastien Nocera wrote: On Sun, May 29, 2016 at 06:51:20PM -0600, Chris Murphy wrote: So there's tmux, screen, curl, wget, and probably quite a few others that don't necessarily get daemonized that are probably affected. I would really like to see a solution whereby tmux and

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, 2016-06-01 at 04:43 -0400, Matthew Miller wrote: > On Sun, May 29, 2016 at 06:51:20PM -0600, Chris Murphy wrote: > > > > So there's tmux, screen, curl, wget, and probably quite a few > > others > > that don't necessarily get daemonized that are probably affected. > I would really like to s

Re: systemd 230 change - KillUserProcesses defaults to yes

On Tue, 31.05.16 15:11, DJ Delorie (d...@redhat.com) wrote: > > Lennart Poettering writes: > > Sorry, but systemd is pretty exactly this: a process babysitter. > > It's becoming a user nanny instead. I wish it would stop trying to > enforce its "my way or the highway" approach to system rules.

Re: systemd 230 change - KillUserProcesses defaults to yes

Dne 31.5.2016 v 21:20 DJ Delorie napsal(a): > Lennart Poettering writes: >> Again, as mentioned before: key here is that permitting user processes >> to stick around after all sessions of the user ended needs to be a >> privilieged concept. It should not be allowed for user code to stick >> arou

Re: systemd 230 change - KillUserProcesses defaults to yes

- Original Message - > On 01/06/16 10:20, Bastien Nocera wrote: > > >> On Sun, May 29, 2016 at 06:51:20PM -0600, Chris Murphy wrote: > >>> So there's tmux, screen, curl, wget, and probably quite a few others > >>> that don't necessarily get daemonized that are probably affected. > >> > >

Re: systemd 230 change - KillUserProcesses defaults to yes

On 01/06/16 11:41, Bastien Nocera wrote: You've obviously never had to run something that's going to take hours or days to complete on a remote server and not wanted it to abort half way through because of a network glitch then. Yeah, I never used nohup. *roll eyes* Sure, nohup is like the c

Re: systemd 230 change - KillUserProcesses defaults to yes

Tom Hughes wrote: On 01/06/16 11:41, Bastien Nocera wrote: You've obviously never had to run something that's going to take hours or days to complete on a remote server and not wanted it to abort half way through because of a network glitch then. Yeah, I never used nohup. *roll eyes* Sure,

Re: systemd 230 change - KillUserProcesses defaults to yes

On 01/06/16 12:19, Howard Chu wrote: This is still looking at the problem back-asswards. The problem isn't that screen and tmux are special cases. The problem is that some handful of programs that got spawned in a GUI desktop environment are special cases, not exiting when they should. I'm sor

Orphaning few packages

Hello, Due to lack of time, I am orphaning following packages: rpms/PyXB -- Python XML Schema Bindings ( master f24 f23 f22 el6 el5 ) rpms/cvsclient -- CVS library for Java ( master f24 f23 f22 ) rpms/rngom -- Java library for parsing RELAX NG grammars ( master f24 f23 f22 ) rpms/spring-l

Re: systemd 230 change - KillUserProcesses defaults to yes

Tom Hughes wrote: On 01/06/16 12:19, Howard Chu wrote: This is still looking at the problem back-asswards. The problem isn't that screen and tmux are special cases. The problem is that some handful of programs that got spawned in a GUI desktop environment are special cases, not exiting when the

Fedora rawhide compose report: 20160601.n.0 changes

OLD: Fedora-Rawhide-20160531.n.0 NEW: Fedora-Rawhide-20160601.n.0 = SUMMARY = Added images:10 Dropped images: 0 Added packages: 7 Dropped packages:23 Upgraded packages: 66 Downgraded packages: 0 Size of added packages: 1.43 MiB Size of dropped packages

Re: systemd 230 change - KillUserProcesses defaults to yes

>> On Sun, May 29, 2016 at 06:51:20PM -0600, Chris Murphy wrote: >> > So there's tmux, screen, curl, wget, and probably quite a few others >> > that don't necessarily get daemonized that are probably affected. >> >> I would really like to see a solution whereby tmux and screen _just >> work_ withou

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 01, 2016 at 11:50:59AM +0200, Lennart Poettering wrote: > > > Sorry, but systemd is pretty exactly this: a process babysitter. > > It's becoming a user nanny instead. I wish it would stop trying to > > enforce its "my way or the highway" approach to system rules. I've been > > playing

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 01, 2016 at 12:43:38PM +0100, Howard Chu wrote: > >There are basically three things that I'm aware of that are used from a user > >session to run something in background in a way that will survive the end of > >the user session and you named them - nohup, screen and tmux. > Your awarene

Re: systemd 230 change - KillUserProcesses defaults to yes

Howard Chu writes: Fix the broken programs, don't force every well-behaved program in the universe to change to accommodate your broken GUI environment. This is Programming 101. This. Kudos to the tmux folks. They made the right call. pgpNzd8y4jAK5.pgp Description: PGP signature -- devel

Re: Orphaning few packages

Il 01/06/2016 13:37, Michal Srb ha scritto: Hello, Due to lack of time, I am orphaning following packages: hi take these rpms/spring-ldap -- Java library for simplifying LDAP operations ( master f24 f23 f22 ) rpms/springframework -- Spring Java Application Framework ( master f24 f23

Re: Orphaning few packages

On 06/01/2016 02:30 PM, gil wrote: Il 01/06/2016 13:37, Michal Srb ha scritto: Hello, Due to lack of time, I am orphaning following packages: hi take these Thank you gil ;) Michal rpms/spring-ldap -- Java library for simplifying LDAP operations ( master f24 f23 f22 ) rpms/sprin

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

On Ter, 2016-05-31 at 20:07 -0500, Rex Dieter wrote: > Sérgio Basto wrote: > > > > > On Ter, 2016-05-31 at 21:56 +, opensou...@till.name wrote: > > > > > > smb4k (maintained by: sergiomb, rdieter) > > > kde-plasma-smb4k-1.2.1-3.fc24.i686 requires > > > plasma4(scriptengine-declarativeapplets

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, 01.06.16 12:19, Howard Chu (h...@symas.com) wrote: > This is still looking at the problem back-asswards. The problem isn't that > screen and tmux are special cases. The problem is that some handful of > programs that got spawned in a GUI desktop environment are special cases, > not exiting

Fedora 24 compose report: 20160601.n.0 changes

OLD: Fedora-24-20160531.n.0 NEW: Fedora-24-20160601.n.0 = SUMMARY = Added images:10 Dropped images: 0 Added packages: 0 Dropped packages:24 Upgraded packages: 25 Downgraded packages: 0 Size of added packages: 0.00 B Size of dropped packages:124.57 MiB

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 01, 2016 at 03:48:04PM +0200, Lennart Poettering wrote: > Again, this isn't just work-arounds around broken programs. It's a > security thing. It's privileged code (logind, PID 1) that enforces a > clear life-cycle on unprivileged programs. > > Any scheme that relies on unprivileged pr

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 1, 2016 at 9:48 AM, Lennart Poettering wrote: > On Wed, 01.06.16 12:19, Howard Chu (h...@symas.com) wrote: > >> This is still looking at the problem back-asswards. The problem isn't that >> screen and tmux are special cases. The problem is that some handful of >> programs that got spaw

Re: systemd 230 change - KillUserProcesses defaults to yes

On Jun 1, 2016 3:03 AM, "Vít Ondruch" wrote: > > > > Dne 31.5.2016 v 21:20 DJ Delorie napsal(a): > > Lennart Poettering writes: > >> Again, as mentioned before: key here is that permitting user processes > >> to stick around after all sessions of the user ended needs to be a > >> privilieged conc

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 1, 2016 at 9:48 AM, Lennart Poettering wrote: > On Wed, 01.06.16 12:19, Howard Chu (h...@symas.com) wrote: > > > This is still looking at the problem back-asswards. The problem isn't > that > > screen and tmux are special cases. The problem is that some handful of > > programs that go

Fedora Rawhide-20160601.n.0 compose check report

Missing expected images: Cloud_base raw-xz i386 Atomic raw-xz x86_64 Kde raw-xz armhfp Minimal raw-xz armhfp Failed openQA tests: 34/73 (x86_64), 8/17 (i386) ID: 19976 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/19976 ID: 19978 Te

Re: Orphaning few packages

take also this one regards .g Il 01/06/2016 13:37, Michal Srb ha scritto: rpms/rngom -- Java library for parsing RELAX NG grammars ( master f24 f23 f22 ) -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, 2016-06-01 at 15:48 +0200, Lennart Poettering wrote: > > Any scheme that relies on unprivileged programs "being nice" doesn't > fix the inherent security problem: after logout a user should not be > able consume further runtime resources on the system, regardless if he > does that because

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 01, 2016 at 10:04:27AM -0400, Dan Book wrote: > > > > Again, this isn't just work-arounds around broken programs. It's a > > security thing. It's privileged code (logind, PID 1) that enforces a > > clear life-cycle on unprivileged programs. > > > > Any scheme that relies on unprivileged

Fedora 24-20160601.n.0 compose check report

Missing expected images: Cloud_base raw-xz i386 Failed openQA tests: 5/73 (x86_64), 1/17 (i386) ID: 20071 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/20071 ID: 20082 Test: x86_64 KDE-live-iso base_services_start URL: https://openq

Re: systemd 230 change - KillUserProcesses defaults to yes

On Jun 1, 2016 7:29 AM, "Tomasz Torcz" wrote: > > On Wed, Jun 01, 2016 at 10:04:27AM -0400, Dan Book wrote: > > > > > > Again, this isn't just work-arounds around broken programs. It's a > > > security thing. It's privileged code (logind, PID 1) that enforces a > > > clear life-cycle on unprivileg

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 1, 2016 at 10:28 AM, Tomasz Torcz wrote: > > > I think that programs needing special treatment should use operating > system's facilities to communicate that. So tmux, screen, nohup should > really open a new session. It's unfortunate that tmux author is hostile > against that, but

Re: systemd 230 change - KillUserProcesses defaults to yes

Hi, Lennart Poettering wrote on Wed, Jun 01, 2016 at 03:48:04PM +0200: > Again, this isn't just work-arounds around broken programs. It's a > security thing. It's privileged code (logind, PID 1) that enforces a > clear life-cycle on unprivileged programs. > > Any scheme that relies on unprivilege

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 01, 2016 at 07:35:21AM -0700, Andrew Lutomirski wrote: > On Jun 1, 2016 7:29 AM, "Tomasz Torcz" wrote: > > > > On Wed, Jun 01, 2016 at 10:04:27AM -0400, Dan Book wrote: > > > > > > > > Again, this isn't just work-arounds around broken programs. It's a > > > > security thing. It's privi

Re: systemd 230 change - KillUserProcesses defaults to yes

On 06/01/2016 02:01 PM, Josh Boyer wrote: Given the principle of least surprise, it would make more sense to default with this being disabled out of the box. I have to disagree with this statement. Upstream should always reflect how things should be while downstream reflects how things are o

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, 2016-06-01 at 09:59 -0400, Matthew Miller wrote: > > This paints a very specific premise of what a "logout" is, and I'm > not > sure I agree with it. There are actually many cases where I want to > use > resources on systems I have accounts on without specifically being > logged in — the

Re: systemd 230 change - KillUserProcesses defaults to yes

Matthias Clasen wrote: On Wed, 2016-06-01 at 09:59 -0400, Matthew Miller wrote: This paints a very specific premise of what a "logout" is, and I'm not sure I agree with it. There are actually many cases where I want to use resources on systems I have accounts on without specifically being logg

gnome-software integration

I'm looking into a bug filed against one of my applications (BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1330096). The complaint is that the gnome-software application picks up the xiphos-common package when the user tries to install from there, rather than picking up the actual GUI packages (w

Re: gnome-software integration

On 01/06/16 16:24, Greg Hellings wrote: I'm looking into a bug filed against one of my applications (BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1330096). The complaint is that the gnome-software application picks up the xiphos-common package when the user tries to install from there, rather

Re: gnome-software integration

On 06/01/2016 05:24 PM, Greg Hellings wrote: > I'm looking into a bug filed against one of my applications (BZ: > https://bugzilla.redhat.com/show_bug.cgi?id=1330096). The complaint is > that the gnome-software application picks up the xiphos-common package > when the user tries to install from the

Re: gnome-software integration

> xiphos-gtk2.rpm: > /usr/bin/xiphos-gtk2 > /usr/share/appdata/xiphos-gtk2.appdata.xml > /usr/share/applications/xiphos-gtk2.desktop > > xiphos-gtk3.rpm: > /usr/bin/xiphos-gtk3 > /usr/share/appdata/xiphos-gtk3.appdata.xml > /usr/share/applications/xiphos-gtk3.desktop I have to ask though: is it

Re: gnome-software integration

On 06/01/2016 05:43 PM, Matthias Clasen wrote: > >> xiphos-gtk2.rpm: >> /usr/bin/xiphos-gtk2 >> /usr/share/appdata/xiphos-gtk2.appdata.xml >> /usr/share/applications/xiphos-gtk2.desktop >> >> xiphos-gtk3.rpm: >> /usr/bin/xiphos-gtk3 >> /usr/share/appdata/xiphos-gtk3.appdata.xml >> /usr/share/appli

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

On 2016-05-31 20:07, Rex Dieter wrote: Nothing in rawhide should depend on strigi anymore. [snip] Are you implying that something *does* depend on it and/or you have a package that fails to build in rawhide? Disabling strigi/libstreamanalyzer support will cripple KFileMetaInfo: https://api.k

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 01, 2016 at 10:35:31AM -0400, Dan Book wrote: > As mentioned, this isn't just about screen, tmux, and nohup (or if there's > any other programs used in a similar context). *Any* command run with a > trailing & is commonly expected to survive logout, usually from remote > shells. Um, n

Re: systemd 230 change - KillUserProcesses defaults to yes

Solomon Peachy wrote: On Wed, Jun 01, 2016 at 10:35:31AM -0400, Dan Book wrote: As mentioned, this isn't just about screen, tmux, and nohup (or if there's any other programs used in a similar context). *Any* command run with a trailing & is commonly expected to survive logout, usually from remot

jplesnik uploaded Capture-Tiny-0.42.tar.gz for perl-Capture-Tiny

3ed62d55e84707f1287ff2ef236799d1 Capture-Tiny-0.42.tar.gz http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Capture-Tiny/Capture-Tiny-0.42.tar.gz/md5/3ed62d55e84707f1287ff2ef236799d1/Capture-Tiny-0.42.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 1, 2016 at 10:58 AM, Matthias Clasen wrote: > On Wed, 2016-06-01 at 09:59 -0400, Matthew Miller wrote: > > > > > This paints a very specific premise of what a "logout" is, and I'm > > not > > sure I agree with it. There are actually many cases where I want to > > use > > resources on

Re: gnome-software integration

On Wed, 2016-06-01 at 17:50 +0200, Kalev Lember wrote: > For what it's worth, I think it's totally fine to follow upstream's > recommendation and keep on just shipping the GTK2 version until the > GTK3 > version is ready. But then again I don't know anything about Xiphos, > so > maybe there is a go

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 01, 2016 at 05:11:13PM +0100, Howard Chu wrote: > > '&' in of itself was *never* any sort of guarantee, regardless of > > foolish expectations to the contrary. > > Wrong, for all csh users. > > You folks are all talking from quite narrow perspectives. You inadvertantly proved my poin

Python package reviewer wanted

I have two package review requests that have been stuck in limbo for a month and could use some help with. Both are fairly simple Python packages, part of Project Atomic[1] -- one a server, the other its CLI counterpart. If anyone has some cycles to spare on this I'd be grateful. https://bug

Re: gnome-software integration

On Wed, Jun 1, 2016 at 12:19 PM, wrote: > Date: Wed, 1 Jun 2016 17:38:15 +0200 > From: Kalev Lember > Subject: Re: gnome-software integration > To: Development discussions related to Fedora > > Message-ID: > Content-Type: text/plain; charset=utf-8 > > On 06/01/2016 05:24 PM, Greg Helli

Re: systemd 230 change - KillUserProcesses defaults to yes

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

Re: gnome-software integration

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

Re: Python package reviewer wanted

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

RE: systemd 230 change - KillUserProcesses defaults to yes

> -Original Message- > From: Vít Ondruch [mailto:vondr...@redhat.com] > Sent: Wednesday, June 01, 2016 06:03 > To: devel@lists.fedoraproject.org > Subject: Re: systemd 230 change - KillUserProcesses defaults to yes > > > How many users logs out if they leave their (single-user) computer?

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

The -D_FORTIFY_SOURCE=2 macro is added with -Wp,-D_FORTIFY_SOURCE=2. The only notes as to why that I can find are: commit 1518ff2d14377c05ecf7cf9428e42964516883b4 Author: Elliot Lee Date: Wed Feb 9 15:09:11 2005 + Fix java builds +* Wed Feb 9 2005 Elliot Lee 8.0.33-1 +- Change -D to

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 1, 2016 at 3:20 AM, Bastien Nocera wrote: > > > - Original Message - >> On Sun, May 29, 2016 at 06:51:20PM -0600, Chris Murphy wrote: >> > So there's tmux, screen, curl, wget, and probably quite a few others >> > that don't necessarily get daemonized that are probably affected.

Re: systemd 230 change - KillUserProcesses defaults to yes

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

Re: systemd 230 change - KillUserProcesses defaults to yes

On 05/27/2016 12:45 PM, Christopher wrote: It seems to me that what's happening is that systemd is now enforcing this "login session" perspective... metaphorically speaking, gluing the transparent overlay onto the map (but don't worry! they also provide a special adhesive remover!). This make

Re: systemd 230 change - KillUserProcesses defaults to yes

On 06/01/2016 02:19 PM, Przemek Klosowski wrote: > On 05/27/2016 12:45 PM, Christopher wrote: >> >> It seems to me that what's happening is that systemd is now enforcing this >> "login session" perspective... metaphorically speaking, gluing the >> transparent >> overlay onto the map (but don't wor

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 1, 2016 at 2:19 PM, Przemek Klosowski < przemek.klosow...@nist.gov> wrote: > On 05/27/2016 12:45 PM, Christopher wrote: > > > It seems to me that what's happening is that systemd is now enforcing this > "login session" perspective... metaphorically speaking, gluing the > transparent ov

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

On Wed, Jun 01, 2016 at 11:57:27AM -0600, Orion Poplawski wrote: > The -D_FORTIFY_SOURCE=2 macro is added with -Wp,-D_FORTIFY_SOURCE=2. The only > notes as to why that I can find are: > > commit 1518ff2d14377c05ecf7cf9428e42964516883b4 > Author: Elliot Lee > Date: Wed Feb 9 15:09:11 2005 +

Re: systemd 230 change - KillUserProcesses defaults to yes

On 06/01/2016 04:43 AM, Matthew Miller wrote: On Sun, May 29, 2016 at 06:51:20PM -0600, Chris Murphy wrote: So there's tmux, screen, curl, wget, and probably quite a few others that don't necessarily get daemonized that are probably affected. I would really like to see a solution whereby tmux

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

Hello, Today I noticed that rtmidi, a dependency of milkytracker, had gotten retired and this did also automatically retire milkytracker. I wish to become the point-of-contact for rtmidi and unretire both rtmidi and milkytracker. At [1] it looks as if a new review is not yet required for th

Re: Package retired by was taken (by me)

On Tue, May 31, 2016 at 11:04:18PM +0100, Athmane Madjoudj wrote: > It seems that s3ql package was retired today however I took the > package on 2016-05-16 and update it week later, see BZ #1249301 If you would like to maintain s3ql and the package it depends on, you can ask me or releng to get

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

On Wed, Jun 01, 2016 at 10:21:34PM +0300, Joonas Sarajärvi wrote: > I wish to become the point-of-contact for rtmidi and unretire both rtmidi > and milkytracker. This should have happened now. Currently it is best to file a ticket on the releng trac if these kind of unretirements are needed. Kin

Review swaps

I've got a handful of packages awaiting review, and am willing to swap for reviews with others. Take your pick: - gap-pkg-resclasses: https://bugzilla.redhat.com/show_bug.cgi?id=1336005 - gap-pkg-gbnp: https://bugzilla.redhat.com/show_bug.cgi?id=1340513 - gap-pkg-irredsol: https://bugzilla.redhat

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 01, 2016 at 02:08:13PM -0400, Solomon Peachy wrote: > > Fedora as a distro needs to determine which of these assumptions are > > valid *for Fedora* and set the defaults accordingly, as well as > > determining if/how to give users the freedom to set them differently. > I don't think it's

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 01, 2016 at 02:34:01PM -0400, Robert Marcano wrote: > >I would really like to see a solution whereby tmux and screen _just > >work_ without any required changes to user behavior. They're basically > >commands which _indicate_ "I want a new session that persists". > What about a default

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

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

Re: systemd 230 change - KillUserProcesses defaults to yes

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

Re: systemd 230 change - KillUserProcesses defaults to yes

On 06/01/2016 09:48 AM, Lennart Poettering wrote: On Wed, 01.06.16 12:19, Howard Chu (h...@symas.com) wrote: This is still looking at the problem back-asswards. The problem isn't that screen and tmux are special cases. The problem is that some handful of programs that got spawned in a GUI deskt

Re: systemd 230 change - KillUserProcesses defaults to yes

OK so back to a specific example on Fedora 24 with a restart/shutdown delay. User gdm owns session-c1.scope, and for some reason I can't figure out, it won't quit on its own. So it enters a failed state 1m30s after I ask for a restart/shutdown. [1] I edited /etc/systemd/logind.conf uncommented Kill

Re: systemd 230 change - KillUserProcesses defaults to yes

> Date: Wed, 1 Jun 2016 15:48:04 +0200 > From: Lennart Poettering > Subject: Re: systemd 230 change - KillUserProcesses defaults to yes > To: Development discussions related to Fedora > > Message-ID: <20160601134804.GB21606@gardel-login> > Content-Type: text/plain; charset=us-ascii > > O

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 01, 2016 at 03:22:45PM -0500, Justin Brown wrote: > On the topic of consistency, it makes the most sense to do same as > /usr/bin/yum currently does for nohup (tmux/screen/etc can become actual > Good call. Yum and dnf take logout inhibitors on the desktop, which helps in some cases,

Re: jwm

On 05/31/2016 01:31 PM, Bernardo Sulzbach wrote: I see you write from an @redhat.com address. Are you saying that all US-based RedHat developers get 45 hour work weeks or less? I'm talking about what the papers say, not the actual amount of work. I am not a labor lawyer so this is just my opi

Re: jwm

On 06/01/2016 06:21 PM, Przemek Klosowski wrote: So the answer to your question is that the papers say they work 40 hours per week, but in reality they work more. The employment law doesn't prescribe the actual number of hours worked by this class of employees, and the employer can set the work p

Re: jwm

On 06/01/2016 05:34 PM, Bernardo Sulzbach wrote: On 06/01/2016 06:21 PM, Przemek Klosowski wrote: So the answer to your question is that the papers say they work 40 hours per week, but in reality they work more. The employment law doesn't prescribe the actual number of hours worked by this class

Attempting to contact unresponsive maintainers - gabbayo and psss

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

Bugzilla email address sync

I recently updated my FAS account email forwarding address. Then, I got an email with the title "Please fix your bugzilla.redhat.com account" This email was notifying me that my bugzilla.redhat.com account email address did not match my FAS forwarding address. I'd really rather not broadcast my

Re: Bugzilla email address sync

On Wed, 01 Jun 2016 21:51:27 + Christopher wrote: > I recently updated my FAS account email forwarding address. > > Then, I got an email with the title "Please fix your > bugzilla.redhat.com account" > > This email was notifying me that my bugzilla.redhat.com account email > address did not

Re: Bugzilla email address sync

On Wed, Jun 1, 2016 at 5:56 PM Kevin Fenzi wrote: > On Wed, 01 Jun 2016 21:51:27 + > Christopher wrote: > > > I recently updated my FAS account email forwarding address. > > > > Then, I got an email with the title "Please fix your > > bugzilla.redhat.com account" > > > > This email was notif

Re: Bugzilla email address sync

On Wed, 01 Jun 2016 22:30:14 + Christopher wrote: > Thanks. I opened: > https://fedorahosted.org/fedora-infrastructure/ticket/5333 to address > the issue more broadly (I figure this would be useful to others, and > not just me). I don't think there's a more broad solution that will currently

Re: Bugzilla email address sync

On 2/06/2016 08:37, Kevin Fenzi wrote: > On Wed, 01 Jun 2016 22:30:14 + > Christopher wrote: > >> Thanks. I opened: >> https://fedorahosted.org/fedora-infrastructure/ticket/5333 to address >> the issue more broadly (I figure this would be useful to others, and >> not just me). > > I don't th

Re: Bugzilla email address sync

On Thu, 2 Jun 2016 09:05:55 +1000 Jeff Fearn wrote: > Hi, we expect to have SAML authentication working in Bugzilla 5, I'm > implimenting it for Red Hat customer accounts ATM and also testing > with FAS in the hopes we can get it "for free" :) Awesome. Great news indeed. :) kevin pgpnhSjY1OU

Re: Bugzilla email address sync

On Thu, Jun 02, 2016 at 09:05:55 +1000, Jeff Fearn wrote: Hi, we expect to have SAML authentication working in Bugzilla 5, I'm implimenting it for Red Hat customer accounts ATM and also testing with FAS in the hopes we can get it "for free" :) What IdPs are you going to support? Is it just g

Re: Bugzilla email address sync

On 2/06/2016 09:08, Bruno Wolff III wrote: > On Thu, Jun 02, 2016 at 09:05:55 +1000, > Jeff Fearn wrote: >> >> Hi, we expect to have SAML authentication working in Bugzilla 5, I'm >> implimenting it for Red Hat customer accounts ATM and also testing with >> FAS in the hopes we can get it "for fre

nfs bug - any info on bugzilla 1324635

Hi Guys, Anyone have any information on bugzilla 1324635. This seems like a private bug being tracked by redhat but is major and impacting us. Basically nfs gets impacted with large writes. Thanks! -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/d

Re: nfs bug - any info on bugzilla 1324635

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

Re: nfs bug - any info on bugzilla 1324635

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

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

 Following is the list of topics that will be discussed in the FPC meeting Thursday at 2016-06-03 16:00 UTC in #fedora-meeting-1 on irc.freenode.net.  Local time information (via. rktime): 2016-06-03 09:00 Fri US/Pacific PDT 2016-06-03 12:00 Fri US/Eastern EDT 2016-06-03 1

Re: systemd 230 change - KillUserProcesses defaults to yes

Dne 1.6.2016 v 18:18 Ben Rosser napsal(a): > > > On Wed, Jun 1, 2016 at 10:58 AM, Matthias Clasen > wrote: > > On Wed, 2016-06-01 at 09:59 -0400, Matthew Miller wrote: > > > > > This paints a very specific premise of what a "logout" is, and I'm > > not

Re: systemd 230 change - KillUserProcesses defaults to yes

On Wed, Jun 01, 2016 at 04:09:19PM +0100, Howard Chu wrote: > Matthias Clasen wrote: > > I am very much in favor of systemd enforcing that the session actually > > ends when I log out, so that I don't accidentally leave processes > > running. Leaking session processes have been a perennial problem