F31 System-Wide Change proposal: Automatic strict inter-package dependencies
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Automatic_strict_inter-package_dep...
= Automatic strict inter-package dependencies =
== Summary ==
Implement feature in RPM which will enforce strict dependencies
between subpackages automatically (right now packagers have to do it
themselves).
== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]]
* Email: ignatenkobrain(a)fedoraproject.org
== Detailed Description ==
Let's take graphene as an example.
Spec file contains:
<pre>
%package devel
Requires: %{name}%{?_isa} = %{version}-%{release}
%package tests
Requires: %{name}%{?_isa} = %{version}-%{release}
</pre>
What we see when we build RPMs is:
* <code>graphene-devel</code> requires <code>graphene(x86-64) =
1.8.2-3.fc30</code> AND <code>libgraphene-1.0.so.0()(64bit)</code> AND
<code>pkgconfig(graphene-1.0)</code>
* <code>graphene-tests</code> requires <code>graphene(x86-64) =
1.8.2-3.fc30</code> AND <code>libgraphene-1.0.so.0()(64bit)</code>
What can we do?
* <code>Requires: libgraphene-1.0.so.0()(64bit)</code> is actually
provided by <code>graphene</code> (coming from same package), so it
can be dropped in favor of <code>Requires: graphene(x86-64) =
1.8.2-3.fc30</code>
* <code>Requires: pkgconfig(graphene-1.0)</code> is provided by
<code>graphene-devel</code> (coming from the same subpackage), so it
can be dropped entirely
== Benefit to Fedora ==
Package dependencies (between subpackages) will be more strict, more
automated ([https://docs.fedoraproject.org/en-US/packaging-guidelines/#_requiring_bas...
this section from guidelines] can be dropped entirely). Metadata size
will decrease as well.
== Scope ==
* Proposal owners: Implement required feature in RPM, backport it to Fedora.
* Other developers: Drop unneeded dependencies to keep spec file simpler.
* Release engineering: [https://pagure.io/releng/issue/8128 #8128]
* Policies and guidelines: Drop yet another Packaging Guidelines
section because it will be automated.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Everything will keep working.
== How To Test ==
TBD.
== User Experience ==
User's won't see packaging errors (wrt. inter-package dependencies) anymore.
== Dependencies ==
RPM changes are needed. Will be handled by Proposal Owners.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Proposal
Owners will try to fix problems ASAP or move Change to the next
release (and revert changes).
* Contingency deadline: Beta Freeze.
* Blocks release? No.
* Blocks product? No.
== Documentation ==
TBD.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months
Non-responsive maintainer cquad
by Jakub Jelen
Hello all,
according to the policy [1], I am starting a non-responsive maintainer
process to be able to update dependency of one of my packages. I filled
a bug several months ago and explicitly asked for ans answer last week
[2] without any response.
Cedric (in cc) does not look active in Fedora during last year. If you
know some other contact, than the email in the FAS, please let me know.
Last login in FAS:
cquad 2018-04-25
Last action on koji:
Sat, 19 Aug 2017 package list entry revoked: gitso in dist-6E-epel
by pkgdb
Last package update on bodhi:
2017-02-04 06:31:48 on package svgsalamander-1.1.1-1.fc25
Last actions performed according to fedmsg:
- jjelen(a)redhat.com updated 'flag.needinfo' on RHBZ#1645865 'Please,
update svgsalamander to 1.1.2' on 2019-02-20 09:58:44 ()
- jjelen(a)redhat.com updated 'flag.needinfo' on RHBZ#1645865 'Please,
update svgsalamander to 1.1.2' on 2019-02-20 09:58:44 ()
- releng updated nothing on RHBZ#1675995 'signpost-core: FTBFS in
Fedora rawhide/f...' on 2019-02-11 22:58:50 ()
- releng updated nothing on RHBZ#1674975 'gitso: FTBFS in Fedora
rawhide/f30' on 2019-02-11 19:27:02 ()
- unofficialmonsters(a)gmail.com commented on RHBZ#1536356 '[abrt]
pulseaudio: pa_bluetooth_discover...' on 2018-12-08 09:10:44 ()
- bcotton(a)redhat.com commented on RHBZ#1524586 'CVE-2016-4216
xmpcore: XXE resulting in ...' on 2018-11-27 18:52:24 ()
- bcotton(a)redhat.com commented on RHBZ#1417569 'CVE-2017-5617
svgsalamander: Server side...' on 2018-11-27 16:26:00 ()
- cquad moved to position 876 on the badges leaderboard on 2018-11-21
05:19:24 ()
- cquad has been awarded the "Adult Frog" badge on 2018-11-21
05:19:13 ()
- jjelen(a)redhat.com filed a new bug RHBZ#1645865 'Please, update
svgsalamander to 1.1.2' on 2018-11-04 14:27:17 ()
[1]
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_packa...
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1645865
Thanks,
--
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.
5 years, 2 months
Re: Undelivered Mail Returned to Sender
by Dridi Boukelmoune
On Sun, Feb 24, 2019 at 11:23 AM Mail Delivery System
<MAILER-DAEMON(a)fedoraproject.org> wrote:
>
> This is the mail system at host bastion02.phx2.fedoraproject.org.
>
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send mail to postmaster.
>
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
>
> The mail system
>
> <Axel.Thimm(a)ATrpms.net> (expanded from <apt-owner(a)fedoraproject.org>): connect
> to mail1.ATrpms.net[160.45.254.20]:25: Connection refused
That's unfortunate, I was hoping to discuss this this the apt-rpm
downstream maintainers, but no response from them so far.
The weird thing in the email is that AT right after the @ symbol which
looks like a copy-paste-edit mistake. Does anyone know how to contact
Axel Thimm?
I will also CC Mosaab Alzoubi (moceap) and Itamar Reis Peixoto
(itamarjp) directly, hoping that they will retire apt-rpm promptly on
rawhide as per Panu's recommendation. It would have been better before
f30 branched, but I started this thread late in the cycle...
Dridi
5 years, 2 months
Problem with cmake's PythonInterp in F29 and F28
by Artur Iwicki
I've got a package (colobot) which has a build-time dependency on Python3. The program had a new upstream release today, so I updated the spec file and fired up the builds.
Everything went smooth on rawhide and F30, whereas the F29 and F28 builds failed with a rather amusing error message:
>BUILDSTDERR: CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
>BUILDSTDERR: Could NOT find PythonInterp: Found unsuitable version "1.4", but required
>BUILDSTDERR: is at least "2.7" (found
>BUILDSTDERR: /builddir/build/BUILD/colobot-colobot-gold-0.1.12-alpha/build/%{__python3})
>BUILDSTDERR: Call Stack (most recent call first):
>BUILDSTDERR: /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:376 (_FPHSA_FAILURE_MESSAGE)
>BUILDSTDERR: /usr/share/cmake/Modules/FindPythonInterp.cmake:159 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>BUILDSTDERR: data/CMakeLists.txt:6 (find_package)
>-- Configuring incomplete, errors occurred!
So, uh, is this in issue with cmake, python3, the project's CMakeLists, or something totally different?
For anyone interested in the koji builds:
rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=1215429
fc30: http://koji.fedoraproject.org/koji/buildinfo?buildID=1215430
fc29: http://koji.fedoraproject.org/koji/buildinfo?buildID=1215433
fc28: http://koji.fedoraproject.org/koji/buildinfo?buildID=1215434
5 years, 2 months
Koji Build Failure Due To Dependency EPEL Dependency Issue
by Chris
The error:
DEBUG util.py:490: BUILDSTDERR: Error:
DEBUG util.py:490: BUILDSTDERR: Problem: conflicting requests
DEBUG util.py:490: BUILDSTDERR: - nothing provides python2-oauthlib
needed by python2-requests-oauthlib-0.8.0-5.el7.noarch
DEBUG util.py:634: Child return code was: 1
This same package builds fine using copr (done so here):
https://copr.fedorainfracloud.org/coprs/lead2gold/apprise/
The spec file entry (that works fine for epel7 on Copr) is:
BuildRequires: python2-requests-oauthlib
BuildRequires: python2-oauthlib
This entry just produces an error that all requirements couldn't be met and
the scratch build aborts then too.
BuildRequires: python-oauthlib
It appears to be an upstream issue... a missing entry in the
python-oauthlib such as:
Provides: python2-oauthlib
I originally thought maybe i should be filing an issue with the oauthlib
group, but then if that were the case, it wouldn't have worked perfectly
fine on Copr.
Thoughts? Advice?
Chris
5 years, 2 months
HEADS UP: libgif update problems
by Sandro Mani
Hi
I've pushed what looked like a harmless update from libgif-5.1.4 to
libgif-5.1.6 to rawhide/f30, but apparently the dependency generator
didn't like it, since it now dropped the libgif.so provides from
libgif-devel (despite the file being there) and it generated a
libgif.so.7.1.0 provides instead of the previous libgif.so.7 for libgif.
I'm looking into it. If necessary, I'll rebuild affected packages.
Apologies for the inconvenience.
Sandro
5 years, 2 months