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 w
On Thu, Feb 18, 2010 at 4:29 AM, Peter Hutterer
wrote:
>> > Rajeesh K Nambiar wrote:
>> >> Any pointers on how to migrate the 'enable touchpad tap-to-click'
>> >> feature from the existing .fdi file(s)?
>
> Section "InputClass"
> Identifier "tap-by-default"
> MatchIsTouchpad "on"
>
On 17/02/10 07:59 PM, Dave Airlie wrote:
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
On Thu, 2010-02-18 at 04:30 +0100, Kevin Kofler wrote:
> 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 s
On Thu, 2010-02-18 at 04:18 +0100, Kevin Kofler wrote:
> The question is, wouldn't it have been possible to, yes, branch early so
> Rawhide could move on (as we did), but have builds from F-13 land directly
> in dist-f13 until the Beta Freeze (as was done in the past and worked quite
> well)?
W
Compose started at Wed Feb 17 08:15:15 UTC 2010
New package gfs-goschen-fonts
A 19th century Greek typeface
New package ghc-haskeline
Haskell command-line interface for user input
New package jarjar
Jar Jar Links
New package paratype-pt-sans-fonts
A pan-Cyrillic typ
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:
> Yes, that may be true. It is unfortunate that you'll now have to do a
> buildroot override task, but that was a negative impact we were willing
> to take.
The question is, wouldn't it have been possible to, yes, branch early so
Rawhide could move on (as we did), but have b
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
On Thu, Feb 18, 2010 at 01:32:33 +0100,
Christoph Wickert wrote:
> There is more flexibility for n+2 but I doubt that anybody will/can make
> use of it. We not even have a feature process for F14, so why would
> anyone start a feature now?
Because it didn't make it for F13?
I have stuff I want
On Wed, Feb 17, 2010 at 4:19 PM, David wrote:
> On 15 February 2010 11:19, Arthur G wrote:
>> rolling - as in the song - rolling, rolling, rolling, rawhide!
>
> +1
>
> giving 3 names for trees/branches:
>
> rawhide ---> rolling ---> release
>
> Reasons it appeals to me:
> 1) humorous reference to
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 manager knew how to handle it properly. Basically,
no window could ha
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 wrote:
> On 15 February 2010 11:19, Arthur G wrote:
On Wed, 2010-02-17 at 18:24 -0700, Dariusz J. Garbowski wrote:
> Thanks for your answers. I will do my part in testing color management. It
> may be that I will have to do it over the weekend (there's this work thing
> going on on weekdays!)...
We can send your boss a note, if you think it'd hel
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
On 17/02/10 11:33 AM, Adam Williamson wrote:
> On Tue, 2010-02-16 at 18:48 -0700, Dariusz J. Garbowski 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
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, beca
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
Am Mittwoch, den 17.02.2010, 06:45 -0800 schrieb Jesse Keating:
> On Wed, 2010-02-17 at 15:28 +0100, Christoph Wickert wrote:
> >
> > Right, now there no longer is early branching for selected packages on
> > demand but a general early branches for all packages.
>
> Except it's not really early.
Hi,
On Thu, Feb 18, 2010 at 4:26 AM, Kevin Kofler 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), but it doesn't
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 merkaarto
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 tal
On 15 February 2010 11:19, Arthur G wrote:
> rolling - as in the song - rolling, rolling, rolling, rawhide!
+1
giving 3 names for trees/branches:
rawhide ---> rolling ---> release
Reasons it appeals to me:
1) humorous reference to the song
2) alliteration, it reads nice, everything begins with
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
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), but it doesn't make sense to push updates just
for those changes! Please only pus
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 their current state.
>
> How do we a
On Wed, 2010-02-17 at 23:21 +0100, Kevin Kofler wrote:
> 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
> > "
Matthias Clasen wrote:
> I don't use chain builds when updating gnome, so it can be done.
> Please just complain for yourself...
The problem is that in KDE, the application modules from 4.x.n need to be
built against at least kdelibs 4.x.n, not 4.x.n-1 (and likewise for other
dependencies). (Oft
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
>> KDE app is always aware of the changes before they happen. If t
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?
http://lists.fedoraproject.or
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 it up in your desktop. (For KDE, install
> kcm_touchpad, it will be ins
Christoph Wickert wrote:
> You are lucky. In the past people broke my package without further
> notice and I had to take care of fixing them. On the other hand there
> are maintainers, that announce changes in advance and ask me if I'm fine
> with them rebuilding my packages or if I want to take ca
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 no
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
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 brok
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.or
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
after
The dep checker script seems to have detected some bogus broken deps.
We're still tracking down the root cause, for now you can ignore the
broken deps spam.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
signature.asc
Description: This is a digitally sign
https://bugzilla.redhat.com/show_bug.cgi?id=434735
https://bugzilla.redhat.com/attachment.cgi?id=394796&action=diff
https://bugzilla.redhat.com/attachment.cgi?id=394796&action=edit
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-dev
On Tue, 2010-02-16 at 18:48 -0700, Dariusz J. Garbowski 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 don't se
On 17 February 2010 17:34, Dave Jones 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 use than
> opr
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 goe
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 http://mirrors.
> 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
https://bugzilla.redh
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 like
On Wed, 2010-02-17 at 17:57 +0100, Till Maas wrote:
>
> So how is the package set determined that builds the Alpha release? Is
> it everything which is pushed to F13 in Bodhi for 2010-02-24 at 20:00
> UTC, which is the time of the GO/NOGO meeting? Or is the Alpha release
> first composed and then
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, b
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, 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 Fre
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 "you"s
> that we wrote about:
> https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Us
On Wed, Feb 17, 2010 at 03:28:37PM +0100, Christoph Wickert wrote:
> Am Mittwoch, den 17.02.2010, 15:07 +0100 schrieb Till Maas:
> > On Wed, Feb 17, 2010 at 02:23:22PM +0100, Christoph Wickert wrote:
> >
> > > ...
> >
> > Usually when some of mine packages need to be rebuild because of updated
>
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 b
On Wed, 2010-02-17 at 15:50 +0100, Mathieu Bridon wrote:
> I think Frank's question was:
> In F12, I have a rawhide.repo I can use if I want to move to Rawhide.
> What do I use if I want to move to F13?
>
> At least, that's what I am wondering.
You'd install fedora-release from the branched repo
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 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 t
On Wed, Feb 17, 2010 at 15:11, Jesse Keating 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 fedora.repo
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 mo
Am Mittwoch, den 17.02.2010, 15:07 +0100 schrieb Till Maas:
> On Wed, Feb 17, 2010 at 02:23:22PM +0100, Christoph Wickert wrote:
>
> > ...
>
> Usually when some of mine packages need to be rebuild because of updated
> dependencies, the communication is usually one-way. I get informed that
> the p
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 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
t
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
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
gr
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 ri
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 inflati
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
On Tue, Feb 16, 2010 at 11:31 AM, Peter Hutterer
wrote:
> options as specified. That's just one example, I've tried to detail the new
> configurations on our wiki.
> https://fedoraproject.org/wiki/Input_device_configuration
> If you think there's anything missing, please let me know or add it
> yo
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 th
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 best approach, so if there is none,
ask of it. If there is no nee
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
https://admin.fedorap
> 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 earl
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 f
Hi,
On Tue, Feb 9, 2010 at 4:07 AM, Roland Grunberg 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 what this fe
On 17 February 2010 01:48, Dariusz J. Garbowski 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 don't see test ca
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].
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
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 17/02/10 08:49, Bruno Wolff III wrote:
> On Wed, Feb 17, 2010 at 08:34:01 +,
>Frank Murphy 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.
--
Reg
On Wed, Feb 17, 2010 at 08:34:01 +,
Frank Murphy 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
https://admin.fedoraproject
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 "branch
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
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
81 matches
Mail list logo
