Dne 03. 05. 23 v 14:38 Daniel P. Berrangé napsal(a):
given we're not doing license minimization any more, I'm curious
what package is going to win the prize for the longest license tag :-)
So far:
rpm-specs/perl-Exporter-Tidy.spec: 0BSD or AAL or AFL-3.0 or AGPL-3.0-only or APSL-2.0 or
I've submitted a test version of autogenerating mingw pkgconfig provides
and reqs here:
https://github.com/rpm-software-management/rpm/pull/2504
This generates provides like:
Provides: mingw32(libtiff-5.dll) mingw32(libtiffxx-5.dll)
mingw32-libtiff = 4.4.0-2.fc39 mingw32-pkgconfig(libtiff-4)
On Fri, May 5, 2023 at 11:14 AM Orion Poplawski wrote:
>
> I've submitted a test version of autogenerating mingw pkgconfig provides
> and reqs here:
>
> https://github.com/rpm-software-management/rpm/pull/2504
>
> This generates provides like:
>
> Provides: mingw32(libtiff-5.dll)
OLD: Fedora-Rawhide-20230504.n.0
NEW: Fedora-Rawhide-20230505.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 5
Dropped packages:0
Upgraded packages: 135
Downgraded packages: 0
Size of added packages: 3.75 MiB
Size of dropped packages:0 B
How fun! Thanks for the links and explanation.
On Fri, 5 May 2023 at 16:09, Miro Hrončok wrote:
> On 05. 05. 23 16:28, Mamoru TASAKA wrote:
> > Chris Kelley wrote on 2023/05/05 22:55:
> >> As a purely logical expression, this simplifies to "GPL-2.0-or-later AND
> >> LGPL-2.1-or-later". Is that
python-rpm-generators License tag changes from GPLv2+ to:
GPL-2.0-or-later AND LGPL-2.1-or-later AND (LicenseRef-Fedora-Public-Domain OR
LGPL-2.1-or-later OR GPL-2.0-or-later)
https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/67
Funny thing is that the
Chris Kelley wrote on 2023/05/05 22:55:
As a purely logical expression, this simplifies to "GPL-2.0-or-later AND
LGPL-2.1-or-later". Is that sort of simplification not allowed?
This is no longer allowed:
https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_license_analysis
On Fri, May 5, 2023 at 9:56 AM Chris Kelley wrote:
>
> As a purely logical expression, this simplifies to "GPL-2.0-or-later AND
> LGPL-2.1-or-later". Is that sort of simplification not allowed?
The short answer is, these are not truly logical expressions and
therefore they shouldn't necessarily
On Fri, May 05, 2023 at 09:41:01AM -0600, Orion Poplawski wrote:
> I'm trying to add mingw builds to the libssh package here:
>
> https://src.fedoraproject.org/rpms/libssh/pull-request/15
>
> build is failing with:
>
> Could not open %files file
>
On 5/5/23 09:45, Daniel P. Berrangé wrote:
On Fri, May 05, 2023 at 09:41:01AM -0600, Orion Poplawski wrote:
I'm trying to add mingw builds to the libssh package here:
https://src.fedoraproject.org/rpms/libssh/pull-request/15
build is failing with:
Could not open %files file
On 05. 05. 23 16:28, Mamoru TASAKA wrote:
Chris Kelley wrote on 2023/05/05 22:55:
As a purely logical expression, this simplifies to "GPL-2.0-or-later AND
LGPL-2.1-or-later". Is that sort of simplification not allowed?
This is no longer allowed:
On Fri, May 05, 2023 at 10:29:07AM -0600, Orion Poplawski wrote:
> On 5/5/23 09:45, Daniel P. Berrangé wrote:
> > On Fri, May 05, 2023 at 09:41:01AM -0600, Orion Poplawski wrote:
> > > I'm trying to add mingw builds to the libssh package here:
> > >
> > >
On Fri, May 05, 2023 at 12:15:31PM +0200, Miro Hrončok wrote:
> On 04. 05. 23 23:58, Kevin Fenzi wrote:
> > On Thu, May 04, 2023 at 11:44:33PM +0200, Miro Hrončok wrote:
> > > On 04. 05. 23 23:40, Kevin Fenzi wrote:
> > > > On Thu, May 04, 2023 at 04:03:49PM +0200, Miro Hrončok wrote:
> > > > >
As a purely logical expression, this simplifies to "GPL-2.0-or-later AND
LGPL-2.1-or-later". Is that sort of simplification not allowed?
On Fri, 5 May 2023, 13:20 Miro Hrončok, wrote:
> python-rpm-generators License tag changes from GPLv2+ to:
>
> GPL-2.0-or-later AND LGPL-2.1-or-later AND
>
On 06. 04. 23 21:51, Kevin Fenzi wrote:
On Thu, Apr 06, 2023 at 08:21:36AM +0200, Miro Hrončok wrote:
Hello,
When using custom side tags like this:
$ fedpkg request-side-tag
$ fedpkg chain-build --target f38-build-side-... ...
One of the obstacles is that the initial waitrepo for the
I'm trying to add mingw builds to the libssh package here:
https://src.fedoraproject.org/rpms/libssh/pull-request/15
build is failing with:
Could not open %files file
/home/orion/fedora/libssh/libssh-0.10.4/mingw32-debugfiles.list: No such
file or directory
What am I doing wrong?
--
This is a questionable representation though. The license in question is:
"Pick your favourite OSI approved license :)
http://www.opensource.org/licenses/alphabetical;
It might be more appropriate to have a license identifier that
consists of those two lines.
On Fri, May 5, 2023 at 11:09 AM
There is already an ancient similar request upstream with some hints how to
achieve that (it was to disable s390 buikders for noarch packages, though):
https://pagure.io/koji/issue/2229
Inviato da Proton Mail mobile
Messaggio originale
Il 5 Mag 2023, 18:19, Kevin Fenzi ha
On 05. 05. 23 17:09, Miroslav Suchý wrote:
Dne 03. 05. 23 v 14:38 Daniel P. Berrangé napsal(a):
given we're not doing license minimization any more, I'm curious
what package is going to win the prize for the longest license tag :-)
So far:
rpm-specs/perl-Exporter-Tidy.spec: 0BSD or
I'm just starting to look into the mingw packages and building mingw
executables with them - and in particular static building. I'm hoping
someone can clarify some things for me.
For "regular" libs we seem to have:
%{mingw32_bindir}/libexample-0.dll
%{mingw32_libdir}/libexample.dll.a
and
Did you find a co-maintainer for xfig? I use this package on and off and I
would not like to lose it.
On Tuesday, April 25, 2023 at 08:31:59 AM CDT, Hans de Goede
wrote:
Hi All,
I have been keeping the Fedora xfig package alive all these years
because I know that there are still
I am a co-maintainer (I think at least, I used to be co-) of PyPDF2 at least
for a while) or maintainer and I have noticed that the name has changed back to
pypdf (upstream). Is there an easy way to update the name of the package (in
the rpm) and importantly to make sure that the new pypdf rpm
On 5/5/23 21:31, Orion Poplawski wrote:
I'm just starting to look into the mingw packages and building mingw
executables with them - and in particular static building. I'm hoping
someone can clarify some things for me.
For "regular" libs we seem to have:
%{mingw32_bindir}/libexample-0.dll
> Now it uses SPDX identifiers, but lowercase ors, should probably be uppercase
> ORs.
Yea. I've been reading through the spec lately, since I want to add proper SPDX
support to my project,
and it says joiners should be uppercase and parsers should match
case-sensitively.
> License expression
On 5/5/23 10:30, Daniel P. Berrangé wrote:
On Fri, May 05, 2023 at 10:29:07AM -0600, Orion Poplawski wrote:
On 5/5/23 09:45, Daniel P. Berrangé wrote:
On Fri, May 05, 2023 at 09:41:01AM -0600, Orion Poplawski wrote:
I'm trying to add mingw builds to the libssh package here:
Josef Řídký wrote:
> Based on the SPDX requirements, that should be correct. Some parts of the
> package are available under GPL-2.0-only and some under GPL-3.0-only
> license.
And they are not linked together? Because if they are, we have a problem!
Kevin Kofler
Hey All,
I would like to invite all of you to participate in the Kernel 6.3
Test week is happening from 2023-05-07 to 2023-05-14. It's
fairly simple, head over to the wiki [0] and read in detail about the
test week and simply run the test case mentioned in[1] and enter your
results.
As usual,
On 04. 05. 23 23:58, Kevin Fenzi wrote:
On Thu, May 04, 2023 at 11:44:33PM +0200, Miro Hrončok wrote:
On 04. 05. 23 23:40, Kevin Fenzi wrote:
On Thu, May 04, 2023 at 04:03:49PM +0200, Miro Hrončok wrote:
Hello folks,
...snip...
Would that be possible?
I don't think it currently is... but
https://bugzilla.redhat.com/show_bug.cgi?id=2122556
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Resolution|---
https://bugzilla.redhat.com/show_bug.cgi?id=1933287
Fedora Update System changed:
What|Removed |Added
Resolution|--- |ERRATA
Status|ON_QA
On 27-04-2023 14:26, Sandro wrote:
Well, I submitted the package for review [2] and have been told that
vkbasalt not being published on PyPI is an issue wrt naming parity.
So, I filed a bug requesting publication on PyPI [3], but I haven't
heard back from upstream, yet. If upstream remains
The following Fedora EPEL 9 Security updates need testing:
Age URL
9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b31211e2ce
apptainer-1.1.8-1.el9
2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b59aa78f7e
vtk-9.1.0-18.el9
0
There is a new qt5 update in CentOS Stream 9. This update will be going
out when RHEL 9.3 is released six months from now. Again, that is RHEL
9.3, NOT 9.2.
I am currently rebuilding KDE for CentOS Stream 9. This will take some
time to rebuild and make it through testing. I am suspecting it
https://bugzilla.redhat.com/show_bug.cgi?id=2171943
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-SNMP-Info-3.92-1.fc39 |perl-SNMP-Info-3.92-1.fc39
On Thu, May 4, 2023 at 12:57 PM Marcin Dulak wrote:
> Hi,
>
> I have a bugzilla opened about a CenOS Stream package missing during EPEL9
> builds
> https://bugzilla.redhat.com/show_bug.cgi?id=2182460, for over a month
> with no response.
>
> Can something be done about this, apart from trying to
https://bugzilla.redhat.com/show_bug.cgi?id=1729976
Fedora Update System changed:
What|Removed |Added
Resolution|--- |ERRATA
Status|ON_QA
The following Fedora EPEL 8 Security updates need testing:
Age URL
49 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1e00c3d01e
cutter-re-2.2.0-1.el8 rizin-0.5.1-1.el8
9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-44ff2475c4
apptainer-1.1.8-1.el8
2
The following Fedora EPEL 7 Security updates need testing:
Age URL
9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-18a0e3fa23
apptainer-1.1.8-1.el7
5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-342b96903b
zarafa-7.1.14-6.el7
1
The following Fedora EPEL 8 Security updates need testing:
Age URL
50 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1e00c3d01e
cutter-re-2.2.0-1.el8 rizin-0.5.1-1.el8
10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-44ff2475c4
apptainer-1.1.8-1.el8
2
The following Fedora EPEL 9 Security updates need testing:
Age URL
10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b31211e2ce
apptainer-1.1.8-1.el9
3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b59aa78f7e
vtk-9.1.0-18.el9
1
The following Fedora EPEL 7 Security updates need testing:
Age URL
9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-18a0e3fa23
apptainer-1.1.8-1.el7
6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-342b96903b
zarafa-7.1.14-6.el7
2
The NVD analysis at
https://nvd.nist.gov/vuln/detail/CVE-2023-30549
is now finished and they agreed with the impact score that I gave it. They
ended up with an even higher rating because they said the attack complexity was
low. I think the complexity is high, but in either case the overall
https://bugzilla.redhat.com/show_bug.cgi?id=2189445
Denis Fateyev changed:
What|Removed |Added
Resolution|--- |RAWHIDE
Status|NEW
43 matches
Mail list logo
