Re: Proposing new dual booting release criteria
On Wed, Aug 27, 2014 at 4:08 AM, Chris Murphy wrote: > On Aug 24, 2014, at 11:23 AM, Michael Catanzaro wrote: >> Fedora will not become widely popular if it remains dangerous to install. > > At least it doesn't seem more dangerous than any other distribution, but I > agree being trustworthy in this area makes it more likely people will install > it. +1 >> Windows >> === >> (...) >> I propose the language be amended to the following: >> >> "The installer must be able to install into free space alongside an >> existing clean Windows installation and install a bootloader which can >> boot into both Windows and Fedora." >> OS X >> >> (...) >> "The installer must be able to install into free space alongside an >> existing clean OS X installation and install a bootloader which can boot >> into both OS X and Fedora, OR the installer must prominently warn the >> user that he may be unable to boot OS X after installation, allowing the >> user to cancel installation and reboot to OS X." All fine, except that we should maybe feel more than a little concerned about release criteria wordered with *must* and not *should*, when the dependency is a (rather large) piece of proprietary software we have no control of and possibly no access to. François -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Telnetd broken
On Tue, Jan 29, 2013 at 6:37 PM, Chuck Forsberg WA7KGX N2469R wrote: > On 01/29/2013 06:40 AM, Ed Greshko wrote: >> >> On 01/29/2013 10:12 PM, Matthew Miller wrote: >>> >>> On Mon, Jan 28, 2013 at 03:31:25PM -0800, Chuck Forsberg WA7KGX N2469R >>> wrote: The telnet service in Fedora 18 and Rawhide is broken. Here is output from telnet(1) on f18 calling a machine running Rawhide: >>> >>> Confirming on F18. >>> >>> Heh. I bet you're the first person to actually run telnetd in several >>> years. >>> >> FWIW, this seems to be a different manifestation of the problem that I'm >> seeing and asking about out the "users" list. I think you will find that if >> you add >> >> server_args = -D options >> >> to the telnet file of xinetd.d the formatting problem will be gone... >> >> > I've done some more testing. There seems to be a random element to the > problem. > Sometimes the telnet session will operate normally. Other times much of the > output > disappears. Please open a bug, or I'll submit a F19 feature to make telnetd disappear. :) François -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [PATCH] incite bug reporters to post feedback
Hello Luke, test@, bodhi@,
On Sun, Dec 5, 2010 at 6:22 AM, Kevin Fenzi wrote:
> On Sat, 4 Dec 2010 17:56:42 +0100
> François Cami wrote:
>
>> The following patch tentatively changes the message bodhi posts to
>> bugzilla when a build is tagged as an update candidate to make clear
>> that we expect bug reporters to post their feedbacks on updates in the
>> bodhi instance.
>> Please review the message - I am sure someone can make it better.
>
> See also:
>
> https://fedorahosted.org/fedora-infrastructure/ticket/701
I have attached a refined version of the patch to this email, that
hopefully takes into account all the feedboack from Monday's QA
meeting.
I don't think this is a perfect solution and it clearly does not solve
all the issues listed in the afore-mentioned ticket but should still
incite bug reporters to post feedback / karma.
Cheers
François
From 8a0bff89f87452a6e8231ef6612f05f5c0be1869 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fran=C3=A7ois=20Cami?=
Date: Tue, 14 Dec 2010 19:00:59 +0100
Subject: [PATCH] ask bug reporters to test updates and post karma
---
bodhi/controllers.py | 30 --
1 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/bodhi/controllers.py b/bodhi/controllers.py
index f323291..9456ad1 100644
--- a/bodhi/controllers.py
+++ b/bodhi/controllers.py
@@ -971,9 +971,18 @@ class Root(controllers.RootController):
log.debug("Updating newly added bug: %s" % bug)
try:
Bugzilla.byBz_id(bug).add_comment(update,
-"%s has been submitted as an update for %s.\n%s" %
-(update.title, release.long_name,
- config.get('base_address') + tg_url(update.get_url(
+"Package %s:\n"
+"* should fix your issue,\n"
+"* was pushed to the %s updates-testing repository,\n"
+"* should be available at your local mirror within two days.\n"
+"Update it with:\n"
+"# su -c 'yum update --enablerepo=updates-testing %s'\n"
+"as soon as you are able to, then reboot.\n"
+"Please go to the following url:\n"
+"%s\n"
+"then log in and leave karma (feedback)." %
+(update.title, release.long_name, update.title,
+config.get('base_address') + tg_url(update.get_url(
except SQLObjectNotFound:
log.debug('Bug #%d not found in our database' % bug)
@@ -992,9 +1001,18 @@ class Root(controllers.RootController):
# Comment on all bugs
for bug in update.bugs:
bug.add_comment(update,
-"%s has been submitted as an update for %s.\n%s" %
-(update.title, release.long_name,
- config.get('base_address') + tg_url(update.get_url(
+"Package %s:\n"
+"* should fix your issue,\n"
+"* was pushed to the %s updates-testing repository,\n"
+"* should be available at your local mirror within two days.\n"
+"Update it with:\n"
+"# su -c 'yum update --enablerepo=updates-testing %s'\n"
+"as soon as you are able to, then reboot.\n"
+"Please go to the following url:\n"
+"%s\n"
+"then log in and leave karma (feedback)." %
+(update.title, release.long_name, update.title,
+config.get('base_address') + tg_url(update.get_url(
# If a request is specified, make it. By default we're submitting
# new updates directly into testing
--
1.7.3.3
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
[PATCH] incite bug reporters to post feedback
Hi bodhi@, test@,
The following patch tentatively changes the message bodhi posts to
bugzilla when a build is tagged as an update candidate to make clear
that we expect bug reporters to post their feedbacks on updates in the
bodhi instance.
Please review the message - I am sure someone can make it better.
Caveat emptor: I do not have a bodhi+koji+bz instance, so this is
completely untested.
Signed-Off-By: François Cami
Patch also attached because I'm pretty sure the inline version will get mangled.
diff --git a/bodhi/controllers.py b/bodhi/controllers.py
index f323291..3c55512 100644
--- a/bodhi/controllers.py
+++ b/bodhi/controllers.py
@@ -971,9 +971,12 @@ class Root(controllers.RootController):
log.debug("Updating newly added bug: %s" % bug)
try:
Bugzilla.byBz_id(bug).add_comment(update,
-"%s has been submitted as an update
for %s.\n%s" %
-(update.title, release.long_name,
- config.get('base_address') +
tg_url(update.get_url(
+"%s has been submitted as an update
for %s and "
+"will soon be available in the
updates-testing "
+"repository. Please comment on your
experience at:\n"
+"%s" % (
+ update.title, release.long_name,
+ config.get('base_address') +
tg_url(update.get_url(
except SQLObjectNotFound:
log.debug('Bug #%d not found in our
database' % bug)
@@ -992,9 +995,12 @@ class Root(controllers.RootController):
# Comment on all bugs
for bug in update.bugs:
bug.add_comment(update,
-"%s has been submitted as an update for %s.\n%s" %
-(update.title, release.long_name,
- config.get('base_address') +
tg_url(update.get_url(
+"%s has been submitted as an update for %s and "
+"will soon be available in the updates-testing "
+"repository. Please comment on your experience at:\n"
+"%s" % (
+ update.title, release.long_name,
+ config.get('base_address') +
tg_url(update.get_url(
# If a request is specified, make it. By default we're submitting
# new updates directly into testing
--
1.7.3.2
From 8bf87c398701f5b8571d6cdffa3d81afd1ed34b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fran=C3=A7ois=20Cami?=
Date: Sat, 4 Dec 2010 17:42:17 +0100
Subject: [PATCH] edit bz message so that reporters leave comments+karma in bodhi.
---
bodhi/controllers.py | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/bodhi/controllers.py b/bodhi/controllers.py
index f323291..3c55512 100644
--- a/bodhi/controllers.py
+++ b/bodhi/controllers.py
@@ -971,9 +971,12 @@ class Root(controllers.RootController):
log.debug("Updating newly added bug: %s" % bug)
try:
Bugzilla.byBz_id(bug).add_comment(update,
-"%s has been submitted as an update for %s.\n%s" %
-(update.title, release.long_name,
- config.get('base_address') + tg_url(update.get_url(
+"%s has been submitted as an update for %s and "
+"will soon be available in the updates-testing "
+"repository. Please comment on your experience at:\n"
+"%s" % (
+ update.title, release.long_name,
+ config.get('base_address') + tg_url(update.get_url(
except SQLObjectNotFound:
log.debug('Bug #%d not found in our database' % bug)
@@ -992,9 +995,12 @@ class Root(controllers.RootController):
# Comment on all bugs
for bug in update.bugs:
bug.add_comment(update,
-"%s has been submitted as an update for %s.\n%s" %
-(update.title, release.long_name,
- config.get('base_address') + tg_url(update.get_url(
+"%s has been submitted as an update for %s and &
Re: Radeon power management and KMS
On Sat, Nov 20, 2010 at 8:29 AM, Christoph Frieben wrote: > What's up with Radeon power management under KMS? The most recent > related entries in the kernel change log read: > > * Sun Jun 13 2010 Kyle McMartin 2.6.34-34 > - Provide a knob to enable radeon_pm to allow users to test > that functionality. Add radeon.pm=1 to your kernel cmdline > in order to enable it. (It still defaults to off though.) > > However, kernel option radeon.pm has no effect > Has support for this feature been discarded in Fedora kernels? These changelog entries were for 2.6.34 (f13), and I take it you're running f14+ and looking at 2.6.35. Both dynpm and radeon_pm were eliminated from 2.6.35. Radeon power management features are now controlled via sysfs. First, select a power management method, by echoing "dynpm" or "profile" to /sys/class/drm/card-0/device/power_method. It seems that dynpm can produce display artifacts, so you probably want to choose "profile" (which is the default). If you choose the profile method, then you can switch from the "default", "auto", "low", "mid", "high" profiles by echoing the relevant keyword to /sys/class/drm/card-0/device/power_profile. More info there: http://wiki.x.org/wiki/RadeonFeature Relevant commit diff: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ce8f53709bf440100cb9d31b1303291551cf517f François -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: perl-Sys-Virt-0.2.4 not in Fedora 14?
On Fri, Aug 13, 2010 at 10:05 PM, Paul A. Crook wrote: > One of the systems here has been tracking rawhide for a while and latterly 14 > (after it branched) using yum updates. > > I've notice lots of perl updates are currently blocked by the package perl- > Sys-Virt-0.2.4-1.f14 which is installed on the system and depends on > perl-5.10. However looking in the fedora 14 repository I can only find perl- > Sys-Virt-0.2.3-2.f14 (which appears to have been built against perl-5.12). > > Would I be right in thinking perl-Sys-Virt-0.2.4-1 been dropped from F14 and I > need to somehow convince yum to install perl-Sys-Virt-0.2.3-2 instead? It was built: http://koji.fedoraproject.org/koji/buildinfo?buildID=174156 But AFAICT it was not pushed to the mirrors. Adding Daniel Berrange in CC. In the meantime, you can install it from Koji. François -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters
On Fri, Aug 13, 2010 at 12:25 AM, Patrick Lists wrote: > On 08/13/2010 12:23 AM, Clyde E. Kunkel wrote: > [snip] >> Using nomodeset allows x to start on a: >> >> $ lspci | grep VGA >> 01:00.0 VGA compatible controller: ATI Technologies Inc RV630 [Radeon HD >> 2600 Series] > > Is nomodeset different from radeon.modeset=0? In other words should I > test this too besides radeon.modeset=0? Either one is fine. -- fdc -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters
On Thu, Aug 12, 2010 at 11:59 PM, Patrick Lists wrote: > On 08/12/2010 10:43 PM, Adam Williamson wrote: >> On Thu, 2010-08-12 at 22:35 +0200, François Cami wrote: >> >>> OK here on RV410 (Radeon X700 Pro, R400 family), using KMS. >>> I will be testing older cards (Radeon 7500, FireGL 8800) as time permits. >> >> Thanks, Francois! Jerome mentioned he has a reproducer now, a specific >> monitor, but the testing is still useful to help us figure out how wide >> the impact of this is. > > Just tested the boot.iso you mentioned earlier on an Acer laptop > (TM6465WLMi) with an ATI X1300 videocard and it fails miserably when X > is started. The screen becomes totally greenish it first fading to > something more white. What happens when you add radeon.modeset=0 on the CD command line? -- fdc -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters
On Thu, Aug 12, 2010 at 7:59 PM, Adam Williamson wrote: > 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-August/092583.html - > report that the screen is blanked when the installer starts X on various > Radeon adapters when booted with default options. The system is still > running and you can switch to a virtual console to get logs - see > https://bugzilla.redhat.com/show_bug.cgi?id=596985#c36 - but the screen > is permanently blank until reboot. When booted with 'basic video driver' > - which, due to an anaconda bug, actually results in the use of the > radeon driver, but with kernel modesetting disabled - the installer is > able to run X normally, for all three. One further reporter, Chuck > Forsberg - > http://lists.fedoraproject.org/pipermail/test/2010-August/092581.html - > had problems with both default and 'basic video mode' (radeon+UMS). > > Jerome Glisse reports that he was able to start X and see the display in > the installer with one or some of his own test cards. > > What we need here is more data. So it would be really useful if everyone > on this list with a Radeon video adapter could test this. It's fairly > quick and easy and doesn't require you to actually complete an install. > Just get the boot.iso for RC3 (currently) or RC4 (later today, likely) - > the boot.iso for RC3 is at > http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Alpha.RC3/Fedora/x86_64/os/images/boot.iso > or > http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Alpha.RC3/Fedora/i386/os/images/boot.iso > - boot it, and see if you can make it to the graphical stage of the > installation process. Please reply here, and if you observe the same problem > as the reporters, add your details to the bug report (also test the 'basic > graphics driver' choice, and report whether you used rc3 or rc4, and x86-64 > or i386). Thanks! OK here on RV410 (Radeon X700 Pro, R400 family), using KMS. I will be testing older cards (Radeon 7500, FireGL 8800) as time permits. Cheers François -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
