Re: How to interpret F18 Blocker criterion

[Matthias Runge]

On 11/09/2012 01:01 AM, "Jóhann B. Guðmundsson" wrote:


In today's age it's become more common to just run GNU/Linux in a vm
since more or less all hw you buy this day has a virtual capable cpu
instead of jumping through the partitioning hoops and loose the warranty
and support while you are at it and yeah one of the fundamental things
users like and have to do is to upgrade their computers and devices
firmware and even now in the 21 century it cant be done in GNU/Linux
with an ease...
Do I understand you right, that you're suggesting to run Linux in a vm 
instead of real hardware? Because it's the 21st century and we would 
loose warranty?


N!, right?

We definitely need to ensure, Fedora runs quite well as dual boot 
installation.

--
Matthias Runge 
   
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Radeon HD 5750 on Fedora 18 - airplane take off

[Mateusz Marzantowicz]

I've just tried Fedora 18 Live desktop image. It's a big wow and despite
some changes in gnome 3.6 which I'm not accustomed to everything seems
to work fine.

There is however some serious issue, that is also present in earlier
Fedora 17 release. It's about power management of graphics card. As
stated in title it's Radeon HD 5750 (Juniper) and open source driver.
When I started booting Fedora 18 I felt like I was in airplane that is
about to take off.

I've managed to fix this "bug" (or call I whatever you want) according
to instructions in
http://www.x.org/wiki/RadeonFeature#KMS_Power_Management_Options .

I have "profile" method set with "low" profile chosen it reduced fan
speed both on F17 and F18. I use rc.local to set it during boot up. My
question is: is it possible to set this by default in new Fedora 18? I
don't know if it could be done during compile time of kernel/drivers or
must be set explicitly like I did it. I think lot of people will be
happy to hear that GPU fan isn't so noisy.


Mateusz Marzantowicz
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Fedora 18: No GDM on boot.

[John Ellson]

I had similar issues, problems with kernel modules, I think.

kernel-3.6.6-4.fc19 from koji fixed it for me.

John


On 11/08/2012 07:17 PM, Ankur Sinha wrote:

Hi folks,

My f18 system doesn't pull up a login screen on boot. It just waits.
Restarting the gdm.service from a virtual terminal gets it up though,
but I need to this at every boot now.

Here's the gdm.service status when it didn't come up:
http://paste.stg.fedoraproject.org/1590/

I checked the xorg logs as suggested. They seem to have nouveau related
issues:
http://paste.stg.fedoraproject.org/1592/

This is the current gdm.service status (after I'm logged in):
http://paste.stg.fedoraproject.org/1593

Is anyone else experiencing this issue? I see a few "unable to start"
bugs at bugzilla[1], but none of them seem to be related to this.

[1] https://admin.fedoraproject.org/pkgdb/acls/bugs/gdm




-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[Test-Announce] Fedora 19 release name voting

[Robyn Bergeron]

Voting for the release name of Fedora 19 has begun.  The pool of names 
submitted by the community has been narrowed down to 8 possible names, 
one of which will become the release name for the successor to Fedora 18 
("Spherical Cow").


This vote began on November 9th, 2012, at 00:00 UTC, and will end at 
23:59:59 on November 15th, 2012.


* We are using the Range Voting method 
(http://en.wikipedia.org/wiki/Range_voting).


* If this is your first time using the voting system, you may want to 
read the Fedora Elections Guide, located here:

http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Fedora_Elections_Guide/index.html

* In order to vote, you must have a valid Fedora Project Contributor 
Agreement (FPCA) on file and be a member of at least one non-CLA group.


Ballots may be cast on the Fedora Elections System here, now!
https://admin.fedoraproject.org/voting/about/relnamef19

Cheers,

Robyn
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Fedora 18: No GDM on boot.

[Ankur Sinha]

Hi folks,

My f18 system doesn't pull up a login screen on boot. It just waits.
Restarting the gdm.service from a virtual terminal gets it up though,
but I need to this at every boot now. 

Here's the gdm.service status when it didn't come up:
http://paste.stg.fedoraproject.org/1590/

I checked the xorg logs as suggested. They seem to have nouveau related
issues:
http://paste.stg.fedoraproject.org/1592/

This is the current gdm.service status (after I'm logged in):
http://paste.stg.fedoraproject.org/1593

Is anyone else experiencing this issue? I see a few "unable to start"
bugs at bugzilla[1], but none of them seem to be related to this.

[1] https://admin.fedoraproject.org/pkgdb/acls/bugs/gdm
-- 
Thanks, 
Warm regards,
Ankur: "FranciscoD"

Please only print if necessary. 

Looking to contribute to Fedora? Look here: 
https://fedoraproject.org/wiki/Fedora_Join_SIG

http://fedoraproject.org/wiki/User:Ankursinha
http://dodoincfedora.wordpress.com/


signature.asc
Description: This is a digitally signed message part
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: avc denials on fedora 18

[Ankur Sinha]

On Thu, 2012-11-08 at 09:07 -0500, Daniel J Walsh wrote:
> These AVC's loos le a bunch of stuff was being run as xdm_dbus_t,
> which means
> executables started by gdm via dbus session.  I have no idea why.
> 
> Are you still seeing SELinux issues?

Hi Daniel,

I don't see them in the latest logs. Guess the package reinstalls fixed
it.
-- 
Thanks :), 
Warm regards,
Ankur: "FranciscoD"

Please only print if necessary. 

Looking to contribute to Fedora? Look here: 
https://fedoraproject.org/wiki/Fedora_Join_SIG

http://fedoraproject.org/wiki/User:Ankursinha
http://dodoincfedora.wordpress.com/


signature.asc
Description: This is a digitally signed message part
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/08/2012 10:34 PM, John Morris wrote:

Few laptops can fit a second hard drive.  And you quickly learn that in
the real word you had better leave Windows installed so can get tech
support, download new firmware, etc.  So you resize it down to minimal
and put your work OS on.  And if you can't do it in a couple of tries
then you will probably pick a distro that can pull it off.


In today's age it's become more common to just run GNU/Linux in a vm 
since more or less all hw you buy this day has a virtual capable cpu 
instead of jumping through the partitioning hoops and loose the warranty 
and support while you are at it and yeah one of the fundamental things 
users like and have to do is to upgrade their computers and devices 
firmware and even now in the 21 century it cant be done in GNU/Linux 
with an ease...


JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Felix Miata]

On 2012-11-08 16:28 (GMT-0600) John Morris composed:


We have suffered since day one with Microsoft's refusal to admit other
products exist and merrily destroy other boot loaders without so much as
an "I see something else in the MBR, should I overwrite it?" prompt.


pot <-black-> kettle

Installing Grub to MBR never destroys another boot loader? Not! For more 
installations than not, Linux can be installed and booted without changing a 
single byte of MBR code.

--
"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:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[John Morris]

On Wed, 2012-11-07 at 11:55 +0100, Chris Murphy wrote:

> I actually don't understand the RHEL angle on this missing piece
> either. What is the use case of installing RHEL along side Windows?
> Really, enterprise users do this? They share a single disk with one
> bootloader/manager taking over another? Seems risky to me. I'd think
> best practices would be, at best, separate OS's on separate drives, in
> the case of BIOS-MBR. For UEFI-GPT it's… different.

One word: laptops.

Few laptops can fit a second hard drive.  And you quickly learn that in
the real word you had better leave Windows installed so can get tech
support, download new firmware, etc.  So you resize it down to minimal
and put your work OS on.  And if you can't do it in a couple of tries
then you will probably pick a distro that can pull it off.


signature.asc
Description: This is a digitally signed message part
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[John Morris]

On Wed, 2012-11-07 at 07:51 +, "Jóhann B. Guðmundsson" wrote:

> We can still test this and installing Fedora, and arguably we should be 
> doing that along other OS other than just Microsoft as well.
> 
> We would just not have the Fedora release dependent upon the result from 
> those tests...

Really.  So if it were known that Anaconda WOULD hose an existing
Windows install you would be ok with releasing?  Or if Anaconda simply
puked and failed to install a working, booting Fedora in the presence of
a Windows partition?  That is what a release grade product does?

And not just Windows, if Anaconda failed to do it's job and install a
working Fedora without destroying any other OS install it is a serious
problem.  If the newly installed Fedora doesn't work it is a fail.  If
it causes damage beyond itself it is a disaster.  Testing for and
preventing such a PR disaster SHOULD be a release criteria.

Failing to even test means that not only would a broken Fedora be
released upon a unsuspecting world, there wouldn't even be a warning in
the release notes to point to. Is it even possible to test every corner
case out there in the complex world we live in?  Probably not.  Doesn't
mean that making a respectable attempt is a bad idea.

We have suffered since day one with Microsoft's refusal to admit other
products exist and merrily destroy other boot loaders without so much as
an "I see something else in the MBR, should I overwrite it?" prompt.  We
are supposed to be the White Hats and care about users and all that,
lets live up to our own book of rules.


signature.asc
Description: This is a digitally signed message part
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Is it possible to configure X keyboard in F18?

[Sergio]

> 
> Which systemd release got upgrade to when you upgraded?
> 
> JBG
> -- 

systemd 195.2.fc18 obsoleted systemd 44.21.fc17
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Is it possible to configure X keyboard in F18?

[Jóhann B. Guðmundsson]

On 11/08/2012 03:38 PM, Sergio wrote:

Hi.
F18 has deprecated /etc/sysconfig/keyboard but either
there's no way to configure the X keymap (bug) or I

haven't

found yet.

In a post a few days ago it was said that

/etc/vconsole.conf

would replace it but X fails to set the keyboard from
there.

$ cat /etc/vconsole.conf
FONT="latarcyrheb-sun16"
KEYMAP="br-abnt2"

$ cat /var/log/Xorg.0.log
{snip}
[   599.674] (**) Option "xkb_rules" "evdev"
[   599.674] (**) Option "xkb_model" "evdev"
[   599.674] (**) Option "xkb_layout" "us"
{snip}

So it sets the 'us' keymap and thus this is the keymap
active in the login window (lightdm here).

I tried with
$ cat /etc/X11/xorg.conf.d/00-keyboard.conf

Section "InputDevice"
 Identifier
"Keyboard0"
 Driver
"keyboard"
 Option
"XkbLayout" "br"
 Option
"XkbModel" "abnt2"
EndSection

But it doesn't work (I tried changing driver name,

adding

the ServerLayout section etc.).

See X log from F17 with /etc/sysconfig/keyboard:

$ cat /var/log/Xorg.1.log
{snip}
[  4690.573] (**) Option "xkb_rules" "evdev"
[  4690.573] (**) Option "xkb_model" "abnt2"
[  4690.573] (**) Option "xkb_layout" "br"
[  4690.573] (**) Option "xkb_options"
"terminate:ctrl_alt_bksp,"
{snip}

note: I'm using the NVIDIA driver from rpmfusion. Maybe

it

would work with the kernel driver (nouveau; I mention

it as

it seems it's more integrated yet than before) but

still X

should configure the keyboard properly regardless of

the

video driver used.


I found in another post about localectl (and read now your
answer, Frank).
I ran it and the change it made in vconsole.conf just
removed the quotes. Let's see if it will work.

I also ran it for the locale as I was receiving a dracut
error at boot with en_US.UTF-8. So I changed with the listed
en_US.utf8.
Let's see if it will make any difference.


Worked fine. It actually changed /etc/X11/xorg.conf.d/00-keyboard.conf:

# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
 Identifier "system-keyboard"
 MatchIsKeyboard "on"
 Option "XkbLayout" "br"
EndSection



Which systemd release got upgrade to when you upgraded?

JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+--
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  reopened
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+--

Comment (by johannbg):

 It's not our decisions to decide what is and what is not supposed to be in
 various comps group and adding a criteria that specifically checks for
 what is or what no supposed to be in those groups will be near impossible
 to maintained and in general does not scale.

 You might want to check with releng or autoqa who could automatically
 check for "only those dependency" and first and foremost before all of the
 above points I just mentioned can be made those changes will need to be
 approved *first* by the comps maintainers.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+--
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  reopened
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+--

Comment (by herrold):

 Dependency explosion is a serious issue, and probably will require a
 refactoring of several packaging approaches into either a: non-X and full
 pair, or a base and -GUI pair.  But there are other useful axes for
 partition:  Sound, and no-sound, Display and no-display, Server and non-
 server, all come to mind

 The need is clear as the first comment mentions, and the tactics to get
 there have to start somewhere. I saw pkgconfig pulled in, as I tried to
 get a minimal X install up yesterday, and that is just wrong ;)

 If QA only means 'lights up and does not crash', it may well be out of
 scope here ... but until an alternative venue is found, it seems a fair
 topic for discussion here

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Is it possible to configure X keyboard in F18?

[Sergio]

> > Hi.
> > F18 has deprecated /etc/sysconfig/keyboard but either
> > there's no way to configure the X keymap (bug) or I
> haven't
> > found yet.
> > 
> > In a post a few days ago it was said that
> /etc/vconsole.conf
> > would replace it but X fails to set the keyboard from
> > there.
> > 
> > $ cat /etc/vconsole.conf 
> > FONT="latarcyrheb-sun16"
> > KEYMAP="br-abnt2"
> > 
> > $ cat /var/log/Xorg.0.log
> > {snip}
> > [   599.674] (**) Option "xkb_rules" "evdev"
> > [   599.674] (**) Option "xkb_model" "evdev"
> > [   599.674] (**) Option "xkb_layout" "us"
> > {snip}
> > 
> > So it sets the 'us' keymap and thus this is the keymap
> > active in the login window (lightdm here).
> > 
> > I tried with
> > $ cat /etc/X11/xorg.conf.d/00-keyboard.conf 
> > 
> > Section "InputDevice"
> >     Identifier 
> >    "Keyboard0"
> >     Driver     
> >    "keyboard"
> >     Option     
> >    "XkbLayout" "br"
> >     Option     
> >    "XkbModel" "abnt2"
> > EndSection
> > 
> > But it doesn't work (I tried changing driver name,
> adding
> > the ServerLayout section etc.).
> > 
> > See X log from F17 with /etc/sysconfig/keyboard:
> > 
> > $ cat /var/log/Xorg.1.log
> > {snip}
> > [  4690.573] (**) Option "xkb_rules" "evdev"
> > [  4690.573] (**) Option "xkb_model" "abnt2"
> > [  4690.573] (**) Option "xkb_layout" "br"
> > [  4690.573] (**) Option "xkb_options"
> > "terminate:ctrl_alt_bksp,"
> > {snip}
> > 
> > note: I'm using the NVIDIA driver from rpmfusion. Maybe
> it
> > would work with the kernel driver (nouveau; I mention
> it as
> > it seems it's more integrated yet than before) but
> still X
> > should configure the keyboard properly regardless of
> the
> > video driver used.
> > 
> 
> I found in another post about localectl (and read now your
> answer, Frank).
> I ran it and the change it made in vconsole.conf just
> removed the quotes. Let's see if it will work.
> 
> I also ran it for the locale as I was receiving a dracut
> error at boot with en_US.UTF-8. So I changed with the listed
> en_US.utf8.
> Let's see if it will make any difference.
> 

Worked fine. It actually changed /etc/X11/xorg.conf.d/00-keyboard.conf:

# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
Identifier "system-keyboard"
MatchIsKeyboard "on"
Option "XkbLayout" "br"
EndSection

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: HEADS UP several very old sysconfig files are being deprecated

[Sergio]

--- Em qui, 8/11/12, "Jóhann B. Guðmundsson"  escreveu:

> De: "Jóhann B. Guðmundsson" 
> Assunto: Re: HEADS UP several very old sysconfig files are being deprecated
> Para: test@lists.fedoraproject.org
> Data: Quinta-feira, 8 de Novembro de 2012, 9:43
> On 11/08/2012 09:23 AM, Sergio
> wrote:
> >
> > LANG="en_US.UTF-8"
> > SYSFONT="latarcyrheb-sun16"
> >
> > and /etc/sysconfig/keyboard has
> >
> > KEYTABLE="br-abnt2"
> > MODEL="abnt2"
> > LAYOUT="br"
> >
> > So I would create /etc/locale.conf with
> >
> > LANG="en_US.UTF-8"
> >
> > and /etc/vconsole.conf with
> >
> > FONT="latarcyrheb-sun16"
> > KEYMAP="br-abnt2"
> >
> > Is that all? Should I put MODEL and LAYOUT in
> /etc/vconsole.conf too? 
> 
> The legacy files get migrated for you not by you so you
> should not have 
> to do anything.
> 
> The only thing you have to do is start using the new files
> if you are 
> going to make changes ( or create entries )
> 
> JBG

Thanks, I changed them with localectl now but haven't restarted X yet to see if 
it will read the keyboard layout properly.

But the legacy files weren't migrated. I upgraded with yum, maybe that was the 
reason?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Is it possible to configure X keyboard in F18?

[Sergio]

--- Em qui, 8/11/12, Sergio  escreveu:

> De: Sergio 
> Assunto: Is it possible to configure X keyboard in F18?
> Para: test@lists.fedoraproject.org
> Data: Quinta-feira, 8 de Novembro de 2012, 13:11
> Hi.
> F18 has deprecated /etc/sysconfig/keyboard but either
> there's no way to configure the X keymap (bug) or I haven't
> found yet.
> 
> In a post a few days ago it was said that /etc/vconsole.conf
> would replace it but X fails to set the keyboard from
> there.
> 
> $ cat /etc/vconsole.conf 
> FONT="latarcyrheb-sun16"
> KEYMAP="br-abnt2"
> 
> $ cat /var/log/Xorg.0.log
> {snip}
> [   599.674] (**) Option "xkb_rules" "evdev"
> [   599.674] (**) Option "xkb_model" "evdev"
> [   599.674] (**) Option "xkb_layout" "us"
> {snip}
> 
> So it sets the 'us' keymap and thus this is the keymap
> active in the login window (lightdm here).
> 
> I tried with
> $ cat /etc/X11/xorg.conf.d/00-keyboard.conf 
> 
> Section "InputDevice"
>     Identifier 
>    "Keyboard0"
>     Driver     
>    "keyboard"
>     Option     
>    "XkbLayout" "br"
>     Option     
>    "XkbModel" "abnt2"
> EndSection
> 
> But it doesn't work (I tried changing driver name, adding
> the ServerLayout section etc.).
> 
> See X log from F17 with /etc/sysconfig/keyboard:
> 
> $ cat /var/log/Xorg.1.log
> {snip}
> [  4690.573] (**) Option "xkb_rules" "evdev"
> [  4690.573] (**) Option "xkb_model" "abnt2"
> [  4690.573] (**) Option "xkb_layout" "br"
> [  4690.573] (**) Option "xkb_options"
> "terminate:ctrl_alt_bksp,"
> {snip}
> 
> note: I'm using the NVIDIA driver from rpmfusion. Maybe it
> would work with the kernel driver (nouveau; I mention it as
> it seems it's more integrated yet than before) but still X
> should configure the keyboard properly regardless of the
> video driver used.
> 

I found in another post about localectl (and read now your answer, Frank).
I ran it and the change it made in vconsole.conf just removed the quotes. Let's 
see if it will work.

I also ran it for the locale as I was receiving a dracut error at boot with 
en_US.UTF-8. So I changed with the listed en_US.utf8.
Let's see if it will make any difference.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+--
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  reopened
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+--

Comment (by kparal):

 mattdm, please excuse Johann, he's known for acting in a very impolite
 way.

 Johann, please don't close this ticket after every comment, it's annoying
 and rude. Let's give other QA members (and anyone else) chance to express
 their opinion as well. Thanks.

 I'll read the links mattdm posted and reply today or tomorrow, as time
 permits.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+--
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  reopened
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+--

Comment (by mattdm):

 Alternative implementations might be:


 B. More vague about the specifics: "No package in the minimal install set
 may have a dependency chain which includes a graphical windowing system.
 Packages must split functionality requiring this into subpackages, or be
 removed from the minimal package set."

 C. Move specifics entirely to Some Other Place, as many of the existing
 release criteria do: "No package in the minimal install set may have a
 dependency chain which includes a package in the list of packages not
 allowed in the minimal install. Packages must split functionality
 requiring these dependencies into subpackages, or be removed from the
 minimal package set."

 I'm not keen on B because it seems prone to misinterpretation. Option C
 would be fine, but I think the extra level of indirection is unnecessary
 complication in this case.



 T

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Is it possible to configure X keyboard in F18?

[Frank Murphy]

On Thu, 8 Nov 2012 15:14:47 +
Frank Murphy  wrote:

> man localctl 

s/localctl/localectl

-- 
Regards,
Frank
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Is it possible to configure X keyboard in F18?

[Frank Murphy]

On Thu, 8 Nov 2012 07:11:15 -0800 (PST)
Sergio  wrote:

> Hi.
> F18 has deprecated /etc/sysconfig/keyboard but either there's no
> way to configure the X keymap (bug) or I haven't found yet.
> 

man localctl 
-- 
Regards,
Frank
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F18/Rawhide, kdm: wrong keyboard layout

[Sandro Mani]

On Wed, Nov 7, 2012 at 5:06 PM, Frank Murphy  wrote:
> On Fri, 26 Oct 2012 14:55:47 -0700
> Adam Williamson  wrote:
>
>> On Fri, 2012-10-26 at 18:16 +0200, Sandro Mani wrote:
>> > I haven't tried the vconsole thing yet (can't log out right now),
>> > but also in my case the problem _only_ appears at the login
>> > screen. Everywhere else, including on VTs, the layout is correct.
>>
>> It sounds like the console layout is correct and your desktop (KDE
>> or whatever) also has the correct layout configured for your user,
>> so I think what's missing is the systemwide X11 layout. Johann,
>> where does that get set?
>
> Sorry about the late reply
>
> I fixed my login screen problems (LightDM)
> with "localectl set-keyboard uk"
>
> man localectl (within F18)
>
> --
> Regards,
> Frank
> --
> test mailing list
> test@lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test

Thanks, that worked!
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

test days & smolt retirement

[Kamil Paral]

I have done a quick change [1] to our Test Day template and removed all Smolt 
references, because Smolt was retired [2]. But some test days might really miss 
this functionality. Any ideas how to replace missing Smolt with something 
useful in our test day matrices are welcome.

[1] 
https://fedoraproject.org/w/index.php?title=QA%2FTest_Days%2FTemplate&action=historysubmit&diff=310498&oldid=297619
[2] http://lists.fedoraproject.org/pipermail/announce/2012-October/003107.html
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+--
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  reopened
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+--

Comment (by mattdm):

 Again, it's fine to say "this is pending a decision by someone else on
 whether we want this particular requirement", but assuming general
 consensus on that, this

 1. ''isn't'' covered by anything else
 1. should be.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+--
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  reopened
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+--
Changes (by mattdm):

 * status:  closed => reopened
 * resolution:  wontfix =>


Comment:

 I think you are entirely missing the point here. This is not about
 "unresolved package dependency", nor is it about deciding what's
 specifically in a particular comps group. It's about setting a basic
 standard.

 See https://bugzilla.redhat.com/show_bug.cgi?id=874378 for background.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  closed
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:  wontfix   |   Keywords:
Blocked By:|   Blocking:
---+
Changes (by johannbg):

 * resolution:   => wontfix
 * status:  reopened => closed


Comment:

 We as has been stated by both Kamil and myself are not responsible on what
 is in particular comps group. We do not decide what's shipped in those and
 we already have in place criteria that handles unresolved package
 dependency ( see item nr 3 in the alpha criteria  ) which might be the
 only fallout from this encase those responsible decides to make this
 change and we do not add criteria that apply to specific package(s).

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+--
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  reopened
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+--
Changes (by mattdm):

 * resolution:  wontfix =>
 * status:  closed => reopened


Comment:

 Replying to [comment:5 johannbg]:
 > Closing this ticket since we already have criteria that covers minimal
 install and packages and their dependency ( or lack there of ) which would
 automatically cover this if it's decided that the relevant packages that
 have been mentioned in this ticket gets removed from comps minimal group.

 Wait, ''what''? Unless I'm misunderstanding you, this is backwards. The
 issue isn't making sure dependencies don't get removed; it is taking care
 not to grow (a particular set of) new ones.

 If I ''am'' misunderstanding, can you point me to the existing criteria
 you are referring to?

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  closed
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:  wontfix   |   Keywords:
Blocked By:|   Blocking:
---+
Changes (by johannbg):

 * resolution:   => wontfix
 * status:  new => closed


-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+-
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  new
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+-

Comment (by johannbg):

 Replying to [comment:4 mattdm]:
 > Okay, but, regardless of the authority, which we can figure out, a
 release criterion is the sensible manifestation of that decision, and
 ''that'' is QA.

 Yes true.

 Closing this ticket since we already have criteria that covers minimal
 install and packages and their dependency ( or lack there of ) which would
 automatically cover this if it's decided that the relevant packages that
 have been mentioned in this ticket gets removed from comps minimal group.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: avc denials on fedora 18

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/07/2012 07:27 PM, Ankur Sinha wrote:
> Hi folks,
> 
> I upgraded my system from fedora 17 a few days ago. I forgot to change my
> selinux mode to permissive before the update and it took me a while to fix
> my files. I think they're all okay now. However, I still see quite a few
> denials in the audit.log. Would someone know if these are expected, or if I
> need to fix a few more files?
> 
> Output of 'egrep denied /var/log/audit/audit.log' 
> http://paste.stg.fedoraproject.org/1553
> 
> 
> 
These AVC's loos le a bunch of stuff was being run as xdm_dbus_t, which means
executables started by gdm via dbus session.  I have no idea why.

Are you still seeing SELinux issues?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCbvIkACgkQrlYvE4MpobMzNgCfQzxiMCBOHf8ienBdGQp+4lq+
M80AoL0NW5Wlrg848Ek0gkvQzr0LXrCV
=hmjL
-END PGP SIGNATURE-
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+-
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  new
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+-

Comment (by mattdm):

 Okay, but, regardless of the authority, which we can figure out, a release
 criterion is the sensible manifestation of that decision, and ''that'' is
 QA.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+-
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  new
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+-

Comment (by johannbg):

 Replying to [comment:1 kparal]:
 > I like the proposal itself (I also believe minimal install should not
 contain X), but I don't think QA should be the authority that decides and
 dictates this condition.

 Correct QA is not the authority to handle this comps maintainer(s) and
 arguably releng are

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+-
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  new
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+-

Comment (by mattdm):

 The closest document we have is probably
 http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups

 As a representative of the cloud sig, I have a strong vested interest in a
 sane minimal package set. I'm happy to be a "minimal flavor maintainer" if
 we need one. Bill Nottingham (release engineering) has traditionally been
 heavily involved here -- see
 https://fedoraproject.org/wiki/Features/ReworkPackageGroups.

 Should I file a ticket with FESCO asking for a decision on the idea in
 general?

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+-
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  new
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+-

Comment (by kparal):

 I like the proposal itself (I also believe minimal install should not
 contain X), but I don't think QA should be the authority that decides and
 dictates this condition.

 I think currently it is very unclear who manages different flavors of
 Fedora and who gets the decision powers. Who owns the desktop flavor (or
 should I call it a spin?)? Who owns the minimal flavor? Who should I
 report bugs to? Who decides what should be there and what should be not? I
 don't think FESCo should be bothered every time we want to add a remove a
 package. It must be someone else.

 I'm currently not very clear on these matters, especially wrt minimal
 flavor. I suspect desktop SIG would own the desktop flavor, but it's very
 possible that no-one manages minimal flavor at all. I tried to find some
 document on our wiki that would address this, but I failed. So any
 explanations are welcome (I guess adamw will know, he knows everything).

 After this is cleared up, I think we should talk to the minimal flavor
 maintainer (or create one first?), whether this is the current policy or
 not ("no X in minimal") and whether Fedora release should be blocked if
 some X package happens to enter the set.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

yum upgrade from F17 to F18

[Miroslav Suchý]

Hi,
I'm upgrading Fedoras by yum [1] for some time. I know that is not 
supported method and can have some problems. But the truth is that it 
was always less error prone as compared to upgrade using Anaconda or 
preupgrade. Even with upgrade from F16 to F17, which I originally 
thought would be impossible. But again "yum upgrade" was smoother than 
preupgrade.


As upgrading using yum require to have open wiki and follow steps 
written there, I decided to automate it and created script fedora-upgrade:


  https://github.com/xsuchy/fedora-upgrade

When run, it will upgrade your Fedora (currently only F17) to Fedora 18 
using "yum upgrade".
It is first shot, so it is definitely not intended for production 
systems. But you are very welcome to test it and report problems or just 
your ideas how to enhance it.

I intentionally left this script verbose, to help initial debugging.

[1] https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum

--
Miroslav Suchy
Red Hat Systems Management Engineering
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
--+--
 Reporter:  mattdm|   Owner:
 Type:  enhancement   |  Status:  new
 Priority:  major |   Milestone:
Component:  Release criteria  | Version:
 Keywords:|  Blocked By:
 Blocking:|
--+--
 = problem =

 There are no rules holding us to a sane minimal package set. Features
 which are added to minimal could pull in the whole universe.

 = analysis =

 Drawing the line at X11 seems reasonable. (And Wayland.) We can argue at
 length about what minimal means, but this is a fairly clear line in the
 sand ''and'' is usually a reasonable split at a package level ''and''
 matches our historic practice (see vim packages for example).

 = enhancement recommendation =

 "No package in the minimal install set may have a dependency chain which
 includes the libX11, the core X11 library (or its equivalent in Wayland).
 Packages must split functionality requiring this into subpackages, or be
 removed from the minimal package set."

 My suggestion is to make this an Alpha criterion, so such issues can be
 resolved early, but I don't have strong feelings on the particular timing.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: f18 vm inside f17 updated host needs tablet

[Gianluca Cecchi]

Add-on: after yesterday updates at guest f18 side, now it works
without tablet too.
Note that another change I did was the line
hvm

that I previously had as pc-0.14 because I recycled an f17 guest
config file fro scratching it.
It seems instead that I simulate creation of a f18 guest right now, it
sets pc-0.15 (also due to updates at server side since when I first
created the vm some moths ago).
But reverting to pc-0.14 now mouse keeps working so it is not the main point.

I'll keep testing this way without tablet for the moment.
Yesterday updates were:
Nov 07 02:27:50 Updated: coreutils-8.17-6.fc18.x86_64
Nov 07 02:27:50 Updated: selinux-policy-3.11.1-50.fc18.noarch
Nov 07 02:27:52 Updated: device-mapper-libs-1.02.77-1.fc18.x86_64
Nov 07 02:27:52 Updated: device-mapper-1.02.77-1.fc18.x86_64
Nov 07 02:27:52 Updated: device-mapper-event-libs-1.02.77-1.fc18.x86_64
Nov 07 02:27:52 Updated: device-mapper-event-1.02.77-1.fc18.x86_64
Nov 07 02:27:52 Updated: lvm2-libs-2.02.98-1.fc18.x86_64
Nov 07 02:27:52 Updated: 1:perl-parent-0.225-234.fc18.noarch
Nov 07 02:27:53 Updated: 1:perl-Pod-Escapes-1.04-234.fc18.noarch
Nov 07 02:27:53 Updated: perl-Pod-Perldoc-3.17.00-234.fc18.noarch
Nov 07 02:27:53 Updated: perl-threads-shared-1.40-234.fc18.x86_64
Nov 07 02:27:53 Updated: perl-Scalar-List-Utils-1.25-234.fc18.x86_64
Nov 07 02:27:53 Updated: 4:perl-libs-5.16.2-234.fc18.x86_64
Nov 07 02:27:53 Updated: 4:perl-macros-5.16.2-234.fc18.x86_64
Nov 07 02:27:53 Updated: 1:perl-Module-Pluggable-4.00-234.fc18.noarch
Nov 07 02:27:54 Updated: perl-PathTools-3.39.2-234.fc18.x86_64
Nov 07 02:27:54 Updated: perl-Carp-1.26-234.fc18.noarch
Nov 07 02:27:54 Updated: 1:perl-Pod-Simple-3.20-234.fc18.noarch
Nov 07 02:27:54 Updated: perl-Pod-Parser-1.51-234.fc18.noarch
Nov 07 02:27:54 Updated: perl-threads-1.86-234.fc18.x86_64
Nov 07 02:28:00 Updated: 4:perl-5.16.2-234.fc18.x86_64
Nov 07 02:28:01 Updated: 1:cups-libs-1.5.4-14.fc18.x86_64
Nov 07 02:28:03 Updated: 1:cups-1.5.4-14.fc18.x86_64
Nov 07 02:28:03 Updated: perl-Data-Dumper-2.135.06-234.fc18.x86_64
Nov 07 02:28:04 Updated: lvm2-2.02.98-1.fc18.x86_64
Nov 07 02:28:20 Updated: selinux-policy-devel-3.11.1-50.fc18.noarch
Nov 07 02:28:24 Updated: selinux-policy-targeted-3.11.1-50.fc18.noarch
Nov 07 02:28:25 Updated: firstboot-18.6-1.fc18.x86_64
Nov 07 02:28:25 Updated: pygobject3-3.4.1.1-2.fc18.x86_64
Nov 07 02:28:26 Updated: gstreamer1-plugins-good-1.0.2-2.fc18.x86_64
Nov 07 02:28:28 Updated: tzdata-2012i-1.fc18.noarch
Nov 07 02:28:29 Updated: iputils-20121106-1.fc18.x86_64
Nov 07 02:28:30 Updated: tzdata-java-2012i-1.fc18.noarch
Nov 07 02:28:37 Installed: kernel-3.6.6-3.fc18.x86_64

Gianluca
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: HEADS UP several very old sysconfig files are being deprecated

[Jóhann B. Guðmundsson]

On 11/08/2012 09:23 AM, Sergio wrote:


LANG="en_US.UTF-8"
SYSFONT="latarcyrheb-sun16"

and /etc/sysconfig/keyboard has

KEYTABLE="br-abnt2"
MODEL="abnt2"
LAYOUT="br"

So I would create /etc/locale.conf with

LANG="en_US.UTF-8"

and /etc/vconsole.conf with

FONT="latarcyrheb-sun16"
KEYMAP="br-abnt2"

Is that all? Should I put MODEL and LAYOUT in /etc/vconsole.conf too? 


The legacy files get migrated for you not by you so you should not have 
to do anything.


The only thing you have to do is start using the new files if you are 
going to make changes ( or create entries )


JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: f18 vm inside f17 updated host needs tablet

[Gianluca Cecchi]

On Thu Nov 8 03:36:55 UTC 2012 Adam Williamson wrote:
> IIRC the use of a tablet was actually *added* in recent releases because
> it makes the pointer tracking more accurate and avoids the double-cursor
> effect.

I remembered my opinion due to a past thread in spice-devel mailing
list last year.
Specifically, after a quick search:
http://lists.freedesktop.org/archives/spice-devel/2011-October/005669.html

when Arnon said:
"
Before the following, remove the "-usb -device usb-tablet,id=input0"
from qemu line and run it again with the xp guest. There is no need for
it when using the agent.
"

That thread was specific with a Windows XP guest but at that time I
understood that with recent virt-manager and spice (as F17 and F18
are) the tablet was not required overall if you used the agent... and
I noticed that by default my f18 guest has spice-vdagent package
installed and service configured at boot
SO the question is if my assumption is correct...

Also this other thread in this mailing list let me consider not to use
a tablet...

 http://lists.fedoraproject.org/pipermail/test/2011-December/104731.html

But with fedora 18 guest I have no mouse at all in this case...
I'm going to try with latest updates and debug more if considered useful
Thanks,

Gianluca
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: criterion discussion: memory test tool

[Adam Williamson]

On Thu, 2012-11-08 at 05:52 -0500, Kamil Paral wrote:
> > Worth considering the history: Petr proposed the general idea of a
> > criterion as part of the criteria review, and I drafted the final
> > wording. See thread "New criterion for Memory test" from end of
> > January.
> 
> Thanks for finding that thread. We have to find a way how to link
> criteria with list discussions, so that it would be much easier to
> read all relevant discussion to a particular criterion. Putting that
> into my todo list (page 937).

I usually mention the thread when editing the criteria page (but of
course you have to find the release it was originally put in), and the
way I found this one was just to search my mail archives for anything
with the strings 'mem' and 'criter' in the subject :)

> The thread indicates the criterion was created ad-hoc, "the tool is
> there, let's codify it". Since we try to be more conservative about
> what is and what is not a blocker lately, I think this is a good
> candidate for removal.

Yeah, I think you have a point, as I said.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: HEADS UP several very old sysconfig files are being deprecated

[Sergio]

--- Em qui, 8/11/12, Sergio  escreveu:

> De: Sergio 
> Assunto: Re: HEADS UP several very old sysconfig files are being deprecated
> Para: test@lists.fedoraproject.org
> Data: Quinta-feira, 8 de Novembro de 2012, 7:23
> On 10/26/2012 11:24 PM, "Jóhann B.
> Guðmundsson" wrote:
> > *
> > **/etc/sysconfig/i18n has been replaced by
> /etc/locale.conf *
> >
> > LANG + All LC_* variables found in /etc/sysconfig/i18n
> as in
> >
> > LANG=
> > LC_CTYPE=
> > LC_NUMERIC=
> > LC_TIME=
> > LC_COLLATE=
> > LC_MONETARY=
> > LC_MESSAGES=
> > LC_PAPER=
> > LC_NAME=
> > LC_ADDRESS=
> > LC_TELEPHONE=
> > LC_MEASUREMENT=
> > LC_IDENTIFICATION=
> >
> > belong in /etc/locale.conf
> >
> > The locale settings configured in here are system-wide
> and are inherited
> > by every service or user, unless overridden or unset by
> individual
> > programs or individual users.
> > See  man locale.conf for further details
> >
> > */etc/sysconfig/keyboard has been change to
> **/etc/vconsole.conf
> > *
> > The virtual console configuration is
> /etc/vconsole.conf
> > /*
> > *//*NOTE THAT THE VARIABLES BEING USED HAVE CHANGED*/
> >
> > SYSFONT= becomes FONT=
> > SYSFONTACM= becomes FONT_MAP=
> > UNIMAP= becomes FONT_UNIMAP=
> > KEYTABLE= becomes KEYMAP=
> >
> > Kernel keymap and fonts is the default being used if
> FONT= or KEYMAP=
> > are not set or empty
> 
> Hi, just to make sure.
> Currently my /etc/sysconfig/i18n has
> 
> LANG="en_US.UTF-8"
> SYSFONT="latarcyrheb-sun16"
> 
> and /etc/sysconfig/keyboard has
> 
> KEYTABLE="br-abnt2"
> MODEL="abnt2"
> LAYOUT="br"
> 
> So I would create /etc/locale.conf with
> 
> LANG="en_US.UTF-8"
> 
> and /etc/vconsole.conf with
> 
> FONT="latarcyrheb-sun16"
> KEYMAP="br-abnt2"
> 

Ok I read 'man locale.conf' and 'man vconsole.conf'

So in /etc/default/grub 
KEYTABLE is now vconsole.keymap
FONT is now vconsole.font
LANG is now locale.LANG


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: criterion discussion: memory test tool

[Kamil Paral]

> Worth considering the history: Petr proposed the general idea of a
> criterion as part of the criteria review, and I drafted the final
> wording. See thread "New criterion for Memory test" from end of
> January.

Thanks for finding that thread. We have to find a way how to link criteria with 
list discussions, so that it would be much easier to read all relevant 
discussion to a particular criterion. Putting that into my todo list (page 937).

The thread indicates the criterion was created ad-hoc, "the tool is there, 
let's codify it". Since we try to be more conservative about what is and what 
is not a blocker lately, I think this is a good candidate for removal.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: f18 vm inside f17 updated host needs tablet

[Karel Volný]

...
> IIRC the use of a tablet was actually *added* in recent releases because
> it makes the pointer tracking more accurate and avoids the double-cursor
> effect.

let my add my experience ... I'm not sure what the original post is all about, 
but I had some troubles with mouse pointer in qemu, especially when viewing 
over network - all the problems vanished after adding "-usbdevice tablet" to 
qemu commandline

K.

-- 
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp ka...@jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: merge test cases: VNC

[Kamil Paral]

> I think that's going too far. The VNC and VNC_Vncconnect cases are
> very
> different codepaths.
> 
> I think it'd be okay to merge VNC and VNC_Password and just require
> the
> testing to include use of a password.

OK, at least merging these two seems like a no-brainer to me. I'll leave the 
password optional, because that way both options get tested eventually.

> But Vncconnect should remain
> separate. We could consider dropping it from being a blocking test,
> though. I'm not sure we actually need to block release on the vnc
> connect functionality, though there may be some reason to. Is anyone
> aware of the use cases for the vncconnect functionality and how
> critical
> they are?

I think the main use case is if you want to install a machine behind a 
firewall, and you have a public IP. Whether that is critical enough to block 
the release or not, I do not know.

Anyone else has an opinion on that?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Kamil Paral]

> I actually agree that your argument for supporting install as a VBox
> *guest* makes a lot of sense, really, it's a pretty common use case.
> It's probably true that we've applied the 'we don't support VBox'
> mantra
> too easily to the VBox guest case, where it doesn't entirely apply.
> It's
> more about using Fedora as a VBox *host*. I wouldn't be opposed to
> proposals to test or even block on the VBox guest case, as it is a
> common case. Though we'd need to consider the problem where it breaks
> because of something in upstream VBox, which we can't control; that
> might be a deal-breaker for making it a blocker.

I'm very glad that you see it this way. I'd like to codify it somehow, and 
attach a link to this conversation, so we don't have to remember it. But I 
understand this is a problematic criterion, it would have to be very carefully 
worded. Basically, it makes sense to block the release only for VirtualBox 
issues that 1) are showstoppers, they prevent VB usage in a very serious way 2) 
are bugs in our components (e.g. graphics drivers), we can fix them and we also 
want to fix them (it wouldn't be a VB-specific hack).

I'm not sure we want to have a criterion like that. I'd rather have it written 
down in a "best-effort goals" document. Issues related to that document would 
be considered blockers only when they are extremely serious, otherwise they 
would be just NTH. We would use common sense and developer feedback when 
judging it. But that goes against our current policy "if it's not in the 
criteria, it's not a blocker".

Any preferences how to deal with that?

What I can do immediately is to create a new test case for VirtualBox. I'd mark 
it as optional for the time being. WDYT?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Question about rpmnew, rpmsave and config files in F18.

[Sergio]

On 11/08/2012 07:59 AM, Sergio wrote:

Hello. I upgraded from F17 via yum.
I understand that rpmnew files are created when an update has a new
config file and keeps the original config file and rpmsave I guess is
created when the original config file is renamed and the update installs
its new file.

But I would like to clear up about the files in /etc/pam.d

  pam.d]$ ll
total 148
{snip}
lrwxrwxrwx. 1 root root  19 May 24 20:57 fingerprint-auth ->
fingerprint-auth-ac
-rw-r--r--. 1 root root 702 May 24 20:57 fingerprint-auth-ac
-rw-r--r--. 1 root root 701 May  9  2012 fingerprint-auth.rpmnew
{snip}
lrwxrwxrwx. 1 root root  16 May 24 20:57 password-auth -> password-auth-ac
-rw-r--r--. 1 root root 949 May 24 20:57 password-auth-ac
-rw-r--r--. 1 root root 735 May  9  2012 password-auth.rpmnew
{snip}
lrwxrwxrwx. 1 root root  12 May 24 20:57 postlogin -> postlogin-ac
-rw-r--r--. 1 root root 109 May 24 20:57 postlogin-ac
-rw-r--r--  1 root root 314 Aug 17 10:56 postlogin.rpmnew
{snip}
lrwxrwxrwx. 1 root root  17 May 24 20:57 smartcard-auth ->
smartcard-auth-ac
-rw-r--r--. 1 root root 754 May 24 20:57 smartcard-auth-ac
-rw-r--r--. 1 root root 743 May  9  2012 smartcard-auth.rpmnew
{snip}
lrwxrwxrwx. 1 root root  14 May 24 20:57 system-auth -> system-auth-ac
-rw-r--r--. 1 root root 949 May 24 20:57 system-auth-ac
-rw-r--r--. 1 root root 735 May  9  2012 system-auth.rpmnew
{snip}

the files ending with '-ac' come from package authconfig and seems they
are being used by default but it looks like package pam has brought
replacements for those symlinks.
Did I understand it right? Because then I'll delete the symlinks and
rename the rpmnew files.

Thank you.


Ok, sorry for the noise. Installed rpmconf and could deal with them.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Question about rpmnew, rpmsave and config files in F18.

[Sergio]

Hello. I upgraded from F17 via yum.
I understand that rpmnew files are created when an update has a new 
config file and keeps the original config file and rpmsave I guess is 
created when the original config file is renamed and the update installs 
its new file.


But I would like to clear up about the files in /etc/pam.d

 pam.d]$ ll
total 148
{snip}
lrwxrwxrwx. 1 root root  19 May 24 20:57 fingerprint-auth -> 
fingerprint-auth-ac

-rw-r--r--. 1 root root 702 May 24 20:57 fingerprint-auth-ac
-rw-r--r--. 1 root root 701 May  9  2012 fingerprint-auth.rpmnew
{snip}
lrwxrwxrwx. 1 root root  16 May 24 20:57 password-auth -> password-auth-ac
-rw-r--r--. 1 root root 949 May 24 20:57 password-auth-ac
-rw-r--r--. 1 root root 735 May  9  2012 password-auth.rpmnew
{snip}
lrwxrwxrwx. 1 root root  12 May 24 20:57 postlogin -> postlogin-ac
-rw-r--r--. 1 root root 109 May 24 20:57 postlogin-ac
-rw-r--r--  1 root root 314 Aug 17 10:56 postlogin.rpmnew
{snip}
lrwxrwxrwx. 1 root root  17 May 24 20:57 smartcard-auth -> smartcard-auth-ac
-rw-r--r--. 1 root root 754 May 24 20:57 smartcard-auth-ac
-rw-r--r--. 1 root root 743 May  9  2012 smartcard-auth.rpmnew
{snip}
lrwxrwxrwx. 1 root root  14 May 24 20:57 system-auth -> system-auth-ac
-rw-r--r--. 1 root root 949 May 24 20:57 system-auth-ac
-rw-r--r--. 1 root root 735 May  9  2012 system-auth.rpmnew
{snip}

the files ending with '-ac' come from package authconfig and seems they 
are being used by default but it looks like package pam has brought 
replacements for those symlinks.
Did I understand it right? Because then I'll delete the symlinks and 
rename the rpmnew files.


Thank you.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[Test-Announce] Join Fedora GNOME 3.6 Test Day (2012-11-08)

[Martin Holec]

Hello,

this Thursday is Fedora GNOME 3.6 Test Day which is one of the most popular 
testing events among Fedora users and developers.

Gnome 3.6 has many new features: 
http://library.gnome.org/misc/release-notes/3.6/
Please join this test week and help us to hunt down Gnome desktop bugs before 
Fedora 18 Beta release!

For more informations how to attend this test week, look at the following page:
https://fedoraproject.org/wiki/Test_Day:2012-11-08_GNOME_3.6

Join IRC #fedora-test-day on FreeNode and ask QA or developers for help, if you 
get into trouble. We can try to find workarounds and help with debugging.
Please report all bugs at http://bugzilla.redhat.com/ under appropriate 
component. You can also report other Fedora 18 bugs not related to this Test 
Day, ask QA, if you don't know against which component you should fill the 
report.

See you in Bugzilla!

Best Regards,

Martin Holec
Desktop QE, Red Hat Brno
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: HEADS UP several very old sysconfig files are being deprecated

[Sergio]

On 10/26/2012 11:24 PM, "Jóhann B. Guðmundsson" wrote:

*
**/etc/sysconfig/i18n has been replaced by /etc/locale.conf *

LANG + All LC_* variables found in /etc/sysconfig/i18n as in

LANG=
LC_CTYPE=
LC_NUMERIC=
LC_TIME=
LC_COLLATE=
LC_MONETARY=
LC_MESSAGES=
LC_PAPER=
LC_NAME=
LC_ADDRESS=
LC_TELEPHONE=
LC_MEASUREMENT=
LC_IDENTIFICATION=

belong in /etc/locale.conf

The locale settings configured in here are system-wide and are inherited
by every service or user, unless overridden or unset by individual
programs or individual users.
See  man locale.conf for further details

*/etc/sysconfig/keyboard has been change to **/etc/vconsole.conf
*
The virtual console configuration is /etc/vconsole.conf
/*
*//*NOTE THAT THE VARIABLES BEING USED HAVE CHANGED*/

SYSFONT= becomes FONT=
SYSFONTACM= becomes FONT_MAP=
UNIMAP= becomes FONT_UNIMAP=
KEYTABLE= becomes KEYMAP=

Kernel keymap and fonts is the default being used if FONT= or KEYMAP=
are not set or empty


Hi, just to make sure.
Currently my /etc/sysconfig/i18n has

LANG="en_US.UTF-8"
SYSFONT="latarcyrheb-sun16"

and /etc/sysconfig/keyboard has

KEYTABLE="br-abnt2"
MODEL="abnt2"
LAYOUT="br"

So I would create /etc/locale.conf with

LANG="en_US.UTF-8"

and /etc/vconsole.conf with

FONT="latarcyrheb-sun16"
KEYMAP="br-abnt2"

Is that all? Should I put MODEL and LAYOUT in /etc/vconsole.conf too?

Thank you.

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test