date:20110208

Re: Unavailable Maintainer: Peter Gordon

2011-02-08 Thread Dodji Seketeli

Kevin Fenzi ke...@scrye.com writes:

[...]

 It seems that Peter has been unavailable for Fedora packaging work for
 a while now.

[...]

 He maintains: 

[...]

 nemiver -- A GNOME C/C++ Debugger

FWIW, I actively co-maintain this one. If Peter is really overworked I
wouldn't mind taking ownership of the package.

Best wishes.

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

Re: [ACTION REQUIRED] orphaned packages in rawhide

2011-02-08 Thread Hans de Goede

Hi,

On 02/07/2011 09:59 PM, Bill Nottingham wrote:
 Each release, we undergo the effort to track down owners for orphaned
 packages in the release, and block those orphaned packages where
 necessary. It's that time again for Fedora 15.

 The following packages are currently orphaned and exist in F-15. As
 you can see, there are a lot of dependencies on these packages. Please
 pick up these packages if you have a need for them.


 Orphan atomix

I've taken atomix, co maintainers welcome.

Regards,

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

Re: NetworkManager doesn't start on boot

2011-02-08 Thread Lennart Poettering

On Fri, 04.02.11 13:31, Braden McDaniel (bra...@endoframe.com) wrote:

 
 On Thu, 2011-02-03 at 21:12 +0100, Lennart Poettering wrote: 
  On Mon, 31.01.11 02:22, Braden McDaniel (bra...@endoframe.com) wrote:
  
   I've recently set up a virtual machine running rawhide and I've noticed
   that NetworkManager never seems to start on boot; I must always start it
   manually.  As far as I can tell, it is configured to start on boot.  Is
   there something about the virtual machine context that would trigger
   this?
  
  what does systemctl status NetworkManager.service say?
 
 After booting and logging in as root:
 
 # systemctl status NetworkManager.service
 NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service)
   Active: inactive (dead)
   CGroup: name=systemd:/system/NetworkManager.service
 

Hmm, is it even enabled? Try systemctl is-enabled NetworkManager.service ; 
echo $? ?

Lennart

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

Re: Preferred Startup applications gone?

2011-02-08 Thread Kevin Kofler

Bastien Nocera wrote:

On Fri, 2011-02-04 at 08:52 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
it's a design feature, we are told. the intent is that applications
should offer the option to set themselves as the default, instead of
the desktop providing a central config point.

To the GNOME developers (Adam, I know you are just the messenger):

This is very broken. You cannot expect non-GNOME applications to support
setting themselves as the default in GNOME. (For example, if you want to
use, say, Konqueror as your default browser, how would you set that?
Konqueror obviously does not support GNOME preferences.)

There's no GNOME preferences involved. Make sure Konqueror sets itself
as the handler for x-scheme-handler/http (and https) and you're done.

Plus, we have seen where leaving this to the applications leads to on
Window$: applications fight for being the default and the user never gets
asked! Instead, merely running an app will change his/her file
associations, leading to a ping-pong effect. Please do not head down that
road!

We're talking about browsers and mailers. Browsers already do that.

KDE doesn't use x-scheme-handler for browsers at all. Instead, it has a
Default Components setting (very similar to GNOME 2's Preferred
Applications) where, for the browser, you can set it up to use the program
associated with the text/html file type (the default setting) or to use a
specific browser. (In fact, this was added in KDE 4, modeled on the GNOME 2
dialog. In KDE 3, it was hardcoded to always use the text/html file
association as a browser.)

In Fedora, the default text/html handler for KDE is set in
/usr/share/kde-settings/kde-profile/default/share/applications/defaults.list
with the following line:
text/html=kde4-konqueror.desktop;
We patch the startkde script to set XDG_DATA_DIRS so this setting is also
seen by non-KDE applications.

None of the browser packages I have installed override this setting. If I
want to change it, I have to either change the priorities for text/html in
the file associations or force a default browser in Default Components in
KDE's System Settings (or both).

See line 286 of:
http://quickgit.kde.org/?p=kdelibs.gita=blobh=c86a77b02f5bbcc3f357042afb6c6d1cb4bdcb2ahb=e737ed00d8782d82559d8a9ef9d3bef56ced0b49f=kdecore/kernel/ktoolinvocation_x11.cpp
for how this is implemented in KDE. (You'll notice that, when not running
the KDE Plasma Workspace, kdelibs will use xdg-open if installed, so GNOME's
way of handling URLs, including x-scheme-handler, will be used in that
case.)

As of KDE 4.6, KDE now supports x-scheme-handler for the things KDE's old
protocol handler scheme is used for, but that isn't quite the same thing as
what GNOME uses it for.

Kevin Kofler

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

Re: [ACTION REQUIRED] orphaned packages in rawhide

2011-02-08 Thread Kevin Kofler

Bill Nottingham wrote:
 Orphan k3b
 comaintained by: jreznik rdieter rnovacek

This one is well-maintained, but there was some misunderstanding over who's 
supposed to be the primary maintainer. This should get cleared up today.

 Orphan kcm_touchpad

I've taken this one. It is shipped on the KDE live image. Comaintainers 
welcome. (I'll lobby for comaintainers in today's KDE SIG meeting.)

 Orphan taglib
 comaintained by: rdieter

Dependency of many many things as shown in the report. I guess rdieter will 
pick this up, I'm going to ping him today.

Kevin Kofler

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

Re: NetworkManager doesn't start on boot

2011-02-08 Thread Braden McDaniel

On Tue, 2011-02-08 at 09:16 +0100, Lennart Poettering wrote: 
 On Fri, 04.02.11 13:31, Braden McDaniel (bra...@endoframe.com) wrote:
 
  
  On Thu, 2011-02-03 at 21:12 +0100, Lennart Poettering wrote: 
   On Mon, 31.01.11 02:22, Braden McDaniel (bra...@endoframe.com) wrote:
   
I've recently set up a virtual machine running rawhide and I've noticed
that NetworkManager never seems to start on boot; I must always start it
manually.  As far as I can tell, it is configured to start on boot.  Is
there something about the virtual machine context that would trigger
this?
   
   what does systemctl status NetworkManager.service say?
  
  After booting and logging in as root:
  
  # systemctl status NetworkManager.service
  NetworkManager.service - Network Manager
Loaded: loaded 
  (/lib/systemd/system/NetworkManager.service)
Active: inactive (dead)
CGroup: name=systemd:/system/NetworkManager.service
  
 
 Hmm, is it even enabled? Try systemctl is-enabled NetworkManager.service ; 
 echo $? ?

# systemctl is-enabled NetworkManager.service ; echo $?
1

I'm not sure whether 1 means it is or it isn't; but
system-config-services claims it's enabled.

-- 
Braden McDaniel bra...@endoframe.com

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

Re: NetworkManager doesn't start on boot

2011-02-08 Thread Lennart Poettering

On Tue, 08.02.11 04:44, Braden McDaniel (bra...@endoframe.com) wrote:

what does systemctl status NetworkManager.service say?
   
   After booting and logging in as root:
   
   # systemctl status NetworkManager.service
   NetworkManager.service - Network Manager
 Loaded: loaded 
   (/lib/systemd/system/NetworkManager.service)
 Active: inactive (dead)
 CGroup: name=systemd:/system/NetworkManager.service
   
  
  Hmm, is it even enabled? Try systemctl is-enabled NetworkManager.service ; 
  echo $? ?
 
 # systemctl is-enabled NetworkManager.service ; echo $?
 1

So, it isn't enabled. A zero exit code means it is enabled, a non-zero
exit code means it isn't. (that's normal unix logic, even if it appears
reversed)

Try enabling it via systemctl enable NetworkManager.service

Not sure what went wrong here, but normally this fragment in
Networkmanager.spec should ensure that the systemd service gets enabled
on upgrades from sysv versions:

%triggerin -- NetworkManager  1:0.8.1-5
if /sbin/chkconfig NetworkManager ; then
/bin/systemctl enable NetworkManager.service /dev/null 21 || :
fi

or is this a fresh install? if so, I am not entirely sure whose job it
is to enable NM initially after install. Dan?

 I'm not sure whether 1 means it is or it isn't; but
 system-config-services claims it's enabled.

s-c-s only covers sysv services. We probably should deprecate it or at
least add a bit of code to point out that whether a service is on or off
in sysv is ignored for native systemd services.

Lennart

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

Re: NetworkManager doesn't start on boot

2011-02-08 Thread Jon Masters

On Tue, 2011-02-08 at 11:04 +0100, Lennart Poettering wrote:
 On Tue, 08.02.11 04:44, Braden McDaniel (bra...@endoframe.com) wrote:

  I'm not sure whether 1 means it is or it isn't; but
  system-config-services claims it's enabled.
 
 s-c-s only covers sysv services. We probably should deprecate it or at
 least add a bit of code to point out that whether a service is on or off
 in sysv is ignored for native systemd services.

What utility are you recommending to replace it?

Jon.


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

Re: [ACTION REQUIRED] orphaned packages in rawhide

2011-02-08 Thread Richard Hughes

On 7 February 2011 20:59, Bill Nottingham nott...@redhat.com wrote:
 Orphan smolt

Don't we still use this by default on all spins?

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

Re: NetworkManager doesn't start on boot

2011-02-08 Thread Lennart Poettering

On Tue, 08.02.11 05:18, Jon Masters (jonat...@jonmasters.org) wrote:

 
 On Tue, 2011-02-08 at 11:04 +0100, Lennart Poettering wrote:
  On Tue, 08.02.11 04:44, Braden McDaniel (bra...@endoframe.com) wrote:
 
   I'm not sure whether 1 means it is or it isn't; but
   system-config-services claims it's enabled.
  
  s-c-s only covers sysv services. We probably should deprecate it or at
  least add a bit of code to point out that whether a service is on or off
  in sysv is ignored for native systemd services.
 
 What utility are you recommending to replace it?

Well, systemadm does some of this stuff, but doesn't really do
enabling/disabling of services, and also needs some love.

I guess my answer is to use systemctl enable foo.service and
systemctl disable foo.service until somebody comes up with an UI for
this (if one is actually needed).

Lennart

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

Re: incompatible screen update

2011-02-08 Thread Miroslav Lichvar

On Tue, Feb 08, 2011 at 08:42:52AM +0100, Lennart Poettering wrote:
 On Fri, 04.02.11 16:30, Miroslav Lichvar (mlich...@redhat.com) wrote:
  - $HOME/.screen is used as socket directory instead of
/var/run/screen
 
 $HOME is no place to place unix sockets. Unfortunately $HOME might be
 one weirdo file systems which do not support that. Expect bug reports
 about this soon.

Hm, screen wouldn't be the only one doing that, I see in my home
sockets belonging to rxvt-unicode and uim. Anyway, the directory can
be set by SCREENDIR environment variable.

Is this worse than allowing users to write in /var/run/screen? (bug #667252)

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: incompatible screen update

2011-02-08 Thread Lennart Poettering

On Tue, 08.02.11 12:09, Miroslav Lichvar (mlich...@redhat.com) wrote:

 
 On Tue, Feb 08, 2011 at 08:42:52AM +0100, Lennart Poettering wrote:
  On Fri, 04.02.11 16:30, Miroslav Lichvar (mlich...@redhat.com) wrote:
   - $HOME/.screen is used as socket directory instead of
 /var/run/screen
  
  $HOME is no place to place unix sockets. Unfortunately $HOME might be
  one weirdo file systems which do not support that. Expect bug reports
  about this soon.
 
 Hm, screen wouldn't be the only one doing that, I see in my home
 sockets belonging to rxvt-unicode and uim. Anyway, the directory can
 be set by SCREENDIR environment variable.
 
 Is this worse than allowing users to write in /var/run/screen? (bug #667252)

Good question.

Precisely for issues like this XDG_RUNTIME_DIR has recently been
introduced:

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

We carefully made sure to define the semantics of this dir to offer a
safe place to put these sockets.

While it might appear easy to simply make use of XDG_RUNTIME_DIR if set
in screen, and have all problems go away on modern systems (i.e. = F15),
but unfortunately things aren't that easy: the lifetime of
XDG_RUNTIME_DIR is strictly bound to the user being logged in. Since
screen currently does not set up a PAM session it does not count as
login right now and hence will not be able to use this dir when the user
terminates all his real logins.

That all said, I actually do believe that screen should invoke the PAM
session setup code. Ideally, one of those days we enable automatic
cleanup of all processes started from a session when a session
ends. That would break screen unless it is fixed to set up its own
session environment. So, sooner or later it would be really great to
have screen fixed this way.

Lennart

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

Re: [ACTION REQUIRED] orphaned packages in rawhide

2011-02-08 Thread Mat Booth

On 7 February 2011 20:59, Bill Nottingham nott...@redhat.com wrote:
 Each release, we undergo the effort to track down owners for orphaned
 packages in the release, and block those orphaned packages where
 necessary. It's that time again for Fedora 15.

 The following packages are currently orphaned and exist in F-15. As
 you can see, there are a lot of dependencies on these packages. Please
 pick up these packages if you have a need for them.


 Orphan maven-doxia-tools
 Orphan maven-javadoc-plugin
 Orphan plexus-cli
 Orphan plexus-registry
        comaintained by: akurtakov


I'm not sure how these java-sig packages ended up orphaned, I guess
one of us should pick them up.

-- 
Mat Booth
http://fedoraproject.org/get-fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 671389] perl-RPM2 cannot be compiled against rpm-4.9.0

2011-02-08 Thread bugzilla

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

Michael Scherer m...@zarb.org changed:

   What|Removed |Added

 CC||m...@zarb.org

--- Comment #5 from Michael Scherer m...@zarb.org 2011-02-08 06:45:14 EST ---
Well, while the naming doesn't affect the fact it can be distributed, and while
I can understand the branding issue ( but would not consider blocker as there
is also others perl packages with such namespace, like Danga::Socket ), the
lack of clear tarball may be more annoying. 

That's something we plan to address in the Mageia project, and also we will try
to upload to CPAN if it make sense. 

And that wouldn't be the first Mandriva software in Fedora, there is
monitor-edid, prcsys, xsettings-kde.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- 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-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: [ACTION REQUIRED] orphaned packages in rawhide

2011-02-08 Thread Mat Booth

On 8 February 2011 11:47, Mat Booth fed...@matbooth.co.uk wrote:
 On 7 February 2011 20:59, Bill Nottingham nott...@redhat.com wrote:
 Each release, we undergo the effort to track down owners for orphaned
 packages in the release, and block those orphaned packages where
 necessary. It's that time again for Fedora 15.

 The following packages are currently orphaned and exist in F-15. As
 you can see, there are a lot of dependencies on these packages. Please
 pick up these packages if you have a need for them.


 Orphan maven-doxia-tools
 Orphan maven-javadoc-plugin
 Orphan plexus-cli
 Orphan plexus-registry
        comaintained by: akurtakov


 I'm not sure how these java-sig packages ended up orphaned, I guess
 one of us should pick them up.


Except for plexus-registry, which should be retired.


-- 
Mat Booth
http://fedoraproject.org/get-fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] orphaned packages in rawhide

2011-02-08 Thread Stanislav Ochotnicky

On 02/08/2011 12:47 PM, Mat Booth wrote:
 On 7 February 2011 20:59, Bill Nottingham nott...@redhat.com wrote:
 Each release, we undergo the effort to track down owners for orphaned
 packages in the release, and block those orphaned packages where
 necessary. It's that time again for Fedora 15.

 The following packages are currently orphaned and exist in F-15. As
 you can see, there are a lot of dependencies on these packages. Please
 pick up these packages if you have a need for them.


 Orphan maven-doxia-tools
 Orphan maven-javadoc-plugin
 Orphan plexus-cli
 Orphan plexus-registry
comaintained by: akurtakov
 
 
 I'm not sure how these java-sig packages ended up orphaned, I guess
 one of us should pick them up.

There are more java packages than that (akurtakov counted 14 if I am not
mistaken). We are still sorting things after returning from FOSDEM
now...so expect info on that later :-)


-- 
Stanislav Ochotnicky sochotni...@redhat.com
Associate Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com



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

Re: [ACTION REQUIRED] orphaned packages in rawhide

2011-02-08 Thread Alexander Kurtakov

On 01:56:00 pm Tuesday, February 08, 2011 Mat Booth wrote:
 On 7 February 2011 20:59, Bill Nottingham nott...@redhat.com wrote:
  Each release, we undergo the effort to track down owners for orphaned
  packages in the release, and block those orphaned packages where
  necessary. It's that time again for Fedora 15.
  
  The following packages are currently orphaned and exist in F-15. As
  you can see, there are a lot of dependencies on these packages. Please
  pick up these packages if you have a need for them.
  
  
  Orphan maven-doxia-tools
  Orphan maven-javadoc-plugin
  Orphan plexus-cli
  Orphan plexus-registry
 comaintained by: akurtakov
 
 I'm not sure how these java-sig packages ended up orphaned, I guess
 one of us should pick them up.

These were mef's packages and she has better things to do now :).
Current list of java packages that need maintainers according to me is:
Orphan apache-resource-bundles
Orphan maven-doxia-tools
Orphan maven-javadoc-plugin
Orphan plexus-cli
Orphan plexus-registry
Orphan pmd
Orphan geronimo-jms
Orphan geronimo-jta
Orphan geronimo-parent-poms
Orphan janino
Orphan logback

I would welcome everyone helping Java SIG because we are really short on 
people.

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

Re: [ACTION REQUIRED] orphaned packages in rawhide

2011-02-08 Thread Alexander Kurtakov

On 01:59:44 pm Tuesday, February 08, 2011 Mat Booth wrote:
 On 8 February 2011 11:47, Mat Booth fed...@matbooth.co.uk wrote:
  On 7 February 2011 20:59, Bill Nottingham nott...@redhat.com wrote:
  Each release, we undergo the effort to track down owners for orphaned
  packages in the release, and block those orphaned packages where
  necessary. It's that time again for Fedora 15.
  
  The following packages are currently orphaned and exist in F-15. As
  you can see, there are a lot of dependencies on these packages. Please
  pick up these packages if you have a need for them.
  
  
  Orphan maven-doxia-tools
  Orphan maven-javadoc-plugin
  Orphan plexus-cli
  Orphan plexus-registry
 comaintained by: akurtakov
  
  I'm not sure how these java-sig packages ended up orphaned, I guess
  one of us should pick them up.
 
 Except for plexus-registry, which should be retired.

Yes, correct. I counted it in without thinking too much.
would you please kill it Mat?

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

Re: [ACTION REQUIRED] orphaned packages in rawhide

2011-02-08 Thread Mat Booth

On 8 February 2011 12:00, Alexander Kurtakov akurt...@redhat.com wrote:
 On 01:59:44 pm Tuesday, February 08, 2011 Mat Booth wrote:
 On 8 February 2011 11:47, Mat Booth fed...@matbooth.co.uk wrote:
  On 7 February 2011 20:59, Bill Nottingham nott...@redhat.com wrote:
  Each release, we undergo the effort to track down owners for orphaned
  packages in the release, and block those orphaned packages where
  necessary. It's that time again for Fedora 15.
 
  The following packages are currently orphaned and exist in F-15. As
  you can see, there are a lot of dependencies on these packages. Please
  pick up these packages if you have a need for them.
 
 
  Orphan maven-doxia-tools
  Orphan maven-javadoc-plugin
  Orphan plexus-cli
  Orphan plexus-registry
         comaintained by: akurtakov
 
  I'm not sure how these java-sig packages ended up orphaned, I guess
  one of us should pick them up.

 Except for plexus-registry, which should be retired.

 Yes, correct. I counted it in without thinking too much.
 would you please kill it Mat?

 Alex
 --

Ticket filed with rel-eng:

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

I took maven* and plexus-cli.

-- 
Mat Booth
http://fedoraproject.org/get-fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: boost 1.46.0

2011-02-08 Thread Petr Machata

07.02.2011 20:03, Zach Carter wrote:
 I believe my package schroot may have been hit by a 1.46 issue that is fixed 
 in
 1.47

 Is there a plan to update to 1.47 or backport the fixes?

Not in a systematic manner, but generally yes, we do fixes of this sort.


  From the 1.47 changelog:

 Doc fixes: Update release history, add tables of macros and deprecated names.
 Bug fix: convenience.hpp didn't fully apply BOOST_FILESYSTEM_NO_DEPRECATED to
 name changes.
 Bug fix: Ticket #1972 'remove' fixes.
 Bug fix: Restore deprecated basic_directory_entry names inadvertently removed.
 Bug fix: Provide deprecated functions has_branch_path and has_leaf,
 inadvertently omitted from 1.36.0
 Add workarounds for Codegear/Borland C++ Builder 2009.

Actually I found the above in 1.37 (not 47) changelog.  The ticket #1972 
has been closed for years.  See:
http://www.boost.org/doc/libs/1_45_0/libs/filesystem/v2/doc/index.htm

  From 
 http://koji.fedoraproject.org/koji/getfile?taskID=2765676name=build.log:

 sbuild-chroot-config.cc: In member function 'void
 sbuild::chroot_config::add_config_directory(const string, const string)':
 sbuild-chroot-config.cc:170:32: error: 'class
 boost::filesystem3::directory_entry' has no member named 'leaf'

If there's a lot of problems like this, compile with 
-DBOOST_FILESYSTEM_VERSION=2 and have upstream decide what to do 
long-term.  In this particular case, you should be able to replace 
leaf() with path().filename().string().

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

Re: incompatible screen update

2011-02-08 Thread Tomas Mraz

On Tue, 2011-02-08 at 12:40 +0100, Lennart Poettering wrote: 
 On Tue, 08.02.11 12:09, Miroslav Lichvar (mlich...@redhat.com) wrote:
 
  
  On Tue, Feb 08, 2011 at 08:42:52AM +0100, Lennart Poettering wrote:
   On Fri, 04.02.11 16:30, Miroslav Lichvar (mlich...@redhat.com) wrote:
- $HOME/.screen is used as socket directory instead of
  /var/run/screen
   
   $HOME is no place to place unix sockets. Unfortunately $HOME might be
   one weirdo file systems which do not support that. Expect bug reports
   about this soon.
  
  Hm, screen wouldn't be the only one doing that, I see in my home
  sockets belonging to rxvt-unicode and uim. Anyway, the directory can
  be set by SCREENDIR environment variable.
  
  Is this worse than allowing users to write in /var/run/screen? (bug #667252)
 
 Good question.
 
 Precisely for issues like this XDG_RUNTIME_DIR has recently been
 introduced:
 
 http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
 
 We carefully made sure to define the semantics of this dir to offer a
 safe place to put these sockets.
 
 While it might appear easy to simply make use of XDG_RUNTIME_DIR if set
 in screen, and have all problems go away on modern systems (i.e. = F15),
 but unfortunately things aren't that easy: the lifetime of
 XDG_RUNTIME_DIR is strictly bound to the user being logged in. Since
 screen currently does not set up a PAM session it does not count as
 login right now and hence will not be able to use this dir when the user
 terminates all his real logins.
 
 That all said, I actually do believe that screen should invoke the PAM
 session setup code. Ideally, one of those days we enable automatic
 cleanup of all processes started from a session when a session
 ends. That would break screen unless it is fixed to set up its own
 session environment. So, sooner or later it would be really great to
 have screen fixed this way.

The problem is it would require making screen setuid root which I do not
think it is too good idea. 

I think much more reasonable is to just accept the fact that it might be
very reasonable and desirable on some multiuser system to allow users
having background processes that can keep running even after the user
logs out and not to try to enforce rules such as no user process left
after logout blindly on all systems.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: [ACTION REQUIRED] orphaned packages in rawhide

2011-02-08 Thread Daniel J Walsh

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I took matchpbox-window-manager needed for sandbox.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1RUQUACgkQrlYvE4MpobPj8QCgy0OGT3Ukex0bspNQTbIZhGPr
Ql0AnA6+cFgcmt5eqZXKCybXBCAo9oE6
=AqOj
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] orphaned packages in rawhide

2011-02-08 Thread Bruno Wolff III

On Tue, Feb 08, 2011 at 10:24:46 +,
  Richard Hughes hughsi...@gmail.com wrote:
 On 7 February 2011 20:59, Bill Nottingham nott...@redhat.com wrote:
  Orphan smolt
 
 Don't we still use this by default on all spins?

I am pretty sure we want to keep this one. The source is on Fedora Hosted.
It would be nice of one of the upstream guys picked this up.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: incompatible screen update

2011-02-08 Thread Martin Dengler

On Tue, Feb 08, 2011 at 03:05:03PM +0100, Tomas Mraz wrote:
 [Let's] not to try to enforce rules such as no user process left
 after logout blindly on all systems.

Not that I disagree with your statement (I tend to agree) in general,
but how is screen is running but detached morally equivalent to
logout?

Martin


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

Re: incompatible screen update

2011-02-08 Thread Tomas Mraz

On Tue, 2011-02-08 at 14:28 +, Martin Dengler wrote: 
 On Tue, Feb 08, 2011 at 03:05:03PM +0100, Tomas Mraz wrote:
  [Let's] not to try to enforce rules such as no user process left
  after logout blindly on all systems.
 
 Not that I disagree with your statement (I tend to agree) in general,
 but how is screen is running but detached morally equivalent to
 logout?

That's just a philosophical question. For example if you detach screen
you are dropped to the original session and you really logout out of it.
And you are not really connected to the detached screen - it is detached
because noone is attached to it isn't it? :) So it is definitely not a
live login session because noone can interact with it unless he opens a
real session and runs a screen to reattach it.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: libedit update

2011-02-08 Thread Kevin Kofler

Jerry James wrote:
 In particular, the latest version includes wide character (Unicode)
 support.

So, is it time to replace the old unmaintained compat-readline5 which is 
kept only for licensing reasons with this now?

And would it make sense to try to replace readline with libedit systemwide, 
even? It feels quite silly to have multiple implementations of the exact 
same API for licensing reasons, and the libedit license should be compatible 
with everything.

Kevin Kofler

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

[Bug 675992] New: perl-Wx does not provide perl(Wx::Process) and perl(Wx::PlCommandEvent)

2011-02-08 Thread bugzilla

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: perl-Wx does not provide perl(Wx::Process) and perl(Wx::PlCommandEvent)

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

   Summary: perl-Wx does not provide perl(Wx::Process) and
perl(Wx::PlCommandEvent)
   Product: Fedora
   Version: rawhide
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Severity: unspecified
  Priority: unspecified
 Component: perl-Wx
AssignedTo: tcall...@redhat.com
ReportedBy: ppi...@redhat.com
 QAContact: extras...@fedoraproject.org
CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com
Classification: Fedora


I got an error message:

perl-Wx-Perl-ProcessStream has broken dependencies in the rawhide tree:
On x86_64:
perl-Wx-Perl-ProcessStream-0.30-1.fc15.noarch requires
perl(Wx::Process)
perl-Wx-Perl-ProcessStream-0.30-1.fc15.noarch requires
perl(Wx::PlCommandEvent)

perl-Wx-Perl-ProcessStream contains this code:
  #-
  # PACKAGE Wx::Perl::ProcessStream::Process
  #
  # Adds some extra methods to Wx::Process
  #-
  package Wx::Perl::ProcessStream::Process;
  use base qw( Wx::Process );

The Wx::Process module is defined in perl-Wx sources in XS/Process.xs:31:
  MODULE=Wx PACKAGE=Wx::Process

thus the symbol becomes defined by using Wx. From point of view of perl is
everything Ok.

Problem is rpmbuild cannot discover the symbol from
/usr/lib64/perl5/vendor_perl/auto/Wx/Wx.so.

Could you please add:
  Provides: perl(Wx::Process)
  Provides: perl(Wx::PlCommandEvent)
into perl-Wx.spec?

Better solution would be if Wx CPAN upstream added void file declaring the XS
modules (together with POD documentation).

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- 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-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: incompatible screen update

2011-02-08 Thread Martin Dengler

O
n Tue, Feb 08, 2011 at 03:33:08PM +0100, Tomas Mraz wrote:
 On Tue, 2011-02-08 at 14:28 +, Martin Dengler wrote: 
  On Tue, Feb 08, 2011 at 03:05:03PM +0100, Tomas Mraz wrote:
   [Let's] not to try to enforce rules such as no user process left
   after logout blindly on all systems.
  
  Not that I disagree with your statement (I tend to agree) in general,
  but how is screen is running but detached morally equivalent to
  logout?
 
 That's just a philosophical question.

If we're going to talk about logout a definition of it is useful,
philosopical or not :).

 For example if you detach screen you are dropped to the original
 session and you really logout out of it.  And you are not really
 connected to the detached screen - it is detached because noone is
 attached to it isn't it? :)

Agreed...

 So it is definitely not a live login session because noone can
 interact with it unless he opens a real session and runs a screen to
 reattach it.

I agree except to all intents and purposes one is meant to be
*connected* in a significant way when a screen session is active
(attached or not).

With its goal being a window manager[1] with virtual terminals[1]
that persist even when the whole screen session is detached[1], it
sounds to me like it should create a session[2] or live login
session in the sense of it not being killed when there are no users
connected to its terminal.

This is what I understood when you said we should deem background
processes worthy-of-not-being-killed and why I said I tended to agree
with your statement[3] - and Lennart's[2]: they are saying the same
thing, except that session seems well defined (but not
philosophically) and logout does not.

Martin

1. http://www.gnu.org/software/screen/

2. http://lists.fedoraproject.org/pipermail/devel/2011-February/148459.html

 I actually do believe that screen should invoke the PAM
 session setup code 
...that is, create a session == login (for purposes of this
discussion)

3. [I]t might be very reasonable and desirable on some multiuser
system to allow users having background processes that can keep
running even after the user logs out - although I think multiuser
is unnecessarily restrictive.



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

Re: [ACTION REQUIRED] orphaned packages in rawhide

2011-02-08 Thread Peter Robinson

 Orphan libfakekey

I grabbed this one.

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

Re: NetworkManager doesn't start on boot

2011-02-08 Thread Braden McDaniel

On Tue, 2011-02-08 at 11:04 +0100, Lennart Poettering wrote: 
 On Tue, 08.02.11 04:44, Braden McDaniel (bra...@endoframe.com) wrote:
 
 what does systemctl status NetworkManager.service say?

After booting and logging in as root:

# systemctl status NetworkManager.service
NetworkManager.service - Network Manager
  Loaded: loaded 
(/lib/systemd/system/NetworkManager.service)
  Active: inactive (dead)
  CGroup: name=systemd:/system/NetworkManager.service

   
   Hmm, is it even enabled? Try systemctl is-enabled NetworkManager.service 
   ; echo $? ?
  
  # systemctl is-enabled NetworkManager.service ; echo $?
  1
 
 So, it isn't enabled. A zero exit code means it is enabled, a non-zero
 exit code means it isn't. (that's normal unix logic, even if it appears
 reversed)
 
 Try enabling it via systemctl enable NetworkManager.service
 
 Not sure what went wrong here, but normally this fragment in
 Networkmanager.spec should ensure that the systemd service gets enabled
 on upgrades from sysv versions:
 
 %triggerin -- NetworkManager  1:0.8.1-5
 if /sbin/chkconfig NetworkManager ; then
 /bin/systemctl enable NetworkManager.service /dev/null 21 || :
 fi
 
 or is this a fresh install? if so, I am not entirely sure whose job it
 is to enable NM initially after install. Dan?

I installed F14 from DVD and immediately did a yum upgrade to rawhide.

  I'm not sure whether 1 means it is or it isn't; but
  system-config-services claims it's enabled.
 
 s-c-s only covers sysv services. We probably should deprecate it or at
 least add a bit of code to point out that whether a service is on or off
 in sysv is ignored for native systemd services.

Why not fix it?  That is, why should a user of this app care whether a
service is SysV or systemd?  Or, is this app being replaced by some
other UI?

-- 
Braden McDaniel bra...@endoframe.com

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

Re: NetworkManager doesn't start on boot

2011-02-08 Thread Rahul Sundaram

On 02/08/2011 09:09 PM, Braden McDaniel wrote:

 Why not fix it?  That is, why should a user of this app care whether a
 service is SysV or systemd?  Or, is this app being replaced by some
 other UI?

Also is there a plan to modify chkconfig in a similar way to service so
that it calls systemctl if it is a systemd service?  That would make the
transition less abrupt

Rahul

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

Re: [ACTION REQUIRED] orphaned packages in rawhide

2011-02-08 Thread Adam Jackson

Bill Nottingham wrote:
 Orphan libgle

Taken.

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

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1106 matches

Mail list logo