Re: [Guidelines Change] Changes to the Packaging Guidelines

[Rahul Sundaram]

On Tue, Feb 7, 2012 at 12:38 PM, Bohuslav Kabrda  wrote:

>
> Again, citing FHS:
> "Distributions may install software in /opt, but must not modify or delete
> software installed by the local system administrator without the assent of
> the local system administrator."
>
> How can this be interpreted as "non-OS vendor supplied"?
>

This is one of many places in which FHS is vague but that's the common
interpretation all distributions rely on

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

[Bug 787888] CVE-2012-0839 ocaml: hash table collisions CPU usage DoS (oCERT-2011-003)

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

Richard W.M. Jones  changed:

   What|Removed |Added

   Flag||needinfo?(kseifried@redhat.
   ||com)

--- Comment #1 from Richard W.M. Jones  2012-02-07 03:18:29 
EST ---
Are we proposing to fix this for RHEL too?  There are
no OCaml applications in RHEL which are vulnerable to this.

-- 
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: [ACTION NO LONGER REQUIRED] Retired packages for F-17

[drago01]

On Tue, Feb 7, 2012 at 5:31 AM, Orion Poplawski  wrote:
> On 02/06/2012 08:44 PM, Andy Grimm wrote:
>>
>> On Mon, Feb 6, 2012 at 3:09 PM, Bill Nottingham
>>  wrote:
>>>
>>> As stated eariler, the following packages have been retired in F-17 (and
>>> therefore rawhide), due to either failing to build, or not having
>>> maintainers.
>>>
>>> ...
>>> junit4
>>> ...
>>
>>
>> Whoa there.. .this one wasn't in any of the previous emails... perhaps
>> it was orphaned very recently?  It's a BuildReq for most of the java
>> universe, so probably best to give people one more shot at claiming
>> it, if possible.
>
>
> It appears that "junit" is now at version 4.

Yeah and it obsoletes junit4 (and provides it).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Bohuslav Kabrda]

- Original Message -

> On Tue, Feb 7, 2012 at 12:38 PM, Bohuslav Kabrda < bkab...@redhat.com
> > wrote:

> > Again, citing FHS:
> 

> > "Distributions may install software in /opt, but must not modify or
> > delete software installed by the local system administrator without
> > the assent of the local system administrator."
> 

> > How can this be interpreted as "non-OS vendor supplied"?
> 

> This is one of many places in which FHS is vague but that's the
> common interpretation all distributions rely on

> Rahul

"Distributions may install software in /opt" 

What do you find vague about this sentence? 

-- 

Regards, 
Bohuslav "Slavek" Kabrda. 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Rahul Sundaram]

On Tue, Feb 7, 2012 at 1:55 PM, Bohuslav Kabrda  wrote:

> --
>
>
> "Distributions may install software in /opt"
>
> What do you find vague about this sentence?
>
>
Refer to what Ralf quoted and compare and contrast.

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Bohuslav Kabrda]

- Original Message -

> On Tue, Feb 7, 2012 at 1:55 PM, Bohuslav Kabrda < bkab...@redhat.com
> > wrote:

> > "Distributions may install software in /opt"
> 

> > What do you find vague about this sentence?
> 

> Refer to what Ralf quoted and compare and contrast.

> Rahul

Yes, Ralf says how a sentence from FHS "is meant to be interpreted". I'm giving 
you a clear statement, that distributions may install software into /opt. Is 
the interpretation that Ralf is mentioning an official interpretation of FHS 
authors? Because if not, you are clearly preferring your interpretations over a 
clear statement. Or is there something more that I don't see? 

-- 

Regards, 
Bohuslav "Slavek" Kabrda. 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Mathieu Bridon]

On Tue, 2012-02-07 at 03:25 -0500, Bohuslav Kabrda wrote:
> "Distributions may install software in /opt"
> 
> What do you find vague about this sentence?

Is it a Linux distribution (i.e Fedora, Ubuntu, Debian,...) or a
software distribution (i.e a tarball release from upstream) ?


-- 
Mathieu


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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Rahul Sundaram]

On Tue, Feb 7, 2012 at 2:08 PM, Bohuslav Kabrda  wrote:

> Yes, Ralf says how a sentence from FHS "is meant to be interpreted". I'm
> giving you a clear statement, that distributions may install software into
> /opt. Is the interpretation that Ralf is mentioning an official
> interpretation of FHS authors? Because if not, you are clearly preferring
> your interpretations over a clear statement. Or is there something more
> that I don't see?\
>

Yes.  I said, see the quote.  Not the interpretation.  If you see the
quote, you can tell us how you interpret it. It might also be a useful
exercise   to look at how other distributions interpret it as well.   What
does add-on software mean?   If you want to get a official interpretation,
talk to whoever is supposedly trying to revise it now.

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

libcgroup rebase

[Jan Safranek]

libcgroup-0.38.rc1 is heading to rawhide/F17. It should be binary
compatible with 0.37, no rebuild of your packages is needed. Please
check functionality of your applications, just to be sure.

Dependent packages:
condor
condor-procd
libvirt
policycoreutils-sandbox
policycoreutils-python

In addition, libcgroup is being moved to /usr and has native systemd
units. Check /usr/share/doc/libcgroup-tools-0.38.rc1/README_systemd for
instructions how to live with systemd.

It will be updated to final 0.38 release before F17 GA. I expect only
minor bugfixes, if any.

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Marcela Mašláňová]

On 02/07/2012 09:21 AM, Rahul Sundaram wrote:
> 
> 
> On Tue, Feb 7, 2012 at 12:38 PM, Bohuslav Kabrda  > wrote:
> 
> 
> Again, citing FHS:
> "Distributions may install software in /opt, but must not modify or
> delete software installed by the local system administrator without
> the assent of the local system administrator."
> 
> How can this be interpreted as "non-OS vendor supplied"?
> 
> 
> This is one of many places in which FHS is vague but that's the common
> interpretation all distributions rely on
> 
> Rahul
> 
> 
FHS is "vague" about this one, so the installation into /opt was
forbidden. UsrMove was against FHS and it passed. I guess it need better
explanation, then you gave us.

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Michal Schmidt]

Bohuslav Kabrda wrote:
> And more importantly:
> "Distributions may install software in /opt, but must not modify or
> delete software installed by the local system administrator without
> the assent of the local system administrator."

Supposing that we allow Fedora packages to ship files in /opt,
how would we guarantee that on installation they don't overwrite
anything the administrator put there? RPM will overwrite an unowned
file, won't it?

The restriction makes sense.

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Bohuslav Kabrda]

- Original Message -

> On Tue, Feb 7, 2012 at 2:08 PM, Bohuslav Kabrda < bkab...@redhat.com
> > wrote:

> > Yes, Ralf says how a sentence from FHS "is meant to be
> > interpreted".
> > I'm giving you a clear statement, that distributions may install
> > software into /opt. Is the interpretation that Ralf is mentioning
> > an
> > official interpretation of FHS authors? Because if not, you are
> > clearly preferring your interpretations over a clear statement. Or
> > is there something more that I don't see?\
> 

> Yes. I said, see the quote. Not the interpretation. If you see the
> quote, you can tell us how you interpret it. It might also be a
> useful exercise to look at how other distributions interpret it as
> well. What does add-on software mean? If you want to get a official
> interpretation, talk to whoever is supposedly trying to revise it
> now.

> Rahul

Yes, I know the quote, it was me who quoted it in the first place. Add-on 
application software packages can mean almost anything, which is precisely my 
point - you interpret it in a very narrow way, and you are not accepting any 
comments on it. As for the other distributions, I thought we want to do 
something better/different. Other distributions do not do usrmove and we do, so 
what is the point in arguing with that? 

-- 

Regards, 
Bohuslav "Slavek" Kabrda. 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Bohuslav Kabrda]

- Original Message -
> Bohuslav Kabrda wrote:
> > And more importantly:
> > "Distributions may install software in /opt, but must not modify or
> > delete software installed by the local system administrator without
> > the assent of the local system administrator."
> 
> Supposing that we allow Fedora packages to ship files in /opt,
> how would we guarantee that on installation they don't overwrite
> anything the administrator put there? RPM will overwrite an unowned
> file, won't it?
> 
> The restriction makes sense.
> 
> Michal

You have to see this in connection with the sentence "The directories /opt/bin, 
/opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for 
local system administrator use." So if the packages don't use these 
directories, they won't rewrite anything.

-- 
Regards,
Bohuslav "Slavek" Kabrda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Rahul Sundaram]

2012/2/7 Marcela Mašláňová d

> >
> FHS is "vague" about this one, so the installation into /opt was
> forbidden. UsrMove was against FHS and it passed. I guess it need better
> explanation, then you gave us.
>

Good luck finding one other than consensus among distributions . If you
want to talk about usrmove, there were other threads

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Ralf Corsepius]

On 02/07/2012 08:08 AM, Bohuslav Kabrda wrote:



- Original Message -

On 02/07/2012 07:38 AM, Bohuslav Kabrda wrote:

Hi Tom,

- Original Message -

---

The section of the Packaging Guidelines covering /srv was amended
to
include /opt and /usr/local. Specifically, the following sentence
was
added:

In addition, no Fedora package can have any files or
directories
under /opt or /usr/local, as these directories are not
permitted to
be used by Distributions in the FHS.

https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal

---


Can I ask you where specifically you found the statement, that
distributions cannot place their data under /opt?


"/opt is reserved for the installation of add-on application software
packages."

In this context, "add-on application software packages" are meant to
be
interpreted as "non-OS vendor supplied" packages.

Ralf


Again, citing FHS:
"Distributions may install software in /opt, but must not modify or delete software 
installed by the local system administrator without the assent of the local system 
administrator."

How can this be interpreted as "non-OS vendor supplied"?


Like others said, the FHS often leaves room for interpretation. To 
understand this you need to take the historic context into consideration.


The point in here is the definition of "add-on packages".

RH/Fedora has always interpreted "add-on packages" as "3rd party" 
packages (== packages not shipped by RH/Fedora), while other distros 
historically interpreted this differently.
 E.g. there was a time (> 10 years ago) SuSE had considered "gnome" to 
be an (optional) add-on package and had installed it into /opt/gnome.


Now, re-read the sentence in this context: The "may" is an escape to 
allow both these interpretations, while it also implies "distros may 
disallow". The latter is the option RH/Fedora has chosen long time ago.


Meanwhile probably all distros interpret the FHS in the RH/Fedora sense 
and 3rd parties (Most prominent example: Adobe) are shipping their 
packages installed into /opt.


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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Kevin Kofler]

Bohuslav Kabrda wrote:
> Again, citing FHS:
> "Distributions may install software in /opt, but must not modify or delete
> software installed by the local system administrator without the assent of
> the local system administrator."

The only way the "but" part can be enforced in RPM is by not using /opt at 
all. RPM *will* overwrite files installed by the admin outside of RPM if 
they conflict with a file in an RPM.

Kevin Kofler

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Bohuslav Kabrda]

- Original Message -
> On 02/07/2012 08:08 AM, Bohuslav Kabrda wrote:
> >
> >
> > - Original Message -
> >> On 02/07/2012 07:38 AM, Bohuslav Kabrda wrote:
> >>> Hi Tom,
> >>>
> >>> - Original Message -
>  ---
> 
>  The section of the Packaging Guidelines covering /srv was
>  amended
>  to
>  include /opt and /usr/local. Specifically, the following
>  sentence
>  was
>  added:
> 
>  In addition, no Fedora package can have any files or
>  directories
>  under /opt or /usr/local, as these directories are not
>  permitted to
>  be used by Distributions in the FHS.
> 
>  https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal
> 
>  ---
> >>>
> >>> Can I ask you where specifically you found the statement, that
> >>> distributions cannot place their data under /opt?
> >>
> >> "/opt is reserved for the installation of add-on application
> >> software
> >> packages."
> >>
> >> In this context, "add-on application software packages" are meant
> >> to
> >> be
> >> interpreted as "non-OS vendor supplied" packages.
> >>
> >> Ralf
> >
> > Again, citing FHS:
> > "Distributions may install software in /opt, but must not modify or
> > delete software installed by the local system administrator
> > without the assent of the local system administrator."
> >
> > How can this be interpreted as "non-OS vendor supplied"?
> 
> Like others said, the FHS often leaves room for interpretation. To
> understand this you need to take the historic context into
> consideration.
> 
> The point in here is the definition of "add-on packages".
> 
> RH/Fedora has always interpreted "add-on packages" as "3rd party"
> packages (== packages not shipped by RH/Fedora), while other distros
> historically interpreted this differently.
>   E.g. there was a time (> 10 years ago) SuSE had considered "gnome"
>   to
> be an (optional) add-on package and had installed it into /opt/gnome.
> 
> Now, re-read the sentence in this context: The "may" is an escape to
> allow both these interpretations, while it also implies "distros may
> disallow". The latter is the option RH/Fedora has chosen long time
> ago.
> 
> Meanwhile probably all distros interpret the FHS in the RH/Fedora
> sense
> and 3rd parties (Most prominent example: Adobe) are shipping their
> packages installed into /opt.
> 
> Ralf

I see your point and I agree that it does make sense from this perspective. 
Still, I'd like to know what is behind this decision - why do we want to forbid 
this behaviour? Have any Fedora users run into problems with any software 
installing under /opt? Please give me some rationale behind this. I still think 
we may find situations appropriate for using /opt and we shouldn't just say 
"don't do that", but rather "be careful when doing that".

-- 
Regards,
Bohuslav "Slavek" Kabrda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Honza Horak]

On 02/07/2012 11:24 AM, Kevin Kofler wrote:

Bohuslav Kabrda wrote:

Again, citing FHS:
"Distributions may install software in /opt, but must not modify or delete
software installed by the local system administrator without the assent of
the local system administrator."


The only way the "but" part can be enforced in RPM is by not using /opt at
all. RPM *will* overwrite files installed by the admin outside of RPM if
they conflict with a file in an RPM.

 Kevin Kofler



Must RPM really enforce it? RPM allows to do many nasty things, but 
packagers don't do them. Why? Because they more or less follow the 
guidelines, which should be enough in this case. If guidelines contain 
some rational rules (e.g. there is a  capability), I don't see 
a problem.


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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Michal Schmidt]

Bohuslav Kabrda wrote:
> I see your point and I agree that it does make sense from this
> perspective. Still, I'd like to know what is behind this decision -
> why do we want to forbid this behaviour? Have any Fedora users run
> into problems with any software installing under /opt? Please give
> me some rationale behind this. I still think we may find situations
> appropriate for using /opt and we shouldn't just say "don't do
> that", but rather "be careful when doing that".

I'm curious what situations that might be. Why would I want to package
anything in Fedora under /opt? What advantage is there compared to
using /usr like everything else in the distribution?
Why would you not want to enforce this kind of consistency in Fedora
regardless of what funny stuff the FHS allows?

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Marcela Mašláňová]

On 02/07/2012 10:04 AM, Michal Schmidt wrote:
> Bohuslav Kabrda wrote:
>> And more importantly:
>> "Distributions may install software in /opt, but must not modify or
>> delete software installed by the local system administrator without
>> the assent of the local system administrator."
> 
> Supposing that we allow Fedora packages to ship files in /opt,
> how would we guarantee that on installation they don't overwrite
> anything the administrator put there? RPM will overwrite an unowned
> file, won't it?
> 
> The restriction makes sense.
> 
> Michal

We are against forbidden installation path into /opt, because we are
using it in our project - Dynamic Software Collections. The /opt
directory is used for installation of various Collections. Collections
should provide new or old version of software packaged in rpm. For
example latest Ruby for EL-6 branch or older Ruby for F-17. The
installation path start with - /opt/rh/name_of_collection/root/. I guess
this shouldn't be in conflict with anything else.

We didn't speak up sooner, because we don't have documentation and it's
still in a testing phase. Currently are prepared latest Perl for EL-6
and various Ruby collections for EL-6 and Fedora.

Details and examples could be found in my blog posts:
[1] http://mmaslano.livejournal.com/6685.html
[2] http://mmaslano.livejournal.com/6963.html

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Marcela Mašláňová]

On 02/07/2012 12:56 PM, Michal Schmidt wrote:
> Bohuslav Kabrda wrote:
>> I see your point and I agree that it does make sense from this
>> perspective. Still, I'd like to know what is behind this decision -
>> why do we want to forbid this behaviour? Have any Fedora users run
>> into problems with any software installing under /opt? Please give
>> me some rationale behind this. I still think we may find situations
>> appropriate for using /opt and we shouldn't just say "don't do
>> that", but rather "be careful when doing that".
> 
> I'm curious what situations that might be. Why would I want to package
> anything in Fedora under /opt? What advantage is there compared to
> using /usr like everything else in the distribution?
> Why would you not want to enforce this kind of consistency in Fedora
> regardless of what funny stuff the FHS allows?
> 
> Michal

If we want package collection of packages based on new release of Perl
or Ruby, which is separated from system packages, then it's /opt
appropriate.

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Michal Schmidt]

Marcela Mašláňová wrote:
> We are against forbidden installation path into /opt, because we are
> using it in our project - Dynamic Software Collections.

Thank you for mentioning this. At least now I have understanding of
the reasons behind the objections to the guideline.

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

Re: new comps group proposal: Virtualization Host

[Alan Pevec]

On Tue, Feb 7, 2012 at 12:08 AM, Alan Pevec  wrote:
> On Fri, Feb 3, 2012 at 8:29 PM, Bill Nottingham  wrote:
>>> Renaming current "Virtualization" to "Virtualization Client" makes sense.

Oops, just found there's already "Virtualization Client" in
comps-el6.xml - but it's empty:
Group: Virtualization Client
 Description: Clients for installing and managing virtualization instances.

There's also Group: Virtualization Platform
 Description: Provides an interface for accessing and controlling
virtualized guests and containers.

and Group: Virtualization Tools
 Description: Tools for offline virtual image management.

Bill, that was added by you in commit "Rearrange to match RHEL 6 groups."
 
http://git.fedorahosted.org/git/?p=comps.git;a=commit;h=25629d715dc2416b3a83195c6099828a0cfac0cf
what was the idea with those groups, I don't see them as sub-channels
in RHN, except last one which seems to be placeholder for v2v channel?

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

rubgyem-session license change

[Guillermo Gómez]

Due to recent license change in Ruby (from 1.8.7 GPLv2 or Ruby to 1.9.3 BSD or
Ruby), there were some clarifications with various upstreams whose licenses
were "same as ruby's", therefore unclear.

Then after clarification with upstream, rubygem-session now has BSD or
Ruby as it's License.

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

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

CGAL license change to (L)GPLv3+

[Laurent Rineau]

From release 4.0, the CGAL libraries will be released under LGPLv3+ for the 
foundations, and GPLv3+ for the high level packages (instead of LGPLv2 and QPL 
respectively).

I have built a prerelease of CGAL-4.0 in Rawhide.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Michael Schwendt]

On Tue, 07 Feb 2012 12:17:07 +0100, HH (Honza) wrote:

> On 02/07/2012 11:24 AM, Kevin Kofler wrote:
> > Bohuslav Kabrda wrote:
> >> Again, citing FHS:
> >> "Distributions may install software in /opt, but must not modify or delete
> >> software installed by the local system administrator without the assent of
> >> the local system administrator."
> >
> > The only way the "but" part can be enforced in RPM is by not using /opt at
> > all. RPM *will* overwrite files installed by the admin outside of RPM if
> > they conflict with a file in an RPM.
> >
> >  Kevin Kofler
> >
> 
> Must RPM really enforce it?

Not RPM itself, but the distributor's RPM Packaging Policies.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up: new mount(8) and umount(8)

[Karel Zak]

 I have upgraded util-linux package to version 2.21-rc2, changes:

 - new pure libmount based mount(8) and umounts(8), this change should
   be backwardly compatible and (I hope) invisible for users

 - new losetup(8) implementation (uses new /dev/loop-control API)

 - new prlimit(1) command

 - new chcpu(8) command

 - move libblkid cache from /etc to /run

 For more details see:
 ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.21/v2.21-ReleaseNotes

Karel

-- 
 Karel Zak  
 http://karelzak.blogspot.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Matthew Garrett]

On Tue, Feb 07, 2012 at 01:38:11AM -0500, Bohuslav Kabrda wrote:

> Can I ask you where specifically you found the statement, that distributions 
> cannot place their data under /opt?
> 
> Citing FHS [1]:
> "Programs to be invoked by users must be located in the directory 
> /opt//bin or under the /opt/ hierarchy. If the package 
> includes UNIX manual pages, they must be located in /opt//share/man 
> or under the /opt/ hierarchy, and the same substructure as 
> /usr/share/man must be used."
> 
> And more importantly:
> "Distributions may install software in /opt, but must not modify or delete 
> software installed by the local system administrator without the assent of 
> the local system administrator."

If the user has put something in /opt then it's not permitted for the 
distribution to overwrite it. Since you have no idea what the user may 
have installed there, it's not possible for packages to put anything 
under /opt.

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Matthew Garrett]

On Tue, Feb 07, 2012 at 09:55:03AM +0100, Marcela Mašláňová wrote:

> FHS is "vague" about this one, so the installation into /opt was
> forbidden. UsrMove was against FHS and it passed. I guess it need better
> explanation, then you gave us.

I know that this is a rehash of previous discussions, but it's a stretch 
to claim that usrmove is against the FHS - the most you can really argue 
is that there's a requirement for recovery tools to be in the root file 
system, but given that there's also a statement that /boot contains 
data used before the kernel starts executing user-space processes it's 
clear that this predates the modern initramfs. It's explicitly permitted 
that the mandated directories in / be symlinks.

From a practical perspective, I do tend to agree that putting software 
under /opt/fedora would be in line with the FHS and also unlikely to 
break anything.

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

Orphaning insight

[Patrick Monnerat]

I'm afraid I've just orphaned the insight debugger.

It now miss dependency iwidgets, that was a working up-to-date package
orphaned after the forced password change of last year, unperformed by
the iwidgets package owner.

I don't want to start I new troll on this subject: this has already been
widely discussed :-(

But my total disapprobation about this practice encourages me to not
continue support for this product.

If someone wants to adopt this package, please do.

Cheers,
Patrick

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Chris Adams]

Once upon a time, Bohuslav Kabrda  said:
> "Distributions may install software in /opt" 
> 
> What do you find vague about this sentence? 

That's not the sentence (if you're going to quote something, make sure
you quote the whole thing); you left out the rest: "but must not modify
or delete software installed by the local system administrator without
the assent of the local system administrator."

Since package management tools don't have any good way to obtain the
assent of the system adminitrator before overwriting files in /opt,
distributions steer clear of /opt.

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Ralf Corsepius]

On 02/07/2012 02:51 PM, Matthew Garrett wrote:


From a practical perspective, I do tend to agree that putting software
under /opt/fedora would be in line with the FHS and also unlikely to
break anything.


I am inclined to agree, but why would the Fedora project want to do this 
and not to install to /usr?


Ralf




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

rubgyem-systemu license change

[Vít Ondruch]

Due to recent license change in Ruby from GPLv2 or Ruby of to BSD or 
Ruby for Ruby 1.9.3, there were some clarifications with various 
upstreams whose licenses were "same as ruby's", therefore unclear.


After clarification with upstream, rubygem-systemu now has BSD or Ruby 
as it's License.


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


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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Bohuslav Kabrda]

- Original Message -
> Once upon a time, Bohuslav Kabrda  said:
> > "Distributions may install software in /opt"
> > 
> > What do you find vague about this sentence?
> 
> That's not the sentence (if you're going to quote something, make
> sure
> you quote the whole thing); you left out the rest: "but must not
> modify
> or delete software installed by the local system administrator
> without
> the assent of the local system administrator."
> 
> Since package management tools don't have any good way to obtain the
> assent of the system adminitrator before overwriting files in /opt,
> distributions steer clear of /opt.
> 
> --
> Chris Adams 
> Systems and Network Administrator - HiWAAY Internet Services
> I don't speak for anybody but myself - that's enough trouble.

Yes, you are right, you have to quote the whole thing:
"The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and 
/opt/man are reserved for local system administrator use."

-- 
Regards,
Bohuslav "Slavek" Kabrda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Bohuslav Kabrda]

- Original Message -
> On 02/07/2012 02:51 PM, Matthew Garrett wrote:
> 
> > From a practical perspective, I do tend to agree that putting
> > software
> > under /opt/fedora would be in line with the FHS and also unlikely
> > to
> > break anything.
> 
> I am inclined to agree, but why would the Fedora project want to do
> this
> and not to install to /usr?
> 
> Ralf

That's precisely what the new "stack" or "scl" concept that Marcela wrote about 
needs. We don't have a complete documentation out yet, but we will, soon 
(hopefully).

-- 
Regards,
Bohuslav "Slavek" Kabrda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Alan Pevec]

On Tue, Feb 7, 2012 at 3:50 PM, Bohuslav Kabrda  wrote:
> That's precisely what the new "stack" or "scl" concept that Marcela wrote 
> about needs. We don't have a complete documentation out yet, but we will, 
> soon (hopefully).

Random idea after looking at http://jnovy.fedorapeople.org/scl-utils/dsc.pp.pdf
...why not simply set % dsc prefix to e.g. /usr/share/scl/  instead of /opt/rh ?

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Michal Schmidt]

On 02/07/2012 03:50 PM, Bohuslav Kabrda wrote:

Ralf Corsepius wrote:

I am inclined to agree, but why would the Fedora project want to
do this and not to install to /usr?


That's precisely what the new "stack" or "scl" concept that Marcela
wrote about needs. We don't have a complete documentation out yet,
but we will, soon (hopefully).


I'm looking forward to it.

You know, telling us about it right at the start of the thread would 
have worked much better than arguing about quotes from the FHS :-)


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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Bohuslav Kabrda]

Hi Alan,
There are basically two main reasons: stacks contain platform specific files 
(so not good under share) and also, they should be separated from the core 
system, so it's probably best to place them under /opt.

- Original Message -
> On Tue, Feb 7, 2012 at 3:50 PM, Bohuslav Kabrda 
> wrote:
> > That's precisely what the new "stack" or "scl" concept that Marcela
> > wrote about needs. We don't have a complete documentation out yet,
> > but we will, soon (hopefully).
> 
> Random idea after looking at
> http://jnovy.fedorapeople.org/scl-utils/dsc.pp.pdf
> ...why not simply set % dsc prefix to e.g. /usr/share/scl/  instead
> of /opt/rh ?
> 
> Alan
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
Regards,
Bohuslav "Slavek" Kabrda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Review swap

[Jerry James]

Is anyone up for a review swap?  I need a review for lrslib:
https://bugzilla.redhat.com/show_bug.cgi?id=723752.

Thanks,
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Bohuslav Kabrda]

Yep, sorry about that. I was just trying to prove my point (which I think is 
correct), I didn't mean to start a flame. BTW, if you want to try, look at 
http://mmaslano.livejournal.com/6963.html and follow the instructions there, it 
describes in basic steps how to install and use a stack (older version, but 
from user point of view almost the same as current one).

- Original Message -
> On 02/07/2012 03:50 PM, Bohuslav Kabrda wrote:
> > Ralf Corsepius wrote:
> >> I am inclined to agree, but why would the Fedora project want to
> >> do this and not to install to /usr?
> >
> > That's precisely what the new "stack" or "scl" concept that Marcela
> > wrote about needs. We don't have a complete documentation out yet,
> > but we will, soon (hopefully).
> 
> I'm looking forward to it.
> 
> You know, telling us about it right at the start of the thread would
> have worked much better than arguing about quotes from the FHS :-)
> 
> Thanks,
> Michal
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
Regards,
Bohuslav "Slavek" Kabrda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads up: Ruby 1.9.3 landed in Rawhide

[Darryl L. Pierce]

On Mon, Feb 06, 2012 at 09:31:50AM -0500, Bohuslav Kabrda wrote:
> Hi all,
> Ruby 1.9.3 has finally made it into Rawhide, there are still few more 
> packages that need to be built, but otherwise the transitions was successful.
> 
> Please note again, that soname has been bumped to 1.9.1 and license is 
> changed from GPLv2 or Ruby to BSD or Ruby, as already announced.

Is it available in rawhide? I'm not seeing it anywhere.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



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

Re: Heads up: Ruby 1.9.3 landed in Rawhide

[Vít Ondruch]

Dne 7.2.2012 16:33, Darryl L. Pierce napsal(a):

On Mon, Feb 06, 2012 at 09:31:50AM -0500, Bohuslav Kabrda wrote:

Hi all,
Ruby 1.9.3 has finally made it into Rawhide, there are still few more packages 
that need to be built, but otherwise the transitions was successful.

Please note again, that soname has been bumped to 1.9.1 and license is changed 
from GPLv2 or Ruby to BSD or Ruby, as already announced.

Is it available in rawhide? I'm not seeing it anywhere.





Yes, it is.

However, if you are using mock, it might take some time to propagate 
into mirrors. If this is the case, then please try to enable the "local" 
repository in your mock config.



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

Re: Heads up: Ruby 1.9.3 landed in Rawhide

[Jon Ciesla]

On Tue, Feb 7, 2012 at 9:33 AM, Darryl L. Pierce  wrote:
> On Mon, Feb 06, 2012 at 09:31:50AM -0500, Bohuslav Kabrda wrote:
>> Hi all,
>> Ruby 1.9.3 has finally made it into Rawhide, there are still few more 
>> packages that need to be built, but otherwise the transitions was successful.
>>
>> Please note again, that soname has been bumped to 1.9.1 and license is 
>> changed from GPLv2 or Ruby to BSD or Ruby, as already announced.
>
> Is it available in rawhide? I'm not seeing it anywhere.

It is, in fact I got a broken dep email for clearsilver.  I'm trying
to troubleshoot and was going to rebuild and install ruby-1.9.3.0-7 on
my test f16 box, but one of the tests fails:

 29) Failure:
test_run_skip_verbose(TestMiniTestUnit)
[/home/limb/rpmbuild/BUILD/ruby-1.9.3-p0/test/minitest/test_minitest_unit.rb:392]:
--- expected
+++ actual
@@ -2,7 +2,7 @@

 # Running tests:

-ATestCase#test_skip = 0.00 s = S
+ATestCase#test_skip = 0.01 s = S
 ATestCase#test_something = 0.00 s = .


Suggestions?

-J

> --
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel



-- 
in your fear, seek only peace
in your fear, seek only love

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Toshio Kuratomi]

On Tue, Feb 07, 2012 at 10:13:16AM -0500, Bohuslav Kabrda wrote:
> Hi Alan,
> There are basically two main reasons: stacks contain platform specific files 
> (so not good under share)
>
This means they could go under %{_libdir}/dsc/%{DSCNAME}

> and also, they should be separated from the core system, so it's probably
> best to place them under /opt.
> 
The dividing line that Fedora nad most other distributions take these days
is whether the OS vendor is providing it as part of the OS.  If you are
saying that Fedora itself is not going to be packaging these dsc's then you
could use /opt.  However, if you want this to be something that Fedora
packages, /opt is going to be the wrong directory.  (The whole concept may
not be suitable for Fedora but I'm hoping not to have to decide that
until/unless I see a complete proposal :-)

-Toshio


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

Heads-up: libgee06 fails a test case against the updated glib2 in Rawhide

[Michel Alexandre Salim]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

It appears that a recent glib2 update breaks libgee06 -- which is
currently being used by the following packages:

caribou-0:0.4.1-4.fc17.src
systemd-0:39-3.fc17.src
tracker-0:0.12.9-1.fc17.src

Could the maintainers of affected packages (esp. systemd!) check if
they can build against libgee 0.7.2 instead? If not I'll investigate
and try and find a fix.

Thanks,

-  Original Message 
Subject: [Bug 788000] New: FTBFS with recent glib2
Date: Tue, 7 Feb 2012 03:03:21 -0500
From: bugzi...@redhat.com
To: michel+...@sylvestre.me

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

Summary: FTBFS with recent glib2

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

   Summary: FTBFS with recent glib2
   Product: Fedora
   Version: rawhide
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Severity: unspecified
  Priority: unspecified
 Component: libgee06
AssignedTo: michel+...@sylvestre.me
ReportedBy: d...@danny.cz
 QAContact: extras...@fedoraproject.org
CC: michel+...@sylvestre.me
   Estimated Hours: 0.0
Classification: Fedora
  Story Points: ---
  Type: ---
Regression: ---
Mount Type: ---
 Documentation: ---


when built on recent rawhide "make check" fails with the following error:

Provádění(%check): /bin/sh -e /var/tmp/rpm-tmp.eOvkGW
+ umask 022
+ cd /builddir/build/BUILD
+ cd libgee-0.6.1
+ unset DISPLAY
+ make check
Making check in gee
make[1]: Entering directory `/builddir/build/BUILD/libgee-0.6.1/gee'
make  check-am
make[2]: Entering directory `/builddir/build/BUILD/libgee-0.6.1/gee'
make  check-local
make[3]: Entering directory `/builddir/build/BUILD/libgee-0.6.1/gee'
make[3]: Leaving directory `/builddir/build/BUILD/libgee-0.6.1/gee'
make[2]: Leaving directory `/builddir/build/BUILD/libgee-0.6.1/gee'
make[1]: Leaving directory `/builddir/build/BUILD/libgee-0.6.1/gee'
Making check in tests
make[1]: Entering directory `/builddir/build/BUILD/libgee-0.6.1/tests'
make  check-am
make[2]: Entering directory `/builddir/build/BUILD/libgee-0.6.1/tests'
make  check-local
make[3]: Entering directory `/builddir/build/BUILD/libgee-0.6.1/tests'
TEST: tests... (pid=10159)
  /ArrayList/[Collection] type correctness:
GLib-GObject-CRITICAL **: Read-only property 'read-only-view' on class
'GeeAbstractList' has type 'GeeCollection' which is not equal to or more
restrictive than the type 'GeeList' of the property on the interface
'GeeList'
FAIL
GTester: last random seed: R02S69bb021d590335dedf00895624259e52
/bin/sh: line 1: 10158 Terminated  gtester --verbose tests
make[3]: *** [test] Error 143
make[3]: Leaving directory `/builddir/build/BUILD/libgee-0.6.1/tests'
make[2]: Leaving directory `/builddir/build/BUILD/libgee-0.6.1/tests'
make[2]: *** [check-am] Error 2
make[1]: *** [check] Error 2
make[1]: Leaving directory `/builddir/build/BUILD/libgee-0.6.1/tests'
make: *** [check-recursive] Error 1

glib2-2.31.6-1.fc17.x86_64 was used to build libgee06-0.6.1-6.fc17 in
koji and
when glib2-2.31.12-1.fc17.x86_64 is used, the test fails
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPMUiHAAoJEEr1VKujapN6DakIAIqdabo8M19FUl+pIaPGA062
9YMSZ40zSRm3wYpXnIBLGJyr3QhbYGesoKb+o1NipOdRK2xx/nGu5pvYUjqVzZGY
IVdXW9hRpTdjlRSm4Z5egPGFXRWEb+u19+7rG/1TbnQ0IUraSPkJ6qCqWVvzPpZT
6HL7hRad6IpBHyWY+Xfs41RfGACj+ADWmcMZ2wFDIWXAWRLiVA3jbyYjTg/31UhL
kIDhPKkB6YGc17KoCrPiIBNV+648mAbMfqk/pNnEQ6PIYVmGESbJUN0np2W8PTCY
nj4RDE0CyZwO9QbA3ADIl7AZUMNpMW2MOJsLxiNGF7UipZ/KniXJREUQ7B7tBNw=
=VYEc
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Stephen John Smoogen]

On 7 February 2012 02:04, Bohuslav Kabrda  wrote:
> 
>
>
>
> On Tue, Feb 7, 2012 at 2:08 PM, Bohuslav Kabrda  wrote:
>>
>> Yes, Ralf says how a sentence from FHS "is meant to be interpreted". I'm
>> giving you a clear statement, that distributions may install software into
>> /opt. Is the interpretation that Ralf is mentioning an official
>> interpretation of FHS authors? Because if not, you are clearly preferring
>> your interpretations over a clear statement. Or is there something more that
>> I don't see?\
>
>
> Yes.  I said, see the quote.  Not the interpretation.  If you see the quote,
> you can tell us how you interpret it. It might also be a useful exercise
> to look at how other distributions interpret it as well.   What does add-on
> software mean?   If you want to get a official interpretation, talk to
> whoever is supposedly trying to revise it now.
>
> Rahul
>
>
> Yes, I know the quote, it was me who quoted it in the first place. Add-on
> application software packages can mean almost anything, which is precisely
> my point - you interpret it in a very narrow way, and you are not accepting
> any comments on it. As for the other distributions, I thought we want to do
> something better/different. Other distributions do not do usrmove and we do,
> so what is the point in arguing with that?
>

tldr(1): You are fighting 15 years of historical packaging and
assumptions that  outside vendors rely on.
tldr(2): Packagers get one big break per release. /usr/move is it.
Move along til next release.

The historical context goes as follows:

The Red Hat rule from 1996->2001 was "packages do not put stuff into
/opt, /usr/local, or /srv." Like all Red Hat rules it was broken, and
every time it was there was a support nightmare. By 1999 it was
checked for explicitly by various scripts because of that. This rule
was further enhanced by quoting the FHS and taken into account by
Fedora packaging later.

Due to the fact that Red Hat and Fedora have been interpreting the
rule that way for a very very long time, local system administrators
and software vendors are very likely to use /opt for their own things
in either Solaris format (/opt//) or similar means
(/opt/fedoraproject/, /opt/fedora.. ,)  Vendors are very
likely to be the ones most likely to drop stuff in /opt in various
ways (/opt/jboss is a favourite even if they aren't jboss upstream).

The fact that packages in Fedora may end up being Red Hat packages at
some point means that we have to be very very careful about not
breaking some compatibility. [Breaking /usr is going to be a fun one
to deal with but I no longer work with GSS so will just listen to
their screams from afar.]





> --
> Regards,
> Bohuslav "Slavek" Kabrda.
>
> --
> 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.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Ralf Corsepius]

On 02/07/2012 12:56 PM, Marcela Mašláňová wrote:

On 02/07/2012 10:04 AM, Michal Schmidt wrote:

Bohuslav Kabrda wrote:

And more importantly:
"Distributions may install software in /opt, but must not modify or
delete software installed by the local system administrator without
the assent of the local system administrator."


Supposing that we allow Fedora packages to ship files in /opt,
how would we guarantee that on installation they don't overwrite
anything the administrator put there? RPM will overwrite an unowned
file, won't it?

The restriction makes sense.

Michal


We are against forbidden installation path into /opt, because we are
using it in our project

Then you will want to reconsider this.


- Dynamic Software Collections. The /opt
directory is used for installation of various Collections.


Packages (rpms) provided by the "Dynamic Software Collection" project 
can do so, but packages (rpms) built from these sources by Fedora must not.


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

Re: Heads-up: libgee06 fails a test case against the updated glib2 in Rawhide

[Michel Alexandre Salim]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/07/2012 04:51 PM, Michel Alexandre Salim wrote:
> Hi all,
> 
> It appears that a recent glib2 update breaks libgee06 -- which is 
> currently being used by the following packages:
> 
> caribou-0:0.4.1-4.fc17.src systemd-0:39-3.fc17.src 
> tracker-0:0.12.9-1.fc17.src
> 
> Could the maintainers of affected packages (esp. systemd!) check
> if they can build against libgee 0.7.2 instead? If not I'll
> investigate and try and find a fix.
> 
0.6.4 (which is somehow not announced on the libgee website, only on
the mailing list) fixes this problem. An updated build will hit
Rawhide soon.

Thanks,

- -- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  sali...@fedoraproject.org  | GPG key ID: A36A937A
Jabber: hir...@jabber.ccc.de   | IRC: hir...@irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPMVA8AAoJEEr1VKujapN6cx0H/1f6YIBnafqWCdKujeXJhW//
X2+y32cyS6XnHL0eDE9s6fNlunF1aVSNao+5+72oreadvJSASBbJqMb8u5+davAG
Btpsfeul87ohYTVMG3HyQalKWUg8dhGxvD9iQwm2Jsd/aPJGoNqsTWjxNHVEWgFm
R07ckVYSG1JZZcVIu4Z5HlEukayIQha/UOaA0LVJ4d0bSNAq2KopH6Re1OvpPD0a
D4mxGZeVu5KEhxQbRrW8M2CGhCecZyHBc8M8EipZryQozwZxpzfZvdb9yQSuF5H/
CAbKf8/l3maRZNAFX3qhZYJmp2DnFZNvjh4Vx/0zpbgqCods30k7hVP3biAXiPk=
=lO66
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads up: Ruby 1.9.3 landed in Rawhide

[Vít Ondruch]

Dne 7.2.2012 16:37, Jon Ciesla napsal(a):

On Tue, Feb 7, 2012 at 9:33 AM, Darryl L. Pierce  wrote:

On Mon, Feb 06, 2012 at 09:31:50AM -0500, Bohuslav Kabrda wrote:

Hi all,
Ruby 1.9.3 has finally made it into Rawhide, there are still few more packages 
that need to be built, but otherwise the transitions was successful.

Please note again, that soname has been bumped to 1.9.1 and license is changed 
from GPLv2 or Ruby to BSD or Ruby, as already announced.

Is it available in rawhide? I'm not seeing it anywhere.

It is, in fact I got a broken dep email for clearsilver.  I'm trying
to troubleshoot and was going to rebuild and install ruby-1.9.3.0-7 on
my test f16 box, but one of the tests fails:

  29) Failure:
test_run_skip_verbose(TestMiniTestUnit)
[/home/limb/rpmbuild/BUILD/ruby-1.9.3-p0/test/minitest/test_minitest_unit.rb:392]:
--- expected
+++ actual
@@ -2,7 +2,7 @@

  # Running tests:

-ATestCase#test_skip = 0.00 s = S
+ATestCase#test_skip = 0.01 s = S
  ATestCase#test_something = 0.00 s = .


Suggestions?

-J


Jon,

Could you please provide us your srpm?


Vit

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

Re: Heads up: Ruby 1.9.3 landed in Rawhide

[Jon Ciesla]

On Tue, Feb 7, 2012 at 10:25 AM, Vít Ondruch  wrote:
> Dne 7.2.2012 16:37, Jon Ciesla napsal(a):
>>
>> On Tue, Feb 7, 2012 at 9:33 AM, Darryl L. Pierce
>>  wrote:
>>>
>>> On Mon, Feb 06, 2012 at 09:31:50AM -0500, Bohuslav Kabrda wrote:

 Hi all,
 Ruby 1.9.3 has finally made it into Rawhide, there are still few more
 packages that need to be built, but otherwise the transitions was
 successful.

 Please note again, that soname has been bumped to 1.9.1 and license is
 changed from GPLv2 or Ruby to BSD or Ruby, as already announced.
>>>
>>> Is it available in rawhide? I'm not seeing it anywhere.
>>
>> It is, in fact I got a broken dep email for clearsilver.  I'm trying
>> to troubleshoot and was going to rebuild and install ruby-1.9.3.0-7 on
>> my test f16 box, but one of the tests fails:
>>
>>  29) Failure:
>> test_run_skip_verbose(TestMiniTestUnit)
>>
>> [/home/limb/rpmbuild/BUILD/ruby-1.9.3-p0/test/minitest/test_minitest_unit.rb:392]:
>> --- expected
>> +++ actual
>> @@ -2,7 +2,7 @@
>>
>>  # Running tests:
>>
>> -ATestCase#test_skip = 0.00 s = S
>> +ATestCase#test_skip = 0.01 s = S
>>  ATestCase#test_something = 0.00 s = .
>>
>>
>> Suggestions?
>>
>> -J
>
>
> Jon,
>
> Could you please provide us your srpm?

The one in koji.

http://koji.fedoraproject.org/koji/buildinfo?buildID=296249

http://kojipkgs.fedoraproject.org/packages/ruby/1.9.3.0/7.fc17/src/ruby-1.9.3.0-7.fc17.src.rpm

-J

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



-- 
in your fear, seek only peace
in your fear, seek only love

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

Re: why is gurb-menu hidden as default?

[Harald Hoyer]

Am 06.02.2012 20:17, schrieb Miloslav Trmač:
> About a year ago Harald had a talk about a "smart initrd" /
> "integrated rescue mode" along similar lines. Is this still under
> development?
>Mirek

Not yet developed, but still on my agenda
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

KDE-SIG meeting report (06/2012)

[Jaroslav Reznik]

This is a report of the weekly KDE-SIG-Meeting with a summary of the
topics that were discussed. If you want to add a comment please reply
  to this email or add it to the related meeting page.

= Weekly KDE Summary =

Week: 06/2012

Time: 2012-02-07 15:00 UTC

Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2012-02-07

Meeting minutes: 
http://meetbot.fedoraproject.org/fedora-meeting/2012-02-07/kde-sig.2012-02-07-15.03.html
Meeting log: 
http://meetbot.fedoraproject.org/fedora-meeting/2012-02-07/kde-sig.2012-02-07-15.03.log.html


= Participants =
* rdieter
* jreznik
* Kevin_Kofler
* ltinkl
* rnovacek
* than


= Agenda =
* topics to discuss:
** kde 4.8.0 status
** qt/kde in critpath
** ConsoleKit breakage
** plannning wiki 
* recent bugs:

== Summary ==
KDE 4.8.0 blocker
* KDE 4.8.0 blockers: new nepomuk config group (#771053) is fixed
* PowerDevil is actually a regression (lid close) (#771054)
* AGREED: to no longer consider these two bugs (PowerDevil, Gwenview) as a 
blocker bug

qt/kde in critpath
* the main issue for KDE is that critpath is dep-transitive
* critpath goes beyond "system boots and updates"
* AGREED: to postpone critpath to DevConf

ConsoleKit breakage
* short-term fix by adding ConsoleKit reqs (done by Kevin_Kofler)
* waiting for long term fix

= Next Meeting =
http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2012-02-14

= Links =

-- 
Jaroslav Řezník 
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc.   http://cz.redhat.com/

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

Re: new comps group proposal: Virtualization Host

[Bill Nottingham]

Alan Pevec (ape...@gmail.com) said: 
> Bill, that was added by you in commit "Rearrange to match RHEL 6 groups."
>  
> http://git.fedorahosted.org/git/?p=comps.git;a=commit;h=25629d715dc2416b3a83195c6099828a0cfac0cf
> what was the idea with those groups, I don't see them as sub-channels
> in RHN, except last one which seems to be placeholder for v2v channel?

RHEL 6 has:

virtualization: qemu/kvm
virtualization-client: virt-manager, virt-viewer
virtualization-platform: libvirt, fencing, bindings
virtualization-tools: libguestfs, virt-v2v

We can migrate Fedora to match this if people really want.

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

Re: Heads up: Ruby 1.9.3 landed in Rawhide

[Vít Ondruch]

Dne 7.2.2012 17:27, Jon Ciesla napsal(a):

On Tue, Feb 7, 2012 at 10:25 AM, Vít Ondruch  wrote:

Dne 7.2.2012 16:37, Jon Ciesla napsal(a):

On Tue, Feb 7, 2012 at 9:33 AM, Darryl L. Pierce
  wrote:

On Mon, Feb 06, 2012 at 09:31:50AM -0500, Bohuslav Kabrda wrote:

Hi all,
Ruby 1.9.3 has finally made it into Rawhide, there are still few more
packages that need to be built, but otherwise the transitions was
successful.

Please note again, that soname has been bumped to 1.9.1 and license is
changed from GPLv2 or Ruby to BSD or Ruby, as already announced.

Is it available in rawhide? I'm not seeing it anywhere.

It is, in fact I got a broken dep email for clearsilver.  I'm trying
to troubleshoot and was going to rebuild and install ruby-1.9.3.0-7 on
my test f16 box, but one of the tests fails:

  29) Failure:
test_run_skip_verbose(TestMiniTestUnit)

[/home/limb/rpmbuild/BUILD/ruby-1.9.3-p0/test/minitest/test_minitest_unit.rb:392]:
--- expected
+++ actual
@@ -2,7 +2,7 @@

  # Running tests:

-ATestCase#test_skip = 0.00 s = S
+ATestCase#test_skip = 0.01 s = S
  ATestCase#test_something = 0.00 s = .


Suggestions?

-J


Jon,

Could you please provide us your srpm?

The one in koji.

http://koji.fedoraproject.org/koji/buildinfo?buildID=296249

http://kojipkgs.fedoraproject.org/packages/ruby/1.9.3.0/7.fc17/src/ruby-1.9.3.0-7.fc17.src.rpm

-J


Vit

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





I tried it locally and cannot reproduce your issue. Both builds for i386 
and x86_64 succeeded. I started also scratch build for F16 in Koji [1], 
lets see what happens.



BTW for clearsilver you'll need to apply some patch for Ruby 1.9 [2].

Vit




[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=3769574
[2] https://gist.github.com/585817
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

btrfs "scrub" not included in F16?

[Chris Murphy]

I'm seeing all sorts of examples using the command "btrfs scrub" yet on all of 
my F16 installs (including current 3.2.3-1) the command:
btrfs scrub start /
ERROR: unknown command 'scrub'
Usage:
[ . . . ]

Intentionally not included, or user error?

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

Re: [389-devel] New Support Tool: dseconv.pl (dse.ldif file parser)

[Andrey Ivanov]

Hi Mark,

nice tool. It seems you have hardcoded into the script some default values
like config entries in cn=config suffix. Is there a way to do it in a more
flexible way. For example, dseconv could take (some) default values from
template-dse.ldif, template-*.ldif and if they are not found in the
templates just failover to the hardcoded values?

It will save some time on the script maintenance when the default values
are changed and/or added in the templates.

@+


2012/2/6 Mark Reynolds 

> Hi All,
>
> This was a side project of mine for some time, and I just ported it to DS
> 389.  It basically parses the dse.ldif into a readable format.  It groups
> all the backend info together.  So each backend lists its own indexes,
> config, replication info, etc.  It checks for non default config settings
> as well.
>
> It's basically a great way to take a quick look at a customers config:
>
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: btrfs "scrub" not included in F16?

[Josh Boyer]

On Tue, Feb 7, 2012 at 12:30 PM, Chris Murphy  wrote:
> I'm seeing all sorts of examples using the command "btrfs scrub" yet on all 
> of my F16 installs (including current 3.2.3-1) the command:
> btrfs scrub start /
> ERROR: unknown command 'scrub'
> Usage:
>        [ . . . ]
>
> Intentionally not included, or user error?

The scrub commands weren't added in btrfs-progs until October of last year.
The version F16 and rawhide has is just too old to contain that support.

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

Re: btrfs "scrub" not included in F16?

[Richard Hughes]

On 7 February 2012 17:40, Josh Boyer  wrote:
> The scrub commands weren't added in btrfs-progs until October of last year.
> The version F16 and rawhide has is just too old to contain that support.

That worries me a little, seeing how we're pressing on with btrfs by
default for F17... Surely shipping new snapshots of the btrfs-progs
package might be a good idea in rawhide?

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

[389-devel] please review ticket #17 - Replication optimizations around adds and modifies

[Mark Reynolds]

https://fedorahosted.org/389/ticket/17

https://fedorahosted.org/389/attachment/ticket/17/0001-Ticket-17-Replication-optimizations.patch

Thanks,
Mark
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: btrfs "scrub" not included in F16?

[Josef Bacik]

On Tue, Feb 7, 2012 at 12:46 PM, Richard Hughes  wrote:
> On 7 February 2012 17:40, Josh Boyer  wrote:
>> The scrub commands weren't added in btrfs-progs until October of last year.
>> The version F16 and rawhide has is just too old to contain that support.
>
> That worries me a little, seeing how we're pressing on with btrfs by
> default for F17... Surely shipping new snapshots of the btrfs-progs
> package might be a good idea in rawhide?
>

We're not pressing on with btrfs by default for F17.  At this point
I'm waiting for fsck so I can bring it all up to date at once, which
should be shortly (like today or tomorrow).  Thanks,

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

python-sqlite2 retirement/orphaning

[Toshio Kuratomi]

In cleaning up some half-retired packages yesterday, we discovered that
the python-sqlite2 maintainer wishes to retire the package.  There are a few
packages that depend on it but after reviewing the history and the code of
the packages, I think that it is reasonably safe to let this go ahead.

Historically, there was a python-sqlite module.  This version is not required
by any of the code we ship now.  It was replaced by python-sqlite2 (in
python, this is import pysqlite2).  In python-2.5, this library entered the
python stdlib as sqlite3 (import sqlite3).  The pysqlite2 library continues
to be released outside of the stdlib, mainly so that people who want to get
changes to the module (perhaps bugfixes or optimizations) at a faster rate
than the python stdlib's release cycle are able to.

In Fedora, there are several packages that have an explicit:
  Requires: python-sqlite2

I've reviewed the code for all of them and discovered that most will try to
import sqlite3 from the stdlib if pysqlite2 is not present.  Likely, these
just need to have the Requires: python-sqlite2 removed and the package is
then rebuilt:

* anki
* supybot-gribble
* bibus
* conduit
* firmware-extract
* gourmet
* griffith
* hamster-applet
* mysql-workbench
* python-tg-devtools
* python-sqlobject
* roundup
* sigul
* transifex
* trytond-sqlite
* yokadi
* python-keystone

There is one package that actually has a code dependency on pysqlite2.  I've
submitted a patch and asked someone I know who uses the package to test it:

* plague https://bugzilla.redhat.com/show_bug.cgi?id=788189

There are two packages that have a requirement on sqlite but don't actually
have any code that uses it:

* synce-sync-engine --  Looks like it may have at one time but has been ported
  to a lighterweight, internal, picklable data struct instead.

* poky-depends -- This is supposed to be a metapackage:
The poky-depends is to ensure all the required packages are installed to
build poky images. Please note that this only installs the dependency
packages.
If you want to build images, you will need to download Poky. Please refer:
http://pokylinux.org/getit/
http://pokylinux.org/support/
  I'll have to talk to the poky-depends maintainer to find out if the poky
  upstream works with sqlite3 from the stdlib since we aren't actually
  shipping the poky code... just this package that installs the
  dependencies.

If it seems acceptable to everyone involved, I'll go ahead and modify and
rebuild the packages in the first group for F17/rawhide.  I'll continue to
work on porting plague and contact the maintainers of synce-sync-engine and
poky-depends to see if it's okay to remove their deps.  Once all that's
done, I'll finish up the retire package process for the python-sqlite2
maintainer.

If people want to keep the python-sqlite2 package around, I'd strongly
suggest they volunteer to take over maintainance of the package so the
current maintainer can release ownership to them.

Thanks,
-Toshio


pgpD2TtmtirPJ.pgp
Description: PGP signature
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: [389-devel] New Support Tool: dseconv.pl (dse.ldif file parser)

[Mark Reynolds]

Hi Andrey,

This is definitely a good idea, and I will work on it when I get a 
chance.  I think we might add this script to the product - maybe.  If 
that's the case, there will probably more changes as well.  So, this 
isn't the final version by any means.


Thanks,
Mark

On 02/07/2012 12:35 PM, Andrey Ivanov wrote:

Hi Mark,

nice tool. It seems you have hardcoded into the script some default 
values like config entries in cn=config suffix. Is there a way to do 
it in a more flexible way. For example, dseconv could take (some) 
default values from template-dse.ldif, template-*.ldif and if they are 
not found in the templates just failover to the hardcoded values?


It will save some time on the script maintenance when the default 
values are changed and/or added in the templates.


@+


2012/2/6 Mark Reynolds mailto:marey...@redhat.com>>

Hi All,

This was a side project of mine for some time, and I just ported
it to DS 389.  It basically parses the dse.ldif into a readable
format.  It groups all the backend info together.  So each backend
lists its own indexes, config, replication info, etc.  It checks
for non default config settings as well.

It's basically a great way to take a quick look at a customers config:


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

Re: Heads up: Ruby 1.9.3 landed in Rawhide

[Jon Ciesla]

On Tue, Feb 7, 2012 at 11:07 AM, Vít Ondruch  wrote:
> Dne 7.2.2012 17:27, Jon Ciesla napsal(a):
>>
>> On Tue, Feb 7, 2012 at 10:25 AM, Vít Ondruch  wrote:
>>>
>>> Dne 7.2.2012 16:37, Jon Ciesla napsal(a):

 On Tue, Feb 7, 2012 at 9:33 AM, Darryl L. Pierce
  wrote:
>
> On Mon, Feb 06, 2012 at 09:31:50AM -0500, Bohuslav Kabrda wrote:
>>
>> Hi all,
>> Ruby 1.9.3 has finally made it into Rawhide, there are still few more
>> packages that need to be built, but otherwise the transitions was
>> successful.
>>
>> Please note again, that soname has been bumped to 1.9.1 and license is
>> changed from GPLv2 or Ruby to BSD or Ruby, as already announced.
>
> Is it available in rawhide? I'm not seeing it anywhere.

 It is, in fact I got a broken dep email for clearsilver.  I'm trying
 to troubleshoot and was going to rebuild and install ruby-1.9.3.0-7 on
 my test f16 box, but one of the tests fails:

  29) Failure:
 test_run_skip_verbose(TestMiniTestUnit)


 [/home/limb/rpmbuild/BUILD/ruby-1.9.3-p0/test/minitest/test_minitest_unit.rb:392]:
 --- expected
 +++ actual
 @@ -2,7 +2,7 @@

  # Running tests:

 -ATestCase#test_skip = 0.00 s = S
 +ATestCase#test_skip = 0.01 s = S
  ATestCase#test_something = 0.00 s = .


 Suggestions?

 -J
>>>
>>>
>>> Jon,
>>>
>>> Could you please provide us your srpm?
>>
>> The one in koji.
>>
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=296249
>>
>>
>> http://kojipkgs.fedoraproject.org/packages/ruby/1.9.3.0/7.fc17/src/ruby-1.9.3.0-7.fc17.src.rpm
>>
>> -J
>>
>>> Vit
>>>
>>> --
>>> devel mailing list
>>> devel@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/devel
>>
>>
>>
>
> I tried it locally and cannot reproduce your issue. Both builds for i386 and
> x86_64 succeeded. I started also scratch build for F16 in Koji [1], lets see
> what happens.

I retried and it worked.  Weird.

>
> BTW for clearsilver you'll need to apply some patch for Ruby 1.9 [2].

That's what got me building in the first place.  Thanks!

-J
>
> Vit
>
>
>
>
> [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=3769574
> [2] https://gist.github.com/585817
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel



-- 
in your fear, seek only peace
in your fear, seek only love

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Adam Williamson]

On Tue, 2012-02-07 at 13:51 +0530, Rahul Sundaram wrote:
> 
> 
> On Tue, Feb 7, 2012 at 12:38 PM, Bohuslav Kabrda 
> wrote:
> 
> 
> Again, citing FHS:
> "Distributions may install software in /opt, but must not
> modify or delete software installed by the local system
> administrator without the assent of the local system
> administrator."
> 
> 
> How can this be interpreted as "non-OS vendor supplied"?
> 
> This is one of many places in which FHS is vague but that's the common
> interpretation all distributions rely on

Um. Really? Wasn't there a distro - I'm thinking SUSE? - that installed
KDE in /opt for a long time?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Mark Bidewell]

On Tue, Feb 7, 2012 at 1:25 PM, Adam Williamson  wrote:
> On Tue, 2012-02-07 at 13:51 +0530, Rahul Sundaram wrote:
>>
>>
>> On Tue, Feb 7, 2012 at 12:38 PM, Bohuslav Kabrda 
>> wrote:
>>
>>
>>         Again, citing FHS:
>>         "Distributions may install software in /opt, but must not
>>         modify or delete software installed by the local system
>>         administrator without the assent of the local system
>>         administrator."
>>
>>
>>         How can this be interpreted as "non-OS vendor supplied"?
>>
>> This is one of many places in which FHS is vague but that's the common
>> interpretation all distributions rely on
>
> Um. Really? Wasn't there a distro - I'm thinking SUSE? - that installed
> KDE in /opt for a long time?
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
> http://www.happyassassin.net
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Suse is technically closer to the original intent of the filesystem
hierarchy standard.  /usr/bin is for non-critical system binaries (on
some Unix installations, /usr/bin is mounted readonly via NFS).
/usr/local and /opt would then be used to hold optional packages.


-- 
Mark Bidewell
http://www.linkedin.com/in/markbidewell
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: python-sqlite2 retirement/orphaning

[Michel Alexandre Salim]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/07/2012 07:08 PM, Toshio Kuratomi wrote:
> In Fedora, there are several packages that have an explicit: 
> Requires: python-sqlite2
> 
> I've reviewed the code for all of them and discovered that most
> will try to import sqlite3 from the stdlib if pysqlite2 is not
> present.  Likely, these just need to have the Requires:
> python-sqlite2 removed and the package is then rebuilt:
> 
...
> * roundup
I've had an outstanding bug open on this for a while -- this is a
packaging bug as roundup now uses the built-in sqlite3 module by default.

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

- -- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  sali...@fedoraproject.org  | GPG key ID: A36A937A
Jabber: hir...@jabber.ccc.de   | IRC: hir...@irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8xdWUACgkQNd069XiIR3gyaQCdFj5tl595+gJQyWLK1OLVrK/X
mPgAn1Yz1NcNW6Aop2yYHULtmOkPmdgV
=4D0K
-END PGP SIGNATURE-
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: python-sqlite2 retirement/orphaning

[Toshio Kuratomi]

On Tue, Feb 07, 2012 at 08:03:01PM +0100, Michel Alexandre Salim wrote:
> > * roundup
> I've had an outstanding bug open on this for a while -- this is a
> packaging bug as roundup now uses the built-in sqlite3 module by default.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=690246
> 
Thanks, I've fixed and rebuilt that one now.

-Toshio


pgpcNUWLhaMFs.pgp
Description: PGP signature
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

[389-devel] please review ticket#17 - additional optimizations for replicated ops

[Mark Reynolds]

https://fedorahosted.org/389/attachment/ticket/17

https://fedorahosted.org/389/attachment/ticket/17/0001-Ticket-17-replication-optimizations.patch

Found a few more minor optimizations.

Thanks,
Mark
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

This is not the power switch you are looking for

[Jerry James]

Fallout from usrmove, perhaps?  I tried to shutdown a VM running Rawhide:

Clicked on the power button symbol in the upper right hand corner of
the GDM desktop and chose "Power Off".  Nothing.  Clicked it again,
just in case.  Nothing.

Okay, so Ctrl-Alt-F3, login as root, and then this:

[root@jerry-rawhide32 ~]# shutdown -P now
Unknown operation now
[root@jerry-rawhide32 ~]# man shutdown

Nope, I had the syntax right.  Well, there's a poweroff command,
right?  Haven't used it for awhile...

[root@jerry-rawhide32 ~]# man poweroff
man: can't open /usr/share/man/halt.8: No such file or directory
[root@jerry-rawhide32 ~]# man halt

Okay, that worked.  I don't need to pass any arguments, just plain
poweroff.  Cool.

[root@jerry-rawhide32 ~]# poweroff
UNIT  LOAD   ACTIVE SUB   JOB DESCRIPTION
proc-sys...misc.automount loaded active waiting Arbitrary Executable File

... followed by several more pages of systemd output piped to less.

Okay, I give up.  How am I supposed to turn this thing off?
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[389-devel] please review ticket#17 - additional optimizations for replicated ops - updated link

[Mark Reynolds]

Sorry had the wrong link to the patch

https://fedorahosted.org/389/attachment/ticket/17/0001-Ticket-17-new-replication-optimizations.patch

On 02/07/2012 03:05 PM, Mark Reynolds wrote:

https://fedorahosted.org/389/attachment/ticket/17

https://fedorahosted.org/389/attachment/ticket/17/0001-Ticket-17-replication-optimizations.patch 



Found a few more minor optimizations.

Thanks,
Mark
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

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

Re: python-sqlite2 retirement/orphaning

[Michael Schwendt]

On Tue, 7 Feb 2012 10:08:03 -0800, TK (Toshio) wrote:

> There is one package that actually has a code dependency on pysqlite2.  I've
> submitted a patch and asked someone I know who uses the package to test it:
> 
> * plague https://bugzilla.redhat.com/show_bug.cgi?id=788189

Last time Plague has been adjusted to use sqlite3, some more items
required a patch:
http://mschwendt.fedorapeople.org/plague/patches/plague-0.4.4.1-sqlite3.patch

It could be that these are still valid, but it might be that I won't
manage to test prior to this weekend.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: This is not the power switch you are looking for

[Adam Williamson]

On Tue, 2012-02-07 at 13:14 -0700, Jerry James wrote:
> Fallout from usrmove, perhaps?  I tried to shutdown a VM running Rawhide:
> 
> Clicked on the power button symbol in the upper right hand corner of
> the GDM desktop and chose "Power Off".  Nothing.  Clicked it again,
> just in case.  Nothing.
> 
> Okay, so Ctrl-Alt-F3, login as root, and then this:
> 
> [root@jerry-rawhide32 ~]# shutdown -P now
> Unknown operation now
> [root@jerry-rawhide32 ~]# man shutdown
> 
> Nope, I had the syntax right.  Well, there's a poweroff command,
> right?  Haven't used it for awhile...
> 
> [root@jerry-rawhide32 ~]# man poweroff
> man: can't open /usr/share/man/halt.8: No such file or directory
> [root@jerry-rawhide32 ~]# man halt
> 
> Okay, that worked.  I don't need to pass any arguments, just plain
> poweroff.  Cool.
> 
> [root@jerry-rawhide32 ~]# poweroff
> UNIT  LOAD   ACTIVE SUB   JOB DESCRIPTION
> proc-sys...misc.automount loaded active waiting Arbitrary Executable File
> 
> ... followed by several more pages of systemd output piped to less.
> 
> Okay, I give up.  How am I supposed to turn this thing off?

Shutting down can occasionally get a bit wiggy after a systemd version
update. Was this right after you did a big F16 -> F17 yum update or
anything? If so, you may find you have to just suck it up and hard power
off one time, then it'll be back to working properly on the next boot.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: KDE-SIG meeting report (06/2012)

[linux guy]

Does this mean KDE4.8 will ship shortly ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[389-devel] please review ticket #129 - Should only update modifyTimestamp/modifiersName on MODIFY ops

[Mark Reynolds]

https://fedorahosted.org/389/attachment/ticket/129

https://fedorahosted.org/389/attachment/ticket/129/0001-Ticket-129-Should-only-update-modifyTimestamp-modifi.patch

This issue was previously fixed, I just expanded the fix a little.

Thanks,
Mark
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

This is not the power switch you are looking for

[Andre Robatino]

Adam Williamson  redhat.com> writes:

> Shutting down can occasionally get a bit wiggy after a systemd version
> update. Was this right after you did a big F16 -> F17 yum update or
> anything? If so, you may find you have to just suck it up and hard power
> off one time, then it'll be back to working properly on the next boot.

I have the same issue after today's Rawhide updates. It's persistent.



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

Re: python-sqlite2 retirement/orphaning

[Toshio Kuratomi]

On Tue, Feb 07, 2012 at 09:35:20PM +0100, Michael Schwendt wrote:
> On Tue, 7 Feb 2012 10:08:03 -0800, TK (Toshio) wrote:
> 
> > There is one package that actually has a code dependency on pysqlite2.  I've
> > submitted a patch and asked someone I know who uses the package to test it:
> > 
> > * plague https://bugzilla.redhat.com/show_bug.cgi?id=788189
> 
> Last time Plague has been adjusted to use sqlite3, some more items
> required a patch:
> http://mschwendt.fedorapeople.org/plague/patches/plague-0.4.4.1-sqlite3.patch
> 
> It could be that these are still valid, but it might be that I won't
> manage to test prior to this weekend.
>
Thanks!  I took a look at your patch and it looks like it was integrated
upstream.  Most of it verbatim.  The one part I'm not 100% sure of is the
changes to UserInterface.py.  I don't know what the code looked like that
the patch applies against but I think that equivalent changes were merged
into DBManager.py instead.

The current code uses pysqlite2 with imports like this:

try:
from pysqlite2 import _sqlite as sqlite
except ImportError:
import sqlite

Since sqlite3 is supposed to be a slightly older version of pysqlite2,
I updated the import to look like this:

try:
from pysqlite2 import _sqlite as sqlite
except ImportError:
try:
import _sqlite3 as sqlite
except ImportError:
import sqlite

After looking at your patch, there might not be any reason to import the
compiled portion of the extension directly -- it might be okay to do this:

try:
from pysqlite2 import dbapi2 as sqlite
except ImportError:
try:
import sqlite3 as sqlite
except ImportError:
import sqlite

I haven't looked at the python code in those modules closely, I just assumed
that the pysqlite2 code was working already so the sqlite3 module had
a higher chance of working out of the box if I accessed it in the same way.

-Toshio


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

Re: [389-devel] please review ticket #129 - Should only update modifyTimestamp/modifiersName on MODIFY ops

[Mark Reynolds]

I had a typo in part of the fix, but...

After looking at ticket #111, I think maybe we should add this flag to 
memberOf, referint, and maybe some other plugins.

Any thoughts on this?

Thanks,
Mark

PS - having email issues again, so this is a duplicate of a duplicate.  Sorry I 
just don't know if the the first two emails will actually go through.

- Original Message -
From: "Mark Reynolds" 
To: "389 Directory server developer discussion." 
<389-de...@lists.fedoraproject.org>
Sent: Tuesday, February 7, 2012 4:23:52 PM
Subject: [389-devel] please review ticket #129 - Should only update 
modifyTimestamp/modifiersName on MODIFY ops

https://fedorahosted.org/389/attachment/ticket/129

https://fedorahosted.org/389/attachment/ticket/129/0001-Ticket-129-Should-only-update-modifyTimestamp-modifi.patch

This issue was previously fixed, I just expanded the fix a little.

Thanks,
Mark
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: This is not the power switch you are looking for

[Michal Schmidt]

Jerry James wrote:
> [root@jerry-rawhide32 ~]# poweroff
> UNIT  LOAD   ACTIVE SUB   JOB DESCRIPTION
> proc-sys...misc.automount loaded active waiting Arbitrary
> Executable File

A bad systemd build due to a binutils bug:
https://bugzilla.redhat.com/show_bug.cgi?id=788107

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

Re: [389-devel] please review ticket #129 - Should only update modifyTimestamp/modifiersName on MODIFY ops

[Mark Reynolds]

I had a typo in part of the fix, but...

After looking at ticket #111, I think maybe we should add this flag to 
memberOf, referint, and maybe some other plugins.


Any thoughts on this?

Thanks,
Mark

PS - having email issues again, so this is a duplicate

On 02/07/2012 04:28 PM, Mark Reynolds wrote:
Actually after looking at ticket #111, I think maybe we should add 
this flag to memberOf, referint, and maybe some other plugins.


Any thoughts on this?

Thanks,
Mark 

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

Re: This is not the power switch you are looking for

[Jerry James]

On Tue, Feb 7, 2012 at 3:06 PM, Michal Schmidt  wrote:
> A bad systemd build due to a binutils bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=788107

Thank you very much for the link.  It'll be interesting to see if the
man page problem is related.
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: This is not the power switch you are looking for

[Michal Schmidt]

Jerry James wrote:
> Thank you very much for the link.  It'll be interesting to see if the
> man page problem is related.

You mean this error message?:
man: can't open /usr/share/man/halt.8: No such file or directory

No, that's not related to the binutils bug.
The error seems harmless, because it does open the expected
man page afterwards.

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

Re: This is not the power switch you are looking for

[Jerry James]

On Tue, Feb 7, 2012 at 3:51 PM, Michal Schmidt  wrote:
> You mean this error message?:
> man: can't open /usr/share/man/halt.8: No such file or directory

Yes.

>
> No, that's not related to the binutils bug.
> The error seems harmless, because it does open the expected
> man page afterwards.

I'm not sure what you mean by that; "man poweroff" only shows the
error message.  I just noticed from the error message that I should
try "man halt" instead.  You're right that it's not related, though.

$ zcat /usr/share/man/man8/poweroff.8.gz
.so halt.8

That should be:

.so man8/halt.8

I'll file a bug.
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [389-devel] please review ticket #129 - Should only update modifyTimestamp/modifiersName on MODIFY ops

[Mark Reynolds]

Actually after looking at ticket #111, I think maybe we should add this 
flag to memberOf, referint, and maybe some other plugins.


Any thoughts on this?

Thanks,
Mark

On 02/07/2012 04:23 PM, Mark Reynolds wrote:

https://fedorahosted.org/389/attachment/ticket/129

https://fedorahosted.org/389/attachment/ticket/129/0001-Ticket-129-Should-only-update-modifyTimestamp-modifi.patch 



This issue was previously fixed, I just expanded the fix a little.

Thanks,
Mark
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

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

Re: [389-devel] please review ticket #129 - Should only update modifyTimestamp/modifiersName on MODIFY ops

[Rich Megginson]

On 02/07/2012 02:42 PM, Mark Reynolds wrote:

I had a typo in part of the fix, but...

After looking at ticket #111, I think maybe we should add this flag to 
memberOf, referint, and maybe some other plugins.


Any thoughts on this?
If the concern is the audit trail, then when memberof, referint, etc. 
make some change to some other entry based on a change to the original 
entry, then the modifiersName should be the DN of the user that made the 
original change to the original entry that triggered the additional 
change.  Same with the modifyTimestamp.


However, for other uses e.g. updating the password policy failure 
attributes during a failed bind attempt, you might not want to update 
modifiersName and modifyTimestamp even though the entry was modified.


Thanks,
Mark

PS - having email issues again, so this is a duplicate

On 02/07/2012 04:28 PM, Mark Reynolds wrote:
Actually after looking at ticket #111, I think maybe we should add 
this flag to memberOf, referint, and maybe some other plugins.


Any thoughts on this?

Thanks,
Mark 

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


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

Re: This is not the power switch you are looking for

[Michal Schmidt]

Jerry James wrote:
> I'm not sure what you mean by that; "man poweroff" only shows the
> error message.

It worked for me. Perhaps because I had previously installed systemd
from sources and had a leftover manpage file where the man command
was able to find it.

> [...]
> I'll file a bug.

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

Subversion 1.7.1? Not 1.7.2?

[Bojan Smojver]

Is there a particular reason Rawhide etc. are stuck on 1.7.1? Is there a
known problem with 1.7.2 or something?

-- 
Bojan

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

/usrmove?

[David]

1) Will /usrmove already be 'done' in the Fedora 17 test ISO's?

2) Will Rawhide have a simple 'do this step-by-step' for the already
existing Rawhide /usr/move?

3) Will /usrmove be painless for those updating Fedora 16 or Fedora 15
or will we be biried for weeks with complaints of failed upgrades?


-- 

  David

"May your road lead you to warm sands."
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /usrmove?

[Kevin Fenzi]

On Tue, 07 Feb 2012 20:08:28 -0500
David  wrote:

> 1) Will /usrmove already be 'done' in the Fedora 17 test ISO's?

Any of them moving forward, yes. 

> 2) Will Rawhide have a simple 'do this step-by-step' for the already
> existing Rawhide /usr/move?

http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17

> 3) Will /usrmove be painless for those updating Fedora 16 or Fedora 15
> or will we be biried for weeks with complaints of failed upgrades?

If they are doing anaconda updates, it should be. 

Your testing very welcome to ensure that it is. 

kevin



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

[389-devel] Please review: [389 Project] #27: SASL/PLAIN binds do not work

[Noriko Hosoi]

https://fedorahosted.org/389/ticket/27

https://fedorahosted.org/389/attachment/ticket/27/0001-Trac-Ticket-27-SASL-PLAIN-binds-do-not-work.patch

Bug description: ids_sasl_canon_user failed to set "dn: " in front of 
the dn string in the output argument out_user. The dn string is used in 
the next session and the corresponding entry was not found due to the 
bad dn format (missing "dn: ").


Fix description: This patch adds the proper prefix.
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: /usrmove?

[David]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2/7/2012 8:15 PM, Kevin Fenzi wrote:
> On Tue, 07 Feb 2012 20:08:28 -0500 David  
> wrote:
> 
>> 1) Will /usrmove already be 'done' in the Fedora 17 test ISO's?
> 
> Any of them moving forward, yes.
> 
>> 2) Will Rawhide have a simple 'do this step-by-step' for the 
>> already existing Rawhide /usr/move?
> 
> http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17
>
>
> 
>> 3) Will /usrmove be painless for those updating Fedora 16 or 
>> Fedora 15 or will we be biried for weeks with complaints of 
>> failed upgrades?
> 
> If they are doing anaconda updates, it should be.
> 
> Your testing very welcome to ensure that it is.


Thanks for the info. Actually I asked because I had planned on trying
to help. I would be the 'regular user' type.  :-)


- -- 

  David

"May your road lead you to warm sands."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPMeBQAAoJEObJ14kUYB6pl1YIAK4+b2MiRuodySb+w00nR9ZS
uVWFgfwNWa93f16k1jqHUMtLBpMTqP30uOsFeA5kcn8lbyD5CBr7XzIMs99TWzra
N2uJxjvCvj0GnFGtGhcmemytr2M5TUHWCF+ruqGxc0mn6cx97WBm1RehgMClRxkk
721J80nhKR7/hABaYmIXsAM2kwVp3Ovh38byyobGrFViPM8hOJcILPG4e2tUaZGr
rJPr26toIioe9jBHb2QfMX0sryj4dqIJq9NqUYLDYFGjkObistHhBznp+5c91vAD
wub1oLvgt8c62zLqVEUCGx6IqI+N2sxni/8DoUhM6Ao3qQen8gT4Zex43jtVNOE=
=ar7E
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /usrmove?

[Adam Williamson]

On Tue, 2012-02-07 at 18:15 -0700, Kevin Fenzi wrote:
> On Tue, 07 Feb 2012 20:08:28 -0500
> David  wrote:
> 
> > 1) Will /usrmove already be 'done' in the Fedora 17 test ISO's?
> 
> Any of them moving forward, yes. 

It is not done in Alpha TC1. It will be there in Alpha TC2 and later.

> > 2) Will Rawhide have a simple 'do this step-by-step' for the already
> > existing Rawhide /usr/move?
> 
> http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17
> 
> > 3) Will /usrmove be painless for those updating Fedora 16 or Fedora 15
> > or will we be biried for weeks with complaints of failed upgrades?
> 
> If they are doing anaconda updates, it should be. 
> 
> Your testing very welcome to ensure that it is. 

Note that this has not actually been implemented in anaconda yet, so if
you do an anaconda upgrade at this time, it will explode horribly. The
bug requesting this support be added to anaconda is
http://bugzilla.redhat.com/show_bug.cgi?id=787893 .
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: /usrmove?

[Chris Murphy]

On Feb 7, 2012, at 7:46 PM, Adam Williamson wrote:
> Note that this has not actually been implemented in anaconda yet, so if
> you do an anaconda upgrade at this time, it will explode horribly. 

So the instructions here:
http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17

Are the expected steps to move from F16 to F17 Alpha TC1? And then by Alpha TC2 
the expectation is that these steps will be performed by anaconda?


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

Re: /usrmove?

[Bruno Wolff III]

On Tue, Feb 07, 2012 at 20:57:05 -0700,
  Chris Murphy  wrote:
> 
> 
> On Feb 7, 2012, at 7:46 PM, Adam Williamson wrote:
> > Note that this has not actually been implemented in anaconda yet, so if
> > you do an anaconda upgrade at this time, it will explode horribly. 
> 
> So the instructions here:
> http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17
> 
> Are the expected steps to move from F16 to F17 Alpha TC1? And then by Alpha 
> TC2 the expectation is that these steps will be performed by anaconda?

That's for doing a yum upgrade, not anaconda.

A few people (including me) have done this either from (pre usrmove) rawhide
or from an earlier release. It doesn't seem to be any harder than yum
upgrades normally are.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /usrmove?

[Kevin Kofler]

Adam Williamson wrote:
> Note that this has not actually been implemented in anaconda yet, so if
> you do an anaconda upgrade at this time, it will explode horribly. The
> bug requesting this support be added to anaconda is
> http://bugzilla.redhat.com/show_bug.cgi?id=787893 .

It's totally unacceptable that this "feature" has been merged in this 
incomplete state. Working upgrades should have been a prerequisite for 
merging it! Anaconda upgrades are even part of our release criteria! This 
affects both the DVD upgrades and preupgrade, which are the 2 upgrade 
methods Fedora claims to support.

Kevin Kofler

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

Re: /usrmove?

[Stijn Hoop]

On Wed, 08 Feb 2012 06:37:33 +0100
Kevin Kofler  wrote:
> Adam Williamson wrote:
> > Note that this has not actually been implemented in anaconda yet,
> > so if you do an anaconda upgrade at this time, it will explode
> > horribly. The bug requesting this support be added to anaconda is
> > http://bugzilla.redhat.com/show_bug.cgi?id=787893 .
> 
> It's totally unacceptable that this "feature" has been merged in this 
> incomplete state. Working upgrades should have been a prerequisite
> for merging it! Anaconda upgrades are even part of our release
 ^^^
> criteria! This affects both the DVD upgrades and preupgrade, which
> are the 2 upgrade methods Fedora claims to support.

I did not see a release yet, where did you find it?

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