Re: Singular soname bump and a review swap

[Paulo César Pereira de Andrade]

Em sex., 11 de mar. de 2022 às 18:42, Jerry James
 escreveu:
>
> HI Paulo,

  Hi Jerry,

> It's great to hear from you.  I hope you are well.

  Sorry for again taking a bit long to respond :( I have sagemath 9.5 built
locally for almost a month, but I will not interfere with your work right
now, and it is only in a somewhat hackish mode, it just builds :)

> On Wed, Mar 9, 2022 at 4:42 AM Paulo César Pereira de Andrade
>  wrote:
> >   If nobody takes it, I can review.
>
> Ankur took it already.  On the other hand, he doesn't seem to have
> actually started the review yet...
>
> >   I was about to ask for a review as well, as I have my own version locally 
> > :)
>
> Ah, sorry, didn't mean to duplicate effort.
>
> >   Did not double check if already done, but will need to change L-function 
> > to
> > use the sage spkg as upstream is no longer available. This will also need a
> > library major downgrade. But only sagemath uses it, so not a major issue.
> > Optionally, could work on renaming  the L-function package to lcalc, to 
> > match
> > what it is being called in the past 6+ years...
>
> Yes, that's on the list.  This is what I had lined up to do next week
> sometime, after the python-primecountpy review is completed.
>
> - Update L-function to 2.0.5.  I did not notice that this changes the
> L-function soname downwards.  Ugh.  Still, as you say, that should be
> okay since sagemath is the only consumer.  I had added a comment at
> the top of the spec file noting that we should rename it "lcalc". :-)
> - Update python-cysignals to 1.11.2
> - Update Singular to 4.2.1p3
> - Update sympy to 1.10
> - Add python-primecountpy 0.1.0
> - Rebuild polymake due to the Singular update
> - Rebuild python-pysingular due to the Singular update
> - Update sagemath to 9.5
> - Retire pynac, which has been absorbed into sagemath
>
> Is there any of that you would prefer to do yourself?  I don't want to
> step on your toes at all.  Or if you would like to see the changes I'm
> planning to make to any of those packages, I'm happy to share the spec
> files and relevant patches with you.

  Feel free to send me a message if you want me to do some of
the tasks, otherwise you can do the full update.

> And then I'm going back to trying to retire from tending mathematical
> packages in Fedora.  If you want any of the packages I currently
> maintain, let me know and I will transfer them to you.  Regards,

  Sure, no problems :)

> --
> Jerry James
> http://www.jamezone.org/

Thanks!
Paulo
___
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: Singular soname bump and a review swap

[Paulo César Pereira de Andrade]

Em seg., 7 de mar. de 2022 às 18:22, Jerry James
 escreveu:
>
> As you all know by now, I'm trying to retire as steward of the
> sagemath and Macaulay2 stacks.  Nevertheless, after some impassioned

  Many thanks for your work maintaining sagemath!

> pleas from a couple of sagemath users, I have prepared an update for
> sagemath 9.5.  This will require an update to Singular 4.2.1p3, which
> comes with an soname bump.
>
> Sagemath 9.5 has spun the primecount interface out into a separate
> package.  This means that I need to *add* one package to the set I am
> trying to give away so that I can keep claiming that the packages are
> in good shape.  Is anyone interested in a review swap?  I need this
> one:
>
> python-primecountpy:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2061570
>
> The updates will be done sometime next week, after that review is complete.

  If nobody takes it, I can review.

  I was about to ask for a review as well, as I have my own version locally :)

  Did not double check if already done, but will need to change L-function to
use the sage spkg as upstream is no longer available. This will also need a
library major downgrade. But only sagemath uses it, so not a major issue.
Optionally, could work on renaming  the L-function package to lcalc, to match
what it is being called in the past 6+ years...

> --
> Jerry James
> http://www.jamezone.org/

Thanks!
Paulo
___
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: Suggestion for Fedora change proposal: -Bsymbolic-functions default in LDFLAGS

[Paulo César Pereira de Andrade]

Em qua., 4 de dez. de 2019 às 10:16, Tom Hughes  escreveu:
>
> On 04/12/2019 12:58, Paulo César Pereira de Andrade wrote:
>
> >Idea about @subject started with ongoing customer support case that
> > originated https://bugzilla.redhat.com/show_bug.cgi?id=1778236
> > [Problems linking to zlib corrected if zlib is linked with 
> > -Bsymbolic-functions]
> > when doing some research, it appears Ubuntu has it by default for
> > some time.
> >
> >This is currently only a suggestion and/or request for comments.
> > Some extra detail in https://bugzilla.redhat.com/show_bug.cgi?id=1778234
> > [Request For Comments: -Bsymbolic-functions in LDFLAGS by default]
> >
> >Basically, there would be a few issues, most times in broken code,
> > and the valid cases could be worked around removing -Bsymbolic-functions.
> >
> >The biggest advantages are far less relocations, for example, that
> > should mean faster load time, and avoids several issues with symbols
> > being clobbered by symbols from another library.
>
> If I understand correctly then it will also mean that LD_PRELOAD will
> not work for any call made from the library to itself, but would still
> work for calls made from other libraries.

  Not fool proof checked, but I believe this is what would happen. Usually
one wants to only LD_PRELOAD to replace some glibc symbol, for some kind
of debug, but any library where there valid usages of LD_PRELOAD should
not be linked with -Bdynamic-functions.

> Tom
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/

Thanks,
Paulo
___
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: Suggestion for Fedora change proposal: -Bsymbolic-functions default in LDFLAGS

[Paulo César Pereira de Andrade]

Em qua., 4 de dez. de 2019 às 10:11, Igor Gnatenko
 escreveu:
>
> Do you have some benchmark results and/or some statistics related to
> the file size?

  Mostly a guess it should load faster. With 'readelf -r', standard
libz.so.1 in rhel7 shows 46 relocations, and with -Bdynamic-functions
it shows 17 relocations.

  This email is more of a heads up, starting from the customer case
with issues with zlib. Zlib also has problems, at least in rhel7, that
it does not have some symbols versioned, and if there is another symbol
with the same name, it will pick the wrong symbol (at least in the
customer environment).

> On Wed, Dec 4, 2019 at 2:09 PM Paulo César Pereira de Andrade
>  wrote:
> >
> >   Hi,
> >
> >   Idea about @subject started with ongoing customer support case that
> > originated https://bugzilla.redhat.com/show_bug.cgi?id=1778236
> > [Problems linking to zlib corrected if zlib is linked with 
> > -Bsymbolic-functions]
> > when doing some research, it appears Ubuntu has it by default for
> > some time.
> >
> >   This is currently only a suggestion and/or request for comments.
> > Some extra detail in https://bugzilla.redhat.com/show_bug.cgi?id=1778234
> > [Request For Comments: -Bsymbolic-functions in LDFLAGS by default]
> >
> >   Basically, there would be a few issues, most times in broken code,
> > and the valid cases could be worked around removing -Bsymbolic-functions.
> >
> >   The biggest advantages are far less relocations, for example, that
> > should mean faster load time, and avoids several issues with symbols
> > being clobbered by symbols from another library.
> >
> > Thanks!
> > Paulo
> > ___
> > 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
___
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

Suggestion for Fedora change proposal: -Bsymbolic-functions default in LDFLAGS

[Paulo César Pereira de Andrade]

  Hi,

  Idea about @subject started with ongoing customer support case that
originated https://bugzilla.redhat.com/show_bug.cgi?id=1778236
[Problems linking to zlib corrected if zlib is linked with -Bsymbolic-functions]
when doing some research, it appears Ubuntu has it by default for
some time.

  This is currently only a suggestion and/or request for comments.
Some extra detail in https://bugzilla.redhat.com/show_bug.cgi?id=1778234
[Request For Comments: -Bsymbolic-functions in LDFLAGS by default]

  Basically, there would be a few issues, most times in broken code,
and the valid cases could be worked around removing -Bsymbolic-functions.

  The biggest advantages are far less relocations, for example, that
should mean faster load time, and avoids several issues with symbols
being clobbered by symbols from another library.

Thanks!
Paulo
___
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: Could not execute import_srpm

[Paulo César Pereira de Andrade]

Em seg, 8 de abr de 2019 às 10:09, Antonio Trande
 escreveu:
>
> Hi all.

  Hi,

  Just a guess that it was the same issue as for me a few days ago. But it might
be something else, like an offline server for some reason.

  I did not do much work on Fedora for some time, then, when uploading
a new source I was getting all kinds of errors.
   Eventually fixing some .rpmsav andor .rpmorig files, plus using
rdns = false
in /etc/krb5.conf fixed the issue.
  For other possible issues check
https://fedoraproject.org/wiki/Infrastructure/Kerberos

> I can't upload source archive of new package 'smoldyn'
>
> $ fedpkg import ../../smoldyn-2.58-1.fc29.src.rpm
> Uploading: /home/sagitter/rpmbuild/SRPMS/fedora-scm/smoldyn/smoldyn-2.58.tgz
> 
> 100.0%
> Could not execute import_srpm: Fail to upload files. Server returns
> status 408
>
>
> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x6e0331dd1699e4d7
> GPG key server: https://keys.fedoraproject.org/

Thanks,
Paulo
___
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: What to do about sagemath

[Paulo César Pereira de Andrade]

%buEm ter, 16 de out de 2018 às 15:05, Miro Hrončok
 escreveu:
>
> On 16.10.2018 19:17, Jerry James wrote:
> > On Tue, Oct 16, 2018 at 9:51 AM Jerry James  wrote:
> >> Sadly, no.
> >
> > Here is the challenge, Python aficionados.  The attached file,
> > test.pyx, can be processed like this on Fedora 28 with Cython 0.28.4:
> > "cythonize -3 test.pyx".  That succeeds and generates code that Does
> > The Right Thing.
> >
> > On Rawhide with Cython 0.29rc2, that fails as noted earlier in this
> > thread.  The name PyLongObject cannot be imported with cimport.  How
> > does the code need to change to compute the same result?
>
> This compiles for me:
>
> from cpython.longintrepr cimport PyLong_SHIFT, py_long, digit
> ...
> cdef const digit* D = (x).ob_digit

  I am afraid I did not help with sagemath for quite some time, and
would really like to
thank Jerry for keeping working on it.
  The big problem with sagemath is that they gave up on having patches
accepted by
several different upstream projects long ago. After giving up on
getting patches everywhere,
they eventually started adding all kinds of patches to lots of
packages, and one might even
need their version of gcc/g++ to build.
  At some point it was required to build a custom cython in the
buildroot, and use it. Currently
there is the cython_hack bcond. The problem of using a custom cython
in the buildroot is
that a minor set of functionality would be lost after install due to
incompatible cython.
  I am afraid I would suggest temporarily adding a '%bcond_without
bundled_cython',
and using a custom cython build *until* a compatible cython is
available in rawhide/
otherwise, it breaks in a way that would be way too complex to recover from :(

  I am still around, just that could not get back on having enough
free time for volunteer
work in Fedora for several months in a row :( But I hope it will change soon.

Thanks!
Paulo
___
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: Tagging large packages (texlive) takes a very long time

[Paulo César Pereira de Andrade]

2017-11-16 16:49 GMT-05:00 Tom Callaway :
> On 11/16/2017 11:03 AM, Kevin Fenzi wrote:
>> I'm not sure what more we can do...
>
> While not solving this immediate problem, I am working on redoing the
> texlive package to make it less evil, in my spare cycles.

  Maybe now there is a possibility of having a texlive/repository-module ?
Somewhat similar to what is descrived at
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/S56BRPTB2KYYQNMIW7RA5LPPZLEBHD6K/
The problem is maintaining 1.5k+ packages, and creating such number
o individual packages, and every time an update is done (assuming 1
month+), need to remove like 5+ and add new 5+.

  Anyway in the Fedora way :), should split binaries in one package, and
have multiple texlive-collection-* packages (-scheme probably would not
work, so, need to be virtual packages).

> ~tom

Thanks,
Paulo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Need help from someone with experience with %pom_ macros

[Paulo César Pereira de Andrade]

2017-11-14 11:30 GMT-05:00 Mikolaj Izdebski <mizde...@redhat.com>:
> On 11/14/2017 02:58 PM, Paulo César Pereira de Andrade wrote:
>>   Hi,
>>
>>   If you have a spare time, and can do a quick test I would really
>> appreciate.
>>
>>   I only know some basic heuristics based on build errors...
>>
>>   Test should be:
>>
>> $ fedpkg co jacop; cd jacop; fedpkg local
>>
>>   I thought it could be related to scala, but it fails with either current
>> scala, or a rebuild wth patch at
>> https://bugzilla.redhat.com/show_bug.cgi?id=1512883
>>
>> error is:
>>
>> [ERROR] UndeclaredThrowableException: InvocationTargetException:
>> Plugin org.codehaus.mojo:javacc-maven-plugin:2.6 or one of its
>> dependencies could not be resolved: Cannot access scala
>> (http://scala-tools.org/repo-releases/) in offline mode and the
>> artifact com.google.inject:guice:jar:no_aop:4.0 has not been
>> downloaded from it before.
>
> I can't reproduce this.  On rawhide I'm getting compilation errors instead.

  Many thanks. I was just trying to fix it hacking pom_ macros, but on my
rawhide computer. Something is bogus, besides apparently all ok, I am
running rawhide for more than 3 years...

  Based on your response it was clear something was bogus, so, just
created a new mock rawhide chroot, noticed there were two missing
build requires:

'''
$ git diff
diff --git a/jacop.spec b/jacop.spec
index 3effe0e..cf593d1 100644
--- a/jacop.spec
+++ b/jacop.spec
@@ -14,11 +14,14 @@ BuildRequires:  apache-commons-jexl
 BuildRequires: java-devel
 BuildRequires: javacc-maven-plugin
 BuildRequires: maven-local
+BuildRequires: maven-plugin-build-helper
 BuildRequires: maven-plugin-bundle
+BuildRequires: maven-source-plugin
 BuildRequires: scala
 BuildRequires: slf4j-log4j12
 Requires:  javapackages-tools
 BuildArch: noarch
+Patch0:%{name}-privilege.patch

 %description
 Java Constraint Programming solver, JaCoP in short, is an open-source Java
@@ -37,6 +40,7 @@ This package contains the API documentation for %{name}.

 %prep
 %setup -q -n %{name}-%{commit}
+%patch0 -p0
 %pom_remove_plugin "org.scala-tools:maven-scala-plugin" pom.xml
 %pom_remove_dep "org.perf4j" pom.xml
 %pom_change_dep commons-jexl: org.apache.commons:
'''

and this patch corrects the build errors:
'''
diff -up src/main/java/org/jacop/fz/SimpleNode.java.orig
src/main/java/org/jacop/fz/SimpleNode.java
--- src/main/java/org/jacop/fz/SimpleNode.java.orig2017-11-14
09:22:26.471948651 -0500
+++ src/main/java/org/jacop/fz/SimpleNode.java2017-11-14
09:22:31.760948854 -0500
@@ -75,7 +75,7 @@ class SimpleNode implements Node {
 }
   }

-int getId() {
+public int getId() {
 return id;
 }

'''

> In general, for questions like this one I recommend asking on Java SIG
> IRC channel [1].
>
> [1] https://fedoraproject.org/wiki/SIGs/Java#IRC_Channel
>
>
> --
> Mikolaj Izdebski
> Software Engineer, Red Hat
> IRC: mizdebsk

Sorry for the noise :(
Thanks!
Paulo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Need help from someone with experience with %pom_ macros

[Paulo César Pereira de Andrade]

  Hi,

  If you have a spare time, and can do a quick test I would really
appreciate.

  I only know some basic heuristics based on build errors...

  Test should be:

$ fedpkg co jacop; cd jacop; fedpkg local

  I thought it could be related to scala, but it fails with either current
scala, or a rebuild wth patch at
https://bugzilla.redhat.com/show_bug.cgi?id=1512883

error is:

[ERROR] UndeclaredThrowableException: InvocationTargetException:
Plugin org.codehaus.mojo:javacc-maven-plugin:2.6 or one of its
dependencies could not be resolved: Cannot access scala
(http://scala-tools.org/repo-releases/) in offline mode and the
artifact com.google.inject:guice:jar:no_aop:4.0 has not been
downloaded from it before.

Thanks,
Paulo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tagging large packages (texlive) takes a very long time

[Paulo César Pereira de Andrade]

2017-11-13 10:53 GMT-05:00 Kevin Fenzi :
> On 11/13/2017 01:02 AM, Richard W.M. Jones wrote:
>> It looks as if the texlive saga continues!
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=23085154
>>
>> Started yesterday evening and still going 15 hours later.
>> It has picked an armv7 host this time.
>
> I canceled and started a new one.
>
> It wasn't done this morning, and we looked and it turns out we are
> hitting a bug in koji where it's seeing duplicate NVR's for some
> subpackages from the partially imported build, but not failing correctly.
>
> Kalev has started a new one with subpackages bumped properly.
>
> We have hopes for this build. ;)

  Can you share the link for the build job? So people can watch it :)

  I have been trying since last Friday to build sagemath, and always
fails due to armv7hl texlive:

DEBUG util.py:439:  Error:
DEBUG util.py:439:   Problem 1: package
texlive-scheme-basic-6:svn25923.0-36.20160520.fc28.7.noarch requires
texlive-collection-basic, but none of the providers can be installed
DEBUG util.py:439:- package
texlive-collection-basic-6:svn41149-36.20160520.fc28.7.noarch requires
dvipdfmx, but none of the providers can be installed
DEBUG util.py:439:- package
texlive-6:2016-36.20160520.fc28.7.armv7hl requires
texlive-scheme-basic, but none of the providers can be installed
DEBUG util.py:439:- package
texlive-dvipdfmx-bin-6:svn40273-36.20160520.fc28.7.armv7hl requires
texlive-xetex-bin, but none of the providers can be installed
DEBUG util.py:439:- conflicting requests
DEBUG util.py:439:- nothing provides libpoppler.so.71 needed by
texlive-xetex-bin-6:svn41091-36.20160520.fc28.7.armv7hl
DEBUG util.py:439:   Problem 2: package
R-core-devel-3.4.2-2.fc28.armv7hl requires texinfo-tex, but none of
the providers can be installed
DEBUG util.py:439:- package texinfo-tex-6.5-1.fc28.armv7hl
requires tex(tex), but none of the providers can be installed
DEBUG util.py:439:- package R-devel-3.4.2-2.fc28.armv7hl requires
R-core-devel = 3.4.2-2.fc28, but none of the providers can be
installed
DEBUG util.py:439:- package
texlive-collection-basic-6:svn41149-36.20160520.fc28.7.noarch requires
dvipdfmx, but none of the providers can be installed
DEBUG util.py:439:- package R-3.4.2-2.fc28.armv7hl requires
R-devel = 3.4.2-2.fc28, but none of the providers can be installed
DEBUG util.py:439:- package
texlive-dvipdfmx-bin-6:svn40273-36.20160520.fc28.7.armv7hl requires
texlive-xetex-bin, but none of the providers can be installed
DEBUG util.py:439:- conflicting requests
DEBUG util.py:439:- nothing provides libpoppler.so.71 needed by
texlive-xetex-bin-6:svn41091-36.20160520.fc28.7.armv7hl
DEBUG util.py:439:   Problem 3: package
texlive-collection-latexrecommended-6:svn35765.0-36.20160520.fc28.7.noarch
requires texlive-collection-latex, but none of the providers can be
installed
DEBUG util.py:439:- package R-core-3.4.2-2.fc28.armv7hl requires
tex(latex), but none of the providers can be installed
DEBUG util.py:439:- package
texlive-collection-latex-6:svn41011-36.20160520.fc28.7.noarch requires
texlive-collection-basic, but none of the providers can be installed
DEBUG util.py:439:- package python3-rpy-2.9.0-1.fc28.armv7hl
requires libR.so, but none of the providers can be installed
DEBUG util.py:439:- package
texlive-collection-basic-6:svn41149-36.20160520.fc28.7.noarch requires
dvipdfmx, but none of the providers can be installed
DEBUG util.py:439:- package rpy-2.9.0-1.fc28.armv7hl requires
python3-rpy = 2.9.0-1.fc28, but none of the providers can be installed
DEBUG util.py:439:- package
texlive-dvipdfmx-bin-6:svn40273-36.20160520.fc28.7.armv7hl requires
texlive-xetex-bin, but none of the providers can be installed
DEBUG util.py:439:- conflicting requests
DEBUG util.py:439:- nothing provides libpoppler.so.71 needed by
texlive-xetex-bin-6:svn41091-36.20160520.fc28.7.armv7hl

> kevin
>

Thanks,
Paulo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

review-swap: python-cypari2

[Paulo César Pereira de Andrade]

  python-cypari2 - A Python interface to the number theory library pari
  https://bugzilla.redhat.com/show_bug.cgi?id=1511554

  This package is basically previous sagemath pari interfaces, no
as a standalone package.
  It is required to update to sagemath 8.0

Thanks,
Paulo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Review swaps

[Paulo César Pereira de Andrade]

  Hi,
  I have two packages that need review for a
sagemath 7.6 update:

https://bugzilla.redhat.com/show_bug.cgi?id=1445411
[Review Request: python-cysignals - Interrupt and signal handling for Cython]

https://bugzilla.redhat.com/show_bug.cgi?id=1445412
[Review Request: python-fpylll - A Python wrapper for fplll]

python-fpylll needs python-cysignals, so, to review both,
one possible option is:

$ mkdir cysignals
$ cp python*-cysignals*.rpm cysignals
$ createrepo cysignals/
$ fedora-review -r -n python-fpylll -L cysignals

Thanks,
Paulo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Review swaps

[Paulo César Pereira de Andrade]

  I have two packages for review. These should be very
simple reviews.

python-pathlib2: https://bugzilla.redhat.com/show_bug.cgi?id=1406962
python-ipykernel: https://bugzilla.redhat.com/show_bug.cgi?id=1406958

Thanks,
Paulo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Someone needs to stop texlive madness!!!

[Paulo César Pereira de Andrade]

2016-10-15 14:39 GMT-03:00 Kevin Fenzi :
> On Fri, 14 Oct 2016 17:33:00 +0100

>> If it is true .. maybe can someone help me to understand intention
>> packaging texlive like it is now?
>
> I can try and provide history here. ;)
> Disclaimer: This is just what I remember, it could be wrong.
>
> Texlive is unique. It's very handy and used, especially in the
> publishing and educational areas, so it's important to provide it in
> Fedora.

  There is a way to package texlive in small packages, using
few resources, etc. But you need to create like 3k packages
to bootstrap, the *really* hard part, then, create and retire like
2 to 8 per month.

> There's a number of similarities between texlive and perl's cpan or
> pythons pypy. It's a large collection of smaller packages that work
> with each other. However, it also has at least one big difference from
> those other collections: They do (about) yearly releases of the entire
> collection because it's very interrelated. Also, perl and python
> communities grew up around their packaging, so there's a large number
> of people packaging projects up as they are added. Texlive started as a
> free fork of tetex, so it appeared with tons and tons of packages and
> no community to package each little part up.

  Thats the big problem, or maybe an advantage if mapping rpm
meta packages to texlive meta packages.

> Long ago when texlive was replacing tetex, the first thing that had to
> happen was a legal review of all texlive. This took years and lots of
> people. Once that was done it got an exception to come in as one source
> package and lots of subpackages for all the reasons above. The orig
> maintainer had a program that generated the spec file, but they have
> long since moved on. Tom has taken over updating it recently and has
> done a lot to improve the spec. Yes, there have been bugs or issues,
> but sometimes thats the nature of things.
>
> So far this year:
> Added lines: 49387 Removed lines: 270572 Total # of lines: -221185
>
> So, Tom has removed 221k lines from there. I think thats a pretty good
> tally of improvement.
>
> So, focusing on positive actions here:
>
> * Perhaps we could split things up a little. I have often wondered if
>   just splitting things in 5-10 packages could help, but I would
>   absolutely defer to Tom here since he's been doing the work and he
>   was my sponsor 10 years ago and knows more about packaging than I
>   ever could.
>
> * If you have specific ideas for improvements, do file bugs and attach
>   your patches or explain what you think would help. I'm sure he would
>   love to hear it.
>
> Further than that I would wait for Tom to chime in...

  I talked a bit about at some point in the past, but I am currently
not very active contributing to openmandriva, where I did make a
1 to 1 rpm to texlive package, extraced %post scriptlets from
texlive installer, etc.

https://lists.fedoraproject.org/pipermail/devel/2015-March/209458.html

  The post script was a bit weird tough, it did run in background,
wait 15 secs, if some new texlive package was installed, wait
more 15 secs, and so on, and then, in background do the
update:

https://abf.rosalinux.ru/openmandriva/texlive-tlpkg/blob/master/texlive.post

  I even wrote a graphics texlive tool to install new packages or
update texlive:

https://abf.rosalinux.ru/openmandriva/texlive-tlpkg/blob/master/tlmgr
that would use Mandriva urpm for actually managing the packages,
and look like this screenshot...
https://www.tug.org/texlive/doc/texlive-en/texlive-en.html#tlmgr

  The above might look like some self-promotion, maybe it is :)
but just to give an idea of a possible approach to handle it
differently.

Thanks,
Paulo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: review-swap: brial

[Paulo César Pereira de Andrade]

2016-08-16 12:49 GMT-04:00 Jerry James :
> On Tue, Aug 16, 2016 at 10:30 AM, gil  wrote:
>> can you provides the bug's url?
>> thanks in advance
>> regards
>> .g
>
> Oh, sorry gil.  I didn't mean to steal that from you.  Can you post
> your list of packages that need reviews?  Maybe I can get to some over
> the next few days.

  Ops. sorry for forgeting the link:
https://bugzilla.redhat.com/show_bug.cgi?id=1367526

> --
> Jerry James
> http://www.jamezone.org/

Thanks,
Paulo
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

review-swap: brial

[Paulo César Pereira de Andrade]

  This package is required for an update to sagemath 7.3.

  Brial is a replacement to PolyBori, and needs a bundled significantly
different Cudd, so, cannot use the system one.

  It has only one conflict, brial-devel conflicts with polybori-devel.

  Newer sagemath will use it, so polybori is likely to get orphaned
at some point:

$ dnf repoquery --whatrequires 'libpolybori-0.8.so.3()(64bit)'
Last metadata expiration check: 2:32:10 ago on Tue Aug 16 06:45:26 2016.
polybori-devel-0:0.8.3-36.fc25.x86_64
python-polybori-0:0.8.3-36.fc25.x86_64
sagemath-core-0:6.8-13.fc26.x86_64

Thanks,
Paulo
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Review swaps

[Paulo César Pereira de Andrade]

  Hi,

Two  easy reviews. These are required to update to sagemath-6.8.
[I will work to update to sagemath-6.9...]

https://bugzilla.redhat.com/show_bug.cgi?id=1278081
rw - Program that calculates rank-width and rank-decompositions
rw is a program that calculates rank-width and rank-decompositions.
It is based on ideas from "Computing rank-width exactly" by Sang-il Oum,
"Sopra una formula numerica" by Ernesto Pascal, "Generation of a Vector
from the Lexicographical Index" by B.P. Buckles and M. Lybanon and
"Fast additions on masked integers" by Michael D. Adams and David S. Wise.

https://bugzilla.redhat.com/show_bug.cgi?id=1278140
planarity - Implementations of several planarity-related graph algorithms
This code project provides a library for implementing graph algorithms
as well as implementations of several planarity-related graph algorithms.
The origin of this project is the reference implementation for the Edge
Addition Planarity Algorithm, which is now the fastest and simplest
linear-time method for planar graph embedding and planarity obstruction
isolation (i.e. Kuratowski subgraph isolation).

Thanks,
Paulo
-- 
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: About making noarch package arch specific, when contents differ.

[Paulo César Pereira de Andrade]

2015-07-28 5:03 GMT-03:00 Peter Robinson pbrobin...@gmail.com:

 %ifarch x86_64
 %package doc
 BuildArch: noarch
 ...
 %endif

   This looks like a very wise way of handling it. Actually, while debugging

 It's not, it breaks all secondary architectures.

 it, I found that the translated documentation was not being properly
 generated, and after fixing it, it would take like 3 to 4 times longer
 to generate docs, and doc generation was already almost 80% of
 the package build time...

 That tells me the process of generating docs is broken, or they're
 very good docs and worth the wait!

  It is the later. It has its problems of course, but the documentation
is really very good and complete, documenting every single interface.
It is live, once running the sagemath notebook, one can modify
the examples, run with different input, etc.

Thanks,
Paulo
-- 
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: About making noarch package arch specific, when contents differ.

[Paulo César Pereira de Andrade]

2015-07-28 5:58 GMT-03:00 Florian Weimer fwei...@redhat.com:
 On 07/26/2015 04:05 PM, Paulo César Pereira de Andrade wrote:

 Should I make the doc packages arch specific?

 No, this is not a reason to make them arch-specific.  A lot of packages
 give different results when built twice in a row, on the *same*
 architecture.

 There is an effort under way to change that, called “reproducible
 builds”.  The hard part is any reproducibility at all, identical noarch
 builds across architectures are likely just some additional work on top
 of it.

  I believe that if there is a check for bit by bit identical noarch
packages, it would also be mandatory some way to tell that
any minor difference is ok and expected, and use the noarch
built on that arch...

 --
 Florian Weimer / Red Hat Product Security

Thanks,
Paulo
-- 
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: About making noarch package arch specific, when contents differ.

[Paulo César Pereira de Andrade]

2015-07-27 22:34 GMT-03:00 Dan Callaghan dcall...@redhat.com:
 Excerpts from paulo.cesar.pereira.de.andrade's message of 2015-07-27 00:05 
 +10:00:
 Should I make the doc packages arch specific?

 Rather than trying to make Sphinx spit out bitwise-identical output on
 every arch (which sounds like fighting a losing battle), could you just
 build the doc subpackage on only one arch?

 %ifarch x86_64
 %package doc
 BuildArch: noarch
 ...
 %endif

  This looks like a very wise way of handling it. Actually, while debugging
it, I found that the translated documentation was not being properly
generated, and after fixing it, it would take like 3 to 4 times longer
to generate docs, and doc generation was already almost 80% of
the package build time...

 I think Koji still counts this a regular noarch subpackage and it should
 therefore be included in the Fedora trees for all arches.

  In the worst case, it would generate -doc packages only for x86_64,
where most users interested on reading it would be using.

 --
 Dan Callaghan dcall...@redhat.com
 Senior Software Engineer, Products  Technologies Operations
 Red Hat, Inc.

Thanks! I will try this way :)
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

About making noarch package arch specific, when contents differ.

[Paulo César Pereira de Andrade]

I had this build failure:

Package:sagemath-6.5-7.fc22
Status: failed
Built by:   pcpa
ID: 672175
Started:Sat, 25 Jul 2015 22:52:10 UTC
Finished:   Sun, 26 Jul 2015 07:57:28 UTC

Closed tasks:
-
Task 10480570 on arm04-builder10.arm.fedoraproject.org
Task Type: build (noarch)
Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=10480570

mismatch when analyzing sagemath-doc-en-6.5-7.fc22.noarch.rpm, rpmdiff
output was:
error: cannot open Packages index using db5 - Permission denied (13)
error: cannot open Packages database in /var/lib/rpm
error: cannot open Packages database in /var/lib/rpm
added   /usr/share/doc/sagemath/output/html/en/reference/hecke
[...]

The interesting part, is that the above build generated
packages, but ended up with failed state.
After that, I checked contents of the armv7hl and x86_64
trees, and noticed that they are, indeed not identical.
The way documentation is generated with sphinx, should
be part of the cause (when it pickle/unpicke python states, etc),
and sometimes it even adds the location of a file to the docs,
e.g. telling where source is located, causes diffs, from
/usr/lib/python2.7/... vs /usr/lib64/python2.7/...

Should I make the doc packages arch specific?

Thanks,
Paulo
-- 
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: About making noarch package arch specific, when contents differ.

[Paulo César Pereira de Andrade]

2015-07-26 12:20 GMT-03:00 Sérgio Basto ser...@serjux.com:


 On Dom, 2015-07-26 at 11:05 -0300, Paulo César Pereira de Andrade wrote:
 I had this build failure:

 Package:sagemath-6.5-7.fc22
 Status: failed
 Built by:   pcpa
 ID: 672175
 Started:Sat, 25 Jul 2015 22:52:10 UTC
 Finished:   Sun, 26 Jul 2015 07:57:28 UTC

 Closed tasks:
 -
 Task 10480570 on arm04-builder10.arm.fedoraproject.org
 Task Type: build (noarch)
 Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=10480570

 mismatch when analyzing sagemath-doc-en-6.5-7.fc22.noarch.rpm, rpmdiff
 output was:
 error: cannot open Packages index using db5 - Permission denied (13)
 error: cannot open Packages database in /var/lib/rpm
 error: cannot open Packages database in /var/lib/rpm
 added   /usr/share/doc/sagemath/output/html/en/reference/hecke
 [...]

 The interesting part, is that the above build generated
 packages, but ended up with failed state.
 After that, I checked contents of the armv7hl and x86_64
 trees, and noticed that they are, indeed not identical.
 The way documentation is generated with sphinx, should
 be part of the cause (when it pickle/unpicke python states, etc),
 and sometimes it even adds the location of a file to the docs,
 e.g. telling where source is located, causes diffs, from
 /usr/lib/python2.7/... vs /usr/lib64/python2.7/...

 I suspect package is using %{_libdir} and libdir can't be used in noarch
 packages. %{_libdir} expands to /usr/lib on arm and /usr/lib64/ on
 x86_64. This is a general problem when we try translate Debian packages
 to Fedora, I don't have time now to explain better but we had some
 topics about related subjects in Packaging mailing list ...

 Python also have different scriptlets for arch and noarch packages. On
 x86_64 systems, we can find some noarch packages in /usr/lib/python2.7/
 and python arched in /usr/lib64/python2.7/ .

  A good share of the diffs is documentation is printing addresses of
objects, at the time the documentation was generated, for example:

---8---
diff -rNu 
armv7hl/usr/share/doc/sagemath/output/html/en/reference/calculus/sage/gsl/dft.html
x86_64/usr/share/doc/sagemath/output/html/en/reference/calculus/sage/gsl/dft.html
--- 
armv7hl/usr/share/doc/sagemath/output/html/en/reference/calculus/sage/gsl/dft.html
   2015-07-26 12:25:01.039419016 -0300
+++ 
x86_64/usr/share/doc/sagemath/output/html/en/reference/calculus/sage/gsl/dft.html
   2015-07-26 12:25:06.410419222 -0300
@@ -226,7 +226,7 @@

 dl class=method
 dt id=sage.gsl.dft.IndexedSequence.dft
-tt class=descnamedft/ttbig(/bigemchi=lt;function
lt;lambdagt; at 0xac336d70gt;/embig)/biga class=headerlink
href=#sage.gsl.dft.IndexedSequence.dft title=Permalink to this
definition¶/a/dt
+tt class=descnamedft/ttbig(/bigemchi=lt;function
lt;lambdagt; at 0x7f27a03f4140gt;/embig)/biga
class=headerlink href=#sage.gsl.dft.IndexedSequence.dft
title=Permalink to this definition¶/a/dt
 ddpA discrete Fourier transform #8220;over img class=math
src=../../_images/math/7bab5d1f8fefbcece570be83647d253afa56e0df.png
alt=\QQ/#8221; using exact
 img class=math
src=../../_images/math/9373b89a1028693ea48d96bef05ec06f42c4ba41.png
alt=N/-th roots of unity./p
 pEXAMPLES:/p
---8---
Example of the above, live:
http://doc.sagemath.org/html/en/reference/calculus/sage/gsl/dft.html#sage.gsl.dft.IndexedSequence.dft

About %{_libdir}, there are some in this pattern:
---8---
diff -rNu armv7hl/usr/share/doc/sagemath/output/html/en/reference/todolist.html
x86_64/usr/share/doc/sagemath/output/html/en/reference/todolist.html
--- armv7hl/usr/share/doc/sagemath/output/html/en/reference/todolist.html
   2015-07-26 12:25:03.271419101 -0300
+++ x86_64/usr/share/doc/sagemath/output/html/en/reference/todolist.html
   2015-07-26 12:25:08.671419308 -0300
@@ -83,36 +83,36 @@
 p class=lastDeprecate this in favor of a method called img
class=math src=_images/math/107b545f3b4d727d47ab3a406ddd5b3a92cd2fda.png
alt=center()/ once
 subalgebras are properly implemented in Sage./p
 /div
-p class=todo-source(The a class=reference internal
href=algebras/sage/algebras/clifford_algebra.html#index-0emoriginal
entry/em/a is located in
/usr/lib/python2.7/site-packages/sage/algebras/clifford_algebra.py:docstring
of sage.algebras.clifford_algebra.CliffordAlgebra.center_basis, line
12.)/p
+p class=todo-source(The a class=reference internal
href=algebras/sage/algebras/clifford_algebra.html#index-0emoriginal
entry/em/a is located in
/usr/lib64/python2.7/site-packages/sage/algebras/clifford_algebra.py:docstring
of sage.algebras.clifford_algebra.CliffordAlgebra.center_basis, line
12.)/p
---8---

  Others are in some generated js, after searching the first
difference, it looks like this,
diff at char 255:
armv7hl:
Search.setIndex({envversion:42,terms:{represent:[1,2],all:[5,1,3,6,8,12,13],x3y:13,partial:0,sch:3,joyner:14,illustr:[0,2,4,6,7,8,15],skip:9,lfsr_sequenc:9,hamburg:14,roe:7,month:3,'_k1':0,plot_list:15,short_weierstrass_model:10,'_k2':0,ellipt

Re: Self Introduction: Athos Ribeiro

[Paulo César Pereira de Andrade]

2015-07-11 15:11 GMT-03:00 Athos Ribeiro athoscribe...@gmail.com:
 Hi,

  Hi,

 My name is Athos Ribeiro, I have been using Fedora for a while now and just 
 submitted my first package 
 (https://bugzilla.redhat.com/show_bug.cgi?id=1242056).

  Welcome Athos!

 I am a Brazilian Software Engineering student at Universidade de Brasília 
 (Brazil) and have been working on a project where we integrate some tools to 
 in order to host Brazilian government Free Software. The package I am 
 submitting is related to our project and is already present in the Debian 
 project. I do work with the upstream developer of the package and do fix some 
 bugs in there now and then.

 I will keep submitting the other packages we use in our projects whenever we 
 decide they may be useful for other people. I am happy to be able to 
 contribute to the project and hope I can keep contributing when possible.

  I will look and review your package :)

  We talked in person yesterday in FISL, and I should do a more
careful review tomorrow.

 Thank you!

 --
 Athos Ribeiro

Thanks,
Paulo
-- 
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: Reviving Fedora MIPS

[Paulo César Pereira de Andrade]

2015-06-02 7:19 GMT-03:00 Richard W.M. Jones rjo...@redhat.com:
 On Mon, Jun 01, 2015 at 10:10:17PM +0200, Michal Toman wrote:
 Apart from mips64el, we have lately started working on 32-bit mipsel, to
 be ran on the Creator CI20 Borad [4]. This is basically 3 months behind
 mips64el so there are no significant results yet, but hopefully will be
 soon.

 I have the Creator CI20 board.  Does this mean ImgTec are going to
 bring out a 64 bit development board :-?  I guess you won't be able
 to tell me ..

 Anyway my CI20 is currently running Debian, but I'll give Fedora a go
 when I have the time.

 Any help would be appreciated, especially in the area of kernel, u-boot
 and some specific languages - haskell, erlang, ocaml etc. I have already
 been playing with some of those and there is a list of issues on the wiki.

 There's no OCaml 32 bit MIPS backend upstream, but there used to be
 one.  An older version of it can be found here:

 https://github.com/retired-camels/ocaml

 Claims to support BE and LE and uses the n32 ABI, whatever that
 means.  It would require a certain amount of work to bring that up to
 date, but it's not impossible.

 As far as I can tell there is no 64 bit MIPS backend at all and never
 has been.  Depending on how different 32 bit and 64 bit MIPS are that
 might be a lot of work to implement.

  The n32 and n64 abis are like x86_64 and x32 abi. For stack parameters,
on n32 it is still 8 bytes, but only 4 bytes effectively used.
  The abi is a lot more sane as well, 8 gpr and 8 fpr argument registers,
fpr registers are 64 bit.
  But I only played with it for a short time, when porting GNU Lightning
to n32 and n64, while the mips host on snakebit.net was live...

 Rich.

 --
 Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
 Read my programming and virtualization blog: http://rwmj.wordpress.com
 virt-builder quickly builds VMs from scratch
 http://libguestfs.org/virt-builder.1.html

Thanks,
Paulo
-- 
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 replacing yum and dnf-yum

[Paulo César Pereira de Andrade]

2015-04-07 9:53 GMT-03:00 Jan Zelený jzel...@redhat.com:
[...]
 I think you might have misunderstood what's happening. We don't want to offer

  Hopefully I did not :)

 dnf as an alternative to yum. Dnf is its successor. Yum is deprecated by dnf
 in F22 and is very likely going to be removed in one of the next releases.

  For releases I expect it to be functional. I use rawhide for several years
already, so I am used to stuff breaking.

  The problem is that fedora-review and/or mock were broken for more
than two months, see https://bugzilla.redhat.com/show_bug.cgi?id=1208912
so I was using -o--yum.

  I had also switched back to yum in rawhide due to --skip-broken, and
in a few updates not even needing it (I would first see what is broken,
and if not something vital, use --skip-broken), while dnf would just fail
with cryptic messages. I can keep up if kde or gnome is broken, or
some other stuff that does not prevent boot and a functional system.

 That's why we want to migrate users to dnf but at the same time we want to
 give them a possibility to stay a little bit longer on yum if absolutely
 necessary.

 Thanks for understanding
 Jan

Thanks,
Paulo
-- 
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 replacing yum and dnf-yum

[Paulo César Pereira de Andrade]

2015-04-03 11:24 GMT-03:00 Miroslav Suchý msu...@redhat.com:
 On 04/03/2015 03:41 PM, Paulo César Pereira de Andrade wrote:
 DEBUG util.py:388:  No such command: builddep. Please use /usr/bin/dnf --help
 DEBUG util.py:388:  It could be a DNF plugin command.

 I will review using a release other than rawhide.

 Just install dnf-plugins-core.

  It should have been installed in an update, e.g. as a dependency
of any packagers tool.

  It is also not available in any repo, for rhel7 (I would expect it
in epel). I run mock frequently in rhel7, but usually just as a simple
way to create a rawhide, f22 or f21 chroot.

[[off-topic:  Anyway, I made the review on a f21 box in a f21 mock
config, as it required java, and java is currently broken in rawhide.]]

 But suddenly it stopped being useful,
 and yum became again functional, so, I have been using only
 yum.

 This does not solve anything. Software had bugs, have bugs and will have bugs.
 When something is broken, report it. Give developers some time to fix it and 
 return after some time.

  It is hard to give up on something that looks useful, and I am
afraid, was being better for me than its substitute. Sure I gave
it a try, when yum was broken in rawhide. But when dnf
stopped working, and yum solved the problems, I just switched
back.

 --
 Miroslav Suchy, RHCE, RHCDS
 Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys

Thanks,
Paulo
-- 
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 replacing yum and dnf-yum

[Paulo César Pereira de Andrade]

2015-04-03 12:04 GMT-03:00 Paulo César Pereira de Andrade
paulo.cesar.pereira.de.andr...@gmail.com:
 2015-04-03 11:24 GMT-03:00 Miroslav Suchý msu...@redhat.com:
 On 04/03/2015 03:41 PM, Paulo César Pereira de Andrade wrote:
 DEBUG util.py:388:  No such command: builddep. Please use /usr/bin/dnf 
 --help
 DEBUG util.py:388:  It could be a DNF plugin command.

 I will review using a release other than rawhide.

 Just install dnf-plugins-core.

   It should have been installed in an update, e.g. as a dependency
 of any packagers tool.

   It is also not available in any repo, for rhel7 (I would expect it
 in epel). I run mock frequently in rhel7, but usually just as a simple
 way to create a rawhide, f22 or f21 chroot.

Nevermind, I thought dnf-plugins-core would be something that would
fix mock chroot generation with fedora-review, it is just documentation,
not related to mock.

Thanks,
Paulo
-- 
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 replacing yum and dnf-yum

[Paulo César Pereira de Andrade]

2015-04-03 16:18 GMT-03:00 Adam Williamson adamw...@fedoraproject.org:

 As msuchy said, the best thing to do when you encounter something that
 has been affected by the transition is to file a bug and get it fixed,
 not just use an older release.

I opened two bug reports:

[mock with default dnf fails to install dependencies in rawhide]
https://bugzilla.redhat.com/show_bug.cgi?id=1208912

and

[fedora-review gets confused after package build]
https://bugzilla.redhat.com/show_bug.cgi?id=1208914

I did not investigate much the second, just reported what
happened, and that only got there after adding the
dnf_builddep_command option to mocks site-defaults.cfg

Thanks,
Paulo
-- 
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 replacing yum and dnf-yum

[Paulo César Pereira de Andrade]

2015-04-03 16:18 GMT-03:00 Adam Williamson adamw...@fedoraproject.org:

  Hmm, let me see if I understand :)

 mock should be adapted to dnf or changed to call yum-deprecated on F22
 and F23.

 the 'resolvedep' command was already marked as deprecated *in yum*:

 * resolvedep dep1 [dep2] [...]
(maintained  for  legacy  reasons  only - use repoquery or
 yum pro‐
vides)

  Apparently yum is no longer an option in rawhide. The first error I had
was because yum is now a wrapper telling yum is deprecated and
exec'ing dnf, with yum arguments, i.e. the resolvedep deprecated
option, it will just fail.

 so mock really should've been ported off it a while back. If there
 isn't a bug on mock for this already, we should file one.

  It was working, so, this should not really be an issue, as yum is
supposed to be slowly forgotten.

 As msuchy said, the best thing to do when you encounter something that
 has been affected by the transition is to file a bug and get it fixed,
 not just use an older release.

  I just noticed that in f21, dnf-plugins-core actually has a lot of
files, while in rawhide it is only man pages.

  There is a kind of related bug report, for f20 at
https://bugzilla.redhat.com/show_bug.cgi?id=1198769

  I was wondering why, running manually

/usr/bin/dnf builddep --installroot
/var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 23
/var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/SRPMS/ebay-cors-filter-1.0.1-1.fc23.src.rpm

would work, while mock has this log:

DEBUG util.py:452:  Executing command: ['/usr/bin/dnf', 'builddep',
'--installroot', '/var/lib/mock/fedora-rawhide-x86_64/root/',
'--releasever', '23',
'/var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/ebay-cors-filter-1.0.1-1.fc23.src.rpm']
...
DEBUG util.py:388:  No such command: builddep. Please use /usr/bin/dnf --help
DEBUG util.py:388:  It could be a DNF plugin command.

and this pattern have been happening for quite some time; I think more
than one month, and I just did the simple human thing to do :), that was
to switch to mock -o--yum, and on rhel7, where I am most time
nowadays, but still trying to do fedora packaging :-), that is the only
option anyway.

Looking at this part of the mock code:

/usr/lib/python3.4/site-packages/mockbuild/package_manager.py:36
if args[0] == 'builddep':
args = args[1:]
invocation += self.builddep_command
common_opts = self.config[self.name + '_builddep_opts']
else:
invocation = [self.command]
common_opts = self.config[self.name + '_common_opts']
invocation += ['--installroot', self.buildroot.make_chroot_path('')]

it looks like (and in a quick test appears to be it), it would be fixed
with something like:

# echo config_opts['dnf_builddep_command'] = '/usr/bin/dnf builddep'
 /etc/mock/site-defaults.cfg

I will open a bug report about it.

Thanks,
Paulo
-- 
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 replacing yum and dnf-yum

[Paulo César Pereira de Andrade]

2015-04-01 16:40 GMT-03:00 Kevin Fenzi ke...@scrye.com:
 There's some confusion around this, so I thought I would post to try
 and clear up things. In the event I am wrong on any of the below, please
 do feel free to correct me. ;)

 In the past the proposal was to have a yum-dnf package that provided
 /usr/bin/yum, called dnf and conflicted with the yum package. I was
 against that plan, but I think the one we settled on is worth doing.
 It's somewhat of a middle ground between yum is gone right now,
 deal with it and you can keep using yum forever.

 For f22 (and rawhide):

 * dnf is installed by default. By that I mean it is in the 'core' group
   in comps.

 * dnf-yum is installed by default. By that I mean it is in the 'core'
   group in comps next to dnf.

 * yum is installed if something that depends on yum pulls it in or say
   a user installs it manually.

 * yum requires dnf-yum. So, if you install yum manually you will also
   pull in dnf-yum (and the dnf plugin that handles history migrate).

 * When you run 'yum' you get:

 % sudo yum list foobar
 Yum command has been deprecated, use dnf instead.
 See 'man dnf' and 'man yum2dnf' for more information.
 To transfer transaction metadata from yum to DNF, run 'dnf migrate'
 Redirecting to '/usr/bin/dnf list foobar'

 ...then the ouput from dnf list foobar...

 * If you wish to still use yum, the yum package provides now
   a /usr/bin/yum-deprecated command that is the old yum
   command renamed. It also has the notice message as above
   on it.

  I am using rawhide, and was trying to use dnf sometime ago, and
it was looking promising. But suddenly it stopped being useful,
and yum became again functional, so, I have been using only
yum.

  And have been using yum with mock, because it does not work
with dnf, but now, when doing a review, I was surprised with this
in root.log:

DEBUG util.py:452:  Executing command: ['/usr/bin/yum',
'--installroot', '/var/lib/mock/fedora-rawhide-x86_64/root/',
'--releasever', '23', 'resolvedep', 'ccache'] with env
{'CCACHE_UMASK': '002', 'LANG': 'en_US.UTF-8', 'HOME': '/builddir',
'CCACHE_DIR': '/tmp/ccache', 'SHELL': '/bin/bash', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin', 'LC_MESSAGES': 'C', 'PROMPT_COMMAND':
'printf \x1b]0;mock-chroot\x07mock-chroot', 'TERM': 'vt100',
'HOSTNAME': 'mock'} and shell False
DEBUG util.py:388:  Yum command has been deprecated, use dnf instead.
DEBUG util.py:388:  See 'man dnf' and 'man yum2dnf' for more information.
DEBUG util.py:388:  To transfer transaction metadata from yum to DNF,
run 'dnf migrate'Redirecting to '/usr/bin/dnf --installroot
/var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 23 resolvedep
ccache'
DEBUG util.py:388:  No such command: resolvedep. Please use /usr/bin/dnf --help
DEBUG util.py:388:  It could be a DNF plugin command.

so, lets run again (without fedora-review -o--yum) to ge back the dnf error
in root.log:

DEBUG util.py:452:  Executing command: ['/usr/bin/dnf', 'builddep',
'--installroot', '/var/lib/mock/fedora-rawhide-x86_64/root/',
'--releasever', '23',
'/var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/ebay-cors-filter-1.0.1-1.fc23.src.rpm']
with env {'LANG': 'en_US.UTF-8', 'HOME': '/builddir', 'CCACHE_DIR':
'/tmp/ccache', 'SHELL': '/bin/bash', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf
\x1b]0;mock-chroot\x07mock-chroot', 'HOSTNAME': 'mock',
'LC_MESSAGES': 'C', 'TERM': 'vt100', 'CCACHE_UMASK': '002'} and shell
False
DEBUG util.py:388:  No such command: builddep. Please use /usr/bin/dnf --help
DEBUG util.py:388:  It could be a DNF plugin command.

I will review using a release other than rawhide.

 * If you are using the yum python bindings directly, that will continue
to work if you have the yum package installed.

 Note that this landed before Beta freeze, but there were some issues
 with the initial package doing this. There is an update available:

 https://admin.fedoraproject.org/updates/yum-3.4.3-505.fc22

 I think this helps those users who read any of the docs out there
 that say to 'yum install foo' at the cost of those people who need
 some specific command line behavior from yum. The second group
 is much better positioned to use yum-deprecated or know whats
 going on than the first group.

  I understand that there is need to update, to use new tools, but
I am afraid, yum only had a small window of time broken for me
some time ago, after that, I could simply not use dnf to update
rawhide, while with yum, sometimes needing --skip-broken (and
doing that when I knew the packages broken would not break
my system), I would be able to update.

 kevin

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Quick C++ question for C++ experts :)

[Paulo César Pereira de Andrade]

Is this expected to not compile with -fno-implicit-templates?

---%---
$ cat test.cc
#include string
std::string test(int i)
{
std::string t;
std::string s = (;
t = ;
for (int r = i; r; r=1) {
if (r  1)
t = 1 + t;
else
t = 0 + t;
}
s += t;
s += );
return s;
}

int
main(int argc, char *argv[])
{
std::string s = test(16);
return 0;
}

$ g++ -fno-implicit-templates test.cc
/tmp/ccai7t5T.o: In function `test(int)':
test.cc:(.text+0x9d): undefined reference to
`std::__cxx11::basic_stringchar, std::char_traitschar,
std::allocatorchar  std::operator+char, std::char_traitschar,
std::allocatorchar (char const*, std::__cxx11::basic_stringchar,
std::char_traitschar, std::allocatorchar  const)'
test.cc:(.text+0xd9): undefined reference to
`std::__cxx11::basic_stringchar, std::char_traitschar,
std::allocatorchar  std::operator+char, std::char_traitschar,
std::allocatorchar (char const*, std::__cxx11::basic_stringchar,
std::char_traitschar, std::allocatorchar  const)'
collect2: error: ld returned 1 exit status
---%---

I am trying to fix a package, but it is documented to
require -fno-implicit-templates and instantiate templates
in one of the sources, but it instantiates templates for
its own types.

Thanks,
Paulo
-- 
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: Quick C++ question for C++ experts :)

[Paulo César Pereira de Andrade]

2015-03-28 16:06 GMT-03:00 Paulo César Pereira de Andrade
paulo.cesar.pereira.de.andr...@gmail.com:
 Is this expected to not compile with -fno-implicit-templates?

 ---%---
 $ cat test.cc
 #include string
 std::string test(int i)
 {
 std::string t;
 std::string s = (;
 t = ;
 for (int r = i; r; r=1) {
 if (r  1)
 t = 1 + t;
 else
 t = 0 + t;
 }
 s += t;
 s += );
 return s;
 }

 int
 main(int argc, char *argv[])
 {
 std::string s = test(16);
 return 0;
 }

 $ g++ -fno-implicit-templates test.cc
 /tmp/ccai7t5T.o: In function `test(int)':
 test.cc:(.text+0x9d): undefined reference to
 `std::__cxx11::basic_stringchar, std::char_traitschar,
 std::allocatorchar  std::operator+char, std::char_traitschar,
 std::allocatorchar (char const*, std::__cxx11::basic_stringchar,
 std::char_traitschar, std::allocatorchar  const)'
 test.cc:(.text+0xd9): undefined reference to
 `std::__cxx11::basic_stringchar, std::char_traitschar,
 std::allocatorchar  std::operator+char, std::char_traitschar,
 std::allocatorchar (char const*, std::__cxx11::basic_stringchar,
 std::char_traitschar, std::allocatorchar  const)'
 collect2: error: ld returned 1 exit status
 ---%---

  I will open a gcc bug report. It must be a bug, because if using
a temporary to convert 1 or 0 to a std::string it works. Or,
explicit converting, e.g.:

-t = 1 + t;
+t = std::string(1) + t;

  My C++ foo is not that great, thus asking before opening a
bug report.

Thanks,
Paulo
-- 
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: Texlive packaging

[Paulo César Pereira de Andrade]

2015-03-28 16:40 GMT-03:00 Florian Weimer f...@deneb.enyo.de:
 * Matthew Miller:

 On Fri, Mar 27, 2015 at 08:28:21PM +0100, drago01 wrote:
 Actually machine generated isn't per se bad  ... it saves a lot of
 effort and should be done more (for other packages too where
 possible).
 Why waste man power for something that can be automated?

 As for tex ... we could have a srpm for each one (machine generated
 there is no reason it has to be one srpm) would also mean that only
 the packages where something changes end up getting updated.

 Right, as I understand it, the gigantic single SRPM is to avoid the
 normal requirement that each individual package have its own manual
 review. For thousands of packages, that's quite a burden.

 TeXLive isn't just an installer for random versions of CTAN packages,
 right?  They do make releases.  So the bundling is not unlike what
 happens with, say, OpenJDK releases, where it is still not unheard of
 to mix-and-match Hotspot from here and the class libraries from there,
 and yet there is just one SRPM per release.

  One can update the binaries and noarch yearly. Usually most important
would be to fetch bugfixes and security fixes from the year branch
See https://www.tug.org/svn/texlive/branches/
The noarch could be fetched from ftp://tug.org/texlive/historic/

  It is more about keeping up to date or not with upstream, e.g. the
2k+ subpackages all handled by upstream, or doing it yourself, I am
afraid not an easy task, creating a spec to list files from a  1G
.xz file.

 Debian has a middle-ground, with slightly more than 100 binary
 packages, built from four source packages (as far as I can see).

  Technically, Debian also does not have a lot of packages because
they as well have quite a lot of bureaucracy to create packages,
not a bad thing, of course.

  See last paragraph of http://tug.org/pipermail/tldistro/2011q4/000162.html

Thanks,
Paulo
-- 
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: Texlive packaging

[Paulo César Pereira de Andrade]

2015-03-27 16:58 GMT-03:00 Matthew Miller mat...@fedoraproject.org:
 On Fri, Mar 27, 2015 at 08:28:21PM +0100, drago01 wrote:
 Actually machine generated isn't per se bad  ... it saves a lot of
 effort and should be done more (for other packages too where
 possible).
 Why waste man power for something that can be automated?

 As for tex ... we could have a srpm for each one (machine generated
 there is no reason it has to be one srpm) would also mean that only
 the packages where something changes end up getting updated.

 Right, as I understand it, the gigantic single SRPM is to avoid the
 normal requirement that each individual package have its own manual
 review. For thousands of packages, that's quite a burden.

  I maintained a slowly evolving approach in Mandriva for some years,
(but now it is quickly approaching one year I left Mandriva...), see the
main script at
https://abf.rosalinux.ru/openmandriva/texlive-tlpkg/blob/master/tlpobj2spec.pl
It uses the texlive perl modules to do most of the work, and only does
some filtering on contents, choosing %doc (what texlive calls doc
and source), extracting dependencies or license information, %post
scripts, etc.

  The script even handles when I messed something, or, quite common
problem of upstream downgrading a version, or switching to/from
version to date-version format.

  Another important script is
https://abf.rosalinux.ru/openmandriva/texlive-tlpkg/blob/master/checkupdates.pl
it assumes it is called from a top directory where there is a full
checkout of all texlive packages, and, then, it relies on a specific
spec header format, to tell what packages can be updated. Note
that sometimes the package database and the mirrors may not
agree, so, some manual intervention may be required, e.g.
hardcoding to use a fast mirror, or running again to choose another
mirror that agrees with the package database.

  I even adapted the texlive package manager to use the system
package management, e.g. see official tlmgr screenshots at
https://www.tug.org/texlive/doc/texlive-en/texlive-en.html#tlmgr
and the adapted version to use urpmi
https://abf.rosalinux.ru/openmandriva/texlive-tlpkg/blob/master/tlmgr

 But the workaround, while not violating any specific guidelines,
 doesn't _really_ have any more careful individual review of each of its
 parts — it's not a gain. And it has negative side-effects.

 If FPC would be open to bulk-approving machine-generated individual
 spec files (given, say, they're provably all following the template,
 which would be reviewed), and rel-eng has some way of bulk-adding the
 necessary branches and builds, that really seems like a step forward to
 me.

  It is quite a lot of work, so, it would be better to have a SIG and
not let only one person handle all packages.

  Once a setup like the one I used is done, it is required around 2 hours
per week to keep in sync with upstream TeXLive. Assuming one can
can fast create (or do a really quick review, thus a SIG) 3-10 packages
per week (sometimes it will go a lot of time without new packages).
Frequently packages are deprecated (no texlive package requires them),
and sometime later reenabled.

 Am I missing something?



 --
 Matthew Miller
 mat...@fedoraproject.org
 Fedora Project Leader

Thanks,
Paulo
-- 
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: Texlive packaging

[Paulo César Pereira de Andrade]

2015-03-28 13:26 GMT-03:00 Jonathan Underwood jonathan.underw...@gmail.com:
 On 28 March 2015 at 15:07, Paulo César Pereira de Andrade
 paulo.cesar.pereira.de.andr...@gmail.com wrote:
   I maintained a slowly evolving approach in Mandriva for some years,
 (but now it is quickly approaching one year I left Mandriva...), see the
 main script at
 https://abf.rosalinux.ru/openmandriva/texlive-tlpkg/blob/master/tlpobj2spec.pl
 It uses the texlive perl modules to do most of the work, and only does
 some filtering on contents, choosing %doc (what texlive calls doc
 and source), extracting dependencies or license information, %post
 scripts, etc.


 This looks really handy. I wonder though about the need to really have
 one RPM per texlive package.Would it not be a reasonable middle ground
 to generate one SRPM per texlive collection?

  Having 1 to 1, rpm packages matching texlive packages has its
advantages, it comes with dependencies easy to generate, and
one can update a 1-2k single package easily. But creating almost
3k packages to bootstrap could be quite disturbing.

  One package per collection should be quite doable as well, and
could still make a perl script, to make it easy to convert texlive
packages metadata to rpm packages, using the texlive perl
modules.

  An example of how it looks like when having one package per
texlive package is:
https://abf.rosalinux.ru/openmandriva/texlive-collection-fontsrecommended/blob/master/texlive-collection-fontsrecommended.spec
The above is a meta package, only with dependencies.
The above also is an example of what the script did when
there was no license information (it did trust whatever
texlive choose), and used a link to a license file, what
may not be a good idea.

  An example of an actual package, not a meta package:
https://abf.rosalinux.ru/openmandriva/texlive-tetex/blob/master/texlive-tetex.spec
and as well, another example of dubious license tag :(

  This one is a more standard one, regarding licenses:
https://abf.rosalinux.ru/openmandriva/texlive-latex/blob/master/texlive-latex.spec

   It is quite a lot of work, so, it would be better to have a SIG and
 not let only one person handle all packages.


 I would be interested in joining such a SIG and effort.

me too :)

 Jonathan

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Update to 0ad-0.18

[Paulo César Pereira de Andrade]

  Hi,

  In case you would like to see it faster in Fedora :)

  0ad-0.18 needs mozjs31, so I need this package reviewed
and approved:
https://bugzilla.redhat.com/show_bug.cgi?id=1202131

  For rawhide I also need gloox rebuilt for the new
c++ string and list abi:
https://bugzilla.redhat.com/show_bug.cgi?id=1202059

  I pushed commits for 0ad and 0ad-data only for rawhide,
but requiring the new mozjs31 package, and gloox rebuilt,
it works for me.

Thanks,
Paulo
-- 
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: Update to 0ad-0.18

[Paulo César Pereira de Andrade]

2015-03-15 18:32 GMT-03:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl:
 On Sun, Mar 15, 2015 at 04:16:50PM -0300, Paulo César Pereira de Andrade 
 wrote:
   Hi,

   In case you would like to see it faster in Fedora :)

   0ad-0.18 needs mozjs31, so I need this package reviewed
 and approved:
 https://bugzilla.redhat.com/show_bug.cgi?id=1202131

   For rawhide I also need gloox rebuilt for the new
 c++ string and list abi:
 https://bugzilla.redhat.com/show_bug.cgi?id=1202059

   I pushed commits for 0ad and 0ad-data only for rawhide,
 but requiring the new mozjs31 package, and gloox rebuilt,
 it works for me.
 You shouldn't treat rawhide as a dumping ground for packages
 which cannot work. Use a copr or a scratch build.

  It was not a good idea to push 0ad with a build requires
that is not yet available (mozjs31), but otherwise, 0ad-0.17
would also fail to build until gloox is rebuilt.
  I can remake a previous experimental patch if mozjs31
delays too much, to have a conditional on building with
bundled mozjs31, but that would be non default, as would
need fesco approval for the bundling.

 Zbyszek
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: Subject: Self Introduction: Sandro Bonazzola

[Paulo César Pereira de Andrade]

2015-03-02 3:34 GMT-03:00 Sandro Bonazzola sbona...@redhat.com:
 Il 27/02/2015 18:26, Paulo César Pereira de Andrade ha scritto:
 2015-02-27 13:02 GMT-03:00 Sandro Bonazzola sbona...@redhat.com:
 Hi,

   Hello and Welcome Sandro!

 following [1] I'm writing for introducing myself.
 My name is Sandro Bonazzola and I'm a Senior Software Engineer at Red Hat.
 I'm leading RHEV integration team and I'm oVirt[2] project release manager.
 I'm also representing oVirt project in CentOS Virt SIG[3].
 In the past I contributed to several open source projects[4] and I was a 
 former Gentoo Linux developer[5] several years ago.
 My FAS account is sbonazzo[6].
 I'm interested in packaging oVirt and its missing dependencies within 
 Fedora.

   I am a Fedora packager sponsor, and have particular interest in learning
 more about virtualization related projects, so, I can help and sponsor you.
 Do you already have a review request?

 Yes I have one:
 Bug 1197132 - Review Request: reflections - a Java runtime metadata analysis
 But now I see it's a duplicate of
 Bug 834574 - Review Request: reflections - Java run time meta data analysis

 So no requests open for now. Other request will follow, for packaging oVirt 
 under Fedora, a long list of deps is sitll missing.
 Thanks for your welcome and your offer of sponsorship!

  We can continue later on private mail, but at first I would suggest
comparing your package with the other, still under review.
  You can also test most common problems running fedora
review, for example, even before making a review request, you
can run:

$ fedora-review -n NAME -r

where NAME is output of rpm -qp --qf %{NAME} $SRPM, -r is to
tell it to use the spec from the srpm. You may also add something
like -m fedora-rawhide-x86_64 to the fedora-review command line,
if your /etc/mock/default.cfg is not already pointing to a rawhide
config.

 [1] 
 http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Introduce_yourself
 [2] http://www.ovirt.org
 [3] http://wiki.centos.org/SpecialInterestGroup/Virtualization
 [4] https://www.openhub.net/accounts/sanchan
 [5] 
 http://archives.gentoo.org/gentoo-dev/message/bb8da84f01bdba83c88ddf5d300eeafc
 [6] https://fedoraproject.org/wiki/User:Sbonazzo

Thanks,
Paulo
-- 
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: Subject: Self Introduction: Sandro Bonazzola

[Paulo César Pereira de Andrade]

2015-02-27 13:02 GMT-03:00 Sandro Bonazzola sbona...@redhat.com:
 Hi,

  Hello and Welcome Sandro!

 following [1] I'm writing for introducing myself.
 My name is Sandro Bonazzola and I'm a Senior Software Engineer at Red Hat.
 I'm leading RHEV integration team and I'm oVirt[2] project release manager.
 I'm also representing oVirt project in CentOS Virt SIG[3].
 In the past I contributed to several open source projects[4] and I was a 
 former Gentoo Linux developer[5] several years ago.
 My FAS account is sbonazzo[6].
 I'm interested in packaging oVirt and its missing dependencies within Fedora.

  I am a Fedora packager sponsor, and have particular interest in learning
more about virtualization related projects, so, I can help and sponsor you.
Do you already have a review request?

 [1] 
 http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Introduce_yourself
 [2] http://www.ovirt.org
 [3] http://wiki.centos.org/SpecialInterestGroup/Virtualization
 [4] https://www.openhub.net/accounts/sanchan
 [5] 
 http://archives.gentoo.org/gentoo-dev/message/bb8da84f01bdba83c88ddf5d300eeafc
 [6] https://fedoraproject.org/wiki/User:Sbonazzo

 --
 Sandro Bonazzola
 Better technology. Faster innovation. Powered by community collaboration.
 See how it works at redhat.com

Thanks,
Paulo
-- 
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: what is, regarding to std::string and std::list, plan to rebuild packages and better procedures?

[Paulo César Pereira de Andrade]

2015-02-14 17:11 GMT-02:00 Paulo César Pereira de Andrade
paulo.cesar.pereira.de.andr...@gmail.com:
 In my case, I was updating coin-or packages when one of then
 started failing at link time, only on i686, like this:

  undefined reference to
 `CoinMessageHandler::operator(std::__cxx11::basic_stringchar,
 std::char_traitschar, std::allocatorchar  const)'

 I tried to, temporarily fix it by, only on i686 building with
 -D_GLIBCXX_USE_CXX11_ABI=0 in CXXFLAGS. It did work
 on a clean mock chroot, but would fail with a core dump during
 %check in  koji. So, I reverted it as it looked bad, and started
 bootstraping again all packages, but now, the second package
 in the bootstrap process fails its %check like this:

 Testing OsiRowCut with OsiTestSolverInterface
 *** Error in `/builddir/build/BUILD/Osi-0.107.2/test/.libs/lt-unitTest':
 munmap_chunk(): invalid pointer: 0x7fbc26a144f0 ***
 === Backtrace: =
 /usr/lib64/libc.so.6(+0x7a00d)[0x7fbc2611600d]
 /usr/lib64/libc.so.6(cfree+0x1a8)[0x7fbc26122568]
 /builddir/build/BUILD/Osi-0.107.2/test/.libs/lt-unitTest(_ZN9CoinErrorD1Ev+0x1d)[0x416b1d]
 /usr/lib64/libstdc++.so.6(+0x8d66f)[0x7fbc26a1266f]
 /usr/lib64/libCoinUtils.so.3(_ZN16CoinPackedVector15gutsOfSetVectorEiPKiPKdbPKc+0x65c)[0x7fbc271fc34c]
 /builddir/build/BUILD/Osi-0.107.2/src/OsiCommonTest/.libs/libOsiCommonTests.so.1(_Z17OsiRowCutUnitTestPK18OsiSolverInterfaceRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x34b0)[0x7fbc276f3600]

  Restarting today updating/rebuilding the coin-or stack did no longer
trigger the problem in koji builds.

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

what is, regarding to std::string and std::list, plan to rebuild packages and better procedures?

[Paulo César Pereira de Andrade]

In my case, I was updating coin-or packages when one of then
started failing at link time, only on i686, like this:

 undefined reference to
`CoinMessageHandler::operator(std::__cxx11::basic_stringchar,
std::char_traitschar, std::allocatorchar  const)'

I tried to, temporarily fix it by, only on i686 building with
-D_GLIBCXX_USE_CXX11_ABI=0 in CXXFLAGS. It did work
on a clean mock chroot, but would fail with a core dump during
%check in  koji. So, I reverted it as it looked bad, and started
bootstraping again all packages, but now, the second package
in the bootstrap process fails its %check like this:

Testing OsiRowCut with OsiTestSolverInterface
*** Error in `/builddir/build/BUILD/Osi-0.107.2/test/.libs/lt-unitTest':
munmap_chunk(): invalid pointer: 0x7fbc26a144f0 ***
=== Backtrace: =
/usr/lib64/libc.so.6(+0x7a00d)[0x7fbc2611600d]
/usr/lib64/libc.so.6(cfree+0x1a8)[0x7fbc26122568]
/builddir/build/BUILD/Osi-0.107.2/test/.libs/lt-unitTest(_ZN9CoinErrorD1Ev+0x1d)[0x416b1d]
/usr/lib64/libstdc++.so.6(+0x8d66f)[0x7fbc26a1266f]
/usr/lib64/libCoinUtils.so.3(_ZN16CoinPackedVector15gutsOfSetVectorEiPKiPKdbPKc+0x65c)[0x7fbc271fc34c]
/builddir/build/BUILD/Osi-0.107.2/src/OsiCommonTest/.libs/libOsiCommonTests.so.1(_Z17OsiRowCutUnitTestPK18OsiSolverInterfaceRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x34b0)[0x7fbc276f3600]

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

taskotron failure to see dependencies (...has inferior architecture )

[Paulo César Pereira de Andrade]

...
Automatic push to stable based on karma has been
disabled for this update due to failure of an AutoQA
test
...

But I cannot see the error:

---8---
not ok - depcheck for Bodhi update sagemath-6.1.1-6.fc20 # FAIL
  ---
  arch: x86_64
  details:
output: |-
  Build sagemath-6.1.1-6.fc20 failed depcheck
  package sagemath-data-6.1.1-6.fc20.noarch requires sagemath =
6.1.1-6.fc20, but none of the providers can be installed
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  package sagemath-data-6.1.1-6.fc20.noarch requires sagemath =
6.1.1-6.fc20, but none of the providers can be installed
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  package sagemath-data-etc-6.1.1-6.fc20.noarch requires
sagemath-data = 6.1.1-6.fc20, but none of the providers can be
installed
  package sagemath-data-6.1.1-6.fc20.noarch requires sagemath =
6.1.1-6.fc20, but none of the providers can be installed
  package sagemath-data-6.1.1-6.fc20.noarch requires sagemath =
6.1.1-6.fc20, but none of the providers can be installed
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  package sagemath-sagetex-6.1.1-6.fc20.i686 requires
sagemath(x86-32) = 6.1.1-6.fc20, but none of the providers can be
installed
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  package sagemath-devel-6.1.1-6.fc20.i686 requires
sagemath(x86-32) = 6.1.1-6.fc20, but none of the providers can be
installed
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  package sagemath-data-graphs-6.1.1-6.fc20.noarch requires
sagemath-data = 6.1.1-6.fc20, but none of the providers can be
installed
  package sagemath-data-6.1.1-6.fc20.noarch requires sagemath =
6.1.1-6.fc20, but none of the providers can be installed
  package sagemath-data-6.1.1-6.fc20.noarch requires sagemath =
6.1.1-6.fc20, but none of the providers can be installed
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  package sagemath-data-polytopes_db-6.1.1-6.fc20.noarch requires
sagemath-data = 6.1.1-6.fc20, but none of the providers can be
installed
  package sagemath-data-6.1.1-6.fc20.noarch requires sagemath =
6.1.1-6.fc20, but none of the providers can be installed
  package sagemath-data-6.1.1-6.fc20.noarch requires sagemath =
6.1.1-6.fc20, but none of the providers can be installed
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  package sagemath-data-elliptic_curves-6.1.1-6.fc20.noarch
requires sagemath-data = 6.1.1-6.fc20, but none of the providers can
be installed
  package sagemath-data-6.1.1-6.fc20.noarch requires sagemath =
6.1.1-6.fc20, but none of the providers can be installed
  package sagemath-data-6.1.1-6.fc20.noarch requires sagemath =
6.1.1-6.fc20, but none of the providers can be installed
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  package sagemath-rubiks-6.1.1-6.fc20.i686 requires
sagemath(x86-32) = 6.1.1-6.fc20, but none of the providers can be
installed
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  package sagemath-notebook-6.1.1-6.fc20.i686 requires
sagemath(x86-32) = 6.1.1-6.fc20, but none of the providers can be
installed
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  package sagemath-core-6.1.1-6.fc20.i686 requires
sagemath(x86-32) = 6.1.1-6.fc20, but none of the providers can be
installed
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  package sagemath-data-conway_polynomials-6.1.1-6.fc20.noarch
requires sagemath-data = 6.1.1-6.fc20, but none of the providers can
be installed
  package sagemath-data-6.1.1-6.fc20.noarch requires sagemath =
6.1.1-6.fc20, but none of the providers can be installed
  package sagemath-data-6.1.1-6.fc20.noarch requires sagemath =
6.1.1-6.fc20, but none of the providers can be installed
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  sagemath-6.1.1-6.fc20.i686 has inferior architecture
  item: sagemath-6.1.1-6.fc20
  outcome: FAILED
  summary: sagemath-6.1.1-6.fc20 into F20 stable
---8---

Thanks,
Paulo
-- 
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: Attempting to contact unresponsive maintainer - jomara

[Paulo César Pereira de Andrade]

2014-11-12 21:01 GMT-02:00 Jason Rist jr...@redhat.com:
 On 11/12/2014 03:40 PM, Kevin Fenzi wrote:
 On Mon, 10 Nov 2014 20:59:16 +0100
 Matthias Runge mru...@matthias-runge.de wrote:

  Oh yes!
 
  Accidentally, we didn't solve this earlier.
 
  The plan, discussed with jomara was, Jason Rist (FAS: jrist) should
  take over these packages (and probably python-soaplib as well). I
  sponsored him some time ago for exactly that reason and will help him
  through cliffs and shallow waters here as best as I can.
 
  I added myself as co-maintainer to openstack-tuskar,
  openstack-tuskar-ui and python-tuskarclient.
 
  If we don't hear anything in a week, we will be setting the point of
  contact on these packages to orphan.
 
  I don't see a reason, why we need to wait for a week here, and I
  think, we can solve this situation immediately.

 Sure. I can reassign them...

 So to be clear thats:

 openstack-tuskar
 openstack-tuskar-ui
 python-soaplib
 python-tuskarclient

 change POC to jrist?

 kevin



 Yes please. Who is POC on

 python-flask-babel -- Adds i18n/l10n support to Flask applications
 ( epel7 )

  I can take care of python-flask-babel. I added it to Fedora anyway, and
now I actually use rhel...

 python-pyghmi -- Python General Hardware Management Initiative (IPMI
 and others) ( epel7 )

 Thanks,
 Jason


 --
 Jason E. Rist
 Senior Software Engineer
 OpenStack Management UI
 Red Hat, Inc.
 openuc: +1.972.707.6408
 mobile: +1.720.256.3933
 Freenode: jrist
 github/identi.ca: knowncitizen


Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

dnf vs yum

[Paulo César Pereira de Andrade]

  I am sorry I did not fully follow the discussions earlier.

  I only recall it was supposed to exist some compatibility
layer at some point.

  But I keep all the time needing to

$ sudo rm -f /var/lib/rpm/__db*

because I forget and use yum instead of dnf in rawhide.

  I am not really needing anything special, just install
a package, or run dnf update to update rawhide.

Thanks,
Paulo
-- 
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 vs yum

[Paulo César Pereira de Andrade]

2014-10-04 11:08 GMT-03:00 Reindl Harald h.rei...@thelounge.net:

  First think of me of as just an slightly above average user :)

 I am sorry I did not fully follow the discussions earlier.
 I only recall it was supposed to exist some compatibility
 layer at some point.

But I keep all the time needing to

 $ sudo rm -f /var/lib/rpm/__db*


 there is no need to do so

  I switched to using dnf because yum stopped working at
some point. I think it was something related to a libdb-5
update when only dnf would work.

 because I forget and use yum instead of dnf in rawhide.

 I am not really needing anything special, just install
 a package, or run dnf update to update rawhide


 but why do you think you need to touch anything below
 /var/lib/rpm/? that's the rpm database you should never
 touch without damned good reasons like follow dist-upgrade
 instructions

  I learned to do that (rm -f /var/lib/rpm/__db*) long long ago, as the
standard way to recover from minor rpm database corruption. But
I survived extreme cases where not even rpm --rebuilddb would
work. As long as the Packages database is not (completely) corrupted,
it should be possible to recover...

 you can happily use yum and dnf on the same setup
 all the time and the warnings rpm database modified
 or similar are harmless, you may even trigger them by
 touch the rpmdb by hand

  It does not work for me... I sent the email because, I again, forgot
and run
$ sudo yum update

and gone to another terminal, a bit later I learned that yum
thought all updates would be duplicates, so I did

$ sudo rm -f /var/lib/rpm/__db*
$ sudo dn update

sent the email, and now, update to latest rawhide has already
finished...

Thanks,
Paulo
-- 
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 vs yum

[Paulo César Pereira de Andrade]

2014-10-04 13:32 GMT-03:00 Matthew Miller mat...@fedoraproject.org:
 On Sat, Oct 04, 2014 at 11:02:23AM -0300, Paulo César Pereira de Andrade 
 wrote:
   I only recall it was supposed to exist some compatibility
 layer at some point.
   But I keep all the time needing to
 $ sudo rm -f /var/lib/rpm/__db*
 because I forget and use yum instead of dnf in rawhide.

 I'm not sure why you would need to do that because of running yum, but, one
 thing you can do is remove the yum package and install dnf-yum instead,
 which provides a /usr/bin/yum compatibility wrapper.

  Sorry for late reply. I was aware of dnf-yum, that I assume will magically
correct my problem.
  I did not remove plain yum so far on purpose, because I was expecting
it to be automatically replaced, or kept working, but only now I sent a note
about the problems I noticed :)

 --
 Matthew Miller
 mat...@fedoraproject.org
 Fedora Project Leader

Thanks,
Paulo
-- 
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 vs yum

[Paulo César Pereira de Andrade]

2014-10-04 18:23 GMT-03:00 Rahul Sundaram methe...@gmail.com:
 Hi

 On Sat, Oct 4, 2014 at 5:03 PM, Paulo César Pereira de Andrade

   I did not remove plain yum so far on purpose, because I was expecting
 it to be automatically replaced, or kept working, but only now I sent a
 note
 about the problems I noticed :)


 Would you filing a bug report against yum or dnf?  I use both
 interchangeability (for testing dnf) and I haven't run into this issue.

  I checked that I was talking from experience as 1 or more weeks
ago. For a single package install indeed, dnf and yum are now
working.

  I figured I have a lot of duplicates left from some earlier update,
for example:

$ rpm -q xz-libs
xz-libs-5.1.2-13alpha.fc22.x86_64
xz-libs-5.1.2-15alpha.fc22.x86_64
xz-libs-5.1.2-15alpha.fc22.i686

  So, I should work on some script to rpm -e --justdb the older ones.
The initial report in this thread was due to another kind of error, e.g.
yum update says among thousands of other lines:

xz-libs-5.1.2-15alpha.fc22.i686 is a duplicate with
xz-libs-5.1.2-13alpha.fc22.x86_64

but yum output could be good as input for some script attempting
to fix my rawhide, example:

4:texlive-zxjafbfont-svn28539.0-2.fc22.noarch is a duplicate with
4:texlive-zxjafbfont-svn28539.0-1.fc22.noarch
4:texlive-zxjafont-svn30105.0.2-2.fc22.noarch is a duplicate with
4:texlive-zxjafont-svn30105.0.2-1.fc22.noarch
4:texlive-zxjatype-svn28541.0.6-2.fc22.noarch is a duplicate with
4:texlive-zxjatype-svn28541.0.6-1.fc22.noarch

  Just to have an idea:

$ sudo yum update  /tmp/yum
$ wc -l /tmp/yum
3589 /tmp/yum
$ sudo dnf update  /tmp/dnf
$ wc -l /tmp/dnf
2 /tmp/dnf
$ cat /tmp/dnf
Dependencies resolved.
Nothing to do.

 https://fedoraproject.org/wiki/How_to_file_a_bug_report

 http://bugz.fedoraproject.org/dnf

  If I manage to make a clean bug report I will submit it. Rawhide changes
too fast that when one takes some time, and fills a bug report, it may have
been already fixed :)

 Rahul

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

rpath/runpath in binaries

[Paulo César Pereira de Andrade]

  Hi,

  I missed the memo about it not being a fatal error now (rpmlint still tells it
is an error), but just in case, before attempting to enforce it a
package review,
I checked what I have right now in my rawhide box...

$ for f in /usr/bin/*; do file $f | grep -q ELF  chrpath -l $f |
grep -v no rpath or runpath tag found; done
/usr/bin/afm2pl: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/afm2tfm: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/aleph: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/apper: RUNPATH=/usr/lib64/apper
/usr/bin/applygeo: RPATH=/usr/lib64
/usr/bin/bibtex: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/bibtex8: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/bibtexu: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/catman: RPATH=/usr/lib64/man-db
/usr/bin/certtool: RPATH=/usr/lib64
/usr/bin/chktex: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/crywrap: RPATH=/usr/lib64
/usr/bin/ctangle: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/ctie: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/cweave: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/danetool: RPATH=/usr/lib64
/usr/bin/dbus-binding-tool: RPATH=/usr/lib64
/usr/bin/dee-tool: RPATH=/usr/lib64
/usr/bin/detex: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dia: RPATH=/usr/lib64/dia
/usr/bin/disdvi: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dt2dv: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dumpiso: RPATH=/usr/lib64
/usr/bin/dv2dt: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dvi2tty: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dvibook: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dviconcat: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dvicopy: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dvilj: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dvilj2p: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dvilj4: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dvilj4l: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dvipdfmx: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dvipng: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dvipos: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dvips: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dviselect: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dvisvgm: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dvitodvi: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/dvitype: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/enca: RPATH=/usr/lib64
/usr/bin/eptex: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/euptex: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/eventlogadm: RPATH=/usr/lib64/samba
/usr/bin/fribidi: RPATH=/usr/lib64
/usr/bin/gegl: RPATH=/usr/lib64
/usr/bin/geotifcp: RPATH=/usr/lib64
/usr/bin/gftodvi: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/gftopk: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/gftype: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/ggobi: RPATH=/usr/lib64
`/usr/bin/gio-querymodules-32' probably isn't a 64-bit LSB-first ELF file.
elf_open: Exec format error
/usr/bin/gnutls-cli: RPATH=/usr/lib64
/usr/bin/gnutls-cli-debug: RPATH=/usr/lib64
/usr/bin/gnutls-serv: RPATH=/usr/lib64
/usr/bin/gsftopk: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/gvpack: RPATH=/usr/lib64/graphviz
/usr/bin/hbf2gf: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/htdb_dump: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db
/usr/bin/htdb_load: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db
/usr/bin/htdb_stat: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db
/usr/bin/htdig: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db
/usr/bin/htdump: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db
/usr/bin/htfuzzy: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db
/usr/bin/htload: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db
/usr/bin/htmerge: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db
/usr/bin/htnotify: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db
/usr/bin/htpurge: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db
/usr/bin/htsearch: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db
/usr/bin/htstat: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db
/usr/bin/julia-debug: RUNPATH=$ORIGIN/../lib64/julia:$ORIGIN/../lib64
/usr/bin/kpsewhich: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib
/usr/bin/ld.bfd: RPATH=/usr/lib64
/usr/bin/lexgrog: RPATH=/usr/lib64/man-db
/usr/bin/listgeo: RPATH=/usr/lib64
/usr/bin/luatex: 

Re: Looking for a package reviewer

[Paulo César Pereira de Andrade]

2014-09-14 10:12 GMT-03:00 Milan Bouchet-Valat nalimi...@club.fr:
 Hi!

  I would like to review it, and learn more about julia.

 I'm looking for a reviewer for my Julia package. It's been 9 months I've
 started working on it, and now I can't get anybody to do the final
 formal review.

 If anybody wants to swap reviews, please ping me. It should be pretty
 easy, most of the reviewing work has already be done.

 The report is here:
 https://bugzilla.redhat.com/show_bug.cgi?id=1040517

  I tried to do a fedora-review to get started, but it looks like you need
dSFMT:

DEBUG util.py:283:  Error: No Package found for dSFMT-devel

Looks like it is already approved:
https://bugzilla.redhat.com/show_bug.cgi?id=1108765
but you made the wrong request, you should write:

---%---
New Package SCM Request
===
Package Name: dSFMT
Short Description: Double precision SIMD-oriented Fast Mersenne Twister
Owners: laxathom nalimilan
Branches: f19 f20 f21 epel7
InitialCC:
---%---

instead of
---%---
Package Change Request
==
Package Name: dSFMT
Short Description: Double precision SIMD-oriented Fast Mersenne Twister
Upstream URL: http://www.math.sci.hiroshima-u.ac.jp/~%20m-mat/MT/SFMT/index.html
Branches: f20 f19 epel7
Owners: laxathom nalimilan
InitialCC:
---%---

otherwise it may not trigger the scripts that parse bugzilla, and also should
wait for a week day as people that actually manage the git repo may not do
it in weekends.

 Regards

Thanks,
Paulo
-- 
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: Issue during generating header files

[Paulo César Pereira de Andrade]

 Hi all.

  Hi,

 I don't understand why same code is not compiled with rpmbuild unlike
 when I compile in local.

 This is compiled with rpmbuild: http://fpaste.org/130139/
 This is compiled in local:  http://fpaste.org/130141/

 These commands are not performed so auto-header.h file is not created:

  ./bin/generate ./auto/scheme.tlo  auto/auto.c
  ./bin/generate -H ./auto/scheme.tlo  auto/auto-header.h

  Without looking at the spec, apparently it is not parallel make safe,
try removing %{?_smp_mflags} from the make arguments (and
comment about it).

  It should not be the case, but local build is also adding -I/usr/local/include
to gcc command line.

 Regards.

 - --
 Antonio Trande

 mailto: sagitterATfedoraproject.org
 http://fedoraos.wordpress.com/
 https://fedoraproject.org/wiki/User:Sagitter

Thanks,
Paulo
-- 
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: Two-minute(!)-survey on motivation and free time contribution of open source developers

[Paulo César Pereira de Andrade]

2014-08-31 11:03 GMT-03:00 Stefan Kullack stefankull...@web.de:
 Dear all,

 for a university research project in an Open Source class at the Technical
 University Berlin (Germany) I would like to gather some original input from
 open source software developers. I kept the length of the survey to an
 absolute minimum!!! The survey is supposed to capture the free time
 contribution and the primary motivation of open source software developers.

 It would be fantastic if you could spend two minutes on three simple
 questions!

 Here is the link to the survey: https://de.surveymonkey.com/s/MFKXYLP

 I highly appreciate the (short) time you take for filling it out!

  I think the last question misses a very important option, that is when
one believes implementations should be open, like in a math software,
if the formula is hidden and attempting to learn how it is done may even
be considered a criminal act, how can you prove it?

 Best regards,

 Stefan Kullack

 TU Berlin

Thanks,
Paulo
-- 
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: PkgDB, pending ACL requests

[Paulo César Pereira de Andrade]

2014-07-24 6:46 GMT-03:00 Pierre-Yves Chibon pin...@pingoured.fr:
 On Wed, Jul 23, 2014 at 04:25:54PM +0200, Pierre-Yves Chibon wrote:
 On Thu, Jul 17, 2014 at 03:28:56PM +0200, Pierre-Yves Chibon wrote:
  On Wed, Jul 09, 2014 at 10:05:25AM +0200, Pierre-Yves Chibon wrote:
   Good Morning everyone!
  
   In the version 1.13 of pkgdb2 a new API endpoint has been added that just
   provide the list of pending ACL requests:
   https://admin.fedoraproject.org/pkgdb/api/pendingacls
  
   I just wanted to share with you the first line of its output:
  
 # Number of requests pending: 5492
 
  Today we are at:
 
 # Number of requests pending: 5410
 
  So there is some improvements :)

 Today's number is:

 # Number of requests pending: 5151

 We got 341 requests that have been either accepted, rejected of withdrawn 
 over
 the last two weeks, but we still have some pending :)

 So don't forget to visit:
 https://admin.fedoraproject.org/pkgdb/acl/pending/

 I found out yesterday that this list contains pending ACL requests for package
 that have been retired.
 So I fix this in 1.18 (just deployed), so we're down to:

   # Number of requests pending: 4744

  A small suggestion could be for the person making a request to add
a small comment about the reason of it being asked.

  I have 2 pending commit acl requests (to 0ad) that I did not deny
because I thought it could be unpolite, but was not contacted in irc
or email (or possibly missed the request).

 Pierre

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

How to make a buildroot override for f21

[Paulo César Pereira de Andrade]

I am making an update and to speed things up I made overrides
for f19 and f20, but for f21 I get

Could not determine release for coin-or-Ipopt-3.11.8-1.fc21 with tags ['f21']

Probably this is just a ping to update infrastructure :-)

(updated coin-or-Ipopt is required for just approved coin-or-Bonmin
package)

Thanks,
Paulo
-- 
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: Packaging: bin subfolder

[Paulo César Pereira de Andrade]

2014-05-29 18:27 GMT-03:00 Sandro Mani manisan...@gmail.com:
 Hi,

  Hi,

 I'm working on packaging Salome (The Open Source Integration Platform for
 Numerical Simulation) [1], and the cmake scripts there install tons of

  I packaged and maintained it packaged in Mandriva for a few years.
If I recall correctly, it is (kind of) salome solution to avoid name clashes.

 binaries and python scripts to the /usr/bin/salome folder. Is this
 acceptable?

  I believe a symbolic link should be acceptable. Actually creating a subdir
would probably have a lot of opposition, but it should be possible to
reconfigure salome to use %_libexecdir/salome or %_libdir/salome

 Thanks,
 Sandro


 [1] http://www.salome-platform.org/

Paulo
-- 
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: Deprecate setjmp/longjmp? [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]

[Paulo César Pereira de Andrade]

2014-04-27 19:02 GMT-03:00 Andrew Price anpr...@redhat.com:
 On 24/04/14 15:13, Lennart Poettering wrote:

 We probably should make setjmp()-freeness a requirement for
 all code included in Fedora.


 Would it be worth the effort, and how feasible is it anyway?
 - Do we have any usage statistics?
 - How often do we see bugs caused by bad uses of setjmp/longjmp?
 - Is mitigation instead of blanket removal possible?
 - How likely is it that /all/ setjmp/longjmp uses can be reasonably
 replaced?
 - Is there existing upstream momentum to move away from setjmp/longjmp?

 (I'm not against the idea but I think it deserves further discussion.)

  I think setjmp and longjmp should be treated as a warning, and
replaced with sigsetjmp and siglongjmp, but not a fatal error, if I
recall correctly, grub has its own setjmp/longjmp implementation.
  Probably should be a rpmlint warning, like the one of libraries
that call exit.

 Andy

Paulo
-- 
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: Self Introduction: Oden Eriksson

[Paulo César Pereira de Andrade]

2014-04-03 7:50 GMT-03:00 Oden Eriksson o...@nux.se:
 Hello,

  Hi Oden,

  Small Linux world, isn't it ? :-)

 Been active with packaging, productization and maintaining packages for
 Mandriva Linux since 1999 and thought I should give it a try at fedora.

 First cut is this one:

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

 And, it seems I need a sponsor here. Anyone?

  If nobody with MariaDB and MySQL expertise that already commented
in your review request steps in, I will sponsor you.

 Cheers.

Paulo
-- 
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: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20

[Paulo César Pereira de Andrade]

2014-03-27 17:40 GMT-03:00 Adam Williamson awill...@redhat.com:
 On Thu, 2014-03-27 at 16:02 -0400, Adam Jackson wrote:
 We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so
 long before F21 and (among other goodies) it enables OpenGL 3.3 on some
 newer Radeons.  This implies rebasing LLVM 3.4, and that's where it gets
 a little awkward: the OpenGTL package only works up to LLVM 3.3.

 However, OpenGTL is dead upstream, and the only thing requiring it in
 F20 gold - calligra-krita, by way of libQtGTL - has already been updated
 to Obsolete OpenGTL.  As far as I know OpenGTL is the only such package
 we have requiring LLVM 3.3, so the rest of the rebase should just be a
 matter of updating to match F21.

 The following source packages will also be updated for the llvm rebase:

 dragonegg
 gambas3
 pocl
 pure
 python-llvmpy

 If there are no serious objections I'll try to get this all into testing
 early next week.  If you _do_ happen to be using OpenGTL for something
 in F20, now would be an excellent time for you to start working on
 porting it to current LLVM.

 I can absolutely see the reasons for doing this, but...can it at least
 go through a fesco rubber stamp? Let's face it, entirely deprecating a
 library we shipped as part of the gold release seems to be a pretty
 flagrant violation of the update policy, and really ought to be granted
 a formal exception at the very least if it's going to go ahead.

 As a result, we should avoid major updates of packages within a stable
 release. Updates should aim to fix bugs, and not introduce features,
 particularly when those features would materially affect the user or
 developer experience.
 ABI changes in general are very strongly discouraged

 https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases

 Fedora *is* a platform, not just a set of packages, however half-assedly
 we conform to that vision, so I guess I just feel a bit uncomfortable
 not at least putting up a few hoops for this to jump through. :)

  This patch may be useful:
https://abf.rosalinux.ru/openmandriva/opengtl/blob/master/opengtl-0.9.18-llvm-3.4.patch

 --
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
 http://www.happyassassin.net

Paulo
-- 
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 swap - coin-or-Osi

[Paulo César Pereira de Andrade]

The package follows the same pattern of other coin-or
packages already in Fedora, should be trivial do review.

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

Thanks,
Paulo
-- 
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 swap - coin-or-Osi

[Paulo César Pereira de Andrade]

2013/11/1 Antonio Trande anto.tra...@gmail.com:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 11/01/2013 04:36 PM, Paulo César Pereira de Andrade wrote:
 The package follows the same pattern of other coin-or packages
 already in Fedora, should be trivial do review.

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


 Hi Paulo.

  Hi Antonio,

 I can take it.

  Thanks!

 Don't worry about the swap; I have some packages but they are not
 ready for the review yet.  ;)

  I am updating all other coin-or-* packages, but they need to be built
in the proper order, so I will have others ready to review once this one
is done :-)

 - --
 - 
 Antonio Trande

 mailto: sagit...@fedoraproject.org
 http://www.fedoraos.worpress.com
 https://fedoraproject.org/wiki/User:Sagitter

Paulo
-- 
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: 20131006 changes

[Paulo César Pereira de Andrade]

2013/10/7 Jerry James loganje...@gmail.com:
 On Sun, Oct 6, 2013 at 7:36 AM, Fedora Rawhide Report
 rawh...@fedoraproject.org wrote:
 sagemath-5.10-2.fc21
 
 * Fri Oct 04 2013 pcpa paulo.cesar.pereira.de.andr...@gmail.com - 5.10-2
 - Rebuild with newer rawhide atlas.

 The previous version of sagemath was 5.10-4.  Why did the release
 number go backwards?

  I messed things up, due to several build trees and not paying as much
attention as I should, while attempting to do too many things at the
same time, and updating sagemath while waiting some builds...
  I can resubmit it. In the meantime, if you could review the libgap bug
report it would help a lot, for sagemath 5.11 it is not optional.

 --
 Jerry James
 http://www.jamezone.org/

Paulo
-- 
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: fflas-ffpack needs update for atlas in rawide

[Paulo César Pereira de Andrade]

2013/10/3 Jerry James loganje...@gmail.com:
 On Wed, Oct 2, 2013 at 8:57 AM, Jerry James loganje...@gmail.com wrote:
 Does anybody know what progress is being made towards getting a
 working atlas package on ARM?  Thanks,

 Big thanks to Orion for fixing the atlas build on ARM.  Paulo,
 fflas-ffpack and linbox have now been rebuilt for the new atlas.  You
 should be able to rebuild sagemath now.  Let me know if you want me to
 do the build for you.

  Thanks!

  I started working on updating to sagemath 5.11 but besides the problems
in the update, I was stuck with the fflas-ffpack and linbox issues.
  It should be required to review this now:

$ grep -i atlas ~/fedora/sagemath/*
/home/pcpa/fedora/sagemath/sagemath.spec:BuildRequires: atlas-devel
/home/pcpa/fedora/sagemath/sagemath.spec:# ensure proper/preferred
libatlas is in linker path
/home/pcpa/fedora/sagemath/sagemath.spec:perl -pi -e
's|^(extra_link_args = ).*|$1\[-L%{_libdir}/atlas\]|;'
sage/misc/cython.py
/home/pcpa/fedora/sagemath/sagemath.spec:# o link with proper atlas
/home/pcpa/fedora/sagemath/sagemath.spec:# make atlas/blas
available to compiled sources
/home/pcpa/fedora/sagemath/sagemath.spec:   's|^(extra_link_args
=).*|$1 [-L%{_libdir}/atlas]|;'  \
/home/pcpa/fedora/sagemath/sagemath.spec:export
LD_LIBRARY_PATH=%{buildroot}%{_libdir}:%{_libdir}/atlas:$LD_LIBRARY_PATH

as rawhide atlas should no longer match the atlas bundled in sagemath.

  If you want to look in the above, just check build logs, feel free to
rebuild it, but I am afraid it may not be too easy.

 Regards,
 --
 Jerry James
 http://www.jamezone.org/

Paulo
-- 
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: DeveloperAssistant and android development under Fedora 19

[Paulo César Pereira de Andrade]

2013/8/8 Petr Hracek phra...@redhat.com:
 Hi folks,

  Hi,

 I would like to ask you what are necessary steps to develop
 android applications under Fedora.

 I suppose that Eclipse environment is needed.
 Any other package(s)?
 Is there any guide how to do that?

 When some working guide will be ready then it will be a part of
 DeveloperAssistant
 which is already part of Fedora 19.
 https://github.com/bkabrda/devassistant
 https://fedoraproject.org/wiki/Features/DevelopersAssistant

 My idea how it should work is to install necessary packages (as usually)
 and create a sample project which should help with developing android
 application
 under Fedora.

 Any hints will be welcome.

  I think very few bits are missing to make it work with native fedora
eclipse. Someone experienced with eclipse and eclipse packaging
should not have much trouble checking what is missing after installing
the (eclipse bundled) sdk:

http://developer.android.com/sdk/index.html

  No idea about the adt stuff, but for sure could be built as native
rpm packages, well, at least as an exercise to make sure every
bit is really opensource...

 --
 Best regards / S pozdravem
 Petr Hracek

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Paulo
-- 
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: gdcm FTBFS: texlive broken in rawhide?

[Paulo César Pereira de Andrade]

2013/8/6 Jan Kratochvil jan.kratoch...@redhat.com:
 On Mon, 05 Aug 2013 20:38:27 +0200, Mario Ceresa wrote:
 --
 -- vtk-devel-6.0.0-7.fc20.x86_64
 Error: Package:
 3:texlive-dvips-bin-svn30088.0-0.3.20130608_r30832.fc20.1.x86_64 (build)
 Requires: texlive-kpathsea-lib = 3:2013-0.3.20130608_r30832.fc20
 Installing: 3:texlive-kpathsea-lib-2013-0.3.20130608_r30832.fc20.1.x86_64
 (build)
 ---

 I have the same error building GDB.

  I am also waiting for it to be fixed, and guess there are plenty others :-(

 There is F-20 mass-rebuild FTBFS for texlive itself:
 https://bugzilla.redhat.com/show_bug.cgi?id=992788

 Package owner Jindrich Novy is no longer in Red Hat so I am not sure how
 quickly it may get fixed.

  Appears to be not too difficult to correct:

DEBUG util.py:264:  Error: Package:
3:texlive-dvips-bin-svn30088.0-0.3.20130608_r30832.fc20.1.x86_64
(build)
DEBUG util.py:264: Requires: texlive-kpathsea-lib =
3:2013-0.3.20130608_r30832.fc20
DEBUG util.py:264: Installing:
3:texlive-kpathsea-lib-2013-0.3.20130608_r30832.fc20.1.x86_64 (build)
DEBUG util.py:264: texlive-kpathsea-lib =
3:2013-0.3.20130608_r30832.fc20.1

  Just ensure provides/requires match and resubmit it?

 Jan

Paulo
-- 
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: gdcm FTBFS: texlive broken in rawhide?

[Paulo César Pereira de Andrade]

2013/8/6 Simone Caronni negativ...@gmail.com:
 On 6 August 2013 17:38, Jan Kratochvil jan.kratoch...@redhat.com wrote:

 Package owner Jindrich Novy is no longer in Red Hat so I am not sure how
 quickly it may get fixed.


 I really hope the next mantainer can manage a 14 mb spec file :)

  In Mandriva I did a work very similar to current Fedora texlive, but I did
create almost 3k packages so that could update only was really required;
it should be possible to live with around 1.6k packages, but I preferred
to let upstream handle dependencies,  and match 1 to 1 upstream
packages (http://mirrors.ctan.org/systems/texlive/tlnet/archive). But,
I am still to start updating it again, now in OpenMandriva, was just left
in a stable state as of like 6 months ago...

  But something like that would not be viable in Fedora, if needing a
review request and approval for every small package...

 Regards,
 --Simone




 --
 You cannot discover new oceans unless you have the courage to lose sight of
 the shore (R. W. Emerson).

 http://xkcd.com/229/
 http://negativo17.org/

Paulo
-- 
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: heads up - Qt qreal difference on ARM

[Paulo César Pereira de Andrade]

2013/8/2 Adam Jackson a...@redhat.com:
 On Fri, 2013-08-02 at 11:38 +0200, Florian Weimer wrote:
 On 08/02/2013 09:45 AM, Richard W.M. Jones wrote:
  Judging by a google search for qreal float arm this difference
  causes endless problems.  I even found a Fedora build bug related to it.
 
  However it's a matter for upstream to fix it.  Not something we could
  carry around only in Fedora IMHO.

 I would expect that consistency across Fedora architectures is more
 important than alignment to upstream.

 If we're going to start casually disregarding binary portability between
 Fedora and other Linuxes, this is not where I'd start.

  Last time I looked at it, it was not easy either, because there was too
much inline asm for 32 bit float, so, was not just switching some typedef.
  qreal as float also causes a lot of other problems because everybody
expects qreal to be double, even when expanding those inline functions
with a constant argument, need to cast it to float or it will not compile.
  Most trouble I had was python bindings, because there are too many
dynamically generated files, and it is not trivial to patch those to create
temporary vectors to convert float vectors to/from double vectors.

 - ajax

Paulo
-- 
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: Rebuild of Boost dependees

[Paulo César Pereira de Andrade]

2013/7/30 Jerry James loganje...@gmail.com:
 On Mon, Jul 29, 2013 at 10:01 AM, Petr Machata pmach...@redhat.com wrote:

 polybori5663365 SCONS: internal error in regular
 expression engine


 I will try to figure this one out.

  This should be 32 bit only.
http://bugs.python.org/issue17998

It should be possible to workaround the problem in polybori's SConstruct, just
that the trivial solution does not work, but I did not notice any problems after
rebuilding python with the patch in the bugs.python.org report...

 --
 Jerry James
 http://www.jamezone.org/

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Paulo
-- 
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: Following MPI packaging guidelines

[Paulo César Pereira de Andrade]

 Hi all.

 I'm editing .spec file of MUMPS package to conform it to the MPI
 packaging guidelines (http://fedoraproject.org/wiki/Packaging:MPI). I
 have a modest experience in this particular case so I need some
 suggestions.

 This is initial .spec file of MUMPS:
 http://pkgs.fedoraproject.org/cgit/MUMPS.git/tree/MUMPS.spec

 This is that adjusted according to the MPI packaging guidelines:
 http://sagitter.fedorapeople.org/MUMPS/MUMPS.mod.spec

 As you see, I have created the packages

 - - MUMPS-openmpi
 - - MUMPS-openmpi-devel
 - - MUMPS-common

 Upstream provides illustrative test programs showing how MUMPS can be
 used in examples/ directory; Can I package these programs in
 'MUMPS-common' package ? They are located in dedicated directory in
 /usr/share.

 'MUMPS-openmpi' contains all versioned libraries; I don't know if it's
 correct or the package must be named 'MUMPS-openmpi-libs'

 Should all .h files be in a '-headers' subpackage ?
 Now, they are 'MUMPS-openmpi-devel'.

 This phrase in MPI guidelines is little clear for me:

 Software that supports MPI MUST be packaged also in serial mode [i.e.
 no MPI], if it is supported by upstream.

 What does mean serial mode ? :)

  MUMPS.mod.spec appears good. I would use the environment variables
($MPI_LIB and $MPI_INCLUDE) after module load mpi but the definitions
should be good enough.

  About what is serial mode, you should refactor MUMPS.spec to also make
a build with openmpi disabled. Should do two builds in MUMPS.spec, and
install the build that does not need module load mpi to work installed in
%{_libdir}, and the one that needs, installed in $MPI_LIB

 - 
 Antonio Trande

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 for IBM System z 64bit official release

[Paulo César Pereira de Andrade]

2013/7/16 Dan Horák d...@danny.cz:
 Hello everyone,

  Hi,

  Sorry for offtopic,

 Fedora 19 GA release for the IBM System z is here. This time two weeks
 later than the primary mainly because me being on vacation. It's hard
 for me to take time off work when there are always some deadlines in
 sight :-) And again we are closer to primary when we count the number
 of available packages.

  Is it possible to get an ssh account on a system z? I would like
to work on a port of gnu lightning for it. I ported to all hosts available
in the gcc build farm, and am only missing currently alpha from
snakebite.net, that I am deferring as I am finishing an aarch64
port :-)

https://savannah.gnu.org/projects/lightning/

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Who uses abi-compliance-checker?

[Paulo César Pereira de Andrade]

IBook. 'Kiomjm
Em 03/07/2013 19:00, Xavier Bachelot xav...@bachelot.org escreveu:

 On 07/03/2013 10:03 PM, Richard Shaw wrote:
  I initially got abi-compliance-checker into Fedora because one of my
 packages
  does not maintain any sort of API/ABI compatibility or even versioning
 for that
  matter. That way I could always check a new release to see if any of its
  dependencies needed to be rebuilt.
 
  Since then, I've started using it for all of my libraries in the spirit
 of
  Trust but verify, and I've occasionally found issues even though
 upstream
  didn't bump the soversion.
 
  So out of curiosity, anyone else using this great tool?
 
 I'm not using abi-compliance-checker by itself but through the pkgdiff
 wrapper.
 I agree this tool is very helpful.

 Regards,
 Xavier

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Who uses abi-complian. V. I UVce-checker?

[Paulo César Pereira de Andrade]

/  lo m'
Em 03/07/2013 21:16, Richard Shaw hobbes1...@gmail.com escreveu:

 On Wed, Jul 3, 2013 at 4:33 PM, Sérgio Basto ser...@serjux.com wrote:

 On Qua, 2013-07-03 at 15:03 -0500, Richard Shaw wrote:
  I initially got abi-compliance-checker into Fedora because one of my
  packages does not maintain any sort of API/ABI compatibility or even
  versioning for that matter. That way I could always check a new
  release to see if any of its dependencies needed to be rebuilt.
 
 
  Since then, I've started using it for all of my libraries in the
  spirit of Trust but verify, and I've occasionally found issues even
  though upstream didn't bump the soversion.
 
 
  So out of curiosity, anyone else using this great tool?
 
 
  If anyone is curious about it, I don't mind typing up the process I go
  through to make the checks. I think I've found a pretty good path of
  least resistance method :)

 could we use this tool on x264/ffmpeg/mplayer packages ?


 Yes, I'm trying it out, but it looks like there's some windows only
 headers installed trying to include d3d9.h which are tripping it up...

 Richard

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

attachment: ic_launcher.png-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libgd breakage

[Paulo César Pereira de Andrade]

2013/6/28 Adam Williamson awill...@redhat.com:

   Almost there, but still cannot generate chroot in mock.

 DEBUG util.py:264:  Error: Package: gnuplot-4.6.2-2.fc20.x86_64 (build)
 DEBUG util.py:264: Requires: libgd.so.2()(64bit)

 gnuplot appears to be failing on some sort of texlive-related nonsense:

 Execute script `gnuplot.lg'
 /usr/bin/t4ht: line 2: -f/gnuplot: No such file or directory
 /usr/bin/t4ht: line 3: -f/gnuplot: No such file or directory
 /usr/bin/t4ht: line 4: -f/gnuplot: No such file or directory
 --- error --- improper command line

 and then it just appears to loop over the tex4ht usage message forever
 and ever. I don't know if the error is in texlive-tex4ht-bin (which

  It fork bombs for me, and dies a bit later.

 provides /usr/bin/t4ht and /usr/bin/tex4ht), or in how gnuplot is
 calling it. (But I don't have time to figure out that crap, so I'm just
 going to yum remove gnuplot...)

It is not parsing correctly arguments, and t4ht does not check
arguments:

$ cat /usr/bin/t4ht
#!/bin/sh
$1 $2
$1 $2
$1 $2
tex4ht $2
t4ht $2  $3

on f18 at least, and other distros t4ht is a real binary:
$ t4ht --help

t4ht.c (2012-07-25-19:28 kpathsea)
t4ht --help
--- error ---

t4ht [-fdir char]filename ...
  -b ignore -d -m -M for bitmaps
  -c...  choose named segment in env file
  -d...  directory for output files   (default:  current)
  -e...  location of tex4ht.env
  -i debugging info
  -g ignore errors in system calls
  -m...  chmod ... of new output files (reused bitmaps excluded)
  -p don't convert pictures   (default:  convert)
  -r replace bitmaps of all glyphs(default:  reuse old ones)
  -M...  chmod ... of all output files
  -Q quit, if tex4ht.c had problems
  -S...  permission for system calls: *-always, filter
  -X...  content for field %%3 in X scripts
  -  content for field %%2 in . scripts

Example:
   t4ht name -d/WWW/temp/ -etex4ht-32.env -m644



but on rawhide:
$ t4ht --help
 fork bombs -- do not try 

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libgd breakage

[Paulo César Pereira de Andrade]

2013/6/28 Volker Fröhlich volke...@gmx.at:
 On 27/06/13 17:31, Orion Poplawski wrote:

 On 06/26/2013 08:01 AM, Volker Fröhlich wrote:


 GDAL is currently broken because it needs a rebuild for Poppler, but the
 Texlive build is broken, as far as I can see.


 texlive has now been rebuilt.


 We've got a working GDAL build again.

  Almost there, but still cannot generate chroot in mock.

DEBUG util.py:264:  Error: Package: gnuplot-4.6.2-2.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libgd.so.2()(64bit)

Also cannot update my rawhide computer (yum loops forever if I
run with --skip-broken), after yum erase sagemath gnuplot still
fails:

Error: Package: libsss_sudo-1.10.0-7.fc20.beta1.x86_64 (@rawhide)
   Requires: sssd = 1.10.0-7.fc20.beta1
   Removing: sssd-1.10.0-7.fc20.beta1.x86_64 (@rawhide)
   sssd = 1.10.0-7.fc20.beta1
   Updated By: sssd-1.10.0-13.fc20.x86_64 (rawhide)
   sssd = 1.10.0-13.fc20

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

libgd breakage

[Paulo César Pereira de Andrade]

  Hi,

  It is taking a bit too long for some dependencies to be rebuilt
in rawhide.

  Could a compat-libgd be provided please? I am receiving daily
mails about broken deps, already posted to $pkg-owner@ asking
what I could help, but still no response neither problems corrected.
Remi Collet told me it appears there are some FTBFS packages in
the cycle.

  I would like to also start working on packaging sagemath 5.10,
but am not providing as much time to work on fedora as I would
want, so also not providing a compat-libgd sample package,
sorry...

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libgd breakage

[Paulo César Pereira de Andrade]

2013/6/26 Remi Collet fed...@famillecollet.com:
 Le 26/06/2013 14:36, Paulo César Pereira de Andrade a écrit :
   Hi,

   It is taking a bit too long for some dependencies to be rebuilt
 in rawhide.

   Could a compat-libgd be provided please? I am receiving daily
 mails about broken deps, already posted to $pkg-owner@ asking
 what I could help, but still no response neither problems corrected.
 Remi Collet told me it appears there are some FTBFS packages in
 the cycle.

 As none of the FBTFS are related to libgd, I don't see any value to have
 a compat-libgd package.

  I see this failure in root.log:

DEBUG util.py:264:  Error: Package: gnuplot-4.6.2-2.fc20.i686 (build)
DEBUG util.py:264: Requires: libgd.so.2
DEBUG util.py:264:  Error: Package: gdal-libs-1.9.2-7.fc20.i686 (build)
DEBUG util.py:264: Requires: libpoppler.so.34
DEBUG util.py:264:  Error: Package:
2:texlive-dvipng-bin-svn30088.0-24.20130531_r30819.fc20.i686 (build)
DEBUG util.py:264: Requires: libgd.so.2
DEBUG util.py:264:  Error: Package: gdal-1.9.2-7.fc20.i686 (build)
DEBUG util.py:264: Requires: libpoppler.so.34
DEBUG util.py:264:  Error: Package:
2:texlive-pdftex-bin-svn30088.0-24.20130531_r30819.fc20.i686 (build)
DEBUG util.py:264: Requires: libpoppler.so.34
DEBUG util.py:264:  Error: Package:
2:texlive-luatex-bin-svn30739.0-24.20130531_r30819.fc20.i686 (build)
DEBUG util.py:264: Requires: libpoppler.so.34
DEBUG util.py:264:   You could try using --skip-broken to work around
the problem

s/i686/x86_64/ for the x86_64 build error. This is happening for almost
two weeks I believe.

  Sorry for posting to the devel list, but I thought it could be required
to attract the proper attention.

 Remi.


   I would like to also start working on packaging sagemath 5.10,
 but am not providing as much time to work on fedora as I would
 want, so also not providing a compat-libgd sample package,
 sorry...

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Software Management call for RFEs

[Paulo César Pereira de Andrade]

2013/5/22 Björn Persson bj...@xn--rombobjrn-67a.se:
 Jan Zelený wrote:
 what are the changes that you would like to see in the foreseeable
 future (say 2-3 years) and why would you like to see them (what would they
 help you with)?

 Dare I say ... (puts on a helmet) ... Recommends and Suggests?

 We really should have a way for Yum and Packagekit to say Hey, if
 you're installing that, maybe you also want this?. A -devel package
 and its corresponding -doc package should recommend each other for
 example. They shouldn't require each other, because then they could
 just as well be the same package, but usually you want to install them
 together and it would be helpful to at least notify users who install
 the -devel package that the -doc package also exists.

 Another example is a database server and its command line client, which
 you often but not always want to install together. The server should
 recommend the client, while the client might only suggest the server.

 A third example is graphical administration tools for some daemon that
 are in a separate package so that the daemon can be installed without
 pulling in half a desktop environment. In this case the daemon should
 suggest the tools, but perhaps not recommend them.

  The only few times I used Suggests (in Mandriva) was to suggest
optional, but better experience/functionality if installed, packages in
non-free, but I think I never fully understood what it is supposed to
mean, just that it is a Requires that does not break dependencies.

 Björn Persson

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Software Management call for RFEs

[Paulo César Pereira de Andrade]

2013/5/22 Jan Zelený jzel...@redhat.com:
 Dear Fedora community,
 several months ago, at the Developer conference in Brno, Software Management
 team received a whole bunch of proposals for new functionality in RPM and
 related software stack.

  As a packager, some way to transparently handle an upgrade when a
directory changes to a symlink or vice-versa.

  A minor, extra checking one that I was hit recently was lack of checking
a package that have a symlink to /builddir/some-where, and would only work on
my computer because the symlink did point to /home/pcpa/rpmbuild/BUILD/...

  As an user, some way to, but mostly adding some policy, to have multiple
sonames of a library installed. Usually only useful to avoid a window of time
with broken dependencies, but sometimes useful to have some package
that only works with an older version of some library functional, without
blocking an update.

 Thank you in advance for your participation
 Jan

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Pending soname bumps for m4ri, m4rie, and ntl

[Paulo César Pereira de Andrade]

2013/5/3 Jerry James loganje...@gmail.com:

  Hi,

  Sorry for the delay responding.

 I would like to push updates for m4ri 20130416, m4rie 20130416, and
 ntl 6.0.0 to Rawhide.  Each of those updates involves an soname bump.
 This will require rebuilds of the following packages:

 eclib
 flint
 latte-integrale
 linbox
 Macaulay2
 polybori
 sagemath
 Singular

 I have built all of these in mock (although the sagemath build is
 still going; that one takes awhile!).  This also incidentally fixes
 the Macaulay2 failure to build due to a bug in latte-integrale, Rex.
 Sorry that has taken so long, but I just got the patch from upstream
 to fix the problem this morning.

  I started working on updating to sagemath 5.9 that was just
released. But if the 5.8 build finished, and most likely did, as
most of the time is spent building documentation, it should
be ok to update.

 I can handle all of the rebuilds unless any of the maintainers want to
 do it themselves.

 If the Singular maintainer is interested, I have worked out how to
 update it to 3-1-6, and also enable the polymake interface at the same
 time.  Let me know if you would like me to do that as part of the
 rebuild.  We should also consider making a flint-compat or flint1
 package, so we can upgrade the flint package to version 2, unless
 sagemath can be adapted to flint 2.x without too much trouble.
 Singular wants version 2.

  The Singular abi/api is somewhat volatile, so, I prefer to keep
at the version used by sagemath. Testing/updating after the m4ri
and m4rie updates should be a better plan.

 If the other maintainers involved will let me know how they would like
 to handle this, I can either coordinate the rebuilds or do them
 myself.

 Regards,
 --
 Jerry James
 http://www.jamezone.org/

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Pending soname bumps for m4ri, m4rie, and ntl

[Paulo César Pereira de Andrade]

2013/5/6 Jerry James loganje...@gmail.com:
 On Mon, May 6, 2013 at 8:18 AM, Paulo César Pereira de Andrade
 paulo.cesar.pereira.de.andr...@gmail.com wrote:
   I started working on updating to sagemath 5.9 that was just
 released. But if the 5.8 build finished, and most likely did, as
 most of the time is spent building documentation, it should
 be ok to update.

 No, the build failed because of the new version of NTL.  Sagemath's
 ntl_wrap.{h,cpp} assume that many of the fundamental types (ZZ, ZZ_p,

  Ok. This will not be one of the easy updates, as sagemath 5.9
besides not changing much build requires from sagemath 5.8,
had a lot of refactoring on the key portions of the rpm package
build.

 ZZX, etc.) are structs.  In NTL 6.0.0, they are classes, not structs.
 I've got a patch to adapt sagemath to this, but didn't have time to
 test it over the weekend.  I've just started a test build.

  If it works for sagemath 5.8, updating for sagemath 5.9 should
be trivial.

 If the build succeeds, what would you like me to do?  I can send you
 the patch, and you can work it into the 5.9 update, or I can do a
 build of 5.8 with the patch.

  This is fine, feel free to rebuild sagemath 5.8 in rawhide if you
think it is required to avoid breakage for some time/days. If
everything goes fine, I will add your patch to the sagemath 5.9
package.

   The Singular abi/api is somewhat volatile, so, I prefer to keep
 at the version used by sagemath. Testing/updating after the m4ri
 and m4rie updates should be a better plan.

 OK, that makes sense.

 Rex, are you okay with me going forward with the rebuilds, or would
 you like to handle your own?
 --
 Jerry James
 http://www.jamezone.org/

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BuildRequires for texlive stuff for F18 and beyond

[Paulo César Pereira de Andrade]

2013/1/26 Sérgio Basto ser...@serjux.com:
 On Sex, 2013-01-25 at 12:56 -0800, Benjamin De Kosnik wrote:
   [...]
   With the more fine grained texlive packaging in F18 where
   tex(latex) is provided by texlive-collection-latex I am finding
   that this is insufficient to build most documents. I see two
   options in these cases:
  
   1) Add BuildRequires; texlive-collection-latexextra  (nb.
   texlive-collection-latexrecommended isn't usually sufficient)

 Yes. Do this.

  I did split texlive some time ago for Mandriva, and to avoid
dependency problems, what I did was to make the default
install require texlive-scheme-medium, texlive-scheme-xml
texlive-collection-latexextra and texlive-tlpkg.

  There is significantly complex logic in the script to translate
from the texlive metadata to specs, but in the end there were
no dependency problems, other then from time to time people
not happy with installing way more packages than required.

  The script with a lot of quirks and logic to provides for
tetex (no longer used in Mandriva), etc, is:

http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/texlive-tlpkg/current/SOURCES/tlpobj2spec.pl

If only building info docs, the texinfo package was modified
to install minimal dependencies, that is, it has a
requires to texlive-collection-texinfo

 I think, especially now as this dep tuning is going on, that the first
 step should be to bring out these big gun dependencies like:

 BuildRequires: texlive-collection-latexextra

 And get stuff working quickly.

 After the dust has settled with the transition and deps are even
 slightly modularized (from the old latex), then maybe at a future
 date the Deps can be investigated with more granularity, and
 the texlive-collections can be optimized.

 For
 /usr/share/doc/VirtualBox-4.2.6/UserManual.pdf
 /usr/share/doc/VirtualBox-4.2.6/UserManual_fr_FR.pdf

 I need add
 %if 0%{?fedora} = 18
 BuildRequires:  doxygen-latex
 BuildRequires:  texlive-collection-fontsrecommended
 BuildRequires:  texlive-ec
 BuildRequires:  texlive-ucs
 BuildRequires:  texlive-tabulary
 BuildRequires:  texlive-fancybox
 %endif

 texlive-collection-latexextra seems is not required

  Not for your specific case :-) A generic solution needs it.

  I believe upstream texlive should be made aware of a few
texlive-foo that should be in the base texlive-collection-latex,
becase if I recall correctly, only 2 or 3 are commonly used,
but I am just suggesting something that was in my todo...

 Regards,
 --
 Sérgio M. B.

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [rawhide] ideas to improve rawhide

[Paulo César Pereira de Andrade]

2013/1/23 Kevin Fenzi ke...@scrye.com:
 Greetings.

 As some of you may know, I switched my laptop over to rawhide and have
 been posting a series of blogs about the various issues I have run into
 in the last month.

[...]

 So, I've been collecting ideas on how to improve things in rawhide and
 have made a wiki page for these ideas.

 https://fedoraproject.org/wiki/Rawhide_improvement_project_2013

 I know some folks at fudcon were talking about rawhide improvements too,
 so hopefully we will see those proposed before too long as well.

 I've tried to suggest things that won't disrupt maintainers much while
 making things nicer for consumers. Some of these things I have already
 discussed with folks involved and we are going to try and do them,
 others are needing more fleshing out/discussion.

 I'm very open to more ideas or thoughts, or comments/people willing to
 work on items from the above wiki page.

 Thoughts?

  Out of curiosity, are you experiencing this, or am I just unlucky?
https://bugzilla.redhat.com/show_bug.cgi?id=894623
(I did not debug it and am using a f18 computer for local runs of
fedora-review or mock).
Otherwise, I noticed rawhide appears to be better tested now, and
I did no longer see consecutive non booting upgrades, e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=789285
Other breakages I noticed are usually small or short lived, most
drastic one was firefox not working for a small window of time.

 kevin

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git rebase request on a project

[Paulo César Pereira de Andrade]

2013/1/21 Stanislav Ochotnicky sochotni...@redhat.com:
 Quoting Stephen Gallagher (2013-01-18 15:27:30)
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On Fri 18 Jan 2013 06:55:26 AM EST, Paulo César Pereira de Andrade
 wrote:
Sorry if this is a dumb question, but I cannot find any information.
 
I would like to have git rebase master on f16, f17, and f18
  branches of  http://pkgs.fedoraproject.org/cgit/megaglest.git
  I once messed it a bit by adding a commit only to branches and
  later merging master, now I cannot merge without a merge master
  commit, and am not allowed to push myself a git rebase master
  branch.


 Rebases like that are not permitted in Fedora because they rewrite
 history (and therefore mean we wouldn't be able to exactly recreate an
 older build if we needed to). You're going to have to do the merge and
 manage the merge conflicts appropriately (either via 'git merge' or by
 starting from the tarball and working your way up again without a merge
 commit).

 If I understood Paulo correctly, he merely wanted to linearize his history so 
 he
 can continue doing fast-forward merges again. I've cross-merged branches so 
 that
 they are now again on the same hash. Content of all branches (f16+) was the 
 same
 so they were all without conflicts.

  Exactly, I want to do fast-forward merges, but I messed sometime
ago by pushing a commit only to branches.
  I also did not properly explain what I did want to push, it would be
basically:

$ fedpkg clone megaglest
$ cd megaglest
$ for branch in f16 f17 f18; do
  fedpkg switch-branch $branch
  git rebase master
  git rebase --skip
  done
$ git push --all

  But then I messed even more because I was not allowed to
push that.

  The conflict would be Package currently is x86 specific (#855736)
commit. But I think better to not try to fix it by adding that commit
to master now.
  The above would be to clean the history and remove the series
of Merge branch ... from the history, but it would be a cosmetic
change.

 For future, please do everything in master first :-)

  Thanks, I learned my lesson :-)

 Enjoy,

 --
 Stanislav Ochotnicky sochotni...@redhat.com
 Software Engineer - Base Operating Systems Brno

 PGP: 7B087241
 Red Hat Inc.   http://cz.redhat.com

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange Build problem....

[Paulo César Pereira de Andrade]

2013/1/19 Nicolas Mailhot nicolas.mail...@laposte.net:

 Le Mer 16 janvier 2013 20:48, Paulo César Pereira de Andrade a écrit :

   Sorry for that problem. It solved the problems I was having
 but created at least yours problem. I am having an almost live
 conversation right now about related issues at

 BTW the Fedora font packaging guidelines have been very carefully written
 to prohibit the “solution” proposed : when upstreams move to a newer,
 better font format you have to support it in your application and not
 cheat by bundling a version converted to some other format with your app.

 The reason being that all such conversions are lossy, they get out of sync
 with upstream, they bloat the distribution, and you end up with a giant
 pile of fonts in every possible format, each one with different properties
 and problems, driving users crazy because they don't understand why the
 “same” font behaves differently in different apps (or sometimes different
 parts of the same app).

  I was trying to test the options upstream suggested:
-%-
1) Include the STIX ttf fonts included with matplotlib in the matplotlib
package and install them in `matplotlib/mpl-data/fonts/ttf` (as a
vanilla install would do) so as not to conflict with the stix-fonts
package.  Maybe these go in a python-matplotlib-stix-fonts package.

2) Include a version of the STIX fonts converted to ttf.  This will
still have the problem that the glyph tables in matplotlib need to be
updated to use them.

3) Update matplotlib's freetype wrapper to support .otf fonts. Doable,
but considerable work.

4) Leave it as is but warn that STIX font support is broken with the
Fedora matplotlib package.
-%-
  So, at first I did test (only) option 1 and only in my computer.

  After that, all I did was to keep USE_FONTCONFIG = True
but correct all the bugs it uncovered. I am a bit unsure if
the patch in
https://bugzilla.redhat.com/show_bug.cgi?id=896182
was really required, as I could not reproduce the problem
after applying
https://github.com/matplotlib/matplotlib/pull/1666
but I but added it anyway just in case
http://pkgs.fedoraproject.org/cgit/python-matplotlib.git/commit/?id=b58a0f66d32e94144c51272fc40257b5be95baec

 TexLive is unfortunately a pathological example of the morass you can
 create by letting application authors procrastinate on supporting newer
 font formats.

 Besides we have lots of fonts in otf format in Fedora, and matplotlib can
 not use any of them right now. Are you going to bundle them in another
 format too?

  Do you have any hints on working on option 3? Well, that means not
using fontconfig, so might not be worth for a generic Linux solution...

  Option 2 is basically convert stix 1.1 to the format of the bundled
stix 1.0 fonts, but install those as system packages (this is also a
solution not using fontconfig).

 Regards,

 --
 Nicolas Mailhot

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

git rebase request on a project

[Paulo César Pereira de Andrade]

  Sorry if this is a dumb question, but I cannot find any information.

  I would like to have git rebase master on f16, f17, and f18
branches of  http://pkgs.fedoraproject.org/cgit/megaglest.git
I once messed it a bit by adding a commit only to branches and
later merging master, now I cannot merge without a merge master
commit, and am not allowed to push myself a git rebase master
branch.

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange Build problem....

[Paulo César Pereira de Andrade]

2013/1/16 Steve Dickson ste...@redhat.com:
 On 16/01/13 12:27, Toshio Kuratomi wrote:
 Looking at the F17 version of matplotlib, the default afm font is being set
 to None there -- so a better fix (but requiring fixing in matplotlib) might
 be to patch it like this:


 --- /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py   
 2012-12-04 21:32:42.0 -0500
 +++ font_manager.py 2013-01-16 12:26:21.861202681 -0500
 @@ -991,7 +991,10 @@
  self.afmfiles = findSystemFonts(paths, fontext='afm') + \
  findSystemFonts(fontext='afm')
  self.afmlist = createFontList(self.afmfiles, fontext='afm')
 -self.defaultFont['afm'] = self.afmfiles[0]
 +try:
 +self.defaultFont['afm'] = self.afmfiles[0]
 +except IndexError:
 +self.defaultFont['afm'] = None

  self.ttf_lookup_cache = {}
  self.afm_lookup_cache = {}
 This does the trick! Thank you very much!

 It turns out this is the patch the caused the problem:

 commit eb9a122389b7ec7e33d9816fa669d7cb1f04521a
 Author: pcpa paulo.cesar.pereira.de.andr...@gmail.com
 Date:   Wed Jan 16 13:59:10 2013 -0200

 Use fontconfig by default (#885307)

  Sorry for that problem. It solved the problems I was having
but created at least yours problem. I am having an almost live
conversation right now about related issues at

https://sourceforge.net/mailarchive/message.php?msg_id=30202451

right after posting the first test case result this was created:

https://github.com/matplotlib/matplotlib/pull/1666

if possible, can you check if the above patch corrects your
issue?


archives of mailing list not yet updated, but I have made several
runs of matplotlib test suite, with logs at:

http://pcpa.fedorapeople.org/matplotlib-2.7+pull-1666.txt
http://pcpa.fedorapeople.org/matplotlib-2.7-bundled-stix-ttf+fontconfig=false.txt
http://pcpa.fedorapeople.org/matplotlib-2.7-mpl-data-with-bundled-stix-ttf.txt
http://pcpa.fedorapeople.org/matplotlib-2.7.txt
http://pcpa.fedorapeople.org/matplotlib-3.3.txt


 CC-ing the author and created this bz:
https://bugzilla.redhat.com/show_bug.cgi?id=896182

 Thanks again for you time and effort! It was definitely
 appreciated!!

 steved.

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Review swap: c-graph

[Paulo César Pereira de Andrade]

  This should be a very easy one
https://bugzilla.redhat.com/show_bug.cgi?id=881794
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Megaglest unit moving error workaround

[Paulo César Pereira de Andrade]

  In case you have this issue, I just rediscovered a workaround. Add

EnableColorPicking=true

to $HOME/.megaglest/glestuser.ini

you probably will want to remove it later, once the problem is corrected
in mesa.

Initial fedora and upstream bug reports:
https://bugzilla.redhat.com/show_bug.cgi?id=889685
https://sourceforge.net/tracker/index.php?func=detailaid=3598159group_id=300350atid=1266776

  The problem appears to also affect f17 users, not just rawhude, based
on http://forums.fedoraforum.org/showthread.php?t=286192

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Dealing with static code analysis in Fedora

[Paulo César Pereira de Andrade]

2012/12/11 David Malcolm dmalc...@redhat.com:
 A while back I ran my static checker on all of the Python extension
 modules in Fedora 17:
   http://fedoraproject.org/wiki/Features/StaticAnalysisOfPythonRefcounts

 I wrote various scripts to build the packages in a mock environment that
 injects my checker into gcc, then wrote various scripts to triage the
 results.  I then filed bugs by hand for the most important results,
 writing some more scripts along the way to make the process easier.

 This led to some valuable bug fixes, but the mechanism for running the
 analysis was very ad hoc and doesn't scale.

  I think it could be useful at least as a generic tool where one would
just do something like:
make CC=gcc-with-python-plugin
like some time ago one could run
make CC=cgcc
to see what sparse would tell. Or maybe think of it as a tool like
rpmlint.

 In particular, we don't yet have an automated way of rerunning the
 tests, whilst using the old results as a baseline.  For example it would
 be most useful if only new problems could be reported, and if the system
 (whatever it is) remembered when a report has been marked as a true bug
 or as a false positive.  Similarly, there's no automated way of saying
 this particular test is bogus; ignore it for now.

  Something like valgrind's .supp files?

 I'm wondering if there's a Free Software system for doing this kind of
 thing, and if not, I'm thinking of building it.

 What I have in mind is a web app backed by a database (perhaps
 checker.fedoraproject.org ?)

  Remembers me of http://upstream-tracker.org/

 We'd be able to run all of the code in Fedora through static analysis
 tools, and slurp the results into the database: primarily my
 cpychecker work, but we could also run the clang analyzer etc.  I've
 also been working on another as-yet-unreleased static analysis tool for
 which I'd want a db for the results.  What I have working is a way to
 inject an analysis payload into gcc within a mock build, which dumps
 JSON report files into the chroot without disturbing the real build.
 The idea is then to gather up the JSON files and insert the report data
 into the db, tagging it with version information.

 There are two dimensions to the version information:
  (A) the version of the software under analysis
  (name-version-release.arch)
  (B) the version of the tool doing the analysis

 We could use (B) within the system to handle the release cycle of a
 static analysis tool.  Initially, any such analysis tools would be
 regarded as experimental, and package maintainers could happily ignore
 the results of such a tool.  The maintainer of an analysis tool could
 work on bug fixes and heuristics to get the signal:noise ratio of the
 tool up to an acceptable level, and then the status of the analysis tool
 could be upgraded to an alpha level or beyond.

 Functional Requirements:
   * a collection of reports (not bugs):
 * interprocedural control flow, potentially across multiple source
   files (potentially with annotations, such as value of variables,
   call stack?)
   * syntax highlighting
   * capturing of all relevant source (potentially with headers as
 well?)
   * visualization of control flow so that you can see the path
 through the code that leads to the error
 * support for my cpychecker analysis
 * support for an as-yet-unreleased interprocedural static analysis
   tool I've been working on
 * support for reports from the clang static analyzer
 * ability to mark a report as:
   * a true bug (and a way to act on it, e.g. escalate to bugzilla or
 to the relevant upstream tracker)
   * a false positive (and a way for the analysis maintainer to act
 on it)
   * other bug associations with a report? (e.g. if the wording from
 the tool's message could be improved)
   * ability to have a conversation about a report within the UI as
 a series of comments (similar to bugzilla).
 * automated report matching between successive runs, so that the
   markings can be inherited
 * scriptable triage, so that we can write scripts that mark all
   reports matching a certain pattern e.g. as being bogus, as being
   security sensitive, etc
 * potentially: debug data (from the analysis tool) associated with a
   report, so that the maintainers of the tool can analyze a false
   positive
 * ability to store crash results where some code broke a static
   analysis tool, so that the tool can be fixed
   * association between reports and builds
   * association between builds and source packages
   * association between packages and people, so that you can see what
 reports are associated with you (perhaps via the pkgdb?)
   * prioritization of reports to be generated by the tool
   * association between reports and tools (and tool versions)
   * quality marking of tool versions, so that we can ignore alpha
 

Re: What would it take to make Software Collections work in Fedora?

[Paulo César Pereira de Andrade]

2012/12/10 Miloslav Trmač m...@volny.cz:
 On Wed, Dec 5, 2012 at 5:17 PM, Matthew Miller mat...@fedoraproject.org 
 wrote:
 I think, though, that this tool, integrated well and supported, could really
 help us in Fedora (and in EPEL). So, I'd like to

 a) enumerate the problems with Software Collections in Fedora,

 Nicolas's mail has covered the single package point of view
 perfectly - relying on software collections/frozen versions typically
 indicates the package is slowly dying, or based on a problematic
 technology.

 Let me add another view:

 From the point of view of a distribution, relying on software
 collections/frozen versions indicates _it is failing its purpose as a
 distribution_.

  Another issue is that usually not only does software depend on
a frozen version number, it frequently also depends on it patched.

  But these usually are software too complex that the authors
cannot cope with the speed of abi/api changes. Usually the core
software is in some interpreted language, usually python, it
usually will also have compiled .so modules that break easily,
the interpreted language itself may change in subtle ways, and
due to interpreted, frequently carry bugs that will only manifest
at runtime when some code path is exercised.

 The purpose of a distribution is to integrate various upstream pieces
 of software into a coherent whole.  That means file system layout
 standards, naming standards, infrastructure standards, etc., but the
 absolute minimum is the ability to run a piece of software included in
 the distribution in the first place.

  Getting back to my sample/anecdotal sagemath package
https://bugzilla.redhat.com/show_bug.cgi?id=877651 waiting for
some brave soul to review it for almost a month now (I made the
review request when I thought it was in an acceptable shape),
I had it working and have been updating it for roughly six months
now, and was working for almost a year to get it working in
fedora; significant amount of patches being added to different
packages, several new packages, adding workarounds to
the sagemath package because upstream would not agree
with sagemath patches, etc. Well, upstream (in this case
sagemath) cannot handle it if supporting different distros, building
for old distributions or different operating systems, they will just
bundle most of the software they need.

 It quite often is a distribution, and in particular, _our_
 distribution, where somebody first seriously tries to use software
 package against an updated dependency.  In such a situation, the
 package maintainers in the distribution should initiate and actively
 work on integrating the two, collaborating with the respective
 upstreams, not just give up and wish for software collections.

  There is another package I would love to build in Fedora, but I do
not know if I will be able to (because there is also significant legal
stuff to evaluate)... That is http://www.salome-platform.org/
I made all components/dependencies work in Mandriva for a few
years, but last time I touched it I had some probably simple
python/qt4 breakage and it is broken since then
https://qa.mandriva.com/show_bug.cgi?id=65396
I was also having significant trouble with the swig and doxygen
versions, and lately a lot of problems with the paraview interface
(that I had disabled because I would need to bundle it, I spent
quite some time trying to patch it because at that time v3.10
and v3.11 were quite different internally...)

 If we as Fedora give up on integrating the software that comes from
 upstreams, what good do we do for our users?  Where is our added
 value?

  I gave two examples of fully open source software. But there are
those closed source software around, like some that distribute
only .pyc/.pyo files, or some different approach to hide the
sources...

 Mirek

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Where are we going? (Not a rant)

[Paulo César Pereira de Andrade]

2012/12/9 Roberto Ragusa m...@robertoragusa.it:
 On 12/08/2012 07:52 PM, Rahul wrote:
 On 12/08/2012 01:48 PM, Roberto Ragusa wrote:
 (my two cents, as someone using Red Hat / Fedora daily since RH5.1, and 
 never stepping up as Fedora packager because too scared by the bureaucracy)

 Can you be more specific?  What sort of bureaucracy do you think is 
 avoidable in the current process?  What would it take for you to get started?

 I do not have specific suggestions, as I actually do not know the process 
 well,
 and even less the motivations behind each steps.

  Maybe there could be some hire a packager program :-)

 I can only say that at
   https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
 23 steps are shown under Becoming a Fedora Package Collection Maintainer.

 Some of them are technical and more or less unavoidable (koji, expiring 
 certificates,
 scm, bodhi), others are more social (ask a review, introduce, inform upstream,
 get sponsorship), finally there is legal stuff (the CLA).

  Personally I like this model because in the end it translates to
higher quality
packages (the social stuff), and with more people looking at it, unlikely to
allow passing some issues like dubious license, failing make check, failing
to pass proper compiler/loader flags, etc. Otherwise, to lift most of
it, it would
be required to encourage personal repositories or some kind of contrib
repository.

 My enthusiasm has never been powerful enough to overcome such an amount
 of static friction.
 I do not have a bag of packages to add to Fedora, so going through all the
 steps just to maintain one rpm or two is costly. I'm sure that after being
 inside the willingness to do more will raise easily, but the initial
 investment appears unjustified.

  Once you get used to the several steps it also becomes easier, but the
learning curve is not simple, and I believe most mentor capable people
are overworked, so, hard to get someone to babysit the first steps :-)

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Where are we going? (Not a rant)

[Paulo César Pereira de Andrade]

2012/12/7 Tomas Radej tra...@redhat.com:

 The threat for Fedora is that even in the FOSS, there is competition.
 Distros are competing for users - users that give back, users that
 report bugs, or users that are or become maintainers and developers.
 When the overwhelming response to Fedora is Hey, they've got some neat
 features, but I need it to work, so that's why I'm using XYZ instead,
 the user/dev base is going to wither and move elsewhere.

  I believe one of the major issues is some lack of proper usability tests.
To get it done by volunteers, I would suggest something like a very simple
way to setup a VM and test there. Personally, I test, but not consistently
neither reporting bugs, etc, several distros in VirtualBox, because it is
very easy to setup after downloading the install ISO.

  I am also running rawhide in my main desktop at home. Example of my
life as a rawhide user for almost one year:

[non booting rawhide kernels and now breaking last booting kernel]
https://bugzilla.redhat.com/show_bug.cgi?id=827734
[after upgrading to rawhide, fedora fails to boot into installed system]
https://bugzilla.redhat.com/show_bug.cgi?id=789285

  It is ok to have some things broken for a small window of time in
the development branch, not good if one ends up with 3 consecutive
non booting kernel updates of course, but anyway, for most contributors
it is better to run rawhide in a VM, but the more stable it is kept, the
better, because if things get too broken, people will give up in reporting
and triaging problems.

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: What would it take to make Software Collections work in Fedora?

[Paulo César Pereira de Andrade]

2012/12/5 Matthew Miller mat...@fedoraproject.org:
 There is a perpetual problem facing all Linux distributions around how fast
 to move with software updates. In Fedora, of course, our default speed is
 petal-to-the-metal. This is part of who we are and why we are awesome.
 However, it also sometimes makes life difficult for us -- for example, our
 Puppet packages are broken because Ruby is too new. It also makes life
 difficult for people trying to use Fedora seriously. It's especially hard
 with Ruby and Java -- not that there's anything _wrong_ with these
 languages, but the packaging expectations are different and often in
 conflict with the system operator's traditional packaging worldview.

  Somewhat of an example of a very complex package tied to a large amount of
other packages that needs custom patches or specific versions is sagemath
http://fedoraproject.org/wiki/SIGs/SciTech/SAGE

  Sagemath has what it calls spkgs, see for example
http://sagemath.org/download-packages.html
and the upstream distribution of sagemath is a base directory anywhere,
and inside it a tree with its own python, a huge collection of packages,
even its own gcc.

  I did package sagemath in Mandriva for several years, and am now working
on getting it in Fedora. My package works with system packages, but
there are a few exceptions due to either sagemath being tied to something
too old, having some really intrusive patch that upstream does not accept,
or a too fast moving target that is too hard to keep updating/remaking non
trivial patches that still may break badly because some package in the
distro was updated.

  The solution I used for these in Mandriva and hoping to get approved
for Fedora is bundling. For now it is 3 non trivial packages, that are
ipython, cython and pexpect. Everything else I managed to get to work
with the distro version. With some time, *and* with sagemath integrated
in the distro it should also make upstream pay more attention and
coordinate better in the different projects, and those bundled components
eventually may not need to be required anymore.

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] Retiring packages for Fedora 18

[Paulo César Pereira de Andrade]

2012/7/7 Jerry James loganje...@gmail.com:
 On Sat, Jul 7, 2012 at 3:34 AM, Richard W.M. Jones rjo...@redhat.com wrote:
 On Fri, Jul 06, 2012 at 04:55:19PM -0400, Bill Nottingham wrote:
 Removing: emacs-common-proofgeneral
 coq requires xemacs-proofgeneral = 3.7.1-5.fc15
 coq requires emacs-proofgeneral = 3.7.1-5.fc15
 coq-emacs requires emacs-proofgeneral = 3.7.1-5.fc15
 coq-xemacs requires xemacs-proofgeneral = 3.7.1-5.fc15

 The dependency here is that the Coq emacs mode requires
 the proofgeneral emacs mode.  I will drop the dependency
 and the coq-{,x}emacs subpackages (from Coq) unless someone
 takes the above package.

 Note that Coq itself doesn't build right now .. see the email
 I sent a few days ago to this list.

 I will take proofgeneral Real Soon Now.  I'm in overload mode at
 $DAYJOB at the moment, and will likely remain so for about 2 more
 weeks.  My apologies to those who have been waiting for me to do
 something.  If anybody needs to do something to one of the packages I
 maintain at any time in the next couple of weeks, please just go
 ahead.  I hope to return to my normal Fedora activity levels around
 the end of July.

  I am on vacation during July, after that, back to contributing on
weekends and sometimes at night... thus did a lot of work on sagemath
dependencies. I will ask commit access to some packages, so I
can update them myself...

  See http://lists.fedoraproject.org/pipermail/scitech/2012-July/000130.html
for an informal request to speed up a bit some tickets :-)

 --
 Jerry James
 http://www.jamezone.org/

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Paulo César Pereira de Andrade]

2012/6/5 Kevin Kofler kevin.kof...@chello.at:
 Tomas Mraz wrote:
 That's a total nonsense unless the restriction is by-license and not
 just technical obstacle. If it is just a technical obstacle in the code,
 you can remove it and run the software on any crippled machine at your
 will. So no, making your software not to work on particular machines
 does not make it non-free at all.

 That doesn't mean we should ship it in that state.

 If Fedora decides to support Secure Boot, it needs to be distro-wide.

  Could it be done in a pretend to be supported mode, somewhat
like having a known public grub key, and then provide some Linux
certified stickers :-) Then let grub load any OS, or chain load windows
as usual.
  If it is required to validate every built kernel, every module, etc, then
there is no point on it for Linux. The certification for Linux should be
a signed source tarball and secure channel updates, not some entity
signing some specific binary as guaranteed secure.
  For the truly paranoid, could also provide some kind of boot image,
like memtest, providing all source code of course, and can be built for
a bootable device, and let it do any security audit (need to trust
whatever binary is in firmware).

        Kevin Kofler

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Paulo César Pereira de Andrade]

2012/6/6 drago01 drag...@gmail.com:
 On Wed, Jun 6, 2012 at 3:24 PM, Paulo César Pereira de Andrade
 paulo.cesar.pereira.de.andr...@gmail.com wrote:
 2012/6/5 Kevin Kofler kevin.kof...@chello.at:
 Tomas Mraz wrote:
 That's a total nonsense unless the restriction is by-license and not
 just technical obstacle. If it is just a technical obstacle in the code,
 you can remove it and run the software on any crippled machine at your
 will. So no, making your software not to work on particular machines
 does not make it non-free at all.

 That doesn't mean we should ship it in that state.

 If Fedora decides to support Secure Boot, it needs to be distro-wide.

  Could it be done in a pretend to be supported mode, somewhat
 like having a known public grub key, and then provide some Linux
 certified stickers :-) Then let grub load any OS, or chain load windows
 as usual.

 That makes no sense at all.

 1) How would you get OEMs to support add that key?
 2) How do you prevent malware authors to use this public available key
 to sign there malware?

  That is the part of pretend to be supported, just to avoid needing
users to go to some setup mode to disable secure boot, and then
offer other means of security audit, like a custom boot image for
an external device. For windows, it could be some certified bootable
DVD, that would be guaranteed to be clean, and from there run
anti virus, or any scanning tools.

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Paulo César Pereira de Andrade]

2012/6/6 drago01 drag...@gmail.com:
 On Wed, Jun 6, 2012 at 4:51 PM, Paulo César Pereira de Andrade
 paulo.cesar.pereira.de.andr...@gmail.com wrote:
 2012/6/6 drago01 drag...@gmail.com:
 On Wed, Jun 6, 2012 at 3:24 PM, Paulo César Pereira de Andrade
 paulo.cesar.pereira.de.andr...@gmail.com wrote:
 2012/6/5 Kevin Kofler kevin.kof...@chello.at:
 Tomas Mraz wrote:
 That's a total nonsense unless the restriction is by-license and not
 just technical obstacle. If it is just a technical obstacle in the code,
 you can remove it and run the software on any crippled machine at your
 will. So no, making your software not to work on particular machines
 does not make it non-free at all.

 That doesn't mean we should ship it in that state.

 If Fedora decides to support Secure Boot, it needs to be distro-wide.

  Could it be done in a pretend to be supported mode, somewhat
 like having a known public grub key, and then provide some Linux
 certified stickers :-) Then let grub load any OS, or chain load windows
 as usual.

 That makes no sense at all.

 1) How would you get OEMs to support add that key?
 2) How do you prevent malware authors to use this public available key
 to sign there malware?

  That is the part of pretend to be supported, just to avoid needing
 users to go to some setup mode to disable secure boot, and then
 offer other means of security audit, like a custom boot image for
 an external device. For windows, it could be some certified bootable
 DVD, that would be guaranteed to be clean, and from there run
 anti virus, or any scanning tools.

 Now back to reality ... how do you intend to support that?
 Talking about how things should be done is nice and all but not
 really productive.

  That suggestion is impractical for end users, but a way to do
a truly assurance that the system is secure (provided that it has
an as up to date as possible information on known exploits).

  Anyway, I am pretty sure several distros will ignore this issue,
possibly until too late, and the end solution at worst, for
computers where secure boot cannot be disabled should
be to have someone providing a signed first stage loader
(until such key is revoked...)

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-3-2.fc17.x86_64

[Paulo César Pereira de Andrade]

  I know I got what I deserved by attempting to fix by hand the move
from / to /usr, just did need to boot from the fedora16 dvd, mount lvm
root and finish my fix; brain fart, and cyclic dep on moving /lib64
to /usr/lib64 and then a symlink, leaving it with all binaries failing
due to missing /lib64/ld-linux-x86-64.so.2.
  After that, while it is finishing updating to rawhide right now, I did
go search for documentation, but still find that
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17
is not much clear about it. Maybe should strongly advise installing
busybox and/or have a step by step procedure. Or even better, to somehow
have it done automatically, by some statically linked program.

  This should have been already discussed to death, but I found worth to
post a note about it as I am somewhat of a newcomer to fedora...

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-3-2.fc17.x86_64

[Paulo César Pereira de Andrade]

2012/5/15 Adam Williamson awill...@redhat.com:
 On Tue, 2012-05-15 at 23:47 -0300, Paulo César Pereira de Andrade wrote:
 I know I got what I deserved by attempting to fix by hand the move
 from / to /usr, just did need to boot from the fedora16 dvd, mount lvm
 root and finish my fix; brain fart, and cyclic dep on moving /lib64
 to /usr/lib64 and then a symlink, leaving it with all binaries failing
 due to missing /lib64/ld-linux-x86-64.so.2.
   After that, while it is finishing updating to rawhide right now, I did
 go search for documentation, but still find that
 https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17
 is not much clear about it. Maybe should strongly advise installing
 busybox and/or have a step by step procedure.

 It, um, does have a step by step procedure. Do what it says there, and
 it works. I upgraded five boxes.

  Yes, it was me trying to be too smart :-)

 Or even better, to somehow
 have it done automatically, by some statically linked program.

 This is already done if you use any supported upgrade method -
 preupgrade or netinst / DVD upgrade.

  What I did was to install fedora-release-rawhide, disable all
repositories in /etc/yum.repos.d and enable rawhide ones, and then
attempt a few times yum distro-sync until I removed all unresolvable
updates, most due to several review requests and/or requests for
enhancement that I will rebuild...

  Not a criticism, just reporting my hacker instinct of only reading
documentation when everything else fails :-)

 --
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
 http://www.happyassassin.net

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers

[Paulo César Pereira de Andrade]

2012/5/6 Michel Alexandre Salim sali...@fedoraproject.org:

 Hi all,

 LLVM is becoming an increasingly integral part of our distribution
 (with mesa now using it to build the LLVMpipe renderer, for example)
 that I don't really feel comfortable maintaining it mostly by myself.

 I'd love to have some extra help here -- especially those with deep
 C++ expertise; until we get LLVM's own libcxx packaged (it currently
 only supports OS X), LLVM's clang C/C++/Obj-C/Objc-C++ compiler tends
 to play catch-up with g++/libstdc++ in its C++11 support, and since
 upstream does not support older branches post-release, it's normally
 up to us to try and backport patches whenever GCC in a stable release
 gets updated.

 Also, LLVM's packaging is currently not optimal --
 https://bugzilla.redhat.com/show_bug.cgi?id=787187 -- even if you're
 not interested in C++ support, you're more than welcome to help fix
 other issues!

  About packaging I can at least give some ideas. I completely
redesigned the llvm package in Mandriva some months ago. See

http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/llvm/current/SPECS/llvm.spec?view=markup

selling point is using the Mandriva library policy, so it is possible,
for example, to have installed at the same time libllvm3.0 and a
possible libllvm3.1 in the near future. But the choice to give it
major/minor 3.0 is not official...

http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/llvm/current/SOURCES/llvm-3.0-soversion.patch?view=markup

  Also, libraries are installed in libdir, %_not %_libdir/llvm

  The advantage of building it with cmake is that llvm and clang
packages are shared and a release build by default, and require
like 6+ MB, while if built with %configure it will use like 250MB+
in a debug/static build to include everything.

 TIA,

 - --
 Michel Alexandre Salim
 Fedora Project Contributor: http://fedoraproject.org/

 Email:  sali...@fedoraproject.org  | GPG key ID: A36A937A
 Jabber: hir...@jabber.ccc.de       | IRC: hir...@irc.freenode.net

 ()  ascii ribbon campaign - against html e-mail
 /\  www.asciiribbon.org   - against proprietary attachments

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Review swaps

[Paulo César Pereira de Andrade]

2012/5/1 Jerry James loganje...@gmail.com:
 I'm interested in swapping reviews.  Here are the ones I need reviewed:

 vinci: https://bugzilla.redhat.com/show_bug.cgi?id=790560
 permlib: https://bugzilla.redhat.com/show_bug.cgi?id=797312

 Let me know what I can review for you.  Thanks,

  Ok. I replied in the above with what I could help, and just made a newer
package required by sagemath
https://bugzilla.redhat.com/show_bug.cgi?id=817981

  Later I will try to make a proper singular package, and work a bit more
in the initial cliquer package I made just to get further in sagemath build.
With the ratpoints package, now it fails in singular build.

 --
 Jerry James
 http://www.jamezone.org/
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel