from:"Denis Fateyev"

RPM build: unpackaged file .pyi

2022-03-24 Thread Denis Fateyev

Hello there,

After bumping upstream version in "python-apsw", I have noticed that a new
Python .pyi file was created in the new version, so the package build
process started to fail:

error: Installed (but unpackaged) file(s) found:
   /usr/apsw.pyi

https://kojipkgs.fedoraproject.org//work/tasks/5755/84615755/build.log

I haven't found related details in
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
Could you suggest, should I skip and remove .pyi files during RPM packaging?

Thanks!

-- 
wbr, Denis.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Orphaning ustl package

2022-03-23 Thread Denis Fateyev

Hello,

I'm going to orphan "ustl" package for several reasons:
 - the library is generally deprecated;
 - the maintainer has switched the C++ library type to static, which makes
shared lib support no longer possible.

It should be harmless since there are no packages that depend on "ustl".

$ dnf repoquery --whatdepends ustl
ustl-devel-0:2.8-9.fc37.i686
ustl-devel-0:2.8-9.fc37.x86_64

$ dnf repoquery -q --repo=rawhide{,-source} --whatrequires ustl
ustl-devel-0:2.8-9.fc37.i686
ustl-devel-0:2.8-9.fc37.x86_64

-- 
wbr, Denis.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Orphaning ustl package

2022-03-23 Thread Denis Fateyev

Hello,

I'm going to orphan "ustl" package for several reasons:
 - the library is generally deprecated;
 - the maintainer has switched the C++ library type to static, which makes
shared lib support no longer possible.

It should be harmless since there are no packages that depend on "ustl".

$ dnf repoquery --whatdepends ustl
ustl-devel-0:2.8-9.fc37.i686
ustl-devel-0:2.8-9.fc37.x86_64

$ dnf repoquery -q --repo=rawhide{,-source} --whatrequires ustl
ustl-devel-0:2.8-9.fc37.i686
ustl-devel-0:2.8-9.fc37.x86_64

-- 
wbr, Denis.
___
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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Rpm: provide a static library in package

2022-02-22 Thread Denis Fateyev

On Wed, Feb 23, 2022 at 6:47 AM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Denis Fateyev wrote:
> > The "ustl" upstream, for which I maintain the RPM package, has recently
> > switched from providing a shared library to a static library.
>
> Generally, you do not want to follow such a change, but force the build
> system to build a shared library instead, even if it is not the upstream
> default.
>

Unfortunately, the shared library support is explicitly removed by the
upstream:
https://github.com/msharov/ustl/issues/100#issuecomment-1040553883
https://github.com/msharov/ustl/commit/7366ab143d9bd0f48c59931c0c58529eb5179c27

I believe it's not worth to work around this behavior additionally.

As an alternative, I can orphan the "ustl" package in rawhide — I haven't
checked yet, but suspect that it's not used by other packages nowadays.

-- 
wbr, Denis.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Rpm: provide a static library in package

2022-02-22 Thread Denis Fateyev

Hello all,

The "ustl" upstream, for which I maintain the RPM package, has recently
switched from providing a shared library to a static library.

So I'm going to make changes in the package, and provide everything in
"-devel" subpackage.
I have looked through
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries
requirements — but there are some questions left.

1) Should I preserve debug information for the static library during build,
so the library can be stripped and debug packages can be created? Or, can I
just skip  debug package creation with  "%global debug_package %{nil}" ?
I know it's acceptable for header-only, but not sure for packages with
binary static libraries.

2) Can I use the stripping LDFLAGS option ("-s") right during the static
package build, not to strip anything after build? Or, let the built library
be stripped in terms of RPM package flow?

Thanks!

-- 
wbr, Denis.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: GCC changes break "libscrypt" package in F36

2022-02-09 Thread Denis Fateyev

Thank you, all variants work fine.

Now I have another issue with "nfdump" package, probably for the same
reason: a build flag interference.

I use '-fPIC' in LDFLAGS to make "configure" happy:
https://src.fedoraproject.org/rpms/nfdump/blob/rawhide/f/nfdump.spec#_49

I suspect that this flag presence affects the package build, or maybe it's
related to other changes.
It worked for F35 and earlier, and still works with simple "./configure &&
make" (without RPM build flags).

...
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -ggdb -g -O3 -std=gnu11
-Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wmissing-noreturn -fno-strict-aliasing -DNSEL -c ipconv.c  -fPIC -DPIC -o
.libs/ipconv.o
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..
   -ggdb  -g -O3 -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing -DNSEL -c -o
exporter.lo exporter.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -ggdb -g -O3 -std=gnu11
-Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wmissing-noreturn -fno-strict-aliasing -DNSEL -c exporter.c  -fPIC -DPIC
-o .libs/exporter.o
/bin/sh ../libtool  --tag=CC   --mode=link gcc -ggdb  -g -O3 -std=gnu11
-Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wmissing-noreturn -fno-strict-aliasing -DNSEL -release 1.6.23 -Wl,-z,relro
-Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1
-Wl,-dT,/home/mock/rpmbuild/BUILD/nfdump-1.6.23/.package_note-nfdump-1.6.23-3.fc36.x86_64.ld
-fPIC -o libnfdump.la -rpath /usr/lib64 output_util.lo output_raw.lo
output_json.lo output_csv.lo output_pipe.lo output_fmt.lo util.lo
minilzo.lo lz4.lo nffile.lo nfx.lo flist.lo fts_compat.lo grammar.lo
scanner.lo nftree.lo ipconv.lo exporter.lo  -lresolv -lbz2
libtool: link: gcc -shared  -fPIC -DPIC  .libs/output_util.o
.libs/output_raw.o .libs/output_json.o .libs/output_csv.o
.libs/output_pipe.o .libs/output_fmt.o .libs/util.o .libs/minilzo.o
.libs/lz4.o .libs/nffile.o .libs/nfx.o .libs/flist.o .libs/fts_compat.o
.libs/grammar.o .libs/scanner.o .libs/nftree.o .libs/ipconv.o
.libs/exporter.o   -lresolv -lbz2 -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -ggdb -g -O3 -Wl,-z -Wl,relro
-Wl,--as-needed -Wl,-z -Wl,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT
-Wl,/home/mock/rpmbuild/BUILD/nfdump-1.6.23/.package_note-nfdump-1.6.23-3.fc36.x86_64.ld
  -Wl,-soname -Wl,libnfdump-1.6.23.so -o .libs/libnfdump-1.6.23.so
libtool: link: (cd ".libs" && rm -f "libnfdump.so" && ln -s "
libnfdump-1.6.23.so" "libnfdump.so")
libtool: link: ( cd ".libs" && rm -f "libnfdump.la" && ln -s "../
libnfdump.la" "libnfdump.la" )
/bin/sh ../libtool  --tag=CC   --mode=link gcc -DPCAP -g -O3 -std=gnu11
-Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wmissing-noreturn -fno-strict-aliasing -DNSEL  -Wl,-z,relro
-Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1
-Wl,-dT,/home/mock/rpmbuild/BUILD/nfdump-1.6.23/.package_note-nfdump-1.6.23-3.fc36.x86_64.ld
-fPIC -o nfcapd nfcapd-nfcapd.o nfcapd-nfstatfile.o nfcapd-launch.o
nfcapd-nfnet.o nfcapd-collector.o nfcapd-netflow_v1.o
nfcapd-netflow_v5_v7.o nfcapd-netflow_v9.o nfcapd-ipfix.o
nfcapd-bookkeeper.o nfcapd-expire.o nfcapd-pcap_reader.o libnfdump.la
-lpcap  -lresolv -lbz2
libtool: link: gcc -DPCAP -g -O3 -std=gnu11 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn
-fno-strict-aliasing -DNSEL -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT
-Wl,/home/mock/rpmbuild/BUILD/nfdump-1.6.23/.package_note-nfdump-1.6.23-3.fc36.x86_64.ld
-fPIC -o .libs/nfcapd nfcapd-nfcapd.o nfcapd-nfstatfile.o nfcapd-launch.o
nfcapd-nfnet.o nfcapd-collector.o nfcapd-netflow_v1.o
nfcapd-netflow_v5_v7.o nfcapd-netflow_v9.o nfcapd-ipfix.o
nfcapd-bookkeeper.o nfcapd-expire.o nfcapd-pcap_reader.o
 ./.libs/libnfdump.so -lpcap -lresolv -lbz2
/usr/bin/ld: nfcapd-nfcapd.o: relocation R_X86_64_32 against
`.rodata.str1.8' can not be used when making a PIE object; recompile with
-fPIE
/usr/bin/ld: nfcapd-nfstatfile.o: relocation R_X86_64_32 against
`.rodata.str1.1' can not be used when making a PIE object; recompile with
-fPIE
/usr/bin/ld: nfcapd-launch.o: relocation R_X86_64_32S against `.rodata' can
not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: nfcapd-nfnet.o: relocation R_X86_64_32 against
`.rodata.str1.8' can not be used when making a PIE object; recompile with
-fPIE
/usr/bin/ld: nfcapd-collector.o: relocation R_X86_64_32 against
`.rodata.str1.1' can not be used when making a PIE object; recompile with
-fPIE
/usr/bin/ld:

GCC changes break "libscrypt" package in F36

2022-02-08 Thread Denis Fateyev

Hello all,

Recently, I have found that with GCC version bump in F36 some of my
packages are stopped to build, or stopped to build properly during the
planned package rebuild.
They were fine under F35 — but apparently there are some changes in newer
GCC that affected them.

For example,  "libscrypt" package issue is filled here:
https://bugzilla.redhat.com/show_bug.cgi?id=2046062
The library in the package was actually built, but the build results are
different under various GCC versions — as shown in the "nm" dump below.

Has anybody already faced a similar issue? Is there any information on what
could cause the problem, and how to fix it?

Thanks!

[Fedora35]$ nm -D libscrypt.so.0
 U close@GLIBC_2.2.5
 U __ctype_b_loc@GLIBC_2.3
 w __cxa_finalize@GLIBC_2.2.5
 U __errno_location@GLIBC_2.2.5
 U free@GLIBC_2.2.5
 w __gmon_start__
 w _ITM_deregisterTMCloneTable
 w _ITM_registerTMCloneTable
 A libscrypt
4520 T libscrypt_check@@libscrypt
46f0 T libscrypt_hash@@libscrypt
3d80 T libscrypt_mcf@@libscrypt
4430 T libscrypt_salt_gen@@libscrypt
1600 T libscrypt_scrypt@@libscrypt
 U malloc@GLIBC_2.2.5
 U memcpy@GLIBC_2.14
 U mmap@GLIBC_2.2.5
 U munmap@GLIBC_2.2.5
 U open@GLIBC_2.2.5
 U read@GLIBC_2.2.5
 U __snprintf_chk@GLIBC_2.3.4
 U __stack_chk_fail@GLIBC_2.4
 U strchr@GLIBC_2.2.5
 U strlen@GLIBC_2.2.5
 U strtok_r@GLIBC_2.2.5
 U strtoul@GLIBC_2.2.5

[Fedora36]$ nm -D libscrypt.so.0
 U close@GLIBC_2.2.5
 U __ctype_b_loc@GLIBC_2.3
 w __cxa_finalize@GLIBC_2.2.5
 U __errno_location@GLIBC_2.2.5
 U free@GLIBC_2.2.5
 w __gmon_start__
 w _ITM_deregisterTMCloneTable
 w _ITM_registerTMCloneTable
43e0 T libscrypt_b64_decode
4240 T libscrypt_b64_encode
4950 T libscrypt_check
47c0 T libscrypt_hash
3880 T libscrypt_HMAC_SHA256_Final
3620 T libscrypt_HMAC_SHA256_Init
3870 T libscrypt_HMAC_SHA256_Update
4170 T libscrypt_mcf
38f0 T libscrypt_PBKDF2_SHA256
4690 T libscrypt_salt_gen
3c90 T libscrypt_scrypt
34d0 T libscrypt_SHA256_Final
3290 T libscrypt_SHA256_Init
32c0 T libscrypt_SHA256_Update
 U malloc@GLIBC_2.2.5
 U memcpy@GLIBC_2.14
 U mmap@GLIBC_2.2.5
 U munmap@GLIBC_2.2.5
 U open@GLIBC_2.2.5
 U read@GLIBC_2.2.5
48f0 T slow_equals
 U __snprintf_chk@GLIBC_2.3.4
 U __stack_chk_fail@GLIBC_2.4
 U strchr@GLIBC_2.2.5
 U strlen@GLIBC_2.2.5
 U strtok_r@GLIBC_2.2.5
 U strtoul@GLIBC_2.2.5


-- 
wbr, Denis.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

spdrs60: package review swap

2021-10-16 Thread Denis Fateyev

Hello all,

I have a new package request:
https://bugzilla.redhat.com/show_bug.cgi?id=2011964 , which needs to be
reviewed.
If anyone is interested in a review swap — feel free to take it, and I can
review another package in return.

Thanks!

-- 
wbr, Denis.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Test-mysqld] PR #1: Use the correct name of the required package

2020-03-02 Thread Denis Fateyev


dfateyev merged a pull-request against the project: `perl-Test-mysqld` that you 
are following.

Merged pull-request:

``
Use the correct name of the required package
``

https://src.fedoraproject.org/rpms/perl-Test-mysqld/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: perl-CryptX package

2016-04-25 Thread Denis Fateyev

Hello Paul,

On Mon, Apr 25, 2016 at 4:45 PM, Paul Howarth <p...@city-fan.org> wrote:

> Hi Dennis,
>
> On 22/11/15 15:28, Denis Fateyev wrote:
>
>> On Sun, Nov 22, 2015 at 5:20 PM, Paul Howarth <p...@city-fan.org> wrote:
>>
>>
>>> As a data point of interest, I unbundled libtomcrypt from python-crypto
>>> when it became possible:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1087557
>>>
>>> Paul.
>>>
>>>
>> Thanks for the answer. Under these circumstances I should consider to
>> unbundle it too.
>>
>> By the way, the last official "libtomcrypt" release happened more than 5
>> years ago. There was no new official release since that and it's a bit of
>> problem due a lot of historical code and changes were made after that
>> (hundreds of commits). I'll try to contact libtom people on Github, maybe
>> they will bother to prepare a new release.
>>
>
> Did you make any progress with the perl-CryptX packaging? It has now
> become a dependency of perl-Net-SSH-Perl, so I'd like to see it in Fedora.
>

Not really, since I had to unbundle "libtomcrypt" and "libtommath" first as
mentioned above, and it takes some time which I don't have right now.

CryptX won't go well with the "libtomcrypt" packaged in Fedora, since the
packaged version is too aged.
Before updating "libtomcrypt" we also have to update "libtommath" [1] and
"tomsfastmath" [2].

The "libtommath" update has been tested for Fedora pretty well [3] and can
be updated easily, but as for other two more work on preparing new
versions, testing and packaging is required.
Considering all of this, the "proper" unbundled CryptX version cannot be
prepared right now, although we can solve dependencies step by step.

As for the plans, next month I'm going to start testing "tomsfastmath" in
order to help with preparing a new release. After that, the same way with
"libtomcrypt", and then CryptX.
I talked to Karel, the CryptX's author, and we agreed that a configure
switch which allows to use "libtomcrypt" system library would be useful, so
in perspective the unbundling process should be even less problematic.

Thanks,

[1] https://github.com/libtom/libtommath

[2] https://github.com/libtom/tomsfastmath

[3] https://github.com/libtom/libtommath/issues/35

-- 
wbr, Denis.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

The current situation with POE packages

2016-03-19 Thread Denis Fateyev

Hello there,

Just a friendly note if anybody interested but just missed it occasionally:
the whole POE stack is now orphaned in Fedora devel.

https://admin.fedoraproject.org/pkgdb/package/rpms/perl-POE/

I really dislike the idea that this great thing would be gone from Fedora
forever, I use it sometimes and pretty happy with it. But I personally have
no time to pick it up and support it, I do hope that somebody else who's
using it will take it to maintain it further.

-- 
wbr, Denis.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: packages seeking new point of contact

2016-03-04 Thread Denis Fateyev

Hello there,

I've taken python-llfuse (ass requested earlier) and python-apsw.

-- 
wbr, Denis.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Nonresponsive maintainer: maci

2016-02-23 Thread Denis Fateyev

Hello there,

Does anybody know how to contact Marcel Wysocki ("m...@satgnu.net", FAS
login: maci)?

While ago, according the policy I've initiated nonresponsive maintainer
procedure https://bugzilla.redhat.com/show_bug.cgi?id=1304786 , since there
is no contact with main contact for Fedora branches, and no `python-llfuse`
updates for a long time.

I got one answer in the ticket above but there were no further actions
(neither update, nor confirming acls requested). I also wrote him by email
several times, but never got any answer.

-- 
wbr, Denis.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] [HEADS UP]: libtommath major version pre-release testing

2016-01-22 Thread Denis Fateyev

Greetings,

We are preparing a major update for 'libtommath' library [1]. The last
stable release happened more than 5 years ago, so there are a lot of
changes and improvements over the time.

Although there are still some open requests in upstream, the current
library state looks pretty stable to me. Along with multiple enhancements
the core contributors removed a lot of deprecated stuff from the code, and
we cleaned up makefiles and the Fedora package spec to bring more logic in
there.

All 'libtommath' shared library and bundled version users are encouraged to
test their code and/or packages against the current development version of
the library.

There is a Copr repo with packages for the development version [2].
Any feedback and suggestions are very welcome.

Known issues:
-
1) Build permanently fails for epel7 ppc64le. It's a bug in 'ghostscript'
[3], and there was even a workaround in epel7 branch [4];

2) Build appeared to be failing in rawhide, I suspect there is broken
'texlive'.

Both problems can be avoided with excluding pdf docs from the package, and
I do hope that 'texlive' will be fixed in rawhide soon (I haven't checked
the problem in details though).

[1] https://github.com/libtom/libtommath

[2] https://copr.fedorainfracloud.org/coprs/dfateyev/libtommath/

[3] https://bugzilla.redhat.com/show_bug.cgi?id=1243784

[4]
http://pkgs.fedoraproject.org/cgit/rpms/libtommath.git/commit/?h=epel7=7c9593329f1f5e341513a9c58653347471d5c803

Thanks,

--
wbr, Denis.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[HEADS UP]: libtommath major version pre-release testing

2016-01-22 Thread Denis Fateyev

Greetings,

We are preparing a major update for 'libtommath' library [1]. The last
stable release happened more than 5 years ago, so there are a lot of
changes and improvements over the time.

All 'libtommath' shared library and bundled version users are encouraged to
test their code and/or packages against the current development version of
the library.

There is a Copr repo with packages for the development version [2].
Any feedback and suggestions are very welcome.

Known issues:
-
1) Build permanently fails for epel7 ppc64le. It's a bug in 'ghostscript'
[3], and there was even a workaround in epel7 branch [4];

2) Build appeared to be failing in rawhide, I suspect there is broken
'texlive'.

Both problems can be avoided with excluding pdf docs from the package, and
I do hope that 'texlive' will be fixed in rawhide soon (I haven't checked
the problem in details though).

[1] https://github.com/libtom/libtommath

[2] https://copr.fedorainfracloud.org/coprs/dfateyev/libtommath/

[3] https://bugzilla.redhat.com/show_bug.cgi?id=1243784

[4]
http://pkgs.fedoraproject.org/cgit/rpms/libtommath.git/commit/?h=epel7=7c9593329f1f5e341513a9c58653347471d5c803

Thanks,

--
wbr, Denis.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

libwhirlpool (a Whirlpool algorithm implementation)

2016-01-17 Thread Denis Fateyev

Hello list,

A while ago, I've created a Whirlpool hash function library [1] based on
the original implementation of Whirlpool algorithm by Vincent Rijmen and
Paulo S. L. M. Barreto.

It's packaged as 'libwhirlpool' in Fedora and EPEL [2].
Also provides 'whirlpoolsum' utility to calculate and check Whirlpool
hashes with the interface similar to 'md5sum', 'shaXXXsum' from coreutils.

Feel free to use and leave any suggestions or feedback.

[1] https://github.com/dfateyev/libwhirlpool

[2] https://admin.fedoraproject.org/pkgdb/package/rpms/libwhirlpool/

-- 
wbr, Denis.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: Which python3 versions to package for EPEL7?

2016-01-06 Thread Denis Fateyev

On Thu, Jan 7, 2016 at 12:24 AM, Orion Poplawski 
wrote:

> On 01/06/2016 10:51 AM, Kevin Fenzi wrote:
>
> > Also, now that 35 is out, do we want to switch epel7 to python35 before
> > we go building out things much more?
> >
> > kevin
>
> Actually, I think it would be nice to test out the dual nature by adding
> 35 as
> the "other" version for now.

Introducing python34 stuff for epel7 is already a big step forward.
So I personally agree, there is no necessity to force with python35 - it
can be checked as "other" first, as proposed.

-- 
wbr, Denis.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: Additional python34 components for epel7

2016-01-04 Thread Denis Fateyev

On Thu, Dec 31, 2015 at 12:22 AM, Orion Poplawski <or...@cora.nwra.com>
wrote:

> On 12/30/2015 10:00 AM, Orion Poplawski wrote:
> > On 12/30/2015 12:16 AM, Denis Fateyev wrote:
> >> Actually, I've opened a bug against 'msgpack':
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1290393
> ...
> >
> > Some reviews are underway here:
> >
> >
> https://bugzilla.redhat.com/showdependencytree.cgi?id=1294704_resolved=1

If we just could work "the same SRPMS name" problem around ;-)
Healthy repos with the master branch orphaned [1] may look a little weird
to users...

Just think, maybe worth to include some info that "this package for epel
only" into package description, additionally?

[1] https://admin.fedoraproject.org/pkgdb/package/rpms/python3-setuptools/

-- 
wbr, Denis.
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

[EPEL-devel] Re: Additional python34 components for epel7

2016-01-04 Thread Denis Fateyev

On Thu, Dec 31, 2015 at 12:22 AM, Orion Poplawski <or...@cora.nwra.com>
wrote:

> On 12/30/2015 10:00 AM, Orion Poplawski wrote:
> > On 12/30/2015 12:16 AM, Denis Fateyev wrote:
> >> Actually, I've opened a bug against 'msgpack':
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1290393
> ...
> >
> > Some reviews are underway here:
> >
> >
> https://bugzilla.redhat.com/showdependencytree.cgi?id=1294704_resolved=1

If we just could work "the same SRPMS name" problem around ;-)
Healthy repos with the master branch orphaned [1] may look a little weird
to users...

Just think, maybe worth to include some info that "this package for epel
only" into package description, additionally?

[1] https://admin.fedoraproject.org/pkgdb/package/rpms/python3-setuptools/

-- 
wbr, Denis.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: perl-CryptX package

2015-11-22 Thread Denis Fateyev

On Sun, Nov 22, 2015 at 5:20 PM, Paul Howarth  wrote:

>
> As a data point of interest, I unbundled libtomcrypt from python-crypto
> when it became possible:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1087557
>
> Paul.
>

Thanks for the answer. Under these circumstances I should consider to
unbundle it too.

By the way, the last official "libtomcrypt" release happened more than 5
years ago. There was no new official release since that and it's a bit of
problem due a lot of historical code and changes were made after that
(hundreds of commits). I'll try to contact libtom people on Github, maybe
they will bother to prepare a new release.

-- 
wbr, Denis.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

perl-CryptX package

2015-11-20 Thread Denis Fateyev

Hello there,

I'm going to package CryptX Perl module [1] soon.

The only concern is that it contains a lot of XS-based code of ciphers and
hashes that can be probably considered as bundled. Mostly the used
routines, including sha1, sha2 and md5 implementations, are based on
LibTomCrypt library [2, 3].

Neither this library components nor all algo related are mentioned in
Bundled library policies [4]. So the question is: should we threat this
very case as bundled libs presence? Are there any objections against this
module to be packaged "as is", in its current state?

Thanks,

[1] https://metacpan.org/pod/CryptX

[2] http://www.libtom.net

[3] https://github.com/libtom/libtomcrypt

[4]
https://fedoraproject.org/w/index.php?title=Packaging:No_Bundled_Libraries=406058

-- 
wbr, Denis.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Fwd: hotness tried to map perl-Class-Virtual to an upstream project, but failed due to ambiguity. 5682 other projects share the same homepage

2015-02-27 Thread Denis Fateyev

Hello there,

Recently, I've got several such messages for each of new submitted packages.
Is there something wrong with the upstream monitoring for Perl modules?

Thanks.

-- Forwarded message --
From: notificati...@fedoraproject.org
Date: Fri, Feb 27, 2015 at 11:59 PM
Subject: hotness tried to map perl-Class-Virtual to an upstream project,
but failed due to ambiguity. 5682 other projects share the same homepage

hotness tried to map perl-Class-Virtual to an upstream project, but failed
due to ambiguity.  5682 other projects share the same homepage
https://bugzilla.redhat.com/1195862
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File Devel-Timer-0.06.tar.gz uploaded to lookaside cache by dfateyev

2014-11-09 Thread Denis Fateyev

A file has been added to the lookaside cache for perl-Devel-Timer:

92b8d96b9e1a01360a17224ff0351548  Devel-Timer-0.06.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Devel-Timer] perl-Devel-Timer: version 0.06

2014-11-09 Thread Denis Fateyev

commit 7c7d58cb853f3ea0ad8626adf2c30887b16d9a50
Author: Denis Fateyev de...@fateyev.com
Date:   Mon Nov 10 01:00:39 2014 +0600

perl-Devel-Timer: version 0.06

 .gitignore|1 +
 perl-Devel-Timer.spec |   18 ++
 sources   |2 +-
 3 files changed, 8 insertions(+), 13 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d6f866f..b701051 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Devel-Timer-0.05.tar.gz
+/Devel-Timer-0.06.tar.gz
diff --git a/perl-Devel-Timer.spec b/perl-Devel-Timer.spec
index c9795fc..6d0f22f 100644
--- a/perl-Devel-Timer.spec
+++ b/perl-Devel-Timer.spec
@@ -1,15 +1,12 @@
 Name:   perl-Devel-Timer
-Version:0.05
-Release:2%{?dist}
+Version:0.06
+Release:1%{?dist}
 Summary:Track and report execution time for parts of code
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Devel-Timer/
 
 Source0:
http://search.cpan.org/CPAN/authors/id/S/SZ/SZABGAB/Devel-Timer-%{version}.tar.gz
-%if 0%{?el5}
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-%endif
 BuildArch:  noarch
 
 BuildRequires:  perl
@@ -29,6 +26,7 @@ BuildRequires:  perl(strict)
 BuildRequires:  perl(vars)
 
 # Testing
+BuildRequires:  perl(Capture::Tiny) = 0.24
 BuildRequires:  perl(Test::More)
 BuildRequires:  perl(warnings)
 
@@ -48,9 +46,6 @@ perl Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
 
 %install
-%if 0%{?el5}
-rm -rf $RPM_BUILD_ROOT
-%endif
 make pure_install DESTDIR=$RPM_BUILD_ROOT
 
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
@@ -60,10 +55,6 @@ find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} 
\;
 %check
 make test
 
-%if 0%{?el5}
-%clean
-rm -rf $RPM_BUILD_ROOT
-%endif
 
 %files
 %doc COPYING Changes
@@ -72,6 +63,9 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Sat Nov 08 2014 Denis Fateyev de...@fateyev.com - 0.06-1
+- Update to 0.06 release
+
 * Tue Oct 07 2014 Denis Fateyev de...@fateyev.com - 0.05-2
 - Small spec improvements
 
diff --git a/sources b/sources
index c2bf685..ac227d4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-21b0e50193235b9d370514a17dd0e49f  Devel-Timer-0.05.tar.gz
+92b8d96b9e1a01360a17224ff0351548  Devel-Timer-0.06.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Devel-Timer/f20] perl-Devel-Timer: version 0.06

2014-11-09 Thread Denis Fateyev

Summary of changes:

  7c7d58c... perl-Devel-Timer: version 0.06 (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Devel-Timer/f21] perl-Devel-Timer: version 0.06

2014-11-09 Thread Denis Fateyev

Summary of changes:

  7c7d58c... perl-Devel-Timer: version 0.06 (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Devel-Timer/epel7] perl-Devel-Timer: version 0.06

2014-11-09 Thread Denis Fateyev

Summary of changes:

  7c7d58c... perl-Devel-Timer: version 0.06 (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Text-Aligner/epel7] (2 commits) ...0.12 bump

2014-10-25 Thread Denis Fateyev

Summary of changes:

  c510208... 0.11 bump (*)
  095785a... 0.12 bump (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

81 matches

Mail list logo