On Thu, Aug 12, 2010 at 04:19:25AM +0200, Ralf Corsepius wrote:
On 08/12/2010 03:34 AM, Kevin Kofler wrote:
Mike McGrath wrote:
Luckily Remi got a list:
http://lists.fedoraproject.org/pipermail/devel/2010-August/140708.html
Unfortunately, Remi's list only covers php-*, I think there
I'll take SOAPpy, co-maintainers for all of my packages are welcome.
Full list: https://admin.fedoraproject.org/pkgdb/users/packages/supercyper
Regards,
Chen Lei
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Thursday, August 12, 2010 04:19:25 am Ralf Corsepius wrote:
On 08/12/2010 03:34 AM, Kevin Kofler wrote:
Mike McGrath wrote:
Luckily Remi got a list:
http://lists.fedoraproject.org/pipermail/devel/2010-August/140708.html
Unfortunately, Remi's list only covers php-*, I think there
On Wed, Aug 11, 2010 at 19:19, Remi Collet fed...@famillecollet.com wrote:
php-channel-phpunit
php-pecl-xdebug -- PECL package for debugging PHP scripts
I can help co-maintaining these if you like. As far as I see those are
the only one I use.
If you need a hand with other packages on the list
Jesse Keating jkeat...@redhat.com writes:
When an F14 build goes stable through bodhi, it'll be inherited into
rawhide.
Unless there is already a release of the package tagged dist-f15, IIUC.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2010 12:42 AM, Andreas Schwab wrote:
Jesse Keating jkeat...@redhat.com writes:
When an F14 build goes stable through bodhi, it'll be inherited into
rawhide.
Unless there is already a release of the package tagged dist-f15, IIUC.
Hello All!
It was easy to build whole list of upstream projects available in
Fedora - anyone could just look over the contents of this page:
http://cvs.fedoraproject.org/viewvc/rpms/
Now it doesn't look that easy. In fact I have no clue how to build
this list after switching to git. Could
Jesse Keating jkeat...@redhat.com writes:
Yes, that is correct. An already built version on f15 will always be
newer than anything coming up from f14.
Which is exactly the situation with systemd.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84
On Thursday, August 12, 2010 10:19:57 am Martin Gieseking wrote:
Am 12.08.2010 10:03, schrieb Peter Lemenkov:
It was easy to build whole list of upstream projects available in
Fedora - anyone could just look over the contents of this page:
http://cvs.fedoraproject.org/viewvc/rpms/
On 08/12/2010 10:03 AM, Peter Lemenkov wrote:
Hello All!
It was easy to build whole list of upstream projects available in
Fedora - anyone could just look over the contents of this page:
http://cvs.fedoraproject.org/viewvc/rpms/
Now it doesn't look that easy.
I use
Am 12.08.2010 10:32, schrieb Jaroslav Reznik:
But as you can see on [1]: http://pkgs.fedoraproject.org/gitweb/ BROKEN
(listing 10K+ packages does not work). Use e.g.
http://pkgs.fedoraproject.org/gitweb/?p=erlang.git directly for the erlang
package (also broken, unfortunately)
Oops, sorry, I
Martin Gieseking martin.giesek...@uos.de writes:
Am 12.08.2010 10:32, schrieb Jaroslav Reznik:
But as you can see on [1]: http://pkgs.fedoraproject.org/gitweb/ BROKEN
(listing 10K+ packages does not work). Use e.g.
http://pkgs.fedoraproject.org/gitweb/?p=erlang.git directly for the erlang
Hello All!
2010/8/12 Ralf Corsepius rc040...@freenet.de:
I use
https://admin.fedoraproject.org/pkgdb/lists/bugzilla?tg_format=plain for
similar purposes.
Thanks! Exactly what I need.
--
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
On Thu, 2010-08-12 at 10:59 +0200, Andreas Schwab wrote:
Martin Gieseking martin.giesek...@uos.de writes:
Am 12.08.2010 10:32, schrieb Jaroslav Reznik:
But as you can see on [1]: http://pkgs.fedoraproject.org/gitweb/ BROKEN
(listing 10K+ packages does not work). Use e.g.
Matt McCutchen m...@mattmccutchen.net writes:
On Thu, 2010-08-12 at 10:59 +0200, Andreas Schwab wrote:
Martin Gieseking martin.giesek...@uos.de writes:
Am 12.08.2010 10:32, schrieb Jaroslav Reznik:
But as you can see on [1]: http://pkgs.fedoraproject.org/gitweb/ BROKEN
(listing 10K+
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It is common for iso size to be over the 700MB target size due to most
developers and testers doing their work in virtual machines these days.
Therefore, iso size is not an issue. And bringing it back down to below
the 700MB size limit for CD is
On Thursday, August 12, 2010 01:10:08 pm Chris Jones wrote:
It is common for iso size to be over the 700MB target size due to most
developers and testers doing their work in virtual machines these days.
Therefore, iso size is not an issue. And bringing it back down to below
the 700MB size
Compose started at Thu Aug 12 08:15:16 UTC 2010
Broken deps for x86_64
--
Mayavi-3.3.0-1.fc13.x86_64 requires python(abi) = 0:2.6
Mayavi-3.3.0-1.fc13.x86_64 requires libpython2.6.so.1.0()(64bit)
On 08/12/2010 02:25 AM, Jan Kaluza wrote:
On Thursday, August 12, 2010 04:19:25 am Ralf Corsepius wrote:
On 08/12/2010 03:34 AM, Kevin Kofler wrote:
Mike McGrath wrote:
Luckily Remi got a list:
http://lists.fedoraproject.org/pipermail/devel/2010-August/140708.html
Unfortunately, Remi's
On Thu, 12.08.10 00:52, Jesse Keating (jkeat...@redhat.com) wrote:
Yes, that is correct. An already built version on f15 will always be
newer than anything coming up from f14.
Can I undo such a build? I did that mostly because I forgot that the
branching already happened when I built
Lennart Poettering wrote, at 08/12/2010 10:28 PM +9:00:
On Thu, 12.08.10 00:52, Jesse Keating (jkeat...@redhat.com) wrote:
Yes, that is correct. An already built version on f15 will always be
newer than anything coming up from f14.
Can I undo such a build? I did that mostly because I
On Thursday, August 12, 2010 03:23:59 pm Jon Ciesla wrote:
On 08/12/2010 02:25 AM, Jan Kaluza wrote:
On Thursday, August 12, 2010 04:19:25 am Ralf Corsepius wrote:
On 08/12/2010 03:34 AM, Kevin Kofler wrote:
Mike McGrath wrote:
Luckily Remi got a list:
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=620459
--- Comment #2 from Mike McGrath mmcgr...@redhat.com 2010-08-12 09:57:22 EDT
---
thanks, I just missed this one. I'm not an
On Thursday, 12 August 2010 at 04:19, Ralf Corsepius wrote:
[...]
I happened to have a full list of all former xulchris owned packages around:
[...]
cksfv -- Utility to manipulate SFV files
Taken.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion
Hi Lennart,
I found that systemd-units depends on pkgconfig, is this dependency
really needed for minimum systemd?
Regards,
Chen Lei
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I updated system yesterday, installed scd just now:
[init 3]# system-config-display
File /usr/share/system-config-display/xconf.py, line 27, in module
import xf86config
File /usr/lib/python2.7/site-packages/xf86config.py, line 1, in module
import xf86config
ImportError:
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=620459
--- Comment #3 from Jason Tibbitts ti...@math.uh.edu 2010-08-12 10:15:19 EDT
---
Git done (by process-git-requests).
--
On 12/08/10 15:11, Felix Miata wrote:
I updated system yesterday, installed scd just now:
[init 3]# system-config-display
Has it not been replaced by xrandr
for display porpoises?
--
Regards,
Frank Murphy
UTF_8 Encoded
Friend of Fedora
--
devel mailing list
devel@lists.fedoraproject.org
Hello All!
I'm currently in process of automatic enlisting of all ~10K Fedora Git
repos at Ohloh. Right now roughly 7% of repositories were added and
overall process will be finished in a 20-30 hours (it takes me about
5-10 seconds to properly add repository, and I don't want to speedup
this
perl-Config-Model has broken dependencies in the F-14 tree:
On x86_64:
perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) =
0:0.303
On i386:
perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) =
0:0.303
Please resolve this as soon as possible.
--
Fedora
perl-Pugs-Compiler-Rule has broken dependencies in the F-14 tree:
On x86_64:
perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires
perl(:MODULE_COMPAT_5.10.1)
On i386:
perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires
perl(:MODULE_COMPAT_5.10.1)
Please resolve this as soon as
On Thu, 2010-08-12 at 10:11 -0400, Felix Miata wrote:
I updated system yesterday, installed scd just now:
[init 3]# system-config-display
File /usr/share/system-config-display/xconf.py, line 27, in module
import xf86config
File /usr/lib/python2.7/site-packages/xf86config.py, line 1,
On Wed, 2010-08-11 at 17:17 -0400, David Malcolm wrote:
Thanks everyone who've already rebuilt their packages.
I just kicked off a script that attempts to rebuild everything still
affected; the rebuilds are marked as --background which I believe makes
them lower priority in Koji than other
Compose started at Thu Aug 12 13:15:13 UTC 2010
Broken deps for x86_64
--
CGAL-3.6.1-1.fc14.i686 requires libboost_thread-mt.so.1.41.0
CGAL-3.6.1-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit)
On Thu, 2010-08-12 at 11:20 +0200, Andreas Schwab wrote:
Matt McCutchen m...@mattmccutchen.net writes:
I went to https://pkgs.fedoraproject.org/gitweb/ and it sat there
Generating for 5 minutes before I ran out of patience. I wouldn't
consider that working fine.
Try
Summary of changes:
9e43ea9... - new upstream version - fix buildrequires - add requires n (*)
2c1157c... - no need to search for *.bs files in noarch rpm (*)
b726e8d... - new upstream version (*)
6dba6dc... Fix typo that causes a failure to update the common directo (*)
81afc0f... -
commit c1a0b4c23cce4432821234955dde3a086b1f3591
Merge: 81afc0f 2643c13
Author: Paul Howarth p...@city-fan.org
Date: Thu Aug 12 17:00:32 2010 +0100
Merge branch 'el6/master' of ssh://pkgs.fedoraproject.org/perl-MIME-Lite
into el6/master
perl-MIME-Lite was included in EL-6 Beta 2
Lennart Poettering (mzerq...@0pointer.de) said:
Yes, that is correct. An already built version on f15 will always be
newer than anything coming up from f14.
Can I undo such a build? I did that mostly because I forgot that the
branching already happened when I built systemd the first time
On Thu, Aug 12, 2010 at 06:16:52PM +0400, Peter Lemenkov wrote:
Hello All!
I'm currently in process of automatic enlisting of all ~10K Fedora Git
repos at Ohloh. Right now roughly 7% of repositories were added and
overall process will be finished in a 20-30 hours (it takes me about
5-10
On 2010/08/12 10:52 (GMT-0400) David Malcolm composed:
On Thu, 2010-08-12 at 10:11 -0400, Felix Miata wrote:
Doesn't work in F13 either:
# system-config-display
File /usr/share/system-config-display/xconf.py, line 33, in module
import system_config_keyboard.keyboard as keyboard
On Thu, Aug 12, 2010 at 10:10:25PM +0800, Chen Lei wrote:
I found that systemd-units depends on pkgconfig, is this dependency
really needed for minimum systemd?
Please file things like this in bugzilla so they don't get lost in the chaos
of this discussion list.
--
Matthew Miller
On 2010/08/12 10:52 (GMT-0400) David Malcolm composed:
On Thu, 2010-08-12 at 10:11 -0400, Felix Miata wrote:
I updated system yesterday, installed scd just now:
[init 3]# system-config-display
File /usr/share/system-config-display/xconf.py, line 27, in module
import xf86config
File
On Thu, 2010-08-12 at 10:11 -0400, Felix Miata wrote:
I updated system yesterday, installed scd just now:
[init 3]# system-config-display
File /usr/share/system-config-display/xconf.py, line 27, in module
import xf86config
File /usr/lib/python2.7/site-packages/xf86config.py, line 1,
Hi, everyone. So, we have one bug remaining for Fedora 14 whose blocker
status is unclear:
https://bugzilla.redhat.com/show_bug.cgi?id=596985
Two reporters in the bug - John Reiser and Mike Chambers - and one
reporter from the list - Rui He,
On Thu, 2010-08-12 at 17:07 +0100, Richard W.M. Jones wrote:
On Thu, Aug 12, 2010 at 06:16:52PM +0400, Peter Lemenkov wrote:
Hello All!
I'm currently in process of automatic enlisting of all ~10K Fedora Git
repos at Ohloh. Right now roughly 7% of repositories were added and
overall
Oct 6 2006: Fedora Core 6 release date slip -
http://lists.fedoraproject.org/pipermail/announce/2006-October/002243.html
Oct 16 2006: Another slip in the FC6 schedule -
http://lists.fedoraproject.org/pipermail/announce/2006-October/002248.html
Jul 11 2006: FC6 test2 freeze slipping by a week -
On Thu, 12.08.10 22:10, Chen Lei (supercyp...@gmail.com) wrote:
Hi Lennart,
Heya,
I found that systemd-units depends on pkgconfig, is this dependency
really needed for minimum systemd?
Yes, this is intended this way. udev does the same these days. We
consider .pc files simply a nice way
BN == Bill Nottingham nott...@redhat.com writes:
BN I can't help but note that the slips have become more frequent as we
BN started to actually *have* release criteria to test against. We
BN didn't slip nearly as much when we weren't testing it.
To me this implies that we should begin testing
On 2010/08/12 10:46 (GMT-0700) Adam Williamson composed:
It's more or less dead. ajax technically maintains it, but it's right at
the bottom of his priority list and we've been wanting to drop it for
ages. It's useful for almost nothing these days, especially now GNOME
has a mechanism for
On Thu, Aug 12, 2010 at 2:19 PM, Mike McGrath mmcgr...@redhat.com wrote:
... snip ...
Since 2006 we've slipped at least 16-18 weeks by my count. That's more
than half of a full release cycle.
Actually, I don't think that the slips in the releases have _accumulated_ to
be
'half' of a full
On Thu, Aug 12, 2010 at 8:19 PM, Mike McGrath mmcgr...@redhat.com wrote:
Since 2006 I counted 18 slips (I think one or two of those may just be a
single slip listed twice). Lets not yell, lets not flame war, lets not
point fingers. How can we fix this?
It isn't broken so there is nothing to
On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
BN == Bill Nottingham nott...@redhat.com writes:
BN I can't help but note that the slips have become more frequent as we
BN started to actually *have* release criteria to test against. We
BN didn't slip nearly as much when we weren't testing
Felix Miata (mrma...@earthlink.net) said:
So users of absent or dysfunctional DDC and/or EDID should be committed to
800x600 or 1024x768 @96DPI until they replace their (quality, antique, still
working just fine) displays
Just as a point, if the EDID/DDC is dysfunctional, then I don't think
commit 7dfb64501728fe5f414283fc4225f9846abb4431
Author: Paul Howarth p...@city-fan.org
Date: Thu Aug 12 19:39:41 2010 +0100
Resurrect for EPEL-6
Package has disappeared from RHEL-6 as of the Beta 2 Refresh, so this
package,
a clone of what was in Beta 2, is being introduced in
On 12/08/10 19:19, Mike McGrath wrote:
snip
How can we fix this? It's clearly not one group or one
individual or we'd just go talk to them. This is a collective failure.
snip
I don't think it's any failure, just that more ppl are finding problems
across a greater variety of both
On 12/08/10 19:19, Mike McGrath wrote:
snip
How can we fix this? It's clearly not one group or one
individual or we'd just go talk to them. This is a collective failure.
snip
I don't think it's any failure, just that more ppl are finding problems
across a greater variety of both
On Thu, 2010-08-12 at 14:32 -0400, Felix Miata wrote:
The reason I started this thread is precisely because I have little tolerance
for being stuck in last century's 1024x...@96dpi lowfi on a display I've been
running 2048x1536 on for roughly a decade. Before xrandr, X could itself
perform
On Thu, Aug 12, 2010 at 13:27:05 +0200,
Jaroslav Reznik jrez...@redhat.com wrote:
Problem is not an image (we will provide it in the future, forever), the
issue
is size constraint - software grows faster and faster, we have more
dependencies
etc. - means less software on LiveCD...
I
On Thu, 12 Aug 2010, Bill Nottingham wrote:
Matthias Clasen (mcla...@redhat.com) said:
This is a collective failure.
I'd like to question that premise. Why is it a failure if we adjust our
release schedule to meet our release criteria ?
Well, ideally we'd be able to schedule such
On 08/12/2010 02:39 PM, Mike McGrath wrote:
On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
BN == Bill Nottingham nott...@redhat.com writes:
BN I can't help but note that the slips have become more frequent as we
BN started to actually *have* release criteria to test against. We
BN didn't
MM == Mike McGrath mmcgr...@redhat.com writes:
MM Possibly also stop changing earlier?
Not necessarily. We should certainly try to get the earth shattering
changes done as early as possible (i.e. soon after branch) but I
recognize that there isn't sufficient developer time available to both
On Thu, 2010-08-12 at 14:32 -0400, Felix Miata wrote:
On 2010/08/12 10:46 (GMT-0700) Adam Williamson composed:
It's more or less dead. ajax technically maintains it, but it's right at
the bottom of his priority list and we've been wanting to drop it for
ages. It's useful for almost
On Thu, Aug 12, 2010 at 14:50:38 -0400,
Nathaniel McCallum nathan...@natemccallum.com wrote:
One thing I am curious about is why, when slipping for an Alpha target,
the whole schedule slips. Can't we just take a week out of the Beta
cycle? The amount of testing time is roughly the same.
On Thu, 2010-08-12 at 13:50 -0500, Mike McGrath wrote:
Any of the QA guys have any way to measure the the most common cause of
our slips? Is it usually stuff we're our own upstream for? Is it
integration? Is it bugs that were introduced months ago but only recently
found or bugs that were
On 2010/08/12 14:38 (GMT-0400) Bill Nottingham composed:
Felix Miata said:
So users of absent or dysfunctional DDC and/or EDID should be committed to
800x600 or 1024x768 @96DPI until they replace their (quality, antique, still
working just fine) displays
Just as a point, if the EDID/DDC
On 08/12/2010 02:39 PM, drago01 wrote:
On Thu, Aug 12, 2010 at 8:19 PM, Mike McGrath mmcgr...@redhat.com wrote:
Since 2006 I counted 18 slips (I think one or two of those may just be a
single slip listed twice). Lets not yell, lets not flame war, lets not
point fingers. How can we fix
On Thu, Aug 12, 2010 at 13:19:29 -0500,
Mike McGrath mmcgr...@redhat.com wrote:
Since 2006 we've slipped at least 16-18 weeks by my count. That's more
than half of a full release cycle.
Thoughts?
One thing I have noticed is people landing big changes (such as python and
systemd) that break
On Thu, Aug 12, 2010 at 12:00:29 -0700,
Adam Williamson awill...@redhat.com wrote:
We usually catch most initial blockers for any given release at the
first TC stage. Bugs we slip for are usually ones identified at that
stage that we couldn't fix in time, bugs introduced between TC and RC
On 08/12/2010 01:39 PM, Mike McGrath wrote:
On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
BN == Bill Nottinghamnott...@redhat.com writes:
BN I can't help but note that the slips have become more frequent as we
BN started to actually *have* release criteria to test against. We
BN
On 08/12/2010 01:51 PM, Jason L Tibbitts III wrote:
MM == Mike McGrathmmcgr...@redhat.com writes:
MM Possibly also stop changing earlier?
Not necessarily. We should certainly try to get the earth shattering
changes done as early as possible (i.e. soon after branch) but I
recognize that
On 08/12/2010 03:03 PM, Bruno Wolff III wrote:
On Thu, Aug 12, 2010 at 13:19:29 -0500,
Mike McGrath mmcgr...@redhat.com wrote:
Since 2006 we've slipped at least 16-18 weeks by my count. That's more
than half of a full release cycle.
Thoughts?
One thing I have noticed is people landing
On 2010/08/12 11:55 (GMT-0700) Adam Williamson composed:
if you want to maintain s-c-d, I'm sure ajax would be more than
happy to hand over ownership.
Being a non-programmer I'm confident there's little likelihood I'd be
competent to attempt such an endeavor. Nevertheless, my complaints are
On 08/12/2010 03:08 PM, Jon Ciesla wrote:
On 08/12/2010 01:39 PM, Mike McGrath wrote:
On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
BN == Bill Nottinghamnott...@redhat.com writes:
BN I can't help but note that the slips have become more frequent as we
BN started to actually *have*
On 08/12/2010 02:14 PM, Nathaniel McCallum wrote:
On 08/12/2010 03:08 PM, Jon Ciesla wrote:
On 08/12/2010 01:39 PM, Mike McGrath wrote:
On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
BN == Bill Nottinghamnott...@redhat.com writes:
BN I can't help but note that the slips have
Jon Ciesla (l...@jcomserv.net) said:
I disagree that a clockwork release schedule is required for quality, or
even perceived quality. If that's the sort of metric being looked at,
the user is probably best suited to RHEL, CentOS, etc.
It would be interesting to look at RHEL/CentOS to see
On Thu, Aug 12, 2010 at 14:32:21 -0400,
Felix Miata mrma...@earthlink.net wrote:
So users of absent or dysfunctional DDC and/or EDID should be committed to
800x600 or 1024x768 @96DPI until they replace their (quality, antique, still
working just fine) displays or learn the cryptic and
On Thu, 2010-08-12 at 21:33 +0200, Lennart Poettering wrote:
On Thu, 12.08.10 13:19, Mike McGrath (mmcgr...@redhat.com) wrote:
Since 2006 I counted 18 slips (I think one or two of those may just be a
single slip listed twice). Lets not yell, lets not flame war, lets not
point fingers.
On Thu, Aug 12, 2010 at 2:19 PM, Mike McGrath mmcgr...@redhat.com wrote:
Since 2006 I counted 18 slips (I think one or two of those may just be a
single slip listed twice). Lets not yell, lets not flame war, lets not
point fingers. How can we fix this?
[snip]
This is a collective failure.
On Thu, 2010-08-12 at 21:33 +0200, Lennart Poettering wrote:
I want to mention one thing: on opensuse the base
system has a different schedule then the rest of the OS. i.e. the
kernel, gcc, glibc and the low-level tools freeze first, while
everything else may be hacked on a couple of weeks
On Thu, 2010-08-12 at 13:39 -0500, Mike McGrath wrote:
Would an 8[1] month cycle cause fewer slips per release? Fewer bugs?
For me, one of the guiding principles for Fedora QA's work on tools and
policies has been this: time, by itself, doesn't fix anything.
Making the schedules longer isn't
On Thu, 2010-08-12 at 15:00 -0400, Felix Miata wrote:
EDID DDC are mere conveniences unnecessary to the function of the device. I
really couldn't care less whether EDID/DDC exists, much less works. What
matters (works just fine) from a display, which may have been manufactured
before the
On Thu, 2010-08-12 at 15:13 -0400, Felix Miata wrote:
For the benefit of those few, and there will likely always be some, for whom
automatic isn't, some tool is needed upstream in Xorg, possibly SaX2 or SCD
at least as a starting point. A wider call for a maintainer of SaX2 or SCD or
some
http://www.phoronix.com/scan.php?page=news_itempx=ODQ3Mw
I believe I am affected by this issue from time to time.
Any chance that a near future Fedora kernel would contain the fix ?
Thanks
--
devel mailing list
devel@lists.fedoraproject.org
http://www.phoronix.com/scan.php?page=news_itempx=ODQ3OQ
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Le jeudi 12 août 2010 à 13:51 -0500, Jason L Tibbitts III a écrit :
I guess I'm just saying that, if we had the developer time to do it, it
would be super nice if we could get the pre-F15 rawhide is useless bit over
and done with by the time F15 branches. But back in reality, I know
that's a
On Thu, 12.08.10 13:19, Mike McGrath (mmcgr...@redhat.com) wrote:
Since 2006 I counted 18 slips (I think one or two of those may just be a
single slip listed twice). Lets not yell, lets not flame war, lets not
point fingers. How can we fix this? It's clearly not one group or one
individual
On 08/12/2010 02:22 PM, Bill Nottingham wrote:
Jon Ciesla (l...@jcomserv.net) said:
I disagree that a clockwork release schedule is required for quality, or
even perceived quality. If that's the sort of metric being looked at,
the user is probably best suited to RHEL, CentOS, etc.
It would
On Thu, 2010-08-12 at 15:02 -0400, Nathaniel McCallum wrote:
If our schedules aren't reasonably fixed, than others have a hard time
working with us. Loosing users (especially companies with resources to
They are reasonably fixed. Please don't blow this out of proportion. I
don't believe we've
I'll reply here but I'm also bringing together some things in the rest of
the thread... sorry about that.
On Thu, Aug 12, 2010 at 01:19:29PM -0500, Mike McGrath wrote:
Since 2006 I counted 18 slips (I think one or two of those may just be a
single slip listed twice). Lets not yell, lets not
On 2010/08/12 16:53 (GMT-0400) Adam Jackson composed:
On Thu, 2010-08-12 at 15:13 -0400, Felix Miata wrote:
For the benefit of those few, and there will likely always be some, for whom
automatic isn't, some tool is needed upstream in Xorg, possibly SaX2 or SCD
at least as a starting point. A
On 2010/08/12 16:52 (GMT-0400) Adam Jackson composed:
On Thu, 2010-08-12 at 15:00 -0400, Felix Miata wrote:
EDID DDC are mere conveniences unnecessary to the function of the device. I
really couldn't care less whether EDID/DDC exists, much less works. What
matters (works just fine) from a
On Thu, 2010-08-12 at 17:08 -0400, Felix Miata wrote:
On 2010/08/12 16:53 (GMT-0400) Adam Jackson composed:
On Thu, 2010-08-12 at 15:13 -0400, Felix Miata wrote:
For the benefit of those few, and there will likely always be some, for
whom
automatic isn't, some tool is needed upstream
On Thu, 2010-08-12 at 13:19 -0500, Mike McGrath wrote:
How can we fix this?
Step 1 is to realize/admit there is a problem. You've tactfully done
that.
Step 2 is to gather data and knowledge. That doesn't appear to be
happening in these posts.
On the data side, it would be very interesting to
On Thu, Aug 12, 2010 at 13:13, Felix Miata mrma...@earthlink.net wrote:
On 2010/08/12 11:55 (GMT-0700) Adam Williamson composed:
if you want to maintain s-c-d, I'm sure ajax would be more than
happy to hand over ownership.
Being a non-programmer I'm confident there's little likelihood I'd be
Luke Macken wrote:
- Package update acceptance criteria compliance
https://fedoraproject.org/wiki/Package_update_acceptance_criteria
- Disable direct-to-stable pushes
(https://fedorahosted.org/bodhi/ticket/434)
- Minimum time-in-testing requirements
-
Subject: Fedora 14 Blocker Bug Review Meeting 2010-08-13 @ 16:00 UTC (12
PM EST)
When: Friday, 2010-08-13 @ 16:00 UTC (12 PM EST)
Where: #fedora-bugzappers on irc.freenode.net
Here are the current bugs listed as blocking the Alpha release. We'll be
discussing all of these to determine if they
On Fri, 13 Aug 2010 00:31:58 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
I think that this is really going to break our workflow!
I think it's going to help our workflow and provide our users with more
stable updates. Time will tell.
For example, for the Fedora 14 under development, we
Kevin Fenzi wrote:
Well, this has nothing to do with that. We are currently only pushing
to stable those updates that are needed to fix Alpha release blockers
in F14. So, it wouldn't matter here.
It will matter after the Alpha release when urgent dependency fixes will be
withheld for 1 week
On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
- Minimum time-in-testing requirements
- Every day bodhi will look for updates that have been
in testing for N days (fedora: N=7, epel: N=14), and will
add a comment notifying the maintainer that the
Bruno Wolff III wrote:
I hope to occasionally push back a little against this. When LZMA squashfs
makes it upstream (it looks like it won't happen in time for F14) we will
probably gain about 10% on what we can fit in a given size image.
It's quite sad that we're waiting for upstream there.
1 - 100 of 138 matches
Mail list logo
