[Fedora QA] #60: Devise a better location for critpath.txt
by fedora-badges
#60: Devise a better location for critpath.txt
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Wiki | Version:
Keywords: |
-------------------------+--------------------------------------------------
critpath.txt lists critical path packages [1]. Currently it is referenced
as
{{{
http://kojipkgs.fedoraproject.org/mash/rawhide-<<CURRENT
DATE>>/logs/critpath.txt
}}}
or
{{{
http://kojipkgs.fedoraproject.org/mash/rawhide-<<YESTERDAY
DATE>>/logs/critpath.txt
}}}
depending on which page. Similarly for branched releases.
This is not optimal. Very often the url just doesn't work. For example at
the time of writing critpath.txt on F13 Alpha Release Criteria page [2]
references rawhide-20100407/ directory, where critpath.txt is not
available. Nor it is available in rawhide-20100406/ directory. Only in
rawhide-20100405/ it is finally available.
The very page Critical Path Packages [1] references critpath.txt for
Branched release, which is available ATM, but also references critpath.txt
for Rawhide, which is again not available.
Let's imagine other use case - some automated tool must decide whether
package in the critical path. It can't rely on path which are constantly
changing and sometimes are not available.
critpath.txt is created dynamically, so we probably must have the contents
created every day or so. But we should devise such mechanism that the
location is stable and the file is always available (if new contents fails
to create, the old contents is still available). That will also allow
third-party tools to rely on it.
[1] https://fedoraproject.org/wiki/Critical_Path_Packages [[BR]]
[2] https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/60>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
9 years, 1 month
[Fedora QA] #236: No qa test for making sure that the boot.iso is hybridised
by fedora-badges
#236: No qa test for making sure that the boot.iso is hybridised
--------------------+-------------------------------------------------------
Reporter: ausil | Owner: adamw
Type: defect | Status: new
Priority: major | Milestone:
Component: Trac | Version:
Keywords: |
--------------------+-------------------------------------------------------
= bug description =
F-16 alpha shipped witha boot.iso that did not have isohybrid run on it,
this means you can not just dd it to a usb drive and boot it.
= bug analysis =
slipped though as there was no test case
= fix recommendation =
lorax has been fixed, but we should make sure we cover it in testing.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/236>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
9 years, 1 month
Release criteria: virtualization tweak
by Adam Williamson
Hey, all. pjones pointed out at a recent blocker review meeting that the
Beta virt criterion:
"The release must boot successfully as a virtual guest in a situation
where the virtual host is running the same release (using Fedora's
current preferred virtualization technology)"
doesn't really imply that virtual host functionality must work; only
that _if_ virtual host functionality is working, then virtual guest
functionality must work. This was not really our intent with the
criterion, we intended to require both to work at Beta stage. So here's
a proposed improvement:
"The release must be able to self-host using Fedora's current preferred
virtualization technology: that is, the release must be able to act as a
virtual host, and must also successfully install and boot as a virtual
guest when running on a host which is also running the release"
I'm still not super happy with the wording, but I guess it's clearer.
Any better ideas?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9 years, 3 months
Final Release Criterion for Xen DomU
by Tim Flink
During the discussion around Xen DomU support as a beta release
criterion in the Fedora QA meeting today, the question of blocking for
DomU came up.
Specifically, do we want to have Xen DomU support as a final release
criteria?
I can think of two arguments for making it a release criterion:
1. If install as DomU doesn't work at final release, it becomes much
more difficult to install as DomU for that release without spinning
custom install media.
2. Amazon EC2 is based on Xen, DomU support could affect our ability to
release on EC2.
Another thought is that Fedora 16 is going to be the first release in a
while that supports running as Xen Dom0. It seems a bit silly to have
support for Dom0 and not have the ability to run as DomU.
Anyhow, thoughts around making DomU support a final release criterion?
Tim
9 years, 3 months
fedora 16 dvd or network install ?
by cornel panceac
i've downloaded de x86 fedora 16 dvd install iso so that i'll no longer need
the network. during the install, i was asked to configure a wired network
interface (which i did), then proceeded to the install. later i've seen that
the usb stick from which i started the install (which contains the files
from dvd) is not used but instead the ethernet connection is the install
source. i've never tell anaconda to install from the internet (but maybe the
network repos were autoamgically selected). is this by design?
on the other hand, i've noticed that the 3.x kernel freezes often on my x40
thinkpad. is this a known issue? (i'll test the hardware anyway, after
install.)
9 years, 3 months
udevd and slow login?
by Tom Horsley
Just for grins I installed a script in rc.local to furiously
run ps f -e in a loop until it sees a gnome-terminal process
in the list and record the results in a log file.
I got about 40 MB of ps listings (which is a lot to look at :-),
but the most interesting bit I did see was this:
454 ? Ss 0:00 /lib/systemd/systemd-kmsg-syslogd
463 ? Ss 0:00 /sbin/udevd
467 ? S 0:00 \_ /sbin/udevd
468 ? S 0:00 \_ /sbin/udevd
469 ? S 0:00 \_ /sbin/udevd
470 ? S 0:00 \_ /sbin/udevd
471 ? S 0:00 \_ /sbin/udevd
474 ? S 0:00 \_ /sbin/udevd
475 ? S 0:00 \_ /sbin/udevd
476 ? S 0:00 \_ /sbin/udevd
477 ? S 0:00 \_ /sbin/udevd
478 ? S 0:00 \_ /sbin/udevd
479 ? S 0:00 \_ /sbin/udevd
480 ? S 0:00 \_ /sbin/udevd
481 ? S 0:00 \_ /sbin/udevd
482 ? S 0:00 \_ /sbin/udevd
483 ? S 0:00 \_ /sbin/udevd
484 ? S 0:00 \_ /sbin/udevd
485 ? S 0:00 \_ /sbin/udevd
507 ? S 0:00 \_ /sbin/udevd
508 ? S 0:00 \_ /sbin/udevd
509 ? S 0:00 \_ /sbin/udevd
510 ? S 0:00 \_ /sbin/udevd
511 ? S 0:00 \_ /sbin/udevd
512 ? S 0:00 \_ /sbin/udevd
514 ? S 0:00 \_ /sbin/udevd
515 ? S 0:00 \_ /sbin/udevd
516 ? S 0:00 \_ /sbin/udevd
517 ? S 0:00 \_ /sbin/udevd
518 ? S 0:00 \_ /sbin/udevd
519 ? S 0:00 \_ /sbin/udevd
520 ? S 0:00 \_ /sbin/udevd
522 ? S 0:00 \_ /sbin/udevd
526 ? S 0:00 \_ /sbin/udevd
527 ? S 0:00 \_ /sbin/udevd
528 ? S 0:00 \_ /sbin/udevd
529 ? S 0:00 \_ /sbin/udevd
540 ? S 0:00 \_ /sbin/udevd
541 ? S 0:00 \_ /sbin/udevd
542 ? S 0:00 \_ /sbin/udevd
543 ? S 0:00 \_ /sbin/udevd
544 ? S 0:00 \_ /sbin/udevd
545 ? S 0:00 \_ /sbin/udevd
546 ? S 0:00 \_ /sbin/udevd
547 ? S 0:00 \_ /sbin/udevd
548 ? S 0:00 \_ /sbin/udevd
549 ? S 0:00 \_ /sbin/udevd
550 ? S 0:00 \_ /sbin/udevd
551 ? S 0:00 \_ /sbin/udevd
552 ? S 0:00 \_ /sbin/udevd
553 ? S 0:00 \_ /sbin/udevd
554 ? S 0:00 \_ /sbin/udevd
473 ? Ss 0:00 /lib/systemd/systemd-readahead-collect
Those udevd kids showed up for a long time during the ps loop.
What the heck is udevd doing with all those kids, and could
it be what is responsible for it taking 20 seconds to do
a login after the initial boot?
9 years, 3 months
Good thing I build my own kernels
by Jonathan Corbet
As I was booting my system after today's Rawhide update, I noticed that
there were no Fedora kernels on offer at all. It seems like, once again,
grubby is going weird and refusing to add lines for new kernels to
grub.conf as they are installed.
Is this, perhaps, a subtle hint that I should switch the system to
grub2? :)
Thanks,
jon
9 years, 3 months