Hi there, folks.
Delve[0] (a Golang debugger) was retired due to the impossibility of
building a new version of delve for dependencies issues. I would like
to claim the package and fix the situation. I already have one of the
dependencies[1] in the works.
I already talked with the original maintainer (he's in cc) and he is OK with it.
Thanks.
[0] https://src.fedoraproject.org/rpms/delve
[1] https://src.fedoraproject.org/rpms/golang-starlark
It's in redhat-rpm-config-118-1.fc30.
If it causes any problems for you - let me know. In the meantime, you can
use `%undefine _ld_as_needed` to disable it.
Thanks for attention!
--
-Igor Gnatenko
Hi folks!
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
networking criteria.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.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
apt-cdrom. Thanks.
With kind regards,
Didier.
---
PhD student
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
Website: http://ssls.nus.edu.sg
I've orphaned luit. The only user of it was xterm and it recently dropped
support for luit so there are no users left. Whether there are *any* users
left is unclear too :)
The luit package we shipped is still the freedesktop.org one which has been
unmaintained for about a decade now. Upstream now points to
Thomas Dickey's fork at http://invisible-island.net/luit/ so if anyone
wants to take this, I advise switching to that version as part of the first
steps.
Cheers,
Peter
The License field for the libinstpatch 1.0.0 (a pre-release version from SVN) packaged in Fedora 32–34 has been corrected from “LGPLv2+” to “LGPLv2 and GPLv2 and Public Domain”.
In Fedora 35, libinstpatch has been updated to version 1.1.6, which brings another license change, to “LGPLv2 and Public Domain”, and a so-version bump from 0 to 2. Also the directory containing the headers now ends in the so-version (%{_incdir}/libinstpatch-2), but dependent packages all use pkgconfig and do not care.
I have built the update in the side tag “f35-build-side-40054”. The following PR’s cover the dependent packages:
muse: https://src.fedoraproject.org/rpms/muse/pull-request/1
gsequencer: https://src.fedoraproject.org/rpms/gsequencer/pull-request/1
Hey folks!
Just wanted to flag up that, now the new Bodhi version has been
deployed to production, critpath updates are gated on openQA test
results. If any openQA test for your critpath update failed, the gating
status will be marked as 'failed' and you will not be able to push it
stable.
Waivers can be issued for failed tests where appropriate:
https://docs.fedoraproject.org/en-US/ci/gating/#_waive
But in almost all cases a failure indicates either a genuine bug or an
opportunity to improve the test, so I'd prefer to avoid use of waivers
where possible. I am trying to keep an eye on all failed tests, but if
you have a blocked update and you don't understand the failure and I
haven't yet commented on it, please do poke me and I'll take a look.
If a failure looks like some kind of transient issue, several folks
have the power to rerun tests: myself, lruzicka, kparal, tflink,
abokovoy (abbra / ab), pwhalen, and sumantrom. You can ask one of us to
do it. There have been plans in the past to implement some sort of
rerun request system in Bodhi but no-one's quite had the roundtuits to
work it out yet; sorry about that.
Thanks everyone, please be patient with any kinks while we see how this
goes :)
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
Hello everyone,
As per the F36 schedule [1], rawhide starts F36 development on 2021-08-10.
I would like to bring in OpenSSL 3.0.0 [2] and the compat package [3]
(along with devel subpackage) into rawhide.
I would like your opinion/suggestion on:
1. Merging it and building it directly in rawhide. This will make OpenSSL
3.0.0 available by default for immediate use in rawhide.
FTBFS bugs can be reported when there is a mass-rebuild as per [1]
versus
2. Building it in a side-tag, adding all packages. Allowing the packages to
port and fix build failures
on the side-tag and finally merge the side-tag. FTBFS bugs can be reported
immediately.
I have a slight preference for option 1:
1. As rawhide enables us to try out stuff like this.
2. It is very early in the cycle to bring this change.
3. Many upstream packages have been ported (or are in the process of
porting) to
OpenSSL 3.0.0
4. Compat package (rebased to 1.1.1k version) is available with devel files.
Although option 2 sounds more organized.
But I could be missing some information/details. It would be nice to hear
about the experiences in the past and the preferred method by the community.
COPR repo [4] is updated with openssl-3.0.0-beta2.
Change proposal [5] is updated for F36.
[1] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
[2] https://src.fedoraproject.org/fork/saprasad/rpms/openssl/tree/rawhide
[3] https://src.fedoraproject.org/fork/saprasad/rpms/openssl1.1/tree/rawhide
[4] https://copr.fedorainfracloud.org/coprs/saprasad/openssl-3.0/builds/
[5] https://fedoraproject.org/wiki/Changes/OpenSSL3.0
Thank you,
Regards
Sahana Prasad