[EPEL-devel] Packages disappearing from the EPEL 9 buildroot

[Mattias Ellert]

Hi!

Two packages I built for EPEL 9 are now reported by koschei as having
missing build dependencies.

https://koschei.fedoraproject.org/package/davix?collection=epel9

https://koschei.fedoraproject.org/package/uglify-js?collection=epel9

The EPEL 9 builds were built using the following build dependencies
according to the root.log files:

rapidjson-devel-1.1.0-19.el9

web-assets-devel-5-15.el9
nodejs-packaging-2021.01-5.el9

These can no longer be found in the koji buildroot. There are no
expired buildroot overrides for these builds, which could explain the
disappearance.

I can't find these builds in EPEL's koji, so I guess they where
provided by RHEL, but now are no longer? Did RHEL dop these?

Mattias



smime.p7s
Description: S/MIME cryptographic signature
___
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

gsoap updated in rawhide

[Mattias Ellert]

The gsoap package was updated in rawhide to version 2.8.117. As always
for this package there is a soname bump.

The following dependent packages were rebuild by me:

CGSI-gSOA
voms

The following dependent packages need to be rebuilt. Maintainers in cc:

davix
dmlite
gridsite
srm-ifce

Mattias



smime.p7s
Description: S/MIME cryptographic signature
___
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

Non-responsive maintainer tc01 (Ben Rosser)

[Mattias Ellert]

Hi!

I filed a bugzilla request 2021-04-18 (almost 4 month ago) asking for
the uglify-js package to be updated:

https://bugzilla.redhat.com/show_bug.cgi?id=1950780

There has been no reply from the maintainer.

Following the non-responsive maintainer policy
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

I have filed a non-responsive maintainer bugzilla tickat and is asking
on this mailing list if anyone knows how to contact the maintainer tc01
(Ben Rosser):

https://bugzilla.redhat.com/show_bug.cgi?id=1992605

Mattias



smime.p7s
Description: S/MIME cryptographic signature
___
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] gnu-free-fonts-20120503-18.el8.0.1 still not tagged into dist-c8-compose

[Mattias Ellert]

Hi.

I was asked to repost a thread from the CentOS forum on this mailing
list:

Sorry for starting a new thread. But there has not been any activity on
the old thread for a month (2020-02-05) except for my request for a
status update a week ago (2020-02-26) for which there was no reply.

Can someone please tag the update so that it can be installed by users.
The packages available to users are still broken, even though the
update was built almost two month ago (2020-01-07).

For details please see the previous threads and bug reports:

https://forums.centos.org/viewtopic.php?f=54=73346
https://forums.centos.org/viewtopic.php?f=54=72682
https://bugs.centos.org/view.php?id=16759
https://bugs.centos.org/view.php?id=16523

The bug was first reported 2019-10-03 and the fixed packages were built
2020-01-07 but are not yet available for installation/update and the
bug still affects users.

And before someone replies "should be fixed in RHEL first" before
reading the references above - this is a CentOS only bug that never
existed in RHEL.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
___
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

Re: epel8: BuildrootError: could not init mock buildroot

[Mattias Ellert]

tor 2020-01-30 klockan 17:42 -0800 skrev Kevin Fenzi:
> On Thu, Jan 30, 2020 at 07:57:22AM -0500, Stephen John Smoogen wrote:
> > On Thu, 30 Jan 2020 at 06:06, Jiri Kucera  wrote:
> > > Hello,
> > > 
> > > when doing `fedpkg scratch-build --target epel8-candidate --srpm
> > > sox-14.4.2.0-29.el8.src.rpm`, I get:
> > > 
> > 
> > So there seems to be something off in koji and the repo is not getting
> > properly regenerated after the repo gets updated. These errors seem to
> > have occurred after we updated koji to the latest release so this may
> > be a change in what koji does.
> 
> I fear it's just bad timing + the external rhel8 repo we have only keeps
> the newest packages (epel7 repos keep the old packages around too). 
> 
> koji has no way to know that an external repo updated and needs
> regeneration, so it just regenerates it when the buildroots that depend
> on it change, ie, for epel8 that means when a stable updates push goes
> out. Since updates pushes have been broken, no regen has happened
> recently. ;( For epel7, it's fine just using the older package, but in
> epel8 it's gone and you see the 404 for it. 
> 
> Updates pushes should be going again so that should help. 
> 
> After that I guess we could try and just do a regen every day no matter
> what? Or add something to the script that updates the repo to fire one
> after anything updates?
> 
> kevin

There is a work-around for this. Since the buildroot is regenerated
when a buildroot override is added, you can repair the buildroot by
adding an override for some random package you don't really need an
override for, see e.g.:

https://bodhi.fedoraproject.org/overrides/castxml-0.2.0-1.el8

It would of course be better if changes to the external repo would be
automatically detected, but until that happens you can work around it.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
___
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

gsoap updated in rawhide

[Mattias Ellert]

The gsoap package was updated in rawhide to version 2.8.91. As always
for this package there is a soname bump.

The following dependent packages were rebuild by me:

CGSI-gSOA
voms

The following dependent packages need to be rebuilt. Maintainers in cc:

davix
dmlite
fts
glite-lb-server
glite-lbjp-common-gsoap-plugin
gridsite
lcgdm
lcgdm-dav
srm-ifce

Mattias



smime.p7s
Description: S/MIME cryptographic signature
___
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

[EPEL-devel] The use of the playground

[Mattias Ellert]

Hi!

I recently had a discussion about the use of the playground on
pagure.io: https://pagure.io/releng/issue/8582

I was asked to bring the discussion here to epel-devel.

I quote my last comment from the thread below. If you want more details
you can read the entire thread at the pagure link above.


You plan is to use the epel-playground repo for two very different and
incompatible tasks.

The first usecase is as a playground where maintainers can try out new
versions and new features. This means that the versions of packages in
the epel-playground are allowed to be different from the versions in
epel, might have additional features enabled that the versions in epel
are missing, and occasionally could even be backward incompatible with
the version i epel or have a different soname for libraries.

The second usecase is as a place to do mass rebuilds for new rhel point
releases, where you plan to change the rhel base to a new point release
in epel-playgroind, do the rebuilds in epel-playground, and the when
you change th epel repo to the new point release merge the mass rebuilt
packages back to epel. But, since the use case for the playground
repository was to be a place where new unstable stuff is tested, all
those rebuilds will have been built against these new versions and
might depend on features that are not provided by the dependencies that
are in epel, or be compiled to depend on a different soname than the
library that is available in epel.

I.e. since the playground is a playground, packages built in the
playground must never be merged into main epel.

In Fedora there are rebuilds all the time. For new python versions, for
new perl versions, and the recurring mass rebuilds. These are done in
side tags. This can be done without adding a package.cfg file allowing
the build of the package in the side tag, but koji allows this by
default.

The proper way to do a mass rebukd for epel8 is to declare an epel8-
rebuild sidetag that inherits from the rhel 8.n+1 and epel8 and
definitely must not inherit from epel8-playground. The packages built
in this sidetag can then be safely merged into epel8, when epel8 is
redefined to inherit from rhel 8.n+1. And since it is a sidetag there
should be no need to add any special package.cfg since this is not
needed for sidetags in fedora.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
___
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

Re: Could not execute clone: [Errno 2] No such file or directory: '/home/mcatanzaro/Projects/fedora-scm/eog/.git/info/exclude'

[Mattias Ellert]

ons 2019-08-07 klockan 08:30 +0200 skrev Lubomír Sedlář:

> On my machine git creates the file on any clone. How did you manage to
> configure it to not do so?
> That being said, it's still a bug and should be fixed.

You can prevent fedpkg from adding patterns to the exclude file by
adding the following to your ~/.config/rpkg/fedpkg.conf 

[fedpkg]
git_excludes =

Mattias



smime.p7s
Description: S/MIME cryptographic signature
___
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

Re: friday roundup of failing images in rawhide

[Mattias Ellert]

fre 2019-07-19 klockan 18:16 -0700 skrev Kevin Fenzi:
> hey folks, here is a list of currently failing images in rawhide.
> Please fix if you can.
> 
> 4. Fedora scientific KDE:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=36353230
> 
> Problems in request:
> missing packages: root-python
> 
> root-python no longer exists.
> PR to drop it from the kickstart:
> 
> https://pagure.io/fedora-kickstarts/pull-request/547

root-python was the old name for python2-root.
python2-root had Provides and Obsoletes for the old name.
python2-root was dropped in rawhide. python3-root exists if you prefer
to change to the python3 version rather than simply dropping it.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
___
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

Trying to reach maintainer Andreas Bierfert (FAS: awjb)

[Mattias Ellert]

Hi!

I have not been successful in reaching maintainer Andreas Bierfert
(FAS: awjb, e-mail in FAS: andreas.bierf...@lowlatency.de).

Does anyone know if he is still around?

Mattias



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such file or directory

[Mattias Ellert]

The breakage is i Fedora 29.

Mattias

mån 2018-12-10 klockan 12:34 + skrev Sérgio Basto:
> IIRC this is fixed with Mesa in rawhide 
> 
> On Mon, 2018-12-10 at 09:23 +, Samuel Rakitničan wrote:
> > Hi,
> > 
> > Got an e-mail from Koschei [1] with a notice that camotics package is
> > starting to fail to build. The reason for this seems to be that
> > something that used to pull mesa-libEGL-devel doesn't do so anymore.
> > 
> > /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No
> > such file or directory
> > 
> > Since /usr/include/GL/glext.h belongs to mesa-libGL-devel and not
> > camotics I think it would be more appropriate to put the dependency
> > there. Thoughts?
> > 
> > [1] https://apps.fedoraproject.org/koschei/package/camotics?collection=f29
> > 


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F29 Mass rebuild - Help needed to fix failed build

[Mattias Ellert]

ons 2018-07-18 klockan 15:23 +0200 skrev Zoltan Kota:
> Hi All,
> 
> The Mass rebuild of pybliographer failed. See below:
> 
> Fwd: releng's pybliographer-1.2.18-4.fc29 failed to build
> 
> Notification time stamped 2018-07-15 03:04:40 UTC
> 
> releng's pybliographer-1.2.18-4.fc29 failed to build
> http://koji.fedoraproject.org/koji/buildinfo?buildID=1121364
> 
> It seems the .configure script does not find 'python'. The script uses Python 
> variable to store python path (configure.ac: AC_PATH_PROG(Python, python, no) 
> ).
> 
> Can I add/override this variable in the spec file? 
> eg. %configure Python=%{__python2}
> 
> or what is the correct syntax/way to fix the issue?
> 
> Thanks,
> Zoltan

diff --git a/pybliographer.spec b/pybliographer.spec
index ac77e97..4649812 100644
--- a/pybliographer.spec
+++ b/pybliographer.spec
@@ -47,6 +47,7 @@ file formats: BibTeX, ISI, Medline, Ovid, Refer.
 %setup -q
 
 %build
+export Python=/usr/bin/python2
 %configure
 make %{?_smp_mflags}
 
Mattias


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SFNZXL6CPL3UL6RWQ7XXICJMFXYZMV2X/

Re: Packaging Question

[Mattias Ellert]

fre 2017-10-27 klockan 11:47 -0400 skrev Steve Dickson:
> 
> This makes sense but the reason the libnfsidmap-devel package is not
> be upgraded (or installed) is because:
> 
> dnf install /tmp/libnfsidmap-devel*
> Last metadata expiration check: 0:10:48 ago on Fri 27 Oct 2017 11:19:35 AM 
> EDT.
> Error: 
>  Problem: conflicting requests
>   - nothing provides libnfsidmap = 2.2.1-0.fc28 needed by 
> libnfsidmap-devel-1:2.2.1-0.fc28.x86_64
> 
> even though libnfsidmap-2.2.1-0 is installed. 
> 
> The problem is caused by the Requires: in the libnfsidmap-devel subpackage
> 
> %package -n libnfsidmap-devel
> Summary: Development files for the libnfsidmap library
> Group: Development/Libraries
> Requires: pkgconfig
> Requires: libnfsidmap = %{version}-%{release}
> ^^^
> 
> Now if I remove the '%{version}-%{release}' the package 
> is installed/upgraded... but seems wrong to me
> the -devel should be tied to a particular version, right?
> 
> Plus this was the way it was in the original libnfsidmap rpm.
> 
> tia,
> 
> steved.

Your package has epoch defined, so you need to use it when declaring
versioned dependencies between binary packages. 2.2.1-0 is not the same
as 1:2.2.1-0. (And you should use _isa here:

%package -n libnfsidmap-devel
Requires: libnfsidmap%{?_isa} = %{epoch}:%{version}-%{release}

Mattias


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ssl is not being compiled on dillo on F26

[Mattias Ellert]

tis 2017-09-12 klockan 03:20 + skrev Globe Trotter:
> Thank you very much again for helping out here: I would not have
> known how to fix this. I am wondering if you think that it might be a
> good idea to ask upstream to update using openssl v 1.1 (with the
> patch included). If this is the future for openssl, then that might
> be a good move for them to use openssl 1.1?
> 
> I have also submitted updates to testing with this patch, thanks again!

In this case the code still works with older versions of openssl with
the patch applied, since the new lines of code do not use any new
features introduced in openssl 1.1.

Applying the patch does not mean you have to switch to openssl 1.1,
just that you can if you choose to do so. Nothing is lost by applying
the patch, and you gain openssl 1.1 support.

This should be sent upstream.

Mattias


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ssl is not being compiled on dillo on F26

[Mattias Ellert]

lör 2017-09-09 klockan 05:00 + skrev Globe Trotter:
> Hi,
> 
> Thank you for your detailed response. However, I tried replacing
> 
> AC_CHECK_LIB(ssl, SSL_library_init, ssl_ok=yes, ssl_ok=no, -lcrypto)
> 
> with 
> 
> AC_CHECK_LIB(ssl, SSL_writet, ssl_ok=yes, ssl_ok=no, -lcrypto)
> 
> but I get the following error later on in the compilation:
> 
> https.c: In function 'handle_certificate_problem':
> https.c:479:38: error: dereferencing pointer to incomplete type 'X509 {aka 
> struct x509_st}'
>   if ((cn = strstr(remote_cert->name, "/CN=")) == NULL) {
>   ^~
> make[2]: *** [Makefile:887: https.o] Error 1
> 
> I presume that this is an error on account of my change. How do I get around 
> this error? 
> 
> Many thanks again!

With your change, the configure script detects openssl properly again.
However, you still need to do the necessary porting of the code itself
to support openssl 1.1. This is a different problem than getting
configure to work.

This is not the most obvious change, but you need to replace

remote_cert->name

with

X509_NAME_oneline(X509_get_subject_name(remote_cert)

Though the string returned by X509_NAME_oneline needs to be freed, so
just doing the replacement would result in a memory leak.

Patch attached.

Mattias
diff -ur dillo-3.0.5.orig/configure.ac dillo-3.0.5/configure.ac
--- dillo-3.0.5.orig/configure.ac	2015-06-30 16:07:06.0 +0200
+++ dillo-3.0.5/configure.ac	2017-09-11 15:51:57.910529543 +0200
@@ -286,7 +286,7 @@
 
   if test "x$ssl_ok" = "xyes"; then
 old_libs="$LIBS"
-AC_CHECK_LIB(ssl, SSL_library_init, ssl_ok=yes, ssl_ok=no, -lcrypto)
+AC_CHECK_LIB(ssl, SSL_write, ssl_ok=yes, ssl_ok=no, -lcrypto)
 LIBS="$old_libs"
   fi
 
diff -ur dillo-3.0.5.orig/dpi/https.c dillo-3.0.5/dpi/https.c
--- dillo-3.0.5.orig/dpi/https.c	2015-06-30 16:06:08.0 +0200
+++ dillo-3.0.5/dpi/https.c	2017-09-11 16:03:39.862924064 +0200
@@ -443,6 +443,7 @@
char buf[4096], *d_cmd, *msg;
 
X509 * remote_cert;
+   char * remote_cert_name;
 
remote_cert = SSL_get_peer_certificate(ssl_connection);
if (remote_cert == NULL){
@@ -476,7 +477,9 @@
   case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT:
  /*Either self signed and untrusted*/
  /*Extract CN from certificate name information*/
- if ((cn = strstr(remote_cert->name, "/CN=")) == NULL) {
+ remote_cert_name =
+X509_NAME_oneline(X509_get_subject_name(remote_cert), NULL, 0);
+ if ((cn = strstr(remote_cert_name, "/CN=")) == NULL) {
 strcpy(buf, "(no CN given)");
  } else {
 char *cn_end;
@@ -489,6 +492,7 @@
 strncpy(buf, cn, (size_t) (cn_end - cn));
 buf[cn_end - cn] = '\0';
  }
+ OPENSSL_free(remote_cert_name);
  msg = dStrconcat("The remote certificate is self-signed and "
   "untrusted.\nFor address: ", buf, NULL);
  d_cmd = a_Dpip_build_cmd(


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ssl is not being compiled on dillo on F26

[Mattias Ellert]

In openssl 1.1 some functions were renamed to newer more consistent
names. There are however preprocessor macros defined for most of them
so that old code still compiles. One of the old functions that was
renamed was SSL_library_init, which now is defined in
/usr/include/openssl/ssl.h as

# define SSL_library_init() OPENSSL_init_ssl(0, NULL)

The configure.ac in dillo uses AC_CHECK_LIB to detect the presence of
the openssl library like this:

AC_CHECK_LIB(ssl, SSL_library_init, ssl_ok=yes, ssl_ok=no, -lcrypto)

The AC_CHECK_LIB macro only checks for the presence of a symbol in the
library and bypasses any definitions in the header files, so it is
unaware of the preprocessor macro in the header file that redirects the
call to SSL_library_init to a call to OPENSSL_init_ssl. And since
SSL_library_init is no longer a proper symbol in the openssl library
the check fails.

This is easily fixed by replacing the check for SSL_library_init with a
check for a function that hasn't changed name, see e.g. the change
implemented in dcap:

https://github.com/dCache/dcap/pull/12/files

Mattias


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: R packages needing review

[Mattias Ellert]

tor 2017-06-01 klockan 10:39 -0400 skrev Tom Callaway:
> Background: R recently released 3.4.0, which introduced changes that
> required all "compiled" R modules to be rebuilt against it. I've been
> working over the last week or so to do this, and at the same time, bring
> them to the latest revisions.
> 
> Unfortunately, CRAN and Bioconductor (where the majority of R modules
> live) have a bit of a dependency creep problem, where almost every
> update adds new dependencies on other R modules (it's even worse if you
> run the test suites). In order to finish this work and push the R 3.4.0
> update to stable, I need to have the following new R packages reviewed:
> 
> R-GenomeInfoDbData : https://bugzilla.redhat.com/show_bug.cgi?id=1456973
> R-Snow : https://bugzilla.redhat.com/show_bug.cgi?id=1457390
> R-futile.options : https://bugzilla.redhat.com/show_bug.cgi?id=1457391
> R-lambda.r : https://bugzilla.redhat.com/show_bug.cgi?id=1457393
> R-futile.logger : https://bugzilla.redhat.com/show_bug.cgi?id=1457395
> R-BiocParallel : https://bugzilla.redhat.com/show_bug.cgi?id=1457396
> R-magrittr : https://bugzilla.redhat.com/show_bug.cgi?id=1457404
> R-R6 : https://bugzilla.redhat.com/show_bug.cgi?id=1457405
> R-matrixStats : https://bugzilla.redhat.com/show_bug.cgi?id=1457447
> R-DelayedArray : https://bugzilla.redhat.com/show_bug.cgi?id=1457449
> R-SummarizedExperiment : https://bugzilla.redhat.com/show_bug.cgi?id=1457451
> R-GenomicAlignments : https://bugzilla.redhat.com/show_bug.cgi?id=1457453
> 
> None of these are terribly complicated, so they should be very quick
> reviews.
> 
> I will happily trade reviews and or other favors to get these done,
> ideally, this week.
> 
> Thanks in advance,
> 
> ~tom
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

I can take a few a these. If you could review these two python packages
for me:

https://bugzilla.redhat.com/show_bug.cgi?id=1448040
Review Request: python-ipyparallel - Interactive Parallel Computing
with IPython

https://bugzilla.redhat.com/show_bug.cgi?id=1448041
Review Request: python-metakernel - Metakernel for Jupyter

The second one uses the first one when running tests, so they need to
be done in sequence.

Mattias


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help needed with packaging issue, conflicting file /usr/lib/.build-id

[Mattias Ellert]

tor 2017-06-01 klockan 09:20 +0200 skrev Christian Dersch:
> Hi all,
> 
> I have an issue with one package (wcslib) on i686 and armv7hl
> architecture in rawhide, the built binary package has file conflicts
> with some more packages only on that architectures, the others seem
> to be fine (so it seems like 32 Bit is affected in general). Below
> log from mock build of a package requiring wcslib. Does anybody have
> an idea on how to solve this or what causes this?
> 
> Greetings
> Christian

The build-id directories in the package has the setgid bit set (notice
the s in the file listing below). This is a bug in rpm similar to

https://bugzilla.redhat.com/show_bug.cgi?id=1432372 and
https://bugzilla.redhat.com/show_bug.cgi?id=1449732

which describes similar problems for file ownership and rpm metadata
tagging. I suggest filing a similar bug against rpm reporting the
setgid problem. I am not really sure where the setgid bit setting comes
from in this case. The earler bugs were due to the build-id directories
"inheriting" the wrong settings from another file in the package, but
there are no setgid bit set on any of the other files in the package
here.

Mattias

$ rpm -qlvp wcslib-5.16-2.fc27.i686.rpm 
drwxr-sr-x2 rootroot0 maj 20 00:29 
/usr/lib/.build-id
drwxr-sr-x2 rootroot0 maj 20 00:29 
/usr/lib/.build-id/6b
lrwxrwxrwx1 rootroot   34 maj 20 00:29 
/usr/lib/.build-id/6b/1b7ef6e5f72a46eb0512ba8bfc5bfd5d8a7130 -> 
../../../../usr/lib/libwcs.so.5.16
lrwxrwxrwx1 rootroot   14 maj 20 00:28 
/usr/lib/libwcs.so.5 -> libwcs.so.5.16
-rwxr-xr-x1 rootroot  1350320 maj 20 00:28 
/usr/lib/libwcs.so.5.16
drwxr-xr-x2 rootroot0 maj 20 00:29 
/usr/share/doc/wcslib
-rw-r--r--1 rootroot 1847 jan 15 05:25 
/usr/share/doc/wcslib/README
drwxr-xr-x2 rootroot0 maj 20 00:29 
/usr/share/licenses/wcslib
-rw-r--r--1 rootroot 7637 jan 19  2010 
/usr/share/licenses/wcslib/COPYING.LESSER



> DEBUG util.py:439:file /usr/lib/.build-id from install of wcslib-
> 5.16-2.fc27.i686 conflicts with file from package libnghttp2-1.23.1-
> 1.fc27.i686
> DEBUG util.py:439:file /usr/lib/.build-id from install of wcslib-
> 5.16-2.fc27.i686 conflicts with file from package libcurl-7.54.0-
> 5.fc27.i686
> DEBUG util.py:439:file /usr/lib/.build-id from install of wcslib-
> 5.16-2.fc27.i686 conflicts with file from package curl-7.54.0-
> 5.fc27.i686
> DEBUG util.py:439:file /usr/lib/.build-id from install of wcslib-
> 5.16-2.fc27.i686 conflicts with file from package rpm-plugin-selinux-
> 4.13.0.1-23.fc27.i686
> DEBUG util.py:439:file /usr/lib/.build-id from install of wcslib-
> 5.16-2.fc27.i686 conflicts with file from package rpm-libs-4.13.0.1-
> 23.fc27.i686
> DEBUG util.py:439:file /usr/lib/.build-id from install of wcslib-
> 5.16-2.fc27.i686 conflicts with file from package rpm-4.13.0.1-
> 23.fc27.i686
> DEBUG util.py:439:file /usr/lib/.build-id from install of wcslib-
> 5.16-2.fc27.i686 conflicts with file from package rpm-build-libs-
> 4.13.0.1-23.fc27.i686
> DEBUG util.py:439:file /usr/lib/.build-id from install of wcslib-
> 5.16-2.fc27.i686 conflicts with file from package rpm-build-4.13.0.1-
> 23.fc27.i686
> DEBUG util.py:439:file /usr/lib/.build-id from install of wcslib-
> 5.16-2.fc27.i686 conflicts with file from package util-linux-2.30-
> 0.1.fc27.i686
> DEBUG util.py:439:file /usr/lib/.build-id/6b from install of
> wcslib-5.16-2.fc27.i686 conflicts with file from package util-linux-
> 2.30-0.1.fc27.i686
> DEBUG util.py:439:file /usr/lib/.build-id from install of wcslib-
> 5.16-2.fc27.i686 conflicts with file from package gcc-c++-7.1.1-
> 2.fc27.i686
> DEBUG util.py:439:file /usr/lib/.build-id conflicts between
> attempted installs of wcslib-5.16-2.fc27.i686 and libgfortran-7.1.1-
> 2.fc27.i686
> DEBUG util.py:439:file /usr/lib/.build-id conflicts between
> attempted installs of python2-2.7.13-10.fc27.i686 and wcslib-5.16-
> 2.fc27.i686
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Review swap requests

[Mattias Ellert]

Hi!

I am offering two python packages for review swapping:

https://bugzilla.redhat.com/show_bug.cgi?id=1448040
Review Request: python-ipyparallel - Interactive Parallel Computing
with IPython

https://bugzilla.redhat.com/show_bug.cgi?id=1448041
Review Request: python-metakernel - Metakernel for Jupyter

The second one uses the first one when running tests, so they need to
be done in sequence.

Mattias


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

gsoap updated in rawhide

[Mattias Ellert]

Hi!

The gsoap package has been updated to version 2.8.43 in rawhide only.
Dependent packages should rebuild.
However, the mass rebuild is scheduled to start this week so just
leaving it to be fixed by the mass rebuild is very much OK.

$ dnf repoquery --releasever rawhide --srpm --whatrequires gsoap --alldeps
davix-0:0.6.4-3.fc26.src
fts-0:3.5.7-1.fc26.src
glite-lb-server-0:3.0.18-12.fc26.src
glite-lbjp-common-gsoap-plugin-0:3.2.12-10.fc26.src
gridsite-0:2.3.2-2.fc26.src
gsoap-0:2.8.35-3.fc26.src
lcgdm-0:1.9.0-3.fc26.src
lcgdm-dav-0:0.18.0-1.fc26.src
srm-ifce-0:1.24.1-2.fc26.src
voms-0:2.1.0-0.1.rc0.fc26.src

Mattias


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packages FTBFS with Python 3.6

[Mattias Ellert]

ons 2016-12-28 klockan 20:25 +0100 skrev Igor Gnatenko:
> On Wed, Dec 21, 2016 at 12:18 AM, Miro Hrončok 
> wrote:
> > Hi all,
> > We've recently tried to rebuild all Python packages with Python 3.6.
> > However, we currently have bunch of packages that simply fail to build.
> > 
> > As the list contains >200 packages, it would be very helpful, if you
> > (package maintainers) could help us solve the issues, as we cannot go one by
> > one to investigate the issue.
> 
> Attaching current rawhide/koji packages which depend on python 3.5
> instead of 3.6 still.

> root
Fails due to problems generating the debuginfo rpm on aarch64:

https://bugzilla.redhat.com/show_bug.cgi?id=1405570
https://bugzilla.redhat.com/show_bug.cgi?id=1408875

Mattias


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Looking for a proven packager

[Mattias Ellert]

Hi!

I submitted a bugzilla report with a patch that implements an
improvement of the hadoop package in Fedora, extending the current
incomplete Fedora integration patch that only supports ix86 and x86_64
to more architectures. The maintainer is unwilling to apply it, but
says that if a proven packager would apply it he would be extatic.

https://bugzilla.redhat.com/show_bug.cgi?id=1328076

Since I am not a proven packager myself, I am looking for one that can
perform this task.

Mattias


smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

gsoap updated in rawhide

[Mattias Ellert]

Hi!

The gsoap package has been updated to version 2.8.30 in rawhide only.
Dependent packages should rebuild.

dnf repoquery --releasever rawhide --srpm --whatrequires gsoap --alldeps
davix-0:0.6.3-1.fc25.src
fts-0:3.3.1-5.fc24.src
glite-lb-server-0:3.0.18-10.fc24.src
glite-lbjp-common-gsoap-plugin-0:3.2.12-8.fc24.src
gridsite-0:2.2.6-3.fc24.src
lcgdm-0:1.8.10-4.fc24.src
lcgdm-dav-0:0.17.1-2.fc25.src
srm-ifce-0:1.23.3-2.fc24.src
voms-0:2.0.13-1.fc24.src

Mattias


smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fwd: Broken dependencies: qpid-dispatch

[Mattias Ellert]

mån 2016-04-18 klockan 09:41 -0400 skrev Irina Boverman:
> Why I am getting these messages?
> Latest version in rawhide is 0.5-3, and there are no broken
> dependencies...
> Regards, Irina.
> - Forwarded Message -
> From: build...@fedoraproject.org
> To: qpid-dispatch-ow...@fedoraproject.org
> Sent: Monday, April 18, 2016 9:11:59 AM
> Subject: Broken dependencies: qpid-dispatch
> 
> 
> 
> qpid-dispatch has broken dependencies in the rawhide tree:
> On x86_64:
>   qpid-dispatch-router-0.5-2.fc24.x86_64 requires libqpid-
> proton.so.3()(64bit)
> On i386:
>   qpid-dispatch-router-0.5-2.fc24.i686 requires libqpid-
> proton.so.3
> On armhfp:
>   qpid-dispatch-router-0.5-2.fc24.armv7hl requires libqpid-
> proton.so.3
> On x86_64:
>   libqpid-dispatch-0.5-2.fc24.x86_64 requires libqpid-
> proton.so.3()(64bit)
> On i386:
>   libqpid-dispatch-0.5-2.fc24.i686 requires libqpid-proton.so.3
> On armhfp:
>   libqpid-dispatch-0.5-2.fc24.armv7hl requires libqpid-
> proton.so.3
> Please resolve this as soon as possible.
> 

You are not the only one suffering from this. I filed a rel-eng ticket
about it two days ago.

https://fedorahosted.org/rel-eng/ticket/6393

Mattias


smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora 24 Mass Rebuild

[Mattias Ellert]

tor 2016-02-11 klockan 20:52 -0600 skrev Yaakov Selkowitz:
> On 2016-02-06 00:08, Dennis Gilmore wrote:
> > The Mass Rebuild has been completed, 16129 builds have been tagged
> > into f24,
> > there s currently 1155 failed builds that need to be addressed by
> > the package
> > maintainers. FTBFS bugs will be filed shortly.
> 
> Is https://bugzilla.redhat.com/show_bug.cgi?id=1305208 the intended 
> tracker for these?  If so, per past mass rebuilds, a F24FTBFS alias 
> would be helpful.  However, there are only a handful of bugs filed so
> far.

I didn't see it announce anywhere - though I might have missed it - but
I found the list of failed builds here:

http://alt.fedoraproject.org/pub/alt/mass-rebuild/f24-failures.html

Mattias


smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Review swaps (4 R packages)

[Mattias Ellert]

Hi!

I have 4 R package that I submitted for review.

https://bugzilla.redhat.com/show_bug.cgi?id=1305333 R-highlight
https://bugzilla.redhat.com/show_bug.cgi?id=1305334 R-inline
https://bugzilla.redhat.com/show_bug.cgi?id=1305335 R-Rcpp
https://bugzilla.redhat.com/show_bug.cgi?id=1305336 R-RInside

There is a dependency chain: The 3rd depends on the first two, and the
4th depends on the 3rd.

Review swaps welcome.

Mattias


smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

gsoap updated in rawhide

[Mattias Ellert]

Hi!

The gsoap package has been updated to version 2.8.28 in rawhide.
Dependent packages should rebuild.

The Fedora 24 mass rebuild is scheduled to start today, which should
take care of these. But if your package is listed below, check that it
builds as expected. In some cases there are dependency chains that
require packages to be built in order, so some might not build until
the second or third pass in the rebuild.

# dnf repoquery --whatrequires libgsoap* --srpm
davix-0:0.5.0-2.fc24.src
fts-0:3.3.1-4.fc24.src
glite-lb-server-0:3.0.18-9.fc24.src
glite-lbjp-common-gsoap-plugin-0:3.2.12-7.fc23.src
gridsite-0:2.2.6-2.fc24.src
gsoap-0:2.8.22-2.fc23.src
lcgdm-0:1.8.10-2.fc24.src
lcgdm-dav-0:0.16.0-2.fc24.src
srm-ifce-0:1.23.3-1.fc24.src
voms-0:2.0.12-7.fc24.src

Mattias


smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Build root prepared by DNF is way larger

[Mattias Ellert]

tis 2016-01-26 klockan 10:18 + skrev Peter Robinson:
> > > > So it appears this thread was probably not enough. Which keeps us with
> > > > interesting state where mock by default does not install weak
> > > > dependencies where Koji installs them. It causes interesting issues 
> > > > already.
> > > 
> > > mock/koji not installing weak dependencies == anything wanting ruby
> > > being broken.
> > > 
> > > Reason: "ruby" suggests "rubypick" which suggests "ruby".
> > > 
> > > Packages buildrequire "ruby" but do not get "rubypick" installed (or if
> > > they are lucky they get) so are unable to find Ruby because there is no
> > > "/bin/ruby" executable.
> > 
> > If ruby needs ruby-pick to work, then ruby-pick must not be a weak
> > dependency of ruby, but a hard one.
> > 
> > The koji buildroot really should only install hard dependencies. The
> > buildroot is supposed to be the minimal possible set needed to build
> > the package. If a package that would be installed as a weak dependency
> > of one of the build dependencies is needed to build the package, that
> > packa is a build dependency too.
> 
> That's incorrect. EG a package has optional Ruby bindings, it doesn't
> need ruby to build but if ruby isn't present the ruby binding sub
> package is empty. The buildroot should have all that is needed to
> build the desired functionality, nothing more nothing less.
> 
> Peter

I agree that it is a reasonable expectation that installing "ruby"
should make a /usr/bin/ruby binary available. The fact that it
currently doesn't when weak dependencies are not installed is a
packaging bug in ruby, which should be addressed. It is not a reason to
bloat every koji build root for every build of every package in Fedora
with every weak dependency of every build dependency of the package
being built.

Mattias


smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Build root prepared by DNF is way larger

[Mattias Ellert]

mån 2016-01-25 klockan 18:09 +0100 skrev Marcin Juszkiewicz:
> W dniu 25.01.2016 o 17:03, Vít Ondruch pisze:
> > So it appears this thread was probably not enough. Which keeps us with
> > interesting state where mock by default does not install weak
> > dependencies where Koji installs them. It causes interesting issues already.
> 
> mock/koji not installing weak dependencies == anything wanting ruby 
> being broken.
> 
> Reason: "ruby" suggests "rubypick" which suggests "ruby".
> 
> Packages buildrequire "ruby" but do not get "rubypick" installed (or if 
> they are lucky they get) so are unable to find Ruby because there is no 
> "/bin/ruby" executable.

If ruby needs ruby-pick to work, then ruby-pick must not be a weak
dependency of ruby, but a hard one.

The koji buildroot really should only install hard dependencies. The
buildroot is supposed to be the minimal possible set needed to build
the package. If a package that would be installed as a weak dependency
of one of the build dependencies is needed to build the package, that
packa is a build dependency too.

Mattias


smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Incomplete work of fedora-review

[Mattias Ellert]

sön 2015-11-22 klockan 22:21 +0100 skrev Christian Dersch:
> Hi all,
> 
> I can confirm the behaviour Jens reports, there are already two bugs
> open @RHBZ:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1275275
> https://bugzilla.redhat.com/show_bug.cgi?id=1279538
> 
> Greetings,
> Christian

The "Install command returned error code 30" is a different bug than
"it is slow". This bug is however also already reported:

https://bugzilla.redhat.com/show_bug.cgi?id=1264803

Mattias

> On Sun, 2015-11-22 at 22:11 +0100, Jens Lody wrote:
> > Am Sonntag, den 22.11.2015, 21:11 +0100 schrieb Antonio Trande:
> > > Hi all,
> > > 
> > > today i'm not able to review any package because of 'fedora-
> > > review'.
> > > Pratically, always appears an info like "Install command returned
> > > error code 30"
> > > 
> > > > fedora-review -m fedora-rawhide-i386 -b ... INFO: Processing 
> > > > bugzilla bug: ... INFO: Getting .spec and .srpm Urls from : ...
> > > > INFO:   --> SRPM url: http://src.rpm INFO:   --> Spec url: 
> > > > http://spec INFO: Using review directory:
> > > > /home/sagitter/... 
> > > > INFO: Downloading .spec and .srpm files ... ... INFO: Running 
> > > > checks and generating report INFO: Results and/or logs in: 
> > > > /home/sagitter/.../results INFO: Build completed INFO:
> > > > Installing
> > > > built package(s) INFO: Install command returned error code 30 
> > > > < INFO: Active plugins: Generic,
> > > > Shell-api, C/C++
> > > 
> > > and, above all, 'htop' shows a
> > > 
> > > > python3 dnf .. -resolve 'something' python3 dnf .. -resolve 
> > > > 'something else'
> > > 
> > > (where 'something' are the BuildRequires packages) that runs over
> > > and
> > > over again.
> > > 
> > > The result directory of fedora-review contains an empty
> > > 'review.txt'
> > > file but package is built correctly.
> > > 
> > > Has anyone else this problem?
> > > 
> > I don't get the "error code 30" messages, but the review is
> > extremly
> > slow.
> > I takes over 3 hours for a package that needs 3 minutes to build on
> > copr (from upload to finish).
> > The most time is spent for "dnf repoquery -q -C --requires --
> > resolve
> > x", it took nearly 3 hours to do 72 repoqueries, many of them
> > are
> > repeated. There are just 30 different packages to resolve.
> > 
> > Between the messages there are several lines of this type (in
> > german):
> > "11-22 19:05 root DEBUGRunning: dnf repoquery -q -C --
> > requires --resolve Die letzte Prüfung auf abgelaufene Metadaten
> > wurde
> > vor 0:12:50 auf Sun Nov 22 16:03:37 2015 ausgeführt"
> > 
> > It tells me that the last metadata check is 0:12:50 ago and was
> > done
> > at
> > 16:03:37, the message has a timestamp of 19:05.
> > The timestamp is correct, the time for the metadata-check is most
> > likely also correct, but the time span is obviously wrong.
> > 
> > The repoqueries from cache need about 2:45 minutes, as normal user
> > and
> > as root, with a refresh the need a little more than 3 minutes.
> > The command eats up 100% of one of my cpu's with 3.2 GHz. Memory
> > can
> > not be a problem, it needs 0.3 % of my 32GB Ram.
> > 
> > Jens
> > 

smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Removing packages that have broken dependencies in F23 tree, v2

[Mattias Ellert]

mån 2015-10-05 klockan 14:59 +0200 skrev Kalev Lember:
> Hi all,
> 
> Here's another look at F23 broken dependencies. A number of packages
> have been fixed last week, but there's also a new broken dependency,
> CableSwig, due to gccxml retirement.

There is a replacement for gccxml available called castxml, which does
mostly the same thing. It is however not a drop-in replacement, since
the name of the binary is different and it has different command line
options, so the castxml package (available in Fedora 23 and rawhide)
does not Provide: gccxml.

The castxml binary has a --castxml-gccxml option which creates output
compatible with the old gccxml, so adapting to use castxml should not
be terribly complicated.

Mattias




smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Can't build EPEL 6 package: broken dependencies, Release Enginering ???

[Mattias Ellert]

tor 2015-10-01 klockan 13:43 -0400 skrev Irina Boverman:
> See here:
>   http://koji.fedoraproject.org/koji/taskinfo?taskID=11296302
>   
> https://kojipkgs.fedoraproject.org//work/tasks/6309/11296309/root.log
> --
> DEBUG util.py:441:  Executing command: ['/usr/bin/yum', '-
> -installroot', '/var/lib/mock/dist-6E-epel-build-4130166
> -530761/root/', 'groupinstall', 'build'] with env {'LANG': 'en_US.UTF
> -8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'LC_MESSAGES': 'C',
> 'PROMPT_COMMAND': 'printf "\x1b]0;\x07"',
> 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'HOME': '/builddir',
> 'HOSTNAME': 'mock'} and shell False
> DEBUG util.py:377:  Error: Package: redhat-rpm-config-9.0.3
> -44.el6.noarch (build)
> DEBUG util.py:377: Requires: /bin/sh
> DEBUG util.py:377:  Error: Package: redhat-rpm-config-9.0.3
> -44.el6.noarch (build)
> DEBUG util.py:377: Requires: mktemp
> DEBUG util.py:377:  Error: Package: epel-release-6-8.noarch (build)
> DEBUG util.py:377: Requires: /bin/sh
> DEBUG util.py:377:  Error: Package: epel-release-6-8.noarch (build)
> DEBUG util.py:377: Requires: redhat-release >= 6
> DEBUG util.py:377:   You could try using --skip-broken to work around
> the problem
> DEBUG util.py:377:   You could try running: rpm -Va --nofiles -
> -nodigest
> DEBUG util.py:377:  Error: Package: redhat-rpm-config-9.0.3
> -44.el6.noarch (build)
> DEBUG util.py:377: Requires: /usr/bin/perl
> DEBUG util.py:377:  Error: Package: redhat-rpm-config-9.0.3
> -44.el6.noarch (build)
> DEBUG util.py:377: Requires: perl(Getopt::Long)
> DEBUG util.py:377:  Error: Package: redhat-rpm-config-9.0.3
> -44.el6.noarch (build)
> DEBUG util.py:377: Requires: /bin/bash
> DEBUG util.py:488:  Child return code was: 1
> DEBUG util.py:170:  kill orphans
> --
> Regards, Irina.

The EPEl build root contains the combination of the RHEL and EPEL
repos. Koji knows when the EPEL repo is updated and regenerates the
build root when this happens, but when RHEL is updated there is no
immediate automatic regeneration triggered of the EPEL build root, so
the EPEL build root can be broken for some time.

The trick I usually do in this case is that I request a build root
override for some package in the affected EPEL release (even though I
don't really need one), which triggers a regeneration of the build root
that picks up the changes from the RHEL repo.

Mattias


smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf: Error: RPM package source (jpilot-1.8.2-2.fc22.src) will not installed

[Mattias Ellert]

mån 2015-09-28 klockan 15:06 +0200 skrev Luigi Votta:

> I've downloaded it with dnf,  
> and attempted to install with rpm.
> 
> But it doesn't install; this is the result:
> 
> warning: mockbuild user doesn't exists - using root user
> 
> when using: 
> rpm -i jpilot-1.8.2-2.fc22.src.rpm

That is a warning, not an error. The installation is successful.

You have installed a src rpm as root, which is normally not a good
idea. It is better to install src rpms as non-root.

Installing a src rpm will not add it to the rpmdb, so it will not be
listed if you do "rpm -q".

Installing src rpms as root will install the files in the tree below
/root/rpmbuild (or whatever "rpm -E %_topdir" says when run as the root
user if you have a non-standard configuration).

If you install it as you own user, which is recommended, the files will
appear in ${HOME}/rpmbuild.

Mattias


smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

gsoap updated in rawhide

[Mattias Ellert]

Hi!

The gsoap package has been updated to version 2.8.22 in rawhide.
Dependent packages should rebuild:

CGSI-gSOAP (*)
davix
fts
glite-lbjp-common-gsoap-plugin
glite-lb-server
gridsite
lcgdm
lcgdm-dav
srm-ifce
voms (*)

(*) These I am maintainer for and rebuilds have been done already.

Mattias


smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gcc5 C++11 ABI rebuilds and FTBFS packages

[Mattias Ellert]

mån 2015-05-04 klockan 13:09 +0200 skrev Kalev Lember:
 Hi all,

 PackageFailed koji task
 =
 gsoap: http://koji.fedoraproject.org/koji/taskinfo?taskID=9650970

This one is due to a regression in gcc:
https://bugzilla.redhat.com/show_bug.cgi?id=1217224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65956

Mattias Ellert




smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Review swaps

[Mattias Ellert]

tor 2015-01-22 klockan 10:48 -0700 skrev Jerry James:

 5. gap-pkg-sonata: https://bugzilla.redhat.com/show_bug.cgi?id=1185018

 Please let me know what I can review for you in exchange.  Thank you.

Hi!

About two weeks ago I sent a list of review requests to this list asking
for review swaps. All but one of them were picked up - many thanks to
the reviewers. I can offer to trade the last remaining one on the list
with you:

https://bugzilla.redhat.com/show_bug.cgi?id=1144801

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

gsoap updated in rawhide

[Mattias Ellert]

Hi!

The gsoap package has been updated to version 2.8.21 in rawhide.
Dependent packages should rebuild:

CGSI-gSOAP (*)
davix
fts
glite-lbjp-common-gsoap-plugin
glite-lb-server
gridsite
lcgdm
lcgdm-dav
srm-ifce
voms (*)

(*) These I am maintainer for and rebuilds have been done already.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Review swaps

[Mattias Ellert]

Hi!

I have a couple of packages submitted for review and I offer to make
swaps for them:

Globus Toolkit packages (C code - mostly loadable modules)

https://bugzilla.redhat.com/show_bug.cgi?id=1144800
  globus-gridmap-eppn-callout
https://bugzilla.redhat.com/show_bug.cgi?id=1144801
  globus-xio-gridftp-multicast
https://bugzilla.redhat.com/show_bug.cgi?id=1144802
  globus-xio-rate-driver
https://bugzilla.redhat.com/show_bug.cgi?id=1144803
  globus-xio-udt-driver
https://bugzilla.redhat.com/show_bug.cgi?id=1181118
  globus-net-manager

The Java implementation of the VOMS clients:

https://bugzilla.redhat.com/show_bug.cgi?id=1165354
  voms-clients-java

Mattias Ellert



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enable tapping by default

[Mattias Ellert]

tis 2014-11-18 klockan 00:16 +0200 skrev Nikos Roussos:
 On 11/18/2014 12:12 AM, Peter Hutterer wrote:
  On Mon, Nov 17, 2014 at 02:27:53PM +0300, Mustafa Muhammad wrote:
  Hi, I am testing Fedora 21 beta and -like all previous versions- click
  by tapping is off by default.
  Several bug reports concerning this were closed as NOTABUG, but
  tapping is useful for us (people who use it), I don't think it bothers
  the others that much, and is on by default in most operating systems
  and Linux distributions.
 
  What can we do to make this happen?
  
  This comes up every couple of versions, so here is the reasoning for
  disabled by default:
  
  * if you don't know that tapping is a thing (or enabled by default), you get
spurious button events that make the desktop feel buggy.
  * if you do know what tapping is and you want it, you usually know where to
enable it, or at least you can search for it.
 
 Well, in practice most users just think it's broken.
 
 You forgot one case though.
 
 * If you know what tapping is and you don't want it (enabled by
 default), you know where to go to disable it.

Even if you know that this weird feature exists, it will take you
hours to disable it, since while you are trying to find your way through
setting and control panels you will get tons and tons of random clicks
that open random windows that needs to be closed and change random
settings that you need to reset. And while you try to do this you get
even more random clicks that open new windows and change other stuff.

Leaving this off by default is sane.

Mattias




smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Make buildSRPMFromSCM faster?

[Mattias Ellert]

lör 2014-07-19 klockan 12:30 +0100 skrev Richard W.M. Jones:
 The first step of most Koji builds is buildSRPMFromSCM, where a
 .src.rpm file is built from the git repo.
 
 Currently this involves completely building a mock buildroot
 containing all the BuildRequires, and running `rpmbuild -bs'.  This
 takes many minutes (especially when arm is chosen as a builder).

The buildroot for the buildSRPMFromSCM step is not even the full default
buildroot for the package build step and it doesn't install the BRs.

On my recent koji builds 'group install srpm-build' results in
Install 10 Packages (+226 Dependent packages) and no additional
packages are installed during the buildSRPMFromSCM step.

For the build step the 'group install build' results in Install 24
Packages (+141 Dependent packages) after which the BRs and their
dependencies are installed.

(These numbers are from rawhide.)

 It seems the reason for this is because the spec file has to be fully
 parsed in order to work out the Source lines.  Since Source lines
 might depend on RPM macros which might depend on any BuildRequire'd
 package, every BR package must be installed in the mock root.
 `rpmbuild -bs' takes seconds because it just bundles all the Source
 files with the spec file into an SRPM.

If there are such lines they will break since the BRs are not installed
during the buildSRPMFromSCM step.

 Is this really necessary?
 
 Two shortcuts seem possible:
 
 (1) Limit the use of macros in Source lines, so that only a simple,
 standard, perhaps pre-cached buildroot can be used.
 
 (2) Perhaps uglier: Just build an SRPM that contains everything in
 dist-git + everything in the lookaside cache, and hope for the best ...
 
 Thoughts?
 
 Rich.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

gsoap updated in rawhide

[Mattias Ellert]

Hi!

The gsoap package in rawhide has been updated to version 2.8.17.

Dependent packages should rebuild.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rawhide report: 20131221 changes - R libraries

[Mattias Ellert]

lör 2013-12-21 klockan 19:30 -0700 skrev Orion Poplawski:
 On 12/21/2013 07:46 AM, Fedora Rawhide Report wrote:
  Compose started at Sat Dec 21 05:15:03 UTC 2013
 
  Broken deps for i386
  --
  [InsightToolkit]
  InsightToolkit-4.4.2-4.fc21.i686 requires libRlapack.so
  InsightToolkit-4.4.2-4.fc21.i686 requires libRblas.so
 
 
 
  R-3.0.2-2.fc21
  --
  * Fri Dec 20 2013 Tom Callaway s...@fedoraproject.org - 3.0.2-2
  - add --with-blas, --enable-lto to configure
 
 This seems to have changed thing library wise.  Intentional?  Time to 
 just rebuild?

I had to add BR on blas-devel and lapack-devel to get R-qtl to build.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: FTBFS if -Werror=format-security flag is used

[Mattias Ellert]

tis 2013-12-10 klockan 12:18 -0500 skrev Darryl L. Pierce:

  Of all the packages I
  maintain, only one was affected by this issue. That one was easily
  solvable by deleting the bundled swig generated code in the sources and
  have the build regenerate it with a newer swig version that doesn't
  produce broken code.
 
 Our project isn't bundling any Swig generated code. It's generated as a
 part of the build process. Try not to make assumptions in future.

Where did I make this assumption? The description of my experience was
supposed to tell something about swig. That older versions had problems
but newer does not. No reflection on your project was intended
whatsoever.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: FTBFS if -Werror=format-security flag is used

[Mattias Ellert]

fre 2013-12-06 klockan 15:06 -0500 skrev Darryl L. Pierce:
 On Fri, Dec 06, 2013 at 02:27:05AM +0100, Kevin Kofler wrote:
  Michael scherer wrote:
   Let's rather ask the contrary, why is this so much a issue to communicate
   with upstream to fix things, and add patches ?
  
  The vast majority of those warnings are actually false positives, not 
  actual 
  security issues. Putting my upstream hat on, if asked to fix such a false 
  positive, I'd do one of:
  (a) close the bug as INVALID/NOTABUG/WONTFIX or
  (b) hardcode -Wno-error=format-security -Wno-format-security in my build 
  setup and close the bug as FIXED.
 
 Additionally, some code (like my package, qpid-cpp) uses code that's
 generated by another app like Swig. We have no control over what that
 code is. So enabling this as an error would be unresolvable by our
 project and we'd be blocked until the Swig team decided to change their
 code generation bits.

Don't use swig as an excuse not to fix things. Of all the packages I
maintain, only one was affected by this issue. That one was easily
solvable by deleting the bundled swig generated code in the sources and
have the build regenerate it with a newer swig version that doesn't
produce broken code.

My other packages once used to have quite a few of these, but since
Debian has had -Werror=format-security as the default for quite some
time now those were already fixed in order to compile on Debian. So
adding this as the default for Fedora now will not nearly be as
disruptive as it was when it was added as a default on Debian. We are
coming late to the game here.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: File conflict when upgrading package

[Mattias Ellert]

sön 2013-11-17 klockan 22:12 +0100 skrev Sandro Mani:
 Upgrading from xflr5-6.09.05-4.fc21.x86_64 to xflr5-6.09.05-5.fc21.x86_64 
 however fails with
 Transaction check error:
 file /usr/share/applications/xflr5.desktop from install of 
 xflr5-6.09.05-5.fc21.x86_64 conflicts with file from
 package xflr5-6.09.05-4.fc21.x86_64

You are replacing a directory with an ordinary file. The requires a
%pretrans script. %pretrans scripts must be written in lua:

%pretrans -p lua
st = posix.stat(%{_datadir}/applications/%{name}.desktop)
if st and st.type == directory then
  os.execute(rm -rf %{_datadir}/applications/%{name}.desktop)
end

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: root rebuild failed after glew update

[Mattias Ellert]

mån 2013-11-18 klockan 04:26 +0100 skrev punto...@libero.it:
 Il 18/11/2013 04:13, David Airlie ha scritto:
  Hi owners,
 
  I tried to rebuild root after glew update, but it failed due to hadoop 
  changes,
 
  Not sure if hadoop needs a build in rawhide for the current f20 build or 
  something else.
 
  Dave.
 hi
 Hadoop has nothing to do with glew ...
 can you please add the part, of the build.log, where fails to compile?
 regards
 gil

Hi!

I have had an update of root in the pipeline for a few weeks. But it has
been postponed waiting for fixes to the hadoop package. Fixing the root
build for the current rawhide hadoop package would be possible, but
those fixes would have to be thrown out once the next hadoop package
update happens, so I currently prefer to wait for the hadoop update.

Mattias
maintainer of root package



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Mattias Ellert]

tor 2013-11-07 klockan 09:14 + skrev Peter Robinson:

 I don't see many people forcing things through, I believe that the
 vast majority of contributors either like the change or aren't
 bothered by it.

Just so that my silence is not counted as approval. I disapprove.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Mattias Ellert]

mån 2013-11-04 klockan 14:58 -0500 skrev Josh Boyer:

 For a large number of upstream projects, they don't care at all about
 being in a distro.  They just focus on their project and someone else
 integrates it into the distro.  Containerized apps are just another
 way to do that.

No, it is another way not to do that.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: A dependency for a noarch package has been removed on an archictecture. How to silent broken dependency mails?

[Mattias Ellert]

ons 2013-09-04 klockan 17:29 +0300 skrev Susi Lehtola:
 On Wed, 04 Sep 2013 08:55:36 -0400
 Stephen Gallagher sgall...@redhat.com wrote:
   I could change perl-Alien-ROOT from noarch to architecture
   specific, but that's cheating and more seriously it just shifts the
   problem in the reverese dependency hierarchy to next level (i.e. I
   would get broken dependency for packages requiring
   perl-Alien-ROOT).
 
 This is a valid approach.
 
   How does Fedora infrastracture deal with this issue?
   
  
  Add the following line to perl-Alien-ROOT's specfile:
  
  
  ExcludeArch: %{arm}
 
 That's not enough, since that'll break upgrades. You'll have to make
 some package on arm obsolete perl-Alien-ROOT.

In this case this is not necessary since perl-Alien-ROOT was never
installable on arm since its missing dependence was never available
there. So there is no installed version that needs to be obsoleted.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: UTF-8 locale in RPM build

[Mattias Ellert]

sön 2013-08-25 klockan 23:13 +0200 skrev punto...@libero.it:
 Il 25/08/2013 22:17, Ian Pilcher ha scritto:
  I'm trying to build a jpackage SRPM (jena-iri) on Fedora 19, and it's
  failing, because the locale (LANG) is apparently set to C during the
  build.  (javac and javadoc don't like non-ASCII characters in source
  files in an ASCII locale.)
 
  What's the best way to set it to a UTF-8?  (Should I just add export
  LANG=en_US.UTF-8 to the relevant sections of the SPEC file?)
 
  Thanks!
 
 hi
 convert the sources code wiith non-ASCII characters with
 native2ascii
 e.g.
 native2ascii -encoding UTF8 A.java A.java
 regards

In almost all cases converting to ascii is not an acceptable solution.
Not only for java source but for any text. Blindly converting java
sources to ascii can introduce bugs, since - unlike C and C++ - you are
allowed to use non-ascii characters in variable names and other
identifiers in java sources. Even if non-ascii characters are only
present in comments, those may end up in the javadoc documentation, so
converting to ascii is likely to introduce documentation bugs.

Better fix the broken build instructions to correctly state what
encoding is used by the project. E.g. by adding

properties

project.build.sourceEncodingUTF-8/project.build.sourceEncoding
/properties

to the pom-file, or add -Dproject.build.sourceEncoding=UTF-8 to the
build on the command line.

Mattias




smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Bundled Flash

[Mattias Ellert]

fre 2013-08-23 klockan 16:46 -0700 skrev Adam Williamson:
 But if
 I'm going to do it, I'd rather get the replace-dir-with-symlink stuff
 'right' (for whatever value we decide is 'right') first time.

The shortest scriptlet I saw to remove a directory in pretrans is:
(see e.g. 
http://pkgs.fedoraproject.org/cgit/mozilla-firetray.git/tree/mozilla-firetray.spec)

%pretrans -p lua
st = posix.stat(path to dir)
if st and st.type == directory then
  os.execute(rm -rf path to dir)
end

But, this sort of cheats a bit since is calls out to system rm, which is
not present on the initial install transaction. On the other hand on the
initial install transaction the directory does not exist and the
os.execute will not be executed. So it is possibly acceptable. Doing
recursive directory removal completely in lua is as already mentioned a
quite long script.

The corresponding scriptlets to remove a symlink or a file do not have
to cheat:

%pretrans -p lua
st = posix.stat(path to link)
if st and st.type == link then
  os.remove(path to link)
end

%pretrans -p lua
st = posix.stat(path to file)
if st and st.type == regular then
  os.remove(path to file)
end

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [EPEL] gimp-paint-studio failed to build on el6

[Mattias Ellert]

tor 2013-08-15 klockan 11:57 -0700 skrev Luya Tshimbalanga:
 Hello,
 I wonder why the build failed[1] despite assigning a quotation on a doc 
 file listed on:
 http://pkgs.fedoraproject.org/cgit/gimp-paint-studio.git/tree/gimp-paint-studio.spec?h=el6
 
 Is there a way to fix that?
 
 Ref
 
 [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=456904
 
 
 Luya

Try:

%doc License?for?Contents License_gpl-2.0.txt Readme.txt

See: http://www.rpm.org/ticket/858

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

License change: xrootd

[Mattias Ellert]

Hi!

The License tag of the xrootd package ha changed from BSD to LGPLv3+ due
to an upstream license change.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Review swaps

[Mattias Ellert]

Hi

I have a few review requests that I would like to arrange swaps for:

3 packages related to particle physics simulation:

https://bugzilla.redhat.com/show_bug.cgi?id=877275
Review Request: lhapdf - Les Houches Accord PDF Interface

https://bugzilla.redhat.com/show_bug.cgi?id=877396
Review Request: HepMC - C++ Event Record for Monte Carlo Generators

https://bugzilla.redhat.com/show_bug.cgi?id=877607
Review Request: pythia8 - Pythia Event Generator for High Energy Physics

2 Globus Toolkit packages (these are simple since they follow the
template used for all Globus toolkit packages):

https://bugzilla.redhat.com/show_bug.cgi?id=889261
Review Request: globus-gram-job-manager-lsf - Globus Toolkit - LSF Job
Manager Support

https://bugzilla.redhat.com/show_bug.cgi?id=889262
Review Request: globus-gridmap-verify-myproxy-callout - Globus Toolkit -
Globus gridmap myproxy callout

2 EMI authentication libraries (Java and C++) - the C implementation is
already available in Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=912681
Review Request: canl-java - EMI Common Authentication library - bindings
for Java

https://bugzilla.redhat.com/show_bug.cgi?id=952229
Review Request: canl-c++ - EMI Common Authentication library - bindings
for C++

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: package, package2, package3 naming-with-version exploit

[Mattias Ellert]

tor 2013-04-04 klockan 17:29 +0200 skrev Vít Ondruch:
 Dne 4.4.2013 16:20, Miloslav Trmač napsal(a):
  esthetics.
 
 
 May be I misunderstood the thread, but wasn't this the main point since 
 the beginning? To prevent the naming-with-version exploit as is still 
 stated in the $SUBJECT?
 
 It might looks like the thread would be named like how to install 
 multiple versions on single package but it was not. Clearly, there are 
 ways. There are even policies in place. The brainstorming was how to do 
 it right, but there is no will. Every steak holder just repeats how to 
 achieve it currently, no how to do it right.

I think you misunderstand here. I think the replies contain the current
way, not because it is the current way, but because those who reply
consider the current way to be the right way. For me the current way
makes sense and I would not like to change it.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

gsoap updated to version 2.8.12 in rawhide

[Mattias Ellert]

Hi!

The gsoap package has been updated to version 2.8.12 in rawhide only.
Dependent packages (gfal, gridsite, lcgdm, lcgdm-dav, srm-ifce, voms)
must rebuild.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20121228 changes

[Mattias Ellert]

ons 2013-01-02 klockan 14:03 +0100 skrev Vít Ondruch:
 Dne 2.1.2013 13:19, Panu Matilainen napsal(a):
  On 01/02/2013 01:53 PM, Vít Ondruch wrote:
  Dne 28.12.2012 15:39, Michael Scherer napsal(a):
  [root]
  root-graf3d-gl-5.34.02-1.fc19.x86_64 requires
  libGLEW.so.1.7()(64bit)
  doesn't even let a srpm be created on F18, and fail on this line :
 
  %if %{?fedora}%{!?fedora:0} = 17 || %{?rhel}%{!?rhel:0} = 7
 
  ( and as a side note, the spec could for sure benefit from some
  cleaning, with conditional checking for fedora 11, or Group tag
  everywhere )
 
 
  This looks like regression in RPM. I am pretty sure this construct
  worked on F17 and not sure why it shouldn't work on F18.
 
  More likely its this regression in fedpkg:
  https://bugzilla.redhat.com/show_bug.cgi?id=876308
 
  - Panu -
 
 Ah, thank you. And Mattias, the root owner, is author of the ticket, so 
 he is probably very well aware of root issues.
 
 Vít

I am very well aware of this fedpkg regression. It makes 40+ of my
packages currently not buildable in F18 and rawhide.

The bug was reported almost 2 month ago, and the fix for the bug was
provided in a bugzilla comment just 3 days after the bug was reported,
but no update implementing the fix has yet been provided. So the build
system remains broken.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Review swaps

[Mattias Ellert]

Hi!

I am looking for reviewers and am willing to make reviews in return.

Three renamed packages due to upstream name changes:

globus-gram-job-manager-fork:
https://bugzilla.redhat.com/show_bug.cgi?id=772986

globus-gram-job-manager-pbs:
https://bugzilla.redhat.com/show_bug.cgi?id=772988

globus-gram-job-manager-sge:
https://bugzilla.redhat.com/show_bug.cgi?id=772989

One package split:

voms-api-java:
https://bugzilla.redhat.com/show_bug.cgi?id=806066

One new package:

jglobus:
https://bugzilla.redhat.com/show_bug.cgi?id=812751

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

gsoap updated in F17 and rawhide

[Mattias Ellert]

Hi!

gsoap was updated to version 2.8.7 in F17 and rawhide.

Due to changes to the struct soap the soname of the libraries was bumped
from 1 to 2. Dependent packages needs to rebuild:

lcgdm
lcgdm-dav
srm-ifce
voms

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Globus Toolkit updated to version 5.2

[Mattias Ellert]

Hi!

The packages containing software from the Globus Toolkit have been
updated to Globus Toolkit version 5.2 in rawhide. The update for Fedora
15 and 16 and EPEL is currently in the testing repo, and buildroot
overrides are also in place for these releases.

Many of the changes implemented by upstream in this release, such as the
removal of the flavour tags in the library names and the support for
standard installation paths, were already present in the Fedora packages
of earlier releases using patches. This update is backwards compatible
and does not introduce any soname bumps.

The most important change is the handling of threads. In earlier
releases the threading model was chosen at compilation time, and the
model used by the libraries in Fedora and EPEL was using pthreads. In
this release the threading model is instead chosen at runtime, either by
using API calls or by setting environment variables. The default model
in the new release is the forking model, but also the pthread model is
available.

In order to preserve the behaviour of applications linked to previous
versions, versioned symbols have been introduced so that the new
libraries will switch to the pthread threading model automatically when
used by applications that were linked to earlier versions.

Upstream's release notes are available here:
http://www.globus.org/toolkit/docs/5.2/5.2.0/rn/

If you want to help completing the update to GT 5.2 there are 4 rename
reviews and 3 reviews for new packages that need a reviewer.

Rename reviews:

globus-gram-job-manager-fork:
https://bugzilla.redhat.com/show_bug.cgi?id=772986
globus-gram-job-manager-condor:
https://bugzilla.redhat.com/show_bug.cgi?id=772987
globus-gram-job-manager-pbs:
https://bugzilla.redhat.com/show_bug.cgi?id=772988
globus-gram-job-manager-sge:
https://bugzilla.redhat.com/show_bug.cgi?id=772989

New package reviews:

globus-gram-audit:
https://bugzilla.redhat.com/show_bug.cgi?id=772993
globus-simple-ca:
https://bugzilla.redhat.com/show_bug.cgi?id=772994
globus-xioperf
https://bugzilla.redhat.com/show_bug.cgi?id=772995

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Owning /usr/share/icons/hicolor

[Mattias Ellert]

mån 2011-10-31 klockan 19:02 +0100 skrev Till Maas:
 On Mon, Oct 31, 2011 at 11:42:59AM -0600, Jerry James wrote:
 
  Are the fedora-logos and setroubleshoot packages doing it the right
  way, and other icon-installing packages need to be fixed?  Are they
  doing it the wrong way, and should be fixed themselves?  Does
  ownership of that directory depend on some other feature of the
  package?
 
 I guess the directory /usr/share/icons/hicolor and the usual
 subdirectories should be owned by the filesystem package.
 
 Regards
 Till

hicolor-icon-theme is a filesystem package. Apart from a README, a
COPYING, a Changelog and one %ghost it contains one (1) file.

And 340 directories.

This is the filesystem package that packages that install icons are
supposed to depend on.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

gsoap updated in rawhide

[Mattias Ellert]

Hi!

The gsoap package has been updated to version 2.8.4 in rawhide only.

Depending packages should rebuild:

 - CGSI-gSOAP
 - lcgdm
 - voms
 - VirtualBox-OSE (rpmfusion)

Mattias Ellert
gsoap co-maintainer



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

gsoap updated to version 2.8.3 in rawhide and F16

[Mattias Ellert]

Hi!

The gsoap package has been updated to version 2.8.3 in rawhide and F16.

Dependent packages should be rebuilt. A buildroot override is currently
in effect in F16.

According to repoquery the following packages have requires or
build-requires on gsoap(-devel):

 * CGSI-gSOAP
 * lcgdm
 * voms
 * VirtualBox-OSE

The first three are maintained by me and updates have already been
created.

VirtualBox-OSE is from rpmfusion. the maintainer is CC on this mail.

Regards,

Mattias Ellert
gsoap co-maintainer



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Oh god, my eyes (packaging a hairball of bundled PHP stuff, tt-rss)

[Mattias Ellert]

ons 2011-08-31 klockan 10:17 +0300 skrev Yanko Kaneti:

 # repoquery -f '*/jquery*.js' --qf=%{NAME}\n | sort | uniq | wc -l
 356
 
 jQuery FTW :)

Most of these are probably doxygen generated documentation. Recent
versions of doxygen provides a search option for the generated html
documentation and a copy of jquery.js.

At the moment jquery is not package as a separate package. If it was
packagers could replace them with a symlink to that.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora rawhide FTBFS status 2011-06-16 x86_64

[Mattias Ellert]

ons 2011-06-22 klockan 19:17 -0500 skrev Matt Domsch:
 Fedora Fails To Build From Source Results for x86_64
 using rawhide from 2011-06-16
 
 Good hunting!


 lcgdm-1.8.0.1-7.fc16 (build/make) ellert,stevetraylen

This is already resolved (by an update of CGSI-gSOAP). The package built
fine on 2011-06-20 in koji during the perl mass rebuild:

https://koji.fedoraproject.org/koji/buildinfo?buildID=248860


 root-5.28.00d-1.fc16 (build/make) ellert,stevetraylen

This needs the update of lcgdm above to be in the buildroot in order to
build. That build is not in rawhide yet, only in dist-f16-perl.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: patch only if dependent version x? (rpm spec)

[Mattias Ellert]

fre 2011-06-03 klockan 07:19 -0400 skrev Neal Becker:
  
 
 So it is ultimately conditioned on fedora version, not foo-devel version.
 
 OK.
 
 It seems more direct to condition on foo-devel version.  Is that 
 unreasonable?  
 Or just too difficult?

You can do it on the version of the software. If it has a pkg-config
file you can do something like this (taken from an existing specfile in
Fedora):

%prep
%setup -q
%if %(pkg-config --max-version 2.1.2 ftgl 2/dev/null  echo 1 || echo 0)
%patch0 -p1
%endif
%patch1 -p1
%patch2 -p1
%patch3 -p1
%patch4 -p1
%patch5 -p1

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: mass rebuild of mysql packages in F-15

[Mattias Ellert]

ons 2011-03-23 klockan 12:11 -0400 skrev Marcela Maslanova:
 Because many packages in F-15 have broken dependencies there will be needed 
 mass rebuild.
 
 dhorak will build these, which are not rebuild yet. After that will be created
 one big update, so please don't file your own updates into bodhi.
 
 List of all dependent packages:

I have rebuilt my two remaining packages so you do not need to do them
again:

 lcgdm
 voms-mysql-plugin

This one I had already done before:

 List of already built packages:
 root-5.28.00b-2.fc15  dist-f15-mysqlellert

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

gsoap updated to 2.7.17 in F15 and rawhide

[Mattias Ellert]

Hi!

The gsoap package has been updated to version 2.7.17 in F15 and rawhide.

This update also turns on the IPv6 support in the provided gsoap
libraries. Due to the IPv6 support dependent packages need to be
rebuilt.

According to repoquery the following packages are affected:

  condor
  lcgdm
  VirtualBox-OSE (this one is from rpmfusion)

If compilations are using pkg-config --cflags gsoap to get the
compiler flags just doing a rebuild should be enough. Otherwise the
-DWITH_IPV6 needs to be added in some other way when compiling sources
that includes stdsoap2.h.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: gsoap updated to 2.7.17 in F15 and rawhide

[Mattias Ellert]

mån 2011-02-14 klockan 13:12 +0100 skrev Mattias Ellert:
 Hi!
 
 The gsoap package has been updated to version 2.7.17 in F15 and rawhide.

PS. I have requested a buildroot override in F15.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: New fedpkg build coming to an update repo near you!

[Mattias Ellert]

fre 2010-08-27 klockan 08:31 -0700 skrev Jesse Keating:
 
 Mattias Ellert mattias.ell...@fysast.uu.se wrote:
 
 tor 2010-08-26 klockan 13:27 -0700 skrev Jesse Keating:
  
  Matej Cepl mc...@redhat.com wrote:
  
  Jesse Keating, Mon, 23 Aug 2010 23:44:34 -0700:
   I just submitted updates for el5 and f1{2,3,4} as well as a build for
   rawhide (f15) of a new fedpkg build.  Here is a summary from the rpm:
  
  EL6?
  
  A build, and a later build, was done for el6.
 
 And el4?
 
 
 
 El4 is too old for proper fedpkg. For el4 we just have a stub that handles 
 the sources command used in koji. 

I am aware of that - it is just that this stub is broken if the sources
file contains more than one file:

https://bugzilla.redhat.com/show_bug.cgi?id=622605

(There is an updated stub attached to the bugzilla report.)

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: New fedpkg build coming to an update repo near you!

[Mattias Ellert]

tor 2010-08-26 klockan 13:27 -0700 skrev Jesse Keating:
 
 Matej Cepl mc...@redhat.com wrote:
 
 Jesse Keating, Mon, 23 Aug 2010 23:44:34 -0700:
  I just submitted updates for el5 and f1{2,3,4} as well as a build for
  rawhide (f15) of a new fedpkg build.  Here is a summary from the rpm:
 
 EL6?
 
 A build, and a later build, was done for el6.

And el4?

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Naming issue for meego 1.0 related packages

[Mattias Ellert]

fre 2010-07-16 klockan 18:26 +0800 skrev Chen Lei:

 I think using git repo for meego packages have more
 harm than benefit, because the most important feature for rpm is
 people can validate the md5sum of the source tarball easily. Unless
 special case we can't find a way to get reliable souce tarballs, I
 think it's better to use tarballs rather than get source files from
 VCS.

This is not a valid argument. The guidelines specify how to document in
the specfile how to reproduce a source tarball created from VCS. The
reviewer in order to verify the source recreates the source using the
given specification and compares his created copy with the one in the
SRPM. I agree that this comparison would normally have to be done using
diff -r rather than md5sum due to timestamps of directories and
differences in user and group assignments of the checked out files, but
the verification is still possible and valid.

A checkout used in a SRPM should of course be done by giving a tag,
revision or timestamp so that it can be reproduced at any later time.
Using head/trunk/master without any such specification is not
reproducible.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Licensing Guidelines Update - Please Read

[Mattias Ellert]

ons 2010-07-07 klockan 16:29 -0400 skrev Tom spot Callaway:
 Okay. Here's the list of packages that I think might be affected by
 this. Reminder: You need to check these packages and fix any which need
 fixing, then email me and let me know which ones you checked/fixed.
 Thanks!
 
 ~spot
 
 [ellert] dcap: dcap-libs-2.47.2-2.fc14.x86_64
False positive - it is the other way around: the license file is in
dcap-libs and dcap depends on dcap-libs.

 [ellert] voms: voms-doc-1.9.17.1-1.fc14.noarch
Fixed in F12, F13, EPEL4 and EPEL5.
The rawhide build is currently blocked by
https://bugzilla.redhat.com/show_bug.cgi?id=611781
The EPEL6 build can not be done yet due to missing build deps.

 vomsjapi-1.9.17.1-1.fc14.x86_64
False positive - this package already has its own copy of the license
file.

 [ellert] xrootd: xrootd-libs-20100315-2.fc14.x86_64
 xrootd-doc-20100315-2.fc14.noarch
False positives: upstream source does not contain a license file.
Guidelines state packager should not create one.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel