f
> contact for that package do so in pkgdb.
>
> Thanks.
>
> kevin
> --
...
> python-metar (f21)
> python-metar (f22)
> python-metar (f23)
> python-metar (master)
I have taken the python-metar package (branches only).
Jos de Kloe.
--
devel mailing list
devel@lists
On 05/15/2014 05:01 PM, Till Maas wrote:
> Hi,
>
> fuse-encfs does not use proper encryption and upstream was not very
> active recently. Therefore I decided to orphan it on Fedora and EPEL. If
> someone is interested in fixing it, please take it. Otherwise it will be
> retired eventually.
>
> Re
k.
Clearly I am overlooking some dependency issue in my spec file.
Any help would be appreciated.
Best regards,
Jos de Kloe
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Robert, Bohuslav,
Thanks a lot!
I've been staring at this for a long time, but sometimes you just don't
notice your own silly mistakes...
Best regards,
Jos
On 07/03/2014 12:27 PM, Robert Kuska wrote:
>
>
> - Original Message -----
>> From: "Jos de Kloe&quo
This package review: https://bugzilla.redhat.com/show_bug.cgi?id=751749
has been stalled for several years now since the original submitter
(Karel Klíč) never got back to it, even though the review was approved.
Since it is not packaged yet, the nonresponsive package maintainers
policy does not ap
On 12/08/2015 01:25 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Dec 07, 2015 at 10:07:53PM +0100, Piotr Popieluch wrote:
>> On Mon, Dec 7, 2015 at 9:40 PM, Jos de Kloe wrote:
>>
>>> This package review: https://bugzilla.redhat.com/show_bug.cgi?id=751749
>>> h
Hi everyone,
my name is Jos de Kloe, I am working for the Dutch Met. Office (KNMI) as
a scientist and doing a lot of programming work, mainly in python and
fortran.
For this reason I am interested in adding some python modules to Fedora
that can handle some fileformats commonly used in
On 03/04/2013 11:16 AM, Peter Lemenkov wrote:
Hello All!
I've got few review requests which got stuck for a while, and I'd love
to trading reviews with anyone.
* https://bugzilla.redhat.com/906473 - erlang-ranch - Socket acceptor
pool for TCP protocols
* https://bugzilla.redhat.com/906481 - erla
You did not menthon what copy of VirtualBox you used, and that makes a
difference.
I have been running the copy from rpmfusion for some time, and
experienced the same trouble you had. It often breaks after
updates/upgrades, forcing me to use old kernel copies.
In the end I decided to fall back to
something strange happened in my recent pyproj build on rawhide which
causes all relevant requires to be lost, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1467366
I tried to find a solution or workaround, but without succes.
When I do a local mock build the same problem arises.
I tried t
Hi Björn,
On 07/06/2017 12:22 PM, Björn 'besser82' Esser wrote:
> Am 06.07.2017 um 12:03 schrieb Jos de Kloe:
...
> It looks to me like you are using the old and discouraged / deprecated
> `%filter_setup` macro stuff, valid for EPEL <= 6, only…
>
> You should upgra
On 07/06/2017 01:53 PM, Björn 'besser82' Esser wrote:
> Am 06.07.2017 um 13:09 schrieb Jos de Kloe:
>> Hi Björn,
>>
>> On 07/06/2017 12:22 PM, Björn 'besser82' Esser wrote:
>>> Am 06.07.2017 um 12:03 schrieb Jos de Kloe:
>> ...
>&
OK, I'll take the epel branches for this package as well.
Jos.
On 05/02/2016 12:00 PM, nob...@fedoraproject.org wrote:
> Change in package status over the last 168 hours
>
>
> 32 packages were orphaned
> -
> pyproj [el
Something seems wrong in: https://apps.fedoraproject.org/packages/pyproj
The header text and upstream point to pyproject-rpm-macros in stead of
pyproj.
Does anybody know how to fix this?
Jos
___
devel mailing list -- devel@lists.fedoraproject.org
To u
Hi,
this seems to indicate that there is an incompatibility in how numpy
calls cython macros.
On 8/22/19 12:38 AM, Ankur Sinha wrote:
> error: macro "__Pyx_PyCode_New" requires 16 arguments, but only 15 given
Actually, there already is a bug report on cython here:
https://github.com/cython/cyth
Hi,
I hope someone is interested to swap reviews?
I would like to package the python3 bindings to the eccodes package that
I maintain, which has been split to a separate repository by upstream.
See my review request here:
https://bugzilla.redhat.com/show_bug.cgi?id=1808878
Thanks,
Jos de
For your information:
the python-metar package has changed license from MIT to BSD,
starting with release 1.7.0.
see:
https://github.com/python-metar/python-metar/releases
https://src.fedoraproject.org/rpms/python-metar
best regards,
Jos de Kloe
There used to be a unison240 package, but it was orphaned over 2 years ago.
See: https://src.fedoraproject.org/rpms/unison240
On 4/22/23 09:59, Richard W.M. Jones wrote:
On Fri, Apr 21, 2023 at 03:52:42PM -0600, Craig Christianson wrote:
Hello,
Unison is a tool I use all the time, and I would
Thanks Orion, I'll take these.
Sorry for the delay, but I could not commit earlier due to lack of time.
I don't need any review on my side so that's no problem.
Jos
On 9/25/23 21:17, Orion Poplawski wrote:
Could someone (perhaps someone interested in X2Go) please review:
https://bugzilla.redh
I get the following output:
--
sudo dnf --releasever=40 --setopt=module_platform_id=platform:f40
--enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null &&
echo
--enablerepo=updates-testing-modular) --assumeno distro-sync
bash: --enablerepo=updates-testing-modular: command
Dear all,
while doing koji builds for the latest eccodes version 2.34.1 I ran in
to an issue that is puzzling to me, and I have no idea to solve this.
The build runs just fine for f38, f39 and f41/rawhide, but for f40 I get
a number of g++ errors like this:
error: ‘opj_destroy_decompress’
Thanks a lot for these replies!
Jos
On 2/29/24 12:01, Sérgio Basto wrote:
On Thu, 2024-02-29 at 19:19 +0900, Mamoru TASAKA wrote:
Petr Pisar wrote on 2024/02/29 18:35:
V Thu, Feb 29, 2024 at 10:02:32AM +0100, Jos de Kloe napsal(a):
Dear all,
while doing koji builds for the latest eccodes
fixed g2clib and pyproj.
Jos
On 02/18/2018 06:09 PM, Igor Gnatenko wrote:
> Over this weekend I've performed scratch-mass-rebuild without having gcc and
> gcc-c++ in buildroot of all Fedora packages, many of which failed due to
> random
> reasons and I grepped all logs for some common errors fou
I have a question about an open review request on the eccodes package,
see: https://bugzilla.redhat.com/show_bug.cgi?id=1508950
Eccodes will replace grib_api for which downstream will stop support at
the end of this year.
Therefore the first draft spec file had Obsoletes/Provides entries to
make c
Thanks for your advice.
I updated the spec file accordingly and published a new version in the
review request.
On 03/09/2018 12:15 AM, Fernando Nasser wrote:
> On 2018-03-08 5:58 AM, Daniel P. Berrangé wrote:
>> On Thu, Mar 08, 2018 at 11:23:45AM +0100, Jos de Kloe wrote:
>>>
Thanks a lot for taking care of pyproj.
Jos
On 11/13/20 10:47 AM, Sandro Mani wrote:
On 05.11.20 20:27, Sandro Mani wrote:
On 05.11.20 12:36, Tom Hughes wrote:
On 05/11/2020 11:24, Sandro Mani wrote:
I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide
shortly. I'll do a round
ORTRAN programs ( epel7 el6 )
Jos de Kloe
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Hi,
I'm trying to do a build for the python-metar package (first time since
I adapted it after it was orphaned), but I constantly get this error
when I try to do a fedpkg build:
FAILED: BuildError: package metar not in list for tag f27-pending
does anyone know what is wrong, and how to solve it?
.
On 07/30/2017 09:52 PM, Kevin Fenzi wrote:
> On 07/29/2017 08:25 AM, Jos de Kloe wrote:
>> Hi,
>>
>> I'm trying to do a build for the python-metar package (first time since
>> I adapted it after it was orphaned), but I constantly get this error
>> when I
Hi,
I just build a new version of g2clib (upgraded from 1.4.0 to 1.6.0), and
with this change this static library for grib file handling changes name:
old: libgrib2c.a
new: libg2c_v1.6.0.a
I dont know of a packaging guideline that tells me to announce this, but
to prevent surprises for dependent
/2017 10:23 PM, Michael Schwendt wrote:
> On Tue, 15 Aug 2017 22:13:00 +0200, Jos de Kloe wrote:
>
>> Hi,
>>
>> I just build a new version of g2clib (upgraded from 1.4.0 to 1.6.0), and
>> with this change this static library for grib file handling changes name:
>>
this change.
On 08/17/2017 09:11 PM, Volker Fröhlich wrote:
> Am 2017-08-17 um 09:45 schrieb Jos de Kloe:
>> Hi, thanks for your remark.
>>
>> I am aware of one single other package that uses this lib, for which I
>> am the maintainer myself.
>>
>> The upda
Hi,
eccodes will need to be adapted upstream. I filed an issue there and
they will try to fix this a.s.a.p. Untill then, if needed, I could
remove use of libjasper since it is an optional feature.
grib_api is no longer maintained upstream, so not much can be done there.
Jos.
On 2/13/22 21:5
I took xload since I actually like its simplicity and use it quite often.
Jos.
On 4/22/21 11:14 AM, Miro Hrončok wrote:
On 22. 04. 21 4:03, Peter Hutterer wrote:
Now that the XorgUtilityDeaggregation [1] is complete, I'm planning to
retire a set of old X utilities that I think don't need to be
I am seeing this error when trying to build locally using mock:
Error:
Problem: package python3-xarray-0.17.0-1.fc35.noarch requires
python(abi) = 3.9, but none of the providers can be installed
- package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with
python3 < 3.10.0~b2-3.fc35 provide
Dear all,
I have orphaned the grib_api package for Fedora (which is now also FTBFS
since the F42 mass rebuild), both due to lack of time and since grib_api
has now been unmaintained upstream for over 6 years. It is replaced by
eccodes for those architectures that supports it.
Upstream writes
Hi Karolina,
thanks for this hint.
I 'll see if I can fix this then by adding this to the spec file.
Cheers,
Jos
On 7/29/25 1:50 PM, Karolina Surma wrote:
On 7/29/25 13:33, Jos de Kloe wrote:
As these symlinks have been generated by an earlier install of the
same package, an upgrade s
As these symlinks have been generated by an earlier install of the same
package, an upgrade should be able to replace them I think.
So this seems an rpm bug to me.
Is there anything I can do as eccodes packager to fix this?
Jos
On 7/29/25 12:13 PM, Michael Schwendt wrote:
On Mon, 28 Jul 2025
Hi Orion,
I just built eccodes version 2.42.0-3 which should solve this issue.
I did this by reverting the upstream change, and replaced the symbolic
links with a copy of their target.
Downside of this is that the data package will increase in size, and
that I will have to maintain this patc
=2384303
Any hints how to proceed would be appreciated.
Jos
On 7/29/25 1:50 PM, Karolina Surma wrote:
On 7/29/25 13:33, Jos de Kloe wrote:
As these symlinks have been generated by an earlier install of the
same package, an upgrade should be able to replace them I think.
So this seems an rpm bug to
Sales de Andrade wrote:
On Tue, Jul 29, 2025 at 4:16 PM Jos de Kloe wrote:
Hi,
as suggested on this Directory_Replacement page I tried to solve this
problem by adding a little lua scriptlet.
Unfortunately it seems not to work for me so I must be missing some
details here.
You aren't mi
41 matches
Mail list logo
