date:20200806

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

Bug ID: 1866972
   Summary: perl-Test2-Suite-0.000132 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test2-Suite
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.000132
Current version/release in rawhide: 0.000130-1.fc33
URL: http://search.cpan.org/dist/Test2-Suite/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/9536/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Proposing a new Perl Module Versioning Scheme

2020-08-06 Thread Dan Book

I wrote a blog post thoroughly explaining Perl module versions and agree
with the assessment and suggested method presented (though I have no
comment on the remedy).

http://blogs.perl.org/users/grinnz/2018/04/a-guide-to-versions-in-perl.html

-Dan


On Thu, Aug 6, 2020, 1:09 PM Tina Müller  wrote:

> Hi,
>
> I'm working at SUSE, and for about a year I have been in charge of updating
> the CPAN modules in SUSE Open Build Service:
> https://build.opensuse.org/project/show/devel:languages:perl
>
> This is half automated. The spec file is generated with the cpanspec
> script,
> and we manually look over the diff and then request the package to be
> updated.
>
> I would like to make a suggestion and will explain the problems in detail,
> so
> that we are all on the same page.
>
> # Status Quo
>
> As you probably know, the versioning scheme of Perl modules differs from
> rpm.
> For perl, the versions are decimal, so it can happen that for a given
> module A
> versions 0.23 and 0.3 are released. The latter one is higher for perl.
> Semantically, 0.23 is 0.230.0 and 0.3 is 0.300.0, when correctly
> translated to a
> rpm like version.
>
> You can also use versions like 1.2.3 in perl. In that case, they are
> already
> semantically equal to rpm like versions. The majority of perl modules
> still uses
> decimal versions, though.
>
> Many distributions including openSUSE and Fedora are just taking over the
> perl
> module version literally.
>
> This sometimes leads to problems, for example if module B requires module
> A:
>
>  Requires: perl(A) >= 0.23
>
> When module A is uploaded with version 0.3, this will result in an
> unresolvable
> dependency.
>
> In those cases we have to manually fix the requirement.
> Granted, this doesn't happen very often, but when, it's annoying.
>
> There might also be cases where it is the other way around, e.g. module A
> has versions 0.02 and 0.1. 0.02 is just the same as 0.2 in rpm.
>
> Module B has:
>
>  Requires: perl(A) >= 0.1
>
> If module A is still at version 0.02, the dependency will be satisfied,
> because 0.1 is lower in rpm than 0.02.
> But that is wrong. In this case we don't see the mistake though.
>
> Here is a discussion about this that started when I posted my Howto
> for creating a CPAN module with correct Metadata:
> https://github.com/perlpunk/perl5-module-meta/issues/5
>
> # Alternative
>
> The correct way to translate the versions for the spec would be:
>
>  perl -wE'say version->parse($ARGV[0])->normal;' 0.23
>  v0.230.0
>
> and then we just have to cut off the 'v' at the beginning.
> This should work correctly for all module versions, and it is the right
> thing
> to do.
> We wouldn't need any manual handling anymore.
>
> # Problem
>
> As it is impossible to just change all modules in the distributions at the
> same
> time, we need backwards compatibility.
>
> # Proposal
>
> I discussed this on IRC #opensuse-factory. A suggestion came up how to
> avoid
> having to be backward compatible.
>
> The versions of each module inside a CPAN distribution are usually
> generated
> at build time with perl.prov
> (
> https://github.com/rpm-software-management/rpm/blob/master/scripts/perl.prov
> ).
>
> Some distributions also use
> https://github.com/rpm-software-management/rpm/blob/master/scripts/perl.req
> but openSUSE doesn't. The dependencies are extracted at the time when the
> spec
> file is generated.
>
> We could add a new capability additionally to perl(). Maybe cpan(). This
> can
> use the new versioning scheme.
> The packages could be built with both capabilities.
> As soon as all packages are rebuilt, we can start to adjust the Requires
> lines to use the new capability.
>
> This part is actually pretty easy and shouldn't require much work. Please
> correct me if I'm wrong.
>
> However, there is also the package version, and instead of
>
>  Require: perl(A::B) >= x.y
>
> one can do
>
>  Require: perl-A-B >= x.y
>
> so for those package versions we need backward compatibility.
>
> My idea is to take a snapshot of all CPAN modules we have in our repository
> and save the package id and the version.
>
> The migration strategy to the new versioning scheme would be:
>
> All modulues having 1, 2 or 3 decimals can update to the new scheme
> whenever
> a new version is uploaded.
>
> Let's take module A as the example again. The current (CPAN) version would
> be
> 0.23.
>
> When a new version 0.3 is uploaded, we compare the version for A to our
> saved
> version 0.23. If it is (decimally) higher, we use the new scheme: 0.300.0.
> Same thing for other modules requiring A (although we mostly use capability
> requirements anyway).
>
> For all modules having 4 or more decimals, the switch to the version scheme
> has to wait until the major version is updated (which might be never for
> some
> modules).
> E.g. module B has 1.201703. Then we have to wait until the major version is
> incremented to 2.
>
> I made some statistics for our

[Bug 1859415] perl-Log-Log4perl-1.50 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Log-Log4perl-1.50-1.fc |perl-Log-Log4perl-1.50-1.fc
   |33  |33
   |perl-Log-Log4perl-1.50-1.fc |perl-Log-Log4perl-1.50-1.fc
   |32  |32
   |perl-Log-Log4perl-1.50-1.fc |perl-Log-Log4perl-1.50-1.fc
   |31  |31
   ||perl-Log-Log4perl-1.50-1.el
   ||8



--- Comment #10 from Fedora Update System  ---
FEDORA-EPEL-2020-ac5d34630b has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Coin4 build failure

While trying to update the spec for the CMake change I ran into this for
the first time:

cd /builddir/build/BUILD/coin-6enkw/x86_64-redhat-linux-gnu/src/base &&
/usr/bin/g++
 -I/builddir/build/BUILD/coin-6enkw/x86_64-redhat-linux-gnu/data
-I/builddir/build/BUILD/coin-6enkw/include/Inventor/annex
-I/builddir/build/BUILD/coin-6enkw/src
-I/builddir/build/BUILD/coin-6enkw/x86_64-redhat-linux-gnu/src
-I/builddir/build/BUILD/coin-6enkw/include
-I/builddir/build/BUILD/coin-6enkw/x86_64-redhat-linux-gnu/include -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 -DNDEBUG -fPIC -DHAVE_CONFIG_H -DCOIN_INTERNAL
-DCOIN_DEBUG=0 -o CMakeFiles/base.dir/dict.cpp.o -c
/builddir/build/BUILD/coin-6enkw/src/base/dict.cpp
/builddir/build/BUILD/coin-6enkw/src/xml/expat/xmlparse.c:94:3: error:
#error You do not have support for any sources of high quality entropy
enabled. For end user security, that is probably not what you want. Your
options include: * Linux + glibc >=2.25 (getrandom): HAVE_GETRANDOM, *
Linux + glibc <2.25 (syscall SYS_getrandom): HAVE_SYSCALL_GETRANDOM, * BSD
/ macOS >=10.7 (arc4random_buf): HAVE_ARC4RANDOM_BUF, * BSD / macOS <10.7
(arc4random): HAVE_ARC4RANDOM, * libbsd (arc4random_buf):
HAVE_ARC4RANDOM_BUF + HAVE_LIBBSD, * libbsd (arc4random): HAVE_ARC4RANDOM +
HAVE_LIBBSD, * Linux / BSD / macOS (/dev/urandom): XML_DEV_URANDOM *
Windows (RtlGenRandom): _WIN32. If insist on not using any of these, bypass
this error by defining XML_POOR_ENTROPY; you have been warned. If you have
reasons to patch this detection code away or need changes to the build
system, please open a bug. Thank you!
   94 | # error  \
  |   ^

Thoughts?

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

distro perl's ldflags='... -Wl,-z,relro ...' causing module build errors. bug in distro perl flags? or module code?

2020-08-06 Thread PGNet Dev

i'm attempting to build a MaxMind GeopIP2 DB reader perl module

MaxMind::DB::Reader::XS

( https://metacpan.org/pod/MaxMind::DB::Reader::XS
 )

on Fedora 32.


the build fails on F32 with Errors:

"/usr/bin/ld: unrecognized option '-Wl,-z,relro'"

&

"Unsupported compile language "C"" ?

I've filed a bug at the module upstream

uninstallable on Fedora32, errors: "/usr/bin/ld: unrecognized option 
'-Wl,-z,relro'" & "Unsupported compile language "C"" ?
https://github.com/maxmind/MaxMind-DB-Reader-XS/issues/32

the build fails only with Fedora's distro perl, which _includes_ the ldflags

perl -V | grep -i " ldflags"
ldflags ='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong 
-L/usr/local/lib'

but is _successful_ on opensuse, where distro perl's ldflags do NOT include 
'-Wl,-z,relro',

perl -V | grep -i " ldflags"
ldflags =' -L/usr/local/lib64 -fstack-protector-strong'


Is this^ a problem with Fedora's perl build flags "incorrectly" _including_ 
relro?  I've found/followed some of the perl hardening threads @ Fedora; IIUC, 
it's intentional ...

Or likely an issue with the module not correctly dealing with it?
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: mpich always injects lto flags

2020-08-06 Thread Christoph Junghans

On Thu, Aug 6, 2020 at 5:24 PM Jeff Law  wrote:
>
> On Thu, 2020-08-06 at 15:59 -0600, Christoph Junghans wrote:
> > On Wed, Aug 5, 2020 at 7:01 PM Christoph Junghans  
> > wrote:
> > > On Wed, Aug 5, 2020 at 2:21 PM Jeff Law  wrote:
> > > > On Wed, 2020-08-05 at 21:56 +0200, David Schwörer wrote:
> > > > > On 8/5/20 8:45 PM, Christoph Junghans wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I am trying to rebuild espresso to adapt to the recent cmake 
> > > > > > changes,
> > > > > > when doing this I hit
> > > > > > https://github.com/espressomd/espresso/issues/3396, which prevents 
> > > > > > us
> > > > > > from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> > > > > > which works for the build with openmpi, but gets ignored for the 
> > > > > > mpich
> > > > > > build.
> > > > > >
> > > > > > I think the problem is that CMake picks up the lto flags from mpicxx
> > > > > > and then puts them in
> > > > > > MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> > > > > >
> > > > > > So I think the fix would be to strip these flags from mpicc. Sounds 
> > > > > > reasonable?
> > > > > >
> > > > > > The flags also contain
> > > > > > '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> > > > > > makes it depend on redhat-rpm-config. We had a similar issue in 
> > > > > > hdf5 a
> > > > > > while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
> > > > > >
> > > > > > Christoph
> > > > > >
> > > > > Another related bug is:
> > > > >
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1821728
> > > > Note that the BZ complains about -fstack-clash-protection in LLVM which 
> > > > has had
> > > > various bits landing over the last few months.  So that specific issue 
> > > > I'd expect
> > > > to resolve itself over time.  The more general issue remains though.
> > > https://src.fedoraproject.org/rpms/mpich/pull-request/4
> >
> > Can any proven package retrigger
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=48824350, the
> > tests seem flaky and passed for me here:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=48825280
> Done.  ppc64le seems to have tested fine this time.  Of course, there's quite 
> a
> back-up on s390x, so it'll be a while before it's done and tagged.
Great, thanks!

>
> jeff
>
>
>


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

Re: mpich always injects lto flags

On Thu, 2020-08-06 at 15:59 -0600, Christoph Junghans wrote:
> On Wed, Aug 5, 2020 at 7:01 PM Christoph Junghans  wrote:
> > On Wed, Aug 5, 2020 at 2:21 PM Jeff Law  wrote:
> > > On Wed, 2020-08-05 at 21:56 +0200, David Schwörer wrote:
> > > > On 8/5/20 8:45 PM, Christoph Junghans wrote:
> > > > > Hi,
> > > > > 
> > > > > I am trying to rebuild espresso to adapt to the recent cmake changes,
> > > > > when doing this I hit
> > > > > https://github.com/espressomd/espresso/issues/3396, which prevents us
> > > > > from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> > > > > which works for the build with openmpi, but gets ignored for the mpich
> > > > > build.
> > > > > 
> > > > > I think the problem is that CMake picks up the lto flags from mpicxx
> > > > > and then puts them in
> > > > > MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> > > > > 
> > > > > So I think the fix would be to strip these flags from mpicc. Sounds 
> > > > > reasonable?
> > > > > 
> > > > > The flags also contain
> > > > > '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> > > > > makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
> > > > > while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
> > > > > 
> > > > > Christoph
> > > > > 
> > > > Another related bug is:
> > > > 
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1821728
> > > Note that the BZ complains about -fstack-clash-protection in LLVM which 
> > > has had
> > > various bits landing over the last few months.  So that specific issue 
> > > I'd expect
> > > to resolve itself over time.  The more general issue remains though.
> > https://src.fedoraproject.org/rpms/mpich/pull-request/4
> 
> Can any proven package retrigger
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48824350, the
> tests seem flaky and passed for me here:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48825280
Done.  ppc64le seems to have tested fine this time.  Of course, there's quite a
back-up on s390x, so it'll be a while before it's done and tagged.

jeff


___
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: Test machines for s390x?

2020-08-06 Thread Adam Williamson

On Thu, 2020-08-06 at 18:43 -0400, Robbie Harwood wrote:
> Adam Williamson  writes:
> 
> > Neal Gompa wrote:
> > > Adam Williamson  wrote:
> > > > Robbie Harwood wrote:
> > > > > Elliott Sales de Andrade  writes:
> > > > > 
> > > > > > 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
> > > > > 
> > > > > It's very strange to me that having test hardware available isn't a
> > > > > requirement for being a Primary architecture, or for that
> > > > > architecture being present in koji.  IMO we should change that
> > > > > going forward.
> > > > 
> > > > s390x isn't a primary arch. It's an alternative arch.
> 
> That's true, which is why I had the "or".  I'd like it to be a
> requirement for either/both.

Right, I did miss that or, sorry.

> > > > https://fedoraproject.org/wiki/Architectures
> > > 
> > > That page is out of date. All architectures are effectively primary
> > > now, since failures for any arch block builds from releasing in Koji.
> > 
> > We still draw a distinction between the two, it just doesn't have that
> > dimension to it any more. The page even explains this in its definition
> > at the top. The distinction is rather smaller now, but still there.
> > 
> > In the release criteria we've mostly switched to using the term
> > "release-blocking arches", and s390x isn't one of those either. :)
> 
> You're right, I'm being loose with language.  Neal's point is what I'm
> trying to articulate: whatever the formal position is, we as packagers
> have to care about making this architecture work, since our builds won't
> go through if it doesn't.

Sure, we should probably just call them "koji arches" or something...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: Test machines for s390x?

2020-08-06 Thread Robbie Harwood

Adam Williamson  writes:

> Neal Gompa wrote:
>> Adam Williamson  wrote:
>>> Robbie Harwood wrote:
 Elliott Sales de Andrade  writes:
 
> 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
 
 It's very strange to me that having test hardware available isn't a
 requirement for being a Primary architecture, or for that
 architecture being present in koji.  IMO we should change that
 going forward.
>>> 
>>> s390x isn't a primary arch. It's an alternative arch.

That's true, which is why I had the "or".  I'd like it to be a
requirement for either/both.

>>> https://fedoraproject.org/wiki/Architectures
>> 
>> That page is out of date. All architectures are effectively primary
>> now, since failures for any arch block builds from releasing in Koji.
>
> We still draw a distinction between the two, it just doesn't have that
> dimension to it any more. The page even explains this in its definition
> at the top. The distinction is rather smaller now, but still there.
>
> In the release criteria we've mostly switched to using the term
> "release-blocking arches", and s390x isn't one of those either. :)

You're right, I'm being loose with language.  Neal's point is what I'm
trying to articulate: whatever the formal position is, we as packagers
have to care about making this architecture work, since our builds won't
go through if it doesn't.

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning openbabel

Dominik 'Rathann' Mierzejewski wrote:
> This is the porting guide:
> https://open-babel.readthedocs.io/en/latest/UseTheLibrary/migration.html#migrating-to-3-0
> 
> It doesn't look too bad from a cursory look.

To me, this list looks like a classic incompatible major version of a 
library that is nontrivial to port to and that some packages will never get 
ported to, requiring a compatibility library.

I see that the CLI and the Python modules have been renamed entirely, that 
the C++ interface has renamed and removed methods (which I assume are also 
renamed and removed in the Python bindings), and that there is even a major 
API design change (the "Handling of implicit hydrogens" part). This type of 
changes is not trivial to port to.

Kevin Kofler
___
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: mpich always injects lto flags

2020-08-06 Thread Christoph Junghans

On Wed, Aug 5, 2020 at 7:01 PM Christoph Junghans  wrote:
>
> On Wed, Aug 5, 2020 at 2:21 PM Jeff Law  wrote:
> >
> > On Wed, 2020-08-05 at 21:56 +0200, David Schwörer wrote:
> > > On 8/5/20 8:45 PM, Christoph Junghans wrote:
> > > > Hi,
> > > >
> > > > I am trying to rebuild espresso to adapt to the recent cmake changes,
> > > > when doing this I hit
> > > > https://github.com/espressomd/espresso/issues/3396, which prevents us
> > > > from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> > > > which works for the build with openmpi, but gets ignored for the mpich
> > > > build.
> > > >
> > > > I think the problem is that CMake picks up the lto flags from mpicxx
> > > > and then puts them in
> > > > MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> > > >
> > > > So I think the fix would be to strip these flags from mpicc. Sounds 
> > > > reasonable?
> > > >
> > > > The flags also contain
> > > > '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> > > > makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
> > > > while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
> > > >
> > > > Christoph
> > > >
> > > Another related bug is:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1821728
> > Note that the BZ complains about -fstack-clash-protection in LLVM which has 
> > had
> > various bits landing over the last few months.  So that specific issue I'd 
> > expect
> > to resolve itself over time.  The more general issue remains though.
> https://src.fedoraproject.org/rpms/mpich/pull-request/4

Can any proven package retrigger
https://koji.fedoraproject.org/koji/taskinfo?taskID=48824350, the
tests seem flaky and passed for me here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48825280

Thanks,

Christoph

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



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

Re: Orphaning openbabel

2020-08-06 Thread Dominik 'Rathann' Mierzejewski

On Thursday, 30 July 2020 at 19:18, Alexander Ploumistos wrote:
[...]
> Given the time of the year in the Northern Hemisphere, do you think
> you could hold on to the package a little longer (e.g. until the
> beginning of September), so that people who are interested might get
> the chance to get our act together?

Sure thing, though I probably won't have time to do anything with the
package in the meantime.

> Thank you for everything you've done so far,

You're welcome! I've enjoyed maintaining a lot of packages over the
years, but it's time to let go of those I have no interest in anymore.
Openbabel is one of them.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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

[Bug 1842274] perl-Excel-Writer-XLSX-1.07 is available

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



--- Comment #10 from Upstream Release Monitoring 
 ---
Created attachment 1710703
  --> https://bugzilla.redhat.com/attachment.cgi?id=1710703=edit
[patch] Update to 1.07 (#1842274)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1842274] perl-Excel-Writer-XLSX-1.07 is available

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Excel-Writer-XLSX-1.06 |perl-Excel-Writer-XLSX-1.07
   |is available|is available



--- Comment #9 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.07
Current version/release in rawhide: 1.03-2.fc32
URL: http://search.cpan.org/dist/Excel-Writer-XLSX/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/2860/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

2020-08-06 Thread tdawson

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2020-08-07 from 21:00:00 to 22:00:00 UTC
   At freenode@fedora-meeting

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-6
#topic EPEL-7
#topic EPEL-8
#topic Openfloor
#endmeeting




Source: https://apps.fedoraproject.org/calendar/meeting/9722/

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

Re: Orphaning openbabel

2020-08-06 Thread Dominik 'Rathann' Mierzejewski

On Friday, 31 July 2020 at 11:04, Kevin Kofler wrote:
[...]
> We will likely also need an openbabel2 compatibility package then, because I 
> doubt that everything will build against OpenBabel 3 without non-trivial 
> porting.

This is the porting guide:
https://open-babel.readthedocs.io/en/latest/UseTheLibrary/migration.html#migrating-to-3-0

It doesn't look too bad from a cursory look.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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: What do to about massive # of FTBFS bugs?

On Thu, 2020-08-06 at 17:54 +0200, Fabio Valentini wrote:
> On Thu, Aug 6, 2020 at 4:51 PM Jeff Law  wrote:
> > On Thu, 2020-08-06 at 06:17 -0500, Richard Shaw wrote:
> > > On Thu, Aug 6, 2020 at 5:08 AM Fabio Valentini  
> > > wrote:
> > > > I'd say it's pretty safe to submit things to rawhide again. I haven't
> > > > seen any lingering buildroot issues for the past 2-3 days, except for
> > > > some longer wait/build times in koji due to batched ELN build
> > > > submissions (but those are finished now too).
> > > 
> > > Ok, good deal. I've been trying to knock out 2-3 packages a day so I'll 
> > > get to the bottom of the pile in a week or so :)
> > I'm maybe 40% of the way through the failures looking for things that are
> > obviously LTO related and reassigning those to myself.
> > 
> > Based on what I've seen the cmake stuff is still the most common failure.  
> > I've
> > still seen a few s390x infrastructure issues.  Lots of noarch packages that 
> > have
> > failed (haven't looked at those at all since they can't be LTO failures).
> 
> When resubmitting failures caused by intermittent and infra issues, I
> came across a few of those "lto-wrapper failures" on some arches as
> well.
> I can compile a list, if it helps.
Sure that helps.

> 
> I also think LTO can definitely cause issues in noarch builds, if
> mis-compiled archful dependency crashes during the build.
Those kinds of secondary failures do happen.  I've even had tertiary failures
(gcc mis-compiles gas which in turn mis-compiled some X library and your xclock
would render as a mirror image of what it should have -- yes, that's really
happened to me).

Clearly someone is going to need to look at the .noarch things.  But I'm really
focused on first order LTO issues right now.  I'm sure that if there's a second
order issue where LTO is mis-compiling something which in turn causes a .noarch
issue, they'll let the world know...

But the most likely places where an LTO issue is going to show up is in packages
that build code with GCC or LLVM, so that's where I need to focus my time right
now.

jeff
> 
___
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: What to do about FTBFS because auf cmake change?

Neal Gompa wrote:
> Not only is that terrible advice, it's actually *wrong*. If you're
> going to do bad things like that, at least make sure to test it.

I did:
https://src.fedoraproject.org/rpms/blogilo/c/ee482f1b33b50d79190951180d209e749b545dcd?branch=master
https://koji.fedoraproject.org/koji/buildinfo?buildID=1579763

> If you're going to override the build directory with CMake like that
> to bypass the behavior (which you *should not do*), you actually will
> need to set both the source directory (with -S) and the build
> directory (with -B) to override the default setting that the macro
> sets.

I assure you that CMake accepts a lone .. as equivalent to -S.. even to 
override a previous -S setting. I tried it and it builds perfectly fine. It 
might not be documented to work, but it works.

> But note that attempting to force an in-source build or the old
> behavior will eventually break, since CMake upstream intends to
> disallow this eventually (hence all the warnings it throws when you
> try to do that). And a number of projects are already manually
> attempting to break legacy behavior in their CMakeLists.

CMake does not warn about "%{cmake_kf5} .. -B.". See the build.log files in 
the linked build.

Kevin Kofler
___
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: Test machines for s390x?

2020-08-06 Thread Dominik 'Rathann' Mierzejewski

On Thursday, 06 August 2020 at 18:45, Dan Horák wrote:
[...]
> Kevin, shall I try to get a guest from Marist we could use as the stable
> test/devel machine? Like we do with the ppc64le machine from the
> OpenPOWER hub.

By the way, do you have a reliable support contact at the OpenPOWER hub?
I've been trying to contact Michal Ruprich for months about a couple
of VMs I have there that became inaccessible but there has been no reply.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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

[389-devel] please review: PR 51234 - ds-replcheck crashes in offline mode

2020-08-06 Thread Mark Reynolds


https://pagure.io/389-ds-base/pull-request/51234

--

389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

Re: Lost ELF library auto-provides since mass rebuild

* Daniel P. Berrangé:

> This AC_LANG_PROGRAM call puts the code snippet inside a main() { ...}
> so what configure was actually attempting to compile is:
>
>  int
>  main ()
>  {
>  
>int f1() { }
>int f2() { }
>asm(".symver f1, f@VER1");
>asm(".symver f2, f@@VER2");
>int main(int argc, char **argv) { }
>  
>;
>return 0;
>  }
>
>
> clearly this code is nonsense, but by luck it still worked until newer
> GCC came along.

I think it's actually a binutils change.  Older binutils was happy to
apply .symver to undefined symbols, effectively ignoring the directive
(because there is nothing to attach it to).  That changed in binutils
2.35, which started to diagnose the problem with an error.

> The code has to be passed as the first arg of AC_LANG_PROGRAM, not the
> second arg, so that its outside the main() {...}

Glad it's been fixed.

Thanks,
Florian
___
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: Test machines for s390x?

2020-08-06 Thread Adam Williamson

On Thu, 2020-08-06 at 14:01 -0400, Neal Gompa wrote:
> On Thu, Aug 6, 2020 at 2:00 PM Adam Williamson
>  wrote:
> > 
> > On Thu, 2020-08-06 at 13:42 -0400, Robbie Harwood wrote:
> > > Elliott Sales de Andrade  writes:
> > > 
> > > > 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
> > > 
> > > It's very strange to me that having test hardware available isn't a
> > > requirement for being a Primary architecture, or for that architecture
> > > being present in koji.  IMO we should change that going forward.
> > 
> > s390x isn't a primary arch. It's an alternative arch.
> > 
> > https://fedoraproject.org/wiki/Architectures
> 
> That page is out of date. All architectures are effectively primary
> now, since failures for any arch block builds from releasing in Koji.

We still draw a distinction between the two, it just doesn't have that
dimension to it any more. The page even explains this in its definition
at the top. The distinction is rather smaller now, but still there.

In the release criteria we've mostly switched to using the term
"release-blocking arches", and s390x isn't one of those either. :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: neuro-sig COPR group clean up

2020-08-06 Thread Andy Mender

On Thu, 6 Aug 2020 at 19:30, Ankur Sinha  wrote:

> Hello,
>
> We've got quite a few unmaintained repos on COPR under the neuro-sig
> group.  I intend to do a bit of housekeeping to remove projects there
> that aren't in use any more. Please take a look and let me know if you
> do not want me to delete a project:
>
> https://copr.fedorainfracloud.org/groups/g/neurofedora/coprs/
>
> I will delete all projects apart from the neurofedora-extra copr on
> Monday, the 10th of August.
>

Of some interest to me would be the python-joblib package, but I see that a
more recent version is already in the repos.
___
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: Test machines for s390x?

On Thu, Aug 6, 2020 at 2:00 PM Adam Williamson
 wrote:
>
> On Thu, 2020-08-06 at 13:42 -0400, Robbie Harwood wrote:
> > Elliott Sales de Andrade  writes:
> >
> > > 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
> >
> > It's very strange to me that having test hardware available isn't a
> > requirement for being a Primary architecture, or for that architecture
> > being present in koji.  IMO we should change that going forward.
>
> s390x isn't a primary arch. It's an alternative arch.
>
> https://fedoraproject.org/wiki/Architectures

That page is out of date. All architectures are effectively primary
now, since failures for any arch block builds from releasing in Koji.



-- 
真実はいつも一つ！/ 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

Re: Test machines for s390x?

2020-08-06 Thread Adam Williamson

On Thu, 2020-08-06 at 13:42 -0400, Robbie Harwood wrote:
> Elliott Sales de Andrade  writes:
> 
> > 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
> 
> It's very strange to me that having test hardware available isn't a
> requirement for being a Primary architecture, or for that architecture
> being present in koji.  IMO we should change that going forward.

s390x isn't a primary arch. It's an alternative arch.

https://fedoraproject.org/wiki/Architectures
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: Test machines for s390x?

2020-08-06 Thread Robbie Harwood

Elliott Sales de Andrade  writes:

> 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

It's very strange to me that having test hardware available isn't a
requirement for being a Primary architecture, or for that architecture
being present in koji.  IMO we should change that going forward.

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Lost ELF library auto-provides since mass rebuild

2020-08-06 Thread Daniel P . Berrangé

On Thu, Aug 06, 2020 at 05:04:20PM +0200, Florian Weimer wrote:
> * Daniel P. Berrangé:
> 
> > This is in relation to this bug
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1862745
> >
> > The last but one build of libgphoto have auto-provides for the ELF
> > libraries:
> >
> > libgphoto2 = 2.5.24-2.fc33
> > libgphoto2(x86-64) = 2.5.24-2.fc33
> > libgphoto2.so.6()(64bit)
> > libgphoto2_port.so.12()(64bit)
> > libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit)
> > libgphoto2_port.so.12(LIBGPHOTO2_INTERNAL)(64bit)
> >
> > any new build both in the mass rebuild and any scratch builds I try
> > looses some of these auto deps leaving just
> >
> > libgphoto2 = 2.5.24-3.fc33
> > libgphoto2(x86-64) = 2.5.24-3.fc33
> > libgphoto2.so.6()(64bit)
> > libgphoto2_port.so.12()(64bit)
> >
> >
> > Was there any change people are aware of that would explain this and
> > suggest what we need todo to get these deps back in libghoto ?
> 
> I think this isn't the real issue.  As far as I can tell, all the symbol
> versioning information is gone.  The RPM dependencies are correct, but
> the ABI is not. 8-p

Doh, yes, it didn't even occur to me to check the actual symbol versioning
in the library :-(

> configure.ac has this:
> 
> AC_MSG_CHECKING([for asm .symver support])
> AC_COMPILE_IFELSE([dnl
> AC_LANG_PROGRAM([[]],[[
> int f1() { }
> int f2() { }
> asm(".symver f1, f@VER1");
> asm(".symver f2, f@@VER2");
> int main(int argc, char **argv) { }
> ]])dnl
> ],[
> AC_DEFINE([HAVE_ASM_SYMVERS],1,[Define if there is asm .symver 
> support.])
> VERSIONMAPLDFLAGS="-Wl,--version-script=\$(srcdir)/libgphoto2.ver"
> AC_MSG_RESULT(yes)
> ],[
> VERSIONMAPLDFLAGS=""
> AC_MSG_RESULT(no)
> ])
> AC_SUBST(VERSIONMAPLDFLAGS)
> 
> And build.log shows:
> 
> checking for asm .symver support... no
> 
> The HAVE_ASM_SYMVERS macro is apparently unused, but setting
> VERSIONMAPLDFLAGS looks *very* relevant.
> 
> The cause seems to be this:
> 
> /tmp/ccAbnnro.s: Assembler messages:
> /tmp/ccAbnnro.s: Error: invalid attempt to declare external version name
> as default in symbol `f@@VER2'
> 
> It's LTO-related in the sense that f1 & f2 get different symbols with
> LTO.  This fixes the test:
> 
> int __attribute__ ((externally_visible)) f1() { }
> int __attribute__ ((externally_visible)) f2() { }
> asm(".symver f1, f@VER1");
> asm(".symver f2, f@@VER2");
> int main(int argc, char **argv) { }

This didn't work, because the problem was slightly more subtle...

This AC_LANG_PROGRAM call puts the code snippet inside a main() { ...}
so what configure was actually attempting to compile is:

 int
 main ()
 {
 
   int f1() { }
   int f2() { }
   asm(".symver f1, f@VER1");
   asm(".symver f2, f@@VER2");
   int main(int argc, char **argv) { }
 
   ;
   return 0;
 }


clearly this code is nonsense, but by luck it still worked until newer
GCC came along.

The code has to be passed as the first arg of AC_LANG_PROGRAM, not the
second arg, so that its outside the main() {...}

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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

neuro-sig COPR group clean up

2020-08-06 Thread Ankur Sinha

Hello,

We've got quite a few unmaintained repos on COPR under the neuro-sig
group.  I intend to do a bit of housekeeping to remove projects there
that aren't in use any more. Please take a look and let me know if you
do not want me to delete a project:

https://copr.fedorainfracloud.org/groups/g/neurofedora/coprs/

I will delete all projects apart from the neurofedora-extra copr on
Monday, the 10th of August.

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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

CPE Feedback Survey

2020-08-06 Thread Ant Carroll

CPE  need your help :)

Over the last several months we've been trying to improve how we interact
and share information with you all. From the blog posts, to mails and how
we work on the tickets you send us.

Here is a link to a very short survey we've put together to learn how we
can give you the best experience possible going forward by understanding
the experiences you've had recently.
If you could take the time (5mins max) to complete it for us it would be
hugely valuable as we work on this continuous improvement -
https://fedoraproject.limequery.com/696793?lang=en



Cheers,

Ant
-- 

Ant Carroll

Associate Manager, Software Engineering

Red Hat Waterford 

Communications House

Cork Road, Waterford City

ancar...@redhat.com
M: +353876213163 IM: ancarrol
@redhatjobs    redhatjobs
 @redhatjobs


___
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

Proposing a new Perl Module Versioning Scheme

2020-08-06 Thread Tina Müller


Hi,

I'm working at SUSE, and for about a year I have been in charge of updating
the CPAN modules in SUSE Open Build Service:
https://build.opensuse.org/project/show/devel:languages:perl

This is half automated. The spec file is generated with the cpanspec script,
and we manually look over the diff and then request the package to be updated.

I would like to make a suggestion and will explain the problems in detail, so
that we are all on the same page.

# Status Quo

As you probably know, the versioning scheme of Perl modules differs from rpm.
For perl, the versions are decimal, so it can happen that for a given module A
versions 0.23 and 0.3 are released. The latter one is higher for perl.
Semantically, 0.23 is 0.230.0 and 0.3 is 0.300.0, when correctly translated to a
rpm like version.

You can also use versions like 1.2.3 in perl. In that case, they are already
semantically equal to rpm like versions. The majority of perl modules still uses
decimal versions, though.

Many distributions including openSUSE and Fedora are just taking over the perl
module version literally.

This sometimes leads to problems, for example if module B requires module A:

Requires: perl(A) >= 0.23

When module A is uploaded with version 0.3, this will result in an unresolvable
dependency.

In those cases we have to manually fix the requirement.
Granted, this doesn't happen very often, but when, it's annoying.

There might also be cases where it is the other way around, e.g. module A
has versions 0.02 and 0.1. 0.02 is just the same as 0.2 in rpm.

Module B has:

Requires: perl(A) >= 0.1

If module A is still at version 0.02, the dependency will be satisfied,
because 0.1 is lower in rpm than 0.02.
But that is wrong. In this case we don't see the mistake though.

Here is a discussion about this that started when I posted my Howto
for creating a CPAN module with correct Metadata:
https://github.com/perlpunk/perl5-module-meta/issues/5

# Alternative

The correct way to translate the versions for the spec would be:

perl -wE'say version->parse($ARGV[0])->normal;' 0.23
v0.230.0

and then we just have to cut off the 'v' at the beginning.
This should work correctly for all module versions, and it is the right thing
to do.
We wouldn't need any manual handling anymore.

# Problem

As it is impossible to just change all modules in the distributions at the same
time, we need backwards compatibility.

# Proposal

I discussed this on IRC #opensuse-factory. A suggestion came up how to avoid
having to be backward compatible.

The versions of each module inside a CPAN distribution are usually generated
at build time with perl.prov
(https://github.com/rpm-software-management/rpm/blob/master/scripts/perl.prov).

Some distributions also use
https://github.com/rpm-software-management/rpm/blob/master/scripts/perl.req
but openSUSE doesn't. The dependencies are extracted at the time when the spec
file is generated.

We could add a new capability additionally to perl(). Maybe cpan(). This can
use the new versioning scheme.
The packages could be built with both capabilities.
As soon as all packages are rebuilt, we can start to adjust the Requires
lines to use the new capability.

This part is actually pretty easy and shouldn't require much work. Please
correct me if I'm wrong.

However, there is also the package version, and instead of

Require: perl(A::B) >= x.y

one can do

Require: perl-A-B >= x.y

so for those package versions we need backward compatibility.

My idea is to take a snapshot of all CPAN modules we have in our repository
and save the package id and the version.

The migration strategy to the new versioning scheme would be:

All modulues having 1, 2 or 3 decimals can update to the new scheme whenever
a new version is uploaded.

Let's take module A as the example again. The current (CPAN) version would be
0.23.

When a new version 0.3 is uploaded, we compare the version for A to our saved
version 0.23. If it is (decimally) higher, we use the new scheme: 0.300.0.
Same thing for other modules requiring A (although we mostly use capability
requirements anyway).

For all modules having 4 or more decimals, the switch to the version scheme
has to wait until the major version is updated (which might be never for some
modules).
E.g. module B has 1.201703. Then we have to wait until the major version is
incremented to 2.

I made some statistics for our devel:languages:perl repo to see how many
decimals the packages have:

a:   21
a.b:120
a.bb:  2045
a.bbb:  497
a.: 100
a.b: 25
a.bb:   165
a.bbb+:  11
a.b.c+: 129

So the large majority uses 3 or less decimals.

I know the second part is a lot of work, and it feels it comes a bit too
late, considered how long perl has been around. OTOH perl will probably
stay around for a while.

What do you think? Do you think it's worth it? Are there any flaws in my
migration strategy? Or do you have alternative suggestions?

Would be

[Bug 1802607] perl-Net-DNS-1.26 is available

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



--- Comment #12 from Upstream Release Monitoring 
 ---
An unexpected error occurred while creating the scratch build and has been
automatically reported. Sorry!


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1802607] perl-Net-DNS-1.26 is available

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Net-DNS-1.25 is|perl-Net-DNS-1.26 is
   |available   |available



--- Comment #11 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.26
Current version/release in rawhide: 1.21-2.fc32
URL: http://search.cpan.org/dist/Net-DNS/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/3147/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Test machines for s390x?

2020-08-06 Thread Dan Horák

On Wed, 5 Aug 2020 21:21:02 -0700
Kevin Fenzi  wrote:

> On Wed, Aug 05, 2020 at 11:26:34PM -0400, Elliott Sales de Andrade wrote:
> > 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?
> 
> Sorry, not with the current setup. ;( 
> 
> I'll keep an eye out for any possiblity tho... I'd love to be able to
> provide one. 
> 
> I think there may be a way to get access to a guest from ibm though. 
> (I'll let folks who know about that chime in here though)

Kevin, shall I try to get a guest from Marist we could use as the stable
test/devel machine? Like we do with the ppc64le machine from the
OpenPOWER hub.


Dan
___
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 configs for the future-branched F33 (on 2020-08-11)

2020-08-06 Thread Pavel Raiskup

Hey all,

we just wrapped a new update for mock-core-configs + distribution-gpg-keys
that include configuration (configs + gpg keys) for F34:

  https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f1032de02
  https://bodhi.fedoraproject.org/updates/FEDORA-2020-1ec390d120
  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-63b3437a0e

I believe that it's better to have those configs in stable before we do
actual branching [1] on Tuesday.  Those packages should allow an
uninterrupted work with mock during branching period ...  The only problem
is -- when it gets to stable too soon -- that the fedora-34/rawhide-x86_64
chroot will actually build with '%dist .fc33'.  At least as long as there
will be no problems with F34 composes, we should be fine.

[1] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html

Pavel


___
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: Test machines for s390x?

2020-08-06 Thread Chris Murphy

On Wed, Aug 5, 2020 at 9:27 PM Elliott Sales de Andrade
 wrote:
>
> 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.

ARM defaults to little-endian, but also supports big-endian. However I
have no idea to what degree there's software support for big-endian
ARM.


-- 
Chris Murphy
___
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: Respinning rawhide images every filesystem update?

2020-08-06 Thread Alex Scheel

- Original Message -
> From: "Stephen John Smoogen" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, August 6, 2020 10:55:51 AM
> Subject: Re: Respinning rawhide images every filesystem update?
> 
> On Thu, 6 Aug 2020 at 10:05, Alex Scheel  wrote:
> >
> > - Original Message -
> > > From: "Stephen John Smoogen" 
> > > To: "Development discussions related to Fedora"
> > > , asch...@redhat.com
> > > Sent: Thursday, August 6, 2020 9:55:17 AM
> > > Subject: Re: Respinning rawhide images every filesystem update?
> > >
> > > On Thu, 6 Aug 2020 at 09:36, Alex Scheel  wrote:
> > > >
> > > > I'm bumping this thread. This is still broken.
> > > >
> > >
> > > Please open a ticket at
> > > https://pagure.io/fedora-infrastructure/new_issue and open new issue
> > > with an explanation of what is broken and where you are pulling from.
> > > If it is a fedora registry then infrastructure can work on a fix. If
> > > it is from docker.io or quay or elsewhere we can try to find the
> > > people who fix it and let them know.
> >
> > Opened:
> >
> > https://pagure.io/fedora-infrastructure/issue/9208
> >
> > This was also posted to devel to hopefully get the attention of the
> > filesystem maintainer.
> >
> >
> > They seem to have ignored 1548403 since 2018. :-)
> >
> >
> 
> OK so this ticket clarifies the problem because I thought this was a
> problem with the filesystem in the container image with how it is spun
> or delivered. It is instead with the package filesystem. Here is the
> ticket contents (since most people don't follow links in emails).

There's three ways to solve this:

 1) Make the filesystem upgrade nicely in a container, or
 2) Have the container runtime/user namespace system/... support the
type of change that upgrading the filesystem package makes, or
 3) Just respin the container image quickly whenever this happens; this
hides the problem from users without solving the problem.

1 isn't happening because the maintainer isn't involved.
2 isn't happening because the container runtime maintainers punted on it.
3 is the easiest left to accomplish.


If I had a choice, I'd be really happy with 3. I don't know what
all is involved to respin container images with a new package. I'm 
sure it takes time, but I'd imagine it'd be mostly automated. The
problem gets fixed eventually anyways.

- Alex

(Arguably there is 4, quit rebuilding the filesystem package needlessly,
 but we seem to like mass-rebuilds of all packages, and it might set a
 weird precedence if we special case things). 

> filesystem package breaks Fedora containers because dnf cannot
> successfully update the package. See:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1548403
> https://bugzilla.redhat.com/show_bug.cgi?id=1708249
> 
> Every time filesystem updates, it causes this problem. The solution is
> to rebuild Fedora containers with the new filesystem package upgrade,
> so dnf upgrade will already have the updated filesystem package.
> 
> Alternatively, the filesystem maintainer could make their package
> container friendly.
> 
> This is from the main Fedora registry:
> 
> [ascheel@ascheel-p50 ~]$ podman run -ti
> registry.fedoraproject.org/fedora:rawhide /bin/bash
> [root@5808bc88f6ab /]# dnf update --refresh -y
> Fedora 33 openh264 (From Cisco) - x86_64  6.9 kB/s | 5.1 kB 00:00
> Fedora - Modular Rawhide - Developmental pack 2.6 MB/s | 3.1 MB 00:01
> Fedora - Rawhide - Developmental packages for  17 MB/s |  73 MB 00:04
> Dependencies resolved.
> ==
>  Package Arch   Version Repo Size
> ==
> Upgrading:
> 
> 
> 
>  filesystem  x86_64 3.14-3.fc33 rawhide 1.1 M
> 
> 
> 
>   Upgrading: filesystem-3.14-3.fc33.x86_64  3/341
> Error unpacking rpm package filesystem-3.14-3.fc33.x86_64
> 
> 
> 
> Failed:
>   filesystem-3.14-2.fc32.x86_64 filesystem-3.14-3.fc33.x86_64
> 
> Error: Transaction failed
> 
> 
> --
> Stephen J Smoogen.
> ___
> 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:

Re: What do to about massive # of FTBFS bugs?

2020-08-06 Thread Fabio Valentini

On Thu, Aug 6, 2020 at 4:51 PM Jeff Law  wrote:
>
> On Thu, 2020-08-06 at 06:17 -0500, Richard Shaw wrote:
> > On Thu, Aug 6, 2020 at 5:08 AM Fabio Valentini  wrote:
> > > I'd say it's pretty safe to submit things to rawhide again. I haven't
> > > seen any lingering buildroot issues for the past 2-3 days, except for
> > > some longer wait/build times in koji due to batched ELN build
> > > submissions (but those are finished now too).
> >
> > Ok, good deal. I've been trying to knock out 2-3 packages a day so I'll get 
> > to the bottom of the pile in a week or so :)
> I'm maybe 40% of the way through the failures looking for things that are
> obviously LTO related and reassigning those to myself.
>
> Based on what I've seen the cmake stuff is still the most common failure.  
> I've
> still seen a few s390x infrastructure issues.  Lots of noarch packages that 
> have
> failed (haven't looked at those at all since they can't be LTO failures).

When resubmitting failures caused by intermittent and infra issues, I
came across a few of those "lto-wrapper failures" on some arches as
well.
I can compile a list, if it helps.

I also think LTO can definitely cause issues in noarch builds, if
mis-compiled archful dependency crashes during the build.

Fabio
___
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: vim has lost it's damn mind

2020-08-06 Thread John Florian

On 2020-07-28 17:09, John Florian wrote:
>
> I also have seen some weirdness of late, but I'm still on F31.  I had
> yaml files indented with sw=4 and my foldmethod=indent.  Now I have to
> open the fold twice, once for the invisible fold that seems to be
> implied as if sw=2 and one more to get the real thing.  If I reformat
> to use 2-space indents the folding works like I'd expect but something
> changed.  I've also gotten lots of pain with certain key combos that
> were solid for ages.  Ctrl-6 to swap buffers % and # now must be
> Ctrl-Shift-6 for vim, though the former still works in gvim.  I have a
> mapping for  :nohlsearch that I've used for over a decade to
> un-highlight a search.  That no longer works in vim or gvim.  Until
> I'd found that I figured something in konsole had changed.  But once
> gvim revealed weird issues I figured it must be more of a vim thing.
> Now seeing this message, I'm becoming even more certain.
>
I understand better now my problems with my mappings.  Above, I said I
had a mapping for  :nohlsearch.  In actuality, this was ^E
:nohlsearch.  Both should work but only the latter now only works
with vim; gvim shows the mapping with :map but I can't make it trigger.

I still don't know what's up with the yaml indenting.  I'll have to
check on the cindent setting that's been brought up recently.  I also
don't understand the new Ctrl-6 behavior, but I suspect that's konsole
that's changed.


John Florian

___
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: InsightToolkit LTO build failure

2020-08-06 Thread Stephen Gallagher

On Thu, Aug 6, 2020 at 10:05 AM Orion Poplawski  wrote:
>
> InsightToolkit fails to build with LTO:
>
> /usr/bin/ld.gold: fatal error: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> gmake[2]: ***
> [Modules/Filtering/ImageIntensity/test/CMakeFiles/ITKImageIntensityTestDriver.dir/build.make:1307:
> bin/ITKImageIntensityTestDriver] Error 1
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48777433
>
> I'm disabling for now.  Let me know where I should file a bug if needed.
>

That looks like the same bug I reported as
https://bugzilla.redhat.com/show_bug.cgi?id=1866012
___
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: InsightToolkit LTO build failure

2020-08-06 Thread Jakub Jelinek

On Thu, Aug 06, 2020 at 09:13:02AM -0600, Jeff Law wrote:
> On Thu, 2020-08-06 at 17:04 +0200, Jakub Jelinek wrote:
> > On Thu, Aug 06, 2020 at 09:01:16AM -0600, Jeff Law wrote:
> > > No need to file a bug right now.  Once we're past the mass rebuild we'll 
> > > review
> > > everything that's opted out and see what upstream actions need to be 
> > > taken.
> > > 
> > > Note that it appears this package is using the "gold" linker.  That's been
> > > deprecated upstream, so you might want to look at transitioning away to 
> > > either
> > > ld.bfd or lld.
> > 
> > lld doesn't support linker plugins, does it?  So I don't see how it can be
> > an option for GCC LTO.
> ?!?  Tom would know for sure, of course.

At least ld.lld --help says:
  --plugin=Ignored for compatibility with GNU linkers

Jakub
___
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: [regression]Blender gets broken python detection with cmake

2020-08-06 Thread Silvia Sánchez

Hello,

Any news on this?

Regards,
Lailah



On Fri, 24 Jul 2020 at 08:04, Luya Tshimbalanga 
wrote:

> Hello team,
>
> It looks like something broke inside cmake when attempting to detect
> python:
>
> CMake Error at 
> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:164 (message):
>   Could NOT find PythonLibsUnix (missing: PYTHON_LIBRARY PYTHON_LIBPATH
>   PYTHON_INCLUDE_DIR PYTHON_INCLUDE_CONFIG_DIR)
> Call Stack (most recent call first):
>   /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:445 
> (_FPHSA_FAILURE_MESSAGE)
>   build_files/cmake/Modules/FindPythonLibsUnix.cmake:180 
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>   build_files/cmake/platform/platform_unix.cmake:99 (find_package)
>   CMakeLists.txt:812 (include)
> -- Configuring incomplete, errors occurred!
> See also 
> "/builddir/build/BUILD/blender-2.83.3/build/CMakeFiles/CMakeOutput.log".
>
>
>
> Can someone investigate the issue?
>
> Reference: https://koji.fedoraproject.org/koji/taskinfo?taskID=47730766
>
> Thanks
>
> --
> Luya Tshimbalanga
> Fedora Design Team
> Fedora Design Suite maintainer
>
> ___
> 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: InsightToolkit LTO build failure

On Thu, 2020-08-06 at 17:04 +0200, Jakub Jelinek wrote:
> On Thu, Aug 06, 2020 at 09:01:16AM -0600, Jeff Law wrote:
> > No need to file a bug right now.  Once we're past the mass rebuild we'll 
> > review
> > everything that's opted out and see what upstream actions need to be taken.
> > 
> > Note that it appears this package is using the "gold" linker.  That's been
> > deprecated upstream, so you might want to look at transitioning away to 
> > either
> > ld.bfd or lld.
> 
> lld doesn't support linker plugins, does it?  So I don't see how it can be
> an option for GCC LTO.
?!?  Tom would know for sure, of course.

jeff
___
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: Lost ELF library auto-provides since mass rebuild

On Thu, 2020-08-06 at 17:04 +0200, Florian Weimer wrote:
> * Daniel P. Berrangé:
> 
> > This is in relation to this bug
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1862745
> > 
> > The last but one build of libgphoto have auto-provides for the ELF
> > libraries:
> > 
> > libgphoto2 = 2.5.24-2.fc33
> > libgphoto2(x86-64) = 2.5.24-2.fc33
> > libgphoto2.so.6()(64bit)
> > libgphoto2_port.so.12()(64bit)
> > libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit)
> > libgphoto2_port.so.12(LIBGPHOTO2_INTERNAL)(64bit)
> > 
> > any new build both in the mass rebuild and any scratch builds I try
> > looses some of these auto deps leaving just
> > 
> > libgphoto2 = 2.5.24-3.fc33
> > libgphoto2(x86-64) = 2.5.24-3.fc33
> > libgphoto2.so.6()(64bit)
> > libgphoto2_port.so.12()(64bit)
> > 
> > 
> > Was there any change people are aware of that would explain this and
> > suggest what we need todo to get these deps back in libghoto ?
> 
> I think this isn't the real issue.  As far as I can tell, all the symbol
> versioning information is gone.  The RPM dependencies are correct, but
> the ABI is not. 8-p
> 
> configure.ac has this:
> 
> AC_MSG_CHECKING([for asm .symver support])
> AC_COMPILE_IFELSE([dnl
> AC_LANG_PROGRAM([[]],[[
> int f1() { }
> int f2() { }
> asm(".symver f1, f@VER1");
> asm(".symver f2, f@@VER2");
> int main(int argc, char **argv) { }
> ]])dnl
> ],[
> AC_DEFINE([HAVE_ASM_SYMVERS],1,[Define if there is asm .symver 
> support.])
> VERSIONMAPLDFLAGS="-Wl,--version-script=\$(srcdir)/libgphoto2.ver"
> AC_MSG_RESULT(yes)
> ],[
> VERSIONMAPLDFLAGS=""
> AC_MSG_RESULT(no)
> ])
> AC_SUBST(VERSIONMAPLDFLAGS)
> 
> And build.log shows:
> 
> checking for asm .symver support... no
> 
> The HAVE_ASM_SYMVERS macro is apparently unused, but setting
> VERSIONMAPLDFLAGS looks *very* relevant.
> 
> The cause seems to be this:
> 
> /tmp/ccAbnnro.s: Assembler messages:
> /tmp/ccAbnnro.s: Error: invalid attempt to declare external version name
> as default in symbol `f@@VER2'
> 
> It's LTO-related in the sense that f1 & f2 get different symbols with
> LTO.  This fixes the test:
> 
> int __attribute__ ((externally_visible)) f1() { }
> int __attribute__ ((externally_visible)) f2() { }
> asm(".symver f1, f@VER1");
> asm(".symver f2, f@@VER2");
> int main(int argc, char **argv) { }
> 
> Not sure this was missed by Jeff's config.log differ.  Maybe its
> binutils version was too old?
This package needs to opt-out of LTO.

libgphoto2 passed its control and LTO builds as well as the config.h check.  So
I'm not sure what went wrong here.

jeff

___
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: InsightToolkit LTO build failure

2020-08-06 Thread Jakub Jelinek

On Thu, Aug 06, 2020 at 09:01:16AM -0600, Jeff Law wrote:
> No need to file a bug right now.  Once we're past the mass rebuild we'll 
> review
> everything that's opted out and see what upstream actions need to be taken.
> 
> Note that it appears this package is using the "gold" linker.  That's been
> deprecated upstream, so you might want to look at transitioning away to either
> ld.bfd or lld.

lld doesn't support linker plugins, does it?  So I don't see how it can be
an option for GCC LTO.

Jakub
___
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: Lost ELF library auto-provides since mass rebuild

* Daniel P. Berrangé:

> This is in relation to this bug
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1862745
>
> The last but one build of libgphoto have auto-provides for the ELF
> libraries:
>
> libgphoto2 = 2.5.24-2.fc33
> libgphoto2(x86-64) = 2.5.24-2.fc33
> libgphoto2.so.6()(64bit)
> libgphoto2_port.so.12()(64bit)
> libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit)
> libgphoto2_port.so.12(LIBGPHOTO2_INTERNAL)(64bit)
>
> any new build both in the mass rebuild and any scratch builds I try
> looses some of these auto deps leaving just
>
> libgphoto2 = 2.5.24-3.fc33
> libgphoto2(x86-64) = 2.5.24-3.fc33
> libgphoto2.so.6()(64bit)
> libgphoto2_port.so.12()(64bit)
>
>
> Was there any change people are aware of that would explain this and
> suggest what we need todo to get these deps back in libghoto ?

I think this isn't the real issue.  As far as I can tell, all the symbol
versioning information is gone.  The RPM dependencies are correct, but
the ABI is not. 8-p

configure.ac has this:

AC_MSG_CHECKING([for asm .symver support])
AC_COMPILE_IFELSE([dnl
AC_LANG_PROGRAM([[]],[[
int f1() { }
int f2() { }
asm(".symver f1, f@VER1");
asm(".symver f2, f@@VER2");
int main(int argc, char **argv) { }
]])dnl
],[
AC_DEFINE([HAVE_ASM_SYMVERS],1,[Define if there is asm .symver 
support.])
VERSIONMAPLDFLAGS="-Wl,--version-script=\$(srcdir)/libgphoto2.ver"
AC_MSG_RESULT(yes)
],[
VERSIONMAPLDFLAGS=""
AC_MSG_RESULT(no)
])
AC_SUBST(VERSIONMAPLDFLAGS)

And build.log shows:

checking for asm .symver support... no

The HAVE_ASM_SYMVERS macro is apparently unused, but setting
VERSIONMAPLDFLAGS looks *very* relevant.

The cause seems to be this:

/tmp/ccAbnnro.s: Assembler messages:
/tmp/ccAbnnro.s: Error: invalid attempt to declare external version name
as default in symbol `f@@VER2'

It's LTO-related in the sense that f1 & f2 get different symbols with
LTO.  This fixes the test:

int __attribute__ ((externally_visible)) f1() { }
int __attribute__ ((externally_visible)) f2() { }
asm(".symver f1, f@VER1");
asm(".symver f2, f@@VER2");
int main(int argc, char **argv) { }

Not sure this was missed by Jeff's config.log differ.  Maybe its
binutils version was too old?

Thanks,
Florian
___
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: InsightToolkit LTO build failure

On Thu, 2020-08-06 at 08:03 -0600, Orion Poplawski wrote:
> InsightToolkit fails to build with LTO:
> 
> /usr/bin/ld.gold: fatal error: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> gmake[2]: *** 
> [Modules/Filtering/ImageIntensity/test/CMakeFiles/ITKImageIntensityTestDriver.dir/build.make:1307:
>  
> bin/ITKImageIntensityTestDriver] Error 1
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48777433
> 
> I'm disabling for now.  Let me know where I should file a bug if needed.
No need to file a bug right now.  Once we're past the mass rebuild we'll review
everything that's opted out and see what upstream actions need to be taken.

Note that it appears this package is using the "gold" linker.  That's been
deprecated upstream, so you might want to look at transitioning away to either
ld.bfd or lld.

Thanks,
jeff
___
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: Respinning rawhide images every filesystem update?

2020-08-06 Thread Stephen John Smoogen

On Thu, 6 Aug 2020 at 10:05, Alex Scheel  wrote:
>
> - Original Message -
> > From: "Stephen John Smoogen" 
> > To: "Development discussions related to Fedora" 
> > , asch...@redhat.com
> > Sent: Thursday, August 6, 2020 9:55:17 AM
> > Subject: Re: Respinning rawhide images every filesystem update?
> >
> > On Thu, 6 Aug 2020 at 09:36, Alex Scheel  wrote:
> > >
> > > I'm bumping this thread. This is still broken.
> > >
> >
> > Please open a ticket at
> > https://pagure.io/fedora-infrastructure/new_issue and open new issue
> > with an explanation of what is broken and where you are pulling from.
> > If it is a fedora registry then infrastructure can work on a fix. If
> > it is from docker.io or quay or elsewhere we can try to find the
> > people who fix it and let them know.
>
> Opened:
>
> https://pagure.io/fedora-infrastructure/issue/9208
>
> This was also posted to devel to hopefully get the attention of the
> filesystem maintainer.
>
>
> They seem to have ignored 1548403 since 2018. :-)
>
>

OK so this ticket clarifies the problem because I thought this was a
problem with the filesystem in the container image with how it is spun
or delivered. It is instead with the package filesystem. Here is the
ticket contents (since most people don't follow links in emails).

filesystem package breaks Fedora containers because dnf cannot
successfully update the package. See:

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

Every time filesystem updates, it causes this problem. The solution is
to rebuild Fedora containers with the new filesystem package upgrade,
so dnf upgrade will already have the updated filesystem package.

Alternatively, the filesystem maintainer could make their package
container friendly.

This is from the main Fedora registry:

[ascheel@ascheel-p50 ~]$ podman run -ti
registry.fedoraproject.org/fedora:rawhide /bin/bash
[root@5808bc88f6ab /]# dnf update --refresh -y
Fedora 33 openh264 (From Cisco) - x86_64  6.9 kB/s | 5.1 kB 00:00
Fedora - Modular Rawhide - Developmental pack 2.6 MB/s | 3.1 MB 00:01
Fedora - Rawhide - Developmental packages for  17 MB/s |  73 MB 00:04
Dependencies resolved.
==
 Package Arch   Version Repo Size
==
Upgrading:



 filesystem  x86_64 3.14-3.fc33 rawhide 1.1 M



  Upgrading: filesystem-3.14-3.fc33.x86_64  3/341
Error unpacking rpm package filesystem-3.14-3.fc33.x86_64



Failed:
  filesystem-3.14-2.fc32.x86_64 filesystem-3.14-3.fc33.x86_64

Error: Transaction failed


-- 
Stephen J Smoogen.
___
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: What do to about massive # of FTBFS bugs?

On Thu, 2020-08-06 at 06:17 -0500, Richard Shaw wrote:
> On Thu, Aug 6, 2020 at 5:08 AM Fabio Valentini  wrote:
> > I'd say it's pretty safe to submit things to rawhide again. I haven't
> > seen any lingering buildroot issues for the past 2-3 days, except for
> > some longer wait/build times in koji due to batched ELN build
> > submissions (but those are finished now too).
> 
> Ok, good deal. I've been trying to knock out 2-3 packages a day so I'll get 
> to the bottom of the pile in a week or so :)
I'm maybe 40% of the way through the failures looking for things that are
obviously LTO related and reassigning those to myself.

Based on what I've seen the cmake stuff is still the most common failure.  I've
still seen a few s390x infrastructure issues.  Lots of noarch packages that have
failed (haven't looked at those at all since they can't be LTO failures).


Jeff
___
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: Proposed Modular Policy for Fedora ELN

On 05. 08. 20 21:36, Stephen Gallagher wrote:

FESCo has requested that I submit the module policy once more to the
Fedora development list for discussion. Feedback is welcome.

== Requirements for Default Streams
* Default streams are not permitted in Fedora or EPEL 8. Fedora ELN
permits defaults streams that adhere to the policy below.

Since this has been discussed at lengths at FESCo and this is the first time it
has been brought here (thanks for doing it, Stephen), let me summarize my
concerns with allowing default modular streams in ELN.

I would like to know if my concerns are valid or if I am just biased. Sorry for
the long email.

Fedora has experimented with default modular streams for several releases and we
seemed to be at an agreement that the experiment has failed:

See https://pagure.io/fesco/issue/2406 which includes links to relevant previous
discussions on the topic. Admitting that default modular streams are bad took as
nearly two years, despite a few loud and persistent individuals pointing it out
since the beginning.

While I understand the original idea behind the concept of default modular
streams concept, shipping defaults via non-modular content has been proven
superior to default modular streams -- it has been proven that default modular
streams cannot be better than nonmodular defaults and that they can only try to
be as good as them, while they are currently technologically failing to do that:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D2LQ6C6FHDS2LMKPDGCLFJDNHAPA6Q2B/

The currently proposed modularity objective for Fedora admits that this won't be
fixed until ta least Fedora 35 and later:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RF4GUWFIDIASBDKS2RUVDHTSAWCMCWL4/

The current modularity tech-lead strongly discourages default modular streams:

https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122310
https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122502

Yet despite all this, we got a proposal to allow default modular streams in ELN.
The messaging about this proposal suggests that later, default modular streams
might be proposed for Fedora as well.

"""At present, these rules will apply only to Fedora ELN, but are written in
such a way as to be reusable for Fedora and EPEL in the future through another
Change Proposal.""" -- https://fedoraproject.org/wiki/Changes/ModularPolicy

Fedora has decided that default modular streams are no-go. While I admit that
such a decision can be reverted at any time based on significant changes in the
technology, such changes have not happened and are not planned. Yet strong
supporters of default modular streams try to allow them again and again, despite
the enormous amount of feedback they've received including the feedback from the
current modularity team and tech lead.

I sincerely don't understand the RHEL's need for default modular streams, but
when I tried to query the motivation behind this, the answers haven't made it
any better:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YIUXL2AWY3GKITU4TBUSKL2IUHDUPB26/

The idea that we let the maintainers decide how they want to ship the default
content is exactly what failed in Fedora in the first place. But if RHEL people
feel strongly that we need default modular steams to succeed, so be it. What I
don't understand is why do we need this in Fedora (ELN). It boils down to this:
Is ELN part of Fedora and should it follow Fedora's feedback and Fedora's
opinions, or is it a RHEL project executed in the open, with decisions made
behind closed doors?

I've heard several times that we need to have default modular streams in Fedora
ELN to have a place to test them. In my opinion, we had this place, it was in
Fedora, we have tested them and they failed. Hence I don't understand what's
more there to test.

OTOH, why don't just let the ELN SIG do this if it doesn't affect "Fedora
proper"? Because I think it does. Since the beginning of the ELN project, it has
been said that it ships Fedora rawhide content, built differently. Yet if we
ship the default modular streams content in Fedora ELN and the nonmodular
defaults in Fedora Rawhide, suddenly we ship different things, unless we have
technical means to ensure the content is synchronized.

When the ELN proposal was discussed, several package maintainers (both from
Fedora and RHEL) proposed to have an eln branch. It received a big NO because
the content would diverge and keeping it in sync would be (close to) impossible.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/44MCFHOFORTPNJFGK6JJ6YMAHFUT7QG3/
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WRJNM7I5TFQ5TEBOUKKH757K5ME3I47F/
..and many times more...

Fedora ELN should not be a fork. Yet (some of the) default content of

Re: Driverless scanning for WSD and ESCL supported scanners is coming

2020-08-06 Thread Robert Marcano via devel


On 8/6/20 3:48 AM, Zdenek Dohnal wrote:

On 8/5/20 2:30 PM, Jiří Eischmann wrote:


  Will it be possible to use a Fedora machine as a server, so that I can
have an old scanner connected to it via USB and then shared with other
devices on the local network via those protocols?
That would be neat.

Jiri


Hi Jirka,

IIRC it is possible even now via saned on the server, but saned doesn't
use WSD or ESCL, just simple TCP transfer between client and server.

In practice it looks like - you have a proprietary or sane-backends
supported USB scanner (sane-airscan doesn't work for USB devices), you
set up ACL on saned and setup clients to connect to the server.


From the README, it looks like some manufacturers allow eSCL to work 
over USB too:


  However, most (all?) of the eSCL devices will also work over USB, if
  IPP-over-USB daemon is installed on your computer

and some are even USB only:

  [2]: this device is USB-only, but it works well with the IPP-over-USB
  daemon.

I hope this becomes a trend for non networked scanners too.



sane-airscan is a backend for communication with scanner supporting
WSD/ESCL, it doesn't use those protocols for sharing the device.

Zdenek


___
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


___
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

Segmentation fault (core dumped) doxygen docs/doxygen.cfg when compiling sayonara

Hi,

when compiling sayonara on rawhide, the compilation fails with a problem with 
doxygen:

[100%] Built target sayonara
gmake[1]: Leaving directory 
'/home/martin/rpmbuild/BUILD/sayonara-player-1.6.0-beta6'
/usr/bin/cmake -E cmake_progress_start 
/home/martin/rpmbuild/BUILD/sayonara-player-1.6.0-beta6/CMakeFiles 0
+ doxygen -u docs/doxygen.cfg
warning: Tag 'TCL_SUBST' at line 228 of file 'docs/doxygen.cfg' has become 
obsolete.
 This tag has been removed.
warning: Tag 'PERL_PATH' at line 1990 of file 'docs/doxygen.cfg' has become 
obsolete.
 This tag has been removed.
warning: Tag 'MSCGEN_PATH' at line 2012 of file 'docs/doxygen.cfg' has become 
obsolete.
 This tag has been removed.

Configuration file 'docs/doxygen.cfg' updated.

+ doxygen docs/doxygen.cfg
/var/tmp/rpm-tmp.AhfJ4o: line 64: 78158 Segmentation fault  (core dumped) 
doxygen docs/doxygen.cfg


[1] https://martinkg.fedorapeople.org/ErrorReports/sayonara/sayonara.spec

How can i solve this ?

Regards
Martin
___
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: Respinning rawhide images every filesystem update?

2020-08-06 Thread Alex Scheel

- Original Message -
> From: "Stephen John Smoogen" 
> To: "Development discussions related to Fedora" 
> , asch...@redhat.com
> Sent: Thursday, August 6, 2020 9:55:17 AM
> Subject: Re: Respinning rawhide images every filesystem update?
> 
> On Thu, 6 Aug 2020 at 09:36, Alex Scheel  wrote:
> >
> > I'm bumping this thread. This is still broken.
> >
> 
> Please open a ticket at
> https://pagure.io/fedora-infrastructure/new_issue and open new issue
> with an explanation of what is broken and where you are pulling from.
> If it is a fedora registry then infrastructure can work on a fix. If
> it is from docker.io or quay or elsewhere we can try to find the
> people who fix it and let them know.

Opened:

https://pagure.io/fedora-infrastructure/issue/9208

This was also posted to devel to hopefully get the attention of the
filesystem maintainer.


They seem to have ignored 1548403 since 2018. :-)


- Alex

> 
> Without that information, it is very likely it will stay broken unless
> fixed by accident because no one knows what is meant by 'still broken'
> 
> > - Original Message -
> > > From: "Alex Scheel" 
> > > To: "Development discussions related to Fedora"
> > > 
> > > Sent: Monday, August 3, 2020 2:36:40 PM
> > > Subject: Respinning rawhide images every filesystem update?
> > >
> > > Hey list,
> > >
> > >
> > > How do Fedora rawhide images get respun? Every time filesystem updates,
> > > it causes `dnf update` to fail in a podman container because filesystem
> > > can't be updated in a container. We either need to make sure filesystem
> > > updates  cause rawhide containers to be rebuilt, or figure out how to
> > > ship a container-friendly filesystem package.
> > >
> > >
> > > See:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1548403
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1708249
> > >
> > >
> > > And I'm sure many other discussions.
> > >
> > > - Alex
> > ___
> > 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
> 
> 
> 
> --
> Stephen J Smoogen.
> ___
> 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

InsightToolkit LTO build failure

2020-08-06 Thread Orion Poplawski


InsightToolkit fails to build with LTO:

/usr/bin/ld.gold: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
gmake[2]: *** 
[Modules/Filtering/ImageIntensity/test/CMakeFiles/ITKImageIntensityTestDriver.dir/build.make:1307: 
bin/ITKImageIntensityTestDriver] Error 1


https://koji.fedoraproject.org/koji/taskinfo?taskID=48777433

I'm disabling for now.  Let me know where I should file a bug if needed.

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Respinning rawhide images every filesystem update?

2020-08-06 Thread Stephen John Smoogen

On Thu, 6 Aug 2020 at 09:36, Alex Scheel  wrote:
>
> I'm bumping this thread. This is still broken.
>

Please open a ticket at
https://pagure.io/fedora-infrastructure/new_issue and open new issue
with an explanation of what is broken and where you are pulling from.
If it is a fedora registry then infrastructure can work on a fix. If
it is from docker.io or quay or elsewhere we can try to find the
people who fix it and let them know.

Without that information, it is very likely it will stay broken unless
fixed by accident because no one knows what is meant by 'still broken'

> - Original Message -
> > From: "Alex Scheel" 
> > To: "Development discussions related to Fedora" 
> > 
> > Sent: Monday, August 3, 2020 2:36:40 PM
> > Subject: Respinning rawhide images every filesystem update?
> >
> > Hey list,
> >
> >
> > How do Fedora rawhide images get respun? Every time filesystem updates,
> > it causes `dnf update` to fail in a podman container because filesystem
> > can't be updated in a container. We either need to make sure filesystem
> > updates  cause rawhide containers to be rebuilt, or figure out how to
> > ship a container-friendly filesystem package.
> >
> >
> > See:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1548403
> > https://bugzilla.redhat.com/show_bug.cgi?id=1708249
> >
> >
> > And I'm sure many other discussions.
> >
> > - Alex
> ___
> 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



-- 
Stephen J Smoogen.
___
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: /usr/bin/node: No such file or directory

Many thanks, that solves it.

Regards
Martin
___
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: http response to fedpkg build failure?

2020-08-06 Thread Pierre-Yves Chibon

On Thu, Aug 06, 2020 at 06:46:12AM -0500, Richard Shaw wrote:
>This is a new one for me:
>$ fedpkg build

The key line is this one:

           Sorry!  This service is currently unavailable.

Looks like you've hit koji at a time of an outage.

We had a vpn issue earlier today where everything become unavailable for a few
minutes the time for us to fix it. That could be the cause of this.

Pierre
___
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: Making `ls` colours follow terminal configuration

2020-08-06 Thread Kamil Paral

On Thu, Aug 6, 2020 at 3:25 PM Allan Day  wrote:

> Hi all,
>
> coreutils currently configures `ls` to use 256 colours rather than 16.
> This is a downstream Fedora change which means that `ls` doesn't
> follow the colour palette that's configured in the terminal.
>

It makes sense to synchronize with upstream again. And the fact that ls
didn't follow my configured colors in gnome-terminal was somewhat annoying.
Thumbs up from me.
___
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: Respinning rawhide images every filesystem update?

2020-08-06 Thread Alex Scheel

I'm bumping this thread. This is still broken.

- Original Message -
> From: "Alex Scheel" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, August 3, 2020 2:36:40 PM
> Subject: Respinning rawhide images every filesystem update?
> 
> Hey list,
> 
> 
> How do Fedora rawhide images get respun? Every time filesystem updates,
> it causes `dnf update` to fail in a podman container because filesystem
> can't be updated in a container. We either need to make sure filesystem
> updates  cause rawhide containers to be rebuilt, or figure out how to
> ship a container-friendly filesystem package.
> 
> 
> See:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1548403
> https://bugzilla.redhat.com/show_bug.cgi?id=1708249
> 
> 
> And I'm sure many other discussions.
> 
> - Alex
___
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

Making `ls` colours follow terminal configuration

2020-08-06 Thread Allan Day

Hi all,

coreutils currently configures `ls` to use 256 colours rather than 16.
This is a downstream Fedora change which means that `ls` doesn't
follow the colour palette that's configured in the terminal.

We are therefore planning on removing the downstream customisation, so
that `ls` uses the 16 colour palette, which the user is able to
control through the app. This will make `ls` consistent with other
commands. It will also mean that improvements to the default colour
palette will be seen in ls.

If anyone knows of any issues with this, please comment on the issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1830318

Thanks!

Allan
___
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: arm/neon LTO-related FTBS

2020-08-06 Thread Dominique Martinet

Dominique Martinet wrote on Tue, Aug 04, 2020:
> So I'd really need a way to have only that file compiled with the
> optimisations, and other files without it -- Jeff or someone else, could
> you please advise?

I could still use help with that, please.

To recap, waypipe:
 - compiles a single function in single .c file into a static lib (.a)
with optimisations e.g. `-mavx512f -mlzcnt -mbmi` or `-mfpu=neon`
depending on what the compiler provides.
 - compiles other stuff without these optimisations; the other stuff
knows what has been compiled or not through #ifdefs.
 - link the other stuff with that aforementioned .a
( - at runtime, decides if it is safe or not to run the optimized
function, and only runs it if the hardware supports it -- since the code
that makes the decision is compiled without the optimizations the binary
as a whole should run on whatever we support)


with -flto=auto, the final link step fails with the following:

https://kojipkgs.fedoraproject.org//work/tasks/2576/48362576/build.log
--
gcc  -o test/diff_roundtrip test/diff_roundtrip.p/diff_roundtrip.c.o 
-Wl,--as-needed -Wl,--no-undefined -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 -march=armv7-a -mfpu=vfpv3-d16 
-mtune=generic-armv7-a -mabi=aapcs-linux -mfloat-abi=hard -Wl,-z,relro 
-Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
-Wl,--start-group src/libwaypipe_src.a src/libkernel_neon.a 
protocols/libprotocols.a -pthread -lrt /usr/lib/libgbm.so /usr/lib/liblz4.so 
/usr/lib/libzstd.so -Wl,--end-group 
'-Wl,-rpath,$ORIGIN/../src:$ORIGIN/../protocols' 
-Wl,-rpath-link,/builddir/build/BUILD/waypipe-v0.6.1/armv7hl-redhat-linux-gnueabi/src
 
-Wl,-rpath-link,/builddir/build/BUILD/waypipe-v0.6.1/armv7hl-redhat-linux-gnueabi/protocols
/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/10/include/arm_neon.h: In function 
‘run_interval_diff_neon’:
/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/10/include/arm_neon.h:10426:22: fatal 
error: You must enable NEON instructions
(e.g. ‘-mfloat-abi=softfp’ ‘-mfpu=neon’) to use these intrinsics.
10426 |   return (uint64x2_t)__builtin_neon_vld1v2di ((const __builtin_neon_di 
*) __a);
  |  ^
compilation terminated.
--

where `run_interval_diff_neon`is the optimised function that was
compiled in the first .a with optimization flags




From what I have read it's not possible to mark a function or a file as
"LTO disabled"? Did I get that correctly?
What can I or upstream do about this? I mean, I can disable LTO in the
spec file but what _should_ I do ;)

Is it a bug I should file a gcc bz for or is that a feature I don't
understand?
FWIW I don't have the problem with avx512f, it links just fine.


Thanks,
-- 
Dominique
___
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: Proposal to Add: Log In/Out Blocker Criteria

2020-08-06 Thread Kamil Paral

On Thu, Aug 6, 2020 at 5:47 AM Stephen J. Turnbull 
wrote:

> I'm really uncomfortable about the amount of crossp-posting, so I'm
> limiting this to devel@ (I receive it) and test@ (obvious to me why
> relevant).
>
> Kamil Paral writes:
>  > Adam writes:
>
>  > > Arguably the environment from which they logged in is not
>  > > "working as expected" if you can't then log in as someone else.
>  >
>  > However, the existing basic criterion [1] only requires the *initially*
>  > created user to be able to log in. So if you create a second user, and
>  > can't log in with it after a system boot,
>
> Adam's argument is that this is covered by "working as expected".
>

It's not covered in the situation I described. Adam's quoted criterion only
applies after log out, and so it doesn't apply to secondary users (created
after system installation) which try to log in immediately after system
boot (so there is no previous log out) and it fails.

>
> FWIW, I think that the criterion should be something like
>
> users created by *scripts* as part of a *supported* installation
> or upgrade process and which are documented as able to log in,
> must be able to log in from any condition where login is
> documented to be possible.  Logging out must return the login
> facilities to the state in which log in occurred unless some
> *condition* (such as shutdown in progress) *explicitly* changes
> it.
>

I don't think we should only guarantee login for users created during
installation. That seems very poor QA and I wouldn't want to use a system
in which I can create a user but it can't log in and "it's OK". We should
guarantee login for all users which pass some sanity check (i.e. you create
them using standard tools and approaches and don't do anything horrible to
them). Unlike your proposed criterion (which is very convoluted to cover
those corner cases), I don't think we need to specify them. That's the
point of the blocker meeting, to discuss that particular situation. If
somebody removed their login shell, well, that's clearly not our problem
and not a criterion violation - it doesn't need to be codified. On the
other hand, if a regular system update removed that login shell, that's a
big bummer on our side. I prefer easy-to-understand criteria which might
not cover all corner cases (they'll never will, even if you try), but
convey the intended goal well, and people can then use them as a basis for
decision making (while considering all the circumstances).

I'm not sure what you mean by "documented". I wouldn't rely on Fedora
documentation too much in these cases. So that would mean we'd also need to
create and maintain some lists of "which users are supposed to be able to
log in" and "in which conditions the logins are possible".
___
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: /usr/bin/node: No such file or directory


On 06. 08. 20 14:57, Martin Gansser wrote:

Hi,

when I try to compile nodejs-indexof under rawhide I get the following error 
message [2]

/usr/bin/node: No such file or directory

[1] 
https://src.fedoraproject.org/rpms/nodejs-indexof/blob/master/f/nodejs-indexof.spec
[2] https://kojipkgs.fedoraproject.org//work/tasks/3014/48793014/build.log

How can i solve this ?


Replace:

BuildRequires: nodejs-packaging

With:

BuildRequires: nodejs

See 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/#_buildrequires


--
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: /usr/bin/node: No such file or directory

not really right now, but I thought it would be easy.

Martin
___
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: /usr/bin/node: No such file or directory

2020-08-06 Thread Tom Hughes via devel


On 06/08/2020 13:57, Martin Gansser wrote:


when I try to compile nodejs-indexof under rawhide I get the following error 
message [2]

/usr/bin/node: No such file or directory

[1] 
https://src.fedoraproject.org/rpms/nodejs-indexof/blob/master/f/nodejs-indexof.spec
[2] https://kojipkgs.fedoraproject.org//work/tasks/3014/48793014/build.log

How can i solve this ?


Require nodejs for your build?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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

http response to fedpkg build failure?

This is a new one for me:

$ fedpkg build
Could not execute build: The following error occurred while trying to get
the active release branches in PDC:
http://www.w3.org/TR/html4/strict.dtd;>

Fedora Project

Fedora

Navigation

Home
Get
Fedora
Join
Fedora
Get
Help

Tools

Docs Fedora
documentation.
Wiki Collaborative
knowledge.
Planet The voices of the
Fedora community.
Communicate
Speak with Fedora.
Events
Meet the Fedora community.

Sorry! This service is currently unavailable.
The service that you are trying to access is currently
unavailable. Please try refreshing this page in a couple of minutes. If
you still see this message, then please follow the steps below:

Check on http://status.fedoraproject.org/;>the
status page if there are any known outages for our services.
Check the https://pagure.io/fedora-infrastructure/issues;>fedora-infrastructure
pagure instance for an outage notification.
Ask around in #fedora-admin on irc.freenode.net.
If it is accessible, check the https://docs.pagure.org/infra-docs/sysadmin-guide/sops/outage.html;>Outage
SOP for more information.

2010 Red Hat, Inc. and others. For comments or queries,
please https://fedoraproject.org/wiki/Communicating_and_getting_help;>contact
us.

The Fedora Project is maintained and driven by the community and
sponsored by Red Hat. This is a community maintained site. Red Hat is not
responsible for content.

Sponsors
Legal
Trademark

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

Lost ELF library auto-provides since mass rebuild

2020-08-06 Thread Daniel P . Berrangé

This is in relation to this bug

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

The last but one build of libgphoto have auto-provides for the ELF
libraries:

libgphoto2 = 2.5.24-2.fc33
libgphoto2(x86-64) = 2.5.24-2.fc33
libgphoto2.so.6()(64bit)
libgphoto2_port.so.12()(64bit)
libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit)
libgphoto2_port.so.12(LIBGPHOTO2_INTERNAL)(64bit)

any new build both in the mass rebuild and any scratch builds I try
looses some of these auto deps leaving just

libgphoto2 = 2.5.24-3.fc33
libgphoto2(x86-64) = 2.5.24-3.fc33
libgphoto2.so.6()(64bit)
libgphoto2_port.so.12()(64bit)


Was there any change people are aware of that would explain this and
suggest what we need todo to get these deps back in libghoto ?


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: Proposed Modular Policy for Fedora ELN

2020-08-06 Thread Petr Pisar

On Wed, Aug 05, 2020 at 10:50:59PM -0400, Stephen Gallagher wrote:
> On Wed, Aug 5, 2020 at 6:17 PM James Cassell 
> wrote:
> >
> > On Wed, Aug 5, 2020, at 3:36 PM, Stephen Gallagher wrote:
> > > * If a stream of a module has build-time-only components, all such
> > > components *MUST* be marked as `buildonly: True` in the module
> > > metadata to avoid shipping them to users and polluting their
> > > repository.
> > >
> >
> > Can these be directed to a disabled-by-default build-dep repo of some kind
> > for those trying to do local builds?
> >
> 
> That's not really a policy question, but it's *possible* that we could
> do that as part of the compose. I don't see a lot of reason to do so,
> since a local MBS build will handle it for you and as we establish
> later on, the use of these should be a last resort, not a common
> practice.
> 
These build-only components are handy for running tests after the build.

E.g. a non-build component has upstream tests. They are run at build-time, and
thus the module contains build-only components for performing the test. The
tests are also packaged into a subpackage and the subpackage is filtered from
the module. ("buildonly: true" is only a different form of "filter" modulemd
section.) Later a CI may want to install the subpackage and reproduce the
tests.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

/usr/bin/node: No such file or directory

Hi,

when I try to compile nodejs-indexof under rawhide I get the following error 
message [2]

/usr/bin/node: No such file or directory

[1] 
https://src.fedoraproject.org/rpms/nodejs-indexof/blob/master/f/nodejs-indexof.spec
[2] https://kojipkgs.fedoraproject.org//work/tasks/3014/48793014/build.log

How can i solve this ?

Regards
Martin
___
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: bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-18.eln103 failed to build

2020-08-06 Thread Vít Ondruch


Dne 06. 08. 20 v 11:26 Aleksandra Fedorova napsal(a):
> Hi,
>
> On Thu, Aug 6, 2020 at 5:01 AM Orion Poplawski  wrote:
>> So, I'm getting one of these messages every couple of hours and I'd
>> really rather not.  Who do I need to talk to about it?
> You can talk about it with the ELN SIG [1] or Fedora CI SIG [2]. Mail
> thread on devel works, we recommend to use [ELN] as a tag in the
> subject


Nice, so some ELN folks could finally answer this thread for example:


https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/U4TY26R3S65E474FUKGKB6H4JOCIEITY/


Also, it would be useful if ELN team worked on reducing the amount of
Ruby packages which are regularly rebuilt, it would help to reduce the
amount of notifications I receive.


Vít
___
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: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

2020-08-06 Thread Michal Schorm

I further discussed it with Neil.

We came to a compromise.
We will document this macro and its potential usage, as well as the
warning why and when it shouldn't be used; and an information that it
will be removed in some future Fedora release.

I've made a PR to the Docs [1], we should discuss its wording further there.

Once the PR is accepted, the maintainers will be allowed to use this
macro for the special compatibility reasons we talked about here,
knowing of the drawbacks. (unstable private macro that will be
removed)

[1] https://pagure.io/packaging-committee/pull-request/1012

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Thu, Aug 6, 2020 at 1:13 PM Richard Shaw  wrote:
>
> On Thu, Aug 6, 2020 at 5:35 AM Neal Gompa  wrote:
>>
>> On Thu, Aug 6, 2020 at 6:20 AM Michal Schorm  wrote:
>> >
>> > On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa  wrote:
>> > > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa  wrote:
>> > > > > You are not supposed to use %__cmake_builddir.
>> > >
>> > > It is not documented, and eventually will be removed. So don't rely on
>> > > it. If you want to change the build directory, set %_vpath_builddir
>> > > instead.
>> >
>> > Well, just make it documented ?
>> >
>>
>> The %_vpath_builddir macro is *already* documented:
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/vpath/
>
>
> Ok, that helps, but it's rather non-intuitive that it's not with the CMake 
> packaging guidelines. A link would be nice from there would be nice.
>
> 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
___
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

Summary/Minutes from yesterday's FESCo Meeting (2020-08-05)

=
#fedora-meeting-2: FESCO (2020-08-05)
=


Meeting started by King_InuYasha at 14:03:44 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-08-05/fesco.2020-08-05-14.03.log.html
.



Meeting summary
---
* init process  (King_InuYasha, 14:06:21)

* #2440 F33 System-Wide Change: Patches in Forge macros - Auto macros -
  Detached rpm changelogs  (King_InuYasha, 14:09:43)
  * LINK:
https://src.fedoraproject.org/lookaside/rpm-specs-latest.tar.xz
(nirik, 14:23:20)
  * LINK: https://paste.centos.org/view/f4ffc88f   (sgallagh, 14:24:48)
  * proposal 1: accept #2440 sans detached changelogs (+5, 1, -2)
(King_InuYasha, 15:05:37)
  * proposal 2: accept #2440 with detached changelogs (+0, 1, -7)
(King_InuYasha, 15:07:01)
  * AGREED: : accept #2440 sans detached changelogs, that is detached
changelogs are not allowed for Fedora  (King_InuYasha, 15:07:50)
  * proposal 1: accept #2440 sans detached changelogs (+5, 2, -2)
(King_InuYasha, 15:08:45)
  * AGREED: : accept #2440 sans detached changelogs, that is detached
changelogs are not allowed for Fedora  (King_InuYasha, 15:09:11)

* Next week's chair  (King_InuYasha, 15:09:50)
  * ACTION: mhroncok will chair next meeting  (King_InuYasha, 15:10:29)

* Open Floor  (King_InuYasha, 15:10:36)

* #2452 F33 Self-Contained Change: Policy for Modules in Fedora and
  Fedora ELN  (King_InuYasha, 15:20:16)
  * AGREED: sgallagh will update the policy PR accordingly, notify
devel@, and we'll discuss next week  (King_InuYasha, 15:48:43)

* Open Floor  (King_InuYasha, 15:49:02)

Meeting ended at 15:50:03 UTC.




Action Items

* mhroncok will chair next meeting




Action Items, by person
---
* mhroncok
  * mhroncok will chair next meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* King_InuYasha (117)
* mhroncok (77)
* sgallagh (64)
* zbyszek (47)
* dcantrell (44)
* nirik (29)
* decathorpe (27)
* zodbot (15)
* cverna (10)
* ignatenkobrain (5)
* cyberpear (2)
* Conan_Kudo (0)
* Eighth_Doctor (0)
* Sir_Gallantmon (0)
* Son_Goku (0)
* Pharaoh_Atem (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot




-- 
真実はいつも一つ！/ 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

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

On Thu, Aug 6, 2020 at 7:12 AM Richard Shaw  wrote:
>
> On Thu, Aug 6, 2020 at 5:35 AM Neal Gompa  wrote:
>>
>> On Thu, Aug 6, 2020 at 6:20 AM Michal Schorm  wrote:
>> >
>> > On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa  wrote:
>> > > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa  wrote:
>> > > > > You are not supposed to use %__cmake_builddir.
>> > >
>> > > It is not documented, and eventually will be removed. So don't rely on
>> > > it. If you want to change the build directory, set %_vpath_builddir
>> > > instead.
>> >
>> > Well, just make it documented ?
>> >
>>
>> The %_vpath_builddir macro is *already* documented:
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/vpath/
>
>
> Ok, that helps, but it's rather non-intuitive that it's not with the CMake 
> packaging guidelines. A link would be nice from there would be nice.
>

It is linked from the CMake packaging guidelines page, the hyperlink labeled
"Defining source and build directories" points to that page.




--
真実はいつも一つ！/ 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

Re: What do to about massive # of FTBFS bugs?

On Thu, Aug 6, 2020 at 5:08 AM Fabio Valentini  wrote:

>
> I'd say it's pretty safe to submit things to rawhide again. I haven't
> seen any lingering buildroot issues for the past 2-3 days, except for
> some longer wait/build times in koji due to batched ELN build
> submissions (but those are finished now too).
>

Ok, good deal. I've been trying to knock out 2-3 packages a day so I'll get
to the bottom of the pile in a week or so :)

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: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

On Thu, Aug 6, 2020 at 5:35 AM Neal Gompa  wrote:

> On Thu, Aug 6, 2020 at 6:20 AM Michal Schorm  wrote:
> >
> > On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa  wrote:
> > > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa 
> wrote:
> > > > > You are not supposed to use %__cmake_builddir.
> > >
> > > It is not documented, and eventually will be removed. So don't rely on
> > > it. If you want to change the build directory, set %_vpath_builddir
> > > instead.
> >
> > Well, just make it documented ?
> >
>
> The %_vpath_builddir macro is *already* documented:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/vpath/


Ok, that helps, but it's rather non-intuitive that it's not with the CMake
packaging guidelines. A link would be nice from there would be nice.

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: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

On Thu, Aug 6, 2020 at 6:43 AM Michal Schorm  wrote:
>
> On Thu, Aug 6, 2020 at 12:35 PM Neal Gompa  wrote:
> >
> > On Thu, Aug 6, 2020 at 6:20 AM Michal Schorm  wrote:
> > >
> > > On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa  wrote:
> > > > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa  wrote:
> > > > > > You are not supposed to use %__cmake_builddir.
> > > >
> > > > It is not documented, and eventually will be removed. So don't rely on
> > > > it. If you want to change the build directory, set %_vpath_builddir
> > > > instead.
> > >
> > > Well, just make it documented ?
> > >
> >
> > The %_vpath_builddir macro is *already* documented:
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/vpath/
>
> But it doesn't do what we need.
> This %_vpath_builddir macro gives a path to the defined builddir.
>
> While %__cmake_builddir macro gives a path to the *actual* directory
> that was used as a builddir.
> Which is a huge difference, especially, when we talk about unifying
> SPECfiles for F31, F32 and F33.
>
> I see the macro defined as:
> %__cmake_builddir
> %{!?__cmake_in_source_build:%{_vpath_builddir}}%{?__cmake_in_source_build:.}
> This very line will either be in the
> "/usr/lib/rpm/macros.d/macros.cmake" from the
> "cmake-rpm-macros.noarch" package, or in every SPECfile that needs
> this macro.
>
> Why can't it be part of the standard CMake macros set, given that it
> does a different thing than %_vpath_builddir ?
>

I don't want to document something that I don't want to guarantee as
an interface. That knob will eventually be removed (probably in a
couple of Fedora releases). When I do that, %_vpath_builddir will
always directly map to the build directory passed to CMake.


-- 
真実はいつも一つ！/ 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

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

2020-08-06 Thread Michal Schorm

On Thu, Aug 6, 2020 at 12:35 PM Neal Gompa  wrote:
>
> On Thu, Aug 6, 2020 at 6:20 AM Michal Schorm  wrote:
> >
> > On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa  wrote:
> > > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa  wrote:
> > > > > You are not supposed to use %__cmake_builddir.
> > >
> > > It is not documented, and eventually will be removed. So don't rely on
> > > it. If you want to change the build directory, set %_vpath_builddir
> > > instead.
> >
> > Well, just make it documented ?
> >
>
> The %_vpath_builddir macro is *already* documented:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/vpath/

But it doesn't do what we need.
This %_vpath_builddir macro gives a path to the defined builddir.

While %__cmake_builddir macro gives a path to the *actual* directory
that was used as a builddir.
Which is a huge difference, especially, when we talk about unifying
SPECfiles for F31, F32 and F33.

I see the macro defined as:
%__cmake_builddir
%{!?__cmake_in_source_build:%{_vpath_builddir}}%{?__cmake_in_source_build:.}
This very line will either be in the
"/usr/lib/rpm/macros.d/macros.cmake" from the
"cmake-rpm-macros.noarch" package, or in every SPECfile that needs
this macro.

Why can't it be part of the standard CMake macros set, given that it
does a different thing than %_vpath_builddir ?

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
___
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: What to do about FTBFS because auf cmake change?

On Thu, Aug 6, 2020 at 5:45 AM Kevin Kofler  wrote:
>
> FYI, the easiest and most portable fix is to add:
> -B.
> (followed by a space or some other whitespace) before the . or .. (source
> directory) argument. (That basically undoes the effects of this pointless
> incompatible macro change.)
>

Not only is that terrible advice, it's actually *wrong*. If you're
going to do bad things like that, at least make sure to test it.

If you're going to override the build directory with CMake like that
to bypass the behavior (which you *should not do*), you actually will
need to set both the source directory (with -S) and the build
directory (with -B) to override the default setting that the macro
sets.

But note that attempting to force an in-source build or the old
behavior will eventually break, since CMake upstream intends to
disallow this eventually (hence all the warnings it throws when you
try to do that). And a number of projects are already manually
attempting to break legacy behavior in their CMakeLists.

-- 
真実はいつも一つ！/ 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

[Bug 1866735] perl-Module-ScanDeps-1.28 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Module-ScanDeps-1.28-1
   ||.fc33
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-08-06 10:36:25




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

On Thu, Aug 6, 2020 at 6:20 AM Michal Schorm  wrote:
>
> On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa  wrote:
> > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa  wrote:
> > > > You are not supposed to use %__cmake_builddir.
> >
> > It is not documented, and eventually will be removed. So don't rely on
> > it. If you want to change the build directory, set %_vpath_builddir
> > instead.
>
> Well, just make it documented ?
>

The %_vpath_builddir macro is *already* documented:
https://docs.fedoraproject.org/en-US/packaging-guidelines/vpath/



-- 
真実はいつも一つ！/ 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

Re: Poor first time experience for potential contributors interested in release validation

2020-08-06 Thread Kamil Paral

On Thu, Aug 6, 2020 at 5:16 AM Jonathan Watt  wrote:

> I originally reported this issue at
> https://bugzilla.redhat.com/show_bug.cgi?id=1862703 but was asked to
> re-report it here:
>
> I was using whatcanidoforfedora.org to see what areas I could contribute
> to. I selected "Validate Releases" and it took me to the QA wiki:
>
>   https://fedoraproject.org/wiki/QA/Join#release-validation
>
> That section says:
>
>   For information on getting and installing pre-releases, see .
>

Actually, it's in this section:
https://fedoraproject.org/wiki/QA/Join#Testing_Fedora_pre-releases
where it talks about Alpha and Beta releases. And since we have none for
F33 yet, the get-prerelease page is empty. At least I hope it will come
alive again once we have a Beta compose (Alphas are no longer produced).
The wording could be improved regarding this, yes.

What is applicable right now is Rawhide testing, release validation testing
(on Rawhide) and test days. We'll be branching F33 from Rawhide during the
next week or so, I believe, so then it will become F33 testing instead of
Rawhide testing.

As Ben said in Bugzilla, the best place to talk about this is the test list
[1] (this is not the test list), or you can create tickets for us in our
tracker [2].

Thanks for your interest in helping us!

[1]
https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
[2] https://pagure.io/fedora-qa
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

2020-08-06 Thread Michal Schorm

On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa  wrote:
> > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa  wrote:
> > > You are not supposed to use %__cmake_builddir.
>
> It is not documented, and eventually will be removed. So don't rely on
> it. If you want to change the build directory, set %_vpath_builddir
> instead.

Well, just make it documented ?

Otherwise I probably would literally copy it to all of my SPECfiles ... .
And from other replies I see I most likely won't be the only one who
needs *exactly* behaviour of that macro. (To find out what the
builddir path is; without need of changing it)
It only makes sense to provide it in some central place - like among
cmake macros - to avoid a lot of code duplication.

The only other solution I see for now would be to change the builddir
to some other location and use that around the SPECfile.
But ... why? The re-defining of the location from a standard (for
Fedora CMake SPECs) location neither does bring any benefit, nor do we
actually want to do it.

The solution is already in-place. And already we know we will want to
use this macro (To find out what the builddir path is) in the future.
If documenting it and making it "stable" is the only thing needed, I
see it as a max. 5 minute work to save *a lots* of 5-minute work from
others. (For each one per each SPECfile)

Maybe there are some real issues behind the macro which makes it hard
to standardize.
I'd like if you share them in that case, so we might come up with a
better solution together, on this list.

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
___
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: What do to about massive # of FTBFS bugs?

2020-08-06 Thread Fabio Valentini

On Thu, Aug 6, 2020 at 11:50 AM Kevin Kofler  wrote:
>
> Richard Shaw wrote:
> > I'm confused if I should even fix these right now due to the various
> > issues I've seen on the list.
>
> Just set them to ASSIGNED, you have 6 months to actually fix them.
>
> Kevin Kofler

While that might work for you, broken packages are actually blocking
other packager's work.

Regarding the various issues mentioned by Richard:

- I've resubmitted all builds that failed due to infra issues
- I've resubmitted all builds that failed only due to annobin /
gettext broken / binutils issues
- I'm helping Neal and Igor process CMake macro change fallout

The first two didn't require any commits in git, and I only submitted
builds for packages that successfully built in mock locally.
For the third point, I looked at how packagers are handling their
packages, and adjusted my modifications accordingly.

So far, I've reduced the number of FTBFS packages by about 300.
I also manually processed the FBTFS bugs filed for those packages and
closed them accordingly.

I'd say it's pretty safe to submit things to rawhide again. I haven't
seen any lingering buildroot issues for the past 2-3 days, except for
some longer wait/build times in koji due to batched ELN build
submissions (but those are finished now too).

Fabio
___
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: What do to about massive # of FTBFS bugs?

Richard Shaw wrote:
> I'm confused if I should even fix these right now due to the various
> issues I've seen on the list.

Just set them to ASSIGNED, you have 6 months to actually fix them.

Kevin Kofler
___
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: What to do about FTBFS because auf cmake change?

FYI, the easiest and most portable fix is to add:
-B.
(followed by a space or some other whitespace) before the . or .. (source 
directory) argument. (That basically undoes the effects of this pointless 
incompatible macro change.)

Kevin Kofler
___
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: bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-18.eln103 failed to build

2020-08-06 Thread Aleksandra Fedorova

Hi,

On Thu, Aug 6, 2020 at 5:01 AM Orion Poplawski  wrote:
>
> So, I'm getting one of these messages every couple of hours and I'd
> really rather not.  Who do I need to talk to about it?

You can talk about it with the ELN SIG [1] or Fedora CI SIG [2]. Mail
thread on devel works, we recommend to use [ELN] as a tag in the
subject, but this works too.

So let me explain first what is going on, and then what we are going
to do about it.

1) Why do you get the message?

We don't send messages to you or anyone directly. We trigger koji
builds for packages which are considered part of the ELN buildroot.

Koji sends messages about all new builds to the Fedora Messaging bus.
Then Fedora Notification [3] App reads messages from the message bus
and sends you notifications based on your filters. It has some default
settings, thus it sends you notifications about all builds for the
package you maintain, but this can be changed via the app interface.

2) Why do you get them so often?

The goal of the ELN is to contain exactly the same versions of the
packages which were built for Rawhide.

To achieve that goal we have automation, which rebuilds Rawhide
packages for the ELN buildroot. This automation is triggered when a
new package is tagged to f33 koji tag.
Thus ideally you would get just one eln-related message per package update.

Now, as Fedora Mass Rebuild happened over the weekend, there was a
mass retagging event, which automation couldn't process at once. And
we got the backlog of 3500 packages, which we need to rebuild for eln.

To not overload koji, rather than sending all of these packages to be
built at once, we added a background process, which regularly chooses
some random packages from the backlog and sends it to koji.

With this helper script in three days we managed to reduce the backlog
to 190 packages, and then, with some additional filtering, to 40. So
now we have about 40 packages and the script which chooses random
packages from the list hits you package again and again. Sorry for
that.

3) What can you do about it?

Option 1: do nothing.
Since the majority of builds is now processed, with only real failures
left, we will disable the periodic script and will only keep the
rebuild pipeline triggered on new package updates.
You are going to get messages about ELN builds occasionally, but not as often.

Option 2: configure filters in Fedora Notification App so you are not
notified about builds done for 'eln' tag or by this particular user.
Note: we are going to get a proper user for CI automation (something
like `fedora-ci-bot`)[4] so you might need to adjust the filter later.

Option 3: Join the ELN effort :)

For more info on ELN I recommend to check the talk by Stephen
Gallagher at Fedora Nest this Sunday [5].

> FWIW - It seems to fail because of missing deps:
>
> DEBUG util.py:621:  No matching package to install: 'cmake(Qt5)'
> DEBUG util.py:621:  No matching package to install: 'cmake(Qt5X11Extras)'
>

Thanks for looking at it.

Afaik we have qt5-5.14.2-4.eln103 in the eln buildroot, so it is not
clear for me why this dependency resolution fails, but we will look
into it.

> Thanks,
>
>Orion

[1] https://fedoraproject.org/wiki/SIGs/ELN
[2] https://fedoraproject.org/wiki/SIGs/CI
[3] https://apps.fedoraproject.org/notifications
[4] https://pagure.io/releng/issue/9619
[5] https://hopin.to/events/nest-with-fedora#schedule

>  Forwarded Message 
> Subject: bpeck/jenkins-continuous-infra.apps.ci.centos.org's
> vtk-8.2.0-18.eln103 failed to build
> Date: Wed,  5 Aug 2020 19:17:12 + (GMT)
> From: notificati...@fedoraproject.org
> To: or...@fedoraproject.org
>
> Notification time stamped 2020-08-05 19:14:23 UTC
>
> bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-18.eln103
> failed to build
> http://koji.fedoraproject.org/koji/buildinfo?buildID=1546696
>
> --
> Orion Poplawski
> Manager of NWRA Technical Systems  720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
>
> ___
> 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

-- 
Aleksandra Fedorova
bookwar on IRC
___
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:

Re: mpich always injects lto flags

* Christoph Junghans:

> I am trying to rebuild espresso to adapt to the recent cmake changes,
> when doing this I hit
> https://github.com/espressomd/espresso/issues/3396, which prevents us
> from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> which works for the build with openmpi, but gets ignored for the mpich
> build.
>
> I think the problem is that CMake picks up the lto flags from mpicxx
> and then puts them in
> MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
>
> So I think the fix would be to strip these flags from mpicc. Sounds
> reasonable?

I think this could be an application for the extension_*flags macros in
redhat-rpm-config:

# Internal-only.  Do not use.  Expand a variable and strip the flags
# not suitable to extension builders.
%__extension_strip_flags() %{lua:
local name = rpm.expand("%{1}")
local value = " " .. rpm.expand("%{build_" .. name .. "}")
local result = string.gsub(value, "%s+-specs=[^%s]+", " ")
print(result)
}

# Variants of CFLAGS, CXXFLAGS, FFLAGS, LDFLAGS for use within
# extension builders.
%extension_cflags %{__extension_strip_flags cflags}
%extension_cxxflags %{__extension_strip_flags cxxflags}
%extension_fflags %{__extension_strip_flags fflags}
%extension_ldflags %{__extension_strip_flags ldflags}

These were intended for scenarios where the flags are hard-coded into
other tools at build time.  It's unfortunately rather difficult to
decide what should go into those flags.

Ideally, tools like mpicc would use a more dynamic approach to determine
the proper flags.

Thanks,
Florian
___
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: Test machines for s390x?

* Elliott Sales de Andrade:

> 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?

Marist offers machine access for open-source development:





Debian has a porterbox as well.

I don't know which setup is more straightforward to use for Fedora
development.

Thanks,
Florian
___
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: Can we use emulation of other architectures to run integration tests?


On 30. 07. 20 14:14, Miro Hrončok wrote:

On 30. 07. 20 12:24, Aleksandra Fedorova wrote:

As COPR has recently got support for s390 builds, the question is: if
emulation is good enough for building packages, can we use it for
testing? What are the limitations there? Is it worth it?


I don't have that many experience with this but every time I've attempted to 
build some Python package via mock's forcearch emulation on s390x, I got some 
segfaults and gave up.


Seems like I am not the only one, see:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RPUH24RWLJQLXLD7VQ35NUPQD52RQAYQ/


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

[Bug 1866735] New: perl-Module-ScanDeps-1.28 is available

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

Bug ID: 1866735
   Summary: perl-Module-ScanDeps-1.28 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Module-ScanDeps
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: anon.am...@gmail.com, jose.p.oliveira@gmail.com,
jples...@redhat.com,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.28
Current version/release in rawhide: 1.27-7.fc33
URL: http://search.cpan.org/dist/Module-ScanDeps/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/3112/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Test machines for s390x?