On 17/02/10 04:31, Jesse Keating wrote:
--snipped--
There will be a Rawhide Report and a Branched Report. Rawhide will be
F-14 now, Branched is F-13. There will also be Fedora 13 Updates
Testing announcements over on the test list.
When will there be a branched.repo config for testers.
Jesse Keating wrote:
Looking at a set of wiki pages to work on today, I had another thought.
We could just call it 'Branched', as in, Fedora 13 has Branched,
Branched Freeze Policy, Once a Fedora release has branched from
rawhide, , Mark this test-update as stable to go into the Branched
On 17/02/10 08:31, Björn Persson wrote:
Jesse Keating wrote:
--snipped--
So when Fedora 13 has been released, is it then no longer branched? It's still
branched from Rawhide but it's not in the Branched state anymore. Doesn't that
sound a bit awkward?
Björn Persson
I presume branched will
On Wed, Feb 17, 2010 at 08:34:01 +,
Frank Murphy frankl...@gmail.com wrote:
I presume branched will then be repointed to an alpha F14.
rawhide F15
That doesn't happen at the release of F13, but rather at F14 alpha freeze.
--
devel mailing list
devel@lists.fedoraproject.org
On 17/02/10 08:49, Bruno Wolff III wrote:
On Wed, Feb 17, 2010 at 08:34:01 +,
Frank Murphyfrankl...@gmail.com wrote:
I presume branched will then be repointed to an alpha F14.
rawhide F15
That doesn't happen at the release of F13, but rather at F14 alpha freeze.
Sorry bad wording.
Am Dienstag, den 16.02.2010, 20:31 -0800 schrieb Jesse Keating:
static-repos will act as it normally does for a released Fedora. The
repo seen is what is in the buildroot, which is what is tagged for
release, and anything we've tagged override to make it available in
the buildroot for
On Wed, 17 Feb 2010 10:04:13 +0100 Christoph Wickert wrote:
This means that chainbuilds are no longer possible and this slows
development down dramatically. Think of a feature like Xfce 4.8 with
it's tight schedule [1]. E.g. we only have 8 days to build one of the
pre-releases.
When I made
Am Mittwoch, den 17.02.2010, 10:34 +0100 schrieb Michal Schmidt:
On Wed, 17 Feb 2010 10:04:13 +0100 Christoph Wickert wrote:
This means that chainbuilds are no longer possible and this slows
development down dramatically. Think of a feature like Xfce 4.8 with
it's tight schedule [1]. E.g.
On 17 February 2010 01:48, Dariusz J. Garbowski thufo...@yahoo.co.uk wrote:
Features/ColorManagement describes per-screen / per-output support. I have a
dual monitor setup here
(potentially even triple-monitor if I could setup SurroundView with on-board
Radeon and discrete
Radeon card). I
Hi,
On Tue, Feb 9, 2010 at 4:07 AM, Roland Grunberg rgrun...@redhat.com wrote:
This is just an update to let maintainers know that the changes to
LD outlined here :
https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
will be in fedora rawhide pretty soon.
The details behind
On Tue, Feb 16, 2010 at 02:14:24PM -0700, Kevin Fenzi wrote:
* Fedora Engineering Services (nirik, 20:43:55)
* LINK: https://fedoraproject.org/wiki/FES (nirik, 20:44:52)
Is there any reason not to rename that page to Fedora Engineering
Services, because with this acronym, it won't be
Is it ok to backport changes to F-12 for fixed packages in F-13 for
this DSO feature?
The changes to a package's linking lines that you make for this issue are
cleaning up sloppy practice to what was always the right thing to be doing.
So it should always be fine to do that in builds for
updates/testing/13 (the 13 dir) does not yet exist, although sure it's
on the list of things to do, or be created once a package has been
built.
Just an FYI...
--
Mike Chambers
Madisonville, KY
Best lil town on Earth!
--
devel mailing list
devel@lists.fedoraproject.org
On Wed, Feb 17, 2010 at 03:04:00AM -0800, Roland McGrath wrote:
Is it ok to backport changes to F-12 for fixed packages in F-13 for
this DSO feature?
The changes to a package's linking lines that you make for this issue are
cleaning up sloppy practice to what was always the right thing to
Am Mittwoch, den 17.02.2010, 12:18 +0100 schrieb Till Maas:
On Wed, Feb 17, 2010 at 10:44:10AM +0100, Christoph Wickert wrote:
And what about the updates that don't have a custom tag?
If the update is big enough, that a lot of packages require a rebuild,
using a custom tag seems to be the
On Wed, Feb 17, 2010 at 02:23:22PM +0100, Christoph Wickert wrote:
Both approaches have their ups and downs, but both slow down
development:
* Asking rel-eng for overwrites takes time.
* Asking rel-eng for a tag takes some time too. And I'm afraid
that with an
On Wed, 2010-02-17 at 08:26 +, Frank Murphy wrote:
When will there be a branched.repo config for testers.
So they won't be getting rawhide.repo.
It that's what they want\need.
The branched repo config is the fedora.repo file. Mirrormanager will be
making sure that goes to the right
On Wed, 2010-02-17 at 10:04 +0100, Christoph Wickert wrote:
How do we address this issue?
The same way we address it for updates to a stable Fedora.
Release Engineering is an open group, if there are significant delays in
getting tagging done we can certainly try to get more taggers into the
On Wed, 2010-02-17 at 10:34 +0100, Michal Schmidt wrote:
Would it help to use a special Koji tag for this?
Let's say you'd get a tag 'dist-f13-xfce48' where all packages built
there would be immediately available for building dependend packages.
And then when you're done, you'd ask rel-eng to
On Wed, 2010-02-17 at 05:01 -0600, Mike Chambers wrote:
updates/testing/13 (the 13 dir) does not yet exist, although sure it's
on the list of things to do, or be created once a package has been
built.
Just an FYI...
Yep, on my list for today. There are no yum configs in the wild yet
that
On Wed, 2010-02-17 at 05:45 +0100, Ralf Corsepius wrote:
Am I correct in assuming, wcorresponding mock setups for and yum
mirrorlists reflecting this new setup will be in place in time when
these repos go on-line?
yes. MirrorManager should already be working for these repos, I'll be
On Wed, 2010-02-17 at 15:28 +0100, Christoph Wickert wrote:
Right, now there no longer is early branching for selected packages onn
demand but a general early branches for all packages.
Except it's not really early. We're now in bugfix/polish mode for
Fedora 13, not in rapid development
On Wed, Feb 17, 2010 at 15:11, Jesse Keating jkeat...@redhat.com wrote:
On Wed, 2010-02-17 at 08:26 +, Frank Murphy wrote:
When will there be a branched.repo config for testers.
So they won't be getting rawhide.repo.
It that's what they want\need.
The branched repo config is the
On Wed, 2010-02-17 at 10:04 +0100, Christoph Wickert wrote:
This means that large updates like Gnome, KDE or Xfce will get massively
delayed after alpha. They might not make it into one of the prereleases,
which means they get less testing. A lot of features will no longer be
possible in
On Tue, 2010-02-16 at 16:17 -0500, Bill Nottingham wrote:
Jesse Keating (jkeat...@redhat.com) said:
On Tue, 2010-02-16 at 20:09 +, Richard W.M. Jones wrote:
On Tue, Feb 16, 2010 at 08:06:16PM +, Rawhide Report wrote:
1:libguestfs-1.0.84-1.fc13.i686 requires
On Wed, 2010-02-17 at 00:38 +0100, Kevin Kofler wrote:
Peter Hutterer wrote:
evdev and synaptics are updated, so those two are converted. I know fpit
has an fdi file and there's some exceptions in x11-input.fdi that need to
be added too. I need to do this tomorrow unless you want to beat me
On Tue, Feb 16, 2010 at 08:10:17PM -0800, Jesse Keating wrote:
That's right folks, we are now branched for Fedora 13. What does this
mean to you? Well that depends on who you are, here are some yous
that we wrote about:
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Use_Cases
On Wed, 2010-02-17 at 16:33 +0100, Till Maas wrote:
Is the branch freeze a week late or is it now the same as the alpha
freeze? In the Important Release Milestones wiki page[0], the branch
was scheduled for 2010-02-09, but on the F13 Schedule[1], the Alpha
Freeze links to the Alpha Freeze
On Wed, Feb 17, 2010 at 06:11:58AM -0800, Jesse Keating wrote:
The branched repo config is the fedora.repo file. Mirrormanager will be
making sure that goes to the right place. There is an updated
Is this http://mirrors.fedoraproject.org/publiclist/Fedora/ the url for
mirrormanager? I have
On Wed, Feb 17, 2010 at 07:36:00AM -0800, Jesse Keating wrote:
On Wed, 2010-02-17 at 16:33 +0100, Till Maas wrote:
Is the branch freeze a week late or is it now the same as the alpha
freeze? In the Important Release Milestones wiki page[0], the branch
was scheduled for 2010-02-09, but on
I'm going to recommend dropping this package from Fedora entirely.
- Upstream seems to have stopped development on it since intel acquired
its developers (opened-hand)
- The new profiling tools (perf) are in many cases easier to use than
oprofile
- oprofileui had a number of bugs that look
I'm not sure I understand exactly what you need here, but AIUI you just need
this:
what I meant is that the scenario of having a composed layout (eg.
Arabic/English or Arabic/French) should be part of QA tests
because a problem in them will case the user unable to login
On Wed, Feb 17, 2010 at 04:40:33PM +0100, Till Maas wrote:
On Wed, Feb 17, 2010 at 06:11:58AM -0800, Jesse Keating wrote:
The branched repo config is the fedora.repo file. Mirrormanager will be
making sure that goes to the right place. There is an updated
Is this
On Wed, Feb 17, 2010 at 11:52:57AM -0600, Matt Domsch wrote:
On Wed, Feb 17, 2010 at 04:40:33PM +0100, Till Maas wrote:
On Wed, Feb 17, 2010 at 06:11:58AM -0800, Jesse Keating wrote:
The branched repo config is the fedora.repo file. Mirrormanager will be
making sure that goes to the
On 17 February 2010 17:34, Dave Jones da...@redhat.com wrote:
I'm going to recommend dropping this package from Fedora entirely.
- Upstream seems to have stopped development on it since intel acquired
its developers (opened-hand)
- The new profiling tools (perf) are in many cases easier to
I got a message about cegui having a broken dependency in devel that didn't
seem to make any sense since all of the dependencies in the package referred
to subparts of the package having matching versions. I hadn't changed it
for about a week, so it seemed suspicious that it showed up the day
I just got about half a dozen broken dependencies in devel emails that
seem to be completely wacko, as neither the dependent nor the dependee
have changed lately. Something messed up in the repo maybe?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
On Wed, Feb 17, 2010 at 4:07 PM, Tom Lane wrote:
I just got about half a dozen broken dependencies in devel emails that
seem to be completely wacko, as neither the dependent nor the dependee
have changed lately. Something messed up in the repo maybe?
They (the emails) are obviously broken.
Rajeesh K Nambiar wrote:
Any pointers on how to migrate the 'enable touchpad tap-to-click'
feature from the existing .fdi file(s)?
The best solution is to just set it up in your desktop. (For KDE, install
kcm_touchpad, it will be installed by default on the F13 KDE Live spin. For
GNOME, the
Jesse Keating wrote:
There is one small wrinkle. I've broken the dist-rawhide static repo,
because I've made dist-rawhide a real build target to be used by builds
from devel/. I'll be making a symlink soon that will keep
dist-rawhide static repos pointed to the right location.
Why not use
On Wed, Feb 17, 2010 at 04:07:00PM -0500, Tom Lane wrote:
I just got about half a dozen broken dependencies in devel emails that
seem to be completely wacko, as neither the dependent nor the dependee
have changed lately. Something messed up in the repo maybe?
On Wed, Feb 17, 2010 at 05:42:59PM -0500, Joshua Baker-LePain wrote:
On Wed, 17 Feb 2010 at 11:13pm, Kevin Kofler wrote
Rajeesh K Nambiar wrote:
Any pointers on how to migrate the 'enable touchpad tap-to-click'
feature from the existing .fdi file(s)?
The best solution is to just set
On Wed, Feb 17, 2010 at 11:40:15PM +0100, Kevin Kofler wrote:
Yes, I know, because I co-maintain a package using qt and I recently
read something from the maintainer that he can not push a bugfix update
to stable, because a qt override is in the buildroot.
The solution there is to talk to
Sven Lankes wrote:
I'm assuming that Till is talking about my comment
https://bugzilla.redhat.com/show_bug.cgi?id=549717#c2 on merkaartor
(which he co-maintains).
So nothing to see here - please move on. This is about not being able to
do a scratch build of an svn-snapshot of merkaartor.
Hi,
On Thu, Feb 18, 2010 at 4:26 AM, Kevin Kofler kevin.kof...@chello.at wrote:
Parag N(पराग़) wrote:
Is it ok to backport changes to F-12 for fixed packages in F-13 for
this DSO feature?
It's of course OK to apply those changes to all branches (they won't break
anything for the older ld),
On Thu, 2010-02-18 at 01:32 +0100, Christoph Wickert wrote:
This only works for things developed in Fedora or for projects like
Gnome, because we are closely following their schedule. Other projects
have other schedules and we need to be flexible. I really like no frozen
rawhide, but IMO we
On Thu, Feb 18, 2010 at 12:24:45AM +0100, Sven Lankes wrote:
On Wed, Feb 17, 2010 at 11:40:15PM +0100, Kevin Kofler wrote:
Yes, I know, because I co-maintain a package using qt and I recently
read something from the maintainer that he can not push a bugfix update
to stable, because a qt
On Wed, Feb 17, 2010 at 11:40:15PM +0100, Kevin Kofler wrote:
Till Maas wrote:
On Wed, Feb 17, 2010 at 03:28:37PM +0100, Christoph Wickert wrote:
Take KDE for example: Although the KDE SIG is doing a great job in
avoiding breakdowns, I doubt that each and every maintainer of a QT or
Thanks Dave,
Here's one borrowed from the music industry.
mastering (or starting with R - remastering)
I've used this concept successfully for commercial orgs during their
release finalizing stages.
Arthur.
On 18 February 2010 10:19, David bouncingc...@gmail.com wrote:
On 15 February 2010
On Wed, Feb 17, 2010 at 4:19 PM, David bouncingc...@gmail.com wrote:
On 15 February 2010 11:19, Arthur G arthurg.w...@gmail.com wrote:
rolling - as in the song - rolling, rolling, rolling, rawhide!
+1
giving 3 names for trees/branches:
rawhide --- rolling --- release
Reasons it appeals
On Wed, 2010-02-17 at 18:40 -0700, Dariusz J. Garbowski wrote:
Hi,
I was wondering about state of Radeon SurroundView support in Fedora. I tried
to get it working
couple of months ago with 4670 + IGP 790GX and even got the X server start
with 3 displays but
neither Gnome nor KDE window
Till Maas wrote:
I'll remember this. But why don't you use a special tag for this instead
of a buildroot override? I believe this question is not answered and I
even might have asked it once in IRC. ;-)
Because, as has been said earlier in this thread, special tags also have
their problems:
*
Jesse Keating wrote:
You're in Austria right?
Yes. But my wake times tend to be very chaotic. ;-)
Rex wakes up before I do, which is why he's hitting them before me.
Finding somebody on the other side of the pond who's interested in doing
releng work would help.
Right, having somebody
perl-App-Nopaste has broken dependencies in the development tree:
On x86_64:
1:nopaste-0.18-1.fc13.noarch requires perl-App-Nopaste = 0:0.18-1.fc13
On i386:
1:nopaste-0.18-1.fc13.noarch requires perl-App-Nopaste = 0:0.18-1.fc13
Please resolve this as soon as possible.
--
Fedora
perl-MooseX-StrictConstructor has broken dependencies in the development tree:
On x86_64:
perl-MooseX-StrictConstructor-0.08-3.fc13.noarch requires perl(Moose)
= 0:0.74
On i386:
perl-MooseX-StrictConstructor-0.08-3.fc13.noarch requires perl(Moose)
= 0:0.74
Please resolve this
perl-Crypt-OpenSSL-Bignum has broken dependencies in the development tree:
On x86_64:
perl-Crypt-OpenSSL-Bignum-0.04-9.fc13.x86_64 requires perl = 0:5.005
On i386:
perl-Crypt-OpenSSL-Bignum-0.04-9.fc13.i686 requires perl = 0:5.005
Please resolve this as soon as possible.
--
perl-Perl-Critic has broken dependencies in the development tree:
On x86_64:
perl-Perl-Critic-1.105-3.fc13.noarch requires perl = 0:5.006001
perl-Perl-Critic-1.105-3.fc13.noarch requires perl(Module::Pluggable)
= 0:3.1
perl-Perl-Critic-1.105-3.fc13.noarch requires
grepmail has broken dependencies in the development tree:
On x86_64:
grepmail-5.3034-3.fc13.noarch requires perl = 0:5.005
grepmail-5.3034-3.fc13.noarch requires perl(Mail::Mbox::MessageParser)
= 0:1.4001
On i386:
grepmail-5.3034-3.fc13.noarch requires perl = 0:5.005
perl-bioperl has broken dependencies in the development tree:
On x86_64:
perl-bioperl-1.6.1-3.fc13.noarch requires perl(LWP) = 0:5.64
perl-bioperl-1.6.1-3.fc13.noarch requires perl(XML::Writer) = 0:0.4
On i386:
perl-bioperl-1.6.1-3.fc13.noarch requires perl(LWP) = 0:5.64
perl-Number-Format has broken dependencies in the development tree:
On x86_64:
perl-Number-Format-1.73-2.fc13.noarch requires perl = 0:5.008
On i386:
perl-Number-Format-1.73-2.fc13.noarch requires perl = 0:5.008
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
perl-MooseX-CascadeClearing has broken dependencies in the development tree:
On x86_64:
perl-MooseX-CascadeClearing-0.02-2.fc13.noarch requires
perl(namespace::autoclean) = 0:0.08
perl-MooseX-CascadeClearing-0.02-2.fc13.noarch requires perl(Moose) =
0:0.88
On i386:
perl-namespace-clean has broken dependencies in the development tree:
On x86_64:
perl-namespace-clean-0.13-1.fc13.noarch requires
perl(B::Hooks::EndOfScope) = 0:0.07
perl-namespace-clean-0.13-1.fc13.noarch requires perl(Sub::Identify) =
0:0.04
62 matches
Mail list logo
