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
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’
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
GRIB and BUFR files.
It also enables building the package for aarch64 which was excluded up
to now.
As before I am not aware of any significant compatibility issues.
best regards,
Jos de Kloe
--
___
epel-devel mailing list -- epel-devel
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:
Dear all,
as pointed out in bz2236797 it would be useful for our users to upgrade
the eccodes package.
I am not aware of any significant compatibility issues, so if there are
no objections I plan to upgrade this package next week.
best regards,
Jos
On 9/1/23 16:20, bugzi...@redhat.com
n Mon, Jul 3, 2023 at 9:43 PM Jos de Kloe <mailto:josdek...@gmail.com>> wrote:
Hi Tomáš,
I have been looking at this one:
> python-metar jdekloe
and I think it needs to be fixed upstream before it can be build for
python3.12. Of course the faili
Hi Tomáš,
I have been looking at this one:
> python-metar jdekloe
and I think it needs to be fixed upstream before it can be build for
python3.12. Of course the failing tests can be disabled, but that may
just hide that the module is crippled.
So I opened this issue upstream:
0 / 2.26.0 to version 2.30.0.
I am not aware of any significant API/interface changes, and therefore
the so version will not change.
If there are any objections to updating this package please let me know.
Jos de Kloe
___
epel-devel mailing list --
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
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
version will not change.
If there are any objections to updating this package please let me know.
Jos de Kloe
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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
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
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
Hi Miro,
in general I think explicit is better than implicit
(and since I am Dutch, this seems obvious to me).
But regarding your question, I think a better argument for creating a
macro is to prevent mistakes from packagers. I think that is more
relevant than avoiding a few lines of code in
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
is
correct.
Jos de Kloe.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List
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
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
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:
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
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:
>>>
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
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
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
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:
>> old
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
.
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 try t
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
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
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:
>> ...
>>> It looks to
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 upgrade the way
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
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
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
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 <josdek...@gmail.com> wrote:
>>
>>> This package review: https://bugzilla.redhat.com/show_
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
nt of
> 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.fedo
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 josdek...@gmail.com
To: Development
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.
Regards
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 -
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
44 matches
Mail list logo
