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
3 years, 5 months
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
3 years, 5 months
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.
3 years, 5 months
DNF kernel-devel: The Final Frontier
by poma
# yum install $(ls *3.16.0-0.rc6.git0.1.fc21.1.x86_64.rpm)
...
--> Finished Dependency Resolution
Dependencies Resolved
==================================================================================================================================
Package Arch Version Repository Size
==================================================================================================================================
Installing:
kernel x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-3.16.0-0.rc6.git0.1.fc21.1.x86_64 0.0
kernel-core x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-core-3.16.0-0.rc6.git0.1.fc21.1.x86_64 40 M
kernel-debug x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-debug-3.16.0-0.rc6.git0.1.fc21.1.x86_64 0.0
kernel-debug-core x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-debug-core-3.16.0-0.rc6.git0.1.fc21.1.x86_64 41 M
kernel-debug-devel x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-debug-devel-3.16.0-0.rc6.git0.1.fc21.1.x86_64 34 M
kernel-debug-modules x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-debug-modules-3.16.0-0.rc6.git0.1.fc21.1.x86_64 17 M
kernel-debug-modules-extra x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-debug-modules-extra-3.16.0-0.rc6.git0.1.fc21.1.x86_64 2.2 M
kernel-devel x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-devel-3.16.0-0.rc6.git0.1.fc21.1.x86_64 33 M
kernel-modules x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-modules-3.16.0-0.rc6.git0.1.fc21.1.x86_64 17 M
kernel-modules-extra x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-modules-extra-3.16.0-0.rc6.git0.1.fc21.1.x86_64 2.1 M
Updating:
kernel-headers x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-headers-3.16.0-0.rc6.git0.1.fc21.1.x86_64 3.2 M
kernel-tools x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-tools-3.16.0-0.rc6.git0.1.fc21.1.x86_64 226 k
kernel-tools-libs x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-tools-libs-3.16.0-0.rc6.git0.1.fc21.1.x86_64 18 k
kernel-tools-libs-devel x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-tools-libs-devel-3.16.0-0.rc6.git0.1.fc21.1.x86_64 5.8 k
perf x86_64 3.16.0-0.rc6.git0.1.fc21.1 /perf-3.16.0-0.rc6.git0.1.fc21.1.x86_64 2.4 M
python-perf x86_64 3.16.0-0.rc6.git0.1.fc21.1 /python-perf-3.16.0-0.rc6.git0.1.fc21.1.x86_64 344 k
Removing:
kernel x86_64 3.16.0-0.rc5.git0.1.fc21 @rawhide-koji 0.0
kernel-core x86_64 3.16.0-0.rc5.git0.1.fc21 @rawhide-koji 40 M
kernel-devel x86_64 3.16.0-0.rc5.git0.1.fc21 @rawhide-koji 33 M
kernel-modules x86_64 3.16.0-0.rc5.git0.1.fc21 @rawhide-koji 17 M
kernel-modules-extra x86_64 3.16.0-0.rc5.git0.1.fc21 @rawhide-koji 2.1 M
Transaction Summary
===================================================================================================================================
Install 10 Packages
Upgrade 6 Packages
Remove 5 Packages
Total size: 193 M
Is this ok [y/d/N]: y
https://bugzilla.redhat.com/show_bug.cgi?id=1062997#c22
# dnf install $(ls *3.16.0-0.rc6.git0.1.fc21.1.x86_64.rpm)
...
--> Finished dependency resolution
Dependencies resolved.
=====================================================================================
Package Arch Version Repository Size
=====================================================================================
Installing:
kernel x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 32 k
kernel-core x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 18 M
kernel-debug x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 32 k
kernel-debug-core x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 19 M
kernel-debug-devel x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 9.0 M
kernel-debug-modules x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 18 M
kernel-debug-modules-extra x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 2.3 M
kernel-modules x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 17 M
kernel-modules-extra x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 2.2 M
Upgrading:
kernel-devel x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 8.9 M
kernel-headers x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 931 k
kernel-tools x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 114 k
kernel-tools-libs x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 38 k
kernel-tools-libs-devel x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 35 k
perf x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 983 k
python-perf x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 125 k
Removing:
kernel x86_64 3.16.0-0.rc5.git0.1.fc21 @System 0
kernel-core x86_64 3.16.0-0.rc5.git0.1.fc21 @System 40 M
kernel-modules x86_64 3.16.0-0.rc5.git0.1.fc21 @System 17 M
kernel-modules-extra x86_64 3.16.0-0.rc5.git0.1.fc21 @System .1 M
Transaction Summary
=====================================================================================
Install 9 Packages
Upgrade 7 Packages
Remove 4 Packages
Total size: 96 M
Is this ok [y/N]: N
poma
4 years, 2 months
[Fedora QA] #322: New release criterion: no X libs in the minimal install set
by fedora-badges
#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: <https://fedorahosted.org/fedora-qa/ticket/322>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
4 years, 2 months
[Fedora QA] #443: Better format for test compose (TC) and release candidate (RC) requests
by fedora-badges
#443: Better format for test compose (TC) and release candidate (RC) requests
----------------------------------------+------------------------
Reporter: jreznik | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 21
Component: Blocker/NTH review process | Version:
Keywords: | Blocked By:
Blocking: |
----------------------------------------+------------------------
= problem =
With Dennis (in CC), we discussed how to make release process, with
Fedora.next in mind, more transparent and bullet proof. One issue is that
releng request can become pretty messy, with full text included and
sometimes it leads to errors (omission of packages in compose etc).
= enhancement recommendation =
One possibility is to visibly separate full text description (with bug
numbers, reasons - it's good to have history) and the list of exact nvrs
(maybe in code block?), try to avoid "qt bundle" etc. so it's easier to
pick up the right list (for blockers, FEs + exceptional tools requests).
Another thing is better coordination between requester/releng - to mark
when/which list was picked up etc, in similar way how Go/No-Go decision is
stated in the ticket.
Now I'll let more space to Dennis, maybe example of how the request should
look like to make it easy to parse would help.
Long term (and preferred) solution would be to have automation in place,
Blocker app talking to releng interface, compose database, web dashboard
etc...
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/443>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
4 years, 2 months
[Fedora QA] #398: Add Secure Boot test case
by fedora-badges
#398: Add Secure Boot test case
----------------------+------------------------
Reporter: adamwill | Owner:
Type: task | Status: new
Priority: major | Milestone: Fedora 20
Component: Wiki | Version:
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------
We don't have an explicit test for doing a Secure Boot install. We should
have one, for the most basic case (install to a system with a typical OEM
SB configuration).
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/398>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
4 years, 2 months
[Fedora QA] #395: Consider how to improve testing of different installer interfaces
by fedora-badges
#395: Consider how to improve testing of different installer interfaces
----------------------+------------------------
Reporter: adamwill | Owner:
Type: task | Status: new
Priority: major | Milestone: Fedora 20
Component: Wiki | Version:
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------
During the F19 cycle, the anaconda text installer interface became a lot
more capable; it now replicates almost all the functionality of the
graphical UI, only really missing custom partitioning.
However, we still only have a single test case for it -
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Text -
which simply says 'run any old text install you like'. That's a bit weak.
We may want to re-evaluate the most sensible way to test the different
installer interfaces; just having a single test case for each interface
seems a bit of an odd approach. It seems more reasonable to run the
functional test cases against multiple interfaces, though it may be
unrealistic to try and run every test case against every possible
arch/interface combination.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/395>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
4 years, 2 months
[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
4 years, 2 months
