There will be an outage starting at 2009-07-01 01:00 UTC, which will last
approximately 2 hours.
To convert UTC to your local time, take a look at
date -d '2009-07-01 01:00 UTC'
CVS / Source Control
Reason for Outage:
Final migration step for new cvs server. It will hopefully be offline for
only 30-45 minutes. The additional time is for some further tuning if
needed and some verification steps.
Please join #fedora-admin in irc.freenode.net or respond to this email to
track the status of this outage.
Fedora-devel-announce mailing list
Since haxe-4.1.3-4 and nekovm-2.3.0-4, both nekovm and haxe packages contains "/usr/lib/.build-id/b0/aed4ddf2d45372bcc79d5e95d2834f5045c09c".
The nekovm one is a symlink to "/usr/bin/neko". The haxe one to "/usr/bin/haxelib".
Both the neko and haxelib binaries are built with libneko, with a nearly identical main.c with the only difference of the present of neko bytecode embedded as a byte array (neko: the byte array is null; haxelib: the byte array is the haxelib neko bytecode).
I'm not sure how to resolve it.
when trying to install pipewire-jack-audio-connection-kit i get this error message:
# dnf -y install pipewire-jack-audio-connection-kit
Last metadata expiration check: 1:39:52 ago on Thu Dec 31 14:10:39 2020.
Problem: problem with installed package jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- conflicting requests
- package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
How can i fix this ?
Long story short I lost my home directory where I do all of my packager
activities (separate from my main user) so I'm setting things up from
I created new ssh keys and uploaded the public key to
admin.fedoraproject.org and pasted into pagure.io. It's been over an hour
and I'm still getting:
$ fedpkg clone hamlib
Cloning into 'hamlib'...
hobbes1069(a)pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.
I've also updated my API tokens, which is STILL not well documented. I
pasted them in the appropriate spot in "/etc/rpkg/fedpkg.conf" which isn't
So at this week's blocker review meeting, the fact that we don't have
explicit networking requirements in the release criteria really started
to bite us. In the past we have squeezed networking-related issues in
under other criteria, but for some issues that's really difficult,
notably VPN issues. So, we agreed we should draft some explicit
This turns out to be a big area and quite hard to cover (who'd've
thought!), but here is at least a first draft for us to start from. My
proposal would be to add this to the Basic criteria. I have left out
some wikitext stuff from the proposal for clarity; I'd add it back in
on actually applying the proposed changes. It's just formatting stuff,
nothing that'd change the meaning. Anyone have thoughts, complaints,
alternative approaches, supplements? Thanks!
=== Network requirements ===
Each of these requirements apply to both installer and installed system
environments. For any given installer environment, the 'default network
configuration tools' are considered to be those the installer documents
as supported ways to configure networking (e.g. for anaconda-based
environments, configuration via kernel command line options, a
kickstart, or interactively in anaconda itself are included).
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections
using DHCP and static addressing. The default network configuration
tools for the console and for release-blocking desktops must work well
enough to allow typical network connection configuration operations
without major workarounds. Standard network functions such as address
resolution and connections with common protocols such as ping, HTTP and
ssh must work as expected.
Footnote titled "Supported hardware": Supported network hardware is
hardware for which the Fedora kernel includes drivers and, where
necessary, for which a firmware package is available. If support for a
commonly-used piece or type of network hardware that would usually be
present is omitted, that may constitute a violation of this criterion,
after consideration of the [[Blocker_Bug_FAQ|hardware-dependent-
issues|normal factors for hardware-dependent issues]]. Similarly,
violations of this criteria that are hardware or configuration
dependent are, as usual, subject to consideration of those factors when
determining whether they are release-blocking
==== VPN connections ====
Using the default network configuration tools for the console and for
release-blocking desktops, it must be possible to establish a working
connection to common OpenVPN, openconnect-supported and vpnc-supported
VNC servers with typical configurations.
Footnote title "Supported servers and configurations": As there are
many different VPN server applications and configurations, blocker
reviewers must use their best judgment in determining whether
violations of this criterion are likely to be encountered commonly
enough to block a release, and if so, at which milestone. As a general
principle, the more people are likely to use affected servers and the
less complicated the configuration required to hit the bug, the more
likely it is to be a blocker.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
With kind regards,
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg