One factor that makes dnf difficult when poor network communication
causes downloads to time out is whatever partial file data has been read
is discarded. Dnf starts a new download for the failed file from a
different server. If that new download times out, whatever has been
received is
Qiyu Yan wrote on Sat, 01 May 2021 14:40:34 +0800:
It not the last installed becomes the dafault, but the one with highest
version nummber. And unluckily, there is a kernel downgrade with the
upgrade from f33 to f34.
That explains it. The recent F34 update to the 5.11.16-300 kernel
If no F34 kernal is installed, something went awry during the offline
upgrade.
Perhaps try the upgrade again, to learn whether this is a consistent
failure?
One of my systems has a /boot filesystem that is too small. Before I can
install a new kernel, I have to manually remove an older kernal
After upgrade from F33 to F34, the newly-installed kernel was not the
default to boot. I had to explicitly select the F34 kernel in lieu of an
older F33 kernel at boot time. This was a surprise for me (I expected
the last kernal installed to become the default), but it may not be
germane in your
Lukas Ruzicka wrote on Tue, 6 Apr 2021 09:44:22
+0200:
>what happened when you tried to reload the services (or restarting
>computer)?
Ah, the Power-On-Reset panacea. Cures many ills, and cured this one
nicely.
Both prior to pipewire (F33) and with pipewire (F34), it is possible to
obtain 192
Questions:
1. How can pipewire be configured for 192000 Hz audio output?
2. Are these problems with abrt at this time of Final Freeze
a reason for concern, or normal for the release process?
3. Does the message "Can't find packages for 33 debuginfo files"?
below signify some
Should multiple displays be a release-blocking criterion? I can imagine
a desire to ship a new release on-schedule because of significant,
content that works fine, but with multiple display support deferred for
an update because upstream problems are likely to take a while to fix. I
am
> Upgrading: grub2-efi-x64-1:2.06~rc1-3.fc35.x86_64
> 159/498
> warning: /boot/grub2/grubenv created as
> /boot/grub2/grubenv.rpmnew
>
> Upgrading: grub2-efi-x64-1:2.06~rc1-3.fc35.x86_64
Adam Williamson wrote on Wed, 24 Mar 2021 13:01:58 -0700:
>You may have a bad systemd build with name resolution issues. Try
>creating a file /etc/systemd/resolved.conf.d/nocache.conf with this
>content:
>
>[Resolve]
>Cache=no
>
>and restarting systemd-resolved.service, it may help.
This worked
Also happens with F34:
Errors during downloading metadata for repository 'fedora-modular':
- Curl error (7): Couldn't connect to server for
https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-34=x86_64 []
Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare
>In my opinion, a good review would be to install on hardware and show
>actual real-world work being done with Fedora 34, such as a drawing in
>FreeCAD, and how the system differs from Manjaro Gnome 40, Gnome OS,
>Ubuntu 20.10, etc.
Perhaps for the actual release, but this sounds premature for a
I filed:
https://bugzilla.redhat.com/show_bug.cgi?id=1940944
for gnome-abrt to document the cpio problem during extraction of
debuginfo from a downloaded file.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to
Tried again after a few hours. Still trouble with the retrace server,
but local analysis was able to say I experienced the already-reported
https://bugzilla.redhat.com/show_bug.cgi?id=1937073
Temporary unavailability of the server sounds plausible for the original
problem.
There are
Up-to-date F34 (18Mar21) originally installed from
Fedora-Workstation-Live-x86_64-34-20210316.n.0.iso
tries to report error and says:
--- Running report_uReport ---
Failed to upload uReport to the server 'https://retrace.fedoraproject.org/faf'
Error: curl_easy_perform: Couldn't connect to
The key appears to be:
>possible to switch between implementations. This will also allow for an
>easy rollback.
Provided this works easily (it should be an explicit part of the test
activity) it is reasonable to accept some instability or missing function
in the PipeWire facility in order to
Root is pretty much allowed to do everything. If root cannot change your
network operation, something indeed appears to be awry. If you cannot
figure out what, re-install Fedore will probably set things straight. If
not, at least you will have found a well-defined starting point that
others
Try: nmcli general permissions
I suspect network-scripts is the "old way" and with Network Manager you
need something else to specify who may do what with respect to network
connections.
___
test mailing list -- test@lists.fedoraproject.org
To
>When the UPS says the battery is exhausted, must shutdown now, it's more
>than just an aggravation.
It should not be. Worst case should be similar to abrupt power failure.
(Real case: I pull the wrong plug out of my power strip, disconnecting my
server instead of the device I intended to move.)
I think failure to shut down promptly should not be a "blocker" event.
Is shutdown in three minutes instead of three seconds an aggravation
for the user who wants to use a new kernal or another operating
system? Yes.
Does unreasonable time to shut down indicate lack of quality in
Fedora? Of
I am happy to see the 5.6.0-0.rc0.git5.1.fc32.x86_64 kernel recently
deployed to Rawhide supports the "Killer Wi-Fi 6 AX1650i 160MHz Wireless
Network Adapter (201NGW)" in my Dell XPS 13 laptop. The earlier 5.5
kernels did not initialize and use this wireless hardware.
After an update of my Rawhide system yesterday, it refused to boot. A
change to /etc/selinux/config to set SELINUX=permissive avoids the
problem. This may be a one-off situation due to my particular sequence
of updates, unless others have similar troubles. The system log for the
failing boot
With up-to-date (23 January 2020) Fedora Rawhide on a Dell XPS-13 7390
laptop machine, after resumption from suspend, or switching from an
alternate colsole back to the graphical console, I see the expected
graphical login screen. After I enter the correct password, I see a dark
screen (or
Can anyone report success to run gimp in Rawhide? I see its splash
screen, a few messages about initialization, then a segfault.
Full stack trace at: http://ryniker.org/Fedora/gimp_stack_trace
GNU Image Manipulation Program version 2.10.14
git-describe: GIMP_2_10_12-511-ga4f55d6c7e
C
For the first time, Fedora will boot on my Dell laptop:
Fedora-Workstation-Live-x86_64-Rawhide-20200101.n.0.iso
The kernel identifies the machine thus:
DMI: Dell Inc. XPS 13 7390 2-in-1/06CDVY, BIOS 1.1.3 11/10/2019
and Dell identifies it with Service Tag 8NMBZY2. CPU info:
vendor_id :
>Are either of those using EFI with secure boot? According to the bug
>report, that's the trigger.
I believe you are right. To my surprise, after inspection of the BIOS
displays in the machine that does allow data access, I find no mention at
all of secure boot capability.
The machine that
This seems to depend on kernel version. On one F30 system it works:
[root@yoga ryniker]# uname -r
5.0.17-300.fc30.x86_64
[root@yoga ryniker]# ls -l /sys/kernel/debug/usb/devices
-r--r--r--. 1 root root 0 May 30 09:59 /sys/kernel/debug/usb/devices
[root@yoga ryniker]# cat
I think you will find the file is not truly empty. /sys is not an actual
file system, merely an interface to kernel information. There is no
directory structure that records the length or other attributes of a file,
as is the case for data on real media such as disks.
If you read the
Chris Murphy wrote on Mon, 27 May 2019 22:27:16 -0600:
>Dual Fedora's isn't officially supported. The installer almost always
>steps on the previous Fedora's bootloader making it unbootable, in
>favor of a new bootloader for the new Fedora installation.
This deserves some attention. I expect
I have found some problems with resume from suspended state to be much
improved after I switched to "GNOME on xorg". It is too soon to
conclude they will not recur, but several days have passed without
difficulty.
F26 up-to-date on a Lenovo Yoga 3 11-inch laptop, model name 80J8.
>> In an extreme situation, a release could be nearly impossible due to
>> dependency cycles.
>
>You'd need to provide specific examples for "extreme" as this has not
>happened in recent Fedora history (at least back to F-21)
I cannot cite an historical example. With more than a thousand
I agree with you that Firefox is an important resource that Fedora should
deliver, but think a criterion that failure to supply the same default
package set for all (blocking) architectures will do more harm than good.
Release criteria should focus on the quality of what is delivered in a
>install F25 Beta in legacy mode on an 64GB flash medium. And surprise it
>works.
I think this suggests there is some configuration or BIOS problem with
EFI and USB in your machine. Both Chris Murphy and I performed
successful EFI installations, he with Apple and I with Samsung hardware.
It may
>an optical specific Live Workstation spin
Sounds like the proper category: will not block a regular Fedora release,
will not consume test resources for primary Fedora deliverables, and will
provide a focus for those with some stake in optical media.
While lack of community to support an
Might this be a clue (from your anaconda log)?
13:10:26,938 INFO anaconda: Running post-installation scripts
13:10:26,938 INFO anaconda: Running kickstart %%post script(s)
13:10:29,210 ERR anaconda: Error code 1 running the kickstart script at line
33
13:10:29,210 INFO anaconda: All
Works for me. I used a Samsung 940X laptop and a Sandisk 80GB USB3
external SSD.
This is a UEFI machine, and I installed using manual partitioning to
re-use partitions on the external device, which contained an old Fedora
23 system. My purpose here was to preserve an encrypted /home partition.
The target VM has two virtual IDE drives, sda (8 GB) for / and sdb
(0.5GB) for /boot. Installation proceded normally until time to install
the bootloader, which failed. Pop-up window said bootloader installation
failed, and I chose to continue anyway in order to acquire as much log
information
I seem to have touched a sore spot on Mr. Murphy, and apologize if I
have unintentionally irritated him. If he is the designer of the
offline update mechanism, and I correctly perceive the implications of
his explanation, then I do scold him for failure to mitigate the
damage that might occur to a
I am unhappy with the suggestion that the semantics of kernel parameters
may depend on some notion about how "temporary" they are. If a kernel
parameter is specified, it is present; if not specified, it is absent.
It is proper to design parameter syntax and default values to favor
common usage.
The following worked for me:
dnf erase astronomy-bookmarks
(This also erased firefox.)
dnf upgrade
dnf install firefox
(This also installed astronomy-bookmarks)
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
>A month is a pretty long time in Fedora development
True, but a month is only available if the problem is reported on day 1.
If it takes a week or two for a user to report a problem, that interval
lessens the remaining time to EOL.
On the other hand, there is no prohibition against a fix after
>It's not like dnf-system-upgrade would magically stop working when N-2
>reaches EOL, so honestly, overall, I just don't really see the problem
>you're describing
Like most of Fedora, dnf-system-upgrade gets limited testing before
release. When N is released, a large number of users who did not
System-upgrade across two releases raises an interesting End-of-Life
policy issue. If system-upgrade from N-2 to N is so important it will
block release of N until it works, how do we explain why it is no
longer important after four weeks when N-2 reaches End of Life?
Four weeks is little time
On Tue, 24 Nov 2015 10:46:55 -0800, Adam Williamson wrote:
> We have never really gone to any lengths to test or support N-1 upgrades
> with 3rd party repositories or non-repo software either. That's a
> different question.
>From a user's perspective, the value of system-upgrade depends on its
On Tue, 24 Nov 2015 07:52:47 -0500, Stephen Gallagher wrote:
> I've upgraded several family members directly from Fedora 21 to Fedora 23
> in the last week with no issues whatsoever (of course, I also curate
> their repository selection, so they don't end up with incompatible
> packages).
Aye,
I believe a failure to upgrade from N-2 to N should not block the N
release. The reason is limited resources, both for tests and for changes
to fix problems. These resources are more valuable applied to the N
release than to something two releases in the past.
If someone wants to test a
When you change from the GRUB default boot item, the timer stops and no
default boot occurs. You must use a key to tell GRUB to boot the current
selection.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
I think you may be the victim of GNOME's "Do what you maybe probably
want." attitude. This is something you might be able to configure to
your taste, given sufficient knowledge about what specifications to
change.
I have a Lenovo machine with a Realtec card reader:
[ryniker@lenovo ~]$ lspci |
>> I do not like to sacrifice well-defined, predictable behavior for
>> convenience
>
>Convenience is what users need!
>
>> but others may argue this default behavior serves the
>> greater good.
>
>What is the *greater good*?
I think the perceived "good" is that users can load a disk and have a
I suspect you suffer from software that wants to help you and "Do the
right thing."
If you try to mount a device with no media, mount might simply fail (no
media present). Instead, at least for optical drives, it presumes the
desired media might be available in the tray and requests the device
Auto Freeze Exeception seems too complicated an answer to this
question.
Either continue to call new background a blocker, or decide it is
desirable but not a blocking issue.
If lovely new art is not available, some generic Fnn background could
be used then replaced by an update after release,
Fedora-Live-Workstation-x86_64-22-TC3.iso installed without problems
using an external USB drive on my Macbook Pro with 15-inch Retina
Display. I logged on using GNOME with Wayland for the user created during
installation - no problem.
That said, the system appears fragile, and network
I was pleased to see Fedora-Live-Workstation-x86_64-22_Beta-2 boot on my
Apple MacBook Pro 15 with retina display. Install to disk completed
after some fragility relating to my USB flash drive installation
target. Wrote zeros to the first MByte of the flash drive, then Fedora
would partition,
Try:
yum grouplist hidden ids
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
It is interesting to note a difference from F21, where the login
processes are true daemons in the sense they have no controlling
terminal. Now, for example, joachim.bac...@rhrk.uni-kl.de reports:
ps -u gdm
PID TTY TIME CMD
1243 ?00:00:00 systemd
1244 ?00:00:00
Works OK on my Macbook Pro: i7-4850HQ processor with Intel Iris Pro
Graphics 5200 plus Nvidia GT-750M graphics processor.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
we also have no data about the prevalence of weak passwords or attacks
on default-configured Fedora systems
On my firewall system, /var/log/secure is larger than 300 megabytes
(less than one month of data), most of it reports of failed login
attempts to root. I am very careful about passwords on
Recapitiulation:
A security problem was recognized because the ssh daemon is enabled by
default on Fedora systems: with a weak root password, a remote attacker
might easily obtain unlimited access.
The direct solution would seem to be a change to the ssh daemon to
prohibit root login in its
Super simple passwords will no longer be allowed... increased security is
worth it.
No, you just made installation more bothersome - the user will then have
to set the passwords he wants after installation is complete. It is good
to warn about a weak password, but I feel I know better than you
Might this be an effect caused by removal of an old graphics driver?
https://lists.fedoraproject.org/pipermail/devel/2014-May/199459.html
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
a naming scheme that doesn't suck.
Please consider it desirable to implement a scheme with file names
that, in lexical order, list oldest version first (or last). Newest
version somewhere in the middle is a bad design.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
Thank you for years of work to improve Fedora. All Fedora users benefit
to some extent from your efforts.
as WG's slowy turn into tiny little empires fighting amongst themselves
for components directions and maintenance...
Fedora (and linux in general) is growing larger. As this happens,
And no manpage for blkid.
There is a man page for blkid. It is part of:
util-linux-2.24-2.fc20.x86_64
If the man page is missing, perhaps other missing pieces contribute to
the problem. For example, swapon is also in util-linux.
--
test mailing list
test@lists.fedoraproject.org
To
Kamil Paral kpa...@redhat.com wrote on Fri, 20 Dec 2013 05:00:24 -0500
The bandwidth problem should be solved by a simple program:
a. you run it on computer A (lacking bandwidth) - it gathers the list of
installed packages and exports a file
b. then you run it on computer B (good bandwidth) -
So strange as it may seem - it appears that it has to be shut for more than a
short time to fail.
Might it be a hibernation issue? After some period of time, perhaps your
machine wants to move from suspend to hibernate.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
The defining characteristic of the Live images is that they run
without installation on a user's disks. Beyond that, they have the
capability to install a minimal Fedora system to a local disk. Once
the size limit for a live image is increased beyond the capacity of a
CD (or other common media),
On Sat, 14 Dec 2013, at 11:25:40 -0800 Adam Williamson awill...@redhat.com
wrote:
One thing they've floated as an idea is to have a separate 'installation
environment' you could boot into from the live images - so you could
either boot into 'try it out' live mode, or 'install it'
Unnecessary private designation for a bug report might be due to
https://bugzilla.redhat.com/show_bug.cgi?id=1011916
which complains that a bug reporter has to decide about private status
before possibly sensitive information in the report can be examined.
--
test mailing list
The usbmuxd problems reported by yum in your post are likely unrelated to
the lsb issue.
I have a similar usbmuxd problem in F20 Beta TC4. After installation,
during the first yum update I noticed a message about a usbmuxd
scriptlet error. This message vanished among messages from hundreds of
I installed F20 Beta TC4 (KDE) on a Samsung Book 9 plus with no serious
difficulty, but touchpad operation is sometimes erratic and I see this in
syslog:
Oct 16 02:47:18 localhost kernel: [3.407835] usb 2-7: unable to read config
index 0 descriptor/start: -71
Oct 16 02:47:18 localhost
Well, a statically configured network interface might be expected to
just work.
With dynamic configuration, there must be successful contact with a DHCP
server, and the server must be willing to assign an IP address and
possibly provide other information (gateway, nameserver, host name) to
the
No, they're arch-specific. (geode is 32-bit x86, omap is ARM.)
That makes sense. Should yum understand this better? I mean, should the
group list specify architecture dependencies: some packages are needed
for one architecture, others needed for a different architecture?
As things stand, I do
These packages still exist, and haven't been removed or renamed as far
as I can tell.
Yum does not appear able to find them... do you think this is a local problem?
[root@lenovo ryniker]# yum list updates
Loaded plugins: langpacks, refresh-packagekit
[root@lenovo ryniker]# yum repolist
I still find the (maybe my own peculiar) F20 situation confusing. For example:
[root@lenovo ryniker]# yum -v group install kde-desktop-environment
Not loading blacklist plugin, as it is disabled
Loading langpacks plugin
Loading refresh-packagekit plugin
Not loading whiteout plugin, as
just fixed that in comps too, thanks!
Interested in others?
Group: base-x
Mandatory Packages:
-xorg-x11-drv-geode
-xorg-x11-drv-omap
Group-Id: printing
Mandatory Packages:
-ghostscript-cups
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
Still bizarre; works for you, not for me. Today:
[root@lenovo ryniker]# yum distro-sync full
Loaded plugins: langpacks, refresh-packagekit
No packages marked for distribution synchronization
[root@lenovo ryniker]# yum groupinstall KDE Plasma Workspaces
Loaded plugins: langpacks,
There is both a group and environment with:
nameKDE Plasma Workspaces/name
I presume you mean this is a repository problem. I tried yum clean all
and that did not help, even though I understand this will reload all
metadata (like group information) from the repository.
Or do you mean I may
On my last installation (TC4) anaconda's blue progress bar stalled at
approximately 40% while thousands of packages were installed. I suspect
this is Working as Designed. There is a continuing display of package
names as they are installed, as well as counts of installed packages and
total
This is recorded in my system journal (booting the iso install image from a USB
flash drive):
Aug 26 16:11:38 localhost kernel: ACPI Warning: \_SB_.PCI0.P0P1.PEGP._DSM:
Argument #4 type mismatch - Found [Integer], ACPI requires [Package]
(20130517/nsarguments-95)
Aug 26 16:11:38 localhost
Makes sense... the kernel is tainted after an oops. I was distracted
by thoughts about software with dubious provenance.
The first kernel oops (that taints the kernel) is documented here:
https://bugzilla.redhat.com/show_bug.cgi?id=1001806
--
test mailing list
test@lists.fedoraproject.org
To
Sounds like an unfortunate situation that should be addressed by use of a
Live system, which can repair or salvage data from the afflicted file
systems. If repair is possible, job done. If not possible, solution is
to re-install the operating system.
Rather than invest serious effort to make
Yeah, you have some sort of problem (configuration issue?) with your MTA:
2013-06-22 14:52:17 1UqSv3-0001aS-Kb = ryni...@ryniker.ods.org U=ryniker
P=local S=863
2013-06-22 14:52:18 1UqSv3-0001aS-Kb ** c...@omen.com R=dnslookup
T=remote_smtp: SMTP error from remote mail server after RCPT
Might it be possible to defer construction of the yum database until
Firstboot?
Just want to make it clear this is something to consider for F20. I
think it is too late to make this sort of change in F19.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
Does SELinux affect the problem?
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
I think new builds is a bad idea, a response to a worst-case event that
hopefully never happens. If the quality assurance process that generated
multiple alpha, beta, and release candidate builds has failed, another
try to fix one more bug will have less complete testing: it is too likely
to add
True, a usage scenario can often be devised to manifest the worst aspects
of any allocation scheme. There are many other factors that can have so
much influence that I suspect the number of partitions and volume groups
may have little to do with actual performance.
Disk device caching and
How does having two PVs on the same spindle increase latency?
Longer seeks - from one PV to the other - instead of two writes into the
same PV.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
I do not see this behavior; F18 updated to current level (without
updates-testing).
The firefox icon remains in my Favorites bar through logout-login, and
through reboot. Default Gnome desktop.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
Swap is a bit odd.
I don't see it as being any more or less odd than any other mount point. It's
either manual partitioning or not.
Swap is indeed odd. An unusual swap partition on an F18 target
installation disk can scuttle anaconda...
https://bugzilla.redhat.com/show_bug.cgi?id=886243
--
It has been reported...
https://bugzilla.redhat.com/show_bug.cgi?id=849476
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Mateusz Marzantowicz mmarzantow...@osdf.com.pl wrote on Tue, 11 Dec
2012 07:15:57 +0100
Maybe there should be two groups of packages: important (core or
whatever) that must be installed and other (not important) that might
fail to install?
I think it better to start over with a minimal install
F18 TC1 x86-64 install DVD displays some complaints (the following indented
lines
appeared on the console, but I copied them later from /var/log/boot.log):
[[1;32m OK [0m] Started Show Plymouth Boot Screen.
[[1;32m OK [0m] Reached target Basic System.
dracut-pre-pivot[457]: cp:
Probably not. There are too many possibilities to make reasonable any
default except do what the user explicitly says is desired.
The usual problems are hot-swap devices (USB, ESATA, etc.) that may be
present during installation but not later, and swap spaces intended for
other operating systems
John Reiser jrei...@bitwagon.com wrote on Fri, 07 Dec 2012 07:30:50 -0800
NO! NO! NO! Do NOT format any partition, including swap partitions,
except when explicitly requested. I want to share _some_ swap partitions,
but running mkswap destroys the UUID and/or label which other /etc/fstab
depend
we should make this possible via a command line parameter rather than a UI
option; it's an 'advanced' option that's only of use to multiboot
pokemoners (you know...gotta catch 'em all) and is a 'dangerous' option
for anyone who doesn't understand it - if you pick it when you don't know
what you're
Frank Murphy frankl...@gmail.com wrote on Fri, 26 Oct 2012 08:33:25 +0100:
So you agree, it's unneccessary.
For me to need at-spi*. Point made.
I think the point was at-spi is part of GTK, but this part is not
something it is reasonable to package separately, such as a language
package or some
On 09/26/2012 10:37 AM, Kamil Paral wrote:
I personally split maintainers in the distribution into three
categories.
1. Packager
2, Maintainer
3. Upstream maintainer
Is this an argument for an additional Fedora package class? At present,
it seems there are two well-defined types:
Upgrade installation is a bizarre beast, because the result is not well
defined. Yes, a newer set of packages is installed, but a new install
does that. The reason upgrade is so seductive is the notion all one's
configuration and personalization is carried into the upgraded system,
whereas a new
The installer must be able to successfully complete an upgrade
installation from a clean, fully updated default installation (from any
official install medium) of the previous stable Fedora release via any
officially supported upgrade mechanism. The upgraded system must meet
all release criteria.
I think we could link to
https://fedoraproject.org/wiki/Upgrading to define
'supported/recommendation upgrade mechanism'
OK, but to illustrate the problem with indirect references: the
Upgrading page you cite above says to read
You have convinced me, Adam. How much does it contribute to release
quality if excellent test criteria are perfectly validated, but the
documentation the end-user reads says Fedora does something different?
To that user, what he sees is clearly a fault.
QA may not be explicitly requested to vet
1 - 100 of 134 matches
Mail list logo
