Re: 9base in Fedora?

[Petr Sabata]

On Tue, May 24, 2011 at 10:59:27AM -0600, Stephen John Smoogen wrote:
> On Tue, May 24, 2011 at 10:35, Matthew Miller  wrote:
> > On Tue, May 24, 2011 at 09:28:02AM +0200, Nicolas Mailhot wrote:
> >> There is no reason not to put them in /usr/lib(64). That's where common
> >> binaries such as firefox, java, etc already reside. They all have magic
> >> env variables to define their root for scripts and
> >> symlinks/wrappers/alternatives in /usr/bin
> >
> >
> > In this case, though, there wouldn't be wrappers or scripts in /usr/bin.
> 
> Ok looking at how convoluted we are having to get this package in..
> what are the reasons to have it in Fedora? Would some other way of
> producing them having them available be there? Who is going to benefit
> from them being there? Etc
> 

Simply to make Fedora better. I'd like to make those available for our users.
There are currently no other packages relying on this set (or rc, to be more
specific) in Fedora. That could change in the future, though.

-- 
# Petr Sabata


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

Re: which video player for a package Requires ?

[jaroslav]

Hi,

Wiadomość napisana w dniu 2011-05-25, o godz. 00:31, przez Domingo  
Becker:

> 2011/5/24 Nicoleau Fabien :
>> Hi,
>> I'm packaging a software that downloads videos from websites like
>> youtube, dailymotion, etc ...
(...)

>> My question is :
>> what am I suppose to set in "Requires" field for the package ?  
>> totem ?
>> something generic ? nothing ?
>>
>
> I play videos downloaded from websites like the ones you mention with
> totem (.flv and .mp4).
> The Requires would be totem and gstreamer-ffmpeg (from rpmfusion- 
> free).
>

Please, no! I think I wouldn't be the only person really pissed, when  
some package tries to fetch some media player whcih I don't need  
because I use a different one.

regards,

JG.

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

[perl-SQL-Shell/f14] add requires 707442

[Marcela Mašláňová]

commit bd30708f4aa71fa53ee8a8147d991be16ec2f604
Author: Marcela Mašláňová 
Date:   Wed May 25 10:47:29 2011 +0200

add requires 707442

 perl-SQL-Shell.spec |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)
---
diff --git a/perl-SQL-Shell.spec b/perl-SQL-Shell.spec
index 69f6143..239df2b 100644
--- a/perl-SQL-Shell.spec
+++ b/perl-SQL-Shell.spec
@@ -1,6 +1,6 @@
 Name:   perl-SQL-Shell 
 Version:1.14 
-Release:5%{?dist}
+Release:6%{?dist}
 # lib/SQL/Shell.pm -> GPLv2 (refers to "the GPL", bundled COPYING is GPLv2)
 License:GPLv2
 Group:  Development/Libraries
@@ -39,6 +39,8 @@ License:GPL+ or Artistic
 Group:  Development/Libraries
 Summary:Command interperter for DBI shells
 Requires:   %{name} = %{version}-%{release}
+Requires:   perl(IO::Scalar)
+Requires:   perl(Term::ReadLine::Gnu)
 
 %description -n sqlsh
 sqlsh is a command-interpreter API for building shells and batch
@@ -81,6 +83,9 @@ rm -rf %{buildroot}
 %{_mandir}/man1/sqlsh.1.gz
 
 %changelog
+* Wed May 25 2011 Marcela Mašláňová  - 1.14-6
+- add requires 707442
+
 * Thu May 06 2010 Marcela Maslanova  - 1.14-5
 - Mass rebuild with perl-5.12.0
 
--
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: UID_MIN & GID_MIN changed

[Peter Vrabec]

Hi,

On Tuesday, May 24, 2011 05:25:44 PM Toshio Kuratomi wrote:
> On Tue, May 24, 2011 at 1:59 AM, Peter Vrabec  wrote:
> > Hi all,
> > 
> > I'd like to inform you that I have changed UID_MIN & GID_MIN from 500 to
> > 1000 in upgraded shadow-utils.
> > 
> > Where?
> > /etc/login.defs.
> > shadow-utils-4.1.4.3-1.fc16
> > 
> > I suppose UID/GID_MIN=1000 is more common(other distros, upstream). We
> > are not in situation that 500 IDs for system accounts ought to be enough
> > for anybody. Actually, it was not 500.It was 299 because range 0-200 is
> > for reserved IDs. There are 799 non reserved IDs for system accounts
> > available after this change.
> 
> This change should be made as a Feature for F16 and needs some
> thought/coordination put behind it.  There's several issues that I
> see:
> 
> * AFAIK, we actually have not run into the 500 uid limit yet (although
> it is a bit low to be comfortable)
> *  AFAIK, we've only allocated the range 0-100 for reserved IDs.
> * The 0-100 reserved IDs are actually the pain point that we need to
> deal with, not the dynamic system ids in the 101-499 range.
We use 0-200 for reserved IDs  since
http://lists.fedoraproject.org/pipermail/devel/2009-April/028740.html

> * We don't know how many, if any IDs this actually gets us for the
> dynamic range because any site that has already filled the 500-1000
> UID range won't gain any extra dynamic system account through this
> change.
> * This could potentially break sites that are currently using the
> 500-1000 UID range and rely on the order of allocation of UIDs for
> their users on new machines matching with the UIDs on old machines.
> (For instance, NFS UIDs on filesystems matching between a box
> installed with RHEL5 and a box that gets newly installed with F16).
> 
> -Toshio

I'm not against wider announcement. I'm just not sure what is the right way - 
F16 Feature/Release Notes/  ? We can also annouce the 200 limit for 
reserved IDs. ;)

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

[perl-SQL-Shell/f15] add requires 707442

[Marcela Mašláňová]

commit c40655ac2077311c2cccd8a58418e4e73450dd53
Author: Marcela Mašláňová 
Date:   Wed May 25 10:55:12 2011 +0200

add requires 707442

clean specfile.

 perl-SQL-Shell.spec |   16 +++-
 1 files changed, 7 insertions(+), 9 deletions(-)
---
diff --git a/perl-SQL-Shell.spec b/perl-SQL-Shell.spec
index e9a410c..e10b0a0 100644
--- a/perl-SQL-Shell.spec
+++ b/perl-SQL-Shell.spec
@@ -1,13 +1,12 @@
 Name:   perl-SQL-Shell 
 Version:1.14 
-Release:7%{?dist}
+Release:8%{?dist}
 # lib/SQL/Shell.pm -> GPLv2 (refers to "the GPL", bundled COPYING is GPLv2)
 License:GPLv2
 Group:  Development/Libraries
 Summary:Command interpreter for DBI shells 
 Source: 
http://search.cpan.org/CPAN/authors/id/B/BB/BBC/SQL-Shell-%{version}.tar.gz 
 Url:http://search.cpan.org/dist/SQL-Shell
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) 
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 BuildArch:  noarch
 
@@ -39,6 +38,8 @@ License:GPL+ or Artistic
 Group:  Development/Libraries
 Summary:Command interperter for DBI shells
 Requires:   %{name} = %{version}-%{release}
+Requires:   perl(IO::Scalar)
+Requires:   perl(Term::ReadLine::Gnu)
 
 %description -n sqlsh
 sqlsh is a command-interpreter API for building shells and batch
@@ -55,8 +56,6 @@ See the SQL::Shell::Manual manpage for a user guide.
 make %{?_smp_mflags}
 
 %install
-rm -rf %{buildroot}
-
 make pure_install PERL_INSTALL_ROOT=%{buildroot}
 find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
 find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null ';'
@@ -66,21 +65,20 @@ find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null 
';'
 %check
 make test
 
-%clean
-rm -rf %{buildroot} 
-
 %files
-%defattr(-,root,root,-)
 %doc COPYING Changes README 
 %{perl_vendorlib}/*
 %{_mandir}/man3/*.3*
 
 %files -n sqlsh
-%defattr(-,root,root,-)
 %{_bindir}/sqlsh
 %{_mandir}/man1/sqlsh.1.gz
 
 %changelog
+* Wed May 25 2011 Marcela Mašláňová  - 1.14-8
+- add requires 707442
+- clean specfile
+
 * Wed Feb 09 2011 Fedora Release Engineering  
- 1.14-7
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
 
--
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: UID_MIN & GID_MIN changed

[Ondrej Vasik]

On Wed, 2011-05-25 at 10:55 +0200, Peter Vrabec wrote:
> Hi,
> 
> On Tuesday, May 24, 2011 05:25:44 PM Toshio Kuratomi wrote:
> > On Tue, May 24, 2011 at 1:59 AM, Peter Vrabec  wrote:
> > > Hi all,
> > > 
> > > I'd like to inform you that I have changed UID_MIN & GID_MIN from 500 to
> > > 1000 in upgraded shadow-utils.
> > > 
> > > Where?
> > > /etc/login.defs.
> > > shadow-utils-4.1.4.3-1.fc16
> > > 
> > > I suppose UID/GID_MIN=1000 is more common(other distros, upstream). We
> > > are not in situation that 500 IDs for system accounts ought to be enough
> > > for anybody. Actually, it was not 500.It was 299 because range 0-200 is
> > > for reserved IDs. There are 799 non reserved IDs for system accounts
> > > available after this change.
> > 
> > This change should be made as a Feature for F16 and needs some
> > thought/coordination put behind it.  There's several issues that I
> > see:
> > 
> > * AFAIK, we actually have not run into the 500 uid limit yet (although
> > it is a bit low to be comfortable)
> > *  AFAIK, we've only allocated the range 0-100 for reserved IDs.
> > * The 0-100 reserved IDs are actually the pain point that we need to
> > deal with, not the dynamic system ids in the 101-499 range.
> We use 0-200 for reserved IDs  since
> http://lists.fedoraproject.org/pipermail/devel/2009-April/028740.html

Actually since July 2009 - there are no free uid/gid's left bellow 100.
And yes, I'm giving static assignments only for system accounts which
potentially can handle/own sensitive information or do communicate with
other systems - so I rejected some requests for static ID's reservation.

> 
> > * We don't know how many, if any IDs this actually gets us for the
> > dynamic range because any site that has already filled the 500-1000
> > UID range won't gain any extra dynamic system account through this
> > change.
> > * This could potentially break sites that are currently using the
> > 500-1000 UID range and rely on the order of allocation of UIDs for
> > their users on new machines matching with the UIDs on old machines.
> > (For instance, NFS UIDs on filesystems matching between a box
> > installed with RHEL5 and a box that gets newly installed with F16).
> > 
> > -Toshio
> 
> I'm not against wider announcement. I'm just not sure what is the right way - 
> F16 Feature/Release Notes/  ? We can also annouce the 200 limit for 
> reserved IDs. ;)

Probably makes sense :) ... even some ID sanity validator/checker might
be good idea for this "feature".

Ondrej Vasik

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

upstart → systemd upgrade path issue

[Kevin Kofler]

Hi,

today this update:
https://admin.fedoraproject.org/updates/upstart-1.2-2.fc14
got pushed to F14. (FWIW, I don't see how this is consistent with the update 
policies, but that's not the matter here.)

The result is that systemd in F15 no longer Obsoletes the upstart in F14:
https://bugzilla.redhat.com/show_bug.cgi?id=707507

This is going to break upgrades from F14 to F15 for many of our users. :-(

Kevin Kofler

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

Re: 9base in Fedora?

[Kevin Kofler]

Nicolas Mailhot wrote:
> There is no reason not to put them in /usr/lib(64). That's where common
> binaries such as firefox, java, etc already reside. They all have magic
> env variables to define their root for scripts and
> symlinks/wrappers/alternatives in /usr/bin

Well, actually, the proper place for executables is /usr/libexec, not 
/usr/lib(64). That's what libexec is for.

Kevin Kofler

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

Broken dependencies: perl-Text-Hunspell

[buildsys]

perl-Text-Hunspell has broken dependencies in the rawhide tree:
On x86_64:
perl-Text-Hunspell-2.02-2.fc15.x86_64 requires 
libhunspell-1.2.so.0()(64bit)
On i386:
perl-Text-Hunspell-2.02-2.fc15.i686 requires libhunspell-1.2.so.0
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://admin.fedoraproject.org/mailman/listinfo/perl-devel

rawhide report: 20110525 changes

[Rawhide Report]

Compose started at Wed May 25 08:15:04 UTC 2011

Broken deps for x86_64
--
acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell)
beldi-0.9.25-3.fc15.x86_64 requires libhal-storage.so.1()(64bit)
beldi-0.9.25-3.fc15.x86_64 requires libhal.so.1()(64bit)
beldi-0.9.25-3.fc15.x86_64 requires hal
callweaver-javascript-1.2.1-8.fc16.x86_64 requires libjs.so.1()(64bit)
camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit)
db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0
deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet
deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit)
dh-make-0.55-3.fc15.noarch requires debhelper
evolution-couchdb-0.5.3-1.fc16.x86_64 requires 
libcamel-provider-1.2.so.23()(64bit)
evolution-couchdb-0.5.3-1.fc16.x86_64 requires 
libcamel-1.2.so.23()(64bit)
exaile-0.3.2.1-1.fc16.noarch requires hal
fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4
fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4
fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5
fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit)
fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit)
fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit)
file-browser-applet-0.6.6-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
focuswriter-1.3.2.1-2.fc15.x86_64 requires libhunspell-1.2.so.0()(64bit)
gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit)
glunarclock-0.34.1-1.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-cpufire-1.6-3.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-jalali-calendar-1.7.1-2.fc15.noarch requires 
gnome-python2-applet
gnome-applet-music-2.5.1-5.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-music-2.5.1-5.fc15.x86_64 requires gnome-python2-applet
gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0
gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2)
gnome-applet-timer-2.1.4-2.fc15.x86_64 requires gnome-python2-applet >= 
0:2.16
gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-device-manager-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit)
gnome-device-manager-devel-0.2-6.fc15.i686 requires hal-devel >= 
0:0.5.10
gnome-device-manager-devel-0.2-6.fc15.i686 requires pkgconfig(hal)
gnome-device-manager-devel-0.2-6.fc15.x86_64 requires hal-devel >= 
0:0.5.10
gnome-device-manager-devel-0.2-6.fc15.x86_64 requires pkgconfig(hal)
gnome-device-manager-libs-0.2-6.fc15.i686 requires libhal.so.1
gnome-device-manager-libs-0.2-6.fc15.i686 requires hal >= 0:0.5.10
gnome-device-manager-libs-0.2-6.fc15.x86_64 requires 
libhal.so.1()(64bit)
gnome-device-manager-libs-0.2-6.fc15.x86_64 requires hal >= 0:0.5.10
gnome-netstatus-2.28.2-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotdconduit.so.3()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotd.so.5()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotdcm.so.4()(64bit)
gnome-pilot-eds-2.91.92-1.fc16.x86_64 requires 
libcamel-1.2.so.23()(64bit)
gnome-schedule-2.0.2-6.fc15.noarch requires gnome-python2-applet
gnotime-2.3.0-8.fc15.x86_64 requires libgtkhtml-3.15.so.19()(64bit)
gnubiff-2.2.13-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit)
gold-2.1.12.2-5.fc15.noarch requires perl(Data::Properties)
goldendict-1.0.1-4.fc15.x86_64 requires libhunspell-1.2.so.0()(64bit)
gorm-1.2.13-0.20110331.fc16.i686 requires libgnustep-gui.so.0.19
gorm-1.2.13-0.20110331.fc16.i686 requires libgnustep-base.so.1.21
gorm-1.2.13-0.20110331.fc16.x86_64 requires 
libgnustep-gui.so.0.19()(64bit)
gorm-1.2.13-0.20110331.fc16.x86_64 requires 
libgnustep-base.so.1.21()(64bit)
gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit)
gpx-viewer-0.2.0-3.fc14.x86_64 requires 
libchamplain-gtk-0.6.so.0()(64bit)
gpx-viewer-0.2.0-3.fc14.x86_64 requires libgdl-1.so.3()(64bit)
hal-info-20090716-4.fc15.noarch requires hal >= 0:0.5.10
halevt-0.1.6.2-4.fc15.x86_64 requires libhal.so.

Re: which video player for a package Requires ?

[Bastien Nocera]

On Tue, 2011-05-24 at 22:26 +0200, Nicoleau Fabien wrote:
> Hi,
> I'm packaging a software that downloads videos from websites like 
> youtube, dailymotion, etc ...
> 
> This software also allow the user to launch a video player that will 
> read the video as a stream.
> 
> The default value in the configuration file for the video player is "vlc 
> --quiet %u".

That sounds like quvi. Which you probably wouldn't want to use on the
command-line unless you knew what you were doing.

> My question is :
> what am I suppose to set in "Requires" field for the package ? totem ? 
> something generic ? nothing ?

Nothing.

FWIW, Totem has builtin support for quvi (I've been in touch with the
upstream author who made quite a few changes for it to be usable within
Totem). So "totem http://www.myvideosite.com/foobar"; would play if the
site is supported by quvi.

Cheers

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

Re: which video player for a package Requires ?

[Nicoleau Fabien]

Le 24/05/2011 23:10, Haïkel Guémar a écrit :
> Le 24/05/2011 22:26, Nicoleau Fabien a écrit :
>> Hi,
>> I'm packaging a software that downloads videos from websites like
>> youtube, dailymotion, etc ...
>>
>> This software also allow the user to launch a video player that will
>> read the video as a stream.
>>
>> The default value in the configuration file for the video player is "vlc
>> --quiet %u".
>>
>> My question is :
>> what am I suppose to set in "Requires" field for the package ? totem ?
>> something generic ? nothing ?
>>
>> Regards,
>>
>> Fabien Nicoleau
>   shouldn't it be handled by xdg-open ? Then it will try to play the
> video using the default multimedia player configured for the video
> mime-type.
>
> H.
With xdg-open, the internet browser is launched, and then propose to 
download the video file. May be the is a solution to tell to xdg-open to 
"open this file with the video player".

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

Re: which video player for a package Requires ?

[Nicoleau Fabien]

Le 25/05/2011 12:58, Bastien Nocera a écrit :
> On Tue, 2011-05-24 at 22:26 +0200, Nicoleau Fabien wrote:
>> Hi,
>> I'm packaging a software that downloads videos from websites like
>> youtube, dailymotion, etc ...
>>
>> This software also allow the user to launch a video player that will
>> read the video as a stream.
>>
>> The default value in the configuration file for the video player is "vlc
>> --quiet %u".
> That sounds like quvi. Which you probably wouldn't want to use on the
> command-line unless you knew what you were doing.
>
>> My question is :
>> what am I suppose to set in "Requires" field for the package ? totem ?
>> something generic ? nothing ?
> Nothing.
>
> FWIW, Totem has builtin support for quvi (I've been in touch with the
> upstream author who made quite a few changes for it to be usable within
> Totem). So "totem http://www.myvideosite.com/foobar"; would play if the
> site is supported by quvi.
>
> Cheers
>
I'm trying to package "nomnom", that uses quvi (that I also packaged). 
It's a gui that download or read as stream the videos from websites.

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

Re: upstart → systemd upgrade path issue

[Petr Lautrbach]

On Wed, May 25, 2011 at 11:33:50AM +0200, Kevin Kofler wrote:
> Hi,
> 
> today this update:
> https://admin.fedoraproject.org/updates/upstart-1.2-2.fc14
> got pushed to F14. (FWIW, I don't see how this is consistent with the update 
> policies, but that's not the matter here.)

Hi,

upstart-1.x branch is considered as stable and it's recommended update, see [1]
> 
upstart-1.2-2 hasn't changed upstart behavior. It fixes upstream bugs and also 
adds new
features like new stanzas (manual,debug) and also .override files
feature adapted from Ubuntu.

> The result is that systemd in F15 no longer Obsoletes the upstart in F14:
> https://bugzilla.redhat.com/show_bug.cgi?id=707507
> 
> This is going to break upgrades from F14 to F15 for many of our users. :-(
> 

Upgrade still installs systemd. systemd provides systemd-sysvinit which is 
required
by initscripts. 

There is only issue is that upstart is not uninstalled and pulls
initscripts-legacy as pointed in [2].

[1] 
http://upstart.at/2011/03/02/upstart-1-0-this-is-a-fertile-land-and-we-will-thrive-released/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=707507#c5


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

libcgroups adds -tools subpackage

[Jan Safranek]

Starting with libcgroup-0.37.1-3 (heading to rawhide right now),
libcgroup is divided into following subpackages:
- libcgroup - the library only
- libcgroup-tools - command line tools, services and daemons, previously
part of libcgroup.rpm

Please check your RPM dependencies and update them accordingly. AFAIK
there are only two packages dependent on libcgroup:

libvirt
policycoreutils

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

Re: UID_MIN & GID_MIN changed

[Jóhann B. Guðmundsson]

On 05/25/2011 12:30 AM, Dennis Gilmore wrote:
> On Tuesday, May 24, 2011 10:25:44 AM Toshio Kuratomi wrote:
>> On Tue, May 24, 2011 at 1:59 AM, Peter Vrabec  wrote:
>>> Hi all,
>>>
>>> I'd like to inform you that I have changed UID_MIN&  GID_MIN from 500 to
>>> 1000 in upgraded shadow-utils.
>>>
>>> Where?
>>> /etc/login.defs.
>>> shadow-utils-4.1.4.3-1.fc16
>>>
>>> I suppose UID/GID_MIN=1000 is more common(other distros, upstream). We
>>> are not in situation that 500 IDs for system accounts ought to be enough
>>> for anybody. Actually, it was not 500.It was 299 because range 0-200 is
>>> for reserved IDs. There are 799 non reserved IDs for system accounts
>>> available after this change.
>> This change should be made as a Feature for F16 and needs some
>> thought/coordination put behind it.  There's several issues that I
>> see:
>>
>> * AFAIK, we actually have not run into the 500 uid limit yet (although
>> it is a bit low to be comfortable)
>> *  AFAIK, we've only allocated the range 0-100 for reserved IDs.
>> * The 0-100 reserved IDs are actually the pain point that we need to
>> deal with, not the dynamic system ids in the 101-499 range.
>> * We don't know how many, if any IDs this actually gets us for the
>> dynamic range because any site that has already filled the 500-1000
>> UID range won't gain any extra dynamic system account through this
>> change.
>> * This could potentially break sites that are currently using the
>> 500-1000 UID range and rely on the order of allocation of UIDs for
>> their users on new machines matching with the UIDs on old machines.
>> (For instance, NFS UIDs on filesystems matching between a box
>> installed with RHEL5 and a box that gets newly installed with F16).
>>
>> -Toshio
> Im with Toshio here  there is potential pitfalls with many legacy systems.
> there is also great potential that system ids from newer systems will clash
> with legacy ids in ldap and nis setups,  we really should make it a feature as
> it really deserves to be widely anounced.  not quietly on the list here where
> it will likely get forgoten until users are bitten when they start deploying
> f16 boxes.
>
> Dennis

Agreed

Is there a distro wide/*nix wide agreement on what and which range 
reserved/system IDs are supposed to be?

If there is not a general consciousness regarding reserved/system IDs 
and what they are supposed to be there will always be the risk of 
colliding with ids on other distribution and *nix platforms.

I recommend this be made a feature and the feature owners contact at 
least all major distributions and potentially other *nix platforms and 
distro/*nix wide consciousness be made and when this change is made that 
change would reflect the consciousness that was reached.

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

OFED 1.6 InfiniBand packages in Fedora 16?

[Albert Strasheim]

Hello all

It seems the openfabrics.org people are planning their OFED 1.6
release which includes most of the useful InfiniBand packages for
middle of September 2011.

http://lists.openfabrics.org/pipermail/ewg/2011-March/016445.html

This seems to coincide nicely with the Fedora 16 release schedule.

The InfiniBand packages in Fedora currently seem to be quite a bit
behind the packages that will be included in OFED 1.6.

What is the way forward to get the latest InfiniBand packages into Fedora 16?

Regards

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

Upgrading from Fedora 14 to 15 -> some problems

[Casimiro de Almeida Barreto]

Yesterday I upgraded my notebook from 14 to 15.

Problems:

1st: it deleted network configurations.
2nd: rpmdb was left quite messed. Several dependencies non satisfied. As
this particular box was already upgraded from 13 to 14, there were
problems dealing with very old things (fc13 stuff). Much of upgrading
had to be done by hand (including uninstall & reinstall packages). Yum
failed short.
3rd: kde & kdm not upgraded by default. Thus kdm failed to start. I had
to switch to gdm, update kde, kdm, switch to kdm ... not intuitive for
average user.

Nothing really important for average nerd but annoying to users not
proficient in system admin chores.

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

[perl-Compress-Raw-Lzma] Rebuild for xz 5.0.3

[Paul Howarth]

commit 1e5d65f0c44bb0db6d1ef773a6c45077f11c1e0a
Author: Paul Howarth 
Date:   Wed May 25 14:12:07 2011 +0100

Rebuild for xz 5.0.3

 perl-Compress-Raw-Lzma.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Compress-Raw-Lzma.spec b/perl-Compress-Raw-Lzma.spec
index 8291ef6..0ef5288 100644
--- a/perl-Compress-Raw-Lzma.spec
+++ b/perl-Compress-Raw-Lzma.spec
@@ -1,6 +1,6 @@
 Name:  perl-Compress-Raw-Lzma
 Version:   2.035
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   Low-level interface to lzma compression library
 Group: Development/Libraries
 License:   GPL+ or Artistic
@@ -43,6 +43,9 @@ make test
 %{_mandir}/man3/Compress::Raw::Lzma.3pm*
 
 %changelog
+* Mon May 23 2011 Paul Howarth  - 2.035-2
+- Rebuild for xz 5.0.3
+
 * Sat May  7 2011 Paul Howarth  - 2.035-1
 - Update to 2.035 (no changes)
 
--
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: Upgrading from Fedora 14 to 15 -> some problems

[Rahul Sundaram]

On 05/25/2011 06:56 PM, Casimiro de Almeida Barreto wrote:
> Yesterday I upgraded my notebook from 14 to 15.

If you have specific bugs, do report them in bugzilla.  General feedback
should go into users list.  Thanks

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

[perl-Compress-Raw-Lzma] Created tag perl-Compress-Raw-Lzma-2.035-2.fc16

[Paul Howarth]

The lightweight tag 'perl-Compress-Raw-Lzma-2.035-2.fc16' was created pointing 
to:

 1e5d65f... Rebuild for xz 5.0.3
--
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: Upgrading from Fedora 14 to 15 -> some problems

[Robert 'Bob' Jensen]

- "Casimiro de Almeida Barreto"  wrote:

> Yesterday I upgraded my notebook from 14 to 15.
> 
> Problems:
> 
> 1st: it deleted network configurations.
> 2nd: rpmdb was left quite messed. Several dependencies non satisfied.
> As
> this particular box was already upgraded from 13 to 14, there were
> problems dealing with very old things (fc13 stuff). Much of upgrading
> had to be done by hand (including uninstall & reinstall packages).
> Yum
> failed short.
> 3rd: kde & kdm not upgraded by default. Thus kdm failed to start. I
> had
> to switch to gdm, update kde, kdm, switch to kdm ... not intuitive
> for
> average user.
> 
> Nothing really important for average nerd but annoying to users not
> proficient in system admin chores.
> 

What upgrade method is important to know. DVD, preupgrade, other?

-- Bob


|   Robert 'Bob' Jensen||   Fedora Unity Founder   |
|   b...@fedoraunity.org||  http://fedoraunity.org/ |
|   http://bjensen.fedorapeople.org/   |
|http://blogs.fedoraunity.org/bobjensen|
|   http://www.facebook.com/rpjensen   |

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

Re: Upgrading from Fedora 14 to 15 -> some problems

[Casimiro de Almeida Barreto]

Em 25-05-2011 10:42, Robert 'Bob' Jensen escreveu:
> - "Casimiro de Almeida Barreto"  wrote:
>
>> Yesterday I upgraded my notebook from 14 to 15.
>>
>> Problems:
>>
>> 1st: it deleted network configurations.
>> 2nd: rpmdb was left quite messed. Several dependencies non satisfied.
>> As
>> this particular box was already upgraded from 13 to 14, there were
>> problems dealing with very old things (fc13 stuff). Much of upgrading
>> had to be done by hand (including uninstall & reinstall packages).
>> Yum
>> failed short.
>> 3rd: kde & kdm not upgraded by default. Thus kdm failed to start. I
>> had
>> to switch to gdm, update kde, kdm, switch to kdm ... not intuitive
>> for
>> average user.
>>
>> Nothing really important for average nerd but annoying to users not
>> proficient in system admin chores.
>>
> What upgrade method is important to know. DVD, preupgrade, other?
>
> -- Bob
Upgraded from DVD.

Just booted from DVD, chose the "install or upgrade" & then did default
stuff.

I posted here because I think that dependencies are developer issues and
not user ones. From problems I detected, continuous upgrading is not
tried before a new Fedora is released. For future releases I'd suggest
someone keeps a box with complete installation (fedora, fedora-devel,
rpm-fusion...) upgraded from Fedora 14->15 and test upgrading it to
Fedora 16.

I'd also suggest to people dealing with RPM to create a way of
"cleaning" db. Inspecting the one in my box I discovered that there are
"dead memories" from Fedora 12 !!!

Next Sunday I'll upgrade another box. Then I'll try to extract records
to supply to developers. This box promises to be hard because it's using
an old NVIDIA GPU + manufacturer libraries (not nouveau that's not 3D
accelerated).

Besides, clamav requires /sbin/sysctl but does not install if as
dependency (only complains missing /sbin/sysctl and does not install).

Best regards,

CdAB
> 
> |   Robert 'Bob' Jensen||   Fedora Unity Founder   |
> |   b...@fedoraunity.org||  http://fedoraunity.org/ |
> |   http://bjensen.fedorapeople.org/   |
> |http://blogs.fedoraunity.org/bobjensen|
> |   http://www.facebook.com/rpjensen   |
> 

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

execve()ing non-existent command returns EPERM instead of ENOENT in Koji

[Petr Pisar]

Reviewer of my package found the package does pass tests in Koji
(dist-f16). I found the reason:

A test executes non-existent command and expects ENOENT. This is how it
works even in my local Rawhide. However Koji glibc returns EPERM.

You can see it in build.log of scratch build
:

  + /usr/bin/perl -le 'system qq{x-foo}; printf qq{%d %s\n}, $!, $!'
  13 Permission denied

and than failing tests #3 and #10.

The Perl on-liner executes `x-foo' commands and print errno and
strerror(errno).

Of course I can adjust tests to accept EPERM too. But, preferably, I'd
like to know if the spotted difference is intended or it's just a bug in
Koji setup.

-- Petr

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

FESCo and Board Election Questionnaires posted

[David Nalley]

Hi folks:

The responses to the questionnaire are now posted:

https://fedoraproject.org/wiki/F16_elections_questionnaire

Responses are divided by elected body and then appear in the order the
responses arrived in my inbox.

Please take a moment to look over them to better prepare yourselves
for the upcoming elections.

I'd also like to thank the nominees who took the time to answer the questions.

Cheers,

David Nalley
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Cannot reach Adrian R.

[Honza Horak]

Hi all,

I'm trying to reach Adrian Reber for a couple of days, but all emails 
sent to his address have returned back undelivered. He's a maintainer of 
many packages and the only one with commit rights by many of them. His 
last action I've noticed is from March this year.

Some of packages he owns: udns, libcdio, xlockmore, vnstat, 
spu-binutils, libspe2, jabberd, grip, ...

If you have a fresh contact to him or some another info, please, give me 
a notice.

Thanks a lot

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

Re: 9base in Fedora?

[Bill Nottingham]

Petr Sabata (con...@redhat.com) said: 
> > >> There is no reason not to put them in /usr/lib(64). That's where common
> > >> binaries such as firefox, java, etc already reside. They all have magic
> > >> env variables to define their root for scripts and
> > >> symlinks/wrappers/alternatives in /usr/bin
> > >
> > >
> > > In this case, though, there wouldn't be wrappers or scripts in /usr/bin.
> > 
> > Ok looking at how convoluted we are having to get this package in..
> > what are the reasons to have it in Fedora? Would some other way of
> > producing them having them available be there? Who is going to benefit
> > from them being there? Etc
> > 
> 
> Simply to make Fedora better. I'd like to make those available for our users.
> There are currently no other packages relying on this set (or rc, to be more
> specific) in Fedora. That could change in the future, though.

The question is - why does having incompatible plan9 implementations of
common commands make Fedora 'better', outside of "having more stuff"?

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

Re: Upgrading from Fedora 14 to 15 -> some problems

[Kevin Kofler]

Casimiro de Almeida Barreto wrote:
> Upgraded from DVD.
> 
> Just booted from DVD, chose the "install or upgrade" & then did default
> stuff.

The DVD does not include updates when doing the upgrade, which means it is 
fully expected that some packages will not be updated because they're newer 
in Fedora 14 updates than in Fedora 15 GA. Running "yum upgrade" or "yum 
distro-sync" after the DVD upgrade should fix it. (The latter will also 
downgrade packages if even Fedora 15 updates have an older version than 
Fedora 14 updates. Such a situation is actually a bug, but it still happens 
sometimes, so distro-sync is more robust.)

My recommendation is to use preupgrade or 
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum instead of the 
DVD. (The former is the official recommendation, the latter is how I upgrade 
my machines.)

I have been complaining about this brokenness for years, nobody cares about 
fixing it. So I can only recommend to never upgrade from the DVD.

> Next Sunday I'll upgrade another box. Then I'll try to extract records
> to supply to developers. This box promises to be hard because it's using
> an old NVIDIA GPU + manufacturer libraries (not nouveau that's not 3D
> accelerated).

Nouveau now supports OpenGL (3D acceleration) by default in Fedora 15. 
(Fedora 14 already had experimental support for it; in Fedora 15, it is no 
longer experimental.)

Kevin Kofler

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

Re: execve()ing non-existent command returns EPERM instead of ENOENT in Koji

[Petr Pisar]

On 2011-05-25, Petr Pisar  wrote:
>
> A test executes non-existent command and expects ENOENT. This is how it
> works even in my local Rawhide. However Koji glibc returns EPERM.
>
Correction: error 13 is EACCES.

-- Petr

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

Re: 9base in Fedora?

[Petr Sabata]

On Wed, May 25, 2011 at 11:36:10AM -0400, Bill Nottingham wrote:
> Petr Sabata (con...@redhat.com) said: 
> > > >> There is no reason not to put them in /usr/lib(64). That's where common
> > > >> binaries such as firefox, java, etc already reside. They all have magic
> > > >> env variables to define their root for scripts and
> > > >> symlinks/wrappers/alternatives in /usr/bin
> > > >
> > > >
> > > > In this case, though, there wouldn't be wrappers or scripts in /usr/bin.
> > > 
> > > Ok looking at how convoluted we are having to get this package in..
> > > what are the reasons to have it in Fedora? Would some other way of
> > > producing them having them available be there? Who is going to benefit
> > > from them being there? Etc
> > > 
> > 
> > Simply to make Fedora better. I'd like to make those available for our 
> > users.
> > There are currently no other packages relying on this set (or rc, to be more
> > specific) in Fedora. That could change in the future, though.
> 
> The question is - why does having incompatible plan9 implementations of
> common commands make Fedora 'better', outside of "having more stuff"?
> 

You could say the same about most of Fedora packages.

'Better', giving people tools to use, to choose from. Fedora isn't one of those
pure, minimalist distributions anyway. We have a lot of alternatives for a lot
of stuff. Some do more, some do less, some do the same but differently.

If that's good or not is a matter of opinion and the distribution goals.

And by 'incompatible' you mean some scripts depend on GNU coreutils and
therefore can't run with POSIX-only or Plan9 tools, I suppose. That's sad
but not a fault of those other tools.

-- 
# Petr Sabata


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

File Perl-Critic-Tics-0.006.tar.gz uploaded to lookaside cache by ppisar

[Petr Pisar]

A file has been added to the lookaside cache for perl-Perl-Critic-Tics:

dc5d3ea23a5ace74aa11d000cc21  Perl-Critic-Tics-0.006.tar.gz
--
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

[perl-Perl-Critic-Tics] Import

[Petr Pisar]

commit 8ec73fe547df3e0934383f9dc6a90c680e35ae24
Author: Petr Písař 
Date:   Wed May 25 18:07:38 2011 +0200

Import

and remove defattr macro.

 .gitignore |1 +
 perl-Perl-Critic-Tics.spec |   52 
 sources|1 +
 3 files changed, 54 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..a7611af 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Perl-Critic-Tics-0.006.tar.gz
diff --git a/perl-Perl-Critic-Tics.spec b/perl-Perl-Critic-Tics.spec
new file mode 100644
index 000..8c5e0f5
--- /dev/null
+++ b/perl-Perl-Critic-Tics.spec
@@ -0,0 +1,52 @@
+# This file is lincesed under the terms of GNU GPLv2+.
+Name:   perl-Perl-Critic-Tics
+Version:0.006
+Release:1%{?dist}
+Summary:Policies for things that make me wince
+License:GPL+ or Artistic
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/Perl-Critic-Tics/
+Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Perl-Critic-Tics-%{version}.tar.gz
+BuildArch:  noarch
+BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(Perl::Critic) >= 1.07
+BuildRequires:  perl(Perl::Critic::TestUtils)
+BuildRequires:  perl(Perl::Critic::Utils)
+BuildRequires:  perl(Perl::Critic::Violation)
+# Tests only:
+BuildRequires:  perl(Test::More)
+Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+# Plug-in into perlcritics. Require it.
+Requires:   perl(Perl::Critic) >= 1.07
+Requires:   perl(Perl::Critic::Violation)
+
+%description
+The Perl-Critic-Tics distribution includes extra policies for Perl::Critic
+to address a fairly random assortment of things that make me (rjbs) wince.
+
+%prep
+%setup -q -n Perl-Critic-Tics-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes LICENSE README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Tue Jan 25 2011 Petr Pisar  0.006-1
+- Specfile autogenerated by cpanspec 1.78.
+- Remove BuildRoot stuff
+- Remove explicit defattr
diff --git a/sources b/sources
index e69de29..6d294d7 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+dc5d3ea23a5ace74aa11d000cc21  Perl-Critic-Tics-0.006.tar.gz
--
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: UID_MIN & GID_MIN changed

[Iain Arnell]

On Wed, May 25, 2011 at 10:55 AM, Peter Vrabec  wrote:
>
> I'm not against wider announcement. I'm just not sure what is the right way -
> F16 Feature/Release Notes/  ?

How about slashdot's front page? Must be a really slow news day.

http://linux.slashdot.org/story/11/05/25/1312200/Fedora-16-Will-Number-UIDs-From-1000


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

Re: 9base in Fedora?

[Matthew Garrett]

On Wed, May 25, 2011 at 05:59:36PM +0200, Petr Sabata wrote:
> On Wed, May 25, 2011 at 11:36:10AM -0400, Bill Nottingham wrote:
> > The question is - why does having incompatible plan9 implementations of
> > common commands make Fedora 'better', outside of "having more stuff"?
> > 
> 
> You could say the same about most of Fedora packages.
> 
> 'Better', giving people tools to use, to choose from. Fedora isn't one of 
> those
> pure, minimalist distributions anyway. We have a lot of alternatives for a lot
> of stuff. Some do more, some do less, some do the same but differently.

What would cause someone to choose to use these tools rather than the 
ones that exist in Fedora already?

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 9base in Fedora?

[seth vidal]

On Wed, 2011-05-25 at 17:52 +0100, Matthew Garrett wrote:
> On Wed, May 25, 2011 at 05:59:36PM +0200, Petr Sabata wrote:
> > On Wed, May 25, 2011 at 11:36:10AM -0400, Bill Nottingham wrote:
> > > The question is - why does having incompatible plan9 implementations of
> > > common commands make Fedora 'better', outside of "having more stuff"?
> > > 
> > 
> > You could say the same about most of Fedora packages.
> > 
> > 'Better', giving people tools to use, to choose from. Fedora isn't one of 
> > those
> > pure, minimalist distributions anyway. We have a lot of alternatives for a 
> > lot
> > of stuff. Some do more, some do less, some do the same but differently.
> 
> What would cause someone to choose to use these tools rather than the 
> ones that exist in Fedora already?

They come from an environment where plan9 is more commonly used and want
to preserve the behaviors they know/like?

-sv


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

Re: 9base in Fedora?

[Dave Jones]

On Wed, May 25, 2011 at 12:56:25PM -0400, seth vidal wrote:
 
 > > What would cause someone to choose to use these tools rather than the 
 > > ones that exist in Fedora already?
 > 
 > They come from an environment where plan9 is more commonly used

Rob Pike's house ?

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

Re: 9base in Fedora?

[seth vidal]

On Wed, 2011-05-25 at 13:10 -0400, Dave Jones wrote:
> On Wed, May 25, 2011 at 12:56:25PM -0400, seth vidal wrote:
>  
>  > > What would cause someone to choose to use these tools rather than the 
>  > > ones that exist in Fedora already?
>  > 
>  > They come from an environment where plan9 is more commonly used
> 
> Rob Pike's house ?
> 

If we're going to argue that a pkg is unacceptable b/c the number of
people who care about it is ridiculously small, then I'd remind everyone
that a 'linux desktop' using any of the desktop envs we provide in
fedora is used by a tiny, tiny percentage of people.

I keep forgetting who fedora is for.

-sv




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

Re: Cannot reach Adrian R.

[Adrian Reber]

On Wed, May 25, 2011 at 05:22:53PM +0200, Honza Horak wrote:
> I'm trying to reach Adrian Reber for a couple of days, but all emails 
> sent to his address have returned back undelivered. He's a maintainer of 

What error did you get? I have not seen anything.

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

[Bug 656624] Please Update Spec File to use %ghost on files in /var/run and /var/lock

[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=656624

Lee Dan  changed:

   What|Removed |Added

 CC||dndlinu...@gmail.com

--- Comment #1 from Lee Dan  2011-05-25 13:30:47 EDT ---
mldonkey-server package includes a folder /var/run, and this folder disappears
after reboot. Then run 'service mldonkey start' can't work well for can't open
the file /var/run/mldonkey/mlnet.pid.

-- 
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.
___
ocaml-devel mailing list
ocaml-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel

Re: UID_MIN & GID_MIN changed

[Dennis Gilmore]

On Wednesday, May 25, 2011 03:55:55 AM Peter Vrabec wrote:
> Hi,
> 
> On Tuesday, May 24, 2011 05:25:44 PM Toshio Kuratomi wrote:
> > On Tue, May 24, 2011 at 1:59 AM, Peter Vrabec  wrote:
> > > Hi all,
> > > 
> > > I'd like to inform you that I have changed UID_MIN & GID_MIN from 500
> > > to 1000 in upgraded shadow-utils.
> > > 
> > > Where?
> > > /etc/login.defs.
> > > shadow-utils-4.1.4.3-1.fc16
> > > 
> > > I suppose UID/GID_MIN=1000 is more common(other distros, upstream). We
> > > are not in situation that 500 IDs for system accounts ought to be
> > > enough for anybody. Actually, it was not 500.It was 299 because range
> > > 0-200 is for reserved IDs. There are 799 non reserved IDs for system
> > > accounts available after this change.
> > 
> > This change should be made as a Feature for F16 and needs some
> > thought/coordination put behind it.  There's several issues that I
> > see:
> > 
> > * AFAIK, we actually have not run into the 500 uid limit yet (although
> > it is a bit low to be comfortable)
> > *  AFAIK, we've only allocated the range 0-100 for reserved IDs.
> > * The 0-100 reserved IDs are actually the pain point that we need to
> > deal with, not the dynamic system ids in the 101-499 range.
> 
> We use 0-200 for reserved IDs  since
> http://lists.fedoraproject.org/pipermail/devel/2009-April/028740.html
there was no change ever done there. the discussion was minimal to say the 
least.

 
> > * We don't know how many, if any IDs this actually gets us for the
> > dynamic range because any site that has already filled the 500-1000
> > UID range won't gain any extra dynamic system account through this
> > change.
> > * This could potentially break sites that are currently using the
> > 500-1000 UID range and rely on the order of allocation of UIDs for
> > their users on new machines matching with the UIDs on old machines.
> > (For instance, NFS UIDs on filesystems matching between a box
> > installed with RHEL5 and a box that gets newly installed with F16).
> > 
> > -Toshio
> 
> I'm not against wider announcement. I'm just not sure what is the right way
> - F16 Feature/Release Notes/  ? We can also annouce the 200 limit for
> reserved IDs. ;)

another issue that i thought of was existing ldap/nis systems that allocate 
regular users in the 500-1000 range when installing or upgrading if they use 
policies that probit system accounts from logging in will have users unable to 
login. 

Dennis



signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 9base in Fedora?

[Matthew Garrett]

On Wed, May 25, 2011 at 12:56:25PM -0400, seth vidal wrote:
> On Wed, 2011-05-25 at 17:52 +0100, Matthew Garrett wrote:
> > What would cause someone to choose to use these tools rather than the 
> > ones that exist in Fedora already?
> 
> They come from an environment where plan9 is more commonly used and want
> to preserve the behaviors they know/like?

Putting them in your path's just going to break things.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 9base in Fedora?

[seth vidal]

On Wed, 2011-05-25 at 18:41 +0100, Matthew Garrett wrote:
> On Wed, May 25, 2011 at 12:56:25PM -0400, seth vidal wrote:
> > On Wed, 2011-05-25 at 17:52 +0100, Matthew Garrett wrote:
> > > What would cause someone to choose to use these tools rather than the 
> > > ones that exist in Fedora already?
> > 
> > They come from an environment where plan9 is more commonly used and want
> > to preserve the behaviors they know/like?
> 
> Putting them in your path's just going to break things.
> 

'just going to break things' is the criteria, now?

-sv

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

Re: UID_MIN & GID_MIN changed

[Toshio Kuratomi]

On Wed, May 25, 2011 at 1:55 AM, Peter Vrabec  wrote:
> Hi,
>
> On Tuesday, May 24, 2011 05:25:44 PM Toshio Kuratomi wrote:
>> On Tue, May 24, 2011 at 1:59 AM, Peter Vrabec  wrote:
>> > Hi all,
>> >
>> > I'd like to inform you that I have changed UID_MIN & GID_MIN from 500 to
>> > 1000 in upgraded shadow-utils.
>> >
>> > Where?
>> > /etc/login.defs.
>> > shadow-utils-4.1.4.3-1.fc16
>> >
>> > I suppose UID/GID_MIN=1000 is more common(other distros, upstream). We
>> > are not in situation that 500 IDs for system accounts ought to be enough
>> > for anybody. Actually, it was not 500.It was 299 because range 0-200 is
>> > for reserved IDs. There are 799 non reserved IDs for system accounts
>> > available after this change.
>>
>> This change should be made as a Feature for F16 and needs some
>> thought/coordination put behind it.  There's several issues that I
>> see:
>>
>> * AFAIK, we actually have not run into the 500 uid limit yet (although
>> it is a bit low to be comfortable)
>> *  AFAIK, we've only allocated the range 0-100 for reserved IDs.
>> * The 0-100 reserved IDs are actually the pain point that we need to
>> deal with, not the dynamic system ids in the 101-499 range.
> We use 0-200 for reserved IDs  since
> http://lists.fedoraproject.org/pipermail/devel/2009-April/028740.html
>
If people think that 0-200 was the conclusion to that thread, it would
explain why there's a few buggy accounts in
/usr/share/doc/setup*/uidgid :-(  But that was not the conclusion of
that thread.  Of the available range, using 100-200 is an especially
bad choice for expanding the range.  Dynamically allocated system
accounts fall into that space and since allocation goes from the
bottom up, there's likely to be collisions. If we decided that 399-499
was also a range for static uids, the changes of collisions would
still exist but be much lower.


>> * We don't know how many, if any IDs this actually gets us for the
>> dynamic range because any site that has already filled the 500-1000
>> UID range won't gain any extra dynamic system account through this
>> change.
>> * This could potentially break sites that are currently using the
>> 500-1000 UID range and rely on the order of allocation of UIDs for
>> their users on new machines matching with the UIDs on old machines.
>> (For instance, NFS UIDs on filesystems matching between a box
>> installed with RHEL5 and a box that gets newly installed with F16).
>>
>> -Toshio
>
> I'm not against wider announcement. I'm just not sure what is the right way -
> F16 Feature/Release Notes/  ?

Yes, we can release note it.  But you still haven't answered the
question of why this change is necessary.  Do you really have a system
where you have installed more than 400 packages that are allocating
dynamic system accounts?

> We can also annouce the 200 limit for reserved IDs. ;)

We can't just make changes to this range.  Especially not in the lower
end of it.  (and if we change the dynamic system account range to
extend higher, we also can't use the 500-1000 range for that.

I notice that your patch on Monday to shadow-utils also canonicalized
this in the login.defs for the first time.  Please revert that.

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

Re: 9base in Fedora?

[Ralf Ertzinger]

Hi.

On Wed, 25 May 2011 13:18:20 -0400, seth vidal wrote

> I keep forgetting who fedora is for.

It's not like the problem of having multiple implementations of
basic UNIX command line tools has never come up before, though.
Solaris has been doing that for quite a long time.

http://download.oracle.com/docs/cd/E19253-01/816-5175/6mbba7f3l/index.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: UID_MIN & GID_MIN changed

[Toshio Kuratomi]

2011/5/25 "Jóhann B. Guðmundsson" :
> On 05/25/2011 12:30 AM, Dennis Gilmore wrote:
>> On Tuesday, May 24, 2011 10:25:44 AM Toshio Kuratomi wrote:
>>> On Tue, May 24, 2011 at 1:59 AM, Peter Vrabec  wrote:
 Hi all,

 I'd like to inform you that I have changed UID_MIN&  GID_MIN from 500 to
 1000 in upgraded shadow-utils.

 Where?
 /etc/login.defs.
 shadow-utils-4.1.4.3-1.fc16

 I suppose UID/GID_MIN=1000 is more common(other distros, upstream). We
 are not in situation that 500 IDs for system accounts ought to be enough
 for anybody. Actually, it was not 500.It was 299 because range 0-200 is
 for reserved IDs. There are 799 non reserved IDs for system accounts
 available after this change.
>>> This change should be made as a Feature for F16 and needs some
>>> thought/coordination put behind it.  There's several issues that I
>>> see:
>>>
>>> * AFAIK, we actually have not run into the 500 uid limit yet (although
>>> it is a bit low to be comfortable)
>>> *  AFAIK, we've only allocated the range 0-100 for reserved IDs.
>>> * The 0-100 reserved IDs are actually the pain point that we need to
>>> deal with, not the dynamic system ids in the 101-499 range.
>>> * We don't know how many, if any IDs this actually gets us for the
>>> dynamic range because any site that has already filled the 500-1000
>>> UID range won't gain any extra dynamic system account through this
>>> change.
>>> * This could potentially break sites that are currently using the
>>> 500-1000 UID range and rely on the order of allocation of UIDs for
>>> their users on new machines matching with the UIDs on old machines.
>>> (For instance, NFS UIDs on filesystems matching between a box
>>> installed with RHEL5 and a box that gets newly installed with F16).
>>>
>>> -Toshio
>> Im with Toshio here  there is potential pitfalls with many legacy systems.
>> there is also great potential that system ids from newer systems will clash
>> with legacy ids in ldap and nis setups,  we really should make it a feature 
>> as
>> it really deserves to be widely anounced.  not quietly on the list here where
>> it will likely get forgoten until users are bitten when they start deploying
>> f16 boxes.
>>
>> Dennis
>
> Agreed
>
> Is there a distro wide/*nix wide agreement on what and which range
> reserved/system IDs are supposed to be?
>
> If there is not a general consciousness regarding reserved/system IDs
> and what they are supposed to be there will always be the risk of
> colliding with ids on other distribution and *nix platforms.
>
There is a standard but not a consensus:

http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/uidrange.html

On problem is that the LSB is very strict in its ranges there but: 1)
not every distro follows it and 2) the static range is definitely too
small.

> I recommend this be made a feature and the feature owners contact at
> least all major distributions and potentially other *nix platforms and
> distro/*nix wide consciousness be made and when this change is made that
> change would reflect the consciousness that was reached.
>
Coordination would be nice if we can decide on how we can sanely make
changes to this.

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

Re: 9base in Fedora?

[Matthew Garrett]

On Wed, May 25, 2011 at 01:42:02PM -0400, seth vidal wrote:
> On Wed, 2011-05-25 at 18:41 +0100, Matthew Garrett wrote:
> > On Wed, May 25, 2011 at 12:56:25PM -0400, seth vidal wrote:
> > > On Wed, 2011-05-25 at 17:52 +0100, Matthew Garrett wrote:
> > > > What would cause someone to choose to use these tools rather than the 
> > > > ones that exist in Fedora already?
> > > 
> > > They come from an environment where plan9 is more commonly used and want
> > > to preserve the behaviors they know/like?
> > 
> > Putting them in your path's just going to break things.
> > 
> 
> 'just going to break things' is the criteria, now?

If they're used to plan9, they'll presumably want these in their path. 
If they're in their path, other utilities are going to misbehave in ways 
that will be difficult to debug. Why would someone choose to have a 
broken system?

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 9base in Fedora?

[seth vidal]

On Wed, 2011-05-25 at 19:14 +0100, Matthew Garrett wrote:
> On Wed, May 25, 2011 at 01:42:02PM -0400, seth vidal wrote:
> > On Wed, 2011-05-25 at 18:41 +0100, Matthew Garrett wrote:
> > > On Wed, May 25, 2011 at 12:56:25PM -0400, seth vidal wrote:
> > > > On Wed, 2011-05-25 at 17:52 +0100, Matthew Garrett wrote:
> > > > > What would cause someone to choose to use these tools rather than the 
> > > > > ones that exist in Fedora already?
> > > > 
> > > > They come from an environment where plan9 is more commonly used and want
> > > > to preserve the behaviors they know/like?
> > > 
> > > Putting them in your path's just going to break things.
> > > 
> > 
> > 'just going to break things' is the criteria, now?
> 
> If they're used to plan9, they'll presumably want these in their path. 
> If they're in their path, other utilities are going to misbehave in ways 
> that will be difficult to debug. Why would someone choose to have a 
> broken system?

Oh cmon, Matthew, you can't be serious.

just s/broken/development/ in your above statement and it is obvious.

people want broken things b/c then they can fix them.

-sv




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

Re: upstart → systemd upgrade path issue

[Lennart Poettering]

On Wed, 25.05.11 13:04, Petr Lautrbach (plaut...@redhat.com) wrote:

> 
> On Wed, May 25, 2011 at 11:33:50AM +0200, Kevin Kofler wrote:
> > Hi,
> > 
> > today this update:
> > https://admin.fedoraproject.org/updates/upstart-1.2-2.fc14
> > got pushed to F14. (FWIW, I don't see how this is consistent with the 
> > update 
> > policies, but that's not the matter here.)
> 
> Hi,
> 
> upstart-1.x branch is considered as stable and it's recommended update, see 
> [1]
> > 
> upstart-1.2-2 hasn't changed upstart behavior. It fixes upstream bugs and 
> also adds new
> features like new stanzas (manual,debug) and also .override files
> feature adapted from Ubuntu

Hmpf. Does it really make sense updating a packagein a released distro
with features like this? New distros should have new features not old
ones, and with your change you broke F15...  .

Lennart

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

Re: 9base in Fedora?

[Matthew Garrett]

On Wed, May 25, 2011 at 02:21:04PM -0400, seth vidal wrote:
> On Wed, 2011-05-25 at 19:14 +0100, Matthew Garrett wrote:
> > If they're used to plan9, they'll presumably want these in their path. 
> > If they're in their path, other utilities are going to misbehave in ways 
> > that will be difficult to debug. Why would someone choose to have a 
> > broken system?
> 
> Oh cmon, Matthew, you can't be serious.
> 
> just s/broken/development/ in your above statement and it is obvious.
> 
> people want broken things b/c then they can fix them.

If I get a bug complaining that something doesn't work because the user 
is using plan9 awk rather than gnu awk, they're going to get very firmly 
NOTABUGged. I hardly think I'm alone here.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 9base in Fedora?

[Martin Langhoff]

On Wed, May 25, 2011 at 1:41 PM, Matthew Garrett  wrote:
> Putting them in your path's just going to break things.

The plan is to have them _prefixed_ in your path, and un-prefixed in a
specified directory so you can frob the path to run scripts that
expect p9 utilities.

I am not sure what this package specifically brings, but many p9
utilities have *very* interesting ideas.

I have tested p9 before in VMs and I'll be installing this package
(when it comes through) to poke around and see.


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 9base in Fedora?

[seth vidal]

On Wed, 2011-05-25 at 19:35 +0100, Matthew Garrett wrote:
> On Wed, May 25, 2011 at 02:21:04PM -0400, seth vidal wrote:
> > On Wed, 2011-05-25 at 19:14 +0100, Matthew Garrett wrote:
> > > If they're used to plan9, they'll presumably want these in their path. 
> > > If they're in their path, other utilities are going to misbehave in ways 
> > > that will be difficult to debug. Why would someone choose to have a 
> > > broken system?
> > 
> > Oh cmon, Matthew, you can't be serious.
> > 
> > just s/broken/development/ in your above statement and it is obvious.
> > 
> > people want broken things b/c then they can fix them.
> 
> If I get a bug complaining that something doesn't work because the user 
> is using plan9 awk rather than gnu awk, they're going to get very firmly 
> NOTABUGged. I hardly think I'm alone here.
> 

I think that's completely appropriate.

But does that mean the pkg should stay out of the distro?

-sv


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

Outage: Upgrades/Reboots - 2011-05-31 18:00 UTC

[Kevin Fenzi]

Outage: Upgrades/Reboots - 2011-05-31 18:00 UTC

There will be an outage starting at 18:00 UTC on 2011-05-31, 
which will last approximately 2 hours. During this time there may be very short 
outages of services as machines are updated and rebooted into new kernels.

Machines will be rebooted in an order that allows for least disruption to 
services. 

In many cases, there will be no noticeable downtime due to redundancy and 
fail-over.

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

date -d '2011-05-31 18:00 UTC'

Reason for outage: 

System updates/Reboots. 

Affected Services:

BFO - http://boot.fedoraproject.org/
Bodhi - https://admin.fedoraproject.org/updates/
Buildsystem - http://koji.fedoraproject.org/
GIT / Source Control
DNS - ns1.fedoraproject.org, ns2.fedoraproject.org
Docs - http://docs.fedoraproject.org/
Email system
Fedora Account System - https://admin.fedoraproject.org/accounts/
Fedora Community - https://admin.fedoraproject.org/community/
Fedora Hosted - https://fedorahosted.org/
Fedora Insight - https://insight.fedoraproject.org/
Fedora People - http://fedorapeople.org/
Fedora Talk - http://talk.fedoraproject.org/
Main Website - http://fedoraproject.org/
Mirror List - https://mirrors.fedoraproject.org/
Mirror Manager - https://admin.fedoraproject.org/mirrormanager/
Package Database - https://admin.fedoraproject.org/pkgdb/
Smolt - http://smolts.org/
Spins - http://spins.fedoraproject.org/
Start - http://start.fedoraproject.org/
Torrent - http://torrent.fedoraproject.org/
Wiki - http://fedoraproject.org/wiki/

Unaffected Services:

Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/2790

Contact Information:

Please join #fedora-admin in irc.freenode.net or add comments to the ticket for 
this outage above. 


signature.asc
Description: PGP signature
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 9base in Fedora?

[Matthew Garrett]

On Wed, May 25, 2011 at 02:39:16PM -0400, seth vidal wrote:
> On Wed, 2011-05-25 at 19:35 +0100, Matthew Garrett wrote:
> > If I get a bug complaining that something doesn't work because the user 
> > is using plan9 awk rather than gnu awk, they're going to get very firmly 
> > NOTABUGged. I hardly think I'm alone here.
> > 
> 
> I think that's completely appropriate.
> 
> But does that mean the pkg should stay out of the distro?

I don't think we should be shipping anything unless there's an 
expectation that using it in the intended manner won't break unrelated 
software.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 663931] regression from 0.710.08 soap:Client, Application failed during request deserialization

[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=663931

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-SOAP-Lite-0.712-4.fc15 |perl-SOAP-Lite-0.712-4.fc13

-- 
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: 9base in Fedora?

[Matthew Garrett]

On Wed, May 25, 2011 at 02:35:09PM -0400, Martin Langhoff wrote:
> On Wed, May 25, 2011 at 1:41 PM, Matthew Garrett  wrote:
> > Putting them in your path's just going to break things.
> 
> The plan is to have them _prefixed_ in your path, and un-prefixed in a
> specified directory so you can frob the path to run scripts that
> expect p9 utilities.
> 
> I am not sure what this package specifically brings, but many p9
> utilities have *very* interesting ideas.
> 
> I have tested p9 before in VMs and I'll be installing this package
> (when it comes through) to poke around and see.

I don't think 9base provides a great deal - it's just the Plan 9 version 
of the basic Unix shell utilities. If there's interesting and useful 
ideas in them it'd make more sense to work on porting the functionality 
to coreutils.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 705084] perl-SOAP-Lite: do not depend on mod_perl

[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=705084

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-SOAP-Lite-0.712-4.fc15 |perl-SOAP-Lite-0.712-4.fc13

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

[Bug 663931] regression from 0.710.08 soap:Client, Application failed during request deserialization

[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=663931

--- Comment #9 from Fedora Update System  2011-05-25 
14:54:29 EDT ---
perl-SOAP-Lite-0.712-4.fc13 has been pushed to the Fedora 13 stable repository.
 If problems still persist, please make note of it in this bug report.

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

[Bug 705084] perl-SOAP-Lite: do not depend on mod_perl

[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=705084

--- Comment #7 from Fedora Update System  2011-05-25 
14:54:34 EDT ---
perl-SOAP-Lite-0.712-4.fc13 has been pushed to the Fedora 13 stable repository.
 If problems still persist, please make note of it in this bug report.

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

[Bug 707442] sqlsh's help needs IO::Scalar and Term::ReadLine::Gnu

[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=707442

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA

--- Comment #6 from Fedora Update System  2011-05-25 
14:54:07 EDT ---
Package perl-SQL-Shell-1.14-6.fc14:
* should fix your issue,
* was pushed to the Fedora 14 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing perl-SQL-Shell-1.14-6.fc14'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/perl-SQL-Shell-1.14-6.fc14
then log in and leave karma (feedback).

-- 
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: 9base in Fedora?

[seth vidal]

On Wed, 2011-05-25 at 19:53 +0100, Matthew Garrett wrote:
> On Wed, May 25, 2011 at 02:39:16PM -0400, seth vidal wrote:
> > On Wed, 2011-05-25 at 19:35 +0100, Matthew Garrett wrote:
> > > If I get a bug complaining that something doesn't work because the user 
> > > is using plan9 awk rather than gnu awk, they're going to get very firmly 
> > > NOTABUGged. I hardly think I'm alone here.
> > > 
> > 
> > I think that's completely appropriate.
> > 
> > But does that mean the pkg should stay out of the distro?
> 
> I don't think we should be shipping anything unless there's an 
> expectation that using it in the intended manner won't break unrelated 
> software.
> 

/me waits for kkofler to chime in here wrt nm and various kde applets.

-sv


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

[Bug 705084] perl-SOAP-Lite: do not depend on mod_perl

[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=705084

--- Comment #8 from Fedora Update System  2011-05-25 
14:56:33 EDT ---
perl-SOAP-Lite-0.712-4.fc14 has been pushed to the Fedora 14 stable repository.
 If problems still persist, please make note of it in this bug report.

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

[Bug 705084] perl-SOAP-Lite: do not depend on mod_perl

[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=705084

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-SOAP-Lite-0.712-4.fc13 |perl-SOAP-Lite-0.712-4.fc14

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

[Bug 663931] regression from 0.710.08 soap:Client, Application failed during request deserialization

[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=663931

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-SOAP-Lite-0.712-4.fc13 |perl-SOAP-Lite-0.712-4.fc14

-- 
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: which video player for a package Requires ?

[Adam Williamson]

On Tue, 2011-05-24 at 23:10 +0200, Haïkel Guémar wrote:
> Le 24/05/2011 22:26, Nicoleau Fabien a écrit :
> > Hi,
> > I'm packaging a software that downloads videos from websites like 
> > youtube, dailymotion, etc ...
> >
> > This software also allow the user to launch a video player that will 
> > read the video as a stream.
> >
> > The default value in the configuration file for the video player is "vlc 
> > --quiet %u".
> >
> > My question is :
> > what am I suppose to set in "Requires" field for the package ? totem ? 
> > something generic ? nothing ?
> >
> > Regards,
> >
> > Fabien Nicoleau
>  shouldn't it be handled by xdg-open ? Then it will try to play the
> video using the default multimedia player configured for the video
> mime-type.

I was going to say the same thing, but then I tested it, and on my F15
system, it tried to open a .avi file in nautilus. That didn't go so
well.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: upstart → systemd upgrade path issue

[Rahul Sundaram]

On 05/25/2011 04:34 PM, Petr Lautrbach wrote:
> upstart-1.2-2 hasn't changed upstart behavior. It fixes upstream bugs and 
> also adds new
> features like new stanzas (manual,debug) and also .override files
> feature adapted from Ubuntu.

We don't do feature additions like this in a existing release unless
there is a very good reason to.  There is no reason to since we aren't
using any of those new features in Fedora anyway.  Why would you ignore
the update policy in a critical path package?

http://fedoraproject.org/wiki/Updates_Policy#Updates_to_.27critical_path.27_packages


Rahul

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

Re: provenpackager attention needed for penmount

[Adam Williamson]

On Wed, 2011-05-25 at 08:16 +0200, Matej Cepl wrote:
> Dne 25.5.2011 03:18, Peter Hutterer napsal(a):
> > This update has been in testing since April 17 and all it requires is a
> > provenpackager ack. Harmless update, penmount was completely broken before
> > so it's hard to make it more broken now.
> 
> Just one more nitpick ... you meant proventester, right?

Indeed.

Note that ajax has a plan in motion (I think) for trimming this so that
esoteric X drivers are no longer considred to be critpath. He wrote to
the list about it a few weeks back.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: UID_MIN & GID_MIN changed

[Jóhann B. Guðmundsson]

On 05/25/2011 06:14 PM, Toshio Kuratomi wrote:
> Coordination would be nice if we can decide on how we can sanely make
> changes to this.

I would think first is to reach consciousness on what the 
reserved/system IDs are supposed to be once that has been done we can 
start looking at what is the best approach to implement and or fix 
things that might break because of it.

We admins that are in mixed *nix environment and are stuck with legacy 
uid/gid already have to *fix* the idiocy being done in configs and 
application where the min UID/GID is set to anything but 100 ( 
restricted range ).

Basically we whom are living in and running legacy/mixed OS environments 
are fucked already the main thing here is to reach consciousness across 
distro's and preferably *nix platforms so we dont be in this crappy 
situation again after 10 - 20 or 30 years time..

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

Re: UID_MIN & GID_MIN changed

[Simo Sorce]

On Wed, 2011-05-25 at 20:04 +, "Jóhann B. Guðmundsson" wrote:
> On 05/25/2011 06:14 PM, Toshio Kuratomi wrote:
> > Coordination would be nice if we can decide on how we can sanely make
> > changes to this.
> 
> I would think first is to reach consciousness on what the 

Do you mean consesus ? We are pretty conscious of the uid/gid problem
space I believe :)

> reserved/system IDs are supposed to be once that has been done we can 
> start looking at what is the best approach to implement and or fix 
> things that might break because of it.

Changing the reserved id space should break "only" new allocations on
systems that may have used the newly allocated IDs already.
The only way to fix that is to have the admin manually intervene after
the error is brought to his attanetion.

Of course a softer way to deal with this is to not change the defaults
on upgrade if checks reveals IDs in the affected space. The problem is
that it may not be easy to determine this, esp when centralized ID are
also available via NIS/LDAP.

> We admins that are in mixed *nix environment and are stuck with legacy 
> uid/gid already have to *fix* the idiocy being done in configs and 
> application where the min UID/GID is set to anything but 100 ( 
> restricted range ).

There is no need to insult developers that use defaults that are ok for
99% of the users and affect only legacy setups where poor decisions
where made wrt uid/gid allocations.

No default will ever please everyone.

> Basically we whom are living in and running legacy/mixed OS environments 
> are fucked already the main thing here is to reach consciousness across 
> distro's and preferably *nix platforms so we dont be in this crappy 
> situation again after 10 - 20 or 30 years time..

You are asking the impossible, its unreasonable to set the bar to make
any change in this area to some sort of consensus that was not reached
in the past 30 years. It is effectively stalling the process and
preventing change. Which is unreasonable.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: 9base in Fedora?

[Stephen John Smoogen]

On Wed, May 25, 2011 at 01:03, Petr Sabata  wrote:
> On Tue, May 24, 2011 at 10:59:27AM -0600, Stephen John Smoogen wrote:
>> On Tue, May 24, 2011 at 10:35, Matthew Miller  wrote:
>> > On Tue, May 24, 2011 at 09:28:02AM +0200, Nicolas Mailhot wrote:
>> >> There is no reason not to put them in /usr/lib(64). That's where common
>> >> binaries such as firefox, java, etc already reside. They all have magic
>> >> env variables to define their root for scripts and
>> >> symlinks/wrappers/alternatives in /usr/bin
>> >
>> >
>> > In this case, though, there wouldn't be wrappers or scripts in /usr/bin.
>>
>> Ok looking at how convoluted we are having to get this package in..
>> what are the reasons to have it in Fedora? Would some other way of
>> producing them having them available be there? Who is going to benefit
>> from them being there? Etc
>>
>
> Simply to make Fedora better. I'd like to make those available for our users.
> There are currently no other packages relying on this set (or rc, to be more
> specific) in Fedora. That could change in the future, though.


To be clear, my original question for putting them in is not that they
will break things or not. It is more does the "headache" of putting
them to meet FHS, LSB, MNOP standards too much? In the golden old days
I would put these in /usr/plan9  (like the old /usr/ucb or /usr/sysv
or /usr/kerberos) we used to have littered around. Or I would make
them prefixed p9 like I would prefix things g (for gnu), b (for bsd),
k (for kerberos). However that seems not acceptable these days
either.. so we end up with needing to put it in some poorly defined
place (/usr/libexec/plan9/{bin,lib,etc,etc}) that may or may not cause
even more howls somewhere else.

Do these required backflips make the software less usable than if you
had a repository (COPR?)  where stuff landed in /usr/local/ or
/opt/plan9 that people could use without too many problems. Yes
"fewer" people would find it from your fedorapeople web page, but the
few people who know about plan9, want to use plan9 etc are going to
already be doing Web searches for the name.



> --
> # Petr Sabata
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 9base in Fedora?

[Stephen John Smoogen]

On Wed, May 25, 2011 at 09:36, Bill Nottingham  wrote:
> Petr Sabata (con...@redhat.com) said:
>> > >> There is no reason not to put them in /usr/lib(64). That's where common
>> > >> binaries such as firefox, java, etc already reside. They all have magic
>> > >> env variables to define their root for scripts and
>> > >> symlinks/wrappers/alternatives in /usr/bin
>> > >
>> > >
>> > > In this case, though, there wouldn't be wrappers or scripts in /usr/bin.
>> >
>> > Ok looking at how convoluted we are having to get this package in..
>> > what are the reasons to have it in Fedora? Would some other way of
>> > producing them having them available be there? Who is going to benefit
>> > from them being there? Etc
>> >
>>
>> Simply to make Fedora better. I'd like to make those available for our users.
>> There are currently no other packages relying on this set (or rc, to be more
>> specific) in Fedora. That could change in the future, though.
>
> The question is - why does having incompatible plan9 implementations of
> common commands make Fedora 'better', outside of "having more stuff"?

I vaguely recall the headaches we had in Rawhide at one point where we
tried the experiment of moving to OpenBSD implementations of
applications because several customers thought they were more secure.
And they were in the OpenBSD environment. In the Linux environment
they were very buggy and many many applications did not work the way
they did in either OpenBSD or with GNU tools. We also tried putting
them in an alternative path at one point, but this also caused issues
for those users.

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



-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd errors being reported

[Paul Brewer]

Hi,

Adam Williamson at RedHat suggested I post here, so please don't be too hard on 
me.

I have a couple of systemd units which are reported as in error:

--
[palooka@f15 ~]$ systemctl list-units --all --no-pager|grep error
ip6tables.service error  inactive dead  ip6tables.service
livesys-late.service  error  inactive dead  livesys-late.service
[palooka@f15 ~]$ sudo systemctl disable ip6tables.service
Couldn't find ip6tables.service.
[palooka@f15 ~]$ sudo systemctl disable livesys-late.service
Couldn't find livesys-late.service.
[palooka@f15 ~]$
--

ip6tables is not installed on my system, and I know that livesys-late is a 
remnant of having installed from a Live CD.

As can be seen above, when I try to "disable" them, systemctl tells me that it 
can't find these services. So what I want to know is why are they being 
reported as in error, and how can I delete them, or otherwise remove them from 
the scope of systemctl?

Adam suggested I look for broken symlinks in /etc/systemd/system, but I see 
nothing untoward there:

---
[palooka@f15 system]$ pwd
/etc/systemd/system
[palooka@f15 system]$ ls -lR
.:
total 24
lrwxrwxrwx. 1 root root   42 Apr  8 22:33 
dbus-org.freedesktop.NetworkManager.service -> 
/lib/systemd/system/NetworkManager.service
lrwxrwxrwx  1 root root   36 May 18 20:52 default.target -> 
/lib/systemd/system/graphical.target
drwxr-xr-x. 2 root root 4096 Apr  8 22:33 default.target.wants
drwxr-xr-x. 2 root root 4096 Apr  8 22:33 getty.target.wants
drwxr-xr-x. 2 root root 4096 May 18 20:18 graphical.target.wants
drwxr-xr-x. 2 root root 4096 May 21 22:43 multi-user.target.wants
drwxr-xr-x. 2 root root 4096 Apr  8 22:33 network.target.wants
drwxr-xr-x. 2 root root 4096 Apr  8 22:33 sysinit.target.wants

./default.target.wants:
total 0
lrwxrwxrwx. 1 root root 53 Apr  8 22:33 systemd-readahead-collect.service -> 
/lib/systemd/system/systemd-readahead-collect.service
lrwxrwxrwx. 1 root root 52 Apr  8 22:33 systemd-readahead-replay.service -> 
/lib/systemd/system/systemd-readahead-replay.service

./getty.target.wants:
total 0
lrwxrwxrwx. 1 root root 34 Apr  8 22:33 getty@tty1.service -> 
/lib/systemd/system/getty@.service
lrwxrwxrwx. 1 root root 34 Apr  8 22:33 getty@tty2.service -> 
/lib/systemd/system/getty@.service
lrwxrwxrwx. 1 root root 34 Apr  8 22:33 getty@tty3.service -> 
/lib/systemd/system/getty@.service
lrwxrwxrwx. 1 root root 34 Apr  8 22:33 getty@tty4.service -> 
/lib/systemd/system/getty@.service
lrwxrwxrwx. 1 root root 34 Apr  8 22:33 getty@tty5.service -> 
/lib/systemd/system/getty@.service
lrwxrwxrwx. 1 root root 34 Apr  8 22:33 getty@tty6.service -> 
/lib/systemd/system/getty@.service

./graphical.target.wants:
total 0
lrwxrwxrwx. 1 root root 49 Apr  8 22:33 system-setup-keyboard.service -> 
/lib/systemd/system/system-setup-keyboard.service

./multi-user.target.wants:
total 0
lrwxrwxrwx. 1 root root 33 Apr  8 22:33 crond.service -> 
/lib/systemd/system/crond.service
lrwxrwxrwx  1 root root 38 May 18 21:27 irqbalance.service -> 
/lib/systemd/system/irqbalance.service
lrwxrwxrwx. 1 root root 42 Apr  8 22:33 NetworkManager.service -> 
/lib/systemd/system/NetworkManager.service
lrwxrwxrwx. 1 root root 35 Apr  8 22:33 ntpdate.service -> 
/lib/systemd/system/ntpdate.service
lrwxrwxrwx  1 root root 32 May 21 22:43 ntpd.service -> 
/lib/systemd/system/ntpd.service
lrwxrwxrwx. 1 root root 36 Apr  8 22:33 remote-fs.target -> 
/lib/systemd/system/remote-fs.target
lrwxrwxrwx. 1 root root 35 Apr  8 22:33 rsyslog.service -> 
/lib/systemd/system/rsyslog.service

./network.target.wants:
total 0
lrwxrwxrwx. 1 root root 42 Apr  8 22:33 NetworkManager.service -> 
/lib/systemd/system/NetworkManager.service

./sysinit.target.wants:
total 0
lrwxrwxrwx. 1 root root 40 Apr  8 22:33 hwclock-load.service -> 
/lib/systemd/system/hwclock-load.service
[palooka@f15 system]$
--

Is there a problem?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd errors being reported

[Orion Poplawski]

On 05/25/2011 04:05 PM, Paul Brewer wrote:
> ip6tables is not installed on my system, and I know that livesys-late is a 
> remnant of having installed from a Live CD.

I see livesys-late on my anaconda installed systems too.

I have some other fun ones:

VMware.serviceerror  inactive dead  VMware.service

And various "target" ones:

ypbind.target error  inactive dead  ypbind.target

Definitely not using that (not installed).



-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: UID_MIN & GID_MIN changed

[Jóhann B. Guðmundsson]

On 05/25/2011 08:14 PM, Simo Sorce wrote:
> On Wed, 2011-05-25 at 20:04 +, "Jóhann B. Guðmundsson" wrote:
>> On 05/25/2011 06:14 PM, Toshio Kuratomi wrote:
>>> Coordination would be nice if we can decide on how we can sanely make
>>> changes to this.
>> I would think first is to reach consciousness on what the
> Do you mean consesus ? We are pretty conscious of the uid/gid problem
> space I believe :)
>

Yup I meant conscious and I was refering to the uid/gid range

>> reserved/system IDs are supposed to be once that has been done we can
>> start looking at what is the best approach to implement and or fix
>> things that might break because of it.
> Changing the reserved id space should break "only" new allocations on
> systems that may have used the newly allocated IDs already.
> The only way to fix that is to have the admin manually intervene after
> the error is brought to his attanetion.
>
> Of course a softer way to deal with this is to not change the defaults
> on upgrade if checks reveals IDs in the affected space. The problem is
> that it may not be easy to determine this, esp when centralized ID are
> also available via NIS/LDAP.
>
>> We admins that are in mixed *nix environment and are stuck with legacy
>> uid/gid already have to *fix* the idiocy being done in configs and
>> application where the min UID/GID is set to anything but 100 (
>> restricted range ).
> There is no need to insult developers that use defaults that are ok for
> 99% of the users and affect only legacy setups where poor decisions
> where made wrt uid/gid allocations.

I'm pretty sure that things looked differently 20 - 30 years ago which 
in my case is when those poor decisions as you call them were made.
( and encase anyone is wondering I was not the one that made those 
decisions, I only get the *luxury* of dealing with them on daily bases )

> No default will ever please everyone.
>

True true

>> Basically we whom are living in and running legacy/mixed OS environments
>> are fucked already the main thing here is to reach consciousness across
>> distro's and preferably *nix platforms so we dont be in this crappy
>> situation again after 10 - 20 or 30 years time..
> You are asking the impossible, its unreasonable to set the bar to make
> any change in this area to some sort of consensus that was not reached
> in the past 30 years. It is effectively stalling the process and
> preventing change. Which is unreasonable

Has there been any effort in trying to address this problem in the past 
thirty years?

What looks to me the mistake that lsb did in the first place was to 
reserved an id range for dynamic allocation by system administrators and 
post install scripts use.

I'm pretty sure if they had not done that and simply raised the bar on 
reserved id to something high enough let's say 5000 or more and forced 
everyone to apply for an id in the reserverd space we would not be 
having this problem today...

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

Re: systemd errors being reported

[Lennart Poettering]

On Wed, 25.05.11 23:05, Paul Brewer (walterhu...@gmail.com) wrote:

> Hi,
> 
> Adam Williamson at RedHat suggested I post here, so please don't be too hard 
> on me.
> 
> I have a couple of systemd units which are reported as in error:
> 
> --
> [palooka@f15 ~]$ systemctl list-units --all --no-pager|grep error
> ip6tables.service error  inactive dead  ip6tables.service
> livesys-late.service  error  inactive dead  livesys-late.service
> [palooka@f15 ~]$ sudo systemctl disable ip6tables.service
> Couldn't find ip6tables.service.
> [palooka@f15 ~]$ sudo systemctl disable livesys-late.service
> Couldn't find livesys-late.service.
> [palooka@f15 ~]$
> --

Those services are simply referenced by other units, but we couldn't
load them because they didnt exist on disk, which we indicate in the
second column which is "error" for them. The second columns refers to
the "load state", i.e. whether a unit could be loaded successfully.

To make this less confusing we actually hide them on output. But you
turned that off by using "--all", i.e. you asked explicitly to see
them.

BTW, systemctl is smart enough to detect whether it outputs on a
terminal and will not do autopaging if you pipe it to something else,
i.e. drop --no-pager in the command line above.

> As can be seen above, when I try to "disable" them, systemctl tells me
> that it can't find these services. So what I want to know is why are
> they being reported as in error, and how can I delete them, or
> otherwise remove them from the scope of systemctl?

> Is there a problem?

No. ;-)

Lennart

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

Re: UID_MIN & GID_MIN changed

[Dennis Gilmore]

On Wednesday, May 25, 2011 03:14:43 PM Simo Sorce wrote:
> On Wed, 2011-05-25 at 20:04 +, "Jóhann B. Guðmundsson" wrote:
> > On 05/25/2011 06:14 PM, Toshio Kuratomi wrote:
> > > Coordination would be nice if we can decide on how we can sanely make
> > > changes to this.
> > 
> > I would think first is to reach consciousness on what the
> 
> Do you mean consesus ? We are pretty conscious of the uid/gid problem
> space I believe :)
> 
> > reserved/system IDs are supposed to be once that has been done we can
> > start looking at what is the best approach to implement and or fix
> > things that might break because of it.
> 
> Changing the reserved id space should break "only" new allocations on
> systems that may have used the newly allocated IDs already.
> The only way to fix that is to have the admin manually intervene after
> the error is brought to his attanetion.
> 
> Of course a softer way to deal with this is to not change the defaults
> on upgrade if checks reveals IDs in the affected space. The problem is
> that it may not be easy to determine this, esp when centralized ID are
> also available via NIS/LDAP.

new installs in places with legacy systems cand and likely will be effected 
with the result in cases being that users can not log into systems any longer.

Dennis


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: provenpackager attention needed for penmount

[Peter Hutterer]

On Wed, May 25, 2011 at 08:16:47AM +0200, Matej Cepl wrote:
> Dne 25.5.2011 03:18, Peter Hutterer napsal(a):
> > This update has been in testing since April 17 and all it requires is a
> > provenpackager ack. Harmless update, penmount was completely broken before
> > so it's hard to make it more broken now.
> 
> Just one more nitpick ... you meant proventester, right?

yes, sorry. luckily Rahul's capability of understanding what I mean exceeds
my capability of expressing what I mean :)

thanks Rahul!

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

Re: 9base in Fedora?

[Alexander Boström]

ons 2011-05-25 klockan 19:14 +0100 skrev Matthew Garrett:

> If they're in their path, other utilities are going to misbehave in
> ways 
> that will be difficult to debug. 

The user could add the directory to PATH without exporting PATH to
subprocesses, or they could use the shell's alias functionality instead.
Then it will only be used when they type the command name in their own
shell.

Actually, the user must make sure to do this after /etc/profile.d/* is
sourced since those might break.

I don't know in what way 9base is useful but I think the relevant
questions here are:

Would it be ok for a package to

 1. Install a number of prefixed binaries in /usr/bin/ 
 2. Install a number of unprefixed binaries
in /usr/lib//bin/ 
 3. Install some files in /usr/share//profile.d/ (or
something) which are meant to be sourced in the user's shell

?

Is /usr/lib//bin ok for both arch in multilib? Or does it have
to be /usr/lib64 on x86_64 for some reason?

Btw, using shell aliases means that it won't even need to install
anything in /usr/lib/*/bin.

If something can be packaged in a way that will not break things even if
the package is installed and won't increase the size of a minimal
install through dependency creep then let them. :)

/abo


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

Re: UID_MIN & GID_MIN changed

[Alexander Boström]

ons 2011-05-25 klockan 12:37 -0500 skrev Dennis Gilmore:

> another issue that i thought of was existing ldap/nis systems that allocate 
> regular users in the 500-1000 range when installing or upgrading if they use 
> policies that probit system accounts from logging in will have users unable 
> to 
> login. 

As someone who admins such an LDAP setup I think the sooner the change
is made the better. (If it had been changed long ago then it wouldn't
have been a problem now.)

Personally I think UIDs and their relation to user accounts should be
treated as host-local. I also want a pony.

/abo


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

Buildbot package

[philippe makowski]

Hi,

is there any reason that we have buildbot 7.12 ((January 21, 2010))
and that upstream is now 8.3 ?
any problem to upgrade it ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Cannot reach Adrian R.

[Honza Horak]

On 05/25/2011 05:22 PM, Honza Horak wrote:
> I'm trying to reach Adrian Reber for a couple of days, but all emails
> sent to his address have returned back undelivered. He's a maintainer of
> many packages and the only one with commit rights by many of them. His
> last action I've noticed is from March this year.
>
> Some of packages he owns: udns, libcdio, xlockmore, vnstat,
> spu-binutils, libspe2, jabberd, grip, ...
>
> If you have a fresh contact to him or some another info, please, give me
> a notice.
>
> Thanks a lot

Problem solved, thanks everybody :)

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