Re: F23 Brightness reduces itself, this problem also in F24?

2016-05-18 Thread Joerg Lechner 

 



Hi Chris,
I am just starting to understand. "You turn off the support in g-c-c" I don't 
understand, whats to be done?. I have installed Colorhug Backlight Utility, a 
screenshot shows the first display of this app after installation, so far I did 
not make any adjustments. Can You tell me, how I can get, what You need, please 
explain for a none expert.
If there is Lux 0, does this mean, that in my Laptop there is no sensor?
kind regards

 

 

 

-Ursprüngliche Mitteilung- 
Von: Chris Murphy 
Verschickt: Mi, 18 Mai 2016 7:30 pm
Betreff: Re: F23 Brightness reduces itself, this problem also in F24?

On Wed, May 18, 2016 at 11:15 AM, Chris Murphy  
wrote:> Daytime: Ambient reports either 61 Lux -  43 Lux the whole day. At 58> 
Lux, backlight looks like 75% according to the graph. There's no raw> value 
visible. And I'm not inclined to change the brightness. But even> if it went up 
or down, chasing this narrow ambient range, I wouldn't> notice it.58 Lux and 
75%, turned automatic back to On, and 2 minutes later thebrightness is 
automatically bumped to 85 in one event (two notches),even though ambient 
hasn't changed. So that's unexpected. It's notthat noticeable visually. I 
probably would not make a change had I notbeen looking right at CBU when it 
happened.I've changed it back to 75% and after 5 minutes, still at 57 Lux 
and75%, so it hasn't changed again yet.-- Chris Murphy--test mailing 
listtest@lists.fedoraproject.orgTo 
unsubscribe:http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org




--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: F23 Brightness reduces itself, this problem also in F24?

2016-05-18 Thread Chris Murphy 
On Wed, May 18, 2016 at 11:15 AM, Chris Murphy  wrote:

> And then there's the fact this light sensor in the laptop is under one
> of the speaker grills, so it's probably not a totally hideous way to
> approximate an integrating sphere? But...

There's at least 10 Lux, maybe as much as 30 Lux in the room right now
but ColorHung Backlight Utility is reporting 0.0 Lux. So there goes
the idea that it's not a hideous sensor. I've got brightness at 30%
which in journalctl is reported as:
May 18 21:02:31 f24m pkexec[7694]: chris: Executing command
[USER=root] [TTY=unknown] [CWD=/home/chris]
[COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 33120]





-- 
Chris Murphy
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: F24 workstation (upgraded) hang on reboot/shutdown?

2016-05-18 Thread Chris Murphy 
On Wed, May 18, 2016 at 4:50 PM, Felix Miata <mrma...@earthlink.net> wrote:
> Chris Murphy composed on 2016-05-18 16:32 (UTC-0600):
>
>> Chris Murphy> wrote:
>
>
>>> 90 second hang at reboot, lsof reports many user session processes
>>> aren't quitting
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1337307
>
>
>>> There are a bunch of services running as user chris that do not quit
>>> well after a log out. I think that's what's causing exactly 1m30s hang
>>> when trying to reboot or shutdown. Is anyone else seeing this? Was it
>>> a clean install or an upgrade?
>
>
>>> My case is an upgrade with Gnome Software. It wasn't happening with
>>> Fedora 23 before the upgrade. I haven't yet tried a clean install of
>>> Fedora 24. I'd think if this were widespread there'd be complaints by
>>> now.
>
>
>> Well it happens with a clean installation of
>> Fedora-Workstation-Live-x86_64-24-20160518.n.0.iso so I'm not sure
>> what's up... but whatever the cause is, systemd is giving up on
>> whatever won't quit on its own exactly 1m30s after I ask for a
>> shutdown every time. The log is not exactly revealing even with
>> systemd.log_level=debug enabled.
>
>
> Does the delay disappear if you immediately precede shutdown order with
> 'umount -a -t cifs -t nfs' or some variant or subset thereof?

No.

reboot -f does work instantly so it's definitely not a kernel problem.
Basically something(s) isn't quitting in the user session and so
systemd is waiting for the user session to die or whatever the term
is, and then it'll continue with reboot. But that user session doesn't
ever die, and therefore the 1m30 systemd timeout applies for the user
session and is just kills the session and reboots.

The only thing mounted is a local file system. It's super basic.

-- 
Chris Murphy
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: F24 workstation (upgraded) hang on reboot/shutdown?

2016-05-18 Thread Felix Miata 

Chris Murphy composed on 2016-05-18 16:32 (UTC-0600):


Chris Murphy> wrote:



90 second hang at reboot, lsof reports many user session processes
aren't quitting
https://bugzilla.redhat.com/show_bug.cgi?id=1337307



There are a bunch of services running as user chris that do not quit
well after a log out. I think that's what's causing exactly 1m30s hang
when trying to reboot or shutdown. Is anyone else seeing this? Was it
a clean install or an upgrade?



My case is an upgrade with Gnome Software. It wasn't happening with
Fedora 23 before the upgrade. I haven't yet tried a clean install of
Fedora 24. I'd think if this were widespread there'd be complaints by
now.



Well it happens with a clean installation of
Fedora-Workstation-Live-x86_64-24-20160518.n.0.iso so I'm not sure
what's up... but whatever the cause is, systemd is giving up on
whatever won't quit on its own exactly 1m30s after I ask for a
shutdown every time. The log is not exactly revealing even with
systemd.log_level=debug enabled.


Does the delay disappear if you immediately precede shutdown order with 
'umount -a -t cifs -t nfs' or some variant or subset thereof?

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: F24 workstation (upgraded) hang on reboot/shutdown?

2016-05-18 Thread Chris Murphy 
On Wed, May 18, 2016 at 3:34 PM, Chris Murphy <li...@colorremedies.com> wrote:
> 90 second hang at reboot, lsof reports many user session processes
> aren't quitting
> https://bugzilla.redhat.com/show_bug.cgi?id=1337307
>
> There are a bunch of services running as user chris that do not quit
> well after a log out. I think that's what's causing exactly 1m30s hang
> when trying to reboot or shutdown. Is anyone else seeing this? Was it
> a clean install or an upgrade?
>
> My case is an upgrade with Gnome Software. It wasn't happening with
> Fedora 23 before the upgrade. I haven't yet tried a clean install of
> Fedora 24. I'd think if this were widespread there'd be complaints by
> now.

Well it happens with a clean installation of
Fedora-Workstation-Live-x86_64-24-20160518.n.0.iso so I'm not sure
what's up... but whatever the cause is, systemd is giving up on
whatever won't quit on its own exactly 1m30s after I ask for a
shutdown every time. The log is not exactly revealing even with
systemd.log_level=debug enabled.

-- 
Chris Murphy
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

F24 workstation (upgraded) hang on reboot/shutdown?

2016-05-18 Thread Chris Murphy 
90 second hang at reboot, lsof reports many user session processes
aren't quitting
https://bugzilla.redhat.com/show_bug.cgi?id=1337307

There are a bunch of services running as user chris that do not quit
well after a log out. I think that's what's causing exactly 1m30s hang
when trying to reboot or shutdown. Is anyone else seeing this? Was it
a clean install or an upgrade?

My case is an upgrade with Gnome Software. It wasn't happening with
Fedora 23 before the upgrade. I haven't yet tried a clean install of
Fedora 24. I'd think if this were widespread there'd be complaints by
now.

-- 
Chris Murphy
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Fedora Rawhide-20160518.n.0 compose check report

2016-05-18 Thread Fedora compose checker 
Missing expected images:

Cloud_base raw-xz i386
Atomic raw-xz x86_64
Kde raw-xz armhfp
Minimal raw-xz armhfp

Failed openQA tests: 27/72 (x86_64), 5/17 (i386)

ID: 17980   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/17980
ID: 17981   Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/17981
ID: 17982   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/17982
ID: 17983   Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/17983
ID: 17990   Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/17990
ID: 17993   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/17993
ID: 17995   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/17995
ID: 17997   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/17997
ID: 18001   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/18001
ID: 18003   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/18003
ID: 18004   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/18004
ID: 18005   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/18005
ID: 18017   Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/18017
ID: 18021   Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/18021
ID: 18033   Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/18033
ID: 18034   Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/18034
ID: 18035   Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/18035
ID: 18036   Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/18036
ID: 18037   Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/18037
ID: 18038   Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/18038
ID: 18039   Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/18039
ID: 18040   Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/18040
ID: 18041   Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/18041
ID: 18042   Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/18042
ID: 18045   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/18045
ID: 18047   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/18047
ID: 18049   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/18049
ID: 18050   Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/18050
ID: 18051   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/18051
ID: 18066   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/18066
ID: 18067   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/18067
ID: 18068   Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/18068

Passed openQA tests: 36/72 (x86_64), 12/17 (i386)

Skipped openQA tests: 8 of 89
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Fedora 24-20160518.n.0 compose check report

2016-05-18 Thread Fedora compose checker 
Missing expected images:

Kde live i386
Kde live x86_64
Cloud_base raw-xz i386

Failed openQA tests: 6/66 (x86_64), 2/16 (i386)

ID: 18075   Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/18075
ID: 18081   Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/18081
ID: 18083   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/18083
ID: 18129   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/18129
ID: 18133   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/18133
ID: 18137   Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/18137
ID: 18148   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/18148
ID: 18150   Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/18150

Passed openQA tests: 59/66 (x86_64), 14/16 (i386)

-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: [Test-Announce] Fedora 24 Branched 20160518.n.0 nightly compose nominated for testing

2016-05-18 Thread Adam Williamson 
On Wed, 2016-05-18 at 11:04 -0700, rawh...@fedoraproject.org wrote:
> Announcing the creation of a new nightly release validation test event
> for Fedora 24 Branched 20160518.n.0. Please help run some tests for this
> nightly compose if you have time. For more information on nightly
> release validation testing, see:
> https://fedoraproject.org/wiki/QA:Release_validation_test_plan

In case anyone was wondering why this hadn't happened for a while,
turns out there's a bug in hawkey:

https://github.com/rpm-software-management/libhif/issues/125

which makes it think 4.0.14-3 is lower than 4.0.7-1, for some reason.
So the bot thought the pungi package in current nightlies was older
than the pungi package in Beta-1.6, which makes it refuse to create an
event (this is intended to prevent creating an event for a nightly
because the 'package versions are different' when the candidate compose
has a *newer* package that was pulled in through the side tag).

So every day it decided not to create a new event because it thought
the nightlies had an older package than Beta. I fixed it to use a
different EVR comparison function which isn't broken. Sorry for the
trouble! Let's get going on Final validation.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

[Test-Announce] Fedora 24 Branched 20160518.n.0 nightly compose nominated for testing

2016-05-18 Thread rawhide 
Announcing the creation of a new nightly release validation test event
for Fedora 24 Branched 20160518.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
pungi - 1.6: pungi-4.0.7-1.fc24.src, 20160518.n.0: pungi-4.0.14-3.fc24.src
pykickstart - 1.6: pykickstart-2.25-2.fc24.src, 20160518.n.0: 
pykickstart-2.25-3.fc24.src
lorax - 1.6: lorax-24.17-1.fc24.src, 20160518.n.0: lorax-24.18-1.fc24.src
python-blivet - 1.6: python-blivet-1.20.1-1.fc24.src, 20160518.n.0: 
python-blivet-1.20.2-1.fc24.src
anaconda - 1.6: anaconda-24.13.4-1.fc24.src, 20160518.n.0: 
anaconda-24.13.5-1.fc24.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/24

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160518.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160518.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160518.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160518.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160518.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160518.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160518.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relval: https://www.happyassassin.net/relval/
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: F23 Brightness reduces itself, this problem also in F24?

2016-05-18 Thread Chris Murphy 
On Wed, May 18, 2016 at 11:15 AM, Chris Murphy  wrote:

> Daytime: Ambient reports either 61 Lux -  43 Lux the whole day. At 58
> Lux, backlight looks like 75% according to the graph. There's no raw
> value visible. And I'm not inclined to change the brightness. But even
> if it went up or down, chasing this narrow ambient range, I wouldn't
> notice it.

58 Lux and 75%, turned automatic back to On, and 2 minutes later the
brightness is automatically bumped to 85 in one event (two notches),
even though ambient hasn't changed. So that's unexpected. It's not
that noticeable visually. I probably would not make a change had I not
been looking right at CBU when it happened.

I've changed it back to 75% and after 5 minutes, still at 57 Lux and
75%, so it hasn't changed again yet.


-- 
Chris Murphy
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: F23 Brightness reduces itself, this problem also in F24?

2016-05-18 Thread Chris Murphy 
On Wed, May 18, 2016 at 9:03 AM, Richard Hughes  wrote:
> On 17 May 2016 at 22:33, Chris Murphy  wrote:
>> Settings > Power > Automatic brightness = On is the problem.
>
> This is probably my doing, I added the feature for F23 IIRC.
>
>> On my system it'll even go to the last setting and turn the
>> display off as the room gets dark.
>
> So setting the panel to 0% is a bug that sounds like one that's
> already fixed. What hardware is this?

[0.00] DMI: Apple Inc. MacBookPro8,2/Mac-94245A3940C91C80,
BIOSMBP81.88Z.0047.B2C.1510261540 10/26/15

x-session info here:
https://drive.google.com/open?id=0B_2Asp8DGjJ9T2U2VVQ0NUtNTW8




>
>> It works better On than Off for daytime cloud fluctuations. But as the
>> day transitions into night, the reduction in screen brightness is too
>> aggressive.
>
> So this is where the "minimum configuration" in GNOME kinda hurts;
> it's hard to pick an adaptive algorithm (or rather, coefficients for
> an algorithm) that works for everyone.

Well there's no way to know where the nit drop off is, as the
backlight is lowered, without measuring it, is there? The backlight
control looks like it works in 5% increments and on this display
there's a pronounced drop off in brightness right at 20 to 15%, and
again 15 to 10% and a huge one at 10 - 5%. There's a definite
non-linearity at this low range. I don't know the threshold between
software and hardware but I'd guess that the software is just sending
the minimum increment/decrement value to the panel and we get what we
get from the panel, i.e. thre  is no such thing as 1% increments, at
least for this panel. It's the same granularity in OS X so I expect
it's fixed in the panel.

 If your hardware is supported,
> can you turn off the support in g-c-c and install the "ColorHug
> Backlight Utility" -- don't be scared of the name, it should support
> other sensors as well. There you can tweak the numbers, although we
> can't actually "set" them anywhere for GNOME to use. I'd be interested
> in knowing what values you settle on for your hardware.

Daytime: Ambient reports either 61 Lux -  43 Lux the whole day. At 58
Lux, backlight looks like 75% according to the graph. There's no raw
value visible. And I'm not inclined to change the brightness. But even
if it went up or down, chasing this narrow ambient range, I wouldn't
notice it.

I'll have to wait and see what happens as the terminator crosses my
path, but I'm gonna guess that at some point the automatic setting is
dropping brightness too much, given the panel's drop off behavior, too
soon, and also goes too far. It's a noticeable drop off in the day
time, at night when adaptation is mesopic and becoming scotopic, I'm
more sensitive to these changes. So they seems more pronounced.

Thing is, OS X doesn't get it right either, so I'm used to hitting a
button to readjust it. It's just a different behavior in GNOME than OS
X. I mean, I say "WTF psycho display" out loud no matter which OS I'm
using.

But yeah, between the display brightness drop off at the low end, and
the human blob becoming more sensitive due to transitioning away from
photopic adaptation, it's a fun little problem. And the thing is, I
don't adapt at the same rate as the ambient changes. So the thing to
chase at a certain ambient is an estimate of the user's adaptation,
not the ambient. So the ambient goes down down down, keep brightness
the same, ambient stabilizes, user adapts downward and becomes more
sensitive so now the display needs to come down one notch and then a
minute or 10 later, another notch even though ambient hasn't changed.

And then there's the fact this light sensor in the laptop is under one
of the speaker grills, so it's probably not a totally hideous way to
approximate an integrating sphere? But...



-- 
Chris Murphy
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: F23 Brightness reduces itself, this problem also in F24?

2016-05-18 Thread Richard Hughes 
On 17 May 2016 at 22:33, Chris Murphy  wrote:
> Settings > Power > Automatic brightness = On is the problem.

This is probably my doing, I added the feature for F23 IIRC.

> On my system it'll even go to the last setting and turn the
> display off as the room gets dark.

So setting the panel to 0% is a bug that sounds like one that's
already fixed. What hardware is this?

> It works better On than Off for daytime cloud fluctuations. But as the
> day transitions into night, the reduction in screen brightness is too
> aggressive.

So this is where the "minimum configuration" in GNOME kinda hurts;
it's hard to pick an adaptive algorithm (or rather, coefficients for
an algorithm) that works for everyone. If your hardware is supported,
can you turn off the support in g-c-c and install the "ColorHug
Backlight Utility" -- don't be scared of the name, it should support
other sensors as well. There you can tweak the numbers, although we
can't actually "set" them anywhere for GNOME to use. I'd be interested
in knowing what values you settle on for your hardware.

Thanks,

Richard.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: release criteria for final - bug 1320967

2016-05-18 Thread Ahmad Samir 
On 18 May 2016 at 14:41, Joerg Lechner  wrote:

> Hi,
> my question and suggestion is not to have an important issue like this
> -for having one computer as test machine for a new release and in parallell
> for another OS -  as a blocker for Final but earlier as a blocker for Alpha
> or Beta, then at least for me it's easier to help testing in a new release.


I misunderstood then, sorry about the noise :|.


> This is a suggestion for F25, currently for my use I  can still run F23 ||
> Win 8.1, but I can not so easily contribute to F24 testing. Is there a bug
> report helpful?
> Kind regards
>
>
>
I am not sure about the process/procedure to change the criteria, but
posting to this list is a logical first step, I think.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: release criteria for final - bug 1320967

2016-05-18 Thread Joerg Lechner 
Hi, 
my question and suggestion is not to have an important issue like this -for 
having one computer as test machine for a new release and in parallell for 
another OS -  as a blocker for Final but earlier as a blocker for Alpha or 
Beta, then at least for me it's easier to help testing in a new release. This 
is a suggestion for F25, currently for my use I  can still run F23 || Win 8.1, 
but I can not so easily contribute to F24 testing. Is there a bug report 
helpful?
Kind regards

 

 

 

-Ursprüngliche Mitteilung- 
Von: Ahmad Samir 
An: For testing and quality assurance of Fedora releases 

Verschickt: Mi, 18 Mai 2016 1:36 pm
Betreff: Re: release criteria for final - bug 1320967





On 18 May 2016 at 07:39, Joerg Lechner  wrote:

Hi,
I use an about one year old Acer laptop, internal disk Win 8.1, F23/F24 on usb 
flash media, for F20/21/22/23 I tested as user, using the Fedora version in 
development. Because of " 
F24 Alpha 1.7 Desktop - Grub boot menue, not possible to start Win 8.1" - Bug 
1320967, in F24 I don't test very frequently, because unplugging/plugging (in 
my case neccessary for F24) the usb media very often I forget, when I switch 
from Win to Fedora and vice versa. This problem of Grub is a release criteria 
for final. Is it possible to have it for F25 as a release criteria for Beta or 
Alpha?
Kind Regards




It's a known issue 
https://fedoraproject.org/wiki/Common_F24_bugs#uefi-chainloading-error


-- 

Ahmad Samir


--test mailing listtest@lists.fedoraproject.orgTo 
unsubscribe:http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: release criteria for final - bug 1320967

2016-05-18 Thread Ahmad Samir 
On 18 May 2016 at 07:39, Joerg Lechner  wrote:

> Hi,
> I use an about one year old Acer laptop, internal disk Win 8.1, F23/F24 on
> usb flash media, for F20/21/22/23 I tested as user, using the Fedora
> version in development. Because of "
> F24 Alpha 1.7 Desktop - Grub boot menue, not possible to start Win 8.1
> " - Bug 1320967, in
> F24 I don't test very frequently, because unplugging/plugging (in my case
> neccessary for F24) the usb media very often I forget, when I switch from
> Win to Fedora and vice versa. This problem of Grub is a release criteria
> for final. Is it possible to have it for F25 as a release criteria for Beta
> or Alpha?
> Kind Regards
>
>
It's a known issue
https://fedoraproject.org/wiki/Common_F24_bugs#uefi-chainloading-error

-- 
Ahmad Samir
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org