Re: F17: FlightGear

[Gerry Reno]

On 09/11/2012 12:03 AM, Tomas Dabašinskas wrote:
> FlightGear 2.8.0


Opened bug:  https://bugzilla.redhat.com/show_bug.cgi?id=856053



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

[Test-Announce] Fedora 18 Alpha Release Candidate 2 (RC2) Available Now!

[Andre Robatino]

As per the Fedora 18 schedule [1], Fedora 18 Alpha Release Candidate 2
(RC2) is now available for testing. Content information, including
changes, can be found at
https://fedorahosted.org/rel-eng/ticket/5284#comment:19 . Please see the
following pages for download links (including delta ISOs) and testing
instructions. Normally dl.fedoraproject.org should provide the fastest
download, but download-ib01.fedoraproject.org is available as a mirror
(with an approximately 1 hour lag) in case of trouble. To use it, just
replace "dl" with "download-ib01" in the download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Ideally, all Alpha priority test cases for Installation [2], Base [3],
and Desktop [4] should pass in order to meet the Alpha Release Criteria
[5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the
test list [7].

Create Fedora 18 Alpha test compose (TC) and release candidate (RC)
https://fedorahosted.org/rel-eng/ticket/5284

Current Blocker and NTH bugs:
http://qa.fedoraproject.org/blockerbugs/current

F18 Alpha Blocker tracker bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752654

F18 Alpha Nice-To-Have tracker bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752662

[1] http://jreznik.fedorapeople.org/schedules/f-18/f-18-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Base_validation_testing
[4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[5] https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
[6] irc://irc.freenode.net/fedora-qa
[7] https://admin.fedoraproject.org/mailman/listinfo/test



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

Re: F17: FlightGear

[Tomas Dabašinskas]

- Original Message -
> FlightGear 2.8.0 has been released.
> 
> And it supports a lot more controllers.
> 
> Can we have FlightGear updated to 2.8.0 for F17?

Hi,
You should open a new bug 
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=FlightGear

Regards,
-- 
Tomas Dabašinskas | Engineering Content Services | Red Hat Asia Pacific
☎: +61(0)7 3514 8204 | ✉: to...@redhat.com | ☺: tomas | gpg 0x3B6C9366
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: upstream wants me to rename my package

[Doug Ledford]

On 9/9/2012 2:03 AM, Gary Gatling wrote:
> Hey guys,
> 
> I decided to ask if he would be willing to add an epoc tag as Ken
> suggested or be willing to become a maintainer or co-maintainer. I think
> he just continues to insist that rpm work in a way its not designed...
> (Have two versions of the same software thing on a box)

Point him to the MPI packaging guidelines.  They are nothing more than
all the things that have to be done in order for more than one copy of
the same software to be installed at the same time and coexist
peacefully.  Unless you have a dire need for it, it's a royal pain in
the ass.  And have him read the openmpi spec file too, it really
exemplifies how ugly this stuff gets.

--

Doug Ledford 




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

Re: [Test-Announce] Fedora 18 Alpha Release Candidate 1 (RC1) Available Now!

[Adam Williamson]

On 2012-09-10 17:13, Andre Robatino wrote:
As per the Fedora 18 schedule [1], Fedora 18 Alpha Release Candidate 
1

(RC1) is now available for testing. Content information, including
changes, can be found at
https://fedorahosted.org/rel-eng/ticket/5284#comment:16 . Please see 
the

following pages for download links (including delta ISOs) and testing
instructions. Normally dl.fedoraproject.org should provide the 
fastest
download, but download-ib01.fedoraproject.org is available as a 
mirror
(with an approximately 1 hour lag) in case of trouble. To use it, 
just

replace "dl" with "download-ib01" in the download URL.


Emergency announcement: RC1 DVD looks pretty much DOA, huge chunks of 
packages are missing from it again. We're not entirely sure why. I doubt 
you can get a usable install from it, though, by the looks of the 
package list. See https://bugzilla.redhat.com/show_bug.cgi?id=856036 . I 
don't know how netinst will behave, whether it'll pull the right 
packages or not.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide boot problems

[Adam Williamson]

On 2012-09-10 16:43, Stephen John Smoogen wrote:
On 10 September 2012 17:16, Lennart Poettering  
wrote:
On Mon, 10.09.12 15:51, Jesse Keating (jkeat...@j2solutions.net) 
wrote:



On 09/10/2012 02:27 PM, Kalev Lember wrote:
>Can't we just change the branching to a later date?

When we used to do that, we frequently had destabilizing changes
happening late in the development process, because there was no
other place to land them.


My suggestion of just letting everybody branch on their own, getting 
rid

of mass branching and gettind rid of the master branch would neatly
allow people to push their changes to any later distro they want...


I don't see how that can scale to the number of packages in Fedora. 
It

is going to be a combinatorics nightmare especially when a ton of
people don't work together and all have their own idea of the RIGHT
way to branch, land and build their own packages. It might work for a
scaled down OS-tree size distro.. but at 12000 packages.. and things
like "well you pushed this into X and now A..Z packages need to be
rebuilt against it."


It doesn't imply any change in policy, it just gives the packager the 
choice of when to branch for Branched+1. I don't think Lennart meant to 
imply that devs could choose to continue with unstable development in 
Branched - just that they could 'opt out' of having a Branched+1 branch 
until they actually needed one.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide boot problems

[Lennart Poettering]

On Mon, 10.09.12 17:43, Stephen John Smoogen (smo...@gmail.com) wrote:

> On 10 September 2012 17:16, Lennart Poettering  wrote:
> > On Mon, 10.09.12 15:51, Jesse Keating (jkeat...@j2solutions.net) wrote:
> >
> >> On 09/10/2012 02:27 PM, Kalev Lember wrote:
> >> >Can't we just change the branching to a later date?
> >>
> >> When we used to do that, we frequently had destabilizing changes
> >> happening late in the development process, because there was no
> >> other place to land them.
> >
> > My suggestion of just letting everybody branch on their own, getting rid
> > of mass branching and gettind rid of the master branch would neatly
> > allow people to push their changes to any later distro they want...
> 
> I don't see how that can scale to the number of packages in Fedora. It
> is going to be a combinatorics nightmare especially when a ton of

Nightmare? how so? where would it matter?

> people don't work together and all have their own idea of the RIGHT
> way to branch, land and build their own packages. It might work for a
> scaled down OS-tree size distro.. but at 12000 packages.. and things
> like "well you pushed this into X and now A..Z packages need to be
> rebuilt against it."

I don't follow... what has this to do with whether the master branch
exists?

Note that if mass rebuilds need to happen then of course this would mean
that the respective branch in the respective package would have to
create implicitly as part of the rebuild. But that shouldn't be too
hard...

Lennart

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

[Test-Announce] Fedora 18 Alpha Release Candidate 1 (RC1) Available Now!

[Andre Robatino]

As per the Fedora 18 schedule [1], Fedora 18 Alpha Release Candidate 1
(RC1) is now available for testing. Content information, including
changes, can be found at
https://fedorahosted.org/rel-eng/ticket/5284#comment:16 . Please see the
following pages for download links (including delta ISOs) and testing
instructions. Normally dl.fedoraproject.org should provide the fastest
download, but download-ib01.fedoraproject.org is available as a mirror
(with an approximately 1 hour lag) in case of trouble. To use it, just
replace "dl" with "download-ib01" in the download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Ideally, all Alpha priority test cases for Installation [2], Base [3],
and Desktop [4] should pass in order to meet the Alpha Release Criteria
[5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the
test list [7].

Create Fedora 18 Alpha test compose (TC) and release candidate (RC)
https://fedorahosted.org/rel-eng/ticket/5284

Current Blocker and NTH bugs:
http://qa.fedoraproject.org/blockerbugs/current

F18 Alpha Blocker tracker bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752654

F18 Alpha Nice-To-Have tracker bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752662

[1] http://jreznik.fedorapeople.org/schedules/f-18/f-18-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Base_validation_testing
[4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[5] https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
[6] irc://irc.freenode.net/fedora-qa
[7] https://admin.fedoraproject.org/mailman/listinfo/test



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

F17: FlightGear

[Gerry Reno]

FlightGear 2.8.0 has been released.

And it supports a lot more controllers.

Can we have FlightGear updated to 2.8.0 for F17?


Thanks.


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

Re: Rawhide boot problems

[Stephen John Smoogen]

On 10 September 2012 17:16, Lennart Poettering  wrote:
> On Mon, 10.09.12 15:51, Jesse Keating (jkeat...@j2solutions.net) wrote:
>
>> On 09/10/2012 02:27 PM, Kalev Lember wrote:
>> >Can't we just change the branching to a later date?
>>
>> When we used to do that, we frequently had destabilizing changes
>> happening late in the development process, because there was no
>> other place to land them.
>
> My suggestion of just letting everybody branch on their own, getting rid
> of mass branching and gettind rid of the master branch would neatly
> allow people to push their changes to any later distro they want...

I don't see how that can scale to the number of packages in Fedora. It
is going to be a combinatorics nightmare especially when a ton of
people don't work together and all have their own idea of the RIGHT
way to branch, land and build their own packages. It might work for a
scaled down OS-tree size distro.. but at 12000 packages.. and things
like "well you pushed this into X and now A..Z packages need to be
rebuilt against it."



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

[Lennart Poettering]

On Mon, 10.09.12 15:51, Jesse Keating (jkeat...@j2solutions.net) wrote:

> On 09/10/2012 02:27 PM, Kalev Lember wrote:
> >Can't we just change the branching to a later date?
> 
> When we used to do that, we frequently had destabilizing changes
> happening late in the development process, because there was no
> other place to land them.

My suggestion of just letting everybody branch on their own, getting rid
of mass branching and gettind rid of the master branch would neatly
allow people to push their changes to any later distro they want...

Lennart

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

Re: Rawhide boot problems

[Adam Williamson]

On 2012-09-10 15:22, Lennart Poettering wrote:

On Mon, 10.09.12 15:14, Adam Williamson (awill...@redhat.com) wrote:


On 2012-09-10 15:03, Kalev Lember wrote:

>
>The hard reality is that branched and rawhide are getting pretty 
much

>the same set of packages currently. It's a very nice view to let
>development go ahead in rawhide, and to stabilize branched. But we
>only
>have so many developers and everyone is focusing on branched, 
leaving

>rawhide broken.

I don't think that's true, actually. There certainly are devs who
take advantage of the model. Lennart wrote that 'everyone' has to
for it to be valuable, but that isn't true at all.

I can recall at least two notifications to the list about updates to
major libraries happening in Rawhide that aren't happening in F18.
One of them is boost: it's up a whole major version in Rawhide
compared to F18. That's exactly how the policy is supposed to work.
I forget exactly what the other was, but I know there was at least
one more.

Another example from today - the Postgresql maintainer mailed the
list to say that now F18 is delayed he'll be putting the new version
in F18, but until then, he was planning to have the newer version in
Rawhide only - again, exactly how the policy is supposed to work.

Those are just examples from memory, not even looking through the
archives.


What I am proposing is to get rid of the "master" branch, so that 
people
can just branch off F-19 as early and as late as they want, and they 
do

it from F-18 on their own. The mass branching would go away this way,
(might only be a side-effect of distro-wide rebuilds).

This way, Lennart would just maintain systemd in the F-18 branch. And
then in a month or two he would branch F-19 off this branch. And then
when he is ready to open F-20 he would branch it off F-19. And so
on. But the time where Lennart decides to branch off is up to him.

In your example above the boost maintainer otoh could branch off F-19
much earlier than Lennart branches off systemd. Both packagers would
have full flexibility when to branch off.

This would give packagers much more flexibility about branching and
would also simplify our model as the master branch would just go
away... One branch less that can be confused is a win for
everybody.


I don't see a problem with that, but then I'm just the monkey :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide boot problems

[Lennart Poettering]

On Mon, 10.09.12 15:14, Adam Williamson (awill...@redhat.com) wrote:

> On 2012-09-10 15:03, Kalev Lember wrote:
> 
> >
> >The hard reality is that branched and rawhide are getting pretty much
> >the same set of packages currently. It's a very nice view to let
> >development go ahead in rawhide, and to stabilize branched. But we
> >only
> >have so many developers and everyone is focusing on branched, leaving
> >rawhide broken.
> 
> I don't think that's true, actually. There certainly are devs who
> take advantage of the model. Lennart wrote that 'everyone' has to
> for it to be valuable, but that isn't true at all.
> 
> I can recall at least two notifications to the list about updates to
> major libraries happening in Rawhide that aren't happening in F18.
> One of them is boost: it's up a whole major version in Rawhide
> compared to F18. That's exactly how the policy is supposed to work.
> I forget exactly what the other was, but I know there was at least
> one more.
> 
> Another example from today - the Postgresql maintainer mailed the
> list to say that now F18 is delayed he'll be putting the new version
> in F18, but until then, he was planning to have the newer version in
> Rawhide only - again, exactly how the policy is supposed to work.
> 
> Those are just examples from memory, not even looking through the
> archives.

What I am proposing is to get rid of the "master" branch, so that people
can just branch off F-19 as early and as late as they want, and they do
it from F-18 on their own. The mass branching would go away this way,
(might only be a side-effect of distro-wide rebuilds).

This way, Lennart would just maintain systemd in the F-18 branch. And
then in a month or two he would branch F-19 off this branch. And then
when he is ready to open F-20 he would branch it off F-19. And so
on. But the time where Lennart decides to branch off is up to him.

In your example above the boost maintainer otoh could branch off F-19
much earlier than Lennart branches off systemd. Both packagers would
have full flexibility when to branch off.

This would give packagers much more flexibility about branching and
would also simplify our model as the master branch would just go
away... One branch less that can be confused is a win for
everybody.

Lennart

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

Re: Rawhide boot problems

[Adam Williamson]

On 2012-09-10 15:03, Kalev Lember wrote:



The hard reality is that branched and rawhide are getting pretty much
the same set of packages currently. It's a very nice view to let
development go ahead in rawhide, and to stabilize branched. But we 
only

have so many developers and everyone is focusing on branched, leaving
rawhide broken.


I don't think that's true, actually. There certainly are devs who take 
advantage of the model. Lennart wrote that 'everyone' has to for it to 
be valuable, but that isn't true at all.


I can recall at least two notifications to the list about updates to 
major libraries happening in Rawhide that aren't happening in F18. One 
of them is boost: it's up a whole major version in Rawhide compared to 
F18. That's exactly how the policy is supposed to work. I forget exactly 
what the other was, but I know there was at least one more.


Another example from today - the Postgresql maintainer mailed the list 
to say that now F18 is delayed he'll be putting the new version in F18, 
but until then, he was planning to have the newer version in Rawhide 
only - again, exactly how the policy is supposed to work.


Those are just examples from memory, not even looking through the 
archives.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide boot problems

[Kalev Lember]

On 09/10/2012 11:44 PM, Bruno Wolff III wrote:
> On Mon, Sep 10, 2012 at 23:27:43 +0200,
>   Kalev Lember  wrote:
>>
>> Can't we just change the branching to a later date?
> 
> Branching later results in rawhide being frozen during the alpha freeze
> which breaks things for people doing development.

It wouldn't necessarily mean that rawhide has to be completely frozen.
We could still have separate stable and updates-testing repos, so that
updates-testing can continue unfrozen during the Alpha and Beta freezes.

The exact same setup as F18 currently has, with Bodhi and separate f18
and f18-updates-testing would still be possible. Just no split between
rawhide and f18.


> (Note that by alpha people really should be stablizing things and we
> really don't want disruptive development going on in branched at that
> time.)

The hard reality is that branched and rawhide are getting pretty much
the same set of packages currently. It's a very nice view to let
development go ahead in rawhide, and to stabilize branched. But we only
have so many developers and everyone is focusing on branched, leaving
rawhide broken.

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

Re: Rawhide boot problems

[Bruno Wolff III]

On Mon, Sep 10, 2012 at 23:27:43 +0200,
  Kalev Lember  wrote:


Can't we just change the branching to a later date?


Branching later results in rawhide being frozen during the alpha freeze 
which breaks things for people doing development. (Note that by alpha 
people really should be stablizing things and we really don't want 
disruptive development going on in branched at that time.)

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

Re: Rawhide boot problems

[Kalev Lember]

On 09/10/2012 10:30 PM, Lennart Poettering wrote:
> Anway, I still believe that the default approach to doing package 
> development should be to focus on F18 as long as it isn't released, 
> and only open F19 for a packge if the packager decides he is ready 
> to. Right now we have the opposite where a package immediately is 
> branched twice and packagers then have to make sure nobody uses the 
> newer branch yet.
> 
> So yeah, I do acknowledge that both modes of working make sense, I 
> just believe the default approach should be one where focus is on 
> stabilizing things, not on developing new stuff all the time.

This is my view as well. Having two development releases in parallel is
confusing for both package maintainers and testers -- everybody should
really be focusing on the upcoming F18 release, but instead people are
installing rawhide as well.

We just don't have the resources to do two parallel development distros
at a time. Instead, what we are doing now is splitting the tester base
between F18 and rawhide, and this makes F18 quality go down. And also
gives rawhide a bad name.

Can't we just change the branching to a later date?

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

Re: F-18 Branched report: 20120907 changes

[David Timms]

On 08/09/12 11:50, Kevin Fenzi wrote:
> Well, if you want to look, or anyone else wishes to take up the 
> gauntlet:
> 
> http://git.fedorahosted.org/cgit/mash/tree/utils/spam-o-matic
Thanks for the link. Anyone see merit in these ideas ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide boot problems

[Lennart Poettering]

On Mon, 10.09.12 14:09, Bill Nottingham (nott...@redhat.com) wrote:

> Matthias Clasen (mcla...@redhat.com) said: 
> > On Fri, 2012-09-07 at 11:54 -0700, Jesse Keating wrote:
> > 
> > > Fedora 18 is basically closed for new feature work, and instead the 
> > > focus needs to be on integration of the existing feature set and 
> > > bugfixes.  But as you state there is a large amount of time before F18 
> > > releases, which means new feature work would have to stall out for 
> > > months.  Instead, new feature work can begin for F19 and get ahead of 
> > > the game.  That's why F18 and F19 are divergent.  That's why we went 
> > > from a single line of development to two.
> > 
> > But we are not doing two lines of development in systemd or GNOME or
> > other upstream projects. So, why again should we build the same stuff
> > twice ? I personally just don't have the time.
> 
> Honestly, the problem here doesn't really come from a model of building
> for both, or only building for branched, as both are valid strategies
> for a maintainer to take.
> 
> The problem came from a well-intentioned packager who happened to
> choose one strategy when applying a fix, when the maintainers prefer the
> other. I'm not sure how to avoid this other than having each package
> speficy which it prefers (kind of messy) vs. mandating a particular style.

To deal with this I added a small message to the systemd .spec file that
explains this. I do hope that people will actually read it before
commiting things.

Anway, I still believe that the default approach to doing package
development should be to focus on F18 as long as it isn't released, and
only open F19 for a packge if the packager decides he is ready to. Right
now we have the opposite where a package immediately is branched twice
and packagers then have to make sure nobody uses the newer branch yet.

So yeah, I do acknowledge that both modes of working make sense, I just
believe the default approach should be one where focus is on stabilizing
things, not on developing new stuff all the time.

Lennart

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

Re: GNOME 2.5.92 Packages

[Adam Williamson]

On 2012-09-10 6:10, Richard Hughes wrote:

Same rules apply for any packages that want to get rolled into the
2.5.92 update: Please add the builds to the spreadsheet and they will
get rolled up into the mega-update.

The spreadsheet URL is:

https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc&pli=1#gid=0

2.5.90 is in stable now


No, it isn't. Stable is _still_ frozen, thanks to the mega-slip, so 
it's pending for stable. It won't be promoted until the freeze is 
lifted.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PostgreSQL 9.2 for F18?

[Bruno Wolff III]

On Mon, Sep 10, 2012 at 12:31:33 -0400,
  Tom Lane  wrote:

Bruno Wolff III  writes:

On Mon, Sep 10, 2012 at 10:24:40 -0400,
   Tom Lane  wrote:

PG 9.2 is now released, and F18 isn't beta yet.  So I'd like to push it
into F18 --- will anyone help test?



Yeah!



I'll definitely do some testing. My personal web server is running on F18
with updates-testing enabled. Most of the testing will be running simple
queries generated by web requests.


Filed at https://admin.fedoraproject.org/updates/postgresql-9.2.0-1.fc18

regards, tom lane


On F18 I did the package update and then used pg_upgrade and things worked 
as expected. I then tried out using security_barrier for a view I use 
to block access to some columns depending on other columns in the same row 
and that didn't seem to cause any problems (once I typed it correctly). I 
couldn't tell if there was a noticeable performance hit over the network.


I also did an upgrade on an F19 system, but the testing there was pretty 
minimal. (I use it for a wiki that isn't easy to access remotely.) But 
the service worked (service was up and psql connected) after doing a database 
upgrade.


So no bad news so far.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide boot problems

[Panu Matilainen]

On 09/10/2012 08:35 PM, Matthias Clasen wrote:

On Fri, 2012-09-07 at 11:54 -0700, Jesse Keating wrote:


Fedora 18 is basically closed for new feature work, and instead the
focus needs to be on integration of the existing feature set and
bugfixes.  But as you state there is a large amount of time before F18
releases, which means new feature work would have to stall out for
months.  Instead, new feature work can begin for F19 and get ahead of
the game.  That's why F18 and F19 are divergent.  That's why we went
from a single line of development to two.


But we are not doing two lines of development in systemd or GNOME or
other upstream projects. So, why again should we build the same stuff
twice ? I personally just don't have the time.


Well the theory is, all major development should've already landed in 
rawhide before the time of the mass-branch. When that happens the 
current setup works smooth as peaches. But rare upstream projects march 
to Fedora schedules, so you either delay feature/version X to the next 
Fedora version, introducing it in rawhide right after the mass-branch. 
Or fight with the branching. And because everybody wants to squeeze in 
the latest XYZ to this version already so... For example GNOME is AFAICT 
some two months off the "perfect" alignment.


Me thinks flexibility with the branching-point would help: branching 
before alpha is far too early for many projects, for others its 
absolutely necessary. It all depends on what happens to be going on with 
a given package / package set on a given cycle, one size fits almost 
everybody poorly.


In the "squeeze" cycles, what I always end up missing most is having 
rawhide and "branched" to share the same git (master) branch, but 
different builds (as you never know what *else* might change on rawhide 
- binary package inheritance doesn't work well either way) deep in to 
the release cycle (at least up until beta). Of course syncing from 
rawhide -> branched is no longer root-canal painful with git, merely 
tedious, but tedious enough that many packagers dont bother, so we end 
up having this (IMO) twisted situation where active development goes on 
in a branch and master lags behind. And inevitably bits and patches fall 
through the cracks when active working moves back to master. Seen my 
share of it.


- Panu -

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

Re: Rawhide boot problems

[Bill Nottingham]

Matthias Clasen (mcla...@redhat.com) said: 
> On Fri, 2012-09-07 at 11:54 -0700, Jesse Keating wrote:
> 
> > Fedora 18 is basically closed for new feature work, and instead the 
> > focus needs to be on integration of the existing feature set and 
> > bugfixes.  But as you state there is a large amount of time before F18 
> > releases, which means new feature work would have to stall out for 
> > months.  Instead, new feature work can begin for F19 and get ahead of 
> > the game.  That's why F18 and F19 are divergent.  That's why we went 
> > from a single line of development to two.
> 
> But we are not doing two lines of development in systemd or GNOME or
> other upstream projects. So, why again should we build the same stuff
> twice ? I personally just don't have the time.

Honestly, the problem here doesn't really come from a model of building
for both, or only building for branched, as both are valid strategies
for a maintainer to take.

The problem came from a well-intentioned packager who happened to
choose one strategy when applying a fix, when the maintainers prefer the
other. I'm not sure how to avoid this other than having each package
speficy which it prefers (kind of messy) vs. mandating a particular style.

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

Re: Rawhide boot problems

[Matthias Clasen]

On Fri, 2012-09-07 at 11:54 -0700, Jesse Keating wrote:

> Fedora 18 is basically closed for new feature work, and instead the 
> focus needs to be on integration of the existing feature set and 
> bugfixes.  But as you state there is a large amount of time before F18 
> releases, which means new feature work would have to stall out for 
> months.  Instead, new feature work can begin for F19 and get ahead of 
> the game.  That's why F18 and F19 are divergent.  That's why we went 
> from a single line of development to two.

But we are not doing two lines of development in systemd or GNOME or
other upstream projects. So, why again should we build the same stuff
twice ? I personally just don't have the time.

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

Re: PostgreSQL 9.2 for F18?

[Michał Piotrowski]

2012/9/10 Bruno Wolff III :
> On Mon, Sep 10, 2012 at 17:58:32 +0200,
>   Michał Piotrowski  wrote:
>>
>>
>> I updated my test rawhide VM and now it's broken - it boots to target
>> Basic System.
>
>
> I think that depends on the version of systemd used in the initramfs. When I
> saw that problem previously I was able to boot with an older kernel.
> However, I haven't rebooted my rawhide system for about a week, so there
> might be a new issue where rebooting an older kernel doesn't fix the
> problem.

Indeed, an old kernel works. Thanks.


-- 
Best regards,
Michal

http://eventhorizon.pl/
https://getactive.pl/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PostgreSQL 9.2 for F18?

[Bruno Wolff III]

On Mon, Sep 10, 2012 at 17:58:32 +0200,
  Michał Piotrowski  wrote:


I updated my test rawhide VM and now it's broken - it boots to target
Basic System.


I think that depends on the version of systemd used in the initramfs. When 
I saw that problem previously I was able to boot with an older kernel.
However, I haven't rebooted my rawhide system for about a week, so there 
might be a new issue where rebooting an older kernel doesn't fix the problem.

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

Re: PostgreSQL 9.2 for F18?

[Tom Lane]

Bruno Wolff III  writes:
> On Mon, Sep 10, 2012 at 10:24:40 -0400,
>Tom Lane  wrote:
>> PG 9.2 is now released, and F18 isn't beta yet.  So I'd like to push it
>> into F18 --- will anyone help test?

> Yeah!

> I'll definitely do some testing. My personal web server is running on F18 
> with updates-testing enabled. Most of the testing will be running simple 
> queries generated by web requests.

Filed at https://admin.fedoraproject.org/updates/postgresql-9.2.0-1.fc18

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GNOME 2.5.92 Packages

[Richard Hughes]

On 10 September 2012 15:00, Conan Kudo (ニール・ゴンパ)  wrote:
> Don't you mean 3.5.92? I didn't think we were reverting to a version of
> GNOME from 2004...

Gahh, Monday Yup, 3.5.* :)

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

[Bug 855753] perl-Rose-DB-Object-0.800 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA

--- Comment #3 from Fedora Update System  ---
Package perl-Rose-DB-Object-0.800-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing
perl-Rose-DB-Object-0.800-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-13709/perl-Rose-DB-Object-0.800-1.fc18
then log in and leave karma (feedback).

-- 
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: rawhide report: 20120909 changes

[Adam Jackson]

On 9/10/12 4:21 AM, Tomáš Smetana wrote:

On Sun, 9 Sep 2012 12:39:46 +
Fedora Rawhide Report  wrote:


[freeglut]
freeglut-devel-2.8.0-7.fc19.i686 requires libGLU-devel
freeglut-devel-2.8.0-7.fc19.x86_64 requires libGLU-devel


Hello,
  freeglut is mine and I wonder whether the new mesa-libGLU package misses the
"Provides: libGLU-devel" on purpose or if it was just an omission.


Not intentional.  Fixed in:

* Mon Sep 10 2012 Dave Airlie  9.0-0.2
- add back libGLU provides for now

- ajax

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

Re: PostgreSQL 9.2 for F18?

[Michał Piotrowski]

2012/9/10 Michał Piotrowski :
> Hi,
>
> 2012/9/10 Tom Lane :
>> Bruno Wolff III  writes:
>>>Michał Piotrowski  wrote:
 Is there any chance that 9.2 will be available for F18?
>>
>>> I think for 9.1 Tom pushed it just before beta when a few of us promised
>>> to do some testing pronmptly.
>>
>>> So if 9.2 gets released before f18 beta there is probably a good change it 
>>> will
>>> make it in F18. Otherwise it probably won't.
>>
>> PG 9.2 is now released, and F18 isn't beta yet.  So I'd like to push it
>> into F18 --- will anyone help test?
>>
>> regards, tom lane
>
> Splendidly :)
>
> I can help you tomorrow.
>

I updated my test rawhide VM and now it's broken - it boots to target
Basic System.

Any ideas?

-- 
Best regards,
Michal

http://eventhorizon.pl/
https://getactive.pl/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PostgreSQL 9.2 for F18?

[Bruno Wolff III]

On Mon, Sep 10, 2012 at 10:24:40 -0400,
  Tom Lane  wrote:

PG 9.2 is now released, and F18 isn't beta yet.  So I'd like to push it
into F18 --- will anyone help test?


Yeah!

I'll definitely do some testing. My personal web server is running on F18 
with updates-testing enabled. Most of the testing will be running simple 
queries generated by web requests.

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

Recent ABRT changes in F-17

[Jerry James]

Evolution crashed on takeoff this morning.  I tried to report the bug
with ABRT, and was surprised when it automatically contacted the
retrace server without asking me what to do first.  I've already got
huge piles of debuginfo packages installed, so it would probably have
been fine to generate the backtrace locally.  Well, okay, I'll watch
the retrace server run:

--- Running report_uReport ---
(exited with 0)

--- Running analyze_RetraceServer ---
Querying server settings
Preparing an archive to upload
Uploading 722960 bytes
Upload successful
Retrace job started
Initializing virtual root
Initializing virtual root
Initializing virtual root
Initializing virtual root
Initializing virtual root
Initializing virtual root
Initializing virtual root
Retrace job failed
Retrace failed. Try again later and if the problem persists report
this issue please.
Analyzing crash data OK
Initializing virtual root Error 25:
=== OUTPUT ===
INFO: mock.py version 1.1.18 starting...
State Changed: init plugins
INFO: selinux enabled
State Changed: start
State Changed: lock buildroot
State Changed: clean
State Changed: unlock buildroot
State Changed: init
State Changed: lock buildroot
Mock Version: 1.1.18
INFO: Mock Version: 1.1.18
INFO: calling preinit hooks
State Changed: running yum
ERROR: Command failed:
 # ['/usr/bin/yum', '--installroot', '/var/lib/mock/154164959/root/',
'--skip-broken', 'install', 'evolution-3.4.4-1.fc17',
'GConf2-debuginfo-3.2.5-1.fc17.x86_64',
'PackageKit-debuginfo-0.7.5-1.fc17.x86_64',
'PackageKit-gtk3-module-0.7.5-1.fc17.x86_64',
'adwaita-gtk3-theme-3.4.2-1.fc17.x86_64',
'atk-debuginfo-2.4.0-1.fc17.x86_64',
'cairo-debuginfo-1.10.2-7.fc17.x86_64',
'cyrus-sasl-debuginfo-2.1.23-31.fc17.x86_64',
'db4-debuginfo-4.8.30-10.fc17.x86_64',
'1:dbus-debuginfo-1.4.10-4.fc17.x86_64',
'dbus-glib-debuginfo-0.98-2.fc17.x86_64',
'1:dbus-libs-1.4.10-4.fc17.x86_64', 'dconf-0.12.1-1.fc17.x86_64',
'dconf-debuginfo-0.12.1-1.fc17.x86_64',
'e2fsprogs-debuginfo-1.42.3-2.fc17.x86_64',
'1:enchant-debuginfo-1.6.0-4.fc17.x86_64',
'evolution-3.4.4-1.fc17.x86_64',
'evolution-NetworkManager-3.4.4-1.fc17.x86_64',
'evolution-bogofilter-3.4.4-1.fc17.x86_64',
'evolution-data-server-debuginfo-3.4.4-2.fc17.x86_64',
'evolution-debuginfo-3.4.4-1.fc17.x86_64',
'evolution-devel-3.4.4-1.fc17.x86_64',
'evolution-perl-3.4.4-1.fc17.x86_64',
'evolution-pst-3.4.4-1.fc17.x86_64',
'evolution-spamassassin-3.4.4-1.fc17.x86_64',
'expat-2.1.0-1.fc17.x86_64', 'expat-debuginfo-2.1.0-1.fc17.x86_64',
'fontconfig-debuginfo-2.8.0-7.fc17.x86_64',
'freetype-debuginfo-2.4.8-3.fc17.x86_64',
'gcc-base-debuginfo-4.7.0-5.fc17.x86_64',
'gdk-pixbuf2-debuginfo-2.26.1-1.fc17.x86_64',
'glib2-debuginfo-2.32.4-1.fc17.x86_64', 'glibc-2.15-56.fc17.x86_64',
'glibc-debuginfo-2.15-56.fc17.x86_64', 'desktop-backgrounds-gnome',
'gnome-desktop3-debuginfo-3.4.2-1.fc17.x86_64',
'desktop-backgrounds-gnome',
'gnome-themes-standard-debuginfo-3.4.2-1.fc17.x86_64',
'gtk3-debuginfo-3.4.4-1.fc17.x86_64',
'gtkhtml3-debuginfo-4.4.4-1.fc17.x86_64', 'gvfs-1.12.3-1.fc17.x86_64',
'gvfs-debuginfo-1.12.3-1.fc17.x86_64',
'keyutils-debuginfo-1.5.5-2.fc17.x86_64',
'keyutils-libs-1.5.5-2.fc17.x86_64',
'krb5-debuginfo-1.10.2-6.fc17.x86_64',
'krb5-libs-1.10.2-6.fc17.x86_64',
'libICE-debuginfo-1.0.8-1.fc17.x86_64',
'libSM-debuginfo-1.2.1-1.fc17.x86_64',
'libX11-debuginfo-1.5.0-2.fc17.x86_64',
'libXau-debuginfo-1.0.6-3.fc17.x86_64',
'libXcomposite-debuginfo-0.4.3-3.fc17.x86_64',
'libXcursor-debuginfo-1.1.13-1.fc17.x86_64',
'libXdamage-debuginfo-1.1.3-3.fc17.x86_64',
'libXext-debuginfo-1.3.1-1.fc17.x86_64',
'libXfixes-debuginfo-5.0-2.fc17.x86_64',
'libXi-debuginfo-1.6.1-1.fc17.x86_64',
'libXinerama-debuginfo-1.1.2-1.fc17.x86_64',
'libXrandr-debuginfo-1.3.1-3.fc17.x86_64',
'libXrender-0.9.7-1.fc17.x86_64',
'libXrender-debuginfo-0.9.7-1.fc17.x86_64',
'libbluray-debuginfo-0.2.2-1.fc17.x86_64',
'libcanberra-debuginfo-0.28-6.fc17.x86_64',
'libcanberra-gtk3-0.28-6.fc17.x86_64',
'libcom_err-1.42.3-2.fc17.x86_64',
'libcroco-debuginfo-0.6.5-1.fc17.x86_64',
'libffi-debuginfo-3.0.10-2.fc17.x86_64', 'libgcc-4.7.0-5.fc17.x86_64',
'libgcrypt-1.5.0-3.fc17.x86_64',
'libgcrypt-debuginfo-1.5.0-3.fc17.x86_64',
'libgnome-keyring-debuginfo-3.4.1-2.fc17.x86_64',
'libgpg-error-1.10-2.fc17.x86_64',
'libgpg-error-debuginfo-1.10-2.fc17.x86_64',
'libical-debuginfo-0.48-2.fc17.x86_64',
'2:libogg-debuginfo-1.3.0-1.fc17.x86_64',
'2:libpng-debuginfo-1.5.10-1.fc17.x86_64',
'librsvg2-debuginfo-2.36.1-1.fc17.x86_64',
'libselinux-debuginfo-2.1.10-3.fc17.x86_64',
'libsoup-debuginfo-2.38.1-3.fc17.x86_64',
'libtdb-debuginfo-1.2.10-15.fc17.x86_64',
'libtool-debuginfo-2.4.2-3.fc17.x86_64',
'1:libvorbis-debuginfo-1.3.3-1.fc17.x86_64',
'libxcb-debuginfo-1.8.1-1.fc17.x86_64',
'libxml2-debuginfo-2.7.8-7.fc17.x86_64',
'nspr-debuginfo-4.9.1-2.fc17.x86_64',
'nss-debuginfo-3.13.5-1.fc17.x86_64',
'nss-softokn-debuginfo-3.13.5-1.fc17.x86_64',
'nss-util-debuginfo-3.13.5-1.fc17.x86_64',
'1:openssl-1.0.0j-2.fc17.x86_64',
'1:openssl-debuginfo-1.0.0j-2.fc17.x86_64'

Re: PostgreSQL 9.2 for F18?

[Michał Piotrowski]

Hi,

2012/9/10 Tom Lane :
> Bruno Wolff III  writes:
>>Michał Piotrowski  wrote:
>>> Is there any chance that 9.2 will be available for F18?
>
>> I think for 9.1 Tom pushed it just before beta when a few of us promised
>> to do some testing pronmptly.
>
>> So if 9.2 gets released before f18 beta there is probably a good change it 
>> will
>> make it in F18. Otherwise it probably won't.
>
> PG 9.2 is now released, and F18 isn't beta yet.  So I'd like to push it
> into F18 --- will anyone help test?
>
> regards, tom lane

Splendidly :)

I can help you tomorrow.

-- 
Best regards,
Michal

http://eventhorizon.pl/
https://getactive.pl/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PostgreSQL 9.2 for F18?

[Tom Lane]

Bruno Wolff III  writes:
>Michał Piotrowski  wrote:
>> Is there any chance that 9.2 will be available for F18?

> I think for 9.1 Tom pushed it just before beta when a few of us promised 
> to do some testing pronmptly.

> So if 9.2 gets released before f18 beta there is probably a good change it 
> will
> make it in F18. Otherwise it probably won't.

PG 9.2 is now released, and F18 isn't beta yet.  So I'd like to push it
into F18 --- will anyone help test?

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Rose-DB-Object/f18] Update to 0.800

[Bill Pemberton]

Summary of changes:

  84fa1af... Update to 0.800 (*)

(*) 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

[Bug 851721] Review Request: perl-Net-Nessus-XMLRPC - Communicate with Nessus scanner(v4.2+) via XMLRPC

[bugzilla]

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

--- Comment #2 from Olivier Bilodeau  ---
Updates:

- whitespace cleanup
- global instead of define
- removed useless Provides:...
- Source URL now uses real_name global

I plan to propose this to EPEL5 also.

Successful koji build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4472101

The SPEC and SRPM URLs are still valid.

Let me know about anything else I can do to move this forward.

-- 
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 852503] Review Request: perl-Net-Radius - Object-oriented Perl interface to RADIUS

[bugzilla]

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

--- Comment #2 from Olivier Bilodeau  ---
Changes to package based on comments:

- whitespace cleanup
- global instead of define
- removed duplicated Provides:...
- Source URL now uses real_name global

Notes:

I do plan to propose this in EPEL5 so I haven't implemented the defattr and "rm
-rf" changes. 

Successful koji build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4472073

The SPEC and SRPM URLs are still valid.

Let me know about anything else I can do to move this forward.

-- 
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: GNOME 2.5.92 Packages

[ニール・ゴンパ]

On Mon, Sep 10, 2012 at 8:10 AM, Richard Hughes  wrote:

> Same rules apply for any packages that want to get rolled into the
> 2.5.92 update: Please add the builds to the spreadsheet and they will
> get rolled up into the mega-update.
>
> The spreadsheet URL is:
>
> https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc&pli=1#gid=0
>
> 2.5.90 is in stable now, 2.5.91 is in updates-testing. Yell if you
> have any questions. Thanks.
>
> Richard.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


Don't you mean 3.5.92? I didn't think we were reverting to a version of
GNOME from 2004...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

GNOME 2.5.92 Packages

[Richard Hughes]

Same rules apply for any packages that want to get rolled into the
2.5.92 update: Please add the builds to the spreadsheet and they will
get rolled up into the mega-update.

The spreadsheet URL is:
https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc&pli=1#gid=0

2.5.90 is in stable now, 2.5.91 is in updates-testing. Yell if you
have any questions. Thanks.

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

Re: rawhide report: 20120909 changes

[Tomáš Smetana]

On Mon, 10 Sep 2012 08:30:03 -0400
Rich Mattes  wrote:

> Looks like it was also reported in its own bug (
> https://bugzilla.redhat.com/show_bug.cgi?id=855536).  There's a new build
> at (http://koji.fedoraproject.org/koji/buildinfo?buildID=353410) which has
> the libGLU{,-devel} provides.

...which answers my question. I should have searched the Bugzilla first.

Thanks for the link.

Regards,
-- 
Tomáš Smetana
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20120909 changes

[Rich Mattes]

On Mon, Sep 10, 2012 at 7:31 AM, Paul Howarth  wrote:

>
> mesa-libGLU is now an independent package (i.e. not a sub-package of
> mesa), with a sub-package of mesa-libGLU-devel. However, these new packages
> are missing the provides for libGLU and libGLU-devel that the original
> sub-packages of mesa had. I commented on the mesa-libGLU review ticket (
> http://bugzilla.redhat.com/**854377 )
> to that effect and hopefully it will be resolved in due course.
>

Looks like it was also reported in its own bug (
https://bugzilla.redhat.com/show_bug.cgi?id=855536).  There's a new build
at (http://koji.fedoraproject.org/koji/buildinfo?buildID=353410) which has
the libGLU{,-devel} provides.

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

rawhide report: 20120910 changes

[Fedora Rawhide Report]

Compose started at Mon Sep 10 08:15:11 UTC 2012

Broken deps for x86_64
--
[ClanLib]
ClanLib-devel-2.3.6-3.fc18.i686 requires libGLU-devel
ClanLib-devel-2.3.6-3.fc18.x86_64 requires libGLU-devel
[ClanLib06]
ClanLib06-devel-0.6.5-24.fc18.i686 requires libGLU-devel
ClanLib06-devel-0.6.5-24.fc18.x86_64 requires libGLU-devel
[ClanLib1]
ClanLib1-devel-1.0.0-11.fc18.i686 requires libGLU-devel
ClanLib1-devel-1.0.0-11.fc18.x86_64 requires libGLU-devel
[Coin2]
Coin2-devel-2.5.0-16.fc18.i686 requires libGLU-devel
Coin2-devel-2.5.0-16.fc18.x86_64 requires libGLU-devel
[DevIL]
DevIL-ILUT-devel-1.7.8-10.fc18.i686 requires libGLU-devel
DevIL-ILUT-devel-1.7.8-10.fc18.x86_64 requires libGLU-devel
[Inventor]
Inventor-devel-2.1.5-43.fc18.i686 requires libGLU-devel
Inventor-devel-2.1.5-43.fc18.x86_64 requires libGLU-devel
[SDL]
SDL-devel-1.2.15-3.fc19.i686 requires libGLU-devel
SDL-devel-1.2.15-3.fc19.x86_64 requires libGLU-devel
[almanah]
almanah-0.8.0-7.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit)
almanah-0.8.0-7.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit)
almanah-0.8.0-7.fc18.x86_64 requires libecal-1.2.so.12()(64bit)
almanah-0.8.0-7.fc18.x86_64 requires libebook-1.2.so.13()(64bit)
[archmage]
archmage-0.2.4-6.fc18.noarch requires python-chm
[cegui]
cegui-devel-0.7.6-8.fc19.i686 requires libGLU-devel
cegui-devel-0.7.6-8.fc19.x86_64 requires libGLU-devel
[cegui06]
cegui06-devel-0.6.2-12.fc18.i686 requires libGLU-devel
cegui06-devel-0.6.2-12.fc18.x86_64 requires libGLU-devel
[chm2pdf]
chm2pdf-0.9.1-12.fc18.noarch requires python-chm
[clutter-gtk010]
clutter-gtk010-0.11.4-6.fc17.i686 requires libcogl.so.9
clutter-gtk010-0.11.4-6.fc17.x86_64 requires libcogl.so.9()(64bit)
[ease]
ease-0.4-18.fc17.i686 requires libcogl.so.9
ease-0.4-18.fc17.x86_64 requires libcogl.so.9()(64bit)
[emacs-spice-mode]
emacs-spice-mode-1.2.25-9.fc18.noarch requires gwave
[eog-plugins]
eog-plugins-3.4.1-2.fc18.x86_64 requires libcogl.so.9()(64bit)
[evolution-exchange]
evolution-exchange-3.5.2-1.fc18.x86_64 requires 
libedataserverui-3.0.so.3()(64bit)
evolution-exchange-3.5.2-1.fc18.x86_64 requires 
libedataserver-1.2.so.16()(64bit)
evolution-exchange-3.5.2-1.fc18.x86_64 requires 
libedata-cal-1.2.so.17()(64bit)
evolution-exchange-3.5.2-1.fc18.x86_64 requires 
libedata-book-1.2.so.14()(64bit)
evolution-exchange-3.5.2-1.fc18.x86_64 requires 
libecal-1.2.so.12()(64bit)
evolution-exchange-3.5.2-1.fc18.x86_64 requires 
libebook-1.2.so.13()(64bit)
evolution-exchange-3.5.2-1.fc18.x86_64 requires 
libebackend-1.2.so.3()(64bit)
evolution-exchange-3.5.2-1.fc18.x86_64 requires 
libcamel-1.2.so.36()(64bit)
[fedora-ksplice]
fedora-ksplice-0.5-10.fc18.x86_64 requires ksplice
[flush]
flush-0.9.10-7.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
flush-0.9.10-7.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
flush-0.9.10-7.fc18.x86_64 requires 
libboost_signals-mt.so.1.48.0()(64bit)
flush-0.9.10-7.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
[fontik]
fontik-0.6.1-2.20120305git5dbbc513.fc18.x86_64 requires 
libgee-0.8.so.0()(64bit)
[freeglut]
freeglut-devel-2.8.0-7.fc19.i686 requires libGLU-devel
freeglut-devel-2.8.0-7.fc19.x86_64 requires libGLU-devel
[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)
[gdb-heap]
gdb-heap-0.5-9.fc18.x86_64 requires glibc(x86-64) = 0:2.15
[gearmand]
gearmand-0.33-2.fc18.x86_64 requires 
libboost_program_options-mt.so.1.48.0()(64bit)
[glew]
glew-devel-1.7.0-3.fc18.i686 requires libGLU-devel
glew-devel-1.7.0-3.fc18.x86_64 requires libGLU-devel
[glom]
glom-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit)
glom-libs-1.18.6-1.fc17.i686 requires libboost_python.so.1.48.0
glom-libs-1.18.6-1.fc17.x86_64 requires 
libboost_python.so.1.48.0()(64bit)
[gnome-applets]
1:gnome-applets-3.5.1-1.fc18.x86_64 requires libgweather-3.so.0()(64bit)
[gnome-color-manager]
gnome-color-manager-3.5.3-2.fc18.x86_64 requires libcogl.so.9()(64bit)
[gnome-contacts]
gnome-contacts-3.5.4.1-1.fc18.x86_64 requires libcogl.so.9()(64bit)
gnome-contacts-3.5.4.1-1.fc18.x86_64 requires 
libcamel-1.2.so.39()(64bit)
[gnome-games]
1:gnome-games-gnibbles-3.5.5-3.fc19.x86_64 requires 
libcogl.so.9()(64bit)
1:gnome-games-lightsoff-3.5.5-3.fc19.x86_64 requires 
libcogl.so.9()(64bit)

Re: rawhide report: 20120909 changes

[Paul Howarth]

On 09/10/2012 11:36 AM, Michael Schwendt wrote:

On Mon, 10 Sep 2012 10:21:04 +0200, Tomáš Smetana wrote:


On Sun, 9 Sep 2012 12:39:46 +
Fedora Rawhide Report wrote:


[freeglut]
freeglut-devel-2.8.0-7.fc19.i686 requires libGLU-devel
freeglut-devel-2.8.0-7.fc19.x86_64 requires libGLU-devel


Hello,
  freeglut is mine and I wonder whether the new mesa-libGLU package misses the
"Provides: libGLU-devel" on purpose or if it was just an omission.


See 20120908 rawhide report's "mesa" changelog:

  | - Drop libGLU subpackage, split off upstream

Which translates to:

  * drop mesa-libGLU/mesa-libGLU-devel subpackages, which provided "libGLU"
and libGLU-devel

How to proceed from there, the changelog doesn't tell.


mesa-libGLU is now an independent package (i.e. not a sub-package of 
mesa), with a sub-package of mesa-libGLU-devel. However, these new 
packages are missing the provides for libGLU and libGLU-devel that the 
original sub-packages of mesa had. I commented on the mesa-libGLU review 
ticket (http://bugzilla.redhat.com/854377) to that effect and hopefully 
it will be resolved in due course.


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

Re: rawhide report: 20120909 changes

[Michael Schwendt]

On Mon, 10 Sep 2012 10:21:04 +0200, Tomáš Smetana wrote:

> On Sun, 9 Sep 2012 12:39:46 +
> Fedora Rawhide Report wrote:
> 
> > [freeglut]
> > freeglut-devel-2.8.0-7.fc19.i686 requires libGLU-devel
> > freeglut-devel-2.8.0-7.fc19.x86_64 requires libGLU-devel
> 
> Hello,
>  freeglut is mine and I wonder whether the new mesa-libGLU package misses the
> "Provides: libGLU-devel" on purpose or if it was just an omission.

See 20120908 rawhide report's "mesa" changelog:

 | - Drop libGLU subpackage, split off upstream

Which translates to:

 * drop mesa-libGLU/mesa-libGLU-devel subpackages, which provided "libGLU"
   and libGLU-devel

How to proceed from there, the changelog doesn't tell.

-- 
Fedora release 18 (Spherical Cow) - Linux 3.6.0-0.rc4.git2.1.fc18.x86_64
loadavg: 0.86 0.46 0.36
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20120909 changes

[Tomáš Smetana]

On Sun, 9 Sep 2012 12:39:46 +
Fedora Rawhide Report  wrote:

> [freeglut]
>   freeglut-devel-2.8.0-7.fc19.i686 requires libGLU-devel
>   freeglut-devel-2.8.0-7.fc19.x86_64 requires libGLU-devel

Hello,
 freeglut is mine and I wonder whether the new mesa-libGLU package misses the
"Provides: libGLU-devel" on purpose or if it was just an omission.

Thanks and regards,
-- 
Tomáš Smetana
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Packaging Hypertable

[Stanislav Ochotnicky]

Quoting Denis Arnaud (2012-09-09 16:50:59)
> Hi,
> 
> has anyone already attempted to package Hypertable (
> http://hypertable.com/community/source_code/) for Fedora/RedHat/CentOS?
> Does anyone know whether there are current initiatives around it? Would
> someone be interested in starting such a project?
> Upstream already delivers RPM packages (http://hypertable.com/download/0962/),
> but I suspect some work is still needed to be compliant with the Fedora
> packaging guidelines (e.g.,
> http://hypertable.com/documentation/installation/quick_start_standalone/#step-2---fhs-ize-installation
> ).
> 
> Cheers
> 
> Denis


Quick look at [1] shows a lot of bundled libraries. We have some, but
notably we are missing zookeeper, hive, hadoop and libthrift. You'd
first have to package them and that might lead into a pretty deep rabbit
hole. I had a look at zookeeper only and it wasn't as bad as I expected
so who knows :-)


[1] https://github.com/hypertable/hypertable/tree/master/lib

-- 
Stanislav Ochotnicky 
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel