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-*,
On Wed, Aug 11, 2010 at 19:19, Remi Collet 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 or from your
extensive
Jesse Keating 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 45C6 250E 6F00 984
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2010 12:42 AM, Andreas Schwab wrote:
> Jesse Keating 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.
>
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 anyon
Jesse Keating 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 5EC7 45C6 250E 6
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/
>
> Now it doesn't look that easy. In fact I have no clue how to build
>
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/rpm
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
https://admin.f
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, sor
Martin Gieseking 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
>> package (also br
Hello All!
2010/8/12 Ralf Corsepius :
> 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
https://admin.fedoraproject.org/m
On Thu, 2010-08-12 at 10:59 +0200, Andreas Schwab wrote:
> Martin Gieseking 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
Matt McCutchen writes:
> On Thu, 2010-08-12 at 10:59 +0200, Andreas Schwab wrote:
>> Martin Gieseking 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
-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 always
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 l
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)
PragmARC-20060427-6.fc1
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
>>> Unfo
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 be
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:
>
> http:
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 2010-08-12 09:57:22 EDT
---
thanks, I just missed this one. I'm not an ownership hog so feel
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 http://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
import xf86config
File "/usr/lib/python2.7/site-packages/xf86config.py", line 1, in
import xf86config
ImportError: /usr/lib/python2.7/
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 2010-08-12 10:15:19 EDT
---
Git done (by process-git-requests).
--
Configure bugmail: http
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 proce
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.
--
Fedor
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 po
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
> 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 ot
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)
LuxRender-0
On Thu, 2010-08-12 at 11:20 +0200, Andreas Schwab wrote:
> Matt McCutchen 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 http://pkgs.fedoraproject.org/
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... - reb
commit c1a0b4c23cce4432821234955dde3a086b1f3591
Merge: 81afc0f 2643c13
Author: Paul Howarth
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 but has been dropped
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
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-1
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
>> 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
Senior Sy
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
>> import xf86config
>>
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
> 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,
http://lists.fedoraproject.org/pipermail/test/2010-Augu
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
> > o
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, 2010-08-12 at 13:19 -0500, Mike McGrath wrote:
> 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 ?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/m
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 that we can accomplish
our release criteria wit
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 wa
> "BN" == Bill Nottingham 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 earlier (o
On Thu, 12.08.10 12:06, Bill Nottingham (nott...@redhat.com) wrote:
>
> 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 mostl
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 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 release cycle' beca
On Thu, Aug 12, 2010 at 8:19 PM, 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 flame war, lets not
> point fingers. How can we fix this?
It isn't broken so there is nothing to fix; slipping to
On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
> > "BN" == Bill Nottingham 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.
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
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 EPEL-6 to satisfy
On Thu, 2010-08-12 at 13:29 -0500, Jason L Tibbitts III wrote:
> > "BN" == Bill Nottingham 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'
On 12/08/10 19:19, Mike McGrath wrote:
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.
I don't think it's any failure, just that more ppl are finding problems
across a greater variety of both hard\virtual-ware.
On 12/08/10 19:19, Mike McGrath wrote:
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.
I don't think it's any failure, just that more ppl are finding problems
across a greater variety of both hard\virtual-ware.
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 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 hope to occasi
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 sched
On 08/12/2010 02:39 PM, Mike McGrath wrote:
> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>
>>> "BN" == Bill Nottingham 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> did
> "MM" == Mike McGrath 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
stabilize one
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 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.
We've tried that in the
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 we
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 EDI
On 08/12/2010 02:39 PM, drago01 wrote:
> On Thu, Aug 12, 2010 at 8:19 PM, 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 flame war, lets not
>> point fingers. How can we fix this?
>
> It is
On Thu, Aug 12, 2010 at 13:19:29 -0500,
Mike McGrath 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 things for a wh
On Thu, Aug 12, 2010 at 12:00:29 -0700,
Adam Williamson 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 by
This is anoth
On 08/12/2010 01:39 PM, Mike McGrath wrote:
> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>
>>> "BN" == Bill Nottingham 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> di
On 08/12/2010 01:51 PM, Jason L Tibbitts III wrote:
>> "MM" == Mike McGrath 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
On 08/12/2010 03:03 PM, Bruno Wolff III wrote:
> On Thu, Aug 12, 2010 at 13:19:29 -0500,
> Mike McGrath 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 chang
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 n
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 Nottingham 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 Nottingham 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 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 complicated methodology
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 fing
On Thu, Aug 12, 2010 at 2:19 PM, 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 flame war, lets not
> point fingers. How can we fix this?
[snip]
> This is a collective failure.
While I agree t
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 wee
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_item&px=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
https://admin.fedoraproject.org/mailman/listinfo/d
http://www.phoronix.com/scan.php?page=news_item&px=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
> tha
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
> individ
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.
> I
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'v
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 no
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 po
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) f
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 ne
A new version of bodhi has just hit production. This release contains
a number of bugfixes and improvements, along with some important process
changes.
https://admin.fedoraproject.org/updates
ChangeLog
=
- Package update acceptance criteria compliance
https://fedoraproject
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 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
> competent t
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 m
1 - 100 of 139 matches
Mail list logo
