Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Garrett Holmstrom]

On 2012-11-05 12:22, "Jóhann B. Guðmundsson" wrote:

On 11/05/2012 07:52 PM, Miloslav Trmač wrote:

A crit path update that affects, say, two packages and nothing else,
could be "approved by default" as well.  Many of the crit path
features however affect a large or extremely large package set (e.g.
the sysv->systemd script migration), in which case explicitly
involving every maintainer as the feature owner before even proposing
the feature wouldn't scale; that's where FESCo does need to step in as
a more efficient way to represent the large group of packagers.


Case in point for F18 [1] and perfect example of one thing that should
have been completed within one release cycle...

JBG


1.http://fedoraproject.org/wiki/Features/PackagePresets


As that feature is about changing distribution-wide policy, I cannot act 
on it until said policy is written.  (See 
https://fedorahosted.org/fesco/ticket/945)  The feature's owners do not 
appear to be interested in doing so.  If you are, I would greatly 
appreciate it if you would add a proposal to that FESCo ticket so I can 
have a clear path forward.

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

Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El Mon, 5 Nov 2012 08:39:54 +0100
drago01  escribió:
> On Mon, Nov 5, 2012 at 5:57 AM, Dennis Gilmore 
> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > El Wed, 31 Oct 2012 10:59:54 -0700
> > Jesse Keating  escribió:
> >> On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
> >> > * Jesse Keating, Jeremy Katz, and others who helped shape the
> >> > current policy and theory of our release schedule felt that the 6
> >> > month release cycle was fine but that certain features were going
> >> > to take longer to develop. Those would need to be developed and
> >> > not enter into Fedora until they were close enough that they
> >> > could be completed during that cycle.
> >> >- No matter what we do to try and increase the development
> >> > cycle within a release, there's always going to be issues that
> >> > take longer than the release that we need to deal with.
> >> > Perhaps, we just need to be better about making people follow
> >> > this model.
> >>
> >> I'm not entirely sure what I felt then, but I'm certainly open to a
> >> longer release cycle.  In fact I'm very much in favor of one, one
> >> that puts more time between "feature complete" and the actual alpha
> >> release. All too often we see features crash land right at the
> >> deadline, and any software that has to integrate across a lot of
> >> pieces (like anaconda) gets stuck trying to account for all these
> >> changes in a very limited time frame, only to be hindered quickly
> >> by a freeze process.
> >
> > I really do not object to a longer release cycle.  I am also open to
> > making feature freeze being 4-6 weeks before Alpha change freeze.
> > The risk we run is people land new features anyway. but we run that
> > today. We always have a run of things late. People need to land
> > changes earlier  the bigger the change the earlier it needs to
> > land.  Maybe it wont be a popular idea but having feature freeze at
> > previous release time is needed. What I am thinking is:
> >
> > Branch as we do, which opens up development for next release same as
> > we do today, so in the current cycle when we branched off f18, f19
> > features needed to start landing so all that would be taken for f18
> > is bug fix and integration fixes.  when we release f18 we hit F19
> > feature freeze.
> 
> That does not work because we do not have unlimited resources ... you
> can't expect people to work on F19 features at the same time while
> they are trying to get F18 ready for release.
> Honestly I don't think that the current issues have anything to do
> with the schedule but more with the way we handled the anaconda
> feature. We should just fix that and not try to make random changes
> all over the place.
When you doing the major work earlier the work to get the polish and
fix the unforeseen issues is smaller, i don't envisage that it needs
more resources just a change in focus and how we do things.

> 
> Basically there should not be any "this cannot be reverted" (there is
> no such thing really) features. If it is evident before the feature
> freeze that a given feature would not be ready in time we have to punt
> it to the next release PERIOD.

realistically most features cant be reverted easily.  and people will
do and say anything to not have them reverted. often the work to punt
the brokenness is the same as to fix it. the sooner we freeze features
the more time we have to fix the fallout. 

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlCYm7QACgkQkSxm47BaWfftyQCguB9b7tonxviCmXo957I2ZCY3
gZcAn0DoZ/bnNmJdyURL0It69dbUSBp6
=V+xv
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El Mon, 5 Nov 2012 11:32:07 -0700
Kevin Fenzi  escribió:
> On Mon, 5 Nov 2012 18:55:51 +0100
> Till Maas  wrote:
> 
> > Rawhide is not intended to be used for anything important and with
> > any security sensitive data because the used packages are not
> > signed. Whenever I asked to get Rawhide packages signed I was also
> > told that it is, because of Rawhide's use case. Everybody using
> > Rawhide for example to maintainer Fedora packages is endangering
> > the Fedora project.
> 
> I am pretty sure there was a plan to make koji sign packages. I don't
> know what the status of it is however. 

No one is working on it at all. Im actually kind of against the idea.
as things currently stand we would instantly double the disk we need
for /mnt/koji all the key would give us is a yes this build was done as
a real build in koji. the security of the gpg key would be less since
we need to have automated processes able to access the key. the value
of the signed rpm is less.  it also opens up another attack vector that
"could" be exploited.  we would need to sign the metadata or still
resign all the rpms which each has associated costs. signing the
metadata means someone will need to manually do it at the end of a
package push process. in the case of branched or rawhide if we signed
its metadata could be hours until someone wakes up to sign the
metadata. or changing when the runs happen. so that it lands later. 

to me the big issue becomes we cant trust the key as much, since its
either open or the password to unlock it is stored in plain text
somewhere so that it can be unlocked  or rpms automatically signed. the
only way to really have it work right would reduce the security and
trust in the key. all we would gain is a way to distinguish an offical
build vs a scratch build in koji or a build someone did to mimic our
environment.

> I would personally love to see koji sign all official builds with a
> "This was built in koji" key. 
> 
> > Nevertheless, I still believe it would be better if Fedora started
> > to provide signed packages directly from Koji including Rawhide to
> > end this problem. 
> 
> I agree. Any koji folks have any ideas on the status of this feature
> request? 
> 
> Oh look: 
> https://fedorahosted.org/koji/ticket/203
> 
> Looks like there are patches there... anyone able to test or provide
> more feedback to get it moving?

AFAIK the patches are not at all tested, ive not looked to see if it
would mean we end up using twice the disk we use today or not. it would
also prevent the ability to reclaim disk by purging the signed copy of
the rpm easily. since all rpms would be signed with the same key. we
then would need to either not have our gpg keys expire  or have
processes to resign everything and  switch over to new keys or some
other transitiion method.

> > But looking at the current fedup code it seems that
> > Fedora is going to be the first distribution that abandons package
> > security more and more instead of trying to improve it. As far as I
> > know starting with preupgrade doing insecure updates were promoted
> > and now they are going to be made mandatory (except for the
> > unsupported yum update method).
> 
> Please file bugs/patches? 
> 
> I'd like fedup to verify packages if it doesnt already. I'm sure
> others would too. 
I would think that fedup should force the verification of packages. as
long as its not rawhide they are all signed and can be verified.

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlCYl4EACgkQkSxm47BaWfeK4gCfTZFs9k1cJscCVJuaElPe5jFK
9oMAoK1xnwjEx9kQdQFt7XHKHcaNTd74
=52Ak
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[M. Edward (Ed) Borasky]

On Mon, Nov 5, 2012 at 2:06 PM, Matthew Miller  wrote:
> On Mon, Nov 05, 2012 at 01:58:05PM -0800, Jesse Keating wrote:
>> That might be because nobody can get past the
>> installer to test any of the GNOME bits.
>
> Heh. In seriousness, I've been running F18 GNOME on my laptop and, while I
> have a number of annoyances with some design decisions (some patched up by
> shell extensions, some not), it seems pretty solid with not very many
> outright bugs.

Yeah - I shifted my laptop from Fedora 17 GNOME 3 to Fedora 18 TC7
GNOME 3 Saturday and it's behaving very well. I'm doing a lot of
testing with Virtual Machine Manager building all sorts of VMs and so
far the only thing that's bitten me is some bizarre issue with Lubuntu
12.10.

-- 
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: 
http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/

How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F-18 Branched report: 20121031 changes

[Iain Arnell]

On Nov 5, 2012 1:21 PM, "Stephen John Smoogen"  wrote:
>
> On 5 November 2012 11:17, Tom Callaway  wrote:
> > On 11/05/2012 09:21 AM, Paul Howarth wrote:
> >> On 10/31/2012 07:53 PM, Tom Callaway wrote:
>  [perl-Hardware-Verilog-Parser]
>  perl-Hardware-Verilog-Parser-0.13-9.fc17.noarch requires
>  perl(:MODULE_COMPAT_5.14.2)
> >>>
> >>> Really broken. Does not build with current perl. I suggest that it be
> >>> buried in a hole and covered up with a fire (or, if someone loves
> >>> Parse::RecDescent, they can try to fix it).
> >>
> >> I took a look at it and managed to spot the typos causing the problems.
> >>
> >>
https://admin.fedoraproject.org/updates/perl-Hardware-Verilog-Parser-0.13-12.fc18
> >
> > My hat is off to you, sir. :)
> >
>
>
> Wait wait.. I got the kerosene and gunpowder.. are we lighting this
> package on fire or not?

Well it is November 5th. Just don't be using Paul as the Guy.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: MPI updates

[Orion Poplawski]

On 11/02/2012 05:10 PM, Orion Poplawski wrote:

On 11/01/2012 04:21 PM, Jussi Lehtola wrote:

On Thu, 01 Nov 2012 09:08:36 -0600
Orion Poplawski  wrote:

Some MPI updates:

- I built openmpi 1.6.3 in rawhide yesterday.  This had an unexpected
bump in the libmpi_f90.so soname.  I know this affects hdf5 and
netcdf-fortran, both my packages and I'll be rebuilding them later
today (hopefully).


Given that f18 has 1.6, I believe the same update should be made on f18
as well.



Sounds good. I'm holding off for now though because the soname bump in
libmpi_f90.so may have been a mistake.  Waiting for word from upstream.



soname bump was a mistake.  Fixed package has been submitted for F18:

https://admin.fedoraproject.org/updates/openmpi-1.6.3-4.fc18

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

Re: Rawhide

[Nicolas Mailhot]

Le Lun 5 novembre 2012 22:33, Matthias Clasen a écrit :
> On Mon, 2012-11-05 at 17:04 +0100, Nicolas Mailhot wrote:
>
>> You proposal may work *if* GNOME people take care to respect it.
>> Otherwise
>> — yes the nuclear option is to only distribute GNOME releases that were
>> ready at branch time and could be stabilised during all the Fedora test
>> releases. It may seem excessive but the current
>> it-says-it-is-stable-push-it-to-users-without-testing policy has not
>> been
>> good for both of the projects I think.
>
> Not sure what you are trying to say - looking at the current blocker but
> list, I see barely any GNOME bug there.

Maybe because people have stopped filling them ?

I can reliably make dconf and gnome-settings eat all system cpu and make
the computer unusable short of an hard reset, have been able to do so for
months, reported it once or twice, the reports were closed each time with
unhelpful comments (do not care about rawhide/if it's misbehaving, it's
because something else makes it misbehave — even though the only thing
running is the gnome shell) so now I don't bother reporting at all (and
that's not the only problem, only the most critical and coe one I see)

When I have testing cycles to spare I send reports to Dan Walsh who does
run rawhide and does make something with the reports I fill.

Bottom line, GNOME has been very successful in discouraging messengers it
didn't like, that does not make it any less broken unfortunately.

-- 
Nicolas Mailhot

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

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Alek Paunov]

On 05.11.2012 15:57, Simo Sorce wrote:


A possibly viable alternative for the ABIs freezing (which we can not
ensure anyway) is the C/C++/etc tooling - If we arm upstreams, packagers
and 3rd parties with powerful source tools (API migration/checking),
just like Google does internally, unsing the  Clang tooling, witch was
developed exactly for this purpose.

The GCC/OpenJDK tooling development is not something appropriate as
effort for the manpower of almost any upstream, but IMHO should be seen
as important goal for relatively big player like Fedora.


Unfortunately it won't work, unless you are ready to also go and mark
reliable and unreliable upstreams, which is ... difficult.

The reason I say so is that I know for sure not all upstreams are
willing to maintain ABI compatibility. There are various degrees but
some go for absolute ABI compatibility at all costs (glibc) to "I'll
break the ABI on purpose (or because I don't care) at every upgrade
(won't try to name names).



My point was about the second group (dependency providers with evolving 
ABIs) and more specifically about the affected packages (their users - 
dependency consumers). When the consumers are short on resources or just 
don't really care so much about the current Fedora consistency, the 
problem naturally lands at the responsibility of the respective Fedora 
maintainers.


The whole dance would be sufficiently different if we provide the 
cooperative upstreams with powerful tools for aligning their projects 
with the current/prepared release "compound" ABI.


IMO, this means Fedora VMs (not necessarily sponsored by the project, I 
am sure that the Cloud SIG has enough magic at hand to orchestrate 
community/upstreams provided instances) and preinstalled compiler 
plugins based tooling - easy to use instruments for checking and fixing 
their sources according the release environment state.


The above applies also for the third parties (propriety software vendors 
and these with open source licenses but not so open style of 
development) - they probably will spent few dozens of hours to "lint", 
once we provide them with ready to use "login and type 'make'" environment.


Of course, not any upstream would be willing to cooperate - in this case 
we will have to handle the issue with our own resources, but again the 
tooling can reduce the time spent by the packagers with an order of 
magnitude.


Fedora is almost always the First, once we start doing this proactive 
"Upstreams alignment" technology and effort, maybe other Linux OS 
vendors would join too.


Kind Regards,
Alek

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

Re: Rawhide

[Matthew Miller]

On Mon, Nov 05, 2012 at 01:58:05PM -0800, Jesse Keating wrote:
> That might be because nobody can get past the
> installer to test any of the GNOME bits.

Heh. In seriousness, I've been running F18 GNOME on my laptop and, while I
have a number of annoyances with some design decisions (some patched up by
shell extensions, some not), it seems pretty solid with not very many
outright bugs.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Review Swap: ownCloud Server

[Kevin Fenzi]

On Mon, 05 Nov 2012 22:49:04 +0100
Gregor Tätzner  wrote:

> Hello guys and girls,
> 
> I need a review for owncloud:
> https://bugzilla.redhat.com/show_bug.cgi?id=858841
> 
> the licences are good, note that there is not much time left if we
> want to achieve this approved f18 feature [1]

Note that there is negative time to achieve this f18 feature, that has
moved to target f19. ;) 

kevin


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

Re: Review Swap: ownCloud Server

[Matthew Miller]

On Mon, Nov 05, 2012 at 10:49:04PM +0100, Gregor Tätzner wrote:
> Hello guys and girls,
> I need a review for owncloud:
> https://bugzilla.redhat.com/show_bug.cgi?id=858841
> the licences are good, note that there is not much time left if we want to 
> achieve this approved f18 feature [1]
> I admit, this package is quite big. But in return I would be happy to review 
> 2-3 packages

I'll take it. And I'll take a rain-check on the swaps. (Will look tomorrow.)


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[Jesse Keating]

On 11/04/2012 01:31 AM, Panu Matilainen wrote:


Yeh, autoqa can't do a whole lot when its builds often intentionally
dependencies break (eg soname bumps). Unless such builds were required
to be done in a staging area - this is *possible* already but not much
used. It'd have to be reasonably convenient for the developers though,
IIRC this requires rel-eng intervention currently.


The long term plan with AutoQA was to have a staging area.

build -> stage -> AutoQA -> rawhide.

If your package passes autoqa, it goes into rawhide.  If it fails, the 
dev can override and send it on anyway, or try again with a newer build.


--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Review Swap: ownCloud Server

[Gregor Tätzner]

Hello guys and girls,

I need a review for owncloud:
https://bugzilla.redhat.com/show_bug.cgi?id=858841

the licences are good, note that there is not much time left if we want to 
achieve this approved f18 feature [1]

I admit, this package is quite big. But in return I would be happy to review 
2-3 packages

Cheers,
Greg

[1]
http://fedoraproject.org/wiki/Features/OwnCloud

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

Re: Rawhide

[Matthias Clasen]

On Mon, 2012-11-05 at 17:04 +0100, Nicolas Mailhot wrote:

> You proposal may work *if* GNOME people take care to respect it. Otherwise
> — yes the nuclear option is to only distribute GNOME releases that were
> ready at branch time and could be stabilised during all the Fedora test
> releases. It may seem excessive but the current
> it-says-it-is-stable-push-it-to-users-without-testing policy has not been
> good for both of the projects I think.

Not sure what you are trying to say - looking at the current blocker but
list, I see barely any GNOME bug there.

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

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Stephen John Smoogen]

On 4 November 2012 23:57, drago01  wrote:
> On Sun, Nov 4, 2012 at 6:55 PM, Adam Williamson  wrote:
>> On Sun, 2012-11-04 at 12:18 -0500, Simo Sorce wrote:
>>> On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote:
>>> > Hi,
>>> >
>>> > 2012/11/3 Adam Williamson :
>>> > > Note
>>> > > that neither Red Hat nor Microsoft actually support major version
>>> > > upgrades for their operating systems
>>>
>>> Adam, this is plainly untrue for Microsoft, they always supported
>>> upgrading to the next version.
>>
>> As someone already pointed out, 'support' is an overloaded term. They
>> 'support' upgrades the same way we 'support' upgrades - they provide an
>> upgrade mechanism for you to hang yourself with. As was clarified later,
>> the point is that they don't guarantee it will work,
>
> [citation needed]
>
> I can't believe that they were selling something "windows X upgrade"
> without supporting it at all.
> That's like selling a car and telling the customer "it might not move
> at all in that case you are on your own sorry".

I only have my personal experience because trying to find the exact
line in the tiny print which covers it requires me to know more legal
terms than I do. The scenarios I have run into multiple times is where
a manager decided to not pay Microsoft for their upgrade support and
ended up with having to pay for some sort of tiger team to figure out
what went wrong. Usually it is not with the core OS.. that upgrades
fine.. it is usually with registry and non-core programs OR it might
be hardware drivers for anything above the basics .

At which point Microsoft will point you towards the OEM or software
group that manufactures that software.. which is very fun when that is
Microsoft itself.


-- 
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"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: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Jóhann B. Guðmundsson]

On 11/05/2012 07:52 PM, Miloslav Trmač wrote:

A crit path update that affects, say, two packages and nothing else,
could be "approved by default" as well.  Many of the crit path
features however affect a large or extremely large package set (e.g.
the sysv->systemd script migration), in which case explicitly
involving every maintainer as the feature owner before even proposing
the feature wouldn't scale; that's where FESCo does need to step in as
a more efficient way to represent the large group of packagers.


Case in point for F18 [1] and perfect example of one thing that should 
have been completed within one release cycle...


JBG


1.http://fedoraproject.org/wiki/Features/PackagePresets
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F-18 Branched report: 20121031 changes

[Stephen John Smoogen]

On 5 November 2012 11:17, Tom Callaway  wrote:
> On 11/05/2012 09:21 AM, Paul Howarth wrote:
>> On 10/31/2012 07:53 PM, Tom Callaway wrote:
 [perl-Hardware-Verilog-Parser]
 perl-Hardware-Verilog-Parser-0.13-9.fc17.noarch requires
 perl(:MODULE_COMPAT_5.14.2)
>>>
>>> Really broken. Does not build with current perl. I suggest that it be
>>> buried in a hole and covered up with a fire (or, if someone loves
>>> Parse::RecDescent, they can try to fix it).
>>
>> I took a look at it and managed to spot the typos causing the problems.
>>
>> https://admin.fedoraproject.org/updates/perl-Hardware-Verilog-Parser-0.13-12.fc18
>
> My hat is off to you, sir. :)
>


Wait wait.. I got the kerosene and gunpowder.. are we lighting this
package on fire or not?


-- 
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"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: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Miloslav Trmač]

On Mon, Nov 5, 2012 at 8:38 PM, Matthew Miller  wrote:
> On Mon, Nov 05, 2012 at 07:55:26PM +0100, Miloslav Trmač wrote:
>> > Here, I think you're smooshing together two of the three levels I'd
>> > suggested, putting both non-crit-path enhancements and new leaf
>> > functionality into one category. Is that correct?
>> Yes, the "self-contained" wording covers both leaf features and a
>> subset of non-leaf features.  "Non-crit-path" and "all relevant
>> maintainer are involved" are different subsets of non-leaf features,
>> however.
>
> From the point of view of evaluating impact, and for that matter for the
> release notes, I think it's good to have big-non-crit-path-enhancements and
> leaf functionality categorized separately. Both of them would need to be
> self contained in the sense you're suggesting.

Sure, the primary measure is the overall impact on the OS.  The
proposal is to treat "self-contained" features as "approved by
default", nothing more; features with large impact would still go
through the full process by overriding the default approval.

> In fact, for that matter, wouldn't crit path updates _also_ benefit from the
> "all relevant maintainers" rule?

A crit path update that affects, say, two packages and nothing else,
could be "approved by default" as well.  Many of the crit path
features however affect a large or extremely large package set (e.g.
the sysv->systemd script migration), in which case explicitly
involving every maintainer as the feature owner before even proposing
the feature wouldn't scale; that's where FESCo does need to step in as
a more efficient way to represent the large group of packagers.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Matthew Miller]

On Mon, Nov 05, 2012 at 07:55:26PM +0100, Miloslav Trmač wrote:
> > Here, I think you're smooshing together two of the three levels I'd
> > suggested, putting both non-crit-path enhancements and new leaf
> > functionality into one category. Is that correct?
> Yes, the "self-contained" wording covers both leaf features and a
> subset of non-leaf features.  "Non-crit-path" and "all relevant
> maintainer are involved" are different subsets of non-leaf features,
> however.

From the point of view of evaluating impact, and for that matter for the
release notes, I think it's good to have big-non-crit-path-enhancements and
leaf functionality categorized separately. Both of them would need to be
self contained in the sense you're suggesting.

In fact, for that matter, wouldn't crit path updates _also_ benefit from the
"all relevant maintainers" rule? 



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[John . Florian]

> From: "Jóhann B. Guðmundsson" 
> 
> On 11/05/2012 05:28 PM, Przemek Klosowski wrote:
> > On 11/02/2012 07:04 PM, Adam Williamson wrote:
> >
> >> Sure, like I said in another mail, we've got better at that than 
before.
> >> But as I also said in the same mail, you still have to do a version
> >> upgrade every twelve months. That alone is ridiculous for a 'stable'
> >> operating system.
> >>
> >
> > This is an important point---it makes it difficult to deploy Fedora 
> > for other people. When the end-of-support comes, it usually means 
> > having to reinstall, because upgrade can take unbounded time, if 
> > problems pop up. Additionally, in my experience, a reinstall often 
> > results in a better configuration, free of grandfathered suboptimal 
> > settings.
> >
> > I keep thinking about a scheme to roll over an EOL Fedora into a 
> > closest possible CENTOS. It's not trivial because I can't just look 
> > for the CENTOS that matches the original Fedora release, because of 
> > the subsequent updates. It would have to look at the as-is system and 
> > try to figure out the best matching CENTOS release. I am thinking 
> > about a sum-of-squared-differences-like distance metric: calculate sum 

> > over all packages of (installed_version - CENTOS_X_version)^2, for 
> > several CENTOS_X versions, and chose the one giving the smallest 
> > value. Of course some packages (glibc, kernel) would have a higher 
> > weight, but that could be incorporated (\sum_i((v1_i-v2_i)^2/wght_i)).
> 
> Well I personally would rather have centos and other rhel clones unite 
> to support a lts release of Fedora instead since it does not take more 
> then a missing sysadmin or rhel business decision to more or less render 

> those community incapacitated

+1

This is exactly why I've never adopted one of them.  Like the concept, but 
fear such situations.  I'd love to have a LTS for my servers and have 
something like a rolling Fedora release for *my* workstations.  Other 
workstations that I help support, perhaps something in between.

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

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Jóhann B. Guðmundsson]

On 11/05/2012 05:28 PM, Przemek Klosowski wrote:

On 11/02/2012 07:04 PM, Adam Williamson wrote:


Sure, like I said in another mail, we've got better at that than before.
But as I also said in the same mail, you still have to do a version
upgrade every twelve months. That alone is ridiculous for a 'stable'
operating system.



This is an important point---it makes it difficult to deploy Fedora 
for other people. When the end-of-support comes, it usually means 
having to reinstall, because upgrade can take unbounded time, if 
problems pop up. Additionally, in my experience, a reinstall often 
results in a better configuration, free of grandfathered suboptimal 
settings.


I keep thinking about a scheme to roll over an EOL Fedora into a 
closest possible CENTOS. It's not trivial because I can't just look 
for the CENTOS that matches the original Fedora release, because of 
the subsequent updates. It would have to look at the as-is system and 
try to figure out the best matching CENTOS release. I am thinking 
about a sum-of-squared-differences-like distance metric: calculate sum 
over all packages of (installed_version - CENTOS_X_version)^2, for 
several CENTOS_X versions, and chose the one giving the smallest 
value. Of course some packages (glibc, kernel) would have a higher 
weight, but that could be incorporated (\sum_i((v1_i-v2_i)^2/wght_i)).


Well I personally would rather have centos and other rhel clones unite 
to support a lts release of Fedora instead since it does not take more 
then a missing sysadmin or rhel business decision to more or less render 
those community incapacitated


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

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[mike cloaked]

On Mon, Nov 5, 2012 at 6:34 PM, Bruno Wolff III  wrote:

>
>>> >It's a clean installation, I don't think it needs any magic. Also
>>> >third-party repos are not a problem, we just ignore them and they
>>> >won't influence the new system. People will add them manually again
>>> >once in 18 months.
>>>
>>> There is desktop config in people's home directories that may not
>>> work with
>>> updated packages as expected.
>>>
>>
>> Package updates don't touch your /home. Clean install is the same as
>> package updates in these regards.
>>
>
> But the updated packages may not like old configs. There is still
> potential for occasional problems there.
>
>
The way it might go is that if you have a package update which needs a new
config then you have the update process install a config.rpmnew config file
and add a note that due to the change a manual merge of old and new config
files is needed - it is usually not more than a couple of minutes effort to
do that - and provided that there is some advice that maybe even is in the
yum output and in the yum log file with a simple summary of what is needed
then it need not be a big deal - a simple wiki entry somewhere explaining
how to use "diff" or "vimdiff" would work wonders for the majority of users
to merge config files to keep up to date would not be too much effort would
it?

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

[perl-Image-ExifTool/f16] 9.04

[Tom Callaway]

commit af02a0505ef86b324198076787f70a33bfd051c3
Author: Tom Callaway 
Date:   Mon Nov 5 14:03:47 2012 -0500

9.04

 perl-Image-ExifTool.spec |5 -
 sources  |2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Image-ExifTool.spec b/perl-Image-ExifTool.spec
index c9a7aa1..0eaaa37 100644
--- a/perl-Image-ExifTool.spec
+++ b/perl-Image-ExifTool.spec
@@ -1,5 +1,5 @@
 Name:  perl-Image-ExifTool
-Version:   9.01
+Version:   9.04
 Release:   1%{?dist}
 License:   GPL+ or Artistic
 Group: Applications/Multimedia
@@ -51,6 +51,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Nov  5 2012 Tom Callaway  - 9.04-1
+- update to 9.04 (stable)
+
 * Sat Aug 25 2012 Tom Callaway  - 9.01-1
 - update to 9.01 (stable)
 
diff --git a/sources b/sources
index 5d17346..4ab4f8b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-715a07265f59f8c175e6ba38090e623a  Image-ExifTool-9.01.tar.gz
+7f62eae65b6ca1ac140268df98de192b  Image-ExifTool-9.04.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File Image-ExifTool-9.04.tar.gz uploaded to lookaside cache by spot

[Tom Callaway]

A file has been added to the lookaside cache for perl-Image-ExifTool:

7f62eae65b6ca1ac140268df98de192b  Image-ExifTool-9.04.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Miloslav Trmač]

On Mon, Nov 5, 2012 at 7:34 PM, Matthew Miller  wrote:
> On Mon, Nov 05, 2012 at 05:45:14PM +0100, Miloslav Trmač wrote:
>> > I think "Leaf" is better than "Self contained", since it's unlikely for
>> > the feature to have zero outside dependencies. I think it'd be fine for
>> > such a feature to rely on small changes to existing packages (version
>> > updates, say).
>> "Self-contained" in the proposal is intentionally more broad than
>> "leaf".  For example, it allows a small SIG for a less-used language
>> that does not affect the rest of the distribution to agree to do a
>> major version upgrade and to coordinate among the SIG members (as they
>> would coordinate in any case), without FESCo playing an useless
>> middle-man.
>>
>> (The suggested definition of "self-contained" is something like
>> "maintainers of all affected packages sign up to participate on the
>> work for the feature".)
>
> I don't mind too much what the actual name is as long as the scope is clear.
>
> Here, I think you're smooshing together two of the three levels I'd
> suggested, putting both non-crit-path enhancements and new leaf
> functionality into one category. Is that correct?

Yes, the "self-contained" wording covers both leaf features and a
subset of non-leaf features.  "Non-crit-path" and "all relevant
maintainer are involved" are different subsets of non-leaf features,
however.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[Bruno Wolff III]

On Mon, Nov 05, 2012 at 11:32:07 -0700,
  Kevin Fenzi  wrote:


I would personally love to see koji sign all official builds with a
"This was built in koji" key.


If the same key is used regardless of release that could allow for hard 
links to builds inherited from another release. That could speed up 
mirroring.

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

Re: Rawhide

[Matthew Miller]

On Mon, Nov 05, 2012 at 11:32:07AM -0700, Kevin Fenzi wrote:
> > Fedora is going to be the first distribution that abandons package
> > security more and more instead of trying to improve it. As far as I know
> > starting with preupgrade doing insecure updates were promoted and now
> > they are going to be made mandatory (except for the unsupported yum
> > update method).
> Please file bugs/patches? 
> I'd like fedup to verify packages if it doesnt already. I'm sure others
> would too. 

Er, yes. Very much.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Bruno Wolff III]

On Mon, Nov 05, 2012 at 13:23:59 -0500,
  Kamil Paral  wrote:

>> This tool is still not going to be able to do magic and there will
>> be
>> config
>> things that still need to be redone. Third party repos will still
>> be
>> an issue.
>
>It's a clean installation, I don't think it needs any magic. Also
>third-party repos are not a problem, we just ignore them and they
>won't influence the new system. People will add them manually again
>once in 18 months.

There is desktop config in people's home directories that may not
work with
updated packages as expected.


Package updates don't touch your /home. Clean install is the same as package 
updates in these regards.


But the updated packages may not like old configs. There is still potential 
for occasional problems there.



Please read my email again:

** Power users would have to manually transfer /etc changes, add custom repos, 
etc. But if you need to do that only once every 18 months, it's not so bad. 
Also, a lot of power users would use Fedora Rolling instead, so they would not 
be affected at all. Some power users can even do unsupported yum upgrades (as 
many of them do now), so they won't be affected by it either.


It wouldn't be done automatically, no. All this stuff would have to be setup 
again manually. But that's just my view.


I was figuring that many people that enabled rpmfusion to get, say media 
codecs, would not fall into the power user category.


/var is another tricky area. There are good and bad things about keeping and 
replacing it.


Nothing we do is going to be perfect for going from one release to another. 
Putting more work into making that go smoothly is going to be useful as 
long as we have releases.

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

Re: Rawhide

[Kevin Fenzi]

On Mon, 5 Nov 2012 18:55:51 +0100
Till Maas  wrote:

> Rawhide is not intended to be used for anything important and with any
> security sensitive data because the used packages are not signed.
> Whenever I asked to get Rawhide packages signed I was also told that
> it is, because of Rawhide's use case. Everybody using Rawhide for
> example to maintainer Fedora packages is endangering the Fedora
> project.

I am pretty sure there was a plan to make koji sign packages. I don't
know what the status of it is however. 

I would personally love to see koji sign all official builds with a
"This was built in koji" key. 

> Nevertheless, I still believe it would be better if Fedora started to
> provide signed packages directly from Koji including Rawhide to end
> this problem. 

I agree. Any koji folks have any ideas on the status of this feature
request? 

Oh look: 
https://fedorahosted.org/koji/ticket/203

Looks like there are patches there... anyone able to test or provide
more feedback to get it moving?

> But looking at the current fedup code it seems that
> Fedora is going to be the first distribution that abandons package
> security more and more instead of trying to improve it. As far as I
> know starting with preupgrade doing insecure updates were promoted
> and now they are going to be made mandatory (except for the
> unsupported yum update method).

Please file bugs/patches? 

I'd like fedup to verify packages if it doesnt already. I'm sure others
would too. 

kevin


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

Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Matthew Miller]

On Mon, Nov 05, 2012 at 05:45:14PM +0100, Miloslav Trmač wrote:
> > I think "Leaf" is better than "Self contained", since it's unlikely for
> > the feature to have zero outside dependencies. I think it'd be fine for
> > such a feature to rely on small changes to existing packages (version
> > updates, say).
> "Self-contained" in the proposal is intentionally more broad than
> "leaf".  For example, it allows a small SIG for a less-used language
> that does not affect the rest of the distribution to agree to do a
> major version upgrade and to coordinate among the SIG members (as they
> would coordinate in any case), without FESCo playing an useless
> middle-man.
> 
> (The suggested definition of "self-contained" is something like
> "maintainers of all affected packages sign up to participate on the
> work for the feature".)

I don't mind too much what the actual name is as long as the scope is clear.

Here, I think you're smooshing together two of the three levels I'd
suggested, putting both non-crit-path enhancements and new leaf
functionality into one category. Is that correct?



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Kamil Paral]

> >> This tool is still not going to be able to do magic and there will
> >> be
> >> config
> >> things that still need to be redone. Third party repos will still
> >> be
> >> an issue.
> >
> >It's a clean installation, I don't think it needs any magic. Also
> >third-party repos are not a problem, we just ignore them and they
> >won't influence the new system. People will add them manually again
> >once in 18 months.
> 
> There is desktop config in people's home directories that may not
> work with
> updated packages as expected.

Package updates don't touch your /home. Clean install is the same as package 
updates in these regards.

> 
> Custom configuation done in /etc is lost.
> 
> How do they get the packages from the third party repos reinstalled?
> Fedora will probably be limited in doing this in a fully automated
> way,
> since there are legal issues.
> 

Please read my email again:
> ** Power users would have to manually transfer /etc changes, add custom 
> repos, etc. But if you need to do that only once every 18 months, it's not so 
> bad. Also, a lot of power users would use Fedora Rolling instead, so they 
> would not be affected at all. Some power users can even do unsupported yum 
> upgrades (as many of them do now), so they won't be affected by it either.

It wouldn't be done automatically, no. All this stuff would have to be setup 
again manually. But that's just my view.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposal: changing development cycle

[Kevin Fenzi]

On Mon, 5 Nov 2012 14:21:42 +0100
Paolo Leoni  wrote:

> Hi,
> I'm a Fedora user and, occasionally, contributor.
> I'm writing to you only to expose a simple proposal on Fedora future.
> 
> We are debating on how Fedora Development cycle could be improved,
> and, at the same time, how to maintain its "bleeding edge" way.
> 
> So, this is my proposal:
> 
> We could introduce a periodically different Fedora development cycle,
> with major and minor release numbers.
> When we want release a new major version, we have a development cycle
> pretty longer, e.g. one year.
> For the minor release we have the old development cycle: 6 months.

The problem with this is that it's complex to communicate and our users
might not have clear expectations, IMHO. 

> The minor release that come before the major release could have a life
> cycle with a lenght of 18 months, to compensate the longer devel
> cycle of the next major release.

We could also be managing too many (more than we do now) branches. 

> The time to begin development of a major released could be discussed
> and decided by FESCo.

Sure, problem is that open source projects are pretty horrible about
planning. Ask most any open source project you are involved with: 

"Hey, whats your roadmap for the next 2 years?" and you will probibly
get "Oh, our next release in a month has foo and our release after that
(due out in 7 months or so) has bar planned"

It's just really hard in a fast moving industry to plan years ahead
easily. new things come up and you adjust for them all the time. ;) 

For that reason I think it might be difficult for Fedora to commit
upfront to a longer cycle/planning. 

kevin


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

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Kamil Paral]

> >* A release for general users with low volume of security fixes and
> >important bug fixes.
> >** Bug fixes would be pushed monthly and QA would be performed on
> >this monthly batch of updates.
>
> Some packages need more than bug fix updates (unless you are taking a
> very
> broad view of what a bug is). We haven't done a very good job of
> having
> a consistent interpretation with the current update policy. Giving
> the
> proposal below, this will be a more important issue than it is now.

You are right, some types of packages would deserve more frequent updates even 
if they are not just bugfixes. Typically end-user applications like Firefox or 
LibreOffice, if there is no major UI/functionality change. Fedora Stable is 
intended for conservative users, but it's still Fedora, so reasonable minor 
changes would be fine.

>
> >* Released every 18 months, supported for 18+2 months (2 months to
> >give people time to upgrade to the next Fedora Stable).
> >** Why 18 months? Because for general users it is annoying to
> >upgrade every year, but OTOH our package maintainers wouldn't
> >probably like supporting 2-year-old packages. 18 months is still an
> >increase from current 12 months of support, but if we stop
> >releasing two parallel stable releases, we can make the support
> >longer with the same energy spent.
>
> We are going to take a marketing hit doing this.

Probably yes.

But, to tell the truth, we're getting a lot of marketing by postpoing F18 as 
well. There might be a lot of other ways to do marketing.

>
> >** Just one stable release instead of two. Can anyone tell me a
> >compelling argument for having two stable releases (F16, F17) in
> >parallel? I don't see any. The current model probably evolved
> >because we wanted new software fast, but upgrading every 6 months
> >would discourage a lot of users. Let's be honest - yes, it will
> >contain old packages and yes, it is intended for conservative
> >users. For the other group we will have Fedora Rolling.
>
> We provide extra flexibility in letting users decide when they want
> to do
> upgrades to stay in support. It's not only letting them use a release
> for
> about a year if they want, but also to do the upgrade at a time where
> they
> can conveniently deal with any issues.

That's a good argument. Currently they have 7 months to do the upgrade. With my 
proposal, they have 2 months. Unless they want to run a system without security 
patches for some time. So maybe we could extend the time we provide security 
patches?

>
> >* More reliable upgrades, although less convenient for power users.
> >Instead of current way of often-broken system upgrades, our upgrade
> >tool would install a clean system, remount /home, and try to
> >install all GUI applications that the user had manually installed
> >in his previous system.
>
> This seems to be independent of the proposal to have only one stable
> release.

Right.

> This tool is still not going to be able to do magic and there will be
> config
> things that still need to be redone. Third party repos will still be
> an issue.

It's a clean installation, I don't think it needs any magic. Also third-party 
repos are not a problem, we just ignore them and they won't influence the new 
system. People will add them manually again once in 18 months.

> >** This process would also allow Anaconda devs to continuously work
> >on the installer and update it continuously with core system
> >changes. Currently they can't work on Rawhide because "Rawhide is
> >just broken". Fedora Rolling would allow them that.
>
> I don't think that is the issue. They work in branched because they
> don't
> have the man power to also be working in rawhide at the same time and
> since
> anaconda is sensitive to the version of other packages, they want to
> be
> developing against what's going to be in the next release.
>

Yes, but this would reduce the surprise moment when Fedora is being Branched 
and Anaconda team discovers that 1337 things changed in Rawhide since the last 
stable release.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[Nicolas Mailhot]

Le Lun 5 novembre 2012 18:55, Till Maas a écrit :

> Rawhide is not intended to be used for anything important and with any
> security sensitive data because the used packages are not signed.

Alas

> Whenever I asked to get Rawhide packages signed I was also told that it
> is, because of Rawhide's use case. Everybody using Rawhide for example
> to maintainer Fedora packages is endangering the Fedora project.

And everyone not using Rawhide to maintain Fedora packages is contributing
to the regular release slips and to the lack of stability of Fedora
releases (because QA time is eaten up by development that is supposed to
have started in Rawhide).

Signing rawhide would be cheap compared to the costs induced by the
current situation.

-- 
Nicolas Mailhot

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

Re: F-18 Branched report: 20121031 changes

[Tom Callaway]

On 11/05/2012 09:21 AM, Paul Howarth wrote:
> On 10/31/2012 07:53 PM, Tom Callaway wrote:
>>> [perl-Hardware-Verilog-Parser]
>>> perl-Hardware-Verilog-Parser-0.13-9.fc17.noarch requires
>>> perl(:MODULE_COMPAT_5.14.2)
>>
>> Really broken. Does not build with current perl. I suggest that it be
>> buried in a hole and covered up with a fire (or, if someone loves
>> Parse::RecDescent, they can try to fix it).
> 
> I took a look at it and managed to spot the typos causing the problems.
> 
> https://admin.fedoraproject.org/updates/perl-Hardware-Verilog-Parser-0.13-12.fc18

My hat is off to you, sir. :)

~tom

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

Re: Rawhide

[Till Maas]

On Sat, Nov 03, 2012 at 06:32:20PM -0600, Kevin Fenzi wrote:
> So, I have been thinking about rawhide. 
> 
> I agree identifying the problems/issues would be good, and I think
> there's something we can do to help with that: 
> 
> Get a nice group of at least 10 or so folks who are active on this list
> to agree to run it full time on their main machine. 

Rawhide is not intended to be used for anything important and with any
security sensitive data because the used packages are not signed.
Whenever I asked to get Rawhide packages signed I was also told that it
is, because of Rawhide's use case. Everybody using Rawhide for example
to maintainer Fedora packages is endangering the Fedora project.

Nevertheless, I still believe it would be better if Fedora started to
provide signed packages directly from Koji including Rawhide to end this
problem. But looking at the current fedup code it seems that Fedora is
going to be the first distribution that abandons package security more
and more instead of trying to improve it. As far as I know starting with
preupgrade doing insecure updates were promoted and now they are going
to be made mandatory (except for the unsupported yum update method).

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

[perl-Sys-MemInfo/el5: 6/6] Merge branch 'master' into el5

[Orion Poplawski]

commit 51b209efc779419a8b623accf1b28d8dc86369c9
Merge: 7b2c0b9 ff7a981
Author: Orion Poplawski 
Date:   Mon Nov 5 10:46:25 2012 -0700

Merge branch 'master' into el5

 .rpmlint  |2 ++
 perl-Sys-MemInfo.spec |   29 +
 2 files changed, 23 insertions(+), 8 deletions(-)
---
diff --cc perl-Sys-MemInfo.spec
index 18c01a2,b570440..d6de3d6
--- a/perl-Sys-MemInfo.spec
+++ b/perl-Sys-MemInfo.spec
@@@ -6,8 -9,12 +9,13 @@@ License:(GPLv1+ or Artistic) an
  Group:  Development/Libraries
  URL:http://search.cpan.org/dist/Sys-MemInfo/
  Source0:
http://www.cpan.org/modules/by-module/Sys/Sys-MemInfo-%{version}.tar.gz
 +BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
  BuildRequires:  perl(ExtUtils::MakeMaker)
+ BuildRequires:  perl(File::Copy)
+ # Run-time:
+ BuildRequires:  perl(DynaLoader)
+ BuildRequires:  perl(Exporter)
+ # Tests:
  BuildRequires:  perl(Test::More)
  BuildRequires:  perl(Data::Dumper)
  Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Sys-MemInfo/el5] (6 commits) ...Merge branch 'master' into el5

[Orion Poplawski]

Summary of changes:

  7461b80... Improve description (*)
  102f01c... Specify all dependencies (*)
  5d392a2... Modernize spec file (*)
  ca549ff... Teach rpmlint (*)
  ff7a981... Change license (*)
  51b209e... Merge branch 'master' into el5

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Sys-MemInfo/el6] (5 commits) ...Change license

[Orion Poplawski]

Summary of changes:

  7461b80... Improve description (*)
  102f01c... Specify all dependencies (*)
  5d392a2... Modernize spec file (*)
  ca549ff... Teach rpmlint (*)
  ff7a981... Change license (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Przemek Klosowski]

On 11/02/2012 07:04 PM, Adam Williamson wrote:


Sure, like I said in another mail, we've got better at that than before.
But as I also said in the same mail, you still have to do a version
upgrade every twelve months. That alone is ridiculous for a 'stable'
operating system.



This is an important point---it makes it difficult to deploy Fedora for 
other people. When the end-of-support comes, it usually means having to 
reinstall, because upgrade can take unbounded time, if problems pop up. 
Additionally, in my experience, a reinstall often results in a better 
configuration, free of grandfathered suboptimal settings.


I keep thinking about a scheme to roll over an EOL Fedora into a closest 
possible CENTOS. It's not trivial because I can't just look for the 
CENTOS that matches the original Fedora release, because of the 
subsequent updates. It would have to look at the as-is system and try to 
figure out the best matching CENTOS release. I am thinking about a 
sum-of-squared-differences-like distance metric: calculate sum over all 
packages of (installed_version - CENTOS_X_version)^2, for several 
CENTOS_X versions, and chose the one giving the smallest value. Of 
course some packages (glibc, kernel) would have a higher weight, but 
that could be incorporated (\sum_i((v1_i-v2_i)^2/wght_i)).

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

Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Miloslav Trmač]

On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller  wrote:
> On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote:
>> > That sounds good. Maybe recast those ideas as three levels?
>> >  - Critical Path Feature
>> >  - Other Enhancement Feature
>> >  - New Leaf Feature
>> We were thinking with a few folks more about "Self contained feature"
>> but yeah, there's a lack of real definition.
>
> I think "Leaf" is better than "Self contained", since it's unlikely for the
> feature to have zero outside dependencies. I think it'd be fine for such a
> feature to rely on small changes to existing packages (version updates,
> say).

"Self-contained" in the proposal is intentionally more broad than
"leaf".  For example, it allows a small SIG for a less-used language
that does not affect the rest of the distribution to agree to do a
major version upgrade and to coordinate among the SIG members (as they
would coordinate in any case), without FESCo playing an useless
middle-man.

(The suggested definition of "self-contained" is something like
"maintainers of all affected packages sign up to participate on the
work for the feature".)
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Miloslav Trmač]

On Thu, Nov 1, 2012 at 7:10 PM, "Jóhann B. Guðmundsson"
 wrote:
> On 11/01/2012 06:09 PM, Jaroslav Reznik wrote:
>> We were thinking with a few folks more about "Self contained feature"
>> but yeah, there's a lack of real definition.
>>
>> Other thing is - these "Self contained features" could be approved
>> implicitly once are announced on devel list (in cooperation with
>> Feature Wrangler). Features that requires integration etc. will be
>> still approved by FESCo, but idea is to offload amount of work from
>> FESCo so they can give more time to track these features. Not to
>> bother with leaf features or enhancements. And as these should be
>> very visible (thanks to announcement) anybody could escalate any
>> feature to the FESCo for discussion/explicit approval.
>>
>> That's the idea, I promised my proposal delivered to FESCo before
>> Beta;-)  But you know, moving target
>>
>> Any suggestions are welcomed!
>
> Blindly accepting features are unacceptable from QA stand point and arguably
> minor release updates should be kept out of the feature process

An important part of this proposal is to make the mailing list
announcement and time for discussion mandatory; that would actually
significantly increase the visibility of many features.  Also, the
feature would not be accepted "automatically", only "by default" -
anyone, including QA, could move the feature into the "full" process.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-AppConfig] Specify all dependencies. Use DESTDIR rather than PERL_INSTALL_ROOT.

[Marcela Mašláňová]

commit 63d3373030b7bdad93fce9a3b7ca0104bd29e68e
Author: Marcela Mašláňová 
Date:   Mon Nov 5 17:36:44 2012 +0100

Specify all dependencies. Use DESTDIR rather than PERL_INSTALL_ROOT.

Signed-off-by: Marcela Mašláňová 

 perl-AppConfig.spec |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)
---
diff --git a/perl-AppConfig.spec b/perl-AppConfig.spec
index ed933c3..d3f10c1 100644
--- a/perl-AppConfig.spec
+++ b/perl-AppConfig.spec
@@ -1,6 +1,6 @@
 Name:   perl-AppConfig
 Version:1.66
-Release:17%{?dist}
+Release:18%{?dist}
 Summary:Perl module for reading configuration files
 
 Group:  Development/Libraries
@@ -10,7 +10,12 @@ Source0:
http://search.cpan.org/CPAN/authors/id/A/AB/ABW/AppConfig-%{vers
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 BuildArch:  noarch
-BuildRequires:  perl(File::HomeDir) >= 0.61
+BuildRequires:  perl(base)
+BuildRequires:  perl(Exporter)
+BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(Getopt::Long) >= 2.17
+BuildRequires:  perl(lib)
+BuildRequires:  perl(Test::More)
 BuildRequires:  perl(Test::Pod)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 
@@ -44,7 +49,7 @@ make %{?_smp_mflags}
 
 %install
 rm -rf $RPM_BUILD_ROOT
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
 find $RPM_BUILD_ROOT -depth -type d -empty -exec rmdir {} ';'
 chmod -R u+w $RPM_BUILD_ROOT/*
@@ -66,6 +71,10 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Mon Nov 05 2012 Jitka Plesnikova  - 1.66-18
+- Specify all dependencies
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+
 * Fri Jul 20 2012 Fedora Release Engineering  
- 1.66-17
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Rawhide

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

For the most part I always run Rawhide.  Except for a few weeks after branch.
 I like to find the SELinux issues early...


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCX6x4ACgkQrlYvE4MpobMk+wCgmPTaltWIIXgo3Roi/SHzBbRc
2i0AmwUCK1Ts3Q0AIX3ESr4gqPlvuyRn
=TFKv
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[M. Edward (Ed) Borasky]

On Sat, Nov 3, 2012 at 5:32 PM, Kevin Fenzi  wrote:
> So, I have been thinking about rawhide.
>
> I agree identifying the problems/issues would be good, and I think
> there's something we can do to help with that:
>
> Get a nice group of at least 10 or so folks who are active on this list
> to agree to run it full time on their main machine.
>
> As we get close to F18 release, I am considering moving my full time
> laptop to rawhide. If I can get a group of folks to do likewise we can
> at least identify issues faster and help each other as they come up.
>
> Additionally, if some number of these folks who pledge to run rawhide
> full time were provenpackagers we could just go in and fix things as
> they hit (or soon after) instead of waiting a while for fixes to go
> out.
>
> I've run a rawhide vm/test machine here for many years. It's hit it's
> share of problems, but none were insurmountable. Some of them might
> have been for folks who were not more experienced tho, so increasing
> communication around rawhide can only help, IMHO.
>
> Additional thoughts to help rawhide:
>
> - It's been suggested before, but could we practically keep N and N-1
>   packages in rawhide repos? Then 'yum downgrade' becomes much more
>   handy. Repodata size and mirror size might shoot that down though.
>
> - Autoqa could perhaps help out, but I am not holding my breath. ;)
>
> - Anaconda folks haven't wanted rawhide installer images as they cause
>   people to report bugs on things when not ready, etc. However, could
>   we build nightly cloud images at least? Those could help test things
>   and won't require hitting the installer path.
>
> - I'm sure there's more ideas to improve it...
>
> I really think if we get a pool of savvy folks running it day to day we
> should at least be able to identify the pain points. In my experience
> with my test machine, rawhide has been pretty boring for the last two
> cycles, if we can continue to make it so, perhaps the rolling release
> folks might be able to find it usable.
>
> kevin
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

I have two machines - an ancient workstation (Athlon64 X2 with 4 GB of
RAM) and a one-year-old laptop. I would certainly consider running
Rawhide on the workstation but no way am I running it on the laptop as
my *primary* partition.

That said, I am running F18 beta TC7 on both the workstation and the
laptop as my main distro now and everything seems to be fine. The
workstation still has a Beefy Miracle partition but I haven't used it
in over a week and I'll most likely blow it away. Perhaps I can put
Rawhide on it if it will help the efforts for F18.



-- 
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: 
http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/

How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[Nicolas Mailhot]

Le Lun 5 novembre 2012 12:12, Jaroslav Reznik a écrit :
> - Original Message -
>>
>> Le Lun 5 novembre 2012 10:45, Dodji Seketeli a écrit :

>> Someone wrote in this thread that Gnome updates were painful in
>> branched.
>> Well they are horrific in Rawhide. If there was some effort to make
>> them
>> only painful in Rawhide they would not be horrific in branched. (this
>> is
>> called a 'virtuous circle').
>>
>> IMHO it was a huge mistake to synchronise Fedora releases with GNOME
>> releases instead of synchronising Fedora branch times with GNOME
>> release
>> times. That's idiotic and means there is no time Fedora-side to do
>> any QA
>> and fixing before pushing a new GNOME release to users.
>
> I think there's some sync between GNOME and Fedora releases - I already
> proposed F19 schedule - 3.7.90 is a week before branching, and before
> Alpha, 3.8.0 release precedes Features 100% complete and thus it goes
> to Beta. Or are you talking about having final even before branching?
> The current process allows us to influence (in some extend) development
> of GNOME based on Alpha release etc. And yeah, it's probably not enough.

You proposal may work *if* GNOME people take care to respect it. Otherwise
— yes the nuclear option is to only distribute GNOME releases that were
ready at branch time and could be stabilised during all the Fedora test
releases. It may seem excessive but the current
it-says-it-is-stable-push-it-to-users-without-testing policy has not been
good for both of the projects I think.

-- 
Nicolas Mailhot

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

[perl-Text-CSV_XS] Modernize spec file

[Petr Pisar]

commit 38557497ba8b68b2e0c515d8409d2ab7fa222cb7
Author: Petr Písař 
Date:   Mon Nov 5 15:36:46 2012 +0100

Modernize spec file

 perl-Text-CSV_XS.spec |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
---
diff --git a/perl-Text-CSV_XS.spec b/perl-Text-CSV_XS.spec
index 7205219..d3bc9cf 100644
--- a/perl-Text-CSV_XS.spec
+++ b/perl-Text-CSV_XS.spec
@@ -47,7 +47,6 @@ make %{?_smp_mflags}
 make pure_install DESTDIR=%{buildroot}
 find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
 find %{buildroot} -type f -name '*.bs' -empty -exec rm -f {} ';'
-find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null ';'
 chmod -R u+w %{buildroot}/*
 
 %check
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Text-CSV_XS] Correct dependencies

[Petr Pisar]

commit cf2671f51e4283d7fc2f0608c3863315575d0d90
Author: Petr Písař 
Date:   Mon Nov 5 15:36:25 2012 +0100

Correct dependencies

 perl-Text-CSV_XS.spec |   19 +--
 1 files changed, 13 insertions(+), 6 deletions(-)
---
diff --git a/perl-Text-CSV_XS.spec b/perl-Text-CSV_XS.spec
index 2bcb2aa..7205219 100644
--- a/perl-Text-CSV_XS.spec
+++ b/perl-Text-CSV_XS.spec
@@ -1,22 +1,26 @@
 Name:   perl-Text-CSV_XS
 Version:0.91
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Comma-separated values manipulation routines
 Group:  Development/Libraries
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Text-CSV_XS/
 Source0:
http://www.cpan.org/authors/id/H/HM/HMBRAND/Text-CSV_XS-%{version}.tgz
-BuildRequires:  perl(base)
+BuildRequires:  perl(ExtUtils::MakeMaker)
+# Run-time:
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(DynaLoader)
-BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(IO::Handle)
-BuildRequires:  perl(Test::Harness)
+# Tests:
+BuildRequires:  perl(base)
 BuildRequires:  perl(Test::More)
-BuildRequires:  perl(Test::Pod)
-BuildRequires:  perl(Test::Pod::Coverage)
 BuildRequires:  perl(Tie::Scalar)
+# Optional tests:
+BuildRequires:  perl(Test::Pod) >= 1.00
+BuildRequires:  perl(Test::Pod::Coverage)
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+# IO::Handle is loaded by XS code
+Requires:   perl(IO::Handle)
 
 %{?perl_default_filter}
 
@@ -57,6 +61,9 @@ make test
 %{_mandir}/man3/*.3pm*
 
 %changelog
+* Mon Nov 05 2012 Petr Pisar  - 0.91-2
+- Correct dependencies
+
 * Wed Aug 22 2012 Petr Šabata  - 0.91-1
 - 0.91 bump (mostly test-cases updates)
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Martin Sivak]

Hi,

> If/when the "real work" behind a feature has been done early enough,
> getting from Fedora alpha to final consists of just a few bugfixes

Ah well.. only if everybody else did this so all the dependencies are stable.
In which case you just moved the development freeze to earlier date. No 
improvement..

> > Basically there should not be any "this cannot be reverted" (there
> > is
> > no such thing really) features. If it is evident before the feature
> > freeze that a given feature would not be ready in time we have to
> > punt
> > it to the next release PERIOD.

Then there will be no possibility of major rewrites ever. Because some
changes just take more than few months to execute and supporting a branch
with very old (anaconda's GUI first commit in git is from 1999) codebase
takes a lot of manpower.

And to use drago's words: We do not have unlimited resources.

When Gnome decides they are not fixing bugs for Gnome2 and put all resources
to fixing Gnome3, you can wait, because most apps still depend on the mostly 
stable
Gnome2 anyway and the bugs are not show stoppers, merely annoyances.

When we do this in anaconda, you can't just use the older release, because
other components are changing underneath us and the old release will break.

So you will write bugs and RFEs for us to fix in the old branch so you meet your
release deadline and mostly nobody will be testing the new branch.
One release later at the alpha time.. we will get into the same issue of not 
being ready.

We will take the heat whatever model we choose.

So we have chosen. When this is done, we will have UI which has sane
API and is separated from the other internal components and that will allow
us to maintain the installer and firstboot in much better and easier way.

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

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Nikos Roussos]

Tom Lane  wrote:
>Simon Lukasik  writes:
>> Currently, each Fedora release is kept alive for 13(+/-) months.
>There
>> were dozens of threads about shortening or prolonging period -- but I
>am
>> not sure if something like the following has been ever discussed:
>
>> Each N-th Fedora release -- where N%3==1 -- is alive for 7 months.
>> Each N-th Fedora release -- where N%3==2 -- is alive for 7 months.
>> Each N-th Fedora release -- where N%3==0 -- is alive for 19 months.
>
>> Additionally, maintainers might be encouraged to push their system
>wide
>> changes into N%3==1. As well as they might be encouraged to make the
>> Fedora N%3==0 their best bread.
>
>Wouldn't that just encourage 99% of average users to ignore the
>short-lived releases?  It would sure be a damn tempting approach for
>me.
>(Personally, all I want out of Fedora is a stable platform to get my
>work done on, and the less often I have to reinstall, the better.)

99% is an overestimation. Personally I would prefer to update every 6 months 
just to have all the latest stuff, but if I support an organization with many 
Fedora installations I would choose the  N%3==0 release, which would provide me 
only security updates after 7 months.

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

Re: Rawhide

[Matthew Miller]

On Mon, Nov 05, 2012 at 07:27:06AM -0700, Kevin Fenzi wrote:
> I thought about that, but I don't think another list is something do so
> lightly. How about rawhide folks add a [rawhide] to their email
> subjects here to make them easy to filter out/see. 
> I'd personally love to see more signal here in this list. 

If anything, *this* should be the rawhide list. Maybe the more useful thing
would be for there to be a separate list for long naval-gazing(*) threads
about Fedora processes, strategy, and future?



* not that there's anything wrong with that.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposal: changing development cycle

[Mark Bidewell]

I like this idea, it would also allow the introduction of things like newer
versions of Libreoffice, KDE, GNOME faster than potentially breaking
changes.


On Mon, Nov 5, 2012 at 8:27 AM, Paolo Leoni  wrote:

> You can find the same proposal scheme using this link (in order to avoid
> mail formatting issues):
> http://www.paololeoni.eu/fedora_proposal.jpg
>
> bye,
> Paolo
>
>
> 2012/11/5 Paolo Leoni 
>
>> Hi,
>> I'm a Fedora user and, occasionally, contributor.
>> I'm writing to you only to expose a simple proposal on Fedora future.
>>
>> We are debating on how Fedora Development cycle could be improved, and,
>> at the same time, how to maintain its "bleeding edge" way.
>>
>> So, this is my proposal:
>>
>> We could introduce a periodically different Fedora development cycle,
>> with major and minor release numbers.
>> When we want release a new major version, we have a development cycle
>> pretty longer, e.g. one year.
>> For the minor release we have the old development cycle: 6 months.
>>
>> The minor release that come before the major release could have a life
>> cycle with a lenght of 18 months, to compensate the longer devel cycle of
>> the next major release.
>>
>> The time to begin development of a major released could be discussed and
>> decided by FESCo.
>>
>>
>> This is a simple graphical concept of the proposal:
>>
>>
>> || = 6 months of distribution development
>>
>> || = 6 months of distribution stable life
>>
>>
>> Fedora 17.8
>>
>> ||--|--|
>>
>> Fedora 17.9
>>
>>
>> |~|--|--|--|
>>
>> Fedora 18.0 (e.g.: introducing new anaconda...)
>>
>>
>> |~|~|--|--|
>>
>> Fedora 18.1
>>
>>
>> |~|--|--|
>>
>> Fedora 18.2
>>
>>
>> |~|--|--|
>>
>> ..
>>
>>
>> How do you think?
>>
>> Regards,
>> Paolo Leoni ~ www.paololeoni.eu
>>
>>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



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

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Ben Cotton]

On Mon, Nov 5, 2012 at 5:56 AM, Jiri Eischmann  wrote:
>
> Release parties and codenames were just examples. It's about the buzz
> around releases. You can check Google Trends where you find peaks in
> number of searches for Fedora after every release. Or fp.org monthly
> stats. You would lose reviews, that are usually published after
> releases, because I don't see any reviews of rolling release
> distributions by main magazines. Etc.
>
Documentation is another concern. It's hard to maintain static guides
with a rolling release. The Arch Wiki is a great resource to be sure,
but it's ever-changing and not easy to find old information if you're
not running with current. The guides that the Fedora Docs group
produce are a great resource for the community, and it would be a
major strain on our resources to keep up with rolling releases.

My personal opinion is that a rolling release might be nice (not nice
enough, apparently to use Rawhide, but that's more about laziness than
anything), but I'm not convinced it's what's best for the community at
large.

--
Ben Cotton
Fedora Docs Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: MPI updates

[Jon Ciesla]

On Fri, Nov 2, 2012 at 6:10 PM, Orion Poplawski  wrote:

> On 11/01/2012 04:21 PM, Jussi Lehtola wrote:
>
>> On Thu, 01 Nov 2012 09:08:36 -0600
>> Orion Poplawski  wrote:
>>
>>> Some MPI updates:
>>>
>>> - I built openmpi 1.6.3 in rawhide yesterday.  This had an unexpected
>>> bump in the libmpi_f90.so soname.  I know this affects hdf5 and
>>> netcdf-fortran, both my packages and I'll be rebuilding them later
>>> today (hopefully).
>>>
>>
>> Given that f18 has 1.6, I believe the same update should be made on f18
>> as well.
>>
>>
> Sounds good. I'm holding off for now though because the soname bump in
> libmpi_f90.so may have been a mistake.  Waiting for word from upstream.
>

It's a bit late for a soname change in f18 if it's not a mistake. . .

-J


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




-- 
http://cecinestpasunefromage.wordpress.com/

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

[Kevin Fenzi]

On Mon, 05 Nov 2012 10:45:00 +0100
Dodji Seketeli  wrote:

...snip...

> Could we have a rawhide-list for this?  I know fighting proliferation
> of mailing list is a good thing, but practically speaking, being able
> to quickly scan a mailing list before doing a yum update can help a
> Rawhider evaluate in advance the odds of his risking to be unable to
> reboot his machine or not.  :-)

I thought about that, but I don't think another list is something do so
lightly. How about rawhide folks add a [rawhide] to their email
subjects here to make them easy to filter out/see. 

I'd personally love to see more signal here in this list. 

kevin


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

Re: Rawhide

[Michael scherer]

On Mon, Nov 05, 2012 at 10:45:00AM +0100, Dodji Seketeli wrote:
> Kevin Fenzi  a écrit:
 
> > Additionally, if some number of these folks who pledge to run rawhide
> > full time were provenpackagers we could just go in and fix things as
> > they hit (or soon after) instead of waiting a while for fixes to go
> > out. 
> 
> [+1] + vigorous nodding.

Having proven packagers using more their powers seems a good idea in the long 
run.
( work for the perl-sig, worked for years for Mandriva, and I think if there is 
issues, this
could be deal on a case per case basis  )

>   - I'd add, having a way for some provenpackagers of the Rawhide Swat
>   Team to temporarily blacklist a (set of) package, if it appears to
>   significantly break something; so that people doing yum update on
>   Rawhide won't brick their system because of well know issue waiting to
>   be solved.

Technically, that could be done by reusing bodhi and enough person to give -1 
karma.

Another solution could be a yum plugin that will get the blacklist from the 
wiki or 
somewhere, or that would pull it from fedora-people whatever.

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

Re: F-18 Branched report: 20121031 changes

[Paul Howarth]

On 10/31/2012 07:53 PM, Tom Callaway wrote:

[perl-Hardware-Verilog-Parser]
perl-Hardware-Verilog-Parser-0.13-9.fc17.noarch requires 
perl(:MODULE_COMPAT_5.14.2)


Really broken. Does not build with current perl. I suggest that it be
buried in a hole and covered up with a fire (or, if someone loves
Parse::RecDescent, they can try to fix it).


I took a look at it and managed to spot the typos causing the problems.

https://admin.fedoraproject.org/updates/perl-Hardware-Verilog-Parser-0.13-12.fc18

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

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Bruno Wolff III]

On Mon, Nov 05, 2012 at 08:35:53 -0500,
  Kamil Paral  wrote:

My idea would be to have two releases:

== Fedora Stable ==

* A release for general users with low volume of security fixes and important 
bug fixes.
** Bug fixes would be pushed monthly and QA would be performed on this monthly 
batch of updates.


Some packages need more than bug fix updates (unless you are taking a very 
broad view of what a bug is). We haven't done a very good job of having 
a consistent interpretation with the current update policy. Giving the 
proposal below, this will be a more important issue than it is now.



* Released every 18 months, supported for 18+2 months (2 months to give people 
time to upgrade to the next Fedora Stable).
** Why 18 months? Because for general users it is annoying to upgrade every 
year, but OTOH our package maintainers wouldn't probably like supporting 
2-year-old packages. 18 months is still an increase from current 12 months of 
support, but if we stop releasing two parallel stable releases, we can make the 
support longer with the same energy spent.


We are going to take a marketing hit doing this.


** Just one stable release instead of two. Can anyone tell me a compelling 
argument for having two stable releases (F16, F17) in parallel? I don't see 
any. The current model probably evolved because we wanted new software fast, 
but upgrading every 6 months would discourage a lot of users. Let's be honest - 
yes, it will contain old packages and yes, it is intended for conservative 
users. For the other group we will have Fedora Rolling.


We provide extra flexibility in letting users decide when they want to do 
upgrades to stay in support. It's not only letting them use a release for 
about a year if they want, but also to do the upgrade at a time where they 
can conveniently deal with any issues.



* More reliable upgrades, although less convenient for power users. Instead of 
current way of often-broken system upgrades, our upgrade tool would install a 
clean system, remount /home, and try to install all GUI applications that the 
user had manually installed in his previous system.


This seems to be independent of the proposal to have only one stable release. 
This tool is still not going to be able to do magic and there will be config 
things that still need to be redone. Third party repos will still be an issue.



** General user wouldn't see a difference, but we could achieve much higher 
upgrade success rate.


Maybe.


** This process would also allow Anaconda devs to continuously work on the installer and 
update it continuously with core system changes. Currently they can't work on Rawhide 
because "Rawhide is just broken". Fedora Rolling would allow them that.


I don't think that is the issue. They work in branched because they don't 
have the man power to also be working in rawhide at the same time and since 
anaconda is sensitive to the version of other packages, they want to be 
developing against what's going to be in the next release.

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

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Simo Sorce]

On Sun, 2012-11-04 at 19:47 +0200, Alek Paunov wrote:
> On 04.11.2012 19:25, Simo Sorce wrote:
> 
> > note that this is "also" our strength in some respect because it allows
> > the system to evolve a lot more quickly, but it also means upgrades are
> 
> Indeed.
> 
> > simply going to break stuff, and that's not so great for desktop
> > environments and scare the hell off of 3rd party vendors.
> > You may notice we do not have many 3rd party vendors, I think ABI
> > instability is reason number, 1, 2 and 3 of why we can't have reliable
> > third parties with a community built OS.
> >
> 
> I agree completely with all your points.
> 
> A possibly viable alternative for the ABIs freezing (which we can not 
> ensure anyway) is the C/C++/etc tooling - If we arm upstreams, packagers 
> and 3rd parties with powerful source tools (API migration/checking), 
> just like Google does internally, unsing the  Clang tooling, witch was 
> developed exactly for this purpose.
> 
> The GCC/OpenJDK tooling development is not something appropriate as 
> effort for the manpower of almost any upstream, but IMHO should be seen 
> as important goal for relatively big player like Fedora.

Unfortunately it won't work, unless you are ready to also go and mark
reliable and unreliable upstreams, which is ... difficult.

The reason I say so is that I know for sure not all upstreams are
willing to maintain ABI compatibility. There are various degrees but
some go for absolute ABI compatibility at all costs (glibc) to "I'll
break the ABI on purpose (or because I don't care) at every upgrade
(won't try to name names).

Simo.

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

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

rawhide report: 20121105 changes

[Fedora Rawhide Report]

Compose started at Mon Nov  5 08:15:12 UTC 2012

Broken deps for x86_64
--
[LabPlot]
LabPlot-1.6.0.2-12.fc18.i686 requires libaudiofile.so.0
LabPlot-1.6.0.2-12.fc18.x86_64 requires libaudiofile.so.0()(64bit)
[PyKDE]
PyKDE-3.16.6-10.fc18.x86_64 requires sip-api(8) >= 0:8.1
[PyQt]
PyQt-3.18.1-12.fc18.x86_64 requires sip-api(8) >= 0:8.1
[alienarena]
alienarena-server-7.60.1-3.fc19.x86_64 requires alienarena-data = 
0:7.60.1
[autotest-framework]
autotest-framework-server-0.14.3-1.fc17.noarch requires mod_python
[blacs]
blacs-mpich2-1.1-46.fc18.i686 requires libmpich.so.3
blacs-mpich2-1.1-46.fc18.x86_64 requires libmpich.so.3()(64bit)
[cduce]
cduce-0.5.5-2.fc18.x86_64 requires ocaml(runtime) = 0:4.00.0
cduce-0.5.5-2.fc18.x86_64 requires ocaml(Pcre) = 
0:fedf84da3d313aea51e03bb7d7c99a3b
[coccinelle]
coccinelle-1.0.0-0.rc14.5.fc18.x86_64 requires ocaml(runtime) = 0:4.00.0
coccinelle-1.0.0-0.rc14.5.fc18.x86_64 requires ocaml(Pcre) = 
0:fedf84da3d313aea51e03bb7d7c99a3b
[cp2k]
cp2k-mpich2-2.3-1.fc19.x86_64 requires libmpichf90.so.3()(64bit)
cp2k-mpich2-2.3-1.fc19.x86_64 requires libmpich.so.3()(64bit)
cp2k-openmpi-2.3-1.fc19.x86_64 requires libmpi_f90.so.1()(64bit)
[digikam]
kipi-plugins-3.0.0-0.5.beta2.fc19.x86_64 requires 
libopencv_nonfree.so.2.4()(64bit)
kipi-plugins-3.0.0-0.5.beta2.fc19.x86_64 requires 
libopencv_gpu.so.2.4()(64bit)
libkface-3.0.0-0.5.beta2.fc19.i686 requires libopencv_nonfree.so.2.4
libkface-3.0.0-0.5.beta2.fc19.i686 requires libopencv_gpu.so.2.4
libkface-3.0.0-0.5.beta2.fc19.x86_64 requires 
libopencv_nonfree.so.2.4()(64bit)
libkface-3.0.0-0.5.beta2.fc19.x86_64 requires 
libopencv_gpu.so.2.4()(64bit)
[dnf]
dnf-0.2.14-2.git4831982.fc18.noarch requires python-hawkey >= 0:0.3.0
[dogtag-pki]
dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-selinux >= 0:10.0.0
[dustmite]
dustmite-1-5.20120304gitcde46e0.fc17.x86_64 requires 
libphobos-ldc.so.59()(64bit)
[e16]
e16-1.0.10-3.fc18.x86_64 requires libaudiofile.so.0()(64bit)
[esound]
1:esound-libs-0.2.41-6.fc18.i686 requires libaudiofile.so.0
1:esound-libs-0.2.41-6.fc18.x86_64 requires libaudiofile.so.0()(64bit)
1:esound-tools-0.2.41-6.fc18.x86_64 requires libaudiofile.so.0()(64bit)
[espresso]
espresso-mpich2-3.0.2-4.fc18.x86_64 requires libmpich.so.3()(64bit)
[frei0r-plugins]
frei0r-plugins-1.3-7.fc18.x86_64 requires 
libopencv_nonfree.so.2.4()(64bit)
frei0r-plugins-1.3-7.fc18.x86_64 requires libopencv_gpu.so.2.4()(64bit)
[gcstar]
gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::Table)
gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::HBox)
gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::Frame)
gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::EventBox)
[ghc-MemoTrie]
ghc-MemoTrie-0.5-3.fc18.x86_64 requires 
libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit)
[ghc-blaze-builder-conduit]
ghc-blaze-builder-conduit-0.4.0.2-3.fc18.x86_64 requires 
libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit)
[ghc-conduit]
ghc-conduit-0.4.2-3.fc18.x86_64 requires 
libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit)
[ghc-ghc-mtl]
ghc-ghc-mtl-1.0.1.1-2.fc19.x86_64 requires 
ghc(ghc-7.4.1-2e8223f1ab945abe712c4fc4010c270e)
ghc-ghc-mtl-devel-1.0.1.1-2.fc19.x86_64 requires 
ghc-devel(ghc-7.4.1-2e8223f1ab945abe712c4fc4010c270e)
[ghc-hakyll]
ghc-hakyll-3.2.7.2-6.fc18.x86_64 requires 
libHSpandoc-1.9.4.2-ghc7.4.1.so()(64bit)
ghc-hakyll-3.2.7.2-6.fc18.x86_64 requires 
ghc(pandoc-1.9.4.2-a2700c5fb49c2879e0846ae80f139244)
ghc-hakyll-devel-3.2.7.2-6.fc18.x86_64 requires 
ghc-devel(pandoc-1.9.4.2-a2700c5fb49c2879e0846ae80f139244)
[ghc-ltk]
ghc-ltk-0.12.1.0-6.fc19.x86_64 requires 
ghc(ghc-7.4.1-2e8223f1ab945abe712c4fc4010c270e)
ghc-ltk-devel-0.12.1.0-6.fc19.x86_64 requires 
ghc-devel(ghc-7.4.1-2e8223f1ab945abe712c4fc4010c270e)
[ghc-network-conduit]
ghc-network-conduit-0.4.0.1-3.fc18.x86_64 requires 
libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit)
[ghc-snap-core]
ghc-snap-core-0.9.0-4.fc18.x86_64 requires 
libHSunix-compat-0.3.0.1-ghc7.4.1.so()(64bit)
ghc-snap-core-0.9.0-4.fc18.x86_64 requires 
libHSmwc-random-0.12.0.0-ghc7.4.1.so()(64bit)
ghc-snap-core-0.9.0-4.fc18.x86_64 requires 
ghc(unix-compat-0.3.0.1-5c60739e7246890d88ea5d633793062b)
ghc-snap-core-0.9.0-4.fc18.x86_64 requires 
ghc(mwc-random-0.12.0.0-9ca879896db2ffb2250b04f25bb8cb97)
ghc-snap-core-devel-0.9.0-4.fc18.x86_64 requires 
ghc-devel(unix-compat-0.3.0.1-5c60739e7246890d88ea5d633793062b)
ghc-snap-core-devel-0.9.0-4.fc18.x86_64 requires 
ghc-devel(mwc-random-0.12.0.0-9ca879896db2ffb2250b04f25bb8cb97)
[ghc-vector-space]
ghc-vector-space-0.8.2-1.fc18.x86_64 requires 
libHSsemigroups-

[perl-Sys-MemInfo] Change license

[Petr Pisar]

commit ff7a981be79fd7e937d4bccef3bb0c0a5dc19e2c
Author: Petr Písař 
Date:   Mon Nov 5 14:44:34 2012 +0100

Change license

 perl-Sys-MemInfo.spec |   11 +--
 1 files changed, 9 insertions(+), 2 deletions(-)
---
diff --git a/perl-Sys-MemInfo.spec b/perl-Sys-MemInfo.spec
index c302d3b..b570440 100644
--- a/perl-Sys-MemInfo.spec
+++ b/perl-Sys-MemInfo.spec
@@ -1,8 +1,11 @@
 Name:   perl-Sys-MemInfo
 Version:0.91
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:Memory information as Perl module
-License:LGPLv2+
+# README:   GPLv1+ or Artistic
+# MemInfo.pmLGPLv2+
+# 
+License:(GPLv1+ or Artistic) and LGPLv2+
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Sys-MemInfo/
 Source0:
http://www.cpan.org/modules/by-module/Sys/Sys-MemInfo-%{version}.tar.gz
@@ -45,6 +48,10 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Nov 05 2012 Petr Pisar  - 0.91-5
+- Change license from (LGPLv2+) to ((GPLv1+ or Artistic) and LGPLv2+)
+  (CPAN RT #80636)
+
 * Mon Nov 05 2012 Petr Pisar  - 0.91-4
 - Improve description
 - Specify all dependencies
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Kamil Paral]

> The entire QA team (and the entire anaconda team, for that matter) is
> currently spending virtually all its time trying to help bash the new
> anaconda into something vaguely resembling shape for a fairly
> arbitrary
> release deadline, so we can ship something called 'the Fedora 18
> stable
> release' without *completely* corpsing Jimmy Fallon-style as we do
> the
> release announcement ("sre, this is a stable release..." *giggle*
> *giggle* *guffaw* *full-blown laughing fit*). We've barely looked at
> the
> desktop or the update mechanism or anything else. Stuff in Fedora
> regresses all over the place...there all sorts of weirdness in how
> fairly basic bits of our OS work, like updates and login and various
> other crap. We can't really look in a mirror and say that, say,
> Fedora
> 17 is a serious stable operating system release by any reasonable
> definition. It's a stable Fedora release, and we all know what that
> is.
> We had a feature for a smooth boot process back in F12, remember?
> where
> everything was polished and had the same background and you didn't
> see
> any mode transitions? How's that working these days? It was supposed
> to
> be a feature of our operating system. We almost got it done for one
> release, and have been consistently regressing it ever since. That's
> not
> what stable, mature operating systems do.

Adam is telling the inconvenient truth here, and I agree. We really shouldn't 
pretend that Fedora is a "stable OS". Unfortunately none of Linux distributions 
really is (now talking about desktop distributions, not server ones).

But... the fact we're doing a poor job doesn't mean that some "general users" 
are not using Fedora happily. They may the lucky ones (no update breakages) or 
they have a power-user friend who help them from time to time. If we cut them 
off completely, I'm afraid Fedora would become a niche distribution, with just 
a fraction of its previous user base. I think that wouldn't be a good outcome. 
But I agree we need to simplify things and decrease the currently required 
resources (QA, package maintainers, releng, etc) so that the quality can go up.

My idea would be to have two releases:

== Fedora Stable ==

* A release for general users with low volume of security fixes and important 
bug fixes.
** Bug fixes would be pushed monthly and QA would be performed on this monthly 
batch of updates.

* Released every 18 months, supported for 18+2 months (2 months to give people 
time to upgrade to the next Fedora Stable).
** Why 18 months? Because for general users it is annoying to upgrade every 
year, but OTOH our package maintainers wouldn't probably like supporting 
2-year-old packages. 18 months is still an increase from current 12 months of 
support, but if we stop releasing two parallel stable releases, we can make the 
support longer with the same energy spent.
** Just one stable release instead of two. Can anyone tell me a compelling 
argument for having two stable releases (F16, F17) in parallel? I don't see 
any. The current model probably evolved because we wanted new software fast, 
but upgrading every 6 months would discourage a lot of users. Let's be honest - 
yes, it will contain old packages and yes, it is intended for conservative 
users. For the other group we will have Fedora Rolling.

* More reliable upgrades, although less convenient for power users. Instead of 
current way of often-broken system upgrades, our upgrade tool would install a 
clean system, remount /home, and try to install all GUI applications that the 
user had manually installed in his previous system.
** General user wouldn't see a difference, but we could achieve much higher 
upgrade success rate.
** Power users would have to manually transfer /etc changes, add custom repos, 
etc. But if you need to do that only once every 18 months, it's not so bad. 
Also, a lot of power users would use Fedora Rolling instead, so they would not 
be affected at all. Some power users can even do unsupported yum upgrades (as 
many of them do now), so they won't be affected by it either.

* There would probably have to be a stabilization period before new Fedora 
Stable is released. So Branched release would exist for a short time. But it 
would be e.g. 3 months every 18 months, instead of current 3 months every 6 
months. Also, with Fedora Rolling being generally working (as opposed to 
current Rawhide), the period could be much shorter: 1-2 months.

== Fedora Rolling ==

* Rolling release similar to Fedora Branched, but with higher quality 
standards. This would target Linux power users wanting leading-edge software.
** Bodhi karma would be used for issuing updates. Because a lot of people would 
be using Fedora Rolling, the quality would be higher than current Fedora 
Branched (where just a tiny number of people actually run it and report 
problems).

* Big disruptive changes (like usrmove or sysv->systemd) would be allowed to 
happen just in a concrete time slots, e.g. once

Broken dependencies: perl-OpenOffice-UNO

[buildsys]

perl-OpenOffice-UNO has broken dependencies in the rawhide tree:
On x86_64:
perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires 
perl(:MODULE_COMPAT_5.14.2)
On i386:
perl-OpenOffice-UNO-0.07-3.fc17.i686 requires 
perl(:MODULE_COMPAT_5.14.2)
perl-OpenOffice-UNO-0.07-3.fc17.i686 requires libsal_textenc.so
Please resolve this as soon as possible.


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

Re: Proposal: changing development cycle

[Paolo Leoni]

You can find the same proposal scheme using this link (in order to avoid
mail formatting issues):
http://www.paololeoni.eu/fedora_proposal.jpg

bye,
Paolo

2012/11/5 Paolo Leoni 

> Hi,
> I'm a Fedora user and, occasionally, contributor.
> I'm writing to you only to expose a simple proposal on Fedora future.
>
> We are debating on how Fedora Development cycle could be improved, and, at
> the same time, how to maintain its "bleeding edge" way.
>
> So, this is my proposal:
>
> We could introduce a periodically different Fedora development cycle, with
> major and minor release numbers.
> When we want release a new major version, we have a development cycle
> pretty longer, e.g. one year.
> For the minor release we have the old development cycle: 6 months.
>
> The minor release that come before the major release could have a life
> cycle with a lenght of 18 months, to compensate the longer devel cycle of
> the next major release.
>
> The time to begin development of a major released could be discussed and
> decided by FESCo.
>
>
> This is a simple graphical concept of the proposal:
>
>
> || = 6 months of distribution development
>
> || = 6 months of distribution stable life
>
>
> Fedora 17.8
>
> ||--|--|
>
> Fedora 17.9
>
>
> |~|--|--|--|
>
> Fedora 18.0 (e.g.: introducing new anaconda...)
>
>
> |~|~|--|--|
>
> Fedora 18.1
>
>
> |~|--|--|
>
> Fedora 18.2
>
>
> |~|--|--|
>
> ..
>
>
> How do you think?
>
> Regards,
> Paolo Leoni ~ www.paololeoni.eu
>
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[Peter Robinson]

On Mon, Nov 5, 2012 at 1:14 PM, Bruno Wolff III  wrote:

> On Mon, Nov 05, 2012 at 06:12:59 -0500,
>   Jaroslav Reznik  wrote:
>
>> - Original Message -
>>
>> This is a problem - when developers do not work first in Rawhide and
>> do not push back to branched (or push into branched from Rawhide if
>> it's on time). We talked about it in the last Board meeting, one idea
>> was to block in Bodhi any updates where Rawhide version < update
>> version.
>>
>
> In some cases there aren't even rawhide builds. Branched builds are being
> inherited into rawhide once they hit the branched stable release.
>

Yep which causes major problems if something they depend on is bumped on
rawhide as the inheritance just breaks a lot of stuff.

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

Proposal: changing development cycle

[Paolo Leoni]

Hi,
I'm a Fedora user and, occasionally, contributor.
I'm writing to you only to expose a simple proposal on Fedora future.

We are debating on how Fedora Development cycle could be improved, and, at
the same time, how to maintain its "bleeding edge" way.

So, this is my proposal:

We could introduce a periodically different Fedora development cycle, with
major and minor release numbers.
When we want release a new major version, we have a development cycle
pretty longer, e.g. one year.
For the minor release we have the old development cycle: 6 months.

The minor release that come before the major release could have a life
cycle with a lenght of 18 months, to compensate the longer devel cycle of
the next major release.

The time to begin development of a major released could be discussed and
decided by FESCo.


This is a simple graphical concept of the proposal:


|| = 6 months of distribution development

|| = 6 months of distribution stable life


Fedora 17.8

||--|--|

Fedora 17.9


|~|--|--|--|

Fedora 18.0 (e.g.: introducing new anaconda...)


|~|~|--|--|

Fedora 18.1


|~|--|--|

Fedora 18.2


|~|--|--|

..


How do you think?

Regards,
Paolo Leoni ~ www.paololeoni.eu
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[Bruno Wolff III]

On Mon, Nov 05, 2012 at 06:12:59 -0500,
  Jaroslav Reznik  wrote:

- Original Message -

This is a problem - when developers do not work first in Rawhide and
do not push back to branched (or push into branched from Rawhide if
it's on time). We talked about it in the last Board meeting, one idea
was to block in Bodhi any updates where Rawhide version < update
version.


In some cases there aren't even rawhide builds. Branched builds are being 
inherited into rawhide once they hit the branched stable release.

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

[perl-Sys-MemInfo] Teach rpmlint

[Petr Pisar]

commit ca549ffb9b51d9a871f29270d933d2762e66c48b
Author: Petr Písař 
Date:   Mon Nov 5 14:04:33 2012 +0100

Teach rpmlint

 .rpmlint |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
---
diff --git a/.rpmlint b/.rpmlint
new file mode 100644
index 000..17fddf6
--- /dev/null
+++ b/.rpmlint
@@ -0,0 +1,2 @@
+from Config import *
+addFilter("spelling-error .* (freemem|totalmem)");
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Sys-MemInfo] Modernize spec file

[Petr Pisar]

commit 5d392a29e50c22982f5a7997ee49bd47bcb4837c
Author: Petr Písař 
Date:   Mon Nov 5 14:02:57 2012 +0100

Modernize spec file

 perl-Sys-MemInfo.spec |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)
---
diff --git a/perl-Sys-MemInfo.spec b/perl-Sys-MemInfo.spec
index c12cde9..c302d3b 100644
--- a/perl-Sys-MemInfo.spec
+++ b/perl-Sys-MemInfo.spec
@@ -30,12 +30,9 @@ bytes in totalmem and freemem variables.
 make %{?_smp_mflags}
 
 %install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-
+make pure_install DESTDIR=$RPM_BUILD_ROOT
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
 find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
-
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Sys-MemInfo] Specify all dependencies

[Petr Pisar]

commit 102f01ce793df330929f6ef7c10fb28358f5d28c
Author: Petr Písař 
Date:   Mon Nov 5 14:02:28 2012 +0100

Specify all dependencies

 perl-Sys-MemInfo.spec |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)
---
diff --git a/perl-Sys-MemInfo.spec b/perl-Sys-MemInfo.spec
index 3f45636..c12cde9 100644
--- a/perl-Sys-MemInfo.spec
+++ b/perl-Sys-MemInfo.spec
@@ -7,6 +7,11 @@ Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Sys-MemInfo/
 Source0:
http://www.cpan.org/modules/by-module/Sys/Sys-MemInfo-%{version}.tar.gz
 BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(File::Copy)
+# Run-time:
+BuildRequires:  perl(DynaLoader)
+BuildRequires:  perl(Exporter)
+# Tests:
 BuildRequires:  perl(Test::More)
 BuildRequires:  perl(Data::Dumper)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
@@ -45,6 +50,7 @@ make test
 %changelog
 * Mon Nov 05 2012 Petr Pisar  - 0.91-4
 - Improve description
+- Specify all dependencies
 
 * Fri Jul 20 2012 Fedora Release Engineering  
- 0.91-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Sys-MemInfo] Improve description

[Petr Pisar]

commit 7461b80c41065e4a16ddb4afcbdff8b0f448dcc3
Author: Petr Písař 
Date:   Mon Nov 5 14:00:47 2012 +0100

Improve description

 perl-Sys-MemInfo.spec |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/perl-Sys-MemInfo.spec b/perl-Sys-MemInfo.spec
index 790b301..3f45636 100644
--- a/perl-Sys-MemInfo.spec
+++ b/perl-Sys-MemInfo.spec
@@ -1,7 +1,7 @@
 Name:   perl-Sys-MemInfo
 Version:0.91
-Release:3%{?dist}
-Summary:Sys::MemInfo Perl module
+Release:4%{?dist}
+Summary:Memory information as Perl module
 License:LGPLv2+
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Sys-MemInfo/
@@ -14,7 +14,7 @@ Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} 
-V:version`"; echo $versi
 %{?perl_default_filter}
 
 %description
-Sys::MemInfo return the total amount of free and used physical memory in
+Sys::MemInfo returns the total amount of free and used physical memory in
 bytes in totalmem and freemem variables.
 
 %prep
@@ -43,6 +43,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Nov 05 2012 Petr Pisar  - 0.91-4
+- Improve description
+
 * Fri Jul 20 2012 Fedora Release Engineering  
- 0.91-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-DBD-CSV] Specify all dependencies

[Jitka Plesnikova]

commit fcf8e1c0ebb953d67928a5231863efb05d3aaea5
Author: Jitka Plesnikova 
Date:   Mon Nov 5 14:01:30 2012 +0100

Specify all dependencies

 perl-DBD-CSV.spec |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)
---
diff --git a/perl-DBD-CSV.spec b/perl-DBD-CSV.spec
index 5fd46e3..3fc88a0 100644
--- a/perl-DBD-CSV.spec
+++ b/perl-DBD-CSV.spec
@@ -1,6 +1,6 @@
 Name:   perl-DBD-CSV
 Version:0.36
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:DBI driver for CSV files
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -8,9 +8,12 @@ URL:http://search.cpan.org/dist/DBD-CSV/
 Source0:
http://search.cpan.org/CPAN/authors/id/H/HM/HMBRAND/DBD-CSV-%{version}.tgz
 BuildArch:  noarch
 BuildRequires:  perl(Carp)
+BuildRequires:  perl(Cwd)
 BuildRequires:  perl(DBD::File) >= 0.40
 BuildRequires:  perl(DBI) >= 1.614
+BuildRequires:  perl(Encode)
 BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(IO::File)
 BuildRequires:  perl(SQL::Statement) >= 1.33
 BuildRequires:  perl(Text::CSV_XS) >= 0.91
@@ -62,6 +65,9 @@ make test
 %{_mandir}/man3/*.3pm*
 
 %changelog
+* Mon Nov 05 2012 Jitka Plesnikova  - 0.36-2
+- Specify all dependencies
+
 * Mon Aug 27 2012 Petr Šabata  - 0.36-1
 - 0.36 bump, debugging enhancements
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Ralf Corsepius]

On 11/05/2012 01:11 AM, Matěj Cepl wrote:

On Fri, 02 Nov 2012 20:55:38 +, Jóhann B. Guðmundsson wrote:

and one "stable" release ( valid for 2 maybe 3 years ) for those in the
community that want something they dont constantly having to upgrade to
and can deploy on their servers. ( ofcourse to have a stable release we
first and foremost would need maintainers willing to maintain the
distribution for that time, epel could maybe be simply dropped for that
).


That's called CentOS,

Nope ... CentOS/RHEL is a different end of extremes.

7 years+ life-time, no API changes, etc.

What is lacking is a middle ground between "Fedora" and "CentOS".

Something with a life-time of "~2 years", with API increments etc.

Ralf

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

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[mike cloaked]

On Mon, Nov 5, 2012 at 10:56 AM, Jiri Eischmann wrote:

>
> Release parties and codenames were just examples. It's about the buzz
> around releases. You can check Google Trends where you find peaks in
> number of searches for Fedora after every release. Or fp.org monthly
> stats. You would lose reviews, that are usually published after
> releases, because I don't see any reviews of rolling release
> distributions by main magazines. Etc.
>

Here is one:
http://www.linuxuser.co.uk/features/under-the-hood-with-arch-and-gentoo

>From a few weeks ago!


> BTW this is not just about current Fedora users. Marketing is mainly
> about potential users.
>

Sure -

>
> Well, as someone has already said here: stability and reliability are
> relative terms. I used Arch Linux for a while and I didn't find it
> stable and reliable on the level where I'd like to see Fedora. If you
> have to read release notes before every update to make sure you know
> what might break and how to fix it, then you're not using a system that
> would be appealing to a large number of user. And Fedora has always been
> aiming much broader audience than Gentoo or Arch.
>

Generally speaking for arch linux you don't get "release notes" for
packages as such - and for the most part a regular update merely requires
the following command:

#pacman -Syu

then accept or reject running the set of updates that is offered. Not a big
deal - now and again there is an announcement on arch-announce (also on
their main web page) which says run the following command (or two!) before
the next update or similar - hardly a major hassle every few months.

It's true that for my Fedora boxes I just have to run:

#yum -y update

or

#yum update and then accept or reject the set of updates offered - much the
same really.

however for F16 which is current I don't have the latest KDE, or the latest
systemd, or the latest libreoffice etc - which I do on my arch boxes. For
any user that does not mind having KDE work OK but not with the latest
round of bug fixes and new features it is fine. Similar with the other
packages. Chrome is not offered as mainline by either distro but on Fedora
google has a yum repo - so I run the latest chrome just fine on F16 - and
in arch there is the latest via the AUR system so I run the latest chrome
there too. But I won't have to run any re-install on the arch boxes whereas
in order to keep my F16 boxes supported I will have to re-install around
the end of the year. I know there are constant reminders from people who
say they have never re-installed and just preupgrade but my own experience
with that around the F9 timeframe was really poor - and I ended up doing a
sequence of manual steps along with various yum upgrades/updates and kept a
box going through two releases before deciding that a clean install was
about the only sensible way forward at that time - maybe it is really quite
trouble free updating from one release to another these days - so maybe my
F16 boxes could be upgraded nice and easy to F17 and F18 with only a few
commands and a bit of a wait - but I am not convinced it is worth the risk
as one of them is a server!

So it is "horses for courses" - I have two courses and a number of horses
and so far none of the horses have died!

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

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Nicu Buculei]

On 11/05/2012 01:13 PM, Mathieu Bridon wrote:

On Monday, November 05, 2012 06:56 PM, Jiri Eischmann wrote:

mike cloaked píše v Ne 04. 11. 2012 v 21:44 +:


Does anyone have any reliable statistics about the number of users who
feel that release parties and codenames are important to them?


Release parties and codenames were just examples. It's about the buzz
around releases. You can check Google Trends where you find peaks in
number of searches for Fedora after every release.


That just means our marketing is virtually inexistant between two releases.

A rolling release model would mean that our buzz would be lower than the
peak values, but it would be constant.


It does not work this way :)

The number of volunteers promoting Fedora is limited and their time is 
limited, do not expect them to promote Fedora 24 hours a day, 365 days a 
year, they will focus on important things, like the releases (but not only).


Also, is the matter of saturation: the general public has its own 
priorities, if you barrage them with a constant flux of Fedora related 
news, they will quickly become bored: what? yet another feature in 
Fedora? just like the other gazillion they make public every other day?


--
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com

--
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/
photography: http://photoblog.nicubunu.ro/

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

F-18 Branched report: 20121105 changes

[Fedora Branched Report]

Compose started at Mon Nov  5 09:15:26 UTC 2012

Broken deps for x86_64
--
[dhcp-forwarder]
dhcp-forwarder-upstart-0.10-1801.fc18.noarch requires /sbin/initctl
[dnf]
dnf-0.2.14-2.git4831982.fc18.noarch requires python-hawkey >= 0:0.3.0
[dustmite]
dustmite-1-5.20120304gitcde46e0.fc17.x86_64 requires 
libphobos-ldc.so.59()(64bit)
[func]
func-0.28-1.fc17.noarch requires smolt
[gcc-python-plugin]
gcc-python2-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18
gcc-python2-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18
gcc-python3-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18
gcc-python3-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18
[gdb-heap]
gdb-heap-0.5-9.fc18.x86_64 requires glibc(x86-64) = 0:2.15
[gnome-do-plugins]
gnome-do-plugins-banshee-0.8.4-10.fc18.x86_64 requires 
mono(Banshee.CollectionIndexer) = 0:2.4.0.0
[gnome-shell-theme-selene]
gnome-shell-theme-selene-3.4.0-5.fc18.noarch requires 
gnome-shell-extensions-user-theme
[ip-sentinel]
ip-sentinel-upstart-0.12-1303.fc18.noarch requires /sbin/initctl
[libsyncml]
1:libsyncml-0.4.6-4.fc17.i686 requires libsoup-2.2.so.8
1:libsyncml-0.4.6-4.fc17.x86_64 requires libsoup-2.2.so.8()(64bit)
[mapserver]
mapserver-perl-6.0.1-5.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2)
[milter-greylist]
milter-greylist-upstart-4.2.7-1701.fc18.noarch requires /sbin/initctl
[mod_pubcookie]
mod_pubcookie-3.3.4a-7.fc18.x86_64 requires httpd-mmn = 
0:20051115-x86-64
[openvrml]
libopenvrml-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0
libopenvrml-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0
libopenvrml-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0
libopenvrml-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
libopenvrml-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
libopenvrml-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0
libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0
libopenvrml-gl-0.18.9-3.fc18.i686 requires 
libboost_filesystem-mt.so.1.48.0
libopenvrml-gl-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
libopenvrml-gl-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
libopenvrml-gl-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
openvrml-java-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
openvrml-java-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
openvrml-java-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
openvrml-javascript-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
openvrml-javascript-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
openvrml-javascript-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
openvrml-nodes-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
openvrml-nodes-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
openvrml-nodes-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
openvrml-xembed-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
openvrml-xembed-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
openvrml-xembed-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
[perl-Hardware-Verilog-Parser]
perl-Hardware-Verilog-Parser-0.13-9.fc17.noarch requires 
perl(:MODULE_COMPAT_5.14.2)
[perl-OpenOffice-UNO]
perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires 
perl(:MODULE_COMPAT_5.14.2)
[presence]
presence-0.4.6-2.fc18.x86_64 requires libcogl.so.9()(64bit)
[pyfuzzy]
pyfuzzy-0.1.0-5.fc18.noarch requires antlr3-python
[reciteword]
reciteword-0.8.4-10.fc18.x86_64 requires esound
[resource-agents]
resource-agents-3.9.2-3.fc18.5.x86_64 requires libplumbgpl.so.2()(64bit)
resource-agents-3.9.2-3.fc18.5.x86_64 requires libplumb.so.2()(64bit)
[ruby-revolution]
ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires 
libedataserver-1.2.so.16()(64bit)
ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires 
libecal-1.2.so.12()(64bit)
ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires 
libebook-1.2.so.13()(64bit)
[rubygem-activeldap]
rubygem-activeldap-1.2.2-3.fc17.noarch requires 
rubygem(gettext_activerecord) >= 0:2.1.0
rubygem-activeldap-1.2.2-3.fc17.noarch requires ruby(abi) = 0:1.8
[rubygem-calendar_date_select]
rubygem-calendar_date

Broken dependencies: perl-OpenOffice-UNO

[buildsys]

perl-OpenOffice-UNO has broken dependencies in the F-18 tree:
On x86_64:
perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires 
perl(:MODULE_COMPAT_5.14.2)
On i386:
perl-OpenOffice-UNO-0.07-3.fc17.i686 requires 
perl(:MODULE_COMPAT_5.14.2)
perl-OpenOffice-UNO-0.07-3.fc17.i686 requires libsal_textenc.so
Please resolve this as soon as possible.


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

[perl-Devel-Symdump] Add missing requirement - Exporter.

[Marcela Mašláňová]

commit 6557398aea0b97caf25820ebe8b80ac18bb6b3c0
Author: Marcela Mašláňová 
Date:   Mon Nov 5 12:53:58 2012 +0100

Add missing requirement - Exporter.

 perl-Devel-Symdump.spec |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-Symdump.spec b/perl-Devel-Symdump.spec
index 5a99c03..a829a9b 100644
--- a/perl-Devel-Symdump.spec
+++ b/perl-Devel-Symdump.spec
@@ -1,6 +1,6 @@
 Name:   perl-Devel-Symdump
 Version:2.08
-Release:11%{?dist}
+Release:12%{?dist}
 Epoch:  1
 Summary:A Perl module for inspecting Perl's symbol table
 Group:  Development/Libraries
@@ -16,6 +16,7 @@ BuildRequires:  perl(Test::More)
 BuildRequires:  perl(Test::Pod)
 BuildRequires:  perl(Test::Pod::Coverage)
 %endif
+Requires:   perl(Exporter)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 
 %description
@@ -49,6 +50,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/Devel::Symdump.3pm*
 
 %changelog
+* Mon Nov  5 2012 Marcela Mašláňová  - 1:2.08-12
+- Add missing requirement - Exporter
+
 * Fri Jul 20 2012 Fedora Release Engineering  
- 1:2.08-11
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Rawhide

[Panu Matilainen]

On 11/05/2012 01:12 PM, Jaroslav Reznik wrote:

- Original Message -


Le Lun 5 novembre 2012 10:45, Dodji Seketeli a écrit :


Just having a dedicated Rawhide Swat Team of die hard volunteers
who
could spot issues early, file more bugs, gently push for fixes in
Rawhide and last but not least build a kind of "esprit de corps"
among
those who suffer Rawhide breakages for the greater good would be a
great
start, IMHO.


There is already a pool of rawhide users.
Rawhide bugs are already reported.

The problem is not here, the problem is maintainers that deliberately
ignore bugs with rawhide in them (usual excuse and motto are "Rawhide
eats
babies", "I'll test when Rawhide is more stable", no empathy for
other
maintainers that can not test because your problem is breaking their
test
process). They hope the problems will go away before branch time, and
then
cry they get too little time to fix stuff after branching when the
very
same problems hit alpha testers, or badger the reporters to file a
new
report at branch time without even checking the information that was
provided before and assuming it is necessarily stale.

All the systemd problems were reported in Rawhide way before they hit
branched. If they did hit branched it's not because reporting was
lacking,
but because there was a lack of social pressure not to let Rawhide
rot
(with easily predictable consequences).

When systemd inclusion was deferred in stable because it was not
ready and
no service had been migrated there was *no* effort I could see to fix
the
problem in Rawhide and systemd hit the next branch time with all the
problems that justified initial deferring intact.


This is a problem - when developers do not work first in Rawhide and
do not push back to branched (or push into branched from Rawhide if
it's on time). We talked about it in the last Board meeting, one idea
was to block in Bodhi any updates where Rawhide version < update
version.


+1

Changes really need go to rawhide first and then where applicaple, 
pulled to branches. If it feels painful, that's quite possibly a symptom 
of being out of sync with the development window. The current situation 
where branched tree gets ALL the attention when present is much like 
flipping back and forth between left- and right-handed traffic rules: 
much chaos, many collisions and lost bits and pieces ensues.



Someone wrote in this thread that Gnome updates were painful in
branched.
Well they are horrific in Rawhide. If there was some effort to make
them
only painful in Rawhide they would not be horrific in branched. (this
is
called a 'virtuous circle').

IMHO it was a huge mistake to synchronise Fedora releases with GNOME
releases instead of synchronising Fedora branch times with GNOME
release
times. That's idiotic and means there is no time Fedora-side to do
any QA
and fixing before pushing a new GNOME release to users.


I think there's some sync between GNOME and Fedora releases - I already
proposed F19 schedule - 3.7.90 is a week before branching, and before
Alpha, 3.8.0 release precedes Features 100% complete and thus it goes
to Beta. Or are you talking about having final even before branching?
The current process allows us to influence (in some extend) development
of GNOME based on Alpha release etc. And yeah, it's probably not enough.


Its easy to see why eg GNOME wants to sync with Fedora the way its 
currently done, but such massive packageset updates in branched 
invalidate much of the earlier testing.


The stabilization period (ie going from alpha to final through X number 
of intermediate steps) of a distribution and upstream software projects 
are fairly different in nature: In a software project its about fixing 
regressions and bugs in newly introduced features. A distribution 
stabilization is about integrating the hundreds and thousands of 
individual components to something coherent, and doing that is not 
really possible if the components keep radically changing.


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

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Mathieu Bridon]

On Monday, November 05, 2012 06:56 PM, Jiri Eischmann wrote:

mike cloaked píše v Ne 04. 11. 2012 v 21:44 +:

On Sun, Nov 4, 2012 at 9:07 PM, Jiri Eischmann 
wrote:


 This is a very valid argument. I understand this is a devel
 list, so we should stay on the technical level, but if we
 discuss such broad changes that affect the whole project, we
 should also take into account other aspects.

 Switching to rolling release would have a *huge* negative
 impact on marketing! It's releases what makes the fuzz and
 their announcements get beyond our current user base. We would
 have no release parties, no codenames. We would lose the
 product. I wonder what impact it would have on Fedora adoption
 by cloud providers. I think it's much more understandable not
 only for them, but also for their customers to take Fedora 17
 than some monthly build.



Does anyone have any reliable statistics about the number of users who
feel that release parties and codenames are important to them?


Release parties and codenames were just examples. It's about the buzz
around releases. You can check Google Trends where you find peaks in
number of searches for Fedora after every release.


That just means our marketing is virtually inexistant between two releases.

A rolling release model would mean that our buzz would be lower than the 
peak values, but it would be constant.


Depending on how you look at it, it could be a net win.


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

Re: Rawhide

[Jaroslav Reznik]

- Original Message -
> 
> Le Lun 5 novembre 2012 10:45, Dodji Seketeli a écrit :
> 
> > Just having a dedicated Rawhide Swat Team of die hard volunteers
> > who
> > could spot issues early, file more bugs, gently push for fixes in
> > Rawhide and last but not least build a kind of "esprit de corps"
> > among
> > those who suffer Rawhide breakages for the greater good would be a
> > great
> > start, IMHO.
> 
> There is already a pool of rawhide users.
> Rawhide bugs are already reported.
> 
> The problem is not here, the problem is maintainers that deliberately
> ignore bugs with rawhide in them (usual excuse and motto are "Rawhide
> eats
> babies", "I'll test when Rawhide is more stable", no empathy for
> other
> maintainers that can not test because your problem is breaking their
> test
> process). They hope the problems will go away before branch time, and
> then
> cry they get too little time to fix stuff after branching when the
> very
> same problems hit alpha testers, or badger the reporters to file a
> new
> report at branch time without even checking the information that was
> provided before and assuming it is necessarily stale.
> 
> All the systemd problems were reported in Rawhide way before they hit
> branched. If they did hit branched it's not because reporting was
> lacking,
> but because there was a lack of social pressure not to let Rawhide
> rot
> (with easily predictable consequences).
> 
> When systemd inclusion was deferred in stable because it was not
> ready and
> no service had been migrated there was *no* effort I could see to fix
> the
> problem in Rawhide and systemd hit the next branch time with all the
> problems that justified initial deferring intact.

This is a problem - when developers do not work first in Rawhide and
do not push back to branched (or push into branched from Rawhide if
it's on time). We talked about it in the last Board meeting, one idea
was to block in Bodhi any updates where Rawhide version < update
version.

> Someone wrote in this thread that Gnome updates were painful in
> branched.
> Well they are horrific in Rawhide. If there was some effort to make
> them
> only painful in Rawhide they would not be horrific in branched. (this
> is
> called a 'virtuous circle').
> 
> IMHO it was a huge mistake to synchronise Fedora releases with GNOME
> releases instead of synchronising Fedora branch times with GNOME
> release
> times. That's idiotic and means there is no time Fedora-side to do
> any QA
> and fixing before pushing a new GNOME release to users.

I think there's some sync between GNOME and Fedora releases - I already
proposed F19 schedule - 3.7.90 is a week before branching, and before
Alpha, 3.8.0 release precedes Features 100% complete and thus it goes
to Beta. Or are you talking about having final even before branching?
The current process allows us to influence (in some extend) development
of GNOME based on Alpha release etc. And yeah, it's probably not enough.

> (two high-visibility examples anyone can understand, not necessarily
> the
> worst offenders and systemd people at least seem to have improved
> their
> workflow a little over time)
> 
> Adding time to the end of the circle is compounding the problem, not
> fixing it.

Another thing would be use more the GIT workflow while building stuff
for Rawhide. For example - it takes quite a lot of time to build the
whole KDE stack for Rawhide and of course, this leads to breakage -
and if upstream decides to push back release when we're in the middle
(it happened) we were screwed. So use own build target, merge/push
to Rawhide once it's done. Question is how demanding would this 
behaviour be for infrastructure (if used more often by more teams,
or even required by a policy).

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

Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Jiri Eischmann]

mike cloaked píše v Ne 04. 11. 2012 v 21:44 +:
> On Sun, Nov 4, 2012 at 9:07 PM, Jiri Eischmann 
> wrote:
> 
> 
> This is a very valid argument. I understand this is a devel
> list, so we should stay on the technical level, but if we
> discuss such broad changes that affect the whole project, we
> should also take into account other aspects.
> 
> Switching to rolling release would have a *huge* negative
> impact on marketing! It's releases what makes the fuzz and
> their announcements get beyond our current user base. We would
> have no release parties, no codenames. We would lose the
> product. I wonder what impact it would have on Fedora adoption
> by cloud providers. I think it's much more understandable not
> only for them, but also for their customers to take Fedora 17
> than some monthly build.
> 
> 
> 
> Does anyone have any reliable statistics about the number of users who
> feel that release parties and codenames are important to them? 

Release parties and codenames were just examples. It's about the buzz
around releases. You can check Google Trends where you find peaks in
number of searches for Fedora after every release. Or fp.org monthly
stats. You would lose reviews, that are usually published after
releases, because I don't see any reviews of rolling release
distributions by main magazines. Etc.

BTW this is not just about current Fedora users. Marketing is mainly
about potential users. 

> There will no doubt be some people for whom the idea of running a
> particular codenamed release is important - but there will also be
> others for whom a high quality established linux distribution that is
> reliable and up to date irrespective of its codename is more
> important. Marketing feedback if it is possible to give the relative
> number of users in each camp would be helpful here? Gathering such
> statistics is likely difficult though.
>  
> I personally don't like the whole idea of switching to rolling
> release. Although I see some pros, I see a lot of cons that
> would outweight the pros. I've come across a few rolling
> release distributions (Debian Testing, Arch Linux, Gentoo,...)
> and I don't think they work if you want to achieve some level
> of stability and predictability. 
> 
> 
> Arch linux is stable and reliable and predictable - I use it every day
> - you need to ask users of the other distributions named whether users
> feel they are similarly stable and predictable or not for the most
> part.

Well, as someone has already said here: stability and reliability are
relative terms. I used Arch Linux for a while and I didn't find it
stable and reliable on the level where I'd like to see Fedora. If you
have to read release notes before every update to make sure you know
what might break and how to fix it, then you're not using a system that
would be appealing to a large number of user. And Fedora has always been
aiming much broader audience than Gentoo or Arch. 

> Does anyone have any relative user stats on the various distros?
> 
> 
> Do any web sites gather stats which might indicate hit rates coming
> from different distros? 
> 
> 
> These data are difficult to get so in the end a clear goal for any
> distribution has to be agreed on and then executed - if Fedora wishes
> to go to rolling Rawhide but a bit more stable that at present and it
> is possible to do that - then developers must agree at least on some
> kind of overall vote maybe?  In the end the users will guide whether
> the route taken is being adopted widespread among the community.  You
> get some idea of users interested from feedback to the devel list, or
> via bodhi I guess?
> 
> 
> One other question that is hard to answer is whether a particular
> change in direction is achievable since it depends on developers
> adopting it and agreeing to work on it - inevitably some will not want
> to go to any new route - but will the new direction excite other
> developers to come on board that were not there before and make up any
> loss?
> 
> 
> The way I see it is that the two routes are a bit like asking if
> people like meat or fish for the main course at a meal - there will be
> a split opinion - and there are good points about both!  Some people
> may be allergic to one or other though!
> 
> 
> Is there an objective list of pros and cons that can be judged without
> bias in favour of rolling release or periodic releases so that a
> logical weighing of the relative merits of both approaches can be
> considered? If that goes in favour of rolling release then can it be
> achieved with the tools available without too much effort? If new
> tools have to be built within the Fedora Framework is there enough
> effort and willingness to build them?
> 
> 
> -- 
> mike c
> 


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

[Bug 872616] perl-XML-LibXML-2.0010 is available

[bugzilla]

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

Petr Šabata  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-XML-LibXML-2.0010-1.fc
   ||19
 Resolution|--- |RAWHIDE
Last Closed||2012-11-05 05:42:42

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

Re: [rhn-client-tools] Created tag rhn-client-tools-1.8.26-1.fc19

[Miroslav Suchý]

On 11/02/2012 11:32 AM, Nicolas Chauvet wrote:

Hi Miroslav,

It sounds like you are missing f18 branch while creating new build


I always push new Spacewalk packages to rawhide only. The reason is that
always some problem pops up - this time broken dependencies on
spacewalk-web. In rawhide I have quite long time for resolving issues.
If I had put it into F18 or F17, I would need to act more quickly, which
I could not afford.

But if you want those packages in F18 or F17 and you are willing to
help, ping me privately and we can discuss your co-maintaining of those
packages

--
Miroslav Suchy
Red Hat Systems Management Engineering
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide

[Nicolas Mailhot]

Le Lun 5 novembre 2012 10:45, Dodji Seketeli a écrit :

> Just having a dedicated Rawhide Swat Team of die hard volunteers who
> could spot issues early, file more bugs, gently push for fixes in
> Rawhide and last but not least build a kind of "esprit de corps" among
> those who suffer Rawhide breakages for the greater good would be a great
> start, IMHO.

There is already a pool of rawhide users.
Rawhide bugs are already reported.

The problem is not here, the problem is maintainers that deliberately
ignore bugs with rawhide in them (usual excuse and motto are "Rawhide eats
babies", "I'll test when Rawhide is more stable", no empathy for other
maintainers that can not test because your problem is breaking their test
process). They hope the problems will go away before branch time, and then
cry they get too little time to fix stuff after branching when the very
same problems hit alpha testers, or badger the reporters to file a new
report at branch time without even checking the information that was
provided before and assuming it is necessarily stale.

All the systemd problems were reported in Rawhide way before they hit
branched. If they did hit branched it's not because reporting was lacking,
but because there was a lack of social pressure not to let Rawhide rot
(with easily predictable consequences).

When systemd inclusion was deferred in stable because it was not ready and
no service had been migrated there was *no* effort I could see to fix the
problem in Rawhide and systemd hit the next branch time with all the
problems that justified initial deferring intact.

Someone wrote in this thread that Gnome updates were painful in branched.
Well they are horrific in Rawhide. If there was some effort to make them
only painful in Rawhide they would not be horrific in branched. (this is
called a 'virtuous circle').

IMHO it was a huge mistake to synchronise Fedora releases with GNOME
releases instead of synchronising Fedora branch times with GNOME release
times. That's idiotic and means there is no time Fedora-side to do any QA
and fixing before pushing a new GNOME release to users.

(two high-visibility examples anyone can understand, not necessarily the
worst offenders and systemd people at least seem to have improved their
workflow a little over time)

Adding time to the end of the circle is compounding the problem, not
fixing it.

-- 
Nicolas Mailhot

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

[perl-XML-LibXML] 2.0010 bumpity

[Petr Šabata]

commit 80235465a0323c8a5c7bfdda6d352b06cafa9636
Author: Petr Šabata 
Date:   Mon Nov 5 11:16:09 2012 +0100

2.0010 bumpity

 .gitignore   |1 +
 perl-XML-LibXML.spec |5 -
 sources  |2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b498f1a..a788ac1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -16,3 +16,4 @@ XML-LibXML-1.70.tar.gz
 /XML-LibXML-2.0006.tar.gz
 /XML-LibXML-2.0007.tar.gz
 /XML-LibXML-2.0008.tar.gz
+/XML-LibXML-2.0010.tar.gz
diff --git a/perl-XML-LibXML.spec b/perl-XML-LibXML.spec
index 980d094..3222365 100644
--- a/perl-XML-LibXML.spec
+++ b/perl-XML-LibXML.spec
@@ -3,7 +3,7 @@ Name:   perl-XML-LibXML
 # https://bugzilla.redhat.com/show_bug.cgi?id=469480
 # it might not be needed anymore
 # this module is maintained, the other is not
-Version:2.0008
+Version:2.0010
 Release:1%{?dist}
 Epoch:  1
 Summary:Perl interface to the libxml2 library
@@ -102,6 +102,9 @@ fi
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Nov 05 2012 Petr Šabata  - 1:2.0010-1
+- 2.0010 bumpity
+
 * Tue Oct 23 2012 Petr Šabata  - 1:2.0008-1
 - 2.0008 bump
 
diff --git a/sources b/sources
index ff5d526..d88d84a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d2bb8b6453574a47b46e3329902bde2d  XML-LibXML-2.0008.tar.gz
+c95bbf6bdaef0b16bd7979f7e4f97ec8  XML-LibXML-2.0010.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File XML-LibXML-2.0010.tar.gz uploaded to lookaside cache by psabata

[Petr Šabata]

A file has been added to the lookaside cache for perl-XML-LibXML:

c95bbf6bdaef0b16bd7979f7e4f97ec8  XML-LibXML-2.0010.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 872616] perl-XML-LibXML-2.0010 is available

[bugzilla]

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

Petr Šabata  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||psab...@redhat.com
   Assignee|mmasl...@redhat.com |psab...@redhat.com

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

[Bug 855755] perl-X11-Protocol-Other-21 is available

[bugzilla]

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

Petr Šabata  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-X11-Protocol-Other-21-
   ||1.fc19
 Resolution|--- |RAWHIDE
Last Closed||2012-11-05 04:54:04

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

[perl] Remove patch, update MODULE_COMPAT

[Jitka Plesnikova]

commit acd8b4dbbf9b77434cad7cfb4039e15e90c82d58
Author: Jitka Plesnikova 
Date:   Mon Nov 5 10:57:01 2012 +0100

Remove patch, update MODULE_COMPAT

 ...5.16.1-PATCH-perl-114220-h-not-equiv-to-h.patch |   83 
 perl.spec  |3 +-
 2 files changed, 2 insertions(+), 84 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index 3af8a14..70d442d 100644
--- a/perl.spec
+++ b/perl.spec
@@ -125,10 +125,11 @@ BuildRequires:  procps, rsyslog
 
 
 # compat macro needed for rebuild
-%global perl_compat perl(:MODULE_COMPAT_5.16.1)
+%global perl_compat perl(:MODULE_COMPAT_5.16.2)
 
 # Compat provides
 Provides: %perl_compat
+Provides: perl(:MODULE_COMPAT_5.16.1)
 Provides: perl(:MODULE_COMPAT_5.16.0)
 
 # Threading provides
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Panu Matilainen]

On 11/05/2012 09:39 AM, drago01 wrote:

On Mon, Nov 5, 2012 at 5:57 AM, Dennis Gilmore  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El Wed, 31 Oct 2012 10:59:54 -0700
Jesse Keating  escribió:

On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:

* Jesse Keating, Jeremy Katz, and others who helped shape the
current policy and theory of our release schedule felt that the 6
month release cycle was fine but that certain features were going
to take longer to develop. Those would need to be developed and not
enter into Fedora until they were close enough that they could be
completed during that cycle.
- No matter what we do to try and increase the development cycle
within a release, there's always going to be issues that take
longer than the release that we need to deal with.  Perhaps, we
just need to be better about making people follow this model.


I'm not entirely sure what I felt then, but I'm certainly open to a
longer release cycle.  In fact I'm very much in favor of one, one
that puts more time between "feature complete" and the actual alpha
release. All too often we see features crash land right at the
deadline, and any software that has to integrate across a lot of
pieces (like anaconda) gets stuck trying to account for all these
changes in a very limited time frame, only to be hindered quickly by
a freeze process.


I really do not object to a longer release cycle.  I am also open to
making feature freeze being 4-6 weeks before Alpha change freeze. The
risk we run is people land new features anyway. but we run that today.
We always have a run of things late. People need to land changes
earlier  the bigger the change the earlier it needs to land.  Maybe it
wont be a popular idea but having feature freeze at previous release
time is needed. What I am thinking is:

Branch as we do, which opens up development for next release same as
we do today, so in the current cycle when we branched off f18, f19
features needed to start landing so all that would be taken for f18 is
bug fix and integration fixes.  when we release f18 we hit F19 feature
freeze.


That does not work because we do not have unlimited resources ... you
can't expect people to work on F19 features at the same time while
they are trying to get F18 ready for release.


If/when the "real work" behind a feature has been done early enough, 
getting from Fedora alpha to final consists of just a few bugfixes that 
can only be found with sufficiently large test-audience. That's very 
different from the way things some things land: known very incomplete 
work submitted at very last minute, followed by a mad scramble to try 
and scrape it to somehow acceptable state in time. It's avoidable by 
simply resisting the urge to slip stuff in on the last minute, the 
release cycle is short enough that world does not end if you postpone 
something to the next release.



Honestly I don't think that the current issues have anything to do
with the schedule but more with the way we handled the anaconda
feature. We should just fix that and not try to make random changes
all over the place.

Basically there should not be any "this cannot be reverted" (there is
no such thing really) features. If it is evident before the feature
freeze that a given feature would not be ready in time we have to punt
it to the next release PERIOD.


No disagreement there - features with no feasible contingency plan 
should be treated very cautiously and if accepted anyway, should have 
stricter completeness-requirements and much earlier deadlines than 
easily reversible things.


- Panu -

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

[perl-X11-Protocol-Other] 21 bump

[Petr Šabata]

commit 24ae61d9bdaa1f7fe103e4e78252040f932c6a99
Author: Petr Šabata 
Date:   Mon Nov 5 10:39:13 2012 +0100

21 bump

 .gitignore   |1 +
 perl-X11-Protocol-Other.spec |   38 --
 sources  |2 +-
 3 files changed, 26 insertions(+), 15 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9c5552a..e357e9b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 X11-Protocol-Other-18.tar.gz
+/X11-Protocol-Other-21.tar.gz
diff --git a/perl-X11-Protocol-Other.spec b/perl-X11-Protocol-Other.spec
index 303c769..a7d28d8 100644
--- a/perl-X11-Protocol-Other.spec
+++ b/perl-X11-Protocol-Other.spec
@@ -1,5 +1,5 @@
 Name:   perl-X11-Protocol-Other
-Version:18
+Version:21
 Release:1%{?dist}
 Summary:Miscellaneous X11::Protocol helpers
 License:GPLv3+
@@ -7,40 +7,50 @@ Group:  Development/Libraries
 URL:http://search.cpan.org/dist/X11-Protocol-Other/
 Source0:
http://www.cpan.org/modules/by-module/X11/X11-Protocol-Other-%{version}.tar.gz
 BuildArch:  noarch
-BuildRequires:  perl >= 0:5.004
+BuildRequires:  perl(constant)
+BuildRequires:  perl(lib)
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(Encode)
+BuildRequires:  perl(Encode::Encoding)
+BuildRequires:  perl(Encode::HanExtra)
+BuildRequires:  perl(Exporter)
 BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(IO::Select)
 BuildRequires:  perl(X11::Protocol)
-BuildRequires:  perl(Encode::HanExtra)
-Requires:   perl(X11::Protocol)
-Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 
 %description
 These are some helper functions for X11::Protocol.
 
 %prep
 %setup -q -n X11-Protocol-Other-%{version}
+chmod a-x examples/*
 
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"
+perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE="%{optflags}"
 make %{?_smp_mflags}
 
 %install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
-
-%{_fixperms} $RPM_BUILD_ROOT/*
+make pure_install PERL_INSTALL_ROOT=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f {} \;
+find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
+%{_fixperms} %{buildroot}/*
 
 %check
 make test
 
 %files
-%doc Changes COPYING
+%doc Changes COPYING examples
 %{perl_vendorlib}/*
 %{_mandir}/man3/*
 
 %changelog
+* Mon Nov 05 2012 Petr Šabata  - 21-1
+- 21 bump
+- Fix the deps
+- Modernize the spec a bit
+- Package the examples
+
 * Sat Aug 11 2012 Robin Lee  18-1
 - Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index d3532c7..562bbbc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-cbbe7338df08642d6bf01f3c66f65d27  X11-Protocol-Other-18.tar.gz
+06c1a9df4ccad8c42b0123890063af96  X11-Protocol-Other-21.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File X11-Protocol-Other-21.tar.gz uploaded to lookaside cache by psabata

[Petr Šabata]

A file has been added to the lookaside cache for perl-X11-Protocol-Other:

06c1a9df4ccad8c42b0123890063af96  X11-Protocol-Other-21.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Rawhide

[Dodji Seketeli]

Kevin Fenzi  a écrit:

> Get a nice group of at least 10 or so folks who are active on this list
> to agree to run it full time on their main machine.   

Amen brother.  Count me in that group if this ever happens. 

I already run rawhide on a dedicated box for daily duties like email,
web browsing etc.  I have another box with a stable fedora release for
day to day hacking.  I switch between the two using a KVM swith (the
real hardware, you know, not the kernel virtualization thingy).

It seems to me that if more Fedora Hackers were running Rawhide all the
time, the delay we are seeing now in F18 could have been at least
predicted a long time ago.  The thing is, everybody is damn busy with
his own work/life schedule so we cannot force this on people.

Just having a dedicated Rawhide Swat Team of die hard volunteers who
could spot issues early, file more bugs, gently push for fixes in
Rawhide and last but not least build a kind of "esprit de corps" among
those who suffer Rawhide breakages for the greater good would be a great
start, IMHO.

Who knows, with time, these fine fellows could even inspire more Fedora
Hackers to actually test their builds on Rawhide.  We can dream.  :-)

> Additionally, if some number of these folks who pledge to run rawhide
> full time were provenpackagers we could just go in and fix things as
> they hit (or soon after) instead of waiting a while for fixes to go
> out. 

[+1] + vigorous nodding.

> I've run a rawhide vm/test machine here for many years. It's hit it's
> share of problems, but none were insurmountable. Some of them might
> have been for folks who were not more experienced tho, so increasing
> communication around rawhide can only help, IMHO. 

Could we have a rawhide-list for this?  I know fighting proliferation of
mailing list is a good thing, but practically speaking, being able to
quickly scan a mailing list before doing a yum update can help a
Rawhider evaluate in advance the odds of his risking to be unable to
reboot his machine or not.  :-)

> Additional thoughts to help rawhide: 
>
> - It's been suggested before, but could we practically keep N and N-1
>   packages in rawhide repos? Then 'yum downgrade' becomes much more
>   handy. Repodata size and mirror size might shoot that down though. 
>
> - Autoqa could perhaps help out, but I am not holding my breath. ;) 
>
> - Anaconda folks haven't wanted rawhide installer images as they cause
>   people to report bugs on things when not ready, etc. However, could
>   we build nightly cloud images at least? Those could help test things
>   and won't require hitting the installer path. 
>
> - I'm sure there's more ideas to improve it... 
>
  - I'd add, having a way for some provenpackagers of the Rawhide Swat
  Team to temporarily blacklist a (set of) package, if it appears to
  significantly break something; so that people doing yum update on
  Rawhide won't brick their system because of well know issue waiting to
  be solved.

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

[perl] Update to 5.16.2

[Jitka Plesnikova]

commit 37188919aedfa7b50f47974d52a91bed7aad241e
Author: Jitka Plesnikova 
Date:   Mon Nov 5 10:43:05 2012 +0100

Update to 5.16.2

 .gitignore |1 +
 perl.spec  |   14 +++---
 sources|2 +-
 3 files changed, 9 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7f973e9..88ffbb4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -14,3 +14,4 @@ filter-requires.sh
 /perl-5.16.0.tar.gz
 /perl-5.16.1-228.fc19.src.rpm
 /perl-5.16.1.tar.gz
+/perl-5.16.2.tar.gz
diff --git a/perl.spec b/perl.spec
index 26244c7..3af8a14 100644
--- a/perl.spec
+++ b/perl.spec
@@ -1,4 +1,4 @@
-%global perl_version5.16.1
+%global perl_version5.16.2
 %global perl_epoch  4
 %global perl_arch_stem -thread-multi
 %global perl_archname %{_arch}-%{_os}%{perl_arch_stem}
@@ -29,7 +29,7 @@
 Name:   perl
 Version:%{perl_version}
 # release number must be even higher, because dual-lived modules will be 
broken otherwise
-Release:241%{?dist}
+Release:242%{?dist}
 Epoch:  %{perl_epoch}
 Summary:Practical Extraction and Report Language
 Group:  Development/Languages
@@ -85,9 +85,6 @@ Patch10:perl-5.16.0-fix-broken-atof.patch
 # Do not access freed memory when cloning thread, rhbz#825749, RT#111610
 Patch11:
perl-5.16.1-perl-111610-Trouble-with-XS-APItest-t-clone-with-sta.patch
 
-# Match non-breakable space with /[\h]/ in ASCII mode, rhbz#844919, RT#114220
-Patch12:perl-5.16.1-PATCH-perl-114220-h-not-equiv-to-h.patch
-
 # Clear $@ before `do' I/O error, rhbz#834226, RT#113730
 Patch13:perl-5.16.1-RT-113730-should-be-cleared-on-do-IO-error.patch
 
@@ -1369,7 +1366,6 @@ tarball from perl.org.
 %patch9 -p1
 %patch10 -p1
 %patch11 -p1
-%patch12 -p1
 %patch13 -p1
 %patch14 -p1
 %patch15 -p1
@@ -1580,7 +1576,6 @@ pushd %{build_archlib}/CORE/
 'Fedora Patch9: Fix find2perl to translate ? glob properly (RT#113054)' \
 'Fedora Patch10: Fix broken atof (RT#109318)' \
 'Fedora Patch11: Do not access freed memory when cloning thread 
(RT#111610)' \
-'Fedora Patch12: Match non-breakable space with /[\h]/ in ASCII mode 
(RT#114220)' \
 'Fedora Patch13: Clear $@ before "do" I/O error (RT#113730)' \
 'Fedora Patch14: Do not truncate syscall() return value to 32 bits 
(RT#113980)' \
 'Fedora Patch15: Override the Pod::Simple::parse_file (CPANRT#77530)' \
@@ -2734,6 +2729,11 @@ sed \
 
 # Old changelog entries are preserved in CVS.
 %changelog
+* Mon Nov 05 2012 Jitka Plesnikova  - 4:5.16.2-242
+- 5.16.2 bump (see
+  http://search.cpan.org/dist/perl-5.16.1/pod/perldelta.pod for release
+  notes)
+
 * Wed Oct 31 2012 Petr Pisar  - 4:5.16.1-241
 - Remove bundled podlators (bug #856516)
 
diff --git a/sources b/sources
index 1f2454b..a36ca00 100644
--- a/sources
+++ b/sources
@@ -2,4 +2,4 @@ aceea3db13a159cd5f7e5f2e3ad9534f  perl-5.8.0-libdir64.patch
 ad5d07285d6e4914384b43c9abc2bdba  filter-requires.sh
 1737a36154bb5bca781296794afc6791  perl.stp
 df28fe2c574e8807d0a803308c545dca  perl-example.stp
-bcc5136007177b0fe2b6fd739fb66b84  perl-5.16.1.tar.gz
+0e57f2d01d96471d9effc3fb43175e84  perl-5.16.2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Revamping the non responsive maintainer process

[Jóhann B. Guðmundsson]

On 11/05/2012 09:22 AM, Marcela Mašláňová wrote:
You are using your use-case for everyone. If you insist on automatic 
process, then the metric should work with more data. 


It's good that we elected FESCO to find out and decide which appropriate 
metric data should be used to determine that...


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

File perl-5.16.2.tar.gz uploaded to lookaside cache by jplesnik

[Jitka Plesnikova]

A file has been added to the lookaside cache for perl:

0e57f2d01d96471d9effc3fb43175e84  perl-5.16.2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Revamping the non responsive maintainer process

[Marcela Mašláňová]

On 11/02/2012 06:57 PM, "Jóhann B. Guðmundsson" wrote:

On 11/02/2012 04:56 PM, Kevin Fenzi wrote:

On Fri, 02 Nov 2012 16:44:06 +
"Jóhann B. Guðmundsson"  wrote:


On 11/02/2012 04:25 PM, Tom Lane wrote:

=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
 writes:

On 11/02/2012 03:32 PM, Matthew Miller wrote:

On Fri, Nov 02, 2012 at 03:12:56PM +, "Jóhann B.
Guðmundsson" wrote:

Dead/un-maintained packages need to be removed/reassigned at the
very *beginning* of an new development cycle so feature owners
and others working in the community are dealing with active and
actively maintained packages.

How exactly are you going to force maintainers who go missing to do
so at a prescheduled time?  Real life is seldom that convenient.

If at this point we dont have any process that can actively tell if a
maintainer is present and active within the project then we have
bigger fish to fry then the feature process...

If we have problem A and problem B, can't we work on both at the same
time? :)


Seriously it should not be anymore complex than monitoring last login
into the relevant infrastructure pieces to determine if the relevant
maintainer is active or not.

bash script + a cron job should suffice to achieve just that.

It's not at all that simple, I'm afraid.

How long since last activity do you consider someone 'inactive' ?

What if the packages that maintain simply don't need any changes?

What if they are on vacation?

What if they are active on package A, but not doing something on
package B that you wish they would?

I've long wanted to revamp our process.
I welcome concrete proposals to do so.



Surely if an individual has not logged into for several months into our
infrastructure he must be inactive no?

Bash script + a cron job that monitors login should suffice to check and
even email him asking him to confirm if he is active encase he has a low
maintenance component and only logs in when something is filed  ;)

JBG


No, he can own only one package and be an upstream of the package, 
therefore he will login only for update of the package.


You are using your use-case for everyone. If you insist on automatic 
process, then the metric should work with more data.


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

[Bug 855755] perl-X11-Protocol-Other-21 is available

[bugzilla]

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

Petr Šabata  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||psab...@redhat.com
   Assignee|robinlee.s...@gmail.com |psab...@redhat.com

--- Comment #3 from Petr Šabata  ---
I'm going to do the update...

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