Re: Fedora 30 System-Wide Change proposal: New 128-bit IEEE long double ABI for IBM 64-bit POWER LE

[Elliott Sales de Andrade]

On Wed, 22 Aug 2018 at 17:18, Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition
>
> == Summary ==
> Transition IBM 64-bit POWER LE systems to the new 128-bit IEEE long double
> ABI.
>
> == Owner ==
> * Name: Carlos O'Donell (codonell)
> * Email: car...@redhat.com
>
> == Detailed Description ==
> IBM has designed a new long double ABI that adheres to the 128-bit
> IEEE format. This format is more standard than the existing AIX
> double-double or IBM long double (2 grouped 64-bit doubles) which has
> discontinuous mantissas and is difficult for developers to use. In
> Fedora 29 the plan is to switch to the new ABI for long double, while
>

In Fedora 29 or Fedora 30?


> still supporting old applications via compatibility symbols. Newly
> compiled applications use either the old or new ABI but not a mix of
> both. Changes are required in the core C libraries, and the compiler
> and the compiler runtimes including the C++ standard libraries.
> Therefore there is coordination required across the core toolchain
> componenents e.g. gcc, binutils, glibc, gdb (to debug the new types).
>
> == Benefit to Fedora ==
> Fedora developers will be using a standard 128-bit IEEE format for
> long double instead of the non-standard double-double AIX format which
> has a discontinuous mantissa and multiple representations for the same
> value.
>
> == Scope ==
> The change is relatively limited in that not many packages use the
> long double floating point ABI. The double floating point ABI is much
> more used, but not long double. It is estimated that few packages use
> long double directly, and those packages will need to be rebuilt in
> order to use the new ABI. This rebuilding can be targetted by
> analyzing which packages have long double usage in their debug
> information and rebuilding just those packages. However, we plan to
> just use the existing mass rebuild for glibc 2.29 to handle this
> issue.
>
> * Proposal owners: Transition glibc to float128 format for long double
> for IBM ppc64le. Transition gcc to the default for long double.
> Implement support for the new long double format in
> libstdc++. Ensure gdb can handle the new types.
> * Other developers: Developers need to ensure that rawhide is stable
> and ready for the Fedora 30 branch.
> * Release engineering: A mass rebuild request has been filed for the
> parent system-wide change to upgrade glibc to
> 2.29[https://pagure.io/releng/issue/7475 #7475]
> * Policies and guidelines: The policies and guidelines do not need to
> be updated.
> * Trademark approval: Not needed for this change
>
> == Upgrade/compatibility impact ==
> The library and language runtimes are backwards compatible with the
> version shipped in Fedora.
>
> We fully expect to fix all packaging changes in Fedora Rawhide first
> when everything is ready.
>
> == How To Test ==
> The GNU C Library has its own testsuite, which is run during the
> package build and examined by the glibc developers before being
> uploaded. This test suite has 2500+ tests that run to verify the
> correct operation of the library. In the future we'll also be running
> the microbenchmark to look for performance regressions as well as
> behavioural ones.
>
> Specific testing for 128-bit IEEE long double ABI will be carried out
> by the glibc testsuite. Integration smoke testing will be carried out
> by the glibc developers to make sure new applications are built with
> the correct defaults and work as expected.
>
> Specific testing for 128-bit IEEE long double ABI will be carried out
> by the gcc testsuite.
>
> Specific smoke testing will be carried out using gdb to read and write
> the new types.
>
> == User Experience ==
> Users will see a new 128-bit floating point ABI, but this will largely
> be transparent to them. On POWER hardware that supports 128-bit long
> double in hardware the compiler will use the hardware transparently to
> accelerate floating point operations, otherwise software floating
> point emulation will be used.
>
> == Dependencies ==
> This change requires coordination of glibc and gcc to change the
> compiler defaults and build the compiler language runtimes correctly.
> Also gdb must be able to support the new type to make the process of
> transition seamless.
>
> == Contingency Plan ==
> * Contingency mechanism: Ship glibc 2.28 instead of glibc 2.29, or
> ship glibc 2.29 without this feature if it is not ready.
>
> * Contingency deadline: Final mass rebuild before Fedora release.
> * Blocks release? Upgrading glibc does block the release. We should
> not ship without the float128 ABI change.
>
> == Documentation ==
> The glibc/gcc manual contain the documentation for the release and
> don't need any more additional work.
>
> == Release Notes ==
> * The ppc64le architecture changed the format of the long
> double type to binary128. (Previously, a pair of two doubles
> was used.)
>
> --
> Ben Cotton
> Fedora Program Manager
> 

Re: Updating R-qvalue and R-xtable

[Elliott Sales de Andrade]

Hi Pierre,

> Good Morning Everyone,
> 
> A few days ago, I sent this to the r-sig-fedora(a)r-project.org list but 
> without
> reactions, so I'm sending it here as well in case there are more people
> interested here :)
> 
> Thanks,
> 
> Pierre
> 
> --
> 
> Good Morning Everyone,
> 
> I was going through my list of FTBFS packages today and I fixed all my R
> packages but 2: qvalue and xtable.
> qvalue requires ggplot2

ggplot2 requires tibble and scales. There's a build failure with tibble [1] 
holding that back. On scales, it requires RColorBrewer, but I'm waiting for the 
other person to get back to packaging it [2], or maybe I'll have to do it 
myself.

> xtable requires: lsmeans, spdep, splm, sphet, plm
> 

lsmeans requires xtable, so there's a loop. But those other things are just 
Suggests; they may only be needed for tests and the like.

> I am not doing any R anymore these days and in fact spot has been the one
> maintaining most of my R packages these days (thanks spot!!), so I am not 
> really
> interested in maintaining more R packages.
> Would someone be interested in packaging these libraries?
> 
> Otherwise, I think both qvalue and xtable will get retired in a nearish 
> future.
> 
> 
> Thanks for your help :)
> 
> Pierre

[1] https://github.com/tidyverse/tibble/issues/421
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1504825
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JIJYRDTZND67MHTDSPJQANEECP7UJU43/

Haskell failures: relocation refers to local symbol "" [1], which is defined in a discarded section

[Elliott Sales de Andrade]

Hello all,

All Haskell packages seem to be broken now, e.g., ghc-optional-args [1] or 
anything on koschei [2]. They all fail like this:

+ ghc --make -no-user-package-db -dynamic Setup
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking Setup ...
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crti.o(.gnu.build.attributes+0x14):
 error: relocation refers to local symbol "" [1], which is defined in a 
discarded section
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crti.o(.gnu.build.attributes+0x1c):
 error: relocation refers to local symbol "" [1], which is defined in a 
discarded section
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crtn.o(.gnu.build.attributes+0x14):
 error: relocation refers to local symbol "" [1], which is defined in a 
discarded section
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crtn.o(.gnu.build.attributes+0x1c):
 error: relocation refers to local symbol "" [1], which is defined in a 
discarded section
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)

Does anyone know what's going on here? Is is annobin, new binutils, something 
else? The earliest failing build I can find is git-annex [3], and the 
dependency changes show annobin, binutils, and glibc (among others.)

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=28143935
[2] https://apps.fedoraproject.org/koschei/search?q=ghc-
[3] https://apps.fedoraproject.org/koschei/build/4976352

--
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ITSPQ4PLU6R4GERXX2J7FA42YOOBR7NH/

License change in git-annex

[Elliott Sales de Andrade]

git-annex-6.20180316 has changed license from GPLv3+ to AGPLv3+.

Technically, this was true when I enabled the webapp option in Rawhide earlier, 
but I did not realize it. However, AGPL code has been merged into the main 
application so the entirety of the package is now AGPL regardless of that build 
option.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: qpdf soname bump in rawhide to 21.2.1

[Elliott Sales de Andrade]

Hi,

On Mon, 24 Sep 2018 at 09:52, Zdenek Dohnal  wrote:

> Hi,
>
> qpdf got new version and I would like to rebase our rawhide version, but
> two packages will need to be rebuilt, because they depends on libqpdf
> library.
>

I'm confused; there does not appear to be a soname bump:

$ rpm -q --provides qpdf-libs
libqpdf.so.21()(64bit)
libqpdf.so.21(LIBQPDF_21)(64bit)
qpdf-libs = 8.1.0-3.fc29
qpdf-libs(x86-64) = 8.1.0-3.fc29

vs

$ rpm -q --provides -p ./qpdf-libs-8.2.1-1.fc30.x86_64.rpm
libqpdf.so.21()(64bit)
libqpdf.so.21(LIBQPDF_21)(64bit)
qpdf-libs = 8.2.1-1.fc30
qpdf-libs(x86-64) = 8.2.1-1.fc30


> - python-pikepdf
>
> - cups-filters
>
> I can manage cups-filters rebuild, but I would like to ask
> python-pikepdf's maintainer to rebuild his package.
>
>
Rebuild is done.


> I have copr project
> https://copr.fedorainfracloud.org/coprs/zdohnal/qpdf/builds/ , where I
> tried to rebuild cups-filters and python-pikepdf with new qpdf.
> python-pikepdf's new version fails to build even with old qpdf (I
> reported it to python-pikepdf's maintainer at bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1631890).
>
> Because python-pikepdf is broken anyway, I'll rebuild cups-filters and
> put new qpdf with rawhide.
>
> --
> Zdenek Dohnal
> Associate Software Engineer
> Red Hat Czech - Brno TPB-C
>
>
>

-- 
Elliott
___
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

R-tweenr license change

[Elliott Sales de Andrade]

R-tweenr 1.0.0 has changed license from GPLv2+ and WTFPL to MIT and WTFPL.

-- 
Elliott
___
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: Use immutable CRAN URLs

[Elliott Sales de Andrade]

On Wed, Oct 31, 2018, 5:01 PM Iñaki Ucar  On Wed, 31 Oct 2018 at 21:48, Jason L Tibbitts III 
> wrote:
> >
> > > "IU" == Iñaki Ucar  writes:
> >
> >
> > IU> This is great. However, in theory, given the naming guidelines, by
> > IU> stripping the leading "R-" you should get the package name. In
> > IU> practice, at least one package doesn't adhere to this: R-TH-data,
> > IU> while the R package name is TH.data, not TH-data. I see that the SPEC
> > IU> says "# Cannot use . in name", but this is clearly not true (maybe it
> > IU> was true long ago?).
> >
> > Why is that a problem?  You would just define %packname in that case and
> > nothing changes.
> >
> > Look for the 50% case.  Does it simplify at least half of the packages
> > while not making things harder for the rest?  I don't know the answer
> > but I would be surprised if it wasn't 'yes' even if you change 50% to
> > 90%.
>
> Don't get me wrong: I'm totally in with this change. I was just
> putting all the information on the table. And I'd be surprised if it
> wasn't "yes" for less than 95%. :)
>

All my packages were created using R2spec, so they would all use
%{packname}. I would guess that most packages used the generator as well.

> IU> That would require a good ton of magic. You have seen something like
> > IU> this:
> >
> > IU> %global rlibdir %{_libdir}/R/library
> >
> > IU> The thing is, this is the path for R packages *with* compiled code,
> > IU> while R packages *without* compiled code must go to
> > IU> %_datadir/R/library. That's why every R package has this global on
> > IU> top of the SPEC.
> >
>

This can be determined from the NeedsCompilation key in the DESCRIPTION
file, which is what (my fork of) R2spec does.

> Well, what you'd generally do is simply use a different macro for the
> > noarch location and the arch-specific location.  So you'd one defined
> > macro for things under libdir, another macro for things under
> > datadir.  Like Perl and Python and such do.
> >
> > If you really wanted to get down into it, it's tough to magically define
> > a macro depending on BuildArch (though I could be missing a trick) but
> > ou could conceivably have macros like %r_archful_package and
> > %r_noarch_package.
> >
> > They could some macro like your %rlibdir and also take care of adding
> > the build dependencies and (where needed) the BuildArch: line and the
> > R-core dependency.  There's really a whole lot you could do, down to
> > having macros used in %install, adding that annoying empty %build
>
> That is quite annoying, yes. :)
>
> > section, even generating a file list so you don't have to manually list
> > so much in %files.
> >
>

Basically anything under %{rlibdir}%{packname} is needed and nothing
appears elsewhere. If we didn't need to mark doc and license files, we
could have just specified that top-level directory. The hard part about
that is the naming is pretty inconsistent. Because CRAN disallows providing
the full license text in LICENSE, upstreams that want to follow the terms
of the license will put it in a separate file and the name is never the
same.

> It depends on how far you want to go, and how specific you can be before
> > you're not actually simplifying a majority of the R packages we have.
>

In the same way Go has moved to mostly generated, I think R can mostly get
away with this as well. We can get most of the information from the
DESCRIPTION file or re-write R2spec to output what we need. I don't really
know how macros work or I might have attempted this earlier.


> >  - J<
>
> --
> Iñaki Ucar
>
___
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

python?-sip-api is no longer available, breaking python-wxpython4

[Elliott Sales de Andrade]

Hi all,

I am attempting to build the latest matplotlib but it is failing to
install python3-wxpython4 [1]:

   - nothing provides python3-sip-api(12)(x86-64) = 12.5 needed by
python3-wxpython4-4.0.1-9.fc29.x86_64

I attempted to rebuild python-wxpython4 [2], but that did not help. It
was then that I found out that python?-sip-api was removed on purpose
[3], meaning python?-wxpython4 can no longer be installed.

Is this an oversight? Should python?-sip-api be Provided by a
different subpackage? Should python?-wxpython4 Require on something
else? Should the %{no_namespace} change be reverted?

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=30484915
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=30485980
[3] 
https://src.fedoraproject.org/rpms/sip/c/c17e1e6b4925f017028076ed90153ebb03f1a5c4?branch=master

-- 
Elliott
___
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

%find_lang for non-standard locations

[Elliott Sales de Andrade]

Hi,

The general guidelines currently state that translations should be
found using %find_lang; this macro provides a listing of all *.mo
files but not their containing directories.

Specifying just the files makes sense when they are in the global
location (/usr/share/locale), but not so much when they are in, e.g.,
the Python site-packages directories. For example, python3-humanize
currently lists:

/usr/lib/python3.7/site-packages/humanize
...
/usr/lib/python3.7/site-packages/humanize/locale/fr_FR/LC_MESSAGES/humanize.mo
/usr/lib/python3.7/site-packages/humanize/locale/ko_KR/LC_MESSAGES/humanize.mo
/usr/lib/python3.7/site-packages/humanize/locale/ru_RU/LC_MESSAGES/humanize.mo

but *not* the humanize/locale or humanize/locale/* directories. So
when you uninstall python3-humanize, you are left with the
/usr/lib/python3.7/site-packages/humanize/locale/*/LC_MESSAGES/
directories.

I see three ways forward:
1. Teach %find_lang to add directories if it's not in /usr/share/locale
2. Tell packagers to explicitly include the directories is not in
/usr/share/locale
3. Stop recommending %find_lang if it serves no other purpose than to
just list files (I *think* multiple packages owning directories is no
longer an issue?)

I'd lean towards 1 as I think 2 is just unnecessary extra work and the
condition in 3 is not probably true.

--
Elliott
___
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: Proposal: Abandon v8 package

[Elliott Sales de Andrade]

Let's try this again, but CC'ing the package owners.

On 2019-02-17 9:12 p.m., Elliott Sales de Andrade wrote:
> Hi,
> 
> Sorry for resurrecting a long-dead thread, but a few things happened recently:
> 1. v8 was just retired last week or so,
> 2. R-V8 just ported itself from v8-314 to v8 LTS 6/7.
> 
> Currently, R-V8 supports both v8-314 and v8, but as the latter fixes several 
> downstream package issues, it is the recommended build target. I expect that 
> eventually they will stop supporting 314 as well. This leaves me in a bit of 
> a pickle as it does not bundle v8 and neither I nor upstream have any plans 
> to build it ourselves.
> 
>> For all of these same reasons, the Node.js SIG opted to carry a bundled
>> copy of v8 in that package as well. I think we should move to have v8
>> considered to be a copylib for all reasonable purposes within Fedora.
> 
> In Debian, the nodejs package provides a stable *shared* v8 library, and the 
> recommended install is against libnode-dev. Unfortunately, in Fedora, while 
> nodejs-devel provides v8.h, it does *not* provide any shared library.
> 
> Is this something we can also do in Fedora, i.e., split out a nodejs-libs 
> subpackage, or similar?
> 

--
Elliott
___
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

License change of R-gsl: GPLv2+ to GPLv3

[Elliott Sales de Andrade]

Hi,

Upstream has made a new release that changes the license from GPLv2+
to GPLv3. I intend to build this later today. Since its main use and
linkage was to GSL which is GPLv3 only, this is effectively the
license the built work is already under anyway.

-- 
Elliott
___
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: Proposal: Abandon v8 package

[Elliott Sales de Andrade]

On Thu, 28 Feb 2019 at 16:24, Stephen Gallagher  wrote:
>
> On Wed, Feb 27, 2019 at 7:02 PM Elliott Sales de Andrade
>  wrote:
> >
> > Let's try this again, but CC'ing the package owners.
> >
> > On 2019-02-17 9:12 p.m., Elliott Sales de Andrade wrote:
> > > Hi,
> > >
> > > Sorry for resurrecting a long-dead thread, but a few things happened 
> > > recently:
> > > 1. v8 was just retired last week or so,
> > > 2. R-V8 just ported itself from v8-314 to v8 LTS 6/7.
> > >
> > > Currently, R-V8 supports both v8-314 and v8, but as the latter fixes 
> > > several downstream package issues, it is the recommended build target. I 
> > > expect that eventually they will stop supporting 314 as well. This leaves 
> > > me in a bit of a pickle as it does not bundle v8 and neither I nor 
> > > upstream have any plans to build it ourselves.
> > >
> > >> For all of these same reasons, the Node.js SIG opted to carry a bundled
> > >> copy of v8 in that package as well. I think we should move to have v8
> > >> considered to be a copylib for all reasonable purposes within Fedora.
> > >
> > > In Debian, the nodejs package provides a stable *shared* v8 library, and 
> > > the recommended install is against libnode-dev. Unfortunately, in Fedora, 
> > > while nodejs-devel provides v8.h, it does *not* provide any shared 
> > > library.
> > >
> > > Is this something we can also do in Fedora, i.e., split out a nodejs-libs 
> > > subpackage, or similar?
> > >
>
>
> I've been keeping the Node.js packages in Fedora alive, but on
> life-support, for a couple years now. I don't have the cycles to look
> into a significant rework of how they're designed. If you have ideas
> for how to do what you're asking, I will happily review a pull request
> to http://src.fedoraproject.org/rpms/nodejs

OK, I've sent a pull-request to do so [1]. It essentially mimics what
the Debian package does (pass --shared and then manually install the
executable since their script will only install one or the other.) The
other changes just make sure paths are correct for tests to work. It
works for me [2] to build R-V8 (though copr gets stuck building nodejs
on x86_64 for some reason.)

[1] https://src.fedoraproject.org/rpms/nodejs/pull-request/4
[2] https://copr.fedorainfracloud.org/coprs/qulogic/nodejs-R-V8/builds/

-- 
Elliott
___
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: Orphan/retire gogoc

[Elliott Sales de Andrade]

Hi,

> Hello,
> 
> gogoc is dead to the world upstream (the gogo6.com site is now a
> nutritional supplement pusher!), and without gogo6's servers, gogoc is
> fairly useless. It's still possible it could be used to TSP tunnel
> through one's own servers to get IPv6, but as far as I know, there
> aren't any more tunnel services out there that use it.
> 
> So, if someone would find it worthwhile to keep it around for their own
> tunnelling needs, feel free to pick it up. Otherwise, I'll retire it in
> two weeks.

I just noticed this in the F30 FTBFS list. It seems you might have forgotten to 
orphan it? I'd guess it can also be retired too.
___
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: Proposal: Abandon v8 package

[Elliott Sales de Andrade]

Hi,

Sorry for resurrecting a long-dead thread, but a few things happened recently:
1. v8 was just retired last week or so,
2. R-V8 just ported itself from v8-314 to v8 LTS 6/7.

Currently, R-V8 supports both v8-314 and v8, but as the latter fixes several 
downstream package issues, it is the recommended build target. I expect that 
eventually they will stop supporting 314 as well. This leaves me in a bit of a 
pickle as it does not bundle v8 and neither I nor upstream have any plans to 
build it ourselves.

> For all of these same reasons, the Node.js SIG opted to carry a bundled
> copy of v8 in that package as well. I think we should move to have v8
> considered to be a copylib for all reasonable purposes within Fedora.

In Debian, the nodejs package provides a stable *shared* v8 library, and the 
recommended install is against libnode-dev. Unfortunately, in Fedora, while 
nodejs-devel provides v8.h, it does *not* provide any shared library.

Is this something we can also do in Fedora, i.e., split out a nodejs-libs 
subpackage, or similar?
___
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: Unannounced soname bumps: proj and geos

[Elliott Sales de Andrade]

Hi,

On Tue, 5 Feb 2019 at 17:12, Devrim Gündüz  wrote:
> Hi,
>
> On Mon, 2019-02-04 at 21:09 -0500, Elliott Sales de Andrade wrote:
> >
> > The recent bump of proj in Rawhide from 4.9.3 to 5.2.0 also bumped the
> > soname from libproj.so.12 to  libproj.so.13.
> > The bump of geos in Rawhide from 3.6.1 to 3.7.1 also bumped the soname
> > from libgeos-3.6.1.so to libgeos-3.7.1.so.
> >
> > These bumps should be announced *before* the build has been made.
>
> Apologies, that was me. I forgot the process.
>
> > Fortunately, as I was already investigating the possibility of
> > updating proj,
>
> Yay!
>
> > I have the list of proj-dependent packages already. I
> > was not looking at geos, but hopefully the list below includes
> > everyone. I have CC'd maintainers on the list to notify them that they
> > will need to rebuild their packages (or I can do it myself at some
> > point if they're busy.)
>
> I am working on it. Fixed libgeotiff, libspatialite ,ogdi. gdal, GRASS and
> PostGIS so far.
>

Thanks for taking care of these. I was able to rebuild my packages as
well without issue, and I see a few others were done by other
maintainers.
There are still six left that have not been rebuilt: perl-PDL,
shapelib-tools, spatialite-gui, merkaartor, qlandkartegt, saga. I may
build these if the maintainers do not get to it before the branch
point or beta freeze.
And two that were rebuilt but seem to be FTBFS anyway: mapserver, xastir.

PS, can you also take a look at my PRs that enable the test suite and
add the optional datum grids:
https://src.fedoraproject.org/rpms/proj/pull-request/4
https://src.fedoraproject.org/rpms/proj/pull-request/5

> Regards,
> --
> Devrim Gündüz
> Open Source Solution Architect, Red Hat Certified Engineer
> Twitter: @DevrimGunduz , @DevrimGunduzTR

-- 
Elliott
___
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: Fedora 30 Mass Branching Starting Today

[Elliott Sales de Andrade]

Hi,

On Tue, 19 Feb 2019 at 09:21, Mohan Boddu  wrote:
>
> Hello All,
>
> Fedora 30 will be branched from rawhide today as per the Fedora 30 
> schedule[1]. The process takes about a day and everything should be ready by 
> tomorrow. You can still be able to build packages normally until then, but 
> after the mass branching rawhide and F31 will be separated.
>

I don't know if this is because branching is not complete, but it
looks like this did not take effect for new packages.

For example, my request for R-tidyselect [2], resulted in a master
branch (building for f31) only, but the package was tagged into
f30-pending, so I cannot build it. (Actually, I do need to request f30
as well, now.)

> We will send another email once the branching is done.
>
> Thanks,
> Fedora Release Engineering.
>
> [1] https://fedoraproject.org/wiki/Releases/30/Schedule
[2] https://pagure.io/releng/fedora-scm-requests/issue/9825

-- 
Elliott
___
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

Unannounced soname bumps: proj and geos

[Elliott Sales de Andrade]

Hi,

The recent bump of proj in Rawhide from 4.9.3 to 5.2.0 also bumped the
soname from libproj.so.12 to  libproj.so.13.
The bump of geos in Rawhide from 3.6.1 to 3.7.1 also bumped the soname
from libgeos-3.6.1.so to libgeos-3.7.1.so.

These bumps should be announced *before* the build has been made.

Fortunately, as I was already investigating the possibility of
updating proj, I have the list of proj-dependent packages already. I
was not looking at geos, but hopefully the list below includes
everyone. I have CC'd maintainers on the list to notify them that they
will need to rebuild their packages (or I can do it myself at some
point if they're busy.)

Maintainers by package:
R-rgdal  qulogic
R-rgeos  qulogic
dans-gdal-scriptsvolter
fawkes   rmattes thofmann timn
gazebo   rmattes
gdal alexlan devrim jmlich mmahut oliver orion pali
praiskup volter
grassdaveisfera devrim neteler oliver volter
libgeotiff   devrim orion volter
libosmiumtomh
librasterlite2   volter
libspatialitevolter
mapnik   alexlan tomh
mapserverdevrim jujens oliver pali
merkaartor   slankes till
ncl  orion
nodejs-mapnikjamielinux tomh
ogdi sharkcz
osgearth smani
osm2pgsqlfab
perl-PDL alexl caillon caolanm johnp jplesnik lkundrak
mbarnes mmaslano ppisar rhughes rnorwood rstrode ssp
pgRoutingpkubat volter
player   kwizart rmattes timn ttorling
postgis  devrim jmlich maxamillion pkajaba pkubat praiskup
pyproj   jdekloe
python-basemap   jspaleta limb
python-cartopy   qulogic
python-mapniktomh
qgis bruno daveisfera volter
qlandkartegt sharkcz
qmapshacksharkcz
qt-mobility  company heliocastro rdieter than
saga volter
shapelib lucilanga smani
spatialite-gui   volter
spatialite-tools jdornak jstanek pkubat volter
vfrnav   sailer
xastir   lucilanga

Packages by maintainer:
alexl  perl-PDL
alexlangdal mapnik
bruno  qgis
caillonperl-PDL
caolanmperl-PDL
companyqt-mobility
daveisfera grass qgis
devrim gdal grass libgeotiff mapserver postgis
fabosm2pgsql
heliocastro qt-mobility
jamielinux nodejs-mapnik
jdekloepyproj
jdornakspatialite-tools
jmlich gdal postgis
johnp  perl-PDL
jplesnik   perl-PDL
jspaleta   python-basemap
jstanekspatialite-tools
jujens mapserver
kwizartplayer
limb   python-basemap
lkundrak   perl-PDL
lucilanga  shapelib xastir
maxamillion postgis
mbarnesperl-PDL
mmahut gdal
mmaslano   perl-PDL
netelergrass
oliver gdal grass mapserver
orion  gdal libgeotiff ncl
pali   gdal mapserver
pkajabapostgis
pkubat pgRouting postgis spatialite-tools
ppisar perl-PDL
praiskup   gdal postgis
qulogicR-rgdal R-rgeos python-cartopy
rdieterqt-mobility
rhughesperl-PDL
rmattesfawkes gazebo player
rnorwood   perl-PDL
rstrodeperl-PDL
sailer vfrnav
sharkczogdi qlandkartegt qmapshack
slankesmerkaartor
smani  osgearth shapelib
sspperl-PDL
than   qt-mobility
thofmann   fawkes
till   merkaartor
timn   fawkes player
tomh   libosmium mapnik nodejs-mapnik python-mapnik
ttorling   player
volter dans-gdal-scripts gdal grass libgeotiff librasterlite2
libspatialite pgRouting qgis saga spatialite-gui spatialite-tools

-- 
Elliott
___
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

xtl tests fail on ppc64le/armv7hl with gcc9

[Elliott Sales de Andrade]

Hi,

I've had some issues with tests for xtl not working on
ppc64le/armv7hl. These tests work fine on Fedora 29, but fail on 30+
[1]. Unfortunately, koschei does not check these platforms, but I'm
fairly certain these started failing when gcc was updated to 9.0.0.
Upstream is also suspicious that this might be a gcc9 issue [2].

Based on the errors, it's as if the code that's supposed to run to
modify strings just isn't run. It's as if the compiler has determined
that it should optimize away the relevant code. But somehow this
doesn't happen on all platforms.

While I am familiar with C and bits of C++, the template usage here is
a bit too much for me to figure out. Can anyone familiar with this
sort of thing take a look at what might be wrong?

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=35079811
[2] https://github.com/QuantStack/xtl/issues/137

-- 
Elliott
___
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: lmdb fails to map large DBs on i686/s390x

[Elliott Sales de Andrade]

Hi Tom,

On Tue, 4 Jun 2019 at 05:22, Tom Hughes  wrote:
>
> On 04/06/2019 10:03, Elliott Sales de Andrade wrote:
>
> > I have narrowed this down to the mmap call at [6] which attempts to
> > map the backing file into memory. AFAICT, the mapped size is far below
> > the RAM on the build machine as well as far below the normal 32-bit VM
> > limit. So I don't know why the call is failing.
>
> It's not really about the physical memory because just doing the
> mmap won't actually read it all in and in any case the kernel will
> be quite happy to page bits in and out as needed.
>
> The issue will be whether there is that much contiguous address
> space available - on a 32 bit machine 2**28 is, at best, one
> sixteenth of the potential address space.
>
> I say at best because even with the best possible user:kernel
> split at least some address space is reserved to the kernel
> although that can be fairly small with some kernel configurations.
>
> Then you have to take the memory map into account though, and
> how address randomisation may have placed other mappings in
> locations that mean such a large contiguous mapping is not in
> fact available.
>
> Take a look an /proc/NNN/maps for the process when the mmap
> fails and see if it looks like there it a range of that size
> that is actually available...
>

Thanks for the hint. I ran another test and patched it to print
/proc/self/maps whenever loading the lmdb file failed [1] (ignore
other arch failures; I just forgot to disable debuginfo.) Flattening
down the ranges, the largest free space is only about 50% of what the
test would need.

However, looking at the maps also hinted at a way out. There were a
_lot_ of lmdb mappings and looking at the tests, they never explicitly
close the files and rely on garbage collection to clean them up. So I
wrote a somewhat hacky patch to do:

try:
self.db = lmdb.open(...)
except lmdb.MemoryError:
gc.collect()
self.db = lmdb.open(...)

and now it passes [2]. I will report something upstream so that they
can modify the tests to be more explicit about closing things.

That being said, this does not explain why it fails in s390x mock (and
continues to fail even with gc). But I guess getting it to work on
koji is good enough for me.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=35282558
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=35291525

-- 
Elliott
___
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: HEADS UP: libgit 0.28

[Elliott Sales de Andrade]

Hi Igor,

On Wed, 5 Jun 2019 at 12:28, Igor Gnatenko
 wrote:
>
> Hello,
>
> I'm going to build libgit 0.28.x in rawhide and rebuild all affected
> packages somewhere this week.
>

This means switching to a different source branch for
golang-github-libgit2-git2go. Please let me know when 0.28 is ready
and I will change it to rebuild.

> Just FYI.

-- 
Elliott
___
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

lmdb fails to map large DBs on i686/s390x

[Elliott Sales de Andrade]

Hi,

I've been having some issues with LMDB on i686/s390x when building
python-zarr and its dependants. I filed a bug report [1], but the
maintainer suggested asking here to get more reach. I have replicated
my original message from the report below:

The documentation for LMDB [2] states that the map size should be
"chosen as large as possible". Consequently, the zarr developers have
chosen a map size of 2**40 on 64-bit systems and 2**28 on 32-bit
systems [3]. When the package is built on a 64-bit system [4],
everything works fine. However, if the build is run on a 32-bit system
[5], it fails with a MemoryError.

I have narrowed this down to the mmap call at [6] which attempts to
map the backing file into memory. AFAICT, the mapped size is far below
the RAM on the build machine as well as far below the normal 32-bit VM
limit. So I don't know why the call is failing.

I can reproduce this in mock with the fedora-rawhide-i386 config, but
what's weird is it also fails in the fedora-rawhide-s390x config. This
machine has 16G of RAM, so it's enough for 2**28, but not 2**40. So it
fails on 32-bit x86 with more than enough RAM, works on 64-bit x86
with nowhere near enough RAM, yet fails with 64-bit s390x.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1695525
[2] http://www.lmdb.tech/doc/group__mdb.html#gaa2506ec8dab3d969b0e609cd82e619e5
[3] 
https://github.com/zarr-developers/zarr/blob/f6ced1e31b919065f8834d813ec081d2a85195b3/zarr/storage.py#L1585-L1587
[4] https://koji.fedoraproject.org/koji/taskinfo?taskID=33910305
[5] https://koji.fedoraproject.org/koji/taskinfo?taskID=33881973
[6] 
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/liblmdb/mdb.c;h=e12af4482a0172da8d759c1da1530339d9095510;hb=2a5eaad6919ce6941dec4f0d5cce370707a00ba7#l4019

-- 
Elliott
___
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: Automating R package dependencies

[Elliott Sales de Andrade]

On Sun, Jun 16, 2019, 10:00 AM Iñaki Ucar,  wrote:

> On Sun, 16 Jun 2019 at 05:07, Elliott Sales de Andrade
>  wrote:
> >
> > Hi R-interested packagers and others,
> >
> > Recently, I've been looking at how RPM can automatically determine
> > Provides and Requires [1]. I have since implemented this for R using
> > an R script [2] and some file attributes [3]. Following other
> > languages' Provides, I have namespaced them as R(packageName). It then
> > adds corresponding Requires, Suggests, and Enhances.
> >
> > Additionally, R package versions commonly contain dashes. In order to
> > work in RPM, these are replaced with dots. For the automated
> > Provides/Requires, I have used the *real* versions instead.
> >
> > So now the question is how to apply this. I expect there are social
> > concerns, i.e., discussing with the R maintainer, making a
> > Self-contained Change, etc. But for this email, I am mostly concerned
> > with the technical aspects:
> >
> > 1. Is R-devel the right place to put the script and RPM attribute file
> > (all R packages would normally depend on this)?
>
> I believe R-SIG-Fedora is the right place.
>

I meant the package, not the mailing list... But I guess I should cc them
as well when this is more ready.


> > 2. Does this namespacing make sense?
> > 3. Are dashes in *namespaced* versions going to be a problem?
> > 4. Python had a flag to enable the automatic generator; do we need
> > this for R, and how was it implemented?
> > 5. I expect this would need a rebuild of all packages to get the
> > dependencies right (because the regular rebuild is unordered); would
> > this need a side tag? Or would leaving it for the normal mass rebuild
> > just be fine?
> > 6. R only has two levels of dependencies (hard-require or suggested,
> > but not installed by default). Thus both build- and runtime-optional
> > packages are in Suggests; do we care about the extra Suggests?
>
> Sometimes these extra Suggests are not satisfiable, but they can be
> removed after disabling vignette rebuilding. In other cases,
> Recommends are more appropriate for suggested packages.


Yes, but there's no way to know that automatically. Suggests are weak
hints, so the fact that they're not satisfiable shouldn'tbe a problem.
Packagers can always add explicit Recommends if they think it's useful.

Iñaki
>
> > [1] https://rpm.org/user_doc/dependency_generators.html
> > [2]
> https://src.fedoraproject.org/fork/qulogic/rpms/R/blob/autodeps/f/R-deps.R
> > [3]
> https://src.fedoraproject.org/fork/qulogic/rpms/R/blob/autodeps/f/R.attr
> ___
> 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

Re: rawhide no longer recognizing autotool macros

[Elliott Sales de Andrade]

On Wed, 19 Jun 2019 at 01:18, Philip Kovacs via devel
 wrote:
>
> OK, my builds are back in order having removed those macros and replaced them 
> with commands.
>
> I expect that many package maintainers will be hit with this.

There are in fact only 10 packages using these macros:

$ rg '__(aclocal|auto(conf|make))'
slurm.spec
228:%{__aclocal} -I auxdir
229:%{__autoconf}
230:%{__automake} --no-force

iperf.spec
21:%{__autoconf}

vtun.spec
42:%{__autoconf}

fastbit.spec
87:%{__aclocal} -I tests/m4
88:%{__autoconf}
89:%{__automake} --copy --no-force

libticonv.spec
48:%{__aclocal}
50:%{__automake} --add-missing
51:%{__autoconf}

iec16022.spec
45:%{__autoconf}

OpenIPMI.spec
93:%{__aclocal}
95:%{__automake} --add-missing --copy --foreign --force-missing
96:%{__autoconf}

lucidlife.spec
37:%{__autoconf}

trafshow.spec
44:%__autoconf

qrencode.spec
45:%{__autoconf}

>
> On Wednesday, June 19, 2019, 12:01:31 AM EDT, Neal Gompa  
> wrote:
>
>
> On Tue, Jun 18, 2019 at 10:48 PM Philip Kovacs via devel
>
>  wrote:
> >
> > I'm getting new build failures on the autotools macros that had been 
> > working for years.  rpmbuild doesn't like
> > them anymore in rawhide.  The macros are (or were) in the file 
> > `/usr/lib/rpm/macros`.  The relevant portion
> > of my spec is here:
> >
> > -- spec --
> > %build
> > %{__aclocal} -I auxdir
> > %{__autoconf}
> > %{__automake} --no-force
> >
> > Is there a new dependency I need to add or is something just broken?
>
> >
>
> Panu ripped them out for rpm 4.15:
> https://github.com/rpm-software-management/rpm/pull/691
>
> You can trivially switch to just calling the commands...
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> 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



-- 
Elliott
___
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: glibc-arm-linux-gnu help

[Elliott Sales de Andrade]

On Mon, 10 Jun 2019 at 16:46, Tom Callaway  wrote:
>
> Reviving this. I do not have the time nor the energy to attempt to keep this 
> going, so I am going to disable the shared bits in cross-gcc and kill off 
> glibc-arm-linux-gnu. It's been broken for a while, so I doubt anyone will be 
> seriously impacted by this.

Ah that's unfortunate. I've been working on something that could
possibly make use of this, but I haven't quite reached the stage of
testing this out with it, and since it wasn't in Rawhide, I hadn't
taken much look into it.

I see that Debian has pretty much every cross version of libc6:
https://packages.debian.org/search?keywords=libc6=names=all=all

What makes it so easy for them? / What makes it difficult for us? How
can we make cross toolchains easier?

> If you are, I suggest using this copr instead:
> https://copr.fedorainfracloud.org/coprs/lantw44/arm-linux-gnueabi-toolchain/
>
> ~tom
>
> On Wed, Nov 7, 2018 at 11:02 AM Tom Callaway  wrote:
>>
>>
>>
>> On 11/7/18 11:00 AM, Tom Callaway wrote:
>> > A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could
>> > have a packaged arm cross-toolchain that was useful (with glibc, it
>> > cannot build anything in userspace)
>>
>> This should have read "without glibc, it cannot build anything in
>> userspace".
>>
>> ~tom
>
> ___
> 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



-- 
Elliott
___
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: glibc-arm-linux-gnu help

[Elliott Sales de Andrade]

On Wed, 12 Jun 2019 at 08:33, Nicolas Chauvet  wrote:
>
> Le mer. 12 juin 2019 à 10:50, Elliott Sales de Andrade
>  a écrit :
> >
> > On Mon, 10 Jun 2019 at 16:46, Tom Callaway  wrote:
> > >
> > > Reviving this. I do not have the time nor the energy to attempt to keep 
> > > this going, so I am going to disable the shared bits in cross-gcc and 
> > > kill off glibc-arm-linux-gnu. It's been broken for a while, so I doubt 
> > > anyone will be seriously impacted by this.
> >
> > Ah that's unfortunate. I've been working on something that could
> > possibly make use of this, but I haven't quite reached the stage of
> > testing this out with it, and since it wasn't in Rawhide, I hadn't
> > taken much look into it.
> >
> > I see that Debian has pretty much every cross version of libc6:
> > https://packages.debian.org/search?keywords=libc6=names=all=all
> >
> > What makes it so easy for them? / What makes it difficult for us? How
> > can we make cross toolchains easier?
>
> Probably time/human ressources.
> I would be interested in having a working cross compilation toolchain
> also (specially for case where 32bit linking is an issue like chromium
> or else).
> I have tried to work on some patches (including kernel-headers), but
> not had time to fully qualify the changes.
>
> FYI, I've tried to contact the maintainer of the copr repo pointed by
> Tom, so far no answer.
> Looking at some of his copr contributions, he haven't found the right
> step to contribute to fedora main repository yet (also others topics).

To follow up here, I think one of the main issues is the lack of
documentation/guidelines for this case. I've tried to review a
cross-compiler (mspgcc) package, but rpmlint complains about a bunch
of stuff (using lib not lib64, headers in non-devel packages, etc.)
which may or may not be relevant to compilers. I _think_ that the
package is doing the right thing, because it emulates gcc, but I don't
_know_ that it is. And it seems like the Embedded SIG never
answered...

So I can't say that's the case for this copr maintainer, but the
package review for compilers might just seem too much trouble to be
worth it.

> This is unfortunate and I fear this situation is going to increase
> with users kept in their copr projects...
>
> --
> -
>
> Nicolas (kwizart)

-- 
Elliott
___
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

Automating R package dependencies

[Elliott Sales de Andrade]

Hi R-interested packagers and others,

Recently, I've been looking at how RPM can automatically determine
Provides and Requires [1]. I have since implemented this for R using
an R script [2] and some file attributes [3]. Following other
languages' Provides, I have namespaced them as R(packageName). It then
adds corresponding Requires, Suggests, and Enhances.

Additionally, R package versions commonly contain dashes. In order to
work in RPM, these are replaced with dots. For the automated
Provides/Requires, I have used the *real* versions instead.

So now the question is how to apply this. I expect there are social
concerns, i.e., discussing with the R maintainer, making a
Self-contained Change, etc. But for this email, I am mostly concerned
with the technical aspects:

1. Is R-devel the right place to put the script and RPM attribute file
(all R packages would normally depend on this)?
2. Does this namespacing make sense?
3. Are dashes in *namespaced* versions going to be a problem?
4. Python had a flag to enable the automatic generator; do we need
this for R, and how was it implemented?
5. I expect this would need a rebuild of all packages to get the
dependencies right (because the regular rebuild is unordered); would
this need a side tag? Or would leaving it for the normal mass rebuild
just be fine?
6. R only has two levels of dependencies (hard-require or suggested,
but not installed by default). Thus both build- and runtime-optional
packages are in Suggests; do we care about the extra Suggests?

[1] https://rpm.org/user_doc/dependency_generators.html
[2] https://src.fedoraproject.org/fork/qulogic/rpms/R/blob/autodeps/f/R-deps.R
[3] https://src.fedoraproject.org/fork/qulogic/rpms/R/blob/autodeps/f/R.attr

--
Elliott
___
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: Fedora 31 System-Wide Change proposal: Python means Python3

[Elliott Sales de Andrade]

On Thu, 27 Jun 2019 at 18:59,  wrote:
>
> On Thu, Jun 27, 2019 at 4:34 PM, Neal Gompa  wrote:
> > This is because
> > in everything *except* Linux distributions, the unversioned name has
> > already switched over.
>
> Not in macOS.

System macOS is still Python 2, but new developers are not encouraged
to use it. Any reasonable Python macOS programmer uses conda or
virtualenv (or a wrapper like pyenv, pipenv, etc.), and a Python 3
environment will set python->python3.

-- 
Elliott
___
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: Automating R package dependencies

[Elliott Sales de Andrade]

FYI, I have put together a Change proposal for this work, which you
may have seen announced [1].

On Mon, 17 Jun 2019 at 09:35, José Abílio Matos  wrote:
>
> On Sunday, 16 June 2019 03.09.41 WEST Elliott Sales de Andrade wrote:
> > Hi R-interested packagers and others,
> >
> > So now the question is how to apply this. I expect there are social
> > concerns, i.e., discussing with the R maintainer, making a
> > Self-contained Change, etc. But for this email, I am mostly concerned
> > with the technical aspects:
> >
> > 1. Is R-devel the right place to put the script and RPM attribute file
> > (all R packages would normally depend on this)?
>
> Either that or create a new package R-rpm-macros and have R-devel depending on
> it (just like it happens for python).
>

Coupled with Florian's suggestion to place the files in the RPM
ecosystem, I plan to make an R-rpm-macros package for this.

> > 2. Does this namespacing make sense?
>
> What are your doubts here?
>
> 1) use a versioned dependency like R3.6dist(packageName);
> or
> 2) refer to the repository R_cran(packageName)?
>

I'm just looking for any issues that may arise. I don't believe these
latter two would work though. For 1, encoding the minor version seems
unnecessary. While 3.4->3.5 required rebuilding compiled libraries,
3.5->3.6 did not. And non-compiled libraries did not need a rebuild at
all. So adding the minor version would cause extraneous rebuilds when
new R versions come out. For 2, I'm not sure indicating CRAN source
adds any clarity.

> > 3. Are dashes in *namespaced* versions going to be a problem?
>
> I do not think so. I remember in python one case where this happens:
> # rpm -q --provides python3-dateutil
> python3-dateutil = 1:2.8.0-1.fc30
> python3.7dist(python-dateutil) = 2.8.0
> python3dist(python-dateutil) = 2.8.0
>

I was asking about versions, not names.

> > 4. Python had a flag to enable the automatic generator; do we need
> > this for R, and how was it implemented?
> > 5. I expect this would need a rebuild of all packages to get the
> > dependencies right (because the regular rebuild is unordered); would
> > this need a side tag? Or would leaving it for the normal mass rebuild
> > just be fine?
>
> I tend to the last option if we ensure that all R packages are rebuilt.
>

I've discussed with releng and have a simple plan to build without side tag [2].

> > 6. R only has two levels of dependencies (hard-require or suggested,
> > but not installed by default). Thus both build- and runtime-optional
> > packages are in Suggests; do we care about the extra Suggests?
>
> Does dnf cares about Suggests?
>
> According to dnf.conf the option install_weak_deps:
> "When this option is set to True and a new package is about to be installed,
> all packages linked by weak dependency relation (Recommends  or  Supplements
> flags) with this package will pulled into the transaction.  Default is True."
>
> It does not refers Suggests...
>

Not directly at this time. It is simply an unused hint. It is possible
for dnf to print them out for the user to further decide, but nothing
is implemented right now.

> --
> José Abílio
>

[1] https://fedoraproject.org/wiki/Changes/Automatic_R_runtime_dependencies
[2] https://pagure.io/releng/issue/8501

-- 
Elliott
___
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: error: More than one file on a line

[Elliott Sales de Andrade]

On Sat, Aug 3, 2019, 3:49 PM Christoph Junghans,  wrote:

> Hi,
>
> related to https://src.fedoraproject.org/rpms/kim-api/pull-request/1
> I am getting a strange error:
>
> RPM build errors:
> BUILDSTDERR: More than one file on a line:
> /_kim-api-collections-management
> BUILDSTDERR: More than one file on a line:
> /kim-api-collections-management.bash
> (see https://koji.fedoraproject.org/koji/taskinfo?taskID=36767148)
> I remember I have seen this before for bash-completion files, but I
> can unfortunately not remember what the solution was.
>
> the lines in the spec triggering this install are:
> %files
> ...
> %{z_compdir}/_kim-api-collections-management
> %{z_compdir}/kim-api-collections-management.bash
> with:
> %global z_compdir "%{_datadir}/zsh/site-functions"
> which is given to CMake
> %{cmake3}  -DZSH_COMPLETION_COMPLETIONSDIR=%{z_compdir} ..
> and picked up correctly:
> -- Installing:
> /builddir/build/BUILDROOT/kim-api-2.1.2-1.fc31.i386/usr/share/zsh/site-functions/_kim-api-collections-management
> -- Installing:
> /builddir/build/BUILDROOT/kim-api-2.1.2-1.fc31.i386/usr/share/zsh/site-functions/kim-api-collections-management.bash
> nagement
>
> Any ideas?


Remove the quotes on the %global and only use them for the shell
invocations (or not at all because there won't be any spaces in the path
anyway.)

Christoph
>
>
>
> --
> Christoph Junghans
> Web: http://www.compphys.de
> ___
> 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

Re: systemd-243-rc1

[Elliott Sales de Andrade]

On Fri, 2 Aug 2019 at 05:33, Adam Williamson  wrote:
>
> On Thu, 2019-08-01 at 14:36 +0200, Nicolas Mailhot via devel wrote:
> > Le jeudi 01 août 2019 à 14:19 +0200, Lennart Poettering a écrit :
> > > On Do, 01.08.19 10:14, Fabio Valentini (decatho...@gmail.com) wrote:
> > >
> > > > Since these things are both the case, a simple 1:1 mapping from "-"
> > > > to
> > > > "~" (and even back) is exactly correct.
> > > > So I think the systemd.spec is doing exactly the right thing here.
> > > >
> > > > The only issue I see is the arbitrary (?) restriction that git tags
> > > > cannot contain the tilde character.
> > > > Or is that there for filesystem compatibility, because tags are
> > > > just files?
> > >
> > > git uses "~" for referencing commits relative to a commit identifier,
> > > see:
> > >
> > > https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emltrevgtltngtemegemHEADmaster3em
> > >
> > > Hence they do not allow it in tag names, to avoid the ambiguity.
> > >
> > > I guess RPM is the outlier for using ~ the way it uses it, I don't
> > > think much other software does that.
> >
> > ~ is a debianism, introduced in rpm because some felt it was going to
> > satisfy uptream needs for irregular preversiob versioning
> >
> > what rpm likes, and pretty much all component management stacks like
> > and support, is pure series of numbers separated with dots, without the
> > -foo pre-version madness that breaks everywhere in slightly different
> > ways.
> >
> > Don't release anything that is not a series of numbers separated with
> > dots, no one ever managed to define anything else that works for
> > everyone (and many tried).
> >
> > The preversion in semver is basically "it will break right and left,
> > who cares, no one will use it". Written by idealists that forgot the
> > point of preversions is to be used and deployed so some testing is done
> > before final release.
>
> Hmm. I never really chipped into the ~ discussion, but it just occurred
> to me it intersects with a discussion I care quite a lot about: RPM
> version comparison. Especially RPM version comparison when all you have
> to deal with is a string that represents an RPM N(E)VR(A) somehow
> (that's 'name', 'epoch', 'version', 'release', 'arch').
>
> This is a corner case quite a few of us run into (it can happen for
> e.g. when you're working off a fedmsg which just gives you a NEVRA
> string) and it has some surprising properties, like: there isn't really
> a 'good' standard way to do it. RPM doesn't expose this in its public
> APIs. The best way anyone seems to know of to do it in Python, for
> instance, is using `hawkey.split_nevra`...only hawkey is a bit weird,
> it's provided by libdnf and is not in pypi, which means running tests
> on code that uses it using standard stuff like tox-in-a-container is
> difficult. Also, DNF folks have suggested they want it to go away.
>
> You can split a N(E)VR(A) string into components quite easily and
> reliably with standard string manipulations, but comparing the
> components the way RPM does it is difficult to re-implement...and of
> course, the more weird rules like ~ we introduce, the harder it gets.
>
> Anyhow, it occurred to me to try out how hawkey.split_nevra handles
> this tilde scenario, and the answer seems to be "a bit oddly":
>
> >>> tildenevra = hawkey.split_nevra('systemd-243~rc1-1.fc31')
> >>> releasenevra = hawkey.split_nevra('systemd-243-1.fc31')
> >>> releasenevra > tildenevra
> True
> >>> releasenevra.version
> '243'
> >>> tildenevra.version
> '243~rc1'
> >>> releasenevra.version > tildenevra.version
> False
> >>> tildenevra.version > releasenevra.version
> True
>

In [15]: type(releasenevra)
Out[15]: _hawkey.NEVRA

In [16]: type(releasenevra.version)
Out[16]: str

The former probably has a custom __lt__ comparison method, while the
latter is just a regular string and compares using regular string
semantics. Longer (but otherwise the same) strings are "greater" than
shorter strings.

> So...basically, it thinks the entire NEVRA object you get from the
> string 'systemd-243-1.fc31' is "higher versioned" than the NEVRA object
> you get from the string 'systemd-243~rc1-1.fc31'. Which is good, that's
> correct. However, it thinks the version component of 'systemd-243~rc1-
> 1.fc31' is higher than the version component of 'systemd-243-1.fc31'.
> Which I believe is wrong, and also, it's a bit baffling, because if it
> thinks that, I don't understand how it gets to the (correct) conclusion
> that the entire tildenevra is lower versioned than the releasenevra,
> since the 'name' and 'epoch' ('systemd' and 0, respectively) are the
> same for both...
>
> Anyone see what I'm missing?
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 

Re: Orphaning some packages

[Elliott Sales de Andrade]

Hi Pierre,

On Sat, 3 Aug 2019 at 14:35, Pierre-Yves Chibon  wrote:
>
> Good Morning Everyone,
>
> I think it's time I make amends and recognize that I've been a terrible
> maintainer for a number of my packages.
> So I'd like to orphan the following packages hoping they can find a better 
> home.
>
> I no longer use R, so all of my R libraries:
> rpms/R-affy
> rpms/R-affydata
> rpms/R-affyio
> rpms/R-ALL
> rpms/R-AnnotationDbi
> rpms/R-Biobase
> rpms/R-BiocGenerics
> rpms/R-Biostrings
> rpms/R-BSgenome
> rpms/R-BSgenome.Celegans.UCSC.ce2
> rpms/R-BufferedMatrix
> rpms/R-BufferedMatrixMethods
> rpms/R-caTools
> rpms/R-DynDoc
> rpms/R-fibroEset
> rpms/R-GenomicFeatures
> rpms/R-GenomicRanges
> rpms/R-hgu133acdf
> rpms/R-hgu95av2cdf
> rpms/R-hgu95av2probe
> rpms/R-IRanges
> rpms/rkward
> rpms/R-maanova
> rpms/R-multtest
> rpms/R-pls
> rpms/R-preprocessCore
> rpms/R-qvalue
> rpms/R-rlecuyer
> rpms/R-ROC
> rpms/R-RUnit
> rpms/R-sandwich
> rpms/R-statmod
> rpms/R-timeDate
> rpms/R-tkWidgets
> rpms/R-widgetTools
> rpms/R-XML
> rpms/R-xtable
>

I can take R-caTools, R-RUnit, R-timeDate, R-XML, and R-xtable.

And while I have your attention, I'd like to ask about maintaining
R2spec, which has several open PRs but has not been touched for ages.

> rpms/trac-mastertickets-plugin
>No longer used in infra
>
> rpms/libdivecomputer
> rpms/subsurface
>   Upstream (of the later) does a lot of bundling and I've had a hard time
>   keeping up with it. I think this one may be more suitable for a flatpack 
> tbh.
>   libdivecomputer is a dependency of subsurface.
>
> rpms/igraph
> rpms/python-igraph
>   I picked these two when I was looking at graph libraries but I've never done
>   anything with them
>
> rpms/python-rdfextras
>   I took over this one but I'm not using it anywhere and not keeping up with
>   upstream
>
>
> Let me know if you are interested in any of them and I'll give them to you.
> Otherwise I'll likely orphan them when I can back from flock.
>
>
>
> Best,
> Pierre

-- 
Elliott
___
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: Orphaned some (mostly Python) packages

[Elliott Sales de Andrade]

Hi Miro,

On Wed, 7 Aug 2019 at 07:21, Miro Hrončok  wrote:
>
> # python-behave
> Leaf.
> Doesn't build yet with Python 3.8, but a patch exists:
> https://bugzilla.redhat.com/show_bug.cgi?id=1706085
>
>
> # python-cligj
> python-rasterio and python-fiona depend on that.
>

I can take this one, since my packages depend on it.

>
> # python-coverage_pth
> python-pytest-testmon depends on that.
>
>
> # python-jeepney
> python-SecretStorage -> python-keyring depends on that.
>
>
> # python-pathtools
> Needed by:
>python-sphinx-autobuild
>python-watchdog
>python-Lektor
>python-pytest-watch
>
>
> # python-pep8
> BuildRequired by many, but they have been warned:
> https://bugzilla.redhat.com/show_bug.cgi?id=1667200
> Switch to python-pycodestyle or better stop linting in %check.
>
>
> # rpmlint-scl-config
> Leaf. Packaged long time ago and never touched since.
>
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok



-- 
Elliott
___
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: Workaround for missing gpg keys in mock?

[Elliott Sales de Andrade]

On Thu, 22 Aug 2019 at 22:43, Christopher  wrote:
>
> On Thu, Aug 22, 2019 at 9:03 PM Nico Kadel-Garcia  wrote:
> >
> > On Thu, Aug 22, 2019 at 7:57 PM Christopher  
> > wrote:
> > >
> > > I'm trying to do `fedpkg mock` to locally build some packages, and I
> > > keep getting errors about GPG keys not found for f31/f32 packages. How
> > > do I work around this?
> >
> > Disable gpg checks in /etc/mock/whatever.cfg ?
>
> Thanks. I went looking at /etc/mock/fedora-rawhide-x86_64.cfg to
> figure out how to do that... and I found the problem. The file is
> still configured as though f31 is rawhide. So, I simply replaced all
> occurrences of "31" with "32", and "30" with "31".
>

This is fixed in the current version of mock-core-configs. It was just
pushed to stable, so you should be able to update it soon.

> And, then it worked fine. So, thanks for pointing me in the right
> direction. The answer was really stupidly obvious once I knew where to
> look. :)

-- 
Elliott
___
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: Donate 1 minute of your time to test upgrades from F30 to F31

[Elliott Sales de Andrade]

On Wed, 11 Sep 2019 at 11:53, Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Sep 11, 2019 at 10:48:51AM -0400, Solomon Peachy wrote:
> > On Wed, Sep 11, 2019 at 03:16:28PM +0100, Phil Wyett wrote:
> > > > Do you want to make Fedora 31 better? Please spend 1 minute of your
> > > > time and try to run [*]:
> > > >
> > > >   sudo dnf --releasever=31 --setopt=module_platform_id=platform:f31
> > > > --enablerepo=updates-testing distro-sync
> >
> > Here's an upgrade run against five systems.  There's a few more I can
> > test but they're not accessible from here.
> >
> > System 1:  (Laptop)
> >
> > Error:
> >  Problem 1: problem with installed package 0ad-0.0.23b-6.fc30.x86_64
> >   - 0ad-0.0.23b-6.fc30.x86_64 does not belong to a distupgrade repository
> >   - nothing provides libmozjs38-ps-release.so()(64bit) needed by 
> > 0ad-0.0.23b-8.fc31.x86_64
> >   - nothing provides libmozjs38-ps-release.so(js)(64bit) needed by 
> > 0ad-0.0.23b-8.fc31.x86_64
>
> I see kalev is building 0ad right now, so hopefully this will be resolved 
> soon.
>
> >  Problem 2: package python2-pillow-qt-5.4.1-2.fc30.x86_64 requires 
> > python2-pillow(x86-64) = 5.4.1-2.fc30, but none of the providers can be 
> > installed
> >   - python2-pillow-5.4.1-2.fc30.x86_64 does not belong to a distupgrade 
> > repository
> >   - problem with installed package python2-pillow-qt-5.4.1-2.fc30.x86_64
>
> So the python2-pillow-qt subpackage was dropped, but not all
> python2-pillow subpackages. It'd be best if pillow maintainers either
> do the obsoletes internally or file a bug against f-o-p.
>
> >
> > System 2:  (Workstation)
> >
> > Modular dependency problems:
> >
> >  Problem 1: conflicting requests
> >   - nothing provides module(platform:f30) needed by module 
> > eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64
> >  Problem 2: module jmc:latest:3120190813124555:7188e41a-0.x86_64 requires 
> > module(eclipse), but none of the providers can be installed
> >   - conflicting requests
> >   - nothing provides module(platform:f30) needed by module 
> > eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64
>
> >  Problem 2: package aeskulap-0.2.2-0.37.beta2.fc30.x86_64 requires 
> > libdcmdata.so.12()(64bit), but none of the providers can be installed
>
> aeskulap is gone. I'll add it to f-o-p.
>
> >   - dcmtk-3.6.2-4.fc29.x86_64 does not belong to a distupgrade repository
>
> This either needs a rebuild or an update.
>
> >  Problem 3: package gegl03-0.3.30-5.fc30.x86_64 requires 
> > libIlmImf-2_2.so.22()(64bit), but none of the providers can be installed
> >   - OpenEXR-libs-2.2.0-16.fc30.x86_64 does not belong to a distupgrade 
> > repository
> >   - problem with installed package gegl03-0.3.30-5.fc30.x86_64

I've opened https://bugzilla.redhat.com/show_bug.cgi?id=1751416 for
gegl04 to obsolete gegl03.

> >  Problem 4: package obnam-1.21-7.fc29.x86_64 requires python2-cliapp, but 
> > none of the providers can be installed
> >   - python2-cliapp-1.20180121-1.fc30.noarch does not belong to a 
> > distupgrade repository
> >   - problem with installed package obnam-1.21-7.fc29.x86_64
> >  Problem 5: package python2-terminado-0.8.1-6.fc29.noarch requires 
> > python2-tornado >= 4.0.0, but none of the providers can be installed
> >   - python2-tornado-5.0.2-5.fc30.x86_64 does not belong to a distupgrade 
> > repository
>
> python2-tornado is already in f-o-p. I'll add 
> python2-terminado-0.8.1-6.fc29.noarch.
>
> >   - problem with installed package python2-terminado-0.8.1-6.fc29.noarch
> >  Problem 6: problem with installed package 
> > libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64
> >   - package libopenshot-0.2.3-2.20190406git101f25a.fc31.x86_64 requires 
> > libjsoncpp.so.19()(64bit), but none of the providers can be installed
> >   - libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64 does not belong to a 
> > distupgrade repository
> >   - jsoncpp-1.8.4-6.fc30.x86_64 does not belong to a distupgrade repository
> >  Problem 7: cannot install both jsoncpp-1.9.1-1.fc31.x86_64 and 
> > jsoncpp-1.8.4-6.fc30.x86_64
> >   - package python3-libopenshot-0.2.3-2.20190406git101f25a.fc31.x86_64 
> > requires libjsoncpp.so.19()(64bit), but none of the providers can be 
> > installed
> >   - package cmake-3.14.5-4.fc31.x86_64 requires libjsoncpp.so.21()(64bit), 
> > but none of the providers can be installed
> >   - problem with installed package 
> > python3-libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64
> >   - problem with installed package cmake-3.14.5-1.fc30.x86_64
> >   - python3-libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64 does not 
> > belong to a distupgrade repository
> >   - cmake-3.14.5-1.fc30.x86_64 does not belong to a distupgrade repository
> >  Problem 8: package openshot-2.4.4-2.fc31.noarch requires 
> > python3-libopenshot >= 0.2.3, but none of the providers can be installed
> >   - package python3-libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64 
> > requires libjsoncpp.so.19()(64bit), but none of the providers can be 
> > 

Re: Donate 1 minute of your time to test upgrades from F30 to F31

[Elliott Sales de Andrade]

On Thu, Sep 12, 2019, 10:24 AM Ankur Sinha,  wrote:

> On Wed, Sep 11, 2019 10:48:51 -0400, Solomon Peachy wrote:
> >   - vtk-8.1.1-5.fc30.x86_64 does not belong to a distupgrade repository
>
> There's vtk 8.2.0-6 that is already in F31 stable. So not sure what this
> implies:
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-986bbe4d7f
>
> In general what does "does not belong to a distupgrade repository" mean?
>

>From the dist tag, you can see this package is from F30, the old (and to be
deleted from the system) repo. "Not belong to a distupgrade repository"
means it didn't come from F31, the _new_ repo. It's a leftover that is
either pulling in old (unsatisfiable) Requires or is pulled in by some
other leftover.
___
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: Orphaned packages to be retired (~400 during this week)

[Elliott Sales de Andrade]

On Mon, 9 Sep 2019 at 18:02, David Sommerseth  wrote:
>
> On 09/09/2019 23:49, Miro Hrončok wrote:
> > The following packages are orphaned and will be retired when they
> > are orphaned for six weeks, unless someone adopts them. If you know for sure
> > that the package should be retired, please do so now with a proper reason:
> > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> [...snip...]
>
> > dsommers: python-which
>
> This surprises me quite a lot.  I have never been a package maintainer for
> this package.
>

It's not saying you're a package maintainer for this package. It's
saying you'll be affected by its orphaning.

Search for python-which and you'll see it's because python-ethtool
depends on it, and you maintain _that_.

>
> --
> kind regards,
>
> David Sommerseth

-- 
Elliott
___
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: fedora-review seam to not work 8-(

[Elliott Sales de Andrade]

On Mon, 5 Aug 2019 at 18:28, Robert-André Mauchin  wrote:
>
> On Monday, 5 August 2019 18:05:27 CEST J. Scheurich wrote:
> > Hi,
> >
> > (Since the last update ?) fedora-review seams to not work:
> >
> > I am using
> >
> > Spec URL: ftp://ftp.ourproject.org/pub/wdune/vcglib.spec
> > SRPM URL: ftp://ftp.ourproject.org/pub/wdune/vcglib-1.0.1-1.src.rpm
> >
> > as a testcase.
> >
> > $ fedora-review -n vcglib
> > INFO: Processing local files: vcglib
> > INFO: Getting .spec and .srpm Urls from : Local files in /home/home/mufti
> > INFO:   --> SRPM url: file:///home/home/mufti/vcglib-1.0.1-1.src.rpm
> > INFO:   --> Spec url: file:///home/home/mufti/vcglib.spec
> > INFO: Using review directory: /home/home/mufti/review-vcglib
> > ERROR: Exception down the road... (logs in
> > /home/mufti/.cache/fedora-review.log)
> >
> > $ less /home/mufti/.cache/fedora-review.log
> > ...
> > 08-05 17:51 root INFO   --> SRPM url:
> > file:///home/home/mufti/vcglib-1.0.1-1.src.rpm
> > 08-05 17:51 root INFO   --> Spec url:
> > file:///home/home/mufti/vcglib.spec
> > 08-05 17:51 root DEBUGfind_urls completed: 0.010
> > 08-05 17:51 root INFO Using review directory:
> > /home/home/mufti/review-vcglib
> > 08-05 17:51 root DEBUGAvoiding init of working mock root
> > 08-05 17:51 root DEBUGUrl download completed: 2.384
> > 08-05 15:51 root DEBUGException down the road...
> > Traceback (most recent call last):
> >   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> > line 236, in run
> > self._do_run(outfile)
> >   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> > line 226, in _do_run
> > self._do_report(outfile)
> >   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> > line 99, in _do_report
> > ...
> >
> > As far as i understand python, a "BaseException" occored in
> > self._do_run(outfile):
> >
> > $ less +232 /usr/lib/python3.7/site-packages/FedoraReview/review_helper.py
> >self.log.debug("fedora-review %s %s started", __version__,
> > BUILD_FULL)
> > self.log.debug("Command  line: %s", " ".join(sys.argv))
> > try:
> > rcode = 0
> > self._do_run(outfile)
> > except ReviewError as err:
> > if isinstance(err, SpecParseReviewError):
> > nvr = _Nvr(self.bug.get_name())
> > result = SimpleTestResult(
> > "SpecFileParseError", "Can't parse the spec file: ",
> > str(err)
> > )
> > write_xml_report(nvr, [result])
> > self.log.debug("ReviewError: %s", str(err), exc_info=True)
> > if not err.silent:
> > msg = "ERROR: " + str(err)
> > if err.show_logs:
> > msg += " (logs in " + Settings.session_log + ")"
> > self.log.error(msg)
> > rcode = err.exitcode
> > except BaseException:
> > self.log.debug("Exception down the road...", exc_info=True)
> > self.log.error(
> > "Exception down the road... (logs in %s)",
> > Settings.session_log
> > ...
> >
> > What i am doing wrong ?
> >
> > so long
> > MUFTI
>
>
> What's your version of fedora-review? You should have 0.7.2
>
> Name : fedora-review
> Version  : 0.7.2
> Release  : 1.fc30
> Architecture : noarch
> Size : 626 k
> Source   : fedora-review-0.7.2-1.fc30.src.rpm
> Repository   : @System
> From repo: updates-testing
> Summary  : Review tool for fedora rpm packages
> URL  : https://pagure.io/FedoraReview
> License  : GPLv2+
> Description  : This tool automates much of the dirty work when reviewing a
> package
>  : for the Fedora Package Collection like:
>  :
>  : * Downloading SRPM & SPEC.
>  : * Download upstream source
>  : * Check md5sums
>  : * Build and install package in mock.
>  : * Run rpmlint.
>  : * Generate a review template, which becomes the starting
>  :   point for the review work.
>  :
>  : The tool is composed of plugins, one for each supported
> language.
>  : As of today, there is plugins for C/C++, Ruby, java, R, perl
> and
>  : python.  There is also support for external tests that can be
> written
>  : in a simple way in bash.
>
>
> For you SPEC, you should drop the main package and only keep devel.
>
> Drop %global debug_package %{nil}  and make the package noarch
>

No, that's not correct. Header-only libraries are not noarch, and
disable debug packages.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_packaging_header_only_libraries

> Use: Source: https://github.com/cnr-isti-vclab/vcglib/archive/v%{version}/%
> {name}-%{version}.tar.gz
>
> Use cp -a to keep attributes: 

Re: Vim and spec template

[Elliott Sales de Andrade]

On Fri, 19 Jul 2019 at 05:09, Zdenek Dohnal  wrote:
>
>
> On 7/18/19 9:47 PM, Jason L Tibbitts III wrote:
> >> "ZD" == Zdenek Dohnal  writes:
> > ZD> Hi all, I would like to ask as Vim co-maintainer, do you find useful
> > ZD> for Vim to do:
> >
> > ZD> - when you open new file with .spec suffix, Vim will get you basic
> > ZD> spec file structure?
> >
> > Personally I have always found that behavior annoying.  If I open a new
> > file, I expect that the file would be empty.  If I want a template, I
> > can copy one.  Editing a new HTML file doesn't bring up a template for
> > HTML files, for example.
> >
> > The spec template used isn't something I ever want anyway.  It uses tabs
> > instead of spaces and uses them in a way that implies that indentation
> > is somehow required.
> Converted to spaces now.
> >   And it includes a default release tag of
> > "0%{?dist}" which isn't permitted by the packaging guidelines.
> Expected. It is designed for user to run rpmdev-bumpspec .spec,
> so the tool will supply correct format of changelog entry and increment
> the release.

Why would you use rpmdev-bumpspec for a file created in vim when you
can use c in vim directly?

> > (Releases start at one except when packaging prerelease software, and are
> > never exactly zero.)
> >
> > Best to leave it to the packager to choose their own template, or to
> > allow somehow who wants templating behavior to configure templating in a
> > general way.
> >
> >  - J<
>
> --
> Zdenek Dohnal
> Software Engineer
> Red Hat Czech - Brno TPB-C
>
>
> ___
> 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



-- 
Elliott
___
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: NeuroFedora review swaps

[Elliott Sales de Andrade]

Hi Ankur,

On Fri, 19 Jul 2019 at 19:54, Ankur Sinha  wrote:
>
> Hello,
>
> Here are a few new NeuroFedora packages that need review. Happy to swap
> reviews---I only have the one review to do at the moment which I intend
> to complete over the weekend.
>

If you could, please have a look at:
R-rpm-macros - https://bugzilla.redhat.com/show_bug.cgi?id=1731422
The package itself is fairly trivial, and the actual implementation
stuff is being reviewed elsewhere.

> - calcium-calculator: https://bugzilla.redhat.com/show_bug.cgi?id=1731528
> This is a trivial review. If you are a beginner looking for a simple
> package to review, try this one.
>
> - python-pytest-sugar: https://bugzilla.redhat.com/show_bug.cgi?id=1731568
> This is also a trivial review!
>
> - python-matplotlib-scalebar: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1731594
> This is *also* a trivial review!
>
> - python-netpyne: https://bugzilla.redhat.com/show_bug.cgi?id=1731592
>

I reviewed these first 4, but someone beat me to the next one.

> - python-pingouin: https://bugzilla.redhat.com/show_bug.cgi?id=1731583
>
> - MUSIC: https://bugzilla.redhat.com/show_bug.cgi?id=1731487
> This one is slightly advanced since it is built with MPI also. This is
> where we have the ppc build failing, so it may need some investigation.
>

I'll wait on this until you've investigated the build failure.

> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) | 
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London

-- 
Elliott
___
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

Removing macros.R

[Elliott Sales de Andrade]

Hi,

(This message is cross-posted to the Fedora devel and R SIG Fedora
mailing lists.)

Currently, R-core installs macros.R which defines one macro:
%_R_make_search_index   /usr/lib/rpm/R-make-search-index.sh

This script does nothing, and there is no mention of this macro in our
guidelines. The macro is used by one package, R-systemfit. The script
is not used.

According to the R %changelog, it was disabled in 2009.

I would like to clean this up, and will do so in approximately a week,
and/or whenever the mass rebuild finishes.

-- 
Elliott
___
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

[HEADS-UP] Excluding unavailable Suggests from R packages

[Elliott Sales de Andrade]

Hello,

As you may or may not know, due to this F31 Change [1], all R packages
now have Suggests for all packages in their metadata automatically. In
the discussion with FPC and Legal [2], it has been determined that the
Suggests cannot apply to non-existent packages.

I have already fixed my packages, but since it has been some time
since the Change was implemented, I'm sending a heads-up that I plan
to exclude unavailable Suggests from the remaining packages listed at
[3] and below. I will be adding a %global __suggests_exclude in
accordance with the current R packaging guidelines [4]. If you wish to
implement this some other way, please let me know so I won't duplicate
your work. I will do this in approximately one week's time.

I have bcc'd the affected package maintainers, so apologies if you
receive this message multiple times.

Maintainers by package:
R-DBIspot
R-DelayedArray   spot
R-GenomeInfoDb   spot
R-GenomicAlignments  spot
R-R6 spot
R-RSQLitespot
R-Rcpp   ellert
R-Rsamtools  spot
R-S4Vectors  spot
R-SummarizedExperiment spot
R-XVectorspot
R-biomaRtspot
R-blob   spot
R-carjamatos
R-littlerellert
R-lmtest jamatos
R-memoisespot
R-msmdenisarnaud
R-multcomp   jamatos
R-rtracklayerspot
R-snow   spot
R-systemfit  jamatos
R-testthat   spot
R-waveslim   jamatos
R-zoojamatos

Packages by maintainer:
denisarnaud R-msm
ellert R-Rcpp R-littler
jamatosR-car R-lmtest R-multcomp R-systemfit R-waveslim R-zoo
spot   R-DBI R-DelayedArray R-GenomeInfoDb R-GenomicAlignments
R-R6 R-RSQLite R-Rsamtools R-S4Vectors R-SummarizedExperiment
R-XVector R-biomaRt R-blob R-memoise R-rtracklayer R-snow R-testthat

[1] https://fedoraproject.org/wiki/Changes/Automatic_R_runtime_dependencies
[2] https://pagure.io/packaging-committee/issue/914
[3] https://pagure.io/packaging-committee/issue/914#comment-608700
[4] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/R/#_automatically_generated_dependencies
-- 
Elliott
___
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: Use immutable CRAN URLs

[Elliott Sales de Andrade]

Hello,

On Thu, 1 Nov 2018 at 20:45, Jason L Tibbitts III  wrote:
>
> Since I actually had an existing pagure repo for random RPM macro
> experiments, I just dropped the R macro stuff there.
>
> https://pagure.io/misc-rpm-macros
> https://pagure.io/misc-rpm-macros/blob/master/f/macros.R-extra
>
> I still have some ideas to implement but feel free to test what's there.
> To use this, you just need to check out the repo and then add a symlink
> to macros.R-extra in /usr/lib/rpm/macros.d.
>
>  - J<

This is a rather old email thread that I'm resurrecting, but I'm
wondering what the state of those macros is now?

We now have a place in upstream rpm where we could store these macros:
https://github.com/rpm-software-management/R-rpm-macros
It is currently used for automated dependency generators only.

-- 
Elliott
___
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

R-testit license change: GPLv2+ to GPLv3

[Elliott Sales de Andrade]

Hello,

Upstream has changed the license metadata for testit from 'GPL' to
'GPL-3', resulting in the consequential change of the Fedora package
license from GPLv2+ to GPLv3.

-- 
Elliott
___
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: dist-git bugzilla sync script being fixed

[Elliott Sales de Andrade]

On Mon, 2 Dec 2019 at 08:22, Pierre-Yves Chibon  wrote:
>
> Good Morning Everyone™,
>
> we have recently spent some time refactoring, improving and fixing the script
> that syncs the default assignee and CC list from dist-git to Bugzilla.
>
> Since the script was broken for some time, we felt that it needs some 
> validation
> before we run it live (which will still require some work).
> We have uploaded the results at:
> https://pingou.fedorapeople.org/distgit_bugzilla_sync.log
> (Note that this only shows what would be updated.)
>
> We'd appreciate it if you could take some time and check the changes affecting
> you and report any issues you might find.
> An easy way to do this is downloading the file and grepping for your FAS
> username.

[EDITCOMP] Fedora/python-Fiona  initialowner changed  to FAS name(s) `orphan`
[EDITCOMP] Fedora/python-Fiona  initialcclist changed from
`['@python-sig', 'qulogic']` to FAS name(s) `['orphan']`

Need to double-check this, because python-Fiona is retired, and I'm
not an owner of, or CC'd on, it. But I *am* an owner of python-fiona,
which is not orphaned.

-- 
Elliott
___
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: List of long term FTBFS packages to be retired in February (beta)

[Elliott Sales de Andrade]

On Thu, 28 Nov 2019 at 08:05, Miro Hrončok  wrote:
> golang-gopkg-sourcemapeclipseo, go-sig, jchaloup   Fedora 28

This is obsoleted by golang-gopkg-sourcemap-1, has a dead.package, and
should be retired already.
___
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

"mock exited with status 110, see root.log for more information"; but it's a build failure

[Elliott Sales de Andrade]

Yesterday, I saw this error periodically in a few random arches, and
today I saw it more often (see examples at end of email). The
individual builds say something like:

> BuildError: error building package (arch x86_64), mock exited with status 
> 110; see root.log for more information

but root.log contains no error or even the status code 110. It turns
out if you look in build.log, the build was actually running and
failed (due to some silly errors on my part). In mock_output.log,
there is some output about mock state inconsistency:

> ERROR: 
> Exception(/var/tmp/koji/tasks/319/37850319/local/work/tasks/300/37850300/golang-tinygo-x-llvm-0-0.6.20190925git95bc4ff.fc32.src.rpm)
>  Config(f32-build-17588120-1269812) 0 minutes 25 seconds
> INFO: Results and/or logs in: /var/lib/mock/f32-build-17588120-1269812/result
> ERROR: state finish mismatch: current: rpmbuild 
> golang-tinygo-x-llvm-0-0.6.20190925git95bc4ff.fc32.src.rpm, state: build 
> phase for golang-tinygo-x-llvm-0-0.6.20190925git95bc4ff.fc32.src.rpm

Somehow mock is getting confused about what state it's in and koji is
stating the wrong place to look.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1389221
https://koji.fedoraproject.org/koji/buildinfo?buildID=1389222
https://koji.fedoraproject.org/koji/buildinfo?buildID=1389223
https://koji.fedoraproject.org/koji/buildinfo?buildID=1389225
https://koji.fedoraproject.org/koji/buildinfo?buildID=1389518

-- 
Elliott
___
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: "mock exited with status 110, see root.log for more information"; but it's a build failure

[Elliott Sales de Andrade]

On Wed, 25 Sep 2019 at 11:02, Miroslav Suchý  wrote:
>
> Dne 25. 09. 19 v 4:59 Elliott Sales de Andrade napsal(a):
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1389518
>
> I looked at this one and:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=37850317
> and build log:
> https://kojipkgs.fedoraproject.org//work/tasks/317/37850317/build.log
>
> exit code 10 according to:
> https://github.com/rpm-software-management/mock/wiki#exit-codes
> means "error during rpmbuild"

Yes, I know *why* it fails, this is about *how* it fails. Either koji
or mock are confused about what failed. Koji says to look in root.log;
this is wrong, there were no buildroot initialization errors. Mock
also exits with some kind of inconsistency (see original email.)

> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

-- 
Elliott
___
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

Policy for non-responsive reviewers

[Elliott Sales de Andrade]

Hello,

I've been waiting almost 2 months for my reviewer to respond on my
package request. I pinged and set needinfo some time ago, but still
nothing. My package is FTBFS and FTI in F31, and I've been stuck
because of this.

Looking at policies, I see one for non-responsive maintainerw [1], but
I don't think this really applies. There's a page about the package
review process [2] which mentions several items about non-responsive
*submitters*, but nothing about reviewers. There's also some mention
of legal blockers, but not how to ping for clarification there.
Neither the Join page [3] nor the review guidelines [4] mention
anything about timelines.

Now I know there's no _technical_ reason why I can't un-assign a bug,
but I'd rather discuss policy here.
* Who should be pinged, needinfo'd, or otherwise contacted, and after how long?
* If there's a legal question, who should be pinged and when?
* At what point does a packager give up and ask for another reviewer
(by setting back to NEW)?

[1] 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/
[2] https://fedoraproject.org/wiki/Package_Review_Process
[3] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
[4] https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/

-- 
Elliott
___
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: Orphaning 'antimony' package

[Elliott Sales de Andrade]

On Tue, 25 Feb 2020 at 12:55, Antonio Trande  wrote:
>
> Hi all.
>
> Antimony (https://src.fedoraproject.org/rpms/antimony) is an orphan
> package since today.

Actually, it's orphaned *and retired*. This is not insurmountable for
anyone who wishes to take over, but one does not necessarily imply the
other.

> Feel free to take it.
>
> --
> ---
> Antonio Trande

-- 
Elliott
___
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

Packages webapp status

[Elliott Sales de Andrade]

On Thu, 30 Jan 2020 at 08:03, Neal Gompa  wrote:
>
> On Thu, Jan 30, 2020 at 6:40 AM Iñaki Ucar  wrote:
> >
> > On Wed, 29 Jan 2020 at 23:23, Leigh Griffin  wrote:
> > >
> > > I suspect that a bulk of our users are similar to you. Given that you are 
> > > engaged on the thread (thank you!) what is your day to day needs? What 
> > > features are part of your usage and interaction? What's missing or what 
> > > would you like to see added? Your voice here can help represent that 
> > > group and is most welcome.
> >
> > I'd say that if you manage to accommodate the more complicated
> > workflows, the basic one is covered. Beyond that, I really like the
> > table that is displayed in src.fp.o for every package, because in a
> > single glance you can tell which one is the stable version and the
> > version in testing for every release. I really like the links to Koji,
> > Bodhi... integrated just above the table. And I really really like the
> > Fedora Packages app, but it seems to be dead.
> >
> > In summary, package maintainance has many pieces (dist-git, builders,
> > update system, bugzilla, QA, CI...), and a "control panel" like Fedora
> > Packages is very useful, I think.
> >
>
> The Packages app was being rewritten by Miroslav Suchy:
> https://github.com/xsuchy/fedora-packages-ng
>
> I don't know if it's ready yet to replace the existing one, though.
>

I don't know what the status of the replacement is, but when I go to
Packages, 50% of what I look for is missing and 50% is just wrong.
This is less than useless. Any prospective Fedora user won't even
bother installing it if they can't find out whether their favourite
application is available. We might as well just turn Packages off.

So if the rewrite can do basically anything, it's probably an
improvement. I'm sorry to be so harsh to the existing app, but it's
basically of negative benefit to Fedora right now.

-- 
Elliott
___
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: 13 packages still requiring Python 3.7 in Fedora 32

[Elliott Sales de Andrade]

On Wed., Feb. 5, 2020, 6:33 a.m. Miro Hrončok,  wrote:

> In Fedora 32, we have updated Python to 3.8:
>
> https://fedoraproject.org/wiki/Changes/Python3.8
>
> There are last 13 packages that were still not successfully rebuilt with
> Python
> 3.8 and they require Python 3.7 at run-time, causing broken dependencies.
> The
> packages are not installable. I don't think the bugzillas are moving
> anywhere.
>
>
> Technically, such noninstallable packages should be retired one week
> before the
> beta freeze. I'm writing this e-mail to raise awareness about the problem.
> Some
> of the packages are awaiting upstream fixes.
>
>
> mailman3
> https://bugzilla.redhat.com/show_bug.cgi?id=1715598
> mraa
> https://bugzilla.redhat.com/show_bug.cgi?id=1721671
> python-bz2file
> 
>https://bugzilla.redhat.com/show_bug.cgi?id=1728072
> python-cartopy
> 
>https://bugzilla.redhat.com/show_bug.cgi?id=1743898
> python-geoplot
> 
>https://bugzilla.redhat.com/show_bug.cgi?id=1773373
> python-jenkins-job-builder
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1706223
> python-libpysal
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1746849
> python-missingno
> 
>https://bugzilla.redhat.com/show_bug.cgi?id=1773375
> python-nineml
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1746850
> python-nose-parameterized
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1718347
> python-subunit2sql
> 
>https://bugzilla.redhat.com/show_bug.cgi?id=1746853
> python-xarray
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1773377
> upm
> https://bugzilla.redhat.com/show_bug.cgi?id=1736936
>
>
> Maintainers by package:
> mailman3 abompard
> mraa pbrobinson
> python-bz2file   orphan besser82
> python-cartopy   qulogic
> python-geoplot   qulogic
> python-jenkins-job-builder orphan ignatenkobrain ktdreyer pabelanger
> python-libpysal  qulogic
> python-missingno lbazan
> python-ninemlankursinha
> python-nose-parameterized echevemaster
> python-subunit2sql   chandankumar
> python-xarrayqulogic
> upm  pbrobinson
>
> Packages by maintainer:
> abompard   mailman3
> ankursinha python-nineml
> besser82   python-bz2file
> chandankumar python-subunit2sql
> echevemaster python-nose-parameterized
> ignatenkobrain python-jenkins-job-builder
> ktdreyer   python-jenkins-job-builder
> lbazan python-missingno
> pabelanger python-jenkins-job-builder
> pbrobinson mraa upm
> qulogicpython-cartopy python-geoplot python-libpysal python-xarray
>

I'm going to tag a beta for Cartopy today or tomorrow (depending on how
quick I can go through the issues), and import it into Fedora, so that
should unblock the other ones, I think.


> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
___
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: Packages for Fedora Jam

[Elliott Sales de Andrade]

Hi Erich,

On Tue, 18 Feb 2020 at 12:10, Erich Eickmeyer  wrote:
> I have filed bugzilla reports for each one and blocked FE-NEEDSPONSOR for each
> one. I'd like to get these sponsored as soon as possible.
>

To clarify, it is not the packages that need to be sponsored, it is *you*.
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Get_Sponsored

> I'd appreciate your help!
> Erich
> 
> Erich Eickmeyer
> Fedora Jam
> Ubuntu Studio
>

-- 
Elliott
___
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: Policy for non-responsive reviewers

[Elliott Sales de Andrade]

On Sun., Feb. 9, 2020, 11:15 a.m. Jerry James,  wrote:

> On Sun, Feb 9, 2020 at 4:21 AM Elliott Sales de Andrade
>  wrote:
> > Looking at policies, I see one for non-responsive maintainerw [1], but
> > I don't think this really applies. There's a page about the package
> > review process [2] which mentions several items about non-responsive
> > *submitters*, but nothing about reviewers. There's also some mention
> > of legal blockers, but not how to ping for clarification there.
> > Neither the Join page [3] nor the review guidelines [4] mention
> > anything about timelines.
>
> https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
>
> I don't know why that page is so hard to find.  I have to hunt around
> for awhile every time I want it.  Perhaps there should be a link to it
> from https://fedoraproject.org/wiki/Package_Review_Process ?
>

Ah, thank you. Yes it would definitely be best to link it from somewhere
else.

Should it also be moved to policy documents at
https://docs.fedoraproject.org/en-US/fesco/
(Is it a FESCo policy?)

-- 
> Jerry James
> http://www.jamezone.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
>
___
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: Self Introduction: Dan Shoemaker

[Elliott Sales de Andrade]

Hi Dan!

On Thu, 27 Feb 2020 at 02:55, Daniel Shoemaker  wrote:
>
> Hi, my name is Dan Shoemaker.
>  I have been using Fedora since Fedora Core 6 for both personal and 
> professional use.  About five years ago I started developing bash scripts in 
> order to start automating tasks I was doing while maintaining Linux servers 
> for various clients.

Welcome to Fedora!

>  Last year I started taking Todd McLeod's Udemy class Learning Go and I found 
> much to my delight that Fedora has a very active Go SIG.  As a result I would 
> love to become a package maintainer for the Go packages on Fedora.
>

I suggest looking over the general contributor guidelines:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
and when you are familiar with packaging, the Go guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/

And you can join the Go SIG for Go-related tasks: https://pagure.io/GoSIG/go-sig

> Dan

-- 
Elliott
___
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

Ignoring non-Fedora notifications?

[Elliott Sales de Andrade]

Hello,

Some time ago, I reset my Fedora notifications to the defaults
(previously it was just stuff from before I was a packager). As a
member of various SIGs, this means I get a lot of notifications for
packages that are not mine. I am fine with this generally.

However, I don't really care about EPEL notifications. With ELN going
into effect and automatically building things after Rawhide, that
might even mean doubled notifications for any of those builds.

Does anyone know what magic to put into the filter settings to ignore
non-Fedora notifications?

-- 
Elliott
___
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: [EPEL-devel] Soname bump of libb2 on F31/EPEL7

[Elliott Sales de Andrade]

On Sat, 16 May 2020 at 16:31, Felix Schwarz  wrote:
>
>
> Am 16.05.20 um 19:39 schrieb Antonio Trande:
> > `libb2-0.98.1` has been required on F31 [1] and EPEL7 [2]; it expects a
> > soname bump, so all dependent packages need to be rebuilt:
> >
> > $ repoquery --whatrequires libb2-devel --disablerepo=*
> > --enablerepo=*-source
> > R-argon2-0:0.2.0-8.fc32.src
> > borgbackup-0:1.1.11-1.fc32.src
> > gtkhash-0:1.2-2.fc32.src
>
> fine by me. Ideally we could push out all the updated packages in a single
> update to avoid inconsistencies.

Fine by me as well, and yes, single update is required for something like this.

>
> Felix

-- 
Elliott
___
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

License correction for python-glad: MIT -> MIT and ASL 2.0

[Elliott Sales de Andrade]

Hi,

Upstream has clarified their license as they embed some Knronos/EGL
specifications under a different license.

Thus, the package's license has changed from MIT to MIT and ASL 2.0.

-- 
Elliott
___
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

/etc/localtime is not a symlink on koji?

[Elliott Sales de Andrade]

Hi,
I'm debugging an issue in  a FTBFS, which appears caused by unexpected
warnings during a build [1]. These warnings come from R and complain
that /etc/localtime is not a symlink.

According to `man 5 localtime` [2], /etc/localtime cannot be a normal
file or hard link.
Is this something wrong in koji, or its builders?

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=50987042
[2] https://www.freedesktop.org/software/systemd/man/localtime.html
-- 
Elliott
___
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: /etc/localtime is not a symlink on koji?

[Elliott Sales de Andrade]

On Tue, 8 Sep 2020 at 04:52, Petr Pisar  wrote:
>
> On Tue, Sep 08, 2020 at 04:00:14AM -0400, Elliott Sales de Andrade wrote:
> > I'm debugging an issue in  a FTBFS, which appears caused by unexpected
> > warnings during a build [1]. These warnings come from R and complain
> > that /etc/localtime is not a symlink.
> >
> > According to `man 5 localtime` [2], /etc/localtime cannot be a normal
> > file or hard link.
> > Is this something wrong in koji, or its builders?
> >
> > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=50987042
> > [2] https://www.freedesktop.org/software/systemd/man/localtime.html
>
> I hit this issue many years ago and tzdata maintainer claimed
> <https://bugzilla.redhat.com/show_bug.cgi?id=1136219> that it was a fault
> of a mock tool. (Mock tool is used when building a package in Koji). I asked
> a maintainer of mock to fix it
> <https://bugzilla.redhat.com/show_bug.cgi?id=1136040> and he "fixed" it by not
> creating /etc/localtime at all. In the mean time I implemented a work around
> in one of mine affected packages and has not seen any issue like that. (Except
> of a user who complained that the Fedora package survives longer before
> reporting an error than an upstream's code.)
>
> What's your issue now? Is /etc/localtime a normal file again, or is the error
> message wrong and the file is missing completely?

I debugged it a little with ls -l/cat /etc/localtime, and it
definitely exists, but is a regular file. Confusingly, this only
causes a problem on koji, not in local mock, even though manually
running similar code as the test appears to trigger the same warning
as on koji.

Looking at the R source code for Sys.timezone(), I've found that it
checks the TZ envvar before timedatectl & /etc/localtime, so setting
TZ works around the problem for me (and also silences timedatectl's
warnings.)

Since I have a workaround now and it doesn't reproduce on local mock,
I won't bother spamming koji with debug attempts.

>
> -- Petr

-- 
Elliott
___
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

libxls SONAME change

[Elliott Sales de Andrade]

Hi,

The latest libxls 1.6.0 changes ABI, but accidentally did not update
SONAME. I have not yet updated, but will do so once upstream fixes the
SONAME, which I hope will happen within a week's time for this
notice's purposes.

As far as I am aware, the only package dependencies are R-readxl,
which I maintain already and will rebuild as part of the update.

-- 
Elliott
___
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: F32 ppc64le build failure: ImportError: /lib64/libgomp.so.1: cannot allocate memory in static TLS block

[Elliott Sales de Andrade]

On Fri, 4 Sep 2020 at 18:03, Ankur Sinha  wrote:
>
> Hello folks,
>
> I'm seeing this error that causes a test failure on F32 for a noarch
> python package. It builds in mock on my x86_64 here, but on koji it gets
> a ppc64le builder and fails with this error. It's built fine on F33 and
> rawhide. Would anyone know what may be causing this?
>

I'm pretty sure this is this wx+NumPy+Pillow bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=1738752

which as you say is fixed on Fedora 33.

> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) | 
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London

-- 
Elliott
___
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: [golang packaging] how to get files from source tarball

[Elliott Sales de Andrade]

Hi Zdenek,

On Mon, 31 Aug 2020 at 12:11, Zdenek Dohnal  wrote:
>
> Hi,
>
> I'm trying to package ipp-usb project
> (https://github.com/OpenPrinting/ipp-usb) which is written in Go. I
> generated spec file via go2rpm, but several files from source tarball
> which supposed to be packaged is not packaged e.g. systemd unit file
> ipp-usb.service or udev rule file 71-ipp-usb.rules.
>
> I managed to package those files with following install command e.g.:
>
> install -m 0644 -vp
> %{gobuilddir}/src/github.com/OpenPrinting/ipp-usb/systemd-udev/*.rules
> %{buildroot}%{_udevrulesdir}
>
> but '%{gobuilddir}/src/github.com/OpenPrinting/ipp-usb' is quite ugly -
> is there a predefined golang macro for such path? Or a best practice?
>

Well, you should have %{goname} defined at the top that matches at
least part of that.
But you shouldn't need it, as that should be the current directory, so just

install -m 0644 -vp systemd-udev/*.rules %{buildroot}%{_udevrulesdir}

should work.

> Thank you in advance,
>
> Zdenek
>
> --
> Zdenek Dohnal
> Software Engineer
> Red Hat Czech - Brno TPB-C
>
>
> ___
> 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



-- 
Elliott
___
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

License correction: python-cligj MIT -> BSD

[Elliott Sales de Andrade]

The license tag on python-cligj appears to have always been wrongly
tagged as MIT. I have now corrected it to BSD in Rawhide while
updating to its latest beta, and will let this trickle down to other
releases once the new release is out.

-- 
Elliott
___
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

R-ps license change: BSD -> MIT

[Elliott Sales de Andrade]

The R-ps 1.4.0 package has changed license from the previous BSD to MIT.

New builds will be made shortly.

-- 
Elliott
___
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

ocrmypdf license change

[Elliott Sales de Andrade]

Version 11 of ocrmypdf changes license from "LGPLv2 and CC-BY-SA and
Public Domain" to "MPL2.0 and MIT and BSD and CC-BY-SA and Public
Domain"

The main code switched licenses (to MPL2.0), and I found a few files
imported from elsewhere that had a different license (MIT/BSD).

It will be built for F33+ only.

-- 
Elliott
___
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

LTO is broken in Rawhide/33 containers

[Elliott Sales de Andrade]

When using Fedora's containers, LTO appears to be broken. I'm not sure
who to report this to, the container builder or gcc.

$ podman run --pull=always --rm -it registry.fedoraproject.org/fedora:rawhide
# dnf install -y gcc
# echo 'int main(void) { int class=0; return class; }' > sanitycheck.c
# gcc -flto=auto sanitycheck.c -o sanitycheck
lto-wrapper: fatal error: execvp: No such file or directory
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

The test file is what Meson compiles as a check. This also fails on
fedora:33. For good measure, you can throw in a `dnf update -y`, but
it does not update/fix anything.

Running a similar check in `mock -r fedora-rawhide-x86_64` --shell works fine.

-- 
Elliott
___
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: Fedora 32/33 livedisks do not boot on M$ system(s)

[Elliott Sales de Andrade]

On Wed, 30 Sep 2020 at 17:42, Marius Schwarz  wrote:
>
> Am 30.09.20 um 23:00 schrieb Chris Murphy:
> >
> >
> > And then these are current
> > grub2-efi-x64-2.04-31.fc33.x86_64
> > grub2-efi-x64-2.04-23.fc32.x86_64
> > grub2-efi-x64-2.02-110.fc31.x86_64
> >
> > I wonder if the affected hardware is adversely affected by all three
> > of these versions of GRUB?
> >
>
> I made some more tests. It's a race, 1 out of 10 tries succeeds and the
> chance that it does is improoved by inserting the usb drive while being
> in the bios.
>
> The F31 grub files i exchanged do not seem to have something to do with it.
>
> Could it be a timing issue of some kind?
>
> the sooner i hit the boot from usb button, after the stick got inserted,
> the higher is the propability to start.
>

Are you saying you insert the USB stick _after_ turning on the
machine? Otherwise I don't understand the correlation between the
insertion and pressing a boot from USB button.

> I think we can rule out signing here as the surface is in none secure
> boot mode and it starts ( screenshot available).
>
> So what else could cause this?
>
> best regards,
> Marius
>
___
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: Fedora 32/33 livedisks do not boot on M$ system(s)

[Elliott Sales de Andrade]

On Wed, 30 Sep 2020 at 18:27, Marius Schwarz  wrote:
>
> Am 01.10.20 um 00:19 schrieb Elliott Sales de Andrade:
>
> Could it be a timing issue of some kind?
>
> the sooner i hit the boot from usb button, after the stick got inserted,
> the higher is the propability to start.
>
> Are you saying you insert the USB stick _after_ turning on the
> machine? Otherwise I don't understand the correlation between the
> insertion and pressing a boot from USB button.
>
>
> The working/non-working procedure is:
>
> Power on
> ...
> inserting the stick

OK, but why insert the USB stick after power on?
Wouldn't it be less trouble to insert beforehand so that the firmware
will always see it?

> Marius

-- 
Elliott
___
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: Package downgrades from fedora 32 -> fedora 33 (updated + annotated list inside)

[Elliott Sales de Andrade]

On Fri, 2 Oct 2020 at 18:53, Fabio Valentini  wrote:
>
> - golang-github-willf-bitset-devel is newer in 32 than in 33:
>   0:1.1.11-1.fc32 > 0:1.1.10-5.fc33
>
> Updated builds for f33 seem to have been missed by the maintainer, f34 and f32
> have version 1.1.11, but f33 doesn't.
>

Well, I have a local updated f33 branch, but I guess it never got
pushed. It's fixed now.
___
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: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7

[Elliott Sales de Andrade]

On Thu, 28 May 2020 at 02:26, Petr Pisar  wrote:
>
> On Wed, May 27, 2020 at 05:22:04PM -0400, Mukundan Ragavan wrote:
> > Scratch build of gtkhash does not appear to pull in libb2-0.98.1. Has
> > the buildroot override expired?
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=45077601
> >
> It did not expire:
>
> $ bodhi overrides query --builds libb2-0.98.1-2.fc31
> 
>  libb2-0.98.1-2.fc31
> 
>   Submitter: fschwarz
>   Expiration Date: 2020-05-29 00:00:00
>   Notes: updating borgbackup due to libb2 update
>   Expired: False
>
>
> Use the following to ensure the override is active:
>
> $ koji wait-repo f31-build --build=libb2-0.98.1-2.fc31
>
> 1 overrides found (1 shown)
>
> So what libb2 build is in the build root?
>
> $ koji wait-repo f31-build --build=libb2-0.98.1-2.fc31
> Warning: nvr libb2-0.98.1-2.fc31 is not current in tag f31-build
>   latest build in f31-build is libb2-0.98-4.20171225git60ea749.fc31
> ^C
>
>
> How is it possible? What happened with the libb2-0.98.1-2.fc31 build:
>
> $ koji list-history --build libb2-0.98.1-2.fc31
> Fri May 22 20:48:12 2020 libb2-0.98.1-2.fc31 tagged into 
> f31-updates-candidate by sagitter
> Fri May 22 20:54:19 2020 libb2-0.98.1-2.fc31 tagged into f31-signing-pending 
> by bodhi
> Fri May 22 20:54:36 2020 libb2-0.98.1-2.fc31 untagged from 
> f31-signing-pending by autopen
> Fri May 22 20:54:36 2020 libb2-0.98.1-2.fc31 tagged into 
> f31-updates-testing-pending by autopen
> Fri May 22 23:00:35 2020 libb2-0.98.1-2.fc31 tagged into f31-override by bodhi
> Sat May 23 04:51:56 2020 libb2-0.98.1-2.fc31 untagged from 
> f31-updates-candidate by bodhi
> Sat May 23 04:51:56 2020 libb2-0.98.1-2.fc31 tagged into f31-updates-testing 
> by bodhi
> Sat May 23 04:52:04 2020 libb2-0.98.1-2.fc31 untagged from 
> f31-updates-testing-pending by bodhi
> Tue May 26 15:15:47 2020 libb2-0.98.1-2.fc31 untagged from 
> f31-updates-testing by bodhi
> Tue May 26 15:15:47 2020 libb2-0.98.1-2.fc31 untagged from f31-override by 
> bodhi
> Tue May 26 15:15:48 2020 libb2-0.98.1-2.fc31 tagged into 
> f31-updates-candidate by bodhi [still active]

That would be the time that the update [1] was unpushed.

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2020-628ff99cfc

>
> It was untagged from override by bodhi user on 2020-05-26. That's 3 days 
> before the
> expiration. It looks like a bug in Bodhi service.
>
> You can try to submit it into override again.
>
> -- Petr

-- 
Elliott
___
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: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7

[Elliott Sales de Andrade]

I made builds for R-argon2 last night as well, which you can include
in your update.

- R-argon2-0.2.0-7.fc31

Actually, there's no need for a _new_ update; you can just edit the
existing one.

On Mon, 25 May 2020 at 08:41, Felix Schwarz  wrote:
>
>
> builds for borgbackup done (finally):
> - borgbackup-1.1.11-3.el7
> - borgbackup-1.1.11-5.fc31
>
> Please add these once you submit the final update.
>
> Felix
>

-- 
Elliott
___
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

libcroco retired on Rawhide, breaking builds

[Elliott Sales de Andrade]

libcroco was retired on Rawhide, but the libcroco-0.6.so.3()(64bit) it
provides is used by libtextstyle.so.0, part of gettext.

gettext is used by many many things. Please unretire libcroco, or
rebuild gettext without it.

-- 
Elliott
___
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

Test machines for s390x?

[Elliott Sales de Andrade]

Hi,

Now that ppc64 is gone, s390x is the only big-endian architecture
left. Bugs around endianness are not usually difficult to fix, _if_ I
can debug it and see where exactly the problem is. However, this
requires a tedious guess-a-patch, try a scratch build, check the
result, rinse and repeat.

Mock (with --forcearch) is completely useless for this. The programs
just crash during the build in such a way that I can't even use
`catchsegv`, and gdb is unusable in the container. And besides, the
programs don't actually crash on real s390x anyway..

Just like we have test machines for other less used architectures [1],
I am wondering if there is some way we can spin up a test machine for
s390x?

[1] 
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

-- 
Elliott
___
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

ghc-cryptonite LTO failure on s390x

[Elliott Sales de Andrade]

Hi,

The build for ghc-cryptonite failed in the mass rebuild [1] and a
later rebuild by me [2], but only on s390x. The failure appears to be
LTO related. This doesn't appear to affect many other Haskell
packages. (I've found one seemingly-related failure in
ghc-haskell-src-exts [3].) Since it's Haskell, I'm using the standard
macros that should pass consistent flags, etc., so I'm not sure what
more information I can provide.

What happens is that ld.gold warns about mixed LTO/non-LTO:

[  1 of 131] Compiling Crypto.Cipher.DES.Primitive (
Crypto/Cipher/DES/Primitive.hs,
dist/build/Crypto/Cipher/DES/Primitive.p_o )
/usr/bin/ld.gold: warning: incremental linking of LTO and non-LTO
objects; using -flinker-output=nolto-rel which will bypass whole
program optimization

and then errors out because of many LTO mismatches like:

/tmp/ghc794663_0/ghc_19.c:11:19: error:
 warning: type of
‘cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc’
does not match original declaration [-Wlto-type-mismatch]
   11 | extern CostCentre
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[];
  |   ^
   |
11 | extern CostCentre
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[];
   |   ^
/tmp/ghc794663_0/ghc_18.hc:44:9: error:
 note: type ‘StgWord’ should match type ‘struct CostCentre’
   44 | StgWord
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))=
{
  | ^
   |
44 | StgWord 
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))=
{
   | ^
/tmp/ghc794663_0/ghc_18.hc:44:9: error:
 note: 
‘cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc’
was previously declared here
   |
44 | StgWord 
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))=
{
   | ^
/tmp/ghc794663_0/ghc_18.hc:44:9: error:
 note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used
   |
44 | StgWord 
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))=
{
   | ^

followed by inlining failures:

/usr/include/bits/string_fortified.h: In function ‘fill_segment’:
/usr/include/bits/string_fortified.h:59:1: error:
 error: inlining failed in call to ‘always_inline’ ‘memset’:
function body can be overwritten at link time
   59 | __NTH (memset (void *__dest, int __ch, size_t __len))
  | ^
   |
59 | __NTH (memset (void *__dest, int __ch, size_t __len))
   | ^


[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=47957210
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=48408236
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=48322376

-- 
Elliott
___
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: libcroco retired on Rawhide, breaking builds

[Elliott Sales de Andrade]

On Sat, 1 Aug 2020 at 14:42, Kevin Fenzi  wrote:
>
> On Sat, Aug 01, 2020 at 06:35:30PM +0100, Richard W.M. Jones wrote:
> > On Sat, Aug 01, 2020 at 03:13:50PM +0200, Fabio Valentini wrote:
> > > On Sat, Aug 1, 2020 at 2:44 PM Richard W.M. Jones  
> > > wrote:
> > > >
> > > > On Sat, Aug 01, 2020 at 03:25:48AM -0400, Elliott Sales de Andrade 
> > > > wrote:
> > > > > libcroco was retired on Rawhide, but the libcroco-0.6.so.3()(64bit) it
> > > > > provides is used by libtextstyle.so.0, part of gettext.
> > > > >
> > > > > gettext is used by many many things. Please unretire libcroco, or
> > > > > rebuild gettext without it.
> > > >
> > > > Yes, can confirm this breaks the whole virt stack, again.  Any
> > > > "Second build" that needs libvirt has been broken by this.
> > > >
> > > > I really think we should redo this whole mass rebuild from the start.
> > > >
> > > > Rich.
> > >
> > > Well, gettext-0.20.2-4.fc33 without the libcroco dependency has now
> > > been successfully built for f33-rebuild:
> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1574351
> > >
> > > It looks like f33-rebuild doesn't use its own packages for the
> > > buildroot though, so anything using gettext is broken in both f33 and
> > > f33-rebuild :(
> > > Can we get gettext-0.20.2-4.fc33 tagged into the f33? I'd do it
> > > myself, if I was sure not to break anything ... would "koji tag
> > > f33-updates-candidate gettext-0.20.2-4.fc33" be enough?
>
> Yeah, I tagged it in a bit ago, sorry for not updating the list.
>

Thanks. Out of my 84 FTBFS, 75% were due to this breakage. I've
already re-submitted them and they've passed, but I suspect a
reasonable number of the failures in the second pass might be related
to this.

Only 2 were related to the cmake change.

> > I don't know if this was done already, but libvirt is now installable
> > and I was able to build virt-v2v, so it seems I'm now able to build
> > the remaining virt packages.
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=48382603
> >
> > https://kojipkgs.fedoraproject.org//work/tasks/2636/48382636/root.log
> >  => gettext 0.20.2-4.fc33
> > libvirt 6.5.0-1.fc33
>
> We are just checking to make sure all the f33-rebuild packages are
> signed, and then will be merging the tag.
>
> Waiting on 2020-08-01 17:12:08,374 INFO: Calling koji to write 228467 rpms
>
> Fingers crossed.
>
> kevin

-- 
Elliott
___
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: Orphaning my golang packages

[Elliott Sales de Andrade]

On Tue, 7 Jul 2020 at 13:05, Fabio Valentini  wrote:
>
> Hi everybody,
>
> I have to finally admit that I'll never again be able to play catch-up
> with the ever-changing sprawling go library dependency tree of
> syncthing.
>
> I have switched to using bundled dependencies for syncthing ~years ago
> already, and I do not have the time nor the energy to do the amount of
> work that would be necessary to un-bundle everything again. The
> following packages are now orphaned:
>
> - golang-github-calmh-du
> - golang-github-calmh-xdr
> - golang-github-chmduquesne-rollinghash
> - golang-github-d4l3k-messagediff

> - golang-github-gobwas-glob

This one is used by hugo, and you're already admin, so you probably
want to become primary maintainer, Athos.

> - golang-github-jackpal-gateway
> - golang-github-minio-sha256-simd
> - golang-github-petermattis-goid
> - golang-github-syncthing-notify
> - golang-github-thejerf-suture
> - golang-github-vitrun-qart

> - golang-gopkg-asn1-ber-1
> - golang-gopkg-ldap-2

These two are used by golang-vitess, Robert-André.


>
> I think most of them have never been used for anything but building
> syncthing, so they have been useless baggage for me for years. Some
> are also used by other packages, and I hope that those few can find a
> new home.
>
> The packages should comply with the latest Packaging Guidelines for
> Go, should be up-to-date, and are all building successfully, with
> passing test suites.
>
> Thanks.
> Fabio

--
Elliott
___
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: Searching a new home for my packages

[Elliott Sales de Andrade]

On Fri, 12 Jun 2020 at 17:39, Miro Hrončok  wrote:
>
> On 12. 06. 20 21:37, Thomas Spura wrote:
> > Hi all,
> >
> > unfortunately, I don't find much time anymore to look for my packages ..
> > Due to that, I would like to step down as the primary maintainer and
> > am searching for a new home for my packages!
> > On most of them, I am co-maintainer and the following are the ones, where I 
> > am
> > maintainer (and hope I didn't forget one, if so, please let me know):
>
> > - python-jupyter-client
> > - python-jupyter-core
>
> I can take the above two, I've been co-maintaining them for some time. FAS
> churchyard.
>
> > - python-matplotlib
>
> I think qulogic would be the de facto maintainer here.
>

Yep, I'll take it.

> > - ipython
>
> Please assign this package to lbalhar who effectively maintains it.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok

-- 
Elliott
___
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: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Elliott Sales de Andrade]

On Mon, 23 Nov 2020 at 04:32, Miro Hrončok  wrote:
> golang-github-casbin  go-sig, orphan   0 weeks ago

I took this one before realizing it was v1, not v2, so I've orphaned it again.

> golang-github-cenkalti-backoffgo-sig, jchaloup, orphan 0 weeks ago
> golang-github-cespare-xxhash  go-sig, orphan   0 weeks ago

These two are needed by restic (maintainers cc'd). I can take xxhash
if you don't want it, but not so keen on backoff.

> gplugin   orphan   0 weeks ago

Taken

-- 
Elliott
___
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: Packaging chunkfs - no debug output

[Elliott Sales de Andrade]

On Wed, 2 Dec 2020 at 17:45, Richard Shaw  wrote:
>
> On Wed, Dec 2, 2020 at 2:34 PM Elliott Sales de Andrade 
>  wrote:
>>
>>
>>
>> On Wed., Dec. 2, 2020, 11:08 a.m. Richard Shaw,  wrote:
>>>
>>> I'm working on packaging chunkfs for fun and curiosity. It should make 
>>> backing up VMs or other large files with traditional backup compression and 
>>> deduplication methods (i.e. BackupPC) easier by breaking up the file into 
>>> chunks.
>>>
>>> It has a manual Makefile which I've patched to comply with the packaging 
>>> guidelines, but I've run into an issue.
>>>
>>> The build respects the required build flags:
>>>
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o utils.o utils.c
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o unchunkfs.o unchunkfs.c
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o chunkfs.o chunkfs.c
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -s -lfuse  unchunkfs.o utils.o   -o unchunkfs
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -s -lfuse  chunkfs.o utils.o   -o chunkfs
>>
>>
>>
>> This appears to be applying CFLAGS, but not LDFLAGS.
>
>
> I tried adding LDFLAGS="%{build_ldflags}" but then I get:
>
> cc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
> -fcf-protection --Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -s -lfuse  chunkfs.o utils.o   
> -o chunkfs
> make: *** Waiting for unfinished jobs
> cc: error: unrecognized command-line option '--Wl,-z,relro'
>

Either your substitution or the makefile has a typo. The flag is
-Wl,-z,relro, single dash, just like the other ones.

Why not use %set_build_flags instead of manually setting *FLAGS?

> Thanks,
> Richard
>

--
Elliott
___
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: CPE Weekly: 2020-11-22

[Elliott Sales de Andrade]

On Mon, 23 Nov 2020 at 05:54, Aoife Moloney  wrote:
>
> ### OSBS for aarch64
> * Basic OKD 3.11 working on aarm64 with F31

What is OSBS? Please don't use undefined acronyms.

> * Working on repeating that install with F33
> * Next step will be to

This sentence is incomplete.

-- 
Elliott
___
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: Packaging chunkfs - no debug output

[Elliott Sales de Andrade]

On Wed., Dec. 2, 2020, 11:08 a.m. Richard Shaw, 
wrote:

> I'm working on packaging chunkfs for fun and curiosity. It should make
> backing up VMs or other large files with traditional backup compression and
> deduplication methods (i.e. BackupPC) easier by breaking up the file into
> chunks.
>
> It has a manual Makefile which I've patched to comply with the
> packaging guidelines, but I've run into an issue.
>
> The build respects the required build flags:
>
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o utils.o utils.c
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o unchunkfs.o unchunkfs.c
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o chunkfs.o chunkfs.c
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -s -lfuse  unchunkfs.o utils.o   -o unchunkfs
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -s -lfuse  chunkfs.o utils.o   -o chunkfs
>


This appears to be applying CFLAGS, but not LDFLAGS.


> And debuginfo runs:
>
>  /usr/lib/rpm/find-debuginfo.sh -j12 --strict-build-id -m -i
> --build-id-seed 0.8-1.fc33 --unique-debug-suffix -0.8-1.fc33.x86_64
> --unique-debug-src-base chunkfs-0.8-1.fc33.x86_64 --run-dwz
> --dwz-low-mem-die-limit 1000 --dwz-max-die-limit 11000 -S
> debugsourcefiles.list /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8
>
> But all the results are empty files:
>
> $ ll /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/*debug*
> -rw-r--r--. 1 build build 0 Dec  2 09:11
> /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debugfiles.list
> -rw-r--r--. 1 build build 0 Dec  2 09:11
> /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debuglinks.list
> -rw-r--r--. 1 build build 0 Dec  2 09:11
> /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debugsourcefiles.list
> -rw-r--r--. 1 build build 0 Dec  2 09:11
> /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debugsources.list
>
> What gives? Have it just missed something super simple?
>
> Thanks,
> Richard
>
___
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: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

[Elliott Sales de Andrade]

On Mon, 16 Nov 2020 at 03:06, Miroslav Suchý  wrote:
>
> Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a):
> > If you're going to have this kind of "upstream" spec file...well, I
> > wish you wouldn't. But if you do, *AT MINIMUM*, the "downstream" spec
> > files need to have a clear explanation that there is an "upstream" spec
> > file, with a justification as to why, and a link to it. At the very
> > top. Otherwise there is no chance any other Fedora packager is going to
> > find it.
>
> This is actually a good idea. I have lots of such spec files.
>
> Is it a good idea to document this in Packaging Guidelines?

It is already in the guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity

> Something like:
>
>   If upstream provides SPEC files and your SPEC is a copy you should put on 
> top of SPEC
>   file:
>   # This SPEC file is a copy from upstream http://www.upstream.org/foo.spec
>
___
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: video meeting to discuss Matrix/Element and IRC

[Elliott Sales de Andrade]

On Thu, 19 Nov 2020 at 14:44, Tom Hughes via devel
 wrote:
>
> On 19/11/2020 19:25, Adam Williamson wrote:
>
> > I mean, I'm an old fogey too, but at *some* point we do have to accept
> > that new things can be actively better.
>
> True.
>
> > I honestly can see exactly zero downsides to using a Matrix setup as
> > compared to using IRC, and a giant pile of upsides, starting with "I no
> > longer need to dedicate a small portion of my brain to remembering how
> > my IRC bouncer setup works and maintaining it".
>
> Well my experience when I looked at matrix desktop clients
> before was that they needed more screen real estate to be
> usable than IRC clients, which is certainly one downside and
> probably a direct consequence of rich media support.
>
> There's also the fact that unless I can get it to talk to all
> the same chat systems I have pidgin talking to I would need to
> be running two clients instead of one.
>

I don't know if it's packaged and can't speak to its quality, but
there exists a protocol plugin to use Matrix in Pidgin:
https://github.com/matrix-org/purple-matrix/#readme

> I am interested though, and did actually explore the idea of
> running my own home server and what I could bridge it to (so
> not that different to running my own bouncer now...) recently.
>
> Anyway I just looked at the three clients that were suggested
> earlier - all three are using Qt which makes them virtually
> unusable on a wayland/gnome desktop as far as I can see as the
> resize handles are so small they're impossible to use.
>
> More amusingly one of them crashed as soon as I logged in and
> a second went into a "your window is too small mode" as soon
> as I resized it to match my IRC client.
>
> The third was better, but rendered the conversation in that
> left/right style of SMS clients, which is horrible for a chat
> room.
>
> No doubt there are others I can try...
>
> Tom
>

-- 
Elliott
___
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

License change: R-vctrs GPLv3 -> MIT

[Elliott Sales de Andrade]

See title. I will only be updating in F33+.

-- 
Elliott
___
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

R-rprojroot license change: GPLv3 -> MIT

[Elliott Sales de Andrade]

As in title, rprojroot re-licensed from GPLv3 to MIT.

-- 
Elliott
___
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

R-here license change: GPLv3 -> MIT

[Elliott Sales de Andrade]

As in title, here re-licensed from GPLv3 to MIT.

There are also some new dependencies, so likely won't be building this
in Rawhide for a little bit until they are reviewed.

-- 
Elliott
___
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: Problem with F32 koji build root?

[Elliott Sales de Andrade]

On Wed, 28 Oct 2020 at 19:07, Steven A. Falco  wrote:
>
> I'm getting a build failure [1] in F32 that I'm not seeing in other targets 
> (F31, F33, rawhide are all good).
>
> The error is in the tex packages:
>
> ERROR: 
> Exception(/var/tmp/koji/tasks/2028/54442028/local/work/tasks/1779/54441779/kicad-5.1.8-1.fc32.src.rpm)
>  Config(f32-build-23694835-2326598) 0 minutes 58 seconds
> INFO: Results and/or logs in: /var/lib/mock/f32-build-23694835-2326598/result
> ERROR: Command failed:
>   # /usr/bin/dnf builddep --installroot 
> /var/lib/mock/f32-build-23694835-2326598/root/ --setopt=install_weak_deps=0 
> --disableplugin=local --disableplugin=spacewalk 
> /var/lib/mock/f32-build-23694835-2326598/root//builddir/build/SRPMS/kicad-5.1.8-1.fc32.src.rpm
>  --setopt=tsflags=nocontexts
> No matches found for the following disable plugin patterns: local, spacewalk
> Last metadata expiration check: 0:00:01 ago on Wed Oct 28 22:59:10 2020.
> Error:
>   Problem: package texlive-kpathsea-7:20200327-16.fc32.x86_64 requires 
> texlive-texlive-scripts = 7:20200327-16.fc32, but none of the providers can 
> be installed
>- package texlive-texlive-scripts-7:20200327-16.fc32.noarch requires 
> /usr/bin/texlua, but none of the providers can be installed
>- package po4a-0.60-1.fc32.noarch requires texlive-kpathsea-bin, but none 
> of the providers can be installed
>- package po4a-0.60-1.fc32.noarch requires texlive-kpathsea, but none of 
> the providers can be installed
>- package texlive-luatex-7:20200327-16.fc32.x86_64 requires texlive-cm, 
> but none of the providers can be installed
>- conflicting requests
>- nothing provides tex-tetex needed by texlive-cm-9:svn49028-21.fc32.noarch
>- nothing provides texlive-tetex-bin needed by 
> texlive-cm-9:svn49028-21.fc32.noarch
> (try to add '--skip-broken' to skip uninstallable packages)
>
> I'll wait a bit before resubmitting the job, but I'd appreciate suggestions 
> if there is something I can do to work around it.
>

It's not just you:
$ mock -r fedora-32-x86_64 --enablerepo=local --install texlive-tetex-bin
...
 Error: Transaction test error:
  file /etc/texlive/web2c/updmap.cfg conflicts between attempted
installs of texlive-texlive-scripts-7:20200327-16.fc32.noarch and
texlive-tetex-7:20190410-12.fc32.noarch
  file /usr/share/man/man1/fmtutil.1.gz conflicts between attempted
installs of texlive-texlive-scripts-7:20200327-16.fc32.noarch and
texlive-tetex-7:20190410-12.fc32.noarch
  file /usr/share/man/man1/updmap.1.gz conflicts between attempted
installs of texlive-texlive-scripts-7:20200327-16.fc32.noarch and
texlive-tetex-7:20190410-12.fc32.noarch
  file /usr/share/texlive/texmf-dist/scripts/texlive/fmtutil-user.sh
conflicts between attempted installs of
texlive-texlive-scripts-7:20200327-16.fc32.noarch and
texlive-tetex-7:20190410-12.fc32.noarch
  file /usr/share/texlive/texmf-dist/scripts/texlive/fmtutil.pl
conflicts between attempted installs of
texlive-texlive-scripts-7:20200327-16.fc32.noarch and
texlive-tetex-7:20190410-12.fc32.noarch
  file /usr/share/texlive/texmf-dist/scripts/texlive/updmap-user.sh
conflicts between attempted installs of
texlive-texlive-scripts-7:20200327-16.fc32.noarch and
texlive-tetex-7:20190410-12.fc32.noarch
  file /usr/share/texlive/texmf-dist/scripts/texlive/updmap.pl
conflicts between attempted installs of
texlive-texlive-scripts-7:20200327-16.fc32.noarch and
texlive-tetex-7:20190410-12.fc32.noarch

I think this is due to this buildroot override (maintainer cc'd):
https://bodhi.fedoraproject.org/overrides/texlive-base-20200327-16.fc32
Something lower-level like this should probably use a side tag.

> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=54441778
>
> Steve
___
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

R-generics license change: GPLv2 -> MIT

[Elliott Sales de Andrade]

As in subject. I expect little trouble as it's more permissive.

-- 
Elliott
___
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: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)

[Elliott Sales de Andrade]

On Wed, 30 Dec 2020 at 14:53, Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression
>
> == Summary ==
>
> On variants using btrfs as the default filesystem, enable transparent
> compression using zstd. Compression saves space and can significantly
> increase the lifespan of flash-based media by reducing write
> amplification. It can also increase read and write performance.
>
> == Owners ==
>
> * Name: [[User:salimma|Michel Salim]], [[User:dcavalca|Davide
> Cavalca]], [[User:josef|Josef Bacik]]
> * Email: mic...@michel-slm.name, dcava...@fb.com, jo...@toxicpanda.com
>
>
> == Detailed description ==
>
> Transparent compression is a btrfs feature that allows a btrfs
> filesystem to apply compression on a per-file basis. Of the three
> supported algorithms, zstd is the one with the best compression speed
> and ratio. Enabling compression saves space, but it also reduces write
> amplification, which is important for SSDs. Depending on the workload
> and the hardware, compression can also result in an increase in read
> and write performance.
>
> See https://pagure.io/fedora-btrfs/project/issue/5 for details. This
> was originally scoped as an optimization for
> https://fedoraproject.org/wiki/Changes/BtrfsByDefault during Fedora
> 33.
>
>
> == Benefit to Fedora ==
>
> Better disk space usage, reduction of write amplification, which in
> turn helps increase lifespan and performance on SSDs and other
> flash-based media. It can also increase read and write performance.
>
> == Scope ==
>
> * Proposal owners:
> ** Update anaconda to perform the installation using mount -o
> compress=zstd:1
> ** Set the proper option in fstab (alternatively: set the XATTR)
> ** Update disk image build tools to enable compression:
> *** lorax
> *** appliance-tools
> *** osbuild
> *** imagefactory
> ** [optional] Add support for
> [https://github.com/kdave/btrfs-progs/issues/328 setting compression
> level when defragmenting]
> ** [optional] Add support for
> [https://github.com/kdave/btrfs-progs/issues/329 setting compression
> level using `btrfs property`]
> * Other developers:
> ** anaconda: review PRs as needed
> * Release engineering: https://pagure.io/releng/issue/9920
> * Policies and guidelines: N/A
> * Trademark approval: N/A
>
> == Upgrade/compatibility impact ==
>
> This Change only applies to newly installed systems. Existing systems
> on upgrade will be unaffected, but can be converted manually with
> btrfs filesystem defrag -czstd -r, updating `/etc/fstab`
> and remounting.
>
> == How to test ==
>
> Existing systems can be converted to use compression manually with
> btrfs filesystem defrag -czstd -r, updating `/etc/fstab`

Update `/etc/fstab` how? Please be more explicit.

> and remounting.
>
> == User experience ==
>
> Compression will result in file sizes (e.g. as reported by du) not
> matching the actual space occupied on disk. The
> [https://src.fedoraproject.org/rpms/compsize compsize] utility can be
> used to examine the compression type, effective compression ration and
> actual size.
>
> == Dependencies ==
>
> Anaconda will need to be updated to perform the installation using
> mount -o compress=zstd:1
>
> == Contingency plan ==
>
> * Contingency mechanism: will not include PR patches if not merged
> upstream and will not enable
> * Contingency deadline: Final freeze
> * Blocks release? No
> * Blocks product? No
>
> == Documentation ==
>
> https://btrfs.wiki.kernel.org/index.php/Compression
>
> == Release Notes ==
>
> Transparent compression of the filesystem using zstd is now enabled by
> default. Use the compsize utility to find out the actual size on disk
> of a given file.
>
>
> --
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> 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



-- 
Elliott
___
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

License change: R-ggplot2 GPLv2 -> MIT

[Elliott Sales de Andrade]

As in subject.

-- 
Elliott
___
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

License change: R-rlang GPLv3 -> MIT

[Elliott Sales de Andrade]

As in subject. Due to other dependency changes, this will only be in Rawhide.

-- 
Elliott
___
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

License change: R-usethis GPLv3 -> MIT

[Elliott Sales de Andrade]

As in subject; this will be in Rawhide only due to other breaking changes.

-- 
Elliott
___
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: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)

[Elliott Sales de Andrade]

On Wed, 6 Jan 2021 at 05:12, Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Jan 06, 2021 at 04:49:03AM -0500, Jakub Cajka wrote:
> >
> > - Original Message -
> > > From: "Josh Boyer" 
> > > To: "Development discussions related to Fedora" 
> > > 
> > > Cc: "Zbigniew Jędrzejewski-Szmek" 
> > > Sent: Tuesday, January 5, 2021 9:45:28 PM
> > > Subject: Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
> > >
> > > On Tue, Jan 5, 2021 at 2:40 PM Robbie Harwood  wrote:
> > > >
> > > > Zbigniew Jędrzejewski-Szmek  writes:
> > > >
> > > > > On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote:
> > > > >> https://fedoraproject.org/wiki/Changes/golang1.16
> > > > >>
> > > > >> == Summary ==
> > > > >> Rebase of Golang package to upcoming version 1.16 in Fedora 34,
> > > > >
> > > > > No complaint about the Change, but...
> > > > > can we please stop saying "rebase"?
> > > > >
> > > > > That verb made sense when packaging was about a stack of patches and
> > > > > hacks. Nowadays maybe 90% of packages are just the upstream version,
> > > > > and another 9% have patches backported from git that will be dropped
> > > > > on the update to the next upstream version. Talking about a "rebase"
> > > > > is mostly confusing.
> > > >
> > > > Not really a defense, but this is what we call it internally for RHEL.
> > > > So even if we officially change the name, most of us are likely to keep
> > > > calling it rebase out of habit.
> > >
> > > I agree with you, Robbie.  It'll hang around and we'll have to deal
> > > with it for a long time.
> > >
> > > However, even internally in RHEL we're starting to see "rebase" be
> > > really hard to understand.  One team will mean "grab a new tarball
> > > that only contains a limited set of bug fixes" and another team will
> > > mean "grab an entirely new major version release that breaks ABI and
> > > on-disk format".  We should honestly look at how to articulate these
> > > kinds of things better, both in Fedora and in RHEL.  "Rebase" is
> > > quickly becoming meaningless.
> > >
> > > josh
> >
> > I kind of agree with all that have been said and will add my point of view. 
> > First I think that any term the we will invent or choose will eventually 
> > drift in way that we might not agree with or want with little that anyone 
> > can do about it.
> >
> > I would argue that in this case it is the most that rebase can be, 
> > especially with the need to actually rebuild "all" the Go packages to pick 
> > up the changes in the compiler and standard Go library. Not much on the 
> > compiler side as all the Fedora patches doesn't really need much 
> > re-basing(mostly just setting some more saner defaults), but the other 
> > packages are rebased in a sense on top of the new version of compiler.
>
> So... the compiler is *updated** and the packages are **rebuilt**?
> """
>  The Go compiler is updated to the upcoming version 1.16 in Fedora 34,
>  and all golang packages are rebuilt. (The pre-release version of Go will
>  be used for the rebuild if released version will not be available at the
>  time of the mass rebuild).
> """
> ?
>
> > I'm open to any improvement in the wording of the change, feel free to 
> > propose something here or just edit the proposal, but please let me know as 
> > the wiki AFAIK doesn't allow continuous notification on changes(or I 
> > haven't been able to find it and enable it for myself).
>
> There's a "watch" button topright, and also when editing, you are asked
> if you want to be notified about changes. I think I always get an email
> when somebody changes a page I'm watching.
>
> > > > (And it does make sense for RHEL where backporting more patches is the
> > > > norm.  I'm uncomfortable with the assertion that ~99% of all packages
> > > > have no downstream-only packages, but that might just be my bias in the
> > > > opposite direction, since I maintain a couple that do.)
>
> Yeah, my numbers were cut from straight cloth ;) It'd be interesting to have
> some real data.

As a first order estimate, it's rather straightforward to grab the
spec tarball and count the number of Patch lines in each one (which
ignores any fanciness with Lua or conditionals, and doesn't really say
if they are downstream-only, exactly).

The top ten count percentages are:
0  71.5054
1  14.7853
2  5.6351
3  2.7172
4  1.4361
5  0.9893
6  0.6611
7  0.4468
8  0.3419
9  0.2234
10 0.1824
>10 1.0760

So at minimum 71.5% have no downstream-only patches. I _think_
packages with fewer patches are ones that will likely go upstream (as
having more patches might indicate that upstream is dead/dying/slow to
release), so the remaining ones with less than 5 are _likely_ to go
upstream. Just guessing that's about half of those would be another
~12%, so around 84%.

For anyone interested in top-patchers:
 patch_count
cc65 170
gcl  129

Re: merging packages - is fedora fedora guideline right?

[Elliott Sales de Andrade]

On Wed, 20 Jan 2021 at 03:48, Petr Stodulka  wrote:
>
> Hi guys,
> I am confused about the official guidelines for merging of packages in Fedora.
>  From my POV, when I merge some packages and the functionality is preserved,
> the Obsoletes and Provides should be set and kept for 2 release cycles.
> So there is not problem with dependencies, etc. However, I've just realized
> that regarding guidelines only Obsoletes should be set.
>

That link is not to the current Guidelines. The Guidelines section on
renames is here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
and it says to add both, *unless* it is not a sufficiently compatible
replacement.

> Was it changed and is it really correct? From that point, I already have
> a reported broken deps for git-remote-hg because of the missing provides
> after the merge of some packages - I will fix it, but I am curious whether
> this is really expected. Can you guys put a light on that? Or the guideline
> needs to be fixed?
>
> Thank you!
>
> [0] 
> https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages
>
> --
> Petr Stodulka
> OS & Application Modernization
> IRC nicks: pstodulk, skytak
> Senior Software Engineer
> Red Hat Czech s.r.o.

-- 
Elliott
___
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: Fedora rawhide compose report: 20210201.n.1 changes

[Elliott Sales de Andrade]

On Tue, 2 Feb 2021 at 04:45, Vít Ondruch  wrote:
>
>
> Dne 02. 02. 21 v 10:23 Fedora Rawhide Report napsal(a):
> > OLD: Fedora-Rawhide-20210201.n.0
> > NEW: Fedora-Rawhide-20210201.n.1
> >
> > = SUMMARY =
> > Added images:0
> > Dropped images:  2
> > Added packages:  6
> > Dropped packages:0
> > Upgraded packages:   20573
> > Downgraded packages: 0
> >
> > Size of added packages:  2.15 GiB
> > Size of dropped packages:0 B
> > Size of upgraded packages:   133.57 GiB
> > Size of downgraded packages: 0 B
> >
> > Size change of upgraded packages:   -939.80 MiB
>
>
> This ^^ just caught my attention. Can somebody elaborate, where we saved
> ~1GB on rebuild? There are packages, where the savings were significant:
>
> Package:  AusweisApp2-1.20.2-11.fc34
> Old package:  AusweisApp2-1.20.2-10.fc34
> Summary:  Online identification with German ID card (Personalausweis)
> RPMs: AusweisApp2 AusweisApp2-data AusweisApp2-doc
> Size: 18.29 MiB
> Size change:  -4.63 MiB
> Changelog:
>* Mon Jan 25 2021 Fedora Release Engineering
>  - 1.20.2-11
>- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
>
> So I wonder what is behind?
>

The top twenty package name prefixes (I just split at the first dash) are:

In [61]: df.groupby('prefix').delta.aggregate(['count',
'sum']).sort_values('sum').head(20)
Out[61]:
 count sum
prefix
python2324 -327,898,137.92
golang1408 -139,438,803.92
origin   1  -82,627,788.80
boost1  -35,410,411.52
llvm7.0  1  -28,584,181.76
pyproj   1  -28,552,724.48
xeus 1  -28,322,037.76
mod_wsgi 1  -24,788,336.64
xtl  1  -23,613,931.52
arbor1  -23,498,588.16
libiio   1  -23,404,216.32
mantle   1  -21,223,178.24
kata 4  -16,488,417.28
singularity  1  -16,169,041.92
idris1  -15,256,780.80
kubernetes   1  -14,449,377.28
cross1  -12,939,427.84
geary1   -9,898,557.44
lazarus  1   -9,888,071.68
deepin  34   -8,408,135.16

Golang 1.16 (which includes kubernetes and origin on this list, among
others) may have some space saving with an improved linker
(http://golang.org/s/better-linker), which may be reflected here.

Looking at two of mine, xtl and xeus (each ~-20 M), the main
difference is in docs, which no longer include Lato, Roboto, and
FontAwesome in multiple web formats, totalling about 4.8M per
subpackage. These docs are generated by Sphinx and breathe.

The previous build of xtl used:
python3-breathe noarch  4.24.1-1.fc34
build  167 k
python3-sphinx  noarch  1:3.3.1-1.fc34
build  2.0 M
python3-sphinx_rtd_themenoarch  0.4.3-14.fc33
build  3.2 M

while the mass rebuild used:
python3-breathe noarch  4.26.0-1.fc34
build  169 k
python3-sphinx  noarch  1:3.4.3-1.fc34
build  2.1 M
python3-sphinx_rtd_themenoarch  0.5.1-1.fc34
build   61 k

Could it be that Sphinx or the theme was recently changed to drop
fonts and this is reflected as a massive change over all Python
packages that build docs?

>
> Vít
>


--
Elliott
___
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

the-new-hotness is broken?

[Elliott Sales de Andrade]

I just received 3 notifications that

> the-new-hotness saw an update for , but pkgdb says the maintainers 
> are not interested in bugs being filed

but all packages have monitoring enabled.

Did something break with it? Maybe the branch name changes?

-- 
Elliott
___
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: goocanvas2-cairotypes mock build fails

[Elliott Sales de Andrade]

On Thu, 10 Jun 2021 at 02:56, Martin Gansser  wrote:
>
> Hi,
>
> I'am trying to build goocanvas2-cairotypes with mock, but this fails with 
> this error message [1]:
>
> Files found in blib/arch: installing files in blib/lib into architecture 
> dependent library tree
> Installing 
> /builddir/build/BUILDROOT/goocanvas2-cairotypes-0.001-1.fc35.x86_64/usr/lib64/perl5/vendor_perl/auto/GooCanvas2/CairoTypes/CairoTypes.so
> Installing 
> /builddir/build/BUILDROOT/goocanvas2-cairotypes-0.001-1.fc35.x86_64/usr/lib64/perl5/vendor_perl/GooCanvas2/CairoTypes.pm
> Installing 
> /builddir/build/BUILDROOT/goocanvas2-cairotypes-0.001-1.fc35.x86_64/usr/share/man/man3/GooCanvas2::CairoTypes.3pm
> + chmod 0755 
> '/builddir/build/BUILDROOT/goocanvas2-cairotypes-0.001-1.fc35.x86_64%{perl_vendorarch}/auto/GooCanvas2/CairoTypes/CairoTypes.so'
> chmod: cannot access 
> '/builddir/build/BUILDROOT/goocanvas2-cairotypes-0.001-1.fc35.x86_64%{perl_vendorarch}/auto/GooCanvas2/CairoTypes/CairoTypes.so':
>  No such file or directory

It looks like %{perl_vendorarch} is not expanded; did you specify the
right Perl BuildRequires?
https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_build_dependencies

> RPM build errors:
> error: Bad exit status from /var/tmp/rpm-tmp.lactiy (%install)
> Bad exit status from /var/tmp/rpm-tmp.lactiy (%install)
> Child return code was: 1
>
> [1] https://martinkg.fedorapeople.org/ErrorReports/build.log
>
> Regards
> Martin

-- 
Elliott
___
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: Upcoming soname bumps

[Elliott Sales de Andrade]

On Sat, 12 Jun 2021 at 21:14, Jerry James  wrote:
>
> Hello all,
>

Hi,

> It's nearly time for another round of mathematical software updates,
> including some soname bumps.  I am going to do the following, in this
> approximate order:
>
> - cliquer: update to version 1.22
> - cocoalib: update to version 0.99713
> - ffcall: update to version 2.3
> - memtailor: update to git head for some minor improvements
> - pari: build with pthreads support
> - primecount: update to version 7.0, which entails an soname bump
> - clisp: rebuild due to the ffcall and pari updates
> - eclib: rebuild due to the pari update
> - giac: rebuild due to the cocoalib and pari updates, and add cliquer support
> - L-function: rebuild due to the pari update
> - mathic: update to git head for some minor improvements
> - normaliz: rebuild due to the cocoalib update
> - python-cysignals: update to version 1.10.3
> - mathicgb: update to git head for some minor improvements
> - python-cypari2: update to version 2.1.2
> - python-fpylll: update to version 0.5.6
> - python-pplpy: rebuild due to the python-cysignals update
> - Singular: update to version 4.2.0, which entails an soname bump
> - palp: update to version 2.11
> - polymake: update to version 4.4, which entails an soname bump
> - pynac: update to version 0.7.27
> - python-jupymake: rebuild due to the polymake soname bump
> - sagemath: update to version 9.3
> - python-jupyter-polymake: rebuild due to the polymake soname bump

This one is noarch though; does it really need a rebuild?

> - Macaulay2: update to version 1.18
>
> I'm still working through some minor issues with Macaulay2 and some
> major issues with sagemath, but I hope to have those worked out and
> builds ready to go sometime next week.  The builds will be done for
> Rawhide initially, but the sagemath fans in the Fedora audience
> *really* want version 9.3, so if all goes well, I will also update at
> least F34, and F33 as well if sufficient pressure is applied to do so.
>
> Regards,
> --
> Jerry James
> http://www.jamezone.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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Elliott
___
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: [HEADS UP] Moving to sip 5 in Rawhide

[Elliott Sales de Andrade]

On Wed, 16 Jun 2021 at 22:51, Scott Talbert  wrote:
>
> Hi,
>
> Just a heads-up, I've been working on converting packages from sip 4 to
> sip 5 in Rawhide.  (sip is the Python bindings generation system used by
> PyQt and wxPython.)
>

I see we have Qt6, but not PyQt6, in Fedora 34. Is this what's
required to make that available, or is it just that no-one has gotten
around to it?

> I'm planning on opening pull requests against the affected packages soon.
> Please DO NOT merge these PRs yet - they need to be merged and built in a
> side tag in order to build them in the correct order.  Please DO review
> and comment on the PRs though.  Kevin and Rex will be helping merge and
> build once the changes are reviewed.
>
> The sip 5 changes are planned for F35+ only.  Please let me know in the PR
> if you prefer the changes to be fast-forwardable to older releases and
> I'll %if guard them.
>
> The affected packages are:
> python-pyqt5-sip -> NEW package
> calibre
> krita
> plplot
> pyqtwebengine
> python-pyqtchart
> python-qt5
> python3-poppler-qt5
> qgis
> qhexedit2
> qscintilla
> scidavis
> sip
> veusz
>
> Thanks,
> Scott
> ___
> 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



-- 
Elliott
___
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: RPM build errors: Illegal char '@' (0x40) in: @2.15.0@

[Elliott Sales de Andrade]

On Wed, 12 May 2021 at 04:23, Sandro Mani  wrote:
>
> Hi
>
> This is a new one [1] (koji task [2]):
>
> Provides: libimagequant = 2.15.0-1.fc35 libimagequant(x86-64) = 2.15.0-1.fc35 
> libimagequant.so.0()(64bit)
> Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) 
> <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) 
> libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) 
> libc.so.6(GLIBC_2.4)(64bit) libgcc_s.so.1()(64bit) 
> libgcc_s.so.1(GCC_3.3.1)(64bit) libgomp.so.1()(64bit) 
> libgomp.so.1(GOMP_1.0)(64bit) libgomp.so.1(GOMP_4.0)(64bit) 
> libgomp.so.1(OMP_1.0)(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) 
> libm.so.6(GLIBC_2.27)(64bit) libm.so.6(GLIBC_2.29)(64bit) rtld(GNU_HASH)
> Processing files: libimagequant-devel-2.15.0-1.fc35.x86_64
> error: Illegal char '@' (0x40) in: @2.15.0@
> Provides: libimagequant-devel = 2.15.0-1.fc35 libimagequant-devel(x86-64) = 
> 2.15.0-1.fc35
> Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) 
> <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> Requires: /usr/bin/pkg-config libimagequant.so.0()(64bit)
> RPM build errors:
> Illegal char '@' (0x40) in: @2.15.0@
> Child return code was: 1
>
> 2.15.0 is the version of the package. Any ideas where this one comes from?

In the build log, I see:
sed 's|PREFIX|/usr|;s|VERSION|2.15.0|' < imagequant.pc.in > imagequant.pc

And it says @VERSION@ to be substituted by CMake, so this ends up as @2.15.0@.

See the diff:
https://github.com/ImageOptim/libimagequant/compare/2.14.1..2.15.0

IOW, you can stop doing that manually.

> Apparently not from elfdeps:
>
> $ /usr/lib/rpm/elfdeps --provides libimagequant.so
> libimagequant.so.0()(64bit)
> $ /usr/lib/rpm/elfdeps --requires libimagequant.so
> libgcc_s.so.1(GCC_3.3.1)(64bit)
> libgomp.so.1(GOMP_4.0)(64bit)
> libgomp.so.1(GOMP_1.0)(64bit)
> libgomp.so.1(OMP_1.0)(64bit)
> libm.so.6(GLIBC_2.27)(64bit)
> libm.so.6(GLIBC_2.2.5)(64bit)
> libm.so.6(GLIBC_2.29)(64bit)
> libc.so.6(GLIBC_2.3.4)(64bit)
> libc.so.6(GLIBC_2.14)(64bit)
> libc.so.6(GLIBC_2.4)(64bit)
> libc.so.6(GLIBC_2.2.5)(64bit)
> libm.so.6()(64bit)
> libgomp.so.1()(64bit)
> libgcc_s.so.1()(64bit)
> libc.so.6()(64bit)
> rtld(GNU_HASH)
>
> Thanks
> Sandro
>
> [1] https://kojipkgs.fedoraproject.org//work/tasks/743/67740743/build.log
> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=67740603
>
> ___
> 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



-- 
Elliott
___
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