Re: digikam and kipi-plugins?
by Rex Dieter
Per Bothner wrote:
> The Rawhide version of digikam is the very latest (0.10.0-rc1),
> but it fails to find any of the "Kipi plugins", even though I've
> installed the kipi-plugins package. This might be an upstream
> issue, since 0.10.0 is pretty bleeding edge and the kipi-plugins
> may even more bleeding-edge. Gwenview does seem to be see the
> plugins, so I'm wondering if there is there might be a
> Fedora-specific problem before I complain upstream ...
The f10 builds seem to work fine for me (finding the plugins), so perhaps
this is rawhide-specific?
To be clear, digikam's Settings -> configure digikam -> Kipi Plugins is
empty?
-- Rex
5 years, 1 month
Mouse Wheel gone
by Christian Menzel
Since the latest xorg-X11 upgrade I receive the already mentioned XKB
error and the mouse wheel is not working anymore.
Has anybody seen this behavior?
Regards
Chris
5 years, 1 month
Re: NFS failure
by Fulko.Hew@sita.aero
Damian Menscher <menscher(a)uiuc.edu>@redhat.com on 04/07/2004 04:57:13 PM
wrote:
> On Wed, 7 Apr 2004, Jeff Elkins wrote:
>
> > I'm getting failure messages on my nfs mounts i.e. :
> >
> > mount to NFS server 'music.elkins' failed: server is down.
> >
> > nsfd appears to be running and I didn't see anything suspicious in the
logs.
> > The servers are up and running and have other clients connected.
>
> You didn't mention what steps you took to debug it:
>
> Can you ping the server?
> What is the output of rpcinfo -p servername?
> Does the server have access restrictions (firewall, TCP Wrappers, etc)?
I have the same symptoms...
rpcinfo says that nfs et.al. are running.
Something has changed in test 2, since the same PC running RH9
accesses that host just fine.
5 years, 1 month
[Fedora QA] #273: Improve browseability of validation matrix pages
by fedora-badges
#273: Improve browseability of validation matrix pages
-----------------------------------------+------------------------
Reporter: adamwill | Owner: adamwill
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 17
Component: Proventester Mentor Request | Version:
Keywords: | Blocked By:
Blocking: |
-----------------------------------------+------------------------
= problem =
cwickert and sandro have told us they have trouble finding the validation
matrix pages when they need them.
= analysis =
we do have the pages logically named and categorized, but it's still not
that easy to, for e.g., see all the desktop result pages for a given
release at a glance.
= enhancement recommendation =
We could add more categories, for example "Fedora XX
{{desktop,base,install}} validation results" categories, and any others
that come to mind (suggestions please!) It would be nice to have 'next /
previous' links that would let you browse from Final RC4 back to Final RC3
back to Final RC2 back to Final RC1 back to Final TC2 back to Final TC1
back to Beta RC4 and so on, but I'm not sure if that's plausible to
implement automatically (it would be relatively easy to do manually when
creating the pages, though).
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/273>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
5 years, 11 months
[Fedora QA] #228: SOPs for Everything
by fedora-badges
#228: SOPs for Everything
----------------------+-----------------------------------------------------
Reporter: adamwill | Owner: adamwill
Type: task | Status: new
Priority: major | Milestone: Fedora 17
Component: Wiki | Version:
Keywords: |
----------------------+-----------------------------------------------------
We should have...SOPs for Everything!
This is a meta-ticket with the aim of identifying, well, everything QA
does, and making sure they all have SOPs. For a start, I'm going to do a
survey of the QA calendar for a release, and check whether we have an SOP
for each task.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/228>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
5 years, 11 months
[Fedora QA] #277: Add ARM to release criteria / validation process somehow
by fedora-badges
#277: Add ARM to release criteria / validation process somehow
----------------------+------------------------
Reporter: adamwill | Owner: adamwill
Type: task | Status: new
Priority: critical | Milestone: Fedora 17
Component: Wiki | Version:
Keywords: arm | Blocked By:
Blocking: |
----------------------+------------------------
= phenomenon =
ARM is becoming increasingly important to releases. Currently we have no
kind of formal validation process for ARM images. Let's work with the ARM
group to improve this, so we can test whatever is most important to them.
= background analysis =
ARM deployment is significantly different from x86: the standard way to do
things is to provide a pre-built image to dump onto the system, not to
'install' via anaconda. So a lot of our test suite, which is based around
anaconda, may not be entirely appropriate to ARM. Similarly, the desktop
validation stuff isn't likely to be super-interesting to them, as desktop
isn't currently a priority for ARM and things at that high a level ought
to pretty much 'just work'. We should figure out with the ARM team what it
would be most useful to test, and how to work testing into their release
process.
= implementation recommendation =
We may need to write a few new tests, then I think we should design an
ARM-specific validation matrix, which may be much smaller than the main
ones. To start with we may also want to start separate ARM release
criteria pages, to codify the things which are most important to ARM
releases.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/277>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
5 years, 11 months
[Fedora QA] #272: Add changelog to TC/RC announce mails
by fedora-badges
#272: Add changelog to TC/RC announce mails
-------------------------+------------------------
Reporter: adamwill | Owner: robatino
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 17
Component: Trac | Version:
Keywords: | Blocked By:
Blocking: |
-------------------------+------------------------
= problem =
cwickert pointed out in the F16 QA retrospective that the information on
what has changed between TC / RC builds is not easy to find for those
outside of QA.
= enhancement recommendation =
We should include a changelog in the TC / RC announce mails. The
information can usually be found in the rel-eng trac ticket - e.g.
https://fedorahosted.org/rel-eng/ticket/4967 for F16 final - although
sometimes, also, packages are pushed to stable between TC / RC builds:
these would not always be listed out in the trac ticket.
After TC1, the TC / RC announce mails should list all the new builds
included in the build compared to the previous build, and any other
changes (e.g. kickstart or compose process change to fix some bug or
other).
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/272>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
5 years, 11 months
[Fedora QA] #237: tests to verify that torrents and mirrors contain signed checksum files
by fedora-badges
#237: tests to verify that torrents and mirrors contain signed checksum files
----------------------+-----------------------------------------------------
Reporter: robatino | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: Wiki | Version:
Keywords: |
----------------------+-----------------------------------------------------
In many of the last several releases (11, 13, 14, and now 16), at least
some of the Alpha or Beta torrents contain only unsigned checksum files.
This would be easy to prevent by examining the .torrent files, which
contain file sizes (signing a checksum file adds about 1K to the size).
Unfortunately, at present these are not made available for testing prior
to being posted on http://torrent.fedoraproject.org , and when the problem
is pointed out, no matter how quickly, one is told that the torrent can't
be replaced since people are already downloading it. This makes it
important to catch the problem in advance.
Many (but not all) of the torrent files for the last several releases are
still available at http://torrent.fedoraproject.org/torrents/ and
http://torrent.fedoraproject.org/spins/ , and can be examined for example
with gtorrentviewer. I have not checked any older than 11, and not all the
ones after that are available, so the above list of affected releases is
probably incomplete.
A less serious issue is when the checksum files get signed more than once.
For example, the checksum files for F15 Final install discs were signed
twice, first for the torrents and again for the mirrors - see
http://robatino.fedorapeople.org/checksums/15-Final/Fedora/ . The
checksums are identical, and both signatures are valid, but still, it
shouldn't happen.
Looking at
https://fedoraproject.org/wiki/Release_Engineering_Release_Tickets , it
says that for Alpha and Beta, the torrents should be staged before the
mirrors, but the reverse for Final. I've asked why on #fedora-releng but
gotten no response yet. It says nothing about signing the checksum files,
though the linked page
https://fedoraproject.org/wiki/Stage_final_release_for_mirrors (under the
section "Final") mentions it. This may explain why Alpha and Beta torrents
are much less likely to have signed files. If possible, it would be nice
for the order (torrents vs. mirrors) to be the same for all three, and in
any case, the checksum files should be signed once and then used for both
torrents and mirrors. None of this is currently documented.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/237>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
5 years, 11 months