[Fedora QA] #302: freeIPA test day request for 9.13.12
by fedora-badges
#302: freeIPA test day request for 9.13.12
----------------------+------------------
Reporter: dpal | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Test Day | Version:
Keywords: | Blocked By:
Blocking: |
----------------------+------------------
IPA team wants to allocate a test day slot on 9.13.12.
We will be providing details about the features to test and all the
instructions. This is not the first time we do it so we know the drill.
The only help we need is announcement of the IPA test day thought the
Fedora mailing lists.
We might need some other help but we not sure what it would be for now.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/302>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
7 years, 10 months
[Fedora QA] #305: Abrt test day request for 2012-09-27
by fedora-badges
#305: Abrt test day request for 2012-09-27
----------------------+------------------
Reporter: dkutalek | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Test Day | Version:
Keywords: | Blocked By:
Blocking: |
----------------------+------------------
I would like to allocate a test day slot for 2012-09-27.
This will be my first Test day as organizer, so I am just finding out how
things works and how it should look like. Seems like I have folks happy to
help around me in Brno, so hope everything will go fine.
I should bring in details in next weeks and expect having everything ready
by the end of August.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/305>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
7 years, 10 months
[Fedora QA] #308: Request for Fedora Networking Test Week
by fedora-badges
#308: Request for Fedora Networking Test Week
----------------------+------------------
Reporter: martix | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: Test Day | Version:
Keywords: | Blocked By:
Blocking: |
----------------------+------------------
We want to do Networking Test Week on 24.-26. October 2012.
We will focus our testing on Network Manager, dnssec-trigger, firewalld
new functionality, interactions between them and their integration in
Gnome and KDE desktops.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/308>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
7 years, 10 months
[Fedora QA] #304: Request for F18 Power Management test day
by fedora-badges
#304: Request for F18 Power Management test day
-----------------------------------------+------------------
Reporter: jskarvad | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: Proventester Mentor Request | Version:
Keywords: | Blocked By:
Blocking: |
-----------------------------------------+------------------
We would like to run F18 Power Management test day. We expect it to be
similar to our previous F17 Power Management test day. We will try to
prepare Live CDs for this event (as for F17). We suggest 2012-10-11 but
probably any date would fit to us. We would probably also try to hold this
on-site in Red Hat Brno office (as for f17).
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/304>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
7 years, 10 months
[Test-Announce] Call for Test Days for Fedora 18
by Adam Williamson
Hey, folks. It's that time again - time to start thinking about Test
Days for Fedora 18.
For anyone who isn't aware, a Test Day is an event usually focused
around IRC for interaction and a Wiki page for instructions and results,
with the aim being to get a bunch of interested users and developers
together to test a specific feature or area of the distribution. You can
run a Test Day on just about anything for which it would be useful to do
some fairly focused testing in 'real time' with a group of testers; it
doesn't have to be code, for instance we often run Test Days for
l10n/i18n topics. For more information on Test Days, see
https://fedoraproject.org/wiki/QA/Test_Days .
Anyone who wants to can host their own Test Day, or you can request that
the QA group helps you out with organization, or any combination of the
two. To propose a Test Day, just file a ticket in QA trac - full details
are at https://fedoraproject.org/wiki/QA/Test_Days/Create . For
instructions on hosting a Test Day, see
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management .
You can see the schedule at
https://fedoraproject.org/wiki/QA/Fedora_18_test_days . There are many
slots open right now, with the earliest on 2012-08-09 and the latest
2012-11-01. Consider the development schedule, though, in deciding when
you want to run your Test Day - for some topics you may want to avoid
the time before the Alpha release or the time after the feature freeze
or the Final freeze.
We normally aim to schedule Test Days on Thursdays; however, if you want
to run a series of related Test Days, it's often a good idea to do
something like Tuesday / Wednesday / Thursday of the same week (this is
how we usually run the X Test Week, for instance). If all the Thursday
slots fill up but more people want to run Test Days, we will open up
Tuesday slots as overflows. And finally, if you really want to run a
Test Day in a specific timeframe due to the development schedule, but
the Thursday slot for that week is full, we can add a slot on another
day. We're flexible! Just put in your ticket the date or timeframe you'd
like, and we'll figure it out from there.
If you have any questions about the Test Day process, please don't
hesitate to contact me or any other member of the QA team on test@ or in
#fedora-qa on IRC. Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
_______________________________________________
test-announce mailing list
test-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
7 years, 11 months
[Fedora QA] #151: Tests consistent with Criterion
by fedora-badges
#151: Tests consistent with Criterion
---------------------------+------------------------------------------------
Reporter: rhe | Owner: rhe
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 15
Component: Wiki | Version:
Keywords: retrospective |
---------------------------+------------------------------------------------
= problem =
Criteria was kept changing during F-14 test cycle, but some installation
tests didn't update accordingly. On the other hand, the criterion should
be modified to include preupgrade_from_older_release test and new tests
created for F-15.
= enhancement recommendation =
Installation tests need be reviewed and updated to fit for the criterion.
Criterion for preupgrade_from_older_release test is required.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/151>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
7 years, 11 months
how to enable ssh?
by cornel panceac
is there a way to enable ssh on f18? i tried enable/disable, start/stop
firewalld/iptables.service, and even lokkit --enabled (which responded
with: ERROR: FirewallD is active, please use firewall-cmd.)
8 years, 1 month
Criterion proposal: security
by Adam Williamson
So, IIRC, we've vaguely considered this before, but never really come up
with a criterion proposal. But I think we need one or two, to explicitly
allow security issues to be blockers.
I *really* don't want to get into the business of defining what
constitutes a security issue, and what the severity of various types of
issue is, in the criteria. It's a complex and specialized area, and
there are already authorities for doing this. I just had a look at the
major ones - notably CVSS - and it's crazy complex and we're not likely
to be doing those calculations ourselves, so I'm thinking it may be best
to take advantage of the relatively simple Red Hat security
classifications:
https://access.redhat.com/security/updates/classification/
That would allow us to say something like this:
Alpha: "The release must contain no known security issues of 'critical'
impact according to the Red Hat severity classification scale"
Beta: "The release must contain no known security issues of 'important'
impact according to the Red Hat severity classification scale which
cannot be fully resolved by a package update (e.g. issues during
installation)"
Final: "The release must contain no known security issues of 'important'
impact according to the Red Hat severity classification scale, or issues
of 'moderate' impact which cannot be fully resolved by a package update
(e.g. issues during installation)"
(remember that criteria are additive, the Alpha criterion would apply to
Beta and Final)
Something like that - the precise boundaries we could tweak, but I think
the basic idea flies. We use the severities from the RH classification
and we draw a line between issues that could be fixed with an update
(most will fall in this category) and ones we can't fix with an update -
like issues in anaconda.
What do folks think of this? Anyone want to tweak what severity issues
we block for when, or think the approach is bad? Thanks! We might not
want to start at Alpha, on the basis that Alpha is supposed to be for
testing *only* and should never have sensitive data committed to it, for
instance: we could combine the proposed Alpha criterion into the Beta
one.
CCing vdanen (from the security team) for a security expert perspective.
Vincent, your input would be appreciated, remember we can't set bars
*too* high for Fedora due to the release cycle and available development
resources - it'd be interesting to know what rules RHEL uses here, but
we can't necessarily do the same for Fedora.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8 years, 2 months
HEADS UP several very old sysconfig files are being deprecated
by Jóhann B. Guðmundsson
Just a bit of heads up about the recent changes taking place in systemd
( 195 ) for F18+...
The following sysconfig files are being deprecated /etc/sysconfig/clock,
/etc/sysconfig/i18n,/etc/sysconfig/keyboard, /etc/sysconfig/network (
Hostname only )
These changes should be transparent ( they are migrated to systemd
native files ) but various applications might still using the deprecated
files so be on the look out and report any bug you come across.
Ofcourse the fastest way to detect such breakage and to have it fixed,
along with avoiding users confusion would be simply to delete those
files...
So here's the break down...
*
**/etc/sysconfig/clock has been replaced by /etc/localtime *
The time zone is now configured by creating an appropriate
/etc/localtime symlink to the relevant timezone.
To list available timezone run the following command
# timedatectl list-timezone
To set timezone run the following command ( If you live in Iceland like
I do )
# timedatectl set-timezone Atlantic/Reykjavik"
Systemd uses UTC for the hardware clock by default however I recommend
people setup and use ntp
To set the system clock directly run
# set-time "2012-10-27 01:02:03"
I highly recommend against setting the hardware clock to localtime but
because I know some of you guys are dual booting with windows and to
lazy to fix the registry here's how you set the hardware clock to use
localtime instead..
# timedatectl set-local-rtc 1
To set configure the clock to use network time protocol start by
configuring ntp then enable the service
# systemctl enable ntpd.service
And run
# timedatectl set-ntp 1
And finally to see the current setting run
# timedatectl status
I think I have cover most uses case so see man timedatectl and man
localtime to explore it further..
*
**/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
*
**/etc/sysconfig/network ( hostname only ) to /etc/hostname *
There are now three distinguished hostnames in use..
The "pretty" a.k.a the high level one as in "my laptop"
The "static" hostname a.k.a kernel hostname at boot ( the one that got
migrated usually <fqdn> of the host>
The "transient" hostname ( temporary network hostname like dhcp-foo )
To set the pretty one run
# hostnamectl set-hostname <name> --pretty
To set the static one run
# hostnamectl set-hostname <name> --static
To set the transient one run
# hostnamectl set-hostname <name> --transient
To set the same hostname for all three run
# hostnamectl set-hostname <fqdn>
To see the hostname settings run
# hostnamectl status
See man hostname and man hostnamectl for further details.
I think that's about it for the most part so keep watching out for those
bugs
JBG
8 years, 2 months