[Fedora Release Engineering] #159: kdegraphics-3.5.9-2.i386.fc8 landed in f8/x86_64 updates (shouldn't be there)
by Fedora Release Engineering
#159: kdegraphics-3.5.9-2.i386.fc8 landed in f8/x86_64 updates (shouldn't
be there)
-----------------------------------------------+----------------------------
Reporter: Rex Dieter <rdieter(a)math.unl.edu> | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
-----------------------------------------------+----------------------------
{{{
It just came to my attention that kdegraphics-3.5.9-2.i386.fc8 landed in
the f8/x86_64 updates repo and really shouldn't be there. Any ideas how
that happened?
kdegraphics.i386 wasn't in the release. I'll keep trying to figure out
if there's something wrong packaging-wise to pull that in. Thanks.
-- Rex
}}}
--
Ticket URL: <http://fedorahosted.org/rel-eng/ticket/159>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
15 years, 7 months
[Fedora Release Engineering] #827: f10 betatag request for traceroute-2.0.12-1.fc10
by Fedora Release Engineering
#827: f10 betatag request for traceroute-2.0.12-1.fc10
----------------------------+-----------------------------------------------
Reporter: buc | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: Fedora 10 Beta | Component: koji
Keywords: |
----------------------------+-----------------------------------------------
It seems that I was late a little to include latest traceroute-2.0.12 info
rawhide. It was planned though...
2.0.12 is the latest upstream stable, which fixes some little bugs and
adds some new little features, including long time expected support for
the showing of ICMP extensions (MPLS).
I am the uspteam's maintainer as well.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/827>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
15 years, 7 months
untag xorg-x11-drv-i810 ?
by Ray Strode
So the intel driver has a bug right now where the screen only updates if
you move the mouse or press a key.
It's mentioned off hand in
https://bugzilla.redhat.com/show_bug.cgi?id=460330#c4
I've been downgrading to
xorg-x11-drv-i810-2.4.2-1.fc10.x86_64.rpm
to work around the issue on my own laptop. I don't know if there's a newer version that also works.
We probably shouldn't let the beta go out with the broken package should we?
--Ray
15 years, 7 months
Fwd: Broken dependencies: gspiceui
by Chitlesh GOORAH
Hello dear release engineers,
Could you please remove gspiceui-0.9.65-2.fc10.ppc64 from the rawhide
repository ?
It was once assumed that gwave was provided for the PPC64 arch. But it
is not. Gspiceui.spec has already the Exclude item on rawhide.
http://cvs.fedoraproject.org/viewvc/rpms/gspiceui/devel/gspiceui.spec?vie...
Thanks you,
Chitlesh GOORAH
---------- Forwarded message ----------
From: <buildsys(a)fedoraproject.org>
Date: Wed, Sep 24, 2008 at 2:44 PM
Subject: Broken dependencies: gspiceui
To: gspiceui-owner(a)fedoraproject.org
Cc: gwave-owner(a)fedoraproject.org
gspiceui has broken dependencies in the development tree:
On ppc64:
gspiceui-0.9.65-2.fc10.ppc64 requires gwave
Please resolve this as soon as possible.
15 years, 7 months
Planning Post F10 Elections
by Nigel Jones
[it'd appear that my original e-mail only went to FAB so here it is for
the other intended recipients]
Hi everyone,
With the last slip of the Fedora 10 release I've noticed we are getting
dangerously close to Christmas to hold the usual round of post election
votes, from what I can tell the following are on the cards:
* FAmSCo (Ambassadors)
* Fedora Board
* Fedora 11 Release Name
* FESCo (Engineering)
* FLSCo (Translation)
It's all technically a matter of timing, there is technically no reason
why all (or majority) of those votes can't be held at the exact same
time, it might be considered beneficial to hold FAmSCo, FESCo, and FLSCo
elections at the same time for instance.
It'd appear problems could arise in cases where someone may wish to
stand for both *SCo and Board simultaneously and only accept one
nomination.
Now, I'd assume that this situation would be fairly rare, and in these
cases we could have the situation where a candidate says "If I get both
nominations, I'll only accept the one for X", my question is, is this
acceptable to _you_.
>From an administration POV, it'd be best if that's the case there is at
least a day or so between the *SCo and Board elections (time for
announcements etc to be made), on the other hand, if the above is
suitable, they could all be held on the same time period.
>From a schedule POV here it is at the moment.
Based on Jesse's e-mail to fedora-devel-announce
(https://www.redhat.com/archives/fedora-devel-announce/2008-September/msg0...) if the slip is approved by FESCo, Fedora 10 will be released on 25 November.
This means the next logical dates to hold an election would be between
30th November (Sunday) and 17th December (Wednesday - 8 days before
Christmas). This is just over 2 weeks, assuming that F10 doesn't slip
again. The other option is holding them over the New Year, however,
remember that people in the Southern Hemisphere typically have a large
Summer holiday period up until Feb.
I'm not here to dictate when you can/can't hold elections though, but
I'm looking at the interest of the community and getting the best
possible turnout.
So, what do you guys think? Are there any reasons why this window may
not work? (Major holiday periods etc)
- Nigel Jones
(P.S. I'm only on F-A-B, so I'd appreciate CC's, although I will try to
keep an eye on archives etc, also I realize it's quite early, but it'd
mean we can all go into the process knowing when)
--
Nigel Jones <dev(a)nigelj.com>
15 years, 7 months
[Fedora Release Engineering] #764: infrastructure for creating desktop live cds daily
by Fedora Release Engineering
#764: infrastructure for creating desktop live cds daily
---------------------+------------------------------------------------------
Reporter: walters | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
---------------------+------------------------------------------------------
Hi, I want to avoid size regressions in the Live CD; in order to do this,
I'd like to have live CD images created daily by an automated process.
Once that hook is in place, we can add further automated checks on top of
that such as analyzing the size of installed packages, etc.
A git repository where we can put the scripts to run after the image is
created would be perfect.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/764>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
15 years, 7 months
[Fwd: Re: Schedule figures]
by John Poelstra
-------- Original Message --------
Subject: Re: Schedule figures
Date: Tue, 23 Sep 2008 16:28:10 -0700
From: John Poelstra <poelstra(a)redhat.com>
To: Paul W. Frields <stickster(a)gmail.com>
CC: rel-eng(a)fedoraproject.org, Tom 'spot' Callaway
<tcallawa(a)redhat.com>, Bill Nottingham <notting(a)redhat.com>
References: <1222199081.16833.31.camel(a)victoria-eth.internal.frields.org>
Paul W. Frields said the following on 09/23/2008 12:44 PM Pacific Time:
> Ladies and gentlemen,
>
> We're at a point where our GA date currently rests at 4 weeks total slip
> from our original date, and we're still trying to get a working Beta
> AIUI. About 3 weeks of that slip are due to the intrusion -- this
> thread is simply about schedule concerns. We should start thinking now
> about how we can properly take up the slack from the F10 release
> schedule in F11 and F12.
>
> I think if I were to informally poll everyone, they'd agree that we
> can't suck up 4 weeks of development time in the F11 schedule alone.
> Here are some ideas to consider (please add your concerns, and pose a
> solutions to address them):
I don't think we need to change the F11 or F12 schedules. This keeps us
consistent with our stated objective of releasing every six months. I
don't think we need to change the F11 GA date unless there is a major
compelling feature that needs time to develop that cannot wait for
F12... but that would go against our stated objective of being a time
based release.
We can achieve this by shortening the development window and following
the rest of the standard task durations for F11. To me this follows the
line of thinking people have been trying convince me of for a long time
which is basically that our releases are "just snapshots of rawhide".
That being the case, a shortened development window for one release
shouldn't matter that much because it isn't finished it can just join
the next release.
This also avoids the ripple affect of pushing out the GA date of F11 or
F12... you always have to absorb it somewhere so why not just get it
over with in the F11 development cycle?
> * Move all dates in the current F11 schedule to the right by two weeks
> (i.e. absorb two weeks of slip). Similarly absorb remaining two weeks
> of slip into the F12 schedule. Further slip will move both F11 and F12
> schedules to the right accordingly.
>
> * Rigorously enforce freezing in a way that maximizes our chances of
> turning out test releases on time.
>
It seems to me that rigorous freezes are only as good as rigorous
testing because you don't know how good or bad the stuff you've frozen
is until you test it.
John
15 years, 7 months
Fedora 10 Beta Freeze (Spins)
by Jeroen van Meeuwen
Hi there,
Fedora 10 has entered it's Beta Freeze stage which in your case is the
time to start making absolutely sure your Spins are in perfect shape for
being composed by Release Engineering.
Things you will need to make sure are, amongst others:
- it is not oversized
- it composes without troubles
- it ends up like you want it
- it boots, and runs
- it shows no unexpected behavior in applications you include
Right now, the following kickstarts are approved by the Spin SIG:
= fedora-aos.ks (Fedora AOS) =
- SELinux was added back to address the Board's concern with it being
removed originally. This should resolve the only issue the Board raised
but we've not yet seen explicit approval.
- The tool this spin is supposed to be composed with, appliance-tools,
is currently at Release Engineering's discretion. As said before, this
spin also composes with livecd-tools and spits out a nice minimal live
ISO which then again of course also includes the raw ext3 .img file.
- Approved by Spin SIG,
- Approved by Board
- Approved by Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/appliance-tools
= fedora-livecd-broffice.org.ks (Fedora BrOffice.org) =
- Approved by Spin SIG,
- Approved by Board,
- Approved by Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/BrOffice.orgSpin
= fedora-livecd-desktop-default.ks (Fedora Desktop) =
- One of our permanent spins
= fedora-livecd-education-math.ks (Fedora Education Math) =
- Approved by Spin SIG,
- Approved by Board,
- Pending approval from Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/EducationMathSpin
= fedora-livecd-kde.ks (Fedora KDE) =
- One of our permanent spins
= fedora-livecd-xfce.ks (Fedora XFCE) =
- Approved by Spin SIG,
- Approved by Board after a little shuffling with the Feature Page,
- Pending approval from Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/XfceSpin
= fedora-livedvd-developer.ks (Fedora Developer) =
- Approved by Spin SIG,
- Approved by Board,
- Pending approval from Rel. Eng.
Feature Page: https://fedoraproject.org/wiki/Features/DeveloperSpin
= fedora-livedvd-electronic-lab.ks (Fedora Electronic Lab) =
- One of the spins that has been approved previously (Fedora 8)
- Approved by Spin SIG,
- Approved by Board,
- Pending approval from Rel. Eng. (but does not have the right category
on it's Feature page to show up on Rel. Eng.'s radar, maybe since the
feature page existed for Fedora 8 already).
Feature Page: https://fedoraproject.org/wiki/Features/FedoraElectronicLab
= fedora-livedvd-games.ks (Fedora Games) =
- One of the Spins that have been previously accepted (Fedora 8) and is
now re-entering the process.
- Approved by Spin SIG,
- No Approval from Board requested, but previously approved,
- Not yet approved for Fedora 10 by Rel. Eng. (but in the
FeatureReadyForFesco category).
Feature Page: https://fedoraproject.org/wiki/Features/GamesSpin
For the Fedora 10 Beta, a new branch has been created in the
spin-kickstarts repository, called F-10-Beta. This branch only contains
the files necessary for composing the spins. Note that like the rawhide
tree, this branch is supposed to be frozen and as such you should only
be applying fixes, no huge changes.
To checkout the F-10-Beta branch and start working with it, do:
git pull
git checkout --track -b F-10-Beta origin/F-10-Beta
You should not commit any changes to this branch as this is what Rel.
Eng. is going to use to compose the spins from, and we do not know when
that is exactly. Fixes go into the master branch and are pulled into the
F-10-Beta branch only if necessary.
If you have any questions or remarks, please don't hesitate and drop the
list a line.
Kind regards,
Jeroen van Meeuwen
-kanarip
15 years, 7 months
[Fedora Release Engineering] #824: f10 beta live cd size issues
by Fedora Release Engineering
#824: f10 beta live cd size issues
-----------------------+----------------------------------------------------
Reporter: anonymous | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
-----------------------+----------------------------------------------------
Hey,
I've investigated the live cd size issues a bit for the F10 beta, and here
are three proposals to help with that:
1) Add -gnome-games-help to the kickstart file for the live cd. I would do
that myself, but I don't have commit
access to that right now.
2) Tag libgweather-2.24.0-2.fc10 for the beta. I've made it so that the
localized xml files also have %lang tags
now, which should make the language filtering we do for the live cd a
little more effective.
3) Tag libgsf-1.14.9-2.fc10 for the beta, which drops the ImageMagick
dependency again (I've asked Caolan, and
he was fine with dropping it)
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/824>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
15 years, 7 months
