[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d5bbc97415   
json-c12-0.12.1-4.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-db3d7a1399   
exim-4.92.3-2.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fe619e5492   
golang-1.13.11-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

xrootd-4.12.1-1.el6

Details about builds:



 xrootd-4.12.1-1.el6 (FEDORA-EPEL-2020-5f7565fcf4)
 Extended ROOT file server

Update Information:

xrootd 4.12.1

ChangeLog:

* Thu May 21 2020 Mattias Ellert  - 1:4.12.1-1
- Update to version 4.12.1
- Fix broken man page


___
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: [Rawhide] Missing boost-python3-devel in repository

[Luya Tshimbalanga]

On 2020-05-23 12:31 p.m., Igor Raits wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 2020-05-23 at 12:18 -0700, Luya Tshimbalanga wrote:

On 2020-05-23 11:20 a.m., Igor Raits wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 2020-05-23 at 11:09 -0700, Luya Tshimbalanga wrote:

Hello team,

It looks like the build system is missing boost-python3-devel
which
causes openvdb to fail as  result below:

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

Could someone resolve the issue?

So the issue is coming from this commit:
https://src.fedoraproject.org/rpms/boost/c/1f2e448e099a867f9da62b9da009d3dec5e1ad64?branch=master

The boost-python3-devel has been merged into the boost-devel
package,
but the provides have not been added.


Thanks for the notification. It would be great that modificaiton was
posted in the mailing list in a future.

Agree.

Anyhow, https://src.fedoraproject.org/rpms/boost/pull-request/6.



Thank you Igor and Miro!

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

Re: late generation of assemble code

[Neal Gompa]

On Sun, May 24, 2020 at 12:06 AM Paul Dufresne via devel
 wrote:
>
> On 5/23/20 11:26 PM, Neal Gompa wrote:
> > On Sat, May 23, 2020 at 11:22 PM Paul Dufresne via devel
> >  wrote:
> ...
> > It's completely toast on Linux for the same reason FatELF was: nobody liked 
> > it.
>
> ...
>
> I think this is different than FatELF. The idea of FatELF, is that it
> contains the generated code for more than one CPU (as I understand it).
> This means that some of the FatELF you don't need because it is not for
> your CPU. But I propose to not distribute any code for your CPU, only
> high-level assembler (LLVM code). Optimizing the high-level assembler on
> your own computer, you get the optimizations for your CPU, where more
> normal methods have to choose base common characteristics of the CPU family.
>

Your right that the technical reasoning for why nobody liked it is
different. But people don't like what LLVM does either (and
personally, I think clang is still not a great compiler), so we don't
use it that way. Though I suspect it shows up more often in graphics
stuff that way already.



--
真実はいつも一つ！/ 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: late generation of assemble code

[Paul Dufresne via devel]

On 5/23/20 11:26 PM, Neal Gompa wrote:
> On Sat, May 23, 2020 at 11:22 PM Paul Dufresne via devel
>  wrote:
...
> It's completely toast on Linux for the same reason FatELF was: nobody liked 
> it.

...

I think this is different than FatELF. The idea of FatELF, is that it 
contains the generated code for more than one CPU (as I understand it). 
This means that some of the FatELF you don't need because it is not for 
your CPU. But I propose to not distribute any code for your CPU, only 
high-level assembler (LLVM code). Optimizing the high-level assembler on 
your own computer, you get the optimizations for your CPU, where more 
normal methods have to choose base common characteristics of the CPU family.

___
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

Self-Introduction of Tanveer Salim and Notice on Implementation of KangarooTwelve

[tsalim--- via devel]

Dear Fedora Community,

Hello! I am Tanveer Salim and am a Computer Engineering Student from Texas Tech 
University. I am currently writing a standard user-space implementation of 
KangarooTwelve. I contacted Gilles van Assche and he said he was interested in 
viewing my implementation after I finished the rough draft. I have let him know 
I intend to finish the first rough draft by June 1, 2020. And I do intend to 
submit the implementation of KangarooTwelve as a Fedora package. If anyone has 
any questions or comments about my attempt to implement KangarooTwelve please 
let me know.

Sincerely,

Tanveer Salim
___
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: late generation of assemble code

[Neal Gompa]

On Sat, May 23, 2020 at 11:22 PM Paul Dufresne via devel
 wrote:
>
> I sometime ask myself what have happened to the "LLVM dream"?
>
> The idea of LLVM was not to be *just* an intermediate language for the
> compiler. The idea was to push code generation as near as possible of
> code execution. Because at execution time, you know what are the
> specific features of the CPU, and what is used to most often by the user
> of the program.
>
> But it seems CLANG have become a plain replacement of gcc. Just an
> alternative compiler. But as I remember the LLVM whitepaper, the idea
> was that LLVM generated code was the way programs would be distributed.
> It would be possible to generate the assembler at install time. But I
> don't think this is the right time because when you install packages...
> you have a lot of work to be done. No I think the best time to generate
> assembler code is when the CPUs are idle... as a background service.
> Sure, you have to optimize the full program because you don't know yet
> what features of the program the user will use the most, but this don't
> seems such a big problem... because hey... the CPU would not been doing
> much useful things anyway. There is the problem of the user trying to
> launch the program just after installation... I think it would be
> reasonable to show a "finishing compiler of  program", generate the
> assembler code with low optimization, then launch the generated code. It
> will still be time later to do a greater level of optimization.
>
> Is there some technical problems for not packaging LLVM code rather than
> CPU specific code?
>

It's not *completely* dead. This is, in fact, how macOS and iOS apps
are submitted to their respective app stores. The final compilation
happens on Apple's servers for all supported architectures.

It's completely toast on Linux for the same reason FatELF was: nobody liked it.

It doesn't work on Windows because of the instability of the Windows
runtime ABI (unless you pin to specific runtime ABI, which can lock
you out of APIs and features).



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

late generation of assemble code

[Paul Dufresne via devel]

I sometime ask myself what have happened to the "LLVM dream"?

The idea of LLVM was not to be *just* an intermediate language for the 
compiler. The idea was to push code generation as near as possible of 
code execution. Because at execution time, you know what are the 
specific features of the CPU, and what is used to most often by the user 
of the program.


But it seems CLANG have become a plain replacement of gcc. Just an 
alternative compiler. But as I remember the LLVM whitepaper, the idea 
was that LLVM generated code was the way programs would be distributed. 
It would be possible to generate the assembler at install time. But I 
don't think this is the right time because when you install packages... 
you have a lot of work to be done. No I think the best time to generate 
assembler code is when the CPUs are idle... as a background service. 
Sure, you have to optimize the full program because you don't know yet 
what features of the program the user will use the most, but this don't 
seems such a big problem... because hey... the CPU would not been doing 
much useful things anyway. There is the problem of the user trying to 
launch the program just after installation... I think it would be 
reasonable to show a "finishing compiler of  program", generate the 
assembler code with low optimization, then launch the generated code. It 
will still be time later to do a greater level of optimization.


Is there some technical problems for not packaging LLVM code rather than 
CPU specific code?



___
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] 389 DS nightly 2020-05-24 - 94% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/05/24/report-389-ds-base-1.4.4.2-20200523gitc350ddc.fc32.x86_64.html
___
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: [Rawhide] Missing boost-python3-devel in repository

[Miro Hrončok]

On 23. 05. 20 20:09, Luya Tshimbalanga wrote:

Hello team,

It looks like the build system is missing boost-python3-devel which causes 
openvdb to fail as  result below:


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

Could someone resolve the issue?


Should be resolved now.

--
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: fedpkg fork broken?

[Miro Hrončok]

On 23. 05. 20 2:19, Aleksandra Fedorova wrote:

I've got the same problem. I think it uses wrong remote path:

a...@pkgs.fedoraproject.org 


https://pagure.io/fedpkg/issue/394

--
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: [Rawhide] Missing boost-python3-devel in repository

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 2020-05-23 at 12:18 -0700, Luya Tshimbalanga wrote:
> On 2020-05-23 11:20 a.m., Igor Raits wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > On Sat, 2020-05-23 at 11:09 -0700, Luya Tshimbalanga wrote:
> > > Hello team,
> > > 
> > > It looks like the build system is missing boost-python3-devel
> > > which
> > > causes openvdb to fail as  result below:
> > > 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=44871050
> > > 
> > > Could someone resolve the issue?
> > So the issue is coming from this commit:
> > https://src.fedoraproject.org/rpms/boost/c/1f2e448e099a867f9da62b9da009d3dec5e1ad64?branch=master
> > 
> > The boost-python3-devel has been merged into the boost-devel
> > package,
> > but the provides have not been added.
> > 
> Thanks for the notification. It would be great that modificaiton was 
> posted in the mailing list in a future.
Agree.

Anyhow, https://src.fedoraproject.org/rpms/boost/pull-request/6.

> Nevertheless, I updated the spec file to reflect the change.
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=44873827
> 
> https://src.fedoraproject.org/rpms/openvdb/blob/master/f/openvdb.spec
> 
> -- 
> 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
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7JefcACgkQEV1auJxc
Hh4/5Q//bzN3lwRwKRe6j9OlYVyLDjKxV321Fwqs7gKYv1AlvZ6oNWyruT6XWRkd
ot+6TufIaSUp/x7e0G3gUFGWH1YLGSBLvu5hYsTp+TSs5vShwyaFxIMcmC2wlc95
Q/VxeS0HcKAbzOcJ3vUGC4bAL9qgYHbcZanUVzR2Rk+qoYGokbW6yZ/zR6277zJC
9/jp/ig23U8SLGh9W9F/VVZfl/bJg9950454iFQhEJV4bM6Fe4M0N0Y+T4GUmeOi
7J39EanIv89U0c52D7KZ4Ee5ywfsp9XJH2zvhhcB9SVCaIlmma/JW0sB2E4jFeCz
EOoPA3YcwFsTSDlrPcz9nI5fwtbKcWLlOVj03NPeX/EVAnwovtvTvUWEhsp1jSj1
vq1WZZwtuf1et22hpIdwtnP21jQOIPBGKlicsfOisS0xHUrUGPbgwP7/t2GTpDq1
NOAY2UybUtVOPftMQNGvxV+Jsr0Epmk/dgPeed9UcqK2FdoACP8mTXtzVsh/zFKl
JYjGh1Me9m+H8cptjMCs0X58t29tpZPKynFobT4h3DiHqfz22RAClQwoAi8YQluq
AG64fKIXJxoqYFwWy3YW9+dqNkB4DvxnA+5TiTWh2cZr3ILVH8vco09U8gUK43j5
PRSwiW13N8ERvxtNTxiQWlMk683331eYkC+V8m+Ll/RRe3cHE0s=
=3dyQ
-END 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: The price of FHS

[David Schwörer]

As this topic comes up, I think the issue is more related to cases where
upstream is not willing to support FHS installation. PETSc [1] is one
case, openfoam [2] is another example which is currently under review
[3]. The issue is that derived projects get used to this case of
installation, which then can lead to projects depending those to assume
that they are not split in the FHS structure, and require e.g. some
example files to configure correctly (SLEPc [4] does this during configure)

This leads to a lot of pain, trying to convince projects to not assume
the package is installed the way upstream recommends, but the way some
distro prefers.

On the other hand, we are not consistent - mpi binaries end up in
/usr/lib64/$mpi/bin/ but headers are in /usr/include/$mpi-$arch/.

This parallel availability is solved with (environment) modules [5] but
as already discussed with respect to modularity, that causes quickly an
explosion of possibilities ...

[1] https://www.mcs.anl.gov/petsc/
[2] https://openfoam.com/
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1816301
[4] https://slepc.upv.es/
[5] https://en.wikipedia.org/wiki/Environment_Modules_(software)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Rawhide] Missing boost-python3-devel in repository

[Luya Tshimbalanga]

On 2020-05-23 11:20 a.m., Igor Raits wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 2020-05-23 at 11:09 -0700, Luya Tshimbalanga wrote:

Hello team,

It looks like the build system is missing boost-python3-devel which
causes openvdb to fail as  result below:

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

Could someone resolve the issue?

So the issue is coming from this commit:
https://src.fedoraproject.org/rpms/boost/c/1f2e448e099a867f9da62b9da009d3dec5e1ad64?branch=master

The boost-python3-devel has been merged into the boost-devel package,
but the provides have not been added.

Thanks for the notification. It would be great that modificaiton was 
posted in the mailing list in a future.


Nevertheless, I updated the spec file to reflect the change.

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

https://src.fedoraproject.org/rpms/openvdb/blob/master/f/openvdb.spec

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

Fedora-Cloud-31-20200523.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: The price of FHS

[Stephen J. Turnbull]

Paul Dufresne via devel writes:

 > Now I do believe the reason you need to give a version to shared 
 > libraries is because of the FHS. Because FHS suggest to regroup 
 > libraries inside a specific directory and/or directories. But if you 
 > have a common directory that contains every packages inside their own 
 > directory, things because simpler because the directory identify 
 > uniquely a library.

However, none of the above is entirely true, and the minor differences
matter.  You don't need to version shared libraries at all; the system
(specifically ld-linux.so) will pick the first compatibly-named
library on the load path.  So you can specify different libraries by
manipulating the load path (as well as several other mechanisms, some
of which may not be available depending on the system's security posture).

The need to version shared libraries is not based on the FHS; it's
that the library APIs or ABIs or semantics differ, so programs that
target those APIs/ABIs/semantics can get what they're expecting (if
they don't, often you get a core dump, or garbage output, or even a
security vulnerability).  We've learned over the ages for security and
reliability reasons that these version variables and checks really
need to be in the library and application respectively, so even if you
wanted to go with a fully directory-based library search mechanism,
you'd still need the version information.  The libfoo.so.X.Y.Z naming
convention turns out to be simple enough to be quite reliable for
system administration, and the rare slip-up is caught by the version
checks in the code.

The .so version *does* uniquely identify a library, regardless of
directory (with some exceptions such as debug libraries that NixOS
also presumably handles).  But according to another poster, NixOS uses
links to populate an application's library directory, so you actually
don't know what those libraries are from their names.  In principle; I
suspect that NixOS enforces naming conventions so that you do know
what they are, as long as you're using NixOS packages.  But in the
Fedora system, to find the library that will pass the runtime version
checks you need to *both* name it correctly *and* be correct, since
the version in the name needs to match the internal version.

And finally, the FHS does provide for I-don't-need-no-shared-libraries
packages: it can't stop you from statically linking your executables
(although GNU libc *really* doesn't like that for some facilities,
like NSS), and it provides /opt for exactly the kind of package
management you propose.  Very few projects use it as far as I know (to
check I'd have to find out what "LANANA" is exactly and look it up,
see FHS if you wish to do so), presumably because of the benefits
provided by shared libraries, some of which are described below (and
of course there's the support that Fedora package management provides
for the FHS but doesn't provide for /opt-style packaging).

All of your statements are "approximately" true (except the statement
that FHS is a reason for library versioning) from the user's point of
view.  However, what you really are discussing is shared libraries
themselves.  If every binary had all its libraries compiled into it,
this "DLL Hell" (to borrow from the Windows world) would never occur.
So, why do we have shared libraries and DLL hell?

1.  Space is limited, both on disk *and in memory*.  A very basic
library like ld-linux.so or libc.so is likely to have one hundred
or more concurrent references on a moderately busy personal
system.  This saves a *ton* of swapping.

2.  Bandwidth is limited.  Upgrading a large number of packages would
require upgrading each one's copy of shared libraries.  Version
dependencies means that you need to do that individually (although
a Sufficiently Smart PMS could check for available versions on the
system and copy them, you can be sure that will fail sometimes
because the upstream package distributor has patched the library,
and perhaps not changed the version to indicate that).

2.  There are often multiple protocols for a given operating system
feature.  For example, back when I was a developer's egg,
file-locking was done through three different protocols (at
least): dotfile, lockf, and flock.  It wasn't actually done this
way ;-), but if there were a lock.so library, and all running
processes used the same lock.so, nobody would step on anybody
else's files.  (Nowadays the OS provides "mandatory locks",
solving this problem and introducing others.)

3.  Particularly important are security protocols.  We really really
want all of your (new) processes to upgrade to the latest versions
of TLS and the latest cipher suites.  Upgrading your libssl.so
makes all of that possible with one upgrade.  Another example is
the resolver for various name services (the one that GNU libc is
so finicky about).

4.  Some programs will try to load a 

Re: [Rawhide] Missing boost-python3-devel in repository

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 2020-05-23 at 11:09 -0700, Luya Tshimbalanga wrote:
> Hello team,
> 
> It looks like the build system is missing boost-python3-devel which 
> causes openvdb to fail as  result below:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=44871050
> 
> Could someone resolve the issue?

So the issue is coming from this commit: 
https://src.fedoraproject.org/rpms/boost/c/1f2e448e099a867f9da62b9da009d3dec5e1ad64?branch=master

The boost-python3-devel has been merged into the boost-devel package,
but the provides have not been added.

> Thanks in advance
> 
> -- 
> 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
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7JaVcACgkQEV1auJxc
Hh4/vg/+I9na/RkF9N1xATPzZ6DEW8b1aoiBhprnK1S0FuhzMQzZ7lEnjU6SxMZU
rhze18EhLozcBMspP+RUD0jcfV5HEH3l3W2OW3+8HUlYnPOaL1KX87RSglEBhEMQ
2UewxG1f2VHg7UbNExN8Hd3/QzxTtWHrjkLXs74WypqPMAFz7gE3PF/EQw+0EMvk
8Xnbn/AiCe6pc1CjIVBAwYsu3bNY+D9kTvbLp/E0KAfJEhdhSpJOKBU671or1/T8
rzahjt0JqFk9mtA97rSoZbTPDdZdqfXsK0IHa4qI7xUnkWNM+4dPQa2JlxJYYPFB
zpup0n5qpWu66d85IbshcL9zS+eehJVQHVGIfFXmWQSVVdOs54AhsVeZqizFxEbw
VAitWwzqFnyVxI+9UQ+7ZxXgsnghjhTvDErcZU4euBS5/3W6GLOCKZz/E7rE1E3G
acwkPZ5hKegw9YCEdhVGhcHOxeYgP3OkBtBkcihl+qmtG5KLvItsTFE8hY56myl5
bqGE6tlFHw76fQwyW0n8WYchubQZ0YQ5q/q8LxbsTNf1TTj9ctiLCzab1jFYEXh4
GMYXMw68akzhr99Gffu6br9nqiWLrqYDt71Cho/TrdSy7ZVg5d6lnklLy0+FkNw7
0wLIfHEbDPYJaduGdCEGq8Skm0qMWwkI5Ty/iijaj7l2p+4BJ9I=
=fdOA
-END 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

[Rawhide] Missing boost-python3-devel in repository

[Luya Tshimbalanga]

Hello team,

It looks like the build system is missing boost-python3-devel which 
causes openvdb to fail as  result below:


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

Could someone resolve the issue?

Thanks in advance

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

[Test-Announce] Fedora 33 Rawhide 20200522.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 33 Rawhide 20200522.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20200515.n.0: anaconda-33.14-1.fc33.src, 20200522.n.0: 
anaconda-33.15-2.fc33.src
python-blivet - 20200515.n.0: python-blivet-3.2.1-2.fc33.src, 20200522.n.0: 
python-blivet-3.2.2-1.fc33.src
pungi - 20200515.n.0: pungi-4.2.2-1.fc33.src, 20200522.n.0: 
pungi-4.2.2-2.fc33.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/33

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200522.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200522.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200522.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200522.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200522.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200522.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200522.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@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: About insert again a package

[Sandro Mani]

On 23.05.20 15:42, Sergio Belkin wrote:

Hi!
I am package maintainer of UpTools:
https://koji.fedoraproject.org/koji/packageinfo?packageID=11676

Some years ago I lost contact with upstream so could not maintain in a 
proper way, so AFAIK the package was retired, . I recovered contact 
with upstream.
I would like to add it again to Fedora, what steps should I take? Is 
as with new package? Or is as in an update? Please could you help me 
to do it?



You'll need to follow the procedure outlined here

https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package

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

About insert again a package

[Sergio Belkin]

Hi!
I am package maintainer of UpTools:
https://koji.fedoraproject.org/koji/packageinfo?packageID=11676

Some years ago I lost contact with upstream so could not maintain in a
proper way, so AFAIK the package was retired, . I recovered contact with
upstream.
I would like to add it again to Fedora, what steps should I take? Is as
with new package? Or is as in an update? Please could you help me to do it?

Thanks in advance...
-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.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: Sundials upgrade on Rawhide

[Antonio Trande]

On 23/05/20 14:42, David Schwörer wrote:
> On 5/22/20 2:26 PM, Antonio Trande wrote:
>> Scratch build:
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=44816285
> 
> My initial try of rebuilding in copr for easier testing failed.
> 
> I had to add
> export OMPI_MCA_rmaps_base_oversubscribe=yes
> to the %check section, to get it working on copr.
> 
> Would it be better to put that flag in each spec file, or should I open
> a bug against openmpi, to set this flag in %_openmpi_load?
> 

I had noticed this problem in Copr in fact.
I will add that `mpirun` option.


Thank you.
-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/



signature.asc
Description: OpenPGP digital 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: Sundials upgrade on Rawhide

[David Schwörer]

On 5/22/20 2:26 PM, Antonio Trande wrote:
> Scratch build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=44816285

My initial try of rebuilding in copr for easier testing failed.

I had to add
export OMPI_MCA_rmaps_base_oversubscribe=yes
to the %check section, to get it working on copr.

Would it be better to put that flag in each spec file, or should I open
a bug against openmpi, to set this flag in %_openmpi_load?

Cheers,
David
___
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: The price of FHS

[Tomasz Kłoczko]

On Fri, 22 May 2020 at 21:07, Paul Dufresne via devel <
devel@lists.fedoraproject.org> wrote:
[..]

> The main disadvantage of it, is making hard to have multiple active
> versions of a package, because the likelihood of the multiple versions,
> to have the same preferred place in the hierarchy for some files.
>

That has nothing to do with FHS.
Only thing which needs to be prepared for that is using not
overlapping locations between version by package themeselve.

Working example on which you can peak: gtk2, gtk3 and gtk4.

On other way of seeing this disadvantage, is the fact that in a system

> using FHS, new versions of packages often break other programs...
> because using FHS force you to erase the old package to put a new one in
> it's place... so that programs that were dependent on the old version
> cannot use the old version because it is not there anymore.
>

FHS has nothing to do with checking or guarantee consistency of the
isntralled resources.
That kind of duties are on the package management software shoulde.
++mistake


> The other problem I had with NixOS, was the strange Nix syntax of
> packages.


"Strange" is term of "fuzzy logic". Exact values given by that type of
logic on processed objects strictly depends on "reference point(s)/context".
Many people (like me) do't see anything "strange" here because we are using
FHS within context with which seems you are not fasmiliar :)
++mistake

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: The price of FHS

[Tomasz Torcz]

On Sat, May 23, 2020 at 01:01:04PM +0200, Vít Ondruch wrote:
> It would be possible to install individual RPMs into paths such as:
> 
> ~~~
> 
> /pkgs/programA_version1
> /pkgs/libX_version1 contains
> 
> ~~~
> 
> but I wonder how would you imagine the glue above this structure to make
> the programA_version1 to use the libX_version1?

  No need to "imagine" anything. Nix works that way:
  https://lwn.net/Articles/337677/

  The answer lies in symlinks. 


-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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: The price of FHS

[Vít Ondruch]

It would be possible to install individual RPMs into paths such as:

~~~

/pkgs/programA_version1
/pkgs/libX_version1 contains

~~~

but I wonder how would you imagine the glue above this structure to make
the programA_version1 to use the libX_version1?


Vít


Dne 22. 05. 20 v 21:50 Paul Dufresne via devel napsal(a):
> The File Hierarchy Standard (FHS), is a standard that define where the
> files of a package should be placed in the root directory of the
> systems. It probably did not change much since the beginning of Unix,
> and it make files be placed where users, developers and administrators
> expect them to be.
>
> The main disadvantage of it, is making hard to have multiple active
> versions of a package, because the likelihood of the multiple
> versions, to have the same preferred place in the hierarchy for some
> files.
>
> On other way of seeing this disadvantage, is the fact that in a system
> using FHS, new versions of packages often break other programs...
> because using FHS force you to erase the old package to put a new one
> in it's place... so that programs that were dependent on the old
> version cannot use the old version because it is not there anymore.
>
> You probably only realize all this, when you use a distribution like
> NixOS, that have let FHS go away, to make every binary package to be
> in their own directory. This solve the problem of multiple active
> versions of a package, and allows different packages to depend on
> different versions of a package. This also allows normal users to
> install package, just for them... or shared if many users install the
> same version of a program.
>
> Well... I was not so happy with NixOS. In part because binary packages
> are considered, a cache version of a built packages. In the past,
> often the binary cache was not having the built version of a package,
> and it had to build it from sources... which is long, especially if
> you have an older computer. I am unsure why this seems to be less
> problematic now than in the past.
>
> The other problem I had with NixOS, was the strange Nix syntax of
> packages. That I did not seems to get it. Now... with time, the more I
> am exposed to it, the less it seems strange. Still, I wanted a more
> traditional Linux distribution. I had thought that the fact that
> Fedora support modules, that it could be a bit like NixOS. Only
> recently, when someone suggested that we could use modules to have
> different versions of Python, avoiding the problem of new versions
> breaking old versions, did I really realized that Fedora modules does
> not allow multiple active versions of a module to be installed at the
> same time... so that Fedora modules does not help much with the
> problem of new packages needing to replace older versions, so breaking
> packages that were dependent on old versions.
>
> To be clear, the fact to be able to have multiple versions does not
> means that NixOS have many different versions for each packages. For
> some reasons, they try as much as possible to keep just one version of
> each package... but while upgrading... they may keep the older version
> a while. This reduce friction with other packages.
>
> Now like I said, Nix use a very different syntax and tools for
> defining packages. But I don't think you have to adopt it to have most
> of the advantages of Nix. And I believe it would be possible to keep
> the current use of .spec files in such a way of doing things.
>
> That said, I realize that what I am proposing, is more like a fork of
> Fedora, than a proposed change, as letting FHS is such a big change.
> And I am, sadly, not really suggesting that I want to begin such a
> endeavor. For me, it probably means I will begin to move to using more
> NixOS than Fedora. But I had the feeling that it could be useful for
> Fedora, to realize, and evaluate the price they pay for using the File
> Hierarchy Standard.
> ___
> 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

Fedora-Cloud-30-20200523.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: LLVMgold.so: wrong ELF class: ELFCLASS32

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 2020-05-23 at 00:15 +0200, Sandro Mani wrote:
> Hi
Hey,

> I'm seeing this when running nm
> 
> nm: /usr/bin/../bin/../lib/bfd-plugins/LLVMgold.so: wrong ELF class: 
> ELFCLASS32
> 
> I do indeed have both llvm-libs.i686 as well as llvm-libs.x86_64 
> installed. Looks like someone is picking up LLVMgold.so from the
> wrong 
> libdir? Possibly something to report against binutils?
Seems I am not alone who is seeing this: 
https://bugzilla.redhat.com/show_bug.cgi?id=1836618

> Thanks
> Sandro
> ___
> 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
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7I3M4ACgkQEV1auJxc
Hh7lwg/+KHVkhlIf2i1DXvwYwBELdHKQpJ+9NMW9mSF4JwIvdE5KauiCCFYnTcfh
YIJEmvZ8A32UHRxT3ZuCZzZJubfxUIwQweoHS1m5tQzOzDQygmJ3pL5O5WeqZJ7T
+IQOMblTWWcOQojWrY9eZlpUWIfpXkbZZPu6FyXQQBE+BUV3t6hGccpnQxIxh+0p
fnVXwcaprtwCWPPW0phHkL7fLwidc6UzppsSudSxT3ahc8UdIi98uRLCtQRcFonh
MOA3mFotflmgqS360KaLLm/GaSZl6cpiXZE9PTjdn0QapGOSMNb7UHbvm6tWt/m5
59bQA9v1MgUi8EjmrbO3XIguHeh7SYhyPefODuQwEUVvkFHQW9MwhkIf+aA6kzj9
UH0pOtcj0fX4e0Ngq/GtyNhdjNyVyLrXcpXBb6O1bSqBAqZqT0A2uKYZFVUrS9BL
bty9qn/gmxkGfE1XDuTUm0Ak3mL2Yn0132luMcRaTK+BoZafsR/vA1FD3jU/pWkz
Ld/Fn9vI69yYAL59o0ZzkJshDwEp+6t9mfCtg1ZHSpjWTLSUZixcakx3fSkBAFQj
Lcg006DViG2D0UTNFidPGjXmcFixDMCxjY5XCAGZUT/V7ilZ5YEjDcL2nCP/5rkU
I2OxNJ7lsjREtWDn5KivbjS9fXBGl40VH3/JSCm84bocJzrraN8=
=5S1/
-END 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

Fedora-Cloud-32-20200523.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/1 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 603764  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/603764
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: Location of executable code

[Nicolas Mailhot via devel]

Le vendredi 22 mai 2020 à 21:31 -0400, Steve Grubb a écrit :
> 
> Over a couple emails I kind of realized that originally this was
> framing the 
> question wrong. My question now is how can we determine what is meant
> to be 
> executable by system applications vs examples and other cruft? 

There is no easy way right now because this stuff gets classified by
humans, the distinction you want did no exist in the past in the FHS,
so the human classifiers did not think about it.

You could go to the FHS and request separating executable and non
executable data in separate roots, and 5 years after you did it, you’d
began to see the result of the standard change in production systems. I
think that would also involve driving a Fedora Change to focus Fedora
packagers on changing things, and to help fix all the software that
assumes both roots are the same today.

And that would require first for you to have an ironclad definition of
what executable means.

For example, Go source code is mostly not executable (people do not
expect it to run it in a Go interpreter). Except, that when this code
is present, it will be picked up by the next Go static build that needs
it. Making it behave like a shared library (except a library that will
be re-built by each of its users). So, from a security POW, I suspect
it needs to be treated executable, except most people would not think
of it this way. Google will certainly scan it in its own containers the
same way it does for elf files. 

I suspect you could spend a year going through such cases to determine
if they need treating as executable or not.

And, in the end at least 20% of the target population will decide you
are making their life miserable for no good reason, and continue to
blatantly ignore your standard, and mix things. Like systemd and rpm
did for multiarch. So if you care about security you’ll still need to
audit the non-executable root. Except the audit will be less painful,
because a lot of stuff would have been sorted by others.

Regards,

-- 
Nicolas Mailhot
___
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: fedpkg fork broken?

[Dominique Martinet]

Kevin Fenzi wrote on Fri, May 22, 2020:
> So, just to clarify a confusing situation... :) 
> 
> a...@pkgs.fedoraproject.org should never have worked.
> 
> If you have pkgs.fedoraproject.org it means you are using SSH, and are a
> packager. This is just due to the way pkgs was created. Packagers have
> accounts there and can ssh, if you aren't a packager you don't have an
> account and can't ssh. 

So that would probably be a bug that fedpkg adds remote as a...@pkgs.fp.o

I started looking at the code but it looks like it got fixed just two
weeks ago:
https://pagure.io/fedpkg/issue/394
https://pagure.io/fedpkg/c/0da2d94

Looks like we just need to wait for an update :)

> > And I think forking your own repo for pull-requests makes perfect sense,
> > especially since distgit doesn't allow you to remove temporary branches
> > from the main repo.
> 
> +1

I think there might be a confusion here as well. I was thinking of "your
own repo" as pkgs.fedoraproject.org/forks/yourfaslogin/rpms/repo.git -
which I still don't see much sense in forking, if that is possible at
all.

But now I think everyone is talking about some original repo you're
maintainer of; I have no problem agreeing with that one!

-- 
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: Location of executable code

[Nicolas Mailhot via devel]

Le vendredi 22 mai 2020 à 16:48 -0400, Steve Grubb a écrit :
> On Friday, May 22, 2020 4:23:50 PM EDT Przemek Klosowski via devel
> wrote:
> > 
> > In general, data is code is data. 
> 
> I know this argument well (Weird Machines). I was making the same
> argument 10  years ago.  :-)  

It got truer since. The IA stuff people want to replace traditional
computing with is 100% data-driven execution.

Regards,

-- 
Nicolas Mailhot
___
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: Location of executable code

[Nicolas Mailhot via devel]

Le vendredi 22 mai 2020 à 20:41 +0200, Nicolas Mailhot via devel a
écrit :
> 
> So, no use looking for non-executable /usr/share. A lot of /usr/share
> is executable and will stay that way.

Also moving executable things somewhere else would make multiarch (more
of) a major hassle. Because the somwehere else most people think of is
/usr/lib. And then you end up with a situation where all the multilibs
are not symetric and equal, because people had to sacrifice one of them
and stuffed architecture independant parts there.

The architecture independant/architecture specific split is one of the
stong points of the current FHS. The legacy Unix people had to get it
right because they were all deploying on mutually incompatible machine
architectures.

Regards,

-- 
Nicolas Mailhot
___
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