date:20200522

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



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-1a910e5253 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-1a910e5253`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-1a910e5253

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
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 1838904] perl-perlfaq-5.20200523 is available

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



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-6471c56f67 has been pushed to the Fedora 30 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-6471c56f67`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-6471c56f67

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


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

On Fri, May 22, 2020 at 3:20 PM David Malcolm  wrote:

> Hi Steve
>
> Your email talks about "application whitelisting" and "executables",
> and this thread seems to be getting in to the weeds about things like
> the distinction between scripts vs machine code, and modules vs
> scripts; code vs data.
>
> Would it be helpful to approach this from a higher-level point of view?
> Presumably your goal is to enforce some kind of security boundary,
> along the lines of "only blessed things can be run".  What is that
> boundary?  What kinds of threat do you have in mind, and how might this
> whitelisting daemon block them?  (is there a web page somewhere for the
> project?)   (also: what's the user experience?)

And perhaps re-inventing SELinux, applying sophisticated whitelists
and permissions on components throughout userland, is so complex and
error-prone that people will turn it off immediately simply so it's
out of their way, and it will break working software at difficult to
preduct moments? I'm leery of familiar technological approaches that
have been tried, and been discarded as a matter of course, so
repeatedly. Would the time be better spent enhancing SELinux? That's
not a big business opportunity, but it might be considerably more
useful than another whitelisting tool that requites tuning nad
management.

> Some more awkward examples, in case these haven't already been
> mentioned in the thread:
>
> - what about machine code plugins to existing binaries?
>
> - what about Python modules that aren't executable scripts, but which
> are in the import path and might be used by executable scripts? (and
> which might modify the import path)

What about example scripts in /usr/share/doc/ ? This seems like a case
of "premature optimization".: if you're going to manage privileges for
binaries, you're going to have to enter /usr/share/, despite the FHS.

> - what about embedded interpreters?
>
> Hope this is constructive
> Dave
> ___
> 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

[Bug 1838904] perl-perlfaq-5.20200523 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-b96953d5ef has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-b96953d5ef`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-b96953d5ef

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


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

[389-devel] 389 DS nightly 2020-05-23 - 94% PASS

2020-05-22 Thread vashirov

https://fedorapeople.org/groups/389ds/ci/nightly/2020/05/23/report-389-ds-base-1.4.4.2-20200522gitc350ddc.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: fedpkg fork broken?

2020-05-22 Thread Richard Shaw

I figured out my problem, it's the whole confusing what's part of
src.fedoraproject.org and what's part of pagure.io... You need both tokens
for different actions but one goes in:

[fedpkg.pagure]
token = 

[fedpkg.distgit]
token = 

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

Hello,

On Friday, May 22, 2020 6:38:55 PM EDT Kevin Kofler wrote:
> > But what I'm finding in practice is that cinnamon places its javascript
> > there, there are libexec dirs that contain executable code, there are
> > python and byte compiled python over there. In short, the system doesn't
> > work because critical executables are in /usr/share.
> > 
> > The question is what should be done about this? Do we care that things
> > are in /usr/share that are not following the Filesystem Hierarchy
> > Standard? If we do, what is the proper fix this this? Should bz be
> > opened against each component?
> 
> /usr/share is the correct place for architecture-independent files, 
> including binaries and scripts. Though in principle, files that are 
> executable directly (+x bit set) should be in /usr/libexec (if they are to
>  be executed only by programs) or /usr/bin (if they should be executable
> directly by the user) rather than /usr/share. But they may load additional
> architecture-independent code (e.g., libraries, modules, plugins) from
> /usr/share.

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? (This might be 
relevant to people minimizing systems/containers.) Could we ask that all of 
the executable code live inside a libexec dir and examples under something 
else? As an outsider with no knowledge of the packaging history, how do you 
know the intent?

That's it in a nutshell.

-Steve

> /usr/lib is actually the wrong place for architecture-independent (and thus
>  non-multilib) files, though unfortunately it is constantly getting
> abused for them. (IMHO, any file under /usr/lib on a pure 64-bit system on
> a multilib arch (such as x86_64) is a bug, but even systemd now abuses
> that directory that way. IMHO, everything that does not need to be
> multilibbed into /usr/lib and /usr/lib64 should be either in /usr/share or
> in /usr/libexec instead.)
> 
> 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/de...@lists.fedoraproject.or
> g



___
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

2020-05-22 Thread Przemek Klosowski via devel


On 5/22/20 8:48 PM, Parker Gibson wrote:

The issue I see is that no package management system I know of handles multiple 
so versions, they explicitly state packages conflict with each-other even if in 
principle the so versioning means they would not.


The example I gave is from my own system. IN this case package 'nettle' 
owns all those libs, but the scheme would work just fine if one package 
owned the 4.x libraries and another one owned 5.x libraries.


The scheme you are proposing is kind-of used for Java and Go, and is 
sometimes known as 'vendoring' because it allows publishing software in 
complete dependency bundles independent of anything else. It works as 
long as the vendor is diligent about keeping up with it, but it just 
doesn't scale and leads to a fragmented and redundant setup, with 
decaying software all over teh place in those package bundles.

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

2020-05-22 Thread Kevin Fenzi

On Sat, May 23, 2020 at 02:19:07AM +0200, Aleksandra Fedorova wrote:
> 
> I've got the same problem. I think it uses wrong remote path:
> 
> a...@pkgs.fedoraproject.org
> 
> Maybe it was working before, but then certain update happened.

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. 

If you see src.fedoraproject.org that means you are using https. 
Anyone with an account can use this (but it needs you to use fedpkg at
least initially to get a token to push your changes). 

> If you check clone options in UI in Pagure interface, the url will look
> like:
> 
> ssh://book...@pkgs.fedoraproject.org/forks/bookwar/rpms/minetest.git
> 
> There is no variant with "any".
> 
> The API token is valid and works, as the fork is created. It is only the
> remote path which is broken.
> 
> So I ended up calling git remote explicitly after the fork command to
> change the remote uri.
> 
> 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

kevin


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: The price of FHS

2020-05-22 Thread Parker Gibson

The issue I see is that no package management system I know of handles multiple 
so versions, they explicitly state packages conflict with each-other even if in 
principle the so versioning means they would not. Some repositories can handle 
multiple major so versions and I do think this may provide enough flexibility. 
I suppose the place of ultimate conflict is the devel packages as multi-version 
headers would always be in conflict, and I can’t imagine the nonsense one would 
have to go through to tell autoconf/pkg-config “no wait I want this specific 
version” in a shared library environment. But in principle there is nothing FHS 
related limiting multiple versions of a library. It’s an artificial limitation 
that probably helps ease the lives of package maintainers, it is not a 
technical limitation imposed by FHS.

Sent from my iPhone

> On May 22, 2020, at 7:19 PM, Przemek Klosowski via devel 
>  wrote:
> 
> On 5/22/20 6:23 PM, Paul Dufresne via devel wrote:
>> So let's take an example:
>> 
>> At first you have:
>> /pkgs/programA_version1 that have a LD_LIBRARY_PATH that contains 
>> /pkgs/libX_version1
>> /pkgs/libX_version1 contains libX, version 1.
>> 
>> Now you "upgrade" libX vesion 2... because each packages is in it's own 
>> directory, you create a new directory:
>> /pkgs/libX_version2
>> but you do not erase /pkgs/libX_version1 because it is still used by at 
>> least one program, programA.
>> 
>> Note that if you were using FHS, you would have to give a version number to 
>> the library file itself, because else it would clash with the old one, 
>> because they would be it the same directory.
> 
> Yes, and there's nothing wrong with that! In FHS you have
> 
> /lib/libhogweed.so.4 -> libhogweed.so.4.5
>  /lib/libhogweed.so.4.5
> /lib/libhogweed.so.5 -> libhogweed.so.5.0
>  /lib/libhogweed.so.5.0
> 
> An application requiring any v.5 links to /lib/libhogweed.so.5 and allows 
> transparent upgrades from say 5.0 to 5.1, and the sad app that really depends 
> on 4.5 links specifically to /lib/libhogweed.so.4.5. Normally a major version 
> bump implies a significant API change, so it doesn't make sense to also have 
> /lib/libhogweed.so -> libhogweed.so.5 because it would be impossible to 
> assure future compatibility, but if someone came up with an API convention 
> that somehow handles this, it is in principle possible and would completely 
> decouple programs from system library versions.
> 
> 
>> 
>> Now, we eant to "upgrade" program A to version 2... that means we create:
>> /pkgs/programA_version2, while keeping programA_version1... because that's 
>> the way to upgrade in a system without FHS.
>> 
>> Now, the new /pkgs/programA_version2 is different than version 1 by the fact 
>> that it used the new pkgs/libX_version2 ... that is it's LIBRARY_PATH now 
>> contains pkgs/libX_version2, and not pkgs/libX_version1 anymore.
>> 
>> So you try the new version, it works. If nobody use programA_version1, you 
>> can delete pkgs/programA_version1 and pkgs/libX_version1 now. 
> 
> I think all the cases that you called out are handled with this scheme... and 
> it saves us from the DLL hell with different versions of libs all over the 
> place.
> ___
> 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

[Test-Announce] 2020-05-25 @ 15:00 UTC - Fedora QA Meeting

2020-05-22 Thread Adam Williamson

# Fedora Quality Assurance Meeting
# Date: 2020-05-25
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

We didn't meet last week, and there's some stuff to follow up on
from the previous meeting, so let's have a quick check in.

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 33 status and Changes
3. Test Day / community event status
4. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: The price of FHS

On Fri, May 22, 2020 at 4:37 PM Stephen John Smoogen  wrote:
>
>
>
> On Fri, 22 May 2020 at 15:59, Paul Dufresne via devel 
>  wrote:
>>
>> 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.
>>
>
> No the FHS was decided in the late 90's and early 2000's to keep from the way 
> that the Unix distros has split apart where things could be. In general some 
> of the items were based off older layouts but there were differences between 
> BSD unix and System V unix layouts also. Most of these differences were 
> mainly meant to make it so you had to script or write for Irix or HPUX-5 or 
> <> which made users, developers and 
> administrators very hard to work on.

It was also critical to the "dump" and "restore" backup systems of the
time, and bootstrapping new installations. It also helped segregate
partitions and filesystems so that they could be sensibly split up for
multiple disks, migrations to larger systems, and to allocate space
for bulky bundles like, say, Oracle over in /opt/ to keep its binaries
from replacing or getting confused with normal binaries of the same
names.

Part of the problem since then is when people each decide not to pay
any attention and invent their own schemes. Yes, I'm looking at you,
"flatpak".

> It was also to enforce things where you might find the distributor came with 
> a /usr/local/.. which you couldnt replace or a /opt/ which was 
> different from another /opt etc. It was also written for a time when you had 
> hundreds of users on a system and you wanted make sure that could get things 
> running.

Dear lord, yes. Don't get me started on "/home/apache" for Debian and
what it does to setting "/home" as an NFS mount.

> That said, it does limit some choices and layouts but it is mainly to avoid 
> the splintering effects so that I don't have to write a FedEx aware 
> program/script and a Nuix
>
> --
> 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

Re: fedpkg fork broken?

2020-05-22 Thread Aleksandra Fedorova

On Mon, 18 May 2020, 14:18 Richard Shaw,  wrote:

> I'm trying this for the first time (hadn't even noticed it was there!).
> I've been using the src.fp.o github style forking from the web.
>
> I cloned a random project of mine and then tried:
> $ fedpkg fork
> Could not execute do_distgit_fork: The following error occurred while
> creating a new fork: Invalid or expired token. Please visit
> https://src.fedoraproject.org/settings#nav-api-tab to get or renew your
> API token.
> For invalid or expired token refer to "fedpkg fork -h" to set a token in
> your user configuration.
>
> I checked src.fp.o/settings and even though my key was still valid, it was
> going to expire this month so I went ahead and generated a new api token
> and saved it in the specified location:
> ~/.config/rpkg/fedpkg.conf
>
> But I still get the same message 10 minutes later.
>

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

a...@pkgs.fedoraproject.org

Maybe it was working before, but then certain update happened.

If you check clone options in UI in Pagure interface, the url will look
like:

ssh://book...@pkgs.fedoraproject.org/forks/bookwar/rpms/minetest.git

There is no variant with "any".

The API token is valid and works, as the fork is created. It is only the
remote path which is broken.

So I ended up calling git remote explicitly after the fork command to
change the remote uri.

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.

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

2020-05-22 Thread Przemek Klosowski via devel


On 5/22/20 6:23 PM, Paul Dufresne via devel wrote:

So let's take an example:

At first you have:
/pkgs/programA_version1 that have a LD_LIBRARY_PATH that contains 
/pkgs/libX_version1

/pkgs/libX_version1 contains libX, version 1.

Now you "upgrade" libX vesion 2... because each packages is in it's 
own directory, you create a new directory:

/pkgs/libX_version2
but you do not erase /pkgs/libX_version1 because it is still used by 
at least one program, programA.


Note that if you were using FHS, you would have to give a version 
number to the library file itself, because else it would clash with 
the old one, because they would be it the same directory.


Yes, and there's nothing wrong with that! In FHS you have

/lib/libhogweed.so.4 -> libhogweed.so.4.5
 /lib/libhogweed.so.4.5
/lib/libhogweed.so.5 -> libhogweed.so.5.0
 /lib/libhogweed.so.5.0

An application requiring any v.5 links to /lib/libhogweed.so.5 and 
allows transparent upgrades from say 5.0 to 5.1, and the sad app that 
really depends on 4.5 links specifically to /lib/libhogweed.so.4.5. 
Normally a major version bump implies a significant API change, so it 
doesn't make sense to also have /lib/libhogweed.so -> libhogweed.so.5 
because it would be impossible to assure future compatibility, but if 
someone came up with an API convention that somehow handles this, it is 
in principle possible and would completely decouple programs from system 
library versions.





Now, we eant to "upgrade" program A to version 2... that means we create:
/pkgs/programA_version2, while keeping programA_version1... because 
that's the way to upgrade in a system without FHS.


Now, the new /pkgs/programA_version2 is different than version 1 by 
the fact that it used the new pkgs/libX_version2 ... that is it's 
LIBRARY_PATH now contains pkgs/libX_version2, and not 
pkgs/libX_version1 anymore.


So you try the new version, it works. If nobody use programA_version1, 
you can delete pkgs/programA_version1 and pkgs/libX_version1 now. 


I think all the cases that you called out are handled with this 
scheme... and it saves us from the DLL hell with different versions of 
libs all over the place.

___
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


On 5/22/20 3:54 PM, Michel Alexandre Salim wrote:

On 5/22/20 7:30 AM, Steve Grubb wrote:

Hello,

I am working on our application whitelisting daemon. It uses the rpmdb to
derive trust in what's on disk. If we use the whole rpmdb, then the 
number of
files is large. So, to prune the amount of entries in the trust db 
down to a

reasonable number, I thought we could jettison anything in /usr/share.

Any detail that's shareable about this application whitelisting daemon? 
At work we're looking for a similar solution -- we're using Santa for 
our macOS clients but need something for Linux.


I knew I should have finished reading the thread, because this is asked 
and answered. Will be checking out the GitHub repo and see if this is 
something our security teams are interested in!


Cheers,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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


On 5/22/20 7:30 AM, Steve Grubb wrote:

Hello,

I am working on our application whitelisting daemon. It uses the rpmdb to
derive trust in what's on disk. If we use the whole rpmdb, then the number of
files is large. So, to prune the amount of entries in the trust db down to a
reasonable number, I thought we could jettison anything in /usr/share.

Any detail that's shareable about this application whitelisting daemon? 
At work we're looking for a similar solution -- we're using Santa for 
our macOS clients but need something for Linux.


Cheers,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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

2020-05-22 Thread Kevin Kofler

Steve Grubb wrote:
> But what I'm finding in practice is that cinnamon places its javascript
> there, there are libexec dirs that contain executable code, there are
> python and byte compiled python over there. In short, the system doesn't
> work because critical executables are in /usr/share.
> 
> The question is what should be done about this? Do we care that things are
> in /usr/share that are not following the Filesystem Hierarchy Standard? If
> we do, what is the proper fix this this? Should bz be opened against each
> component?

/usr/share is the correct place for architecture-independent files, 
including binaries and scripts. Though in principle, files that are 
executable directly (+x bit set) should be in /usr/libexec (if they are to 
be executed only by programs) or /usr/bin (if they should be executable 
directly by the user) rather than /usr/share. But they may load additional 
architecture-independent code (e.g., libraries, modules, plugins) from 
/usr/share.

/usr/lib is actually the wrong place for architecture-independent (and thus 
non-multilib) files, though unfortunately it is constantly getting abused 
for them. (IMHO, any file under /usr/lib on a pure 64-bit system on a 
multilib arch (such as x86_64) is a bug, but even systemd now abuses that 
directory that way. IMHO, everything that does not need to be multilibbed 
into /usr/lib and /usr/lib64 should be either in /usr/share or in 
/usr/libexec instead.)

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

[Bug 1839251] perl-Regexp-Grammars-1.057 is available

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Regexp-Grammars-1.056  |perl-Regexp-Grammars-1.057
   |is available|is available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.057
Current version/release in rawhide: 1.055-1.fc33
URL: http://search.cpan.org/dist/Regexp-Grammars/

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


-- 
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: The price of FHS

2020-05-22 Thread Paul Dufresne via devel


On 5/22/20 4:22 PM, Parker Gibson wrote:

I don’t think this is specifically about FHS as it is about shared library 
management. The underlying hierarchy defined in FHS doesn’t make the dictations 
about version management that you seem to indicate, nor are the major problems 
with maintaining multiple api compatible versions of shared libraries solved 
with a new hierarchy.


Ok... I am a novice about shared libraries... but here I think how it is 
supposed to work... more or less in Nix.


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.


So let's take an example:

At first you have:

/pkgs/programA_version1 that have a LD_LIBRARY_PATH that contains 
/pkgs/libX_version1


/pkgs/libX_version1 contains libX, version 1.

Now you "upgrade" libX vesion 2... because each packages is in it's own 
directory, you create a new directory:


/pkgs/libX_version2

but you do not erase /pkgs/libX_version1 because it is still used by at 
least one program, programA.


Note that if you were using FHS, you would have to give a version number 
to the library file itself, because else it would clash with the old 
one, because they would be it the same directory.


Now, we eant to "upgrade" program A to version 2... that means we create:

/pkgs/programA_version2, while keeping programA_version1... because 
that's the way to upgrade in a system without FHS.


Now, the new /pkgs/programA_version2 is different than version 1 by the 
fact that it used the new pkgs/libX_version2 ... that is it's 
LIBRARY_PATH now contains pkgs/libX_version2, and not pkgs/libX_version1 
anymore.


So you try the new version, it works. If nobody use programA_version1, 
you can delete pkgs/programA_version1 and pkgs/libX_version1 now.




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

Re: Aggressive updating (Python 3.9): Are we trying to hard?

2020-05-22 Thread Kevin Kofler

Miroslav Suchý wrote:
> Dne 19. 05. 20 v 14:03 Richard Shaw napsal(a):
>> Because Qt 5.13.x / PySide2 5.13.x is NOT compatible with Python 3.8. But
>> instead of asking ourselves, "should we push in the VERY latest Python
>> and hope it's ok?", we just patch the build system to accept it anyway
>> and hope for the best.
>> 
>> Qt (et all) is a pretty organized upstream, so when asked about Python
>> 3.8 support in 5.13.x, they said, "Nope. Wait for 5.14.x."
>> 
> 
> BTW this is scholar example of use-case for Modularity.

No, this is actually exactly the scholar example of NON-use-case for 
Modularity.

As others have already explained, you just cannot replace Python with an 
older version from a module. That will break the entire distribution. Even 
DNF will stop working, unless you rebuild that too. But rebuilding all the 
Python packages in Fedora against the old version just does not scale.

This is the scholar example of use-case for parallel-installable 
compatibility packages (python3.7 and a python3.7-* for each dependency of 
FreeCAD, while all the other python3-* do not have to be touched at all).

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

LLVMgold.so: wrong ELF class: ELFCLASS32

2020-05-22 Thread Sandro Mani


Hi

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?


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

Re: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7


Am 22.05.20 um 23:16 schrieb Felix Schwarz:
> We should push broken updates to EPEL 7/F31.

obviously this should read "We should NOT push broken updates" ;-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7


Am 22.05.20 um 23:16 schrieb Felix Schwarz:
> We should push broken updates to EPEL 7/F31.

obviously this should read "We should NOT push broken updates" ;-)
___
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: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7

Hey,

seems like you already built libb2?

I hoped we could coordinate the update a bit more so there won't be any
breakage. I just added buildroot override (still waiting for it to become
active) and I can rebuild borgbackup.

I hoped you could do the koji build and then dependent packages would be
rebuilt either by you with provenpackager powers or by the packager
maintainers. Afterwards you would create a single koji update.

Do you know if the gtkhash maintainers are ready for a rebuild? There are no
related commits: https://src.fedoraproject.org/rpms/gtkhash

-> Please ensure the current update does not go to stable so all dependent
   packages can be rebuilt + added to the update. (Please disable auto-stable
   by karma and time)

We should push broken updates to EPEL 7/F31.

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

[EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7

Hey,

seems like you already built libb2?

I hoped we could coordinate the update a bit more so there won't be any
breakage. I just added buildroot override (still waiting for it to become
active) and I can rebuild borgbackup.

I hoped you could do the koji build and then dependent packages would be
rebuilt either by you with provenpackager powers or by the packager
maintainers. Afterwards you would create a single koji update.

Do you know if the gtkhash maintainers are ready for a rebuild? There are no
related commits: https://src.fedoraproject.org/rpms/gtkhash

-> Please ensure the current update does not go to stable so all dependent
   packages can be rebuilt + added to the update. (Please disable auto-stable
   by karma and time)

We should push broken updates to EPEL 7/F31.

Felix
___
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: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

2020-05-22 Thread Dan Čermák

Hi Sérgio,

Sérgio Basto  writes:

> Hi,
>
> On Tue, 2020-04-14 at 11:09 +0100, Peter Robinson wrote:
>> > On 14. 04. 20 11:06, Miro Hrončok wrote:
>> > > The following packages are orphaned...
>> > > 
>> > > GConf2alexl, caillon,
>> > > caolanm, 1 weeks ago
>> > 
>> > firefox (maintained by: alexl, caolanm, gecko-maint,
>> > jgrulich, kalev, kengert,
>> > mbarnes, rhughes, rstrode, sharkcz, stransky, ueno, xhorak)
>> > firefox-75.0-1.fc33.src requires pkgconfig(gconf-
>> > 2.0) = 3.2.6
>> > 
>> > thunderbird (maintained by: alexl, caolanm, gecko-maint,
>> > johnp, kalev, kengert,
>> > mbarnes, rhughes, rstrode, ssp, stransky, ueno, xhorak)
>> > thunderbird-68.7.0-1.fc33.src requires GConf2-devel 
>> > = 3.2.6-27.fc31
>> > 
>> > icecat (maintained by: jenslody, kengert, sagitter)
>> > icecat-68.7.0-1.rh1.fc33.src requires
>> > pkgconfig(gconf-2.0) = 3.2.6
>> > 
>> > 
>> > This seems like a forgotten dependency. At least thunderbird builds
>> > fine without
>> > GConf2.
>> 
>> I bet it was a leftover from the migration to gsettings with the
>> gsettings-data-convert script, I suspect all the runtime deps
>> (anaconda too) is around this and can probably be dropped.
>
> GConf2 is not Orphan anymore , but I'd like migrate rawstudio in
> particular to gsettings , where I can find some examples of this
> migration ? 
> What we need ? change code ? , change build requires ? or what ?

You'll need to change the code and the BuildRequires. This guide should
be a decent start for the code changes:
https://developer.gnome.org/gio/stable/ch34.html


Hope this helps,

Dan


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

[Bug 1839251] New: perl-Regexp-Grammars-1.056 is available

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

Bug ID: 1839251
   Summary: perl-Regexp-Grammars-1.056 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Regexp-Grammars
  Keywords: FutureFeature, Triaged
  Assignee: wf...@worldbroken.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
wf...@worldbroken.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.056
Current version/release in rawhide: 1.055-1.fc33
URL: http://search.cpan.org/dist/Regexp-Grammars/

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


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

On Friday, May 22, 2020 3:19:20 PM EDT David Malcolm wrote:
> Your email talks about "application whitelisting" and "executables",
> and this thread seems to be getting in to the weeds about things like
> the distinction between scripts vs machine code, and modules vs
> scripts; code vs data.

But it's real. I was just curious if there was some kind of standard that we 
should be following that says where to expect obvious code such as all the 
python and javascript so that these do not get dropped.

> Would it be helpful to approach this from a higher-level point of view?
> Presumably your goal is to enforce some kind of security boundary,
> along the lines of "only blessed things can be run".  What is that
> boundary? 

The boundary is known things.

> What kinds of threat do you have in mind, and how might this
> whitelisting daemon block them?  (is there a web page somewhere for the
> project?)   (also: what's the user experience?)

It uses fanotify which is a hook made for virus scanners to make a decision. 
It checks the file to see if we know anything about it and what policy says to 
do. It's designed to answer the singular question of: is this file known?

> Some more awkward examples, in case these haven't already been
> mentioned in the thread:
> 
> - what about machine code plugins to existing binaries?
> 
> - what about Python modules that aren't executable scripts, but which
> are in the import path and might be used by executable scripts? (and
> which might modify the import path)
> 
> - what about embedded interpreters?

I'm dropping most of /usr/share. So, if it's not in the trust database, its 
not running. That is safe, but you might have wanted cinnamon to start up. 
So, this is more about adding back to the trust db that which is needed, but 
nothing more.

Another thing weird I'm finding is there is a lot of matlab and numpy files 
with execute bits turn on as well as test suites that could be separately 
packaged.

-Steve

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

Re: Location of executable code

On Friday, May 22, 2020 4:23:50 PM EDT Przemek Klosowski via devel wrote:
> On 5/22/20 1:24 PM, Nico Kadel-Garcia wrote:
> 
> > On Fri, May 22, 2020 at 10:31 AM Steve Grubb  wrote:
> > 
> >> I am working on our application whitelisting daemon.
> 
> Interesting concept---could you please elaborate on your design? It 
> sounds useful but also challenging, as Nico points out.

There is some information about it here:
https://static.sched.com/hosted_files/lssna19/ce/application-whitlisting-sgrubb.pdf

From the speech I gave at the Linux Security Summit last August. The design 
has evolved quite a bit from then. And the 1.0 release should be coming up 
this weekend.

More info on the project page:
https://github.com/linux-application-whitelisting/fapolicyd

If you wanted to try it out, I'd recommend the github copy. This one can do 
integrity enforcement and even teamed up with IMA so they cross check each 
other by validating IMA's xattrs with rpmdb's info.

> On what level do you plan to whitelist---kernel/syscall? shell? all
> shells?

execute or open permision request.

> >>   It uses the rpmdb to
> >> 
> >> derive trust in what's on disk. If we use the whole rpmdb, then the
> >> number of
 files is large. So, to prune the amount of entries in the
> >> trust db down to a reasonable number, I thought we could jettison
> >> anything in /usr/share.> 
> > I think that you're being very optimistic. Python modules, for
> > instance, include executable scripts in their documentation stored in
> > /usr/share/doc/
> 
> 
> In general, data is code is data. 

I know this argument well (Weird Machines). I was making the same argument 10 
years ago.  :-)  But hairs have to be split and uninteresting files dropped.

-Steve

> For instance, any configuration file 
> can be seen as essentially a data-driven execution which, if you squint 
> hard, is theoretically exploitable just like an interpreter reading a 
> shell program. They just live on different points of the same spectrum: 
> on one end, the shell will read 'rm a' and delete file 'a', while a 
> hypothetical application might have a configuration file like this:
> 
> data-source /dev/null
> 
> data-output a
> 
> and the end result will be (almost) the same.
> 
> As another example I used to write configuration for Tcl scripts as Tcl 
> code; then, reading/parsing config scripts was just open/read/eval. If 
> this revolts you, please consider that Tcl has a simple verb-noun syntax 
> that makes such files readable and nice to use, as well as a nice 
> sandboxing mechanism that can be used to defang eval if needed (I didn't 
> care that much because I was writing for in-house use, but it could be 
> used to write a secure application if that was the concern).
> ___
> 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/de...@lists.fedoraproject.or
> g



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

Re: Self Introduction: Andrzej Bylicki (Andy Mender)

2020-05-22 Thread David Kirwan

HI Andy!

On Tue, 19 May 2020 at 15:55, Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> Hello, Andy!
>
> On Monday, 18 May 2020 at 22:37, Andy Mender wrote:
> > Hello everyone!
> >
> > Introduction:
> > After reading the Fedora docs on packaging, I decided I would like to
> join
> > the Fedora project initially as a package maintainer/reviewer and perhaps
> > later as a source code committer. Here's the bug report for the package
> I'd
> > like to revive/unorphan:
> https://bugzilla.redhat.com/show_bug.cgi?id=1837107
>
> Welcome to Fedora! I put in some drive-by comments.
>
> 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
>


-- 
David Kirwan
Software Engineer

Community Platform Engineering @ Red Hat

T: +(353) 86-8624108 IM: @dkirwan
___
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

2020-05-22 Thread Stephen John Smoogen

On Fri, 22 May 2020 at 15:59, Paul Dufresne via devel <
devel@lists.fedoraproject.org> wrote:

> 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.
>
>
No the FHS was decided in the late 90's and early 2000's to keep from the
way that the Unix distros has split apart where things could be. In general
some of the items were based off older layouts but there were differences
between BSD unix and System V unix layouts also. Most of these differences
were mainly meant to make it so you had to script or write for Irix or
HPUX-5 or <> which made users,
developers and administrators very hard to work on.

It was also to enforce things where you might find the distributor came
with a /usr/local/.. which you couldnt replace or a /opt/ which was
different from another /opt etc. It was also written for a time when you
had hundreds of users on a system and you wanted make sure that could get
things running.

That said, it does limit some choices and layouts but it is mainly to avoid
the splintering effects so that I don't have to write a FedEx aware
program/script and a Nuix

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

2020-05-22 Thread Przemek Klosowski via devel


On 5/22/20 1:24 PM, Nico Kadel-Garcia wrote:

On Fri, May 22, 2020 at 10:31 AM Steve Grubb  wrote:

I am working on our application whitelisting daemon.


Interesting concept---could you please elaborate on your design? It 
sounds useful but also challenging, as Nico points out.


On what level do you plan to whitelist---kernel/syscall? shell? all shells?


  It uses the rpmdb to
derive trust in what's on disk. If we use the whole rpmdb, then the number of
files is large. So, to prune the amount of entries in the trust db down to a
reasonable number, I thought we could jettison anything in /usr/share.

I think that you're being very optimistic. Python modules, for
instance, include executable scripts in their documentation stored in
/usr/share/doc/


In general, data is code is data. For instance, any configuration file 
can be seen as essentially a data-driven execution which, if you squint 
hard, is theoretically exploitable just like an interpreter reading a 
shell program. They just live on different points of the same spectrum: 
on one end, the shell will read 'rm a' and delete file 'a', while a 
hypothetical application might have a configuration file like this:


data-source /dev/null

data-output a

and the end result will be (almost) the same.

As another example I used to write configuration for Tcl scripts as Tcl 
code; then, reading/parsing config scripts was just open/read/eval. If 
this revolts you, please consider that Tcl has a simple verb-noun syntax 
that makes such files readable and nice to use, as well as a nice 
sandboxing mechanism that can be used to defang eval if needed (I didn't 
care that much because I was writing for in-house use, but it could be 
used to write a secure application if that was the concern).

___
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

2020-05-22 Thread Parker Gibson

I don’t think this is specifically about FHS as it is about shared library 
management. The underlying hierarchy defined in FHS doesn’t make the dictations 
about version management that you seem to indicate, nor are the major problems 
with maintaining multiple api compatible versions of shared libraries solved 
with a new hierarchy. As for hierarchal path collision, maintainers are 
constantly patching around a package’s default paths as it is, and there are 
always distribution specific hierarchy quirks that are patched for. It really 
isn’t infeasible just due to FHS, and as far as I understand it, modularity 
isn’t a salvation that will allow multi-version shared libraries to co-exist.
Can you elaborate about what programs depend on these old library versions? I 
think generally speaking, when software depends on older libraries it is 
abandoned/unmaintained. If the library has important functionality isn’t it 
best to support efforts to revive development in the first place?

Sent from my iPhone

> On May 22, 2020, at 2:58 PM, Paul Dufresne via devel 
>  wrote:
> 
> 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

The price of FHS

2020-05-22 Thread Paul Dufresne via devel

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

[389-devel] please review: PR 51111 - Fix ASAN ODR warnings

2020-05-22 Thread Mark Reynolds


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

--

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

2020-05-22 Thread Stephen John Smoogen

On Fri, 22 May 2020 at 15:20, David Malcolm  wrote:

> On Fri, 2020-05-22 at 10:30 -0400, Steve Grubb wrote:
> > Hello,
> >
> > I am working on our application whitelisting daemon. It uses the
> > rpmdb to
> > derive trust in what's on disk. If we use the whole rpmdb, then the
> > number of
> > files is large. So, to prune the amount of entries in the trust db
> > down to a
> > reasonable number, I thought we could jettison anything in
> > /usr/share.
> >
> ...
> > Best Regards,
> > -Steve
> >
> >
> > 1 - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html
>
> Hi Steve
>
> Your email talks about "application whitelisting" and "executables",
> and this thread seems to be getting in to the weeds about things like
> the distinction between scripts vs machine code, and modules vs
> scripts; code vs data.
>
>
For various security audits.. it actually isn't in the weeds. The general
want will be that everything that could be executable is known and in
places that are easily checked/removed by say a Private First Class without
much training but a book that says rm -rf /usr/share-execs/. IN most cases
it is more the ability to say that these files can be also checked by
various tools

And yes this does mean the removal/audit etc of
pdf/postscript
bash scripts
python/perl/etc



> Would it be helpful to approach this from a higher-level point of view?
> Presumably your goal is to enforce some kind of security boundary,
> along the lines of "only blessed things can be run".  What is that
> boundary?  What kinds of threat do you have in mind, and how might this
> whitelisting daemon block them?  (is there a web page somewhere for the
> project?)   (also: what's the user experience?)
>
> Some more awkward examples, in case these haven't already been
> mentioned in the thread:
>
> - what about machine code plugins to existing binaries?
>
> - what about Python modules that aren't executable scripts, but which
> are in the import path and might be used by executable scripts? (and
> which might modify the import path)
>
> - what about embedded interpreters?
>
> Hope this is constructive
> Dave
> ___
> 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: Location of executable code

2020-05-22 Thread David Malcolm

On Fri, 2020-05-22 at 10:30 -0400, Steve Grubb wrote:
> Hello,
> 
> I am working on our application whitelisting daemon. It uses the
> rpmdb to 
> derive trust in what's on disk. If we use the whole rpmdb, then the
> number of 
> files is large. So, to prune the amount of entries in the trust db
> down to a 
> reasonable number, I thought we could jettison anything in
> /usr/share.
> 
> According to the Filesystem Hierarchy Standard [1] it says this about
> /usr/
> share:
> 
> The /usr/share hierarchy is for all read-only architecture
> independent data 
> files.
> 
> But what I'm finding in practice is that cinnamon places its
> javascript there, 
> there are libexec dirs that contain executable code, there are python
> and 
> byte compiled python over there. In short, the system doesn't work
> because 
> critical executables are in /usr/share.
> 
> The question is what should be done about this? Do we care that
> things are in 
> /usr/share that are not following the Filesystem Hierarchy Standard?
> If we 
> do, what is the proper fix this this? Should bz be opened against
> each 
> component?
> 
> Best Regards,
> -Steve
> 
> 
> 1 - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html

Hi Steve

Your email talks about "application whitelisting" and "executables",
and this thread seems to be getting in to the weeds about things like
the distinction between scripts vs machine code, and modules vs
scripts; code vs data.

Would it be helpful to approach this from a higher-level point of view?
Presumably your goal is to enforce some kind of security boundary,
along the lines of "only blessed things can be run".  What is that
boundary?  What kinds of threat do you have in mind, and how might this
whitelisting daemon block them?  (is there a web page somewhere for the
project?)   (also: what's the user experience?)

Some more awkward examples, in case these haven't already been
mentioned in the thread:

- what about machine code plugins to existing binaries?

- what about Python modules that aren't executable scripts, but which
are in the import path and might be used by executable scripts? (and
which might modify the import path)

- what about embedded interpreters?

Hope this is constructive
Dave
___
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

2020-05-22 Thread Nicolas Mailhot via devel

Le vendredi 22 mai 2020 à 10:30 -0400, Steve Grubb a écrit :
> The /usr/share hierarchy is for all read-only architecture
> independent data 
> files.

The important part of the FHS definition is “read-only architecture
independent“. Because everything on computing storage is data depending
on how you look at it.

Practically, people have been putting “read-only architecture
independent“ executable data in  /usr/share forever. Not just
javascript. Java bytecode, xslt programs, scheme programs, go code, etc
(in the Java & Go cases I’ve also seen architecture dependant data leak
in here, though I intend to fix the leaking oneway or another in the
next generation of Go packaging).

If you want to split hairs we also install fonts there, and OpenType
fonts contain instructions that will be executed by the text renderer,
and malicious fonts have triggered security problems in the past.

So, no use looking for non-executable /usr/share. A lot of /usr/share
is executable and will stay that way.

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: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)


On Thu, May 21, 2020 at 18:46:14 -0400,
 Dennis Payne  wrote:

The reason for the crashing on startup is that it is not loading the
font.


I have fixes for this out. Even though this currently just affects rawhide, 
I have fixed builds for f31 and f32 as well, so if a font file moves a 
simple rebuild will fix things.

___
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: Increasing the packaging team: regular workshops/vFADs/classroom sessions on packaging

2020-05-22 Thread Eduard Lucena

Hello,

As part of the marketing team, I think we could put a community campaign,
with a video series (series means at least 3) posted properly on YouTube
and promoted by Twitter, CommBlog and ML:

"Package with us!"

Wdyt!

Br,

El jue., 21 may. 2020 a las 6:12, Ankur Sinha ()
escribió:

> On Thu, May 21, 2020 09:16:40 -, Artur Iwicki wrote:
> > I've written blog posts about packaging and gave a talk about it on a
> > local Linux group, so I'd be glad to participate in workshops or some
> > other initiative.
> >
> > One idea that comes to my mind right now is - how about making a video
> > tutorial? While I personally dislike those and prefer text, I know
> > many people like videos for learning, so it might be a worthwhile
> > investment.
>
> That would be great. Any material that walks people through packaging is
> useful.
>
> If at all possible, I'd like to have classroom sessions---there's
> something about a live session that encourages people to get involved.
> Reading docs and watching videos to self learn lacks the "getting to
> know the community" aspect.
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> 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
>


-- 
Eduard Lucena
Móvil: +56962318010
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative
___
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag


On 22. 05. 20 20:05, Adam Williamson wrote:

On Fri, 2020-05-22 at 19:57 +0200, Miro Hrončok wrote:

On 22. 05. 20 19:23, Adam Williamson wrote:

So a request here: once the rebuilds are done, before we consider
moving them to Rawhide proper, can we have releng run a test compose
using the side tag and run openQA on it, to test for bugs in the
installer or key critpath components caused by the 3.9 changes? I don't
see anything about this in the Change page:
https://fedoraproject.org/wiki/Changes/Python3.9
but I think it'd be good to catch at least any major issues before we
land the change rather than after...


I am all in if this is possible.

When we updated to Python 3.7 I wanted to do it, but I was told it was not 
possible.

When we updated to Python 3.8, I've asked around once again, but was still not
possible.


ah, fun :/

we should at *least* be able to hack it up manually or in openQA,
though it may be ugly. if releng still can't do it, let me know and
I'll see if I can work something out.


https://pagure.io/releng/issue/9467

--
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

2020-05-22 Thread Adam Williamson

On Fri, 2020-05-22 at 19:57 +0200, Miro Hrončok wrote:
> On 22. 05. 20 19:23, Adam Williamson wrote:
> > So a request here: once the rebuilds are done, before we consider
> > moving them to Rawhide proper, can we have releng run a test compose
> > using the side tag and run openQA on it, to test for bugs in the
> > installer or key critpath components caused by the 3.9 changes? I don't
> > see anything about this in the Change page:
> > https://fedoraproject.org/wiki/Changes/Python3.9
> > but I think it'd be good to catch at least any major issues before we
> > land the change rather than after...
> 
> I am all in if this is possible.
> 
> When we updated to Python 3.7 I wanted to do it, but I was told it was not 
> possible.
> 
> When we updated to Python 3.8, I've asked around once again, but was still 
> not 
> possible.

ah, fun :/

we should at *least* be able to hack it up manually or in openQA,
though it may be ugly. if releng still can't do it, let me know and
I'll see if I can work something out.
-- 
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag


On 22. 05. 20 19:23, Adam Williamson wrote:

So a request here: once the rebuilds are done, before we consider
moving them to Rawhide proper, can we have releng run a test compose
using the side tag and run openQA on it, to test for bugs in the
installer or key critpath components caused by the 3.9 changes? I don't
see anything about this in the Change page:
https://fedoraproject.org/wiki/Changes/Python3.9
but I think it'd be good to catch at least any major issues before we
land the change rather than after...


I am all in if this is possible.

When we updated to Python 3.7 I wanted to do it, but I was told it was not 
possible.

When we updated to Python 3.8, I've asked around once again, but was still not 
possible.


--
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: looking for scipy on python 3.8 (RISCV Fedora Release 32)

2020-05-22 Thread David Abdurachmanov

On Fri, May 22, 2020 at 5:57 PM Arun Sukumaran Latha
 wrote:
>
> Thanks David for looking into the same.
>
> One more package I would need help build in fedora riscv for ultimately 
> getting tensorflow compiled.
>
> The other dependency is:
> h5py<2.11.0,>=2.10.0
>
> I did try getting the latest one available at 
> http://fedora.riscv.rocks/koji/buildinfo?buildID=149390, but that is 2.9 
> version and I will need at-least 2.10 of the same for tensorflow.
>
> Let me know if that could be compiled as well.

Built: http://fedora.riscv.rocks/koji/buildinfo?buildID=158506

Protobuf is not done yet. There seems to a regression in GCC 10 that
causes the latest release (and a master branch) to fail.

I will see if I can overcome it this weekend.

Cheers,
david

>
> Regards,
> Arun SL
>
> On Mon, May 18, 2020 at 11:11 PM David Abdurachmanov 
>  wrote:
>>
>> On Mon, May 18, 2020 at 7:45 PM Arun Sukumaran Latha
>>  wrote:
>> >
>> > Yes please,  do let me know if we can build thos one.
>> >
>>
>> I will let you know.
>>
>> I found some dependencies misaligned due to some packages failing to
>> build or failing to pass tests.
>> I am slowly rebuilding/checking those, but that will take some time.
>>
>> Cheers,
>> david
>>
>> > Regards,
>> > Arun SL
>> >
>> > On Sun, May 17, 2020, 17:25 David Abdurachmanov 
>> >  wrote:
>> >>
>> >> On Sun, May 17, 2020 at 1:52 PM Arun Sukumaran Latha
>> >>  wrote:
>> >> >
>> >> > Thanks David,
>> >> >
>> >> > That helped a lot.
>> >> >
>> >> > But unfortunately, we have ran into the next issue ie. wrt  grpcio.
>> >> >
>> >> > [riscv@fedora-riscv tensorflow_pkg]$ sudo dnf install python3-grpcio
>> >> > Last metadata expiration check: 0:17:52 ago on Sun 17 May 2020 06:20:36 
>> >> > AM EDT.
>> >> > Error:
>> >> >  Problem: conflicting requests
>> >> >   - nothing provides libpython3.7m.so.1.0()(64bit) needed by 
>> >> > python3-grpcio-1.20.1-2.fc31.riscv64
>> >> >   - nothing provides python(abi) = 3.7 needed by 
>> >> > python3-grpcio-1.20.1-2.fc31.riscv64
>> >> >   - nothing provides python3.7dist(six) >= 1.5.2 needed by 
>> >> > python3-grpcio-1.20.1-2.fc31.riscv64
>> >> >
>> >> > I tried following 
>> >> > http://fedora.riscv.rocks/koji/packageinfo?packageID=23014
>> >> > but still do not see the same available for Python 3.8
>> >> >
>> >> > let me know if you can help me here as well.
>> >>
>> >> This particular package failed to build last time (compile time errors).
>> >> I can give a look into it.
>> >>
>> >> Cheers,
>> >> david
>> >>
>> >> >
>> >> > Regards,
>> >> > Arun SL
>> >> >
>> >> > On Sun, May 17, 2020 at 2:02 PM David Abdurachmanov 
>> >> >  wrote:
>> >> >>
>> >> >> On Sat, May 16, 2020 at 8:26 PM Arun Sukumaran Latha
>> >> >>  wrote:
>> >> >> >
>> >> >> > Hello All,
>> >> >> >
>> >> >> > I was working on getting tensorflow compiled within the RISCV Fedora 
>> >> >> > environment.
>> >> >> > I am using the latest release 32 build.
>> >> >> > Currently I am unable to install the dependent library, scipy due to 
>> >> >> > the same not being available for python 3.8.1 which is currently 
>> >> >> > installed.
>> >> >> >
>> >> >> > [riscv@fedora-riscv ~]$ sudo dnf install python3-scipy
>> >> >> > Last metadata expiration check: 0:22:10 ago on Sat 16 May 2020 
>> >> >> > 12:02:37 PM EDT.
>> >> >> > Error:
>> >> >> >  Problem: conflicting requests
>> >> >> >   - nothing provides libpython3.7m.so.1.0()(64bit) needed by 
>> >> >> > python3-scipy-1.1.0-3.0.riscv64.fc29.riscv64
>> >> >> >   - nothing provides python(abi) = 3.7 needed by 
>> >> >> > python3-scipy-1.1.0-3.0.riscv64.fc29.riscv64
>> >> >> > (try to add '--skip-broken' to skip uninstallable packages)
>> >> >> > [riscv@fedora-riscv ~]$ cat /etc/redhat-release
>> >> >> > Fedora release 32 (Rawhide)
>> >> >> > [riscv@fedora-riscv ~]$ python3 --version
>> >> >> > Python 3.8.1
>> >> >> >
>> >> >> > Can you please let me know if we can have the same soon?
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> I have rebuilt scipy to Python 3.8 in Fedora/RISCV during mass rebuild
>> >> >> for GCC 10, but it's not yet available directly from distro
>> >> >> repository.
>> >> >>
>> >> >> You would need to install it directly from Fedora/RISCV Koji instance:
>> >> >> http://fedora.riscv.rocks/koji/buildinfo?buildID=156446
>> >> >>
>> >> >> 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
>> >> >
>> >> > ___
>> >> > devel mailing list -- devel@lists.fedoraproject.org
>> >> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: TeXLive 2020 landing in rawhide


On 22. 05. 20 13:51, Fabio Valentini wrote:

According to koschei, the graphite2 BuildRequires now pull in *about
300 more (tex + perl) packages than before the 2020 update*, which is
slightly concerning?
See:https://koschei.fedoraproject.org/build/8369713


I also believe this makes the Python Clasrrom Lab not fit in the (arguably 
artificial) size limit:


https://pagure.io/releng/failed-composes/issue/1467

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

2020-05-22 Thread Florian Weimer

* Petr Viktorin:

> Does "read-only architecture independent data" mean the files must not
> be programs?

Not according to the FHS.  From the FHS perspective, /usr/share is just
like RPM's noarch architecture: completely portable across all
architectures.  It can even be machine code if it does not need
customization based on host processor architecture (e.g., firmware for
some peripheral device).

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

On Fri, May 22, 2020 at 10:31 AM Steve Grubb  wrote:
>
> Hello,
>
> I am working on our application whitelisting daemon. It uses the rpmdb to
> derive trust in what's on disk. If we use the whole rpmdb, then the number of
> files is large. So, to prune the amount of entries in the trust db down to a
> reasonable number, I thought we could jettison anything in /usr/share.

I think that you're being very optimistic. Python modules, for
instance, include executable scripts in their documentation stored in
/usr/share/doc/
___
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

2020-05-22 Thread Adam Williamson

On Fri, 2020-05-22 at 03:06 +0200, Miro Hrončok wrote:
> Hello, in order to deliver Python 3.9, we are running a coordinated rebuild 
> in a 
> side tag.
> 
>  https://fedoraproject.org/wiki/Changes/Python3.9
> 
> If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
> please don't rebuild it in regular rawhide.
> If you need to, please let me know, so we can coordinate.
> 
> If you'd like to build the package, you should be able to build it in the 
> side 
> tag via:
> 
>  on branch master:
>  $ fedpkg build --target=f33-python
>  $ koji wait-repo f33-python --build 
> 
> Note that it will take a while before all the essential packages are rebuilt, 
> so 
> don't except all your dependencies to be available right away. When in 
> trouble, 
> ask here or on IRC (#fedora-python on Freenode).
> 
> Builds: 
> https://koji.fedoraproject.org/koji/builds?latest=0=22287=-build_id=0
> 
> Please avoid any potentially disturbing changes in Python packages until the 
> rebuild is over.

So a request here: once the rebuilds are done, before we consider
moving them to Rawhide proper, can we have releng run a test compose
using the side tag and run openQA on it, to test for bugs in the
installer or key critpath components caused by the 3.9 changes? I don't
see anything about this in the Change page:
https://fedoraproject.org/wiki/Changes/Python3.9
but I think it'd be good to catch at least any major issues before we
land the change rather than after...
-- 
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: Location of executable code

2020-05-22 Thread Petr Viktorin


On 2020-05-22 17:31, Steve Grubb wrote:

On Friday, May 22, 2020 10:39:43 AM EDT Petr Viktorin wrote:

On 2020-05-22 16:30, Steve Grubb wrote:

Hello,

I am working on our application whitelisting daemon. It uses the rpmdb to
derive trust in what's on disk. If we use the whole rpmdb, then the
number of files is large. So, to prune the amount of entries in the
trust db down to a reasonable number, I thought we could jettison
anything in /usr/share.

According to the Filesystem Hierarchy Standard [1] it says this about
/usr/ share:

The /usr/share hierarchy is for all read-only architecture independent
data files.

But what I'm finding in practice is that cinnamon places its javascript
there, there are libexec dirs that contain executable code, there are
python and byte compiled python over there. In short, the system doesn't
work because critical executables are in /usr/share.

The question is what should be done about this? Do we care that things
are in /usr/share that are not following the Filesystem Hierarchy
Standard? If we do, what is the proper fix this this? Should bz be
opened against each component?


Does "read-only architecture independent data" mean the files must not
be programs?


I personally think of data and applications/modules/libraries as distinct
entities.


Javascript, Python scripts and Python bytecode are all read-only and
architecture independent.


But they are not data. What I'm trying to do is constrain the notion of what
can be executed.


Interesting. Where do you draw the line?

I guess /usr/lib*/python3.*/pydoc_data/topics.py is not data?
What about a YAML file? An Ansible playbook? A PostScript image?
A JavaScript file intended to be minified and sent to a browser?

Not that those are very practical questions. I'm just curious.


And everything on disk is data.
The document you linked explicitly gives troff macros and "perl" as
examples of what goes in /usr/share/.


Indeed it does. But it also suggests /usr/lib as another home for that. If
there was a /usr/share/code  or /usr/share/perl or some convention like that,
it would make the job easier because applications are discoverable. Instead
they are hidden and in unexpected places. And its hard to tell what are
example programs from something that the system depends on. There needs to be
clarity about the intentions of any system code that lives in /usr/share. At
least the libexec dirs are obvious. Is it possible to make this system code
discoverable?


Possible, but not easy. There's currently no clear distinction, and even 
if you come up with a clear spec, it won't be easy to move all the files.




-Steve


IMO, /usr/share/ would be a better place for *all* pure-Python modules
than /usr/lib/, where they are now. The main reason they weren't moved
is that the move would cause a lot of disruption.


1 - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html

___
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: fwupd / LVFS RFE: classifying updates?




On 5/20/20 11:15 AM, Richard Hughes wrote:

On Wed, May 20, 2020 at 6:58 PM Michel Alexandre Salim
 wrote:

For normal packages, we just set up dnf-automatic to automatically apply
security updates. Would it be possible to flag critical/security
firmware updates so that we can just create a process that automatically
apply these, say on a daily basis, without us having to chase every
single firmware GUIDs?


It's available in the urgency field, no?

└─ThinkPad P50 System Update:
   New version: 0.1.53
   Remote ID:   lvfs
   Summary: Lenovo ThinkPad P50 System Firmware
   Licence: Proprietary
   Size:9.4 MB
   Created: 2018-09-13
   Urgency: High
   Vendor:  Lenovo Ltd.

Ah, indeed, thanks! What seems missing is a CLI option to only install 
updates matching the requested urgency field.


e.g. with DNF you have all these filters:

 --bugfix  Include bugfix relevant packages, in updates
  --enhancement Include enhancement relevant packages, in updates
  --newpackage  Include newpackage relevant packages, in updates
  --securityInclude security relevant packages, in updates
  --advisory ADVISORY, --advisories ADVISORY
Include packages needed to fix the given 
advisory, in

updates
  --bz BUGZILLA, --bzs BUGZILLA
Include packages needed to fix the given BZ, in
updates
  --cve CVES, --cves CVES
Include packages needed to fix the given CVE, in
updates
  --sec-severity {Critical,Important,Moderate,Low}, --secseverity 
{Critical,Important,Moderate,Low} 


Include security relevant packages matching the
severity, in updates

If it's reasonable to have such toggles for fwupdmgr, we're happy to 
send a pull request for it.


Thanks,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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: Koji build failure misattribution - root.log instead of build.log?


On 5/20/20 4:26 PM, Adam Williamson wrote:

On Wed, 2020-05-20 at 16:15 -0700, Adam Williamson wrote:

On Thu, 2020-05-21 at 00:26 +0200, Pavel Raiskup wrote:

On Wednesday, May 20, 2020 11:43:10 PM CEST Michel Alexandre Salim wrote:

Hi,

I often notice that my scratch build right after updating some packages
(or packaging them for the first time) would fail -- e.g. due to some
strict GCC checks -- but Koji would direct me to inspect root.log, even
though there's no error there and the failure is logged in build.log

One recent example:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44743799

Known issue, and if not, where do I report it?


Probably worth reporting.  Koji decides based on mock's exit status;  so unless
Koji misinterprets the exit status from mock (would be koji issue), this should
be returned against mock.


It's koji that broke, I think. It's been this way for several months,
but I never bothered reporting it as I just got used to ignoring what
Koji said.

It should say root.log if the exit code is 30 and build.log if it's 1 -
those are the two most common cases, at least - but it seems to always
say root.log even if the exit code is 1, now.


Aha, these look relevant:

https://pagure.io/koji/c/3f64a48
https://pagure.io/koji/c/c7d35e9

I *suspect* we have only the first deployed right now, and the second
is intended to fix the problem we currently have. If we update our prod
koji to the second, we should get "see build.log or root.log" when the
exit code is 1.

The issue where this is being discussed is
https://pagure.io/koji/issue/1679 .



Thanks for finding this, Adam! I'm following up on that issue.

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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: TeXLive 2020 landing in rawhide

2020-05-22 Thread José Abílio Matos

On Friday, 22 May 2020 12.51.26 WEST Fabio Valentini wrote:
> Also, the build now fails with "! LaTeX Error: File `hanging.sty' not
> found.". graphite2 sources do not contain any .tex files, but
> graphite2 uses LaTeX / pdf output when building documentation / 
manual
> with doxygen, so I'm pretty sure the transitive dependency on
> `tex(hanging)` is missing somewhere else?

FWIW the last part should be `tex(hanging.sty)`. And probably you are 
right about the transitive dependency of this BuildRequires. :-)
-- 
José Abílio
___
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: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)


On Fri, May 22, 2020 at 09:56:48 -0500,
 Bruno Wolff III  wrote:

On Fri, May 22, 2020 at 09:03:31 -0500,
Bruno Wolff III  wrote:


I'll look harder to see if I can get a copy of 3.67. It isn't 
available any more from where I got it and I may have lost the copy 
I had downloaded to evalute a number of years ago.


I found a source rpm that has the 2.3.67 tarball in it. It looks 
reasonable.

https://ftp.lysator.liu.se/pub/opensuse/repositories/games/openSUSE_Tumbleweed/src/vulture-2.3.67-4.130.src.rpm
I have a local copy for now.

My feeling is that one will have better luck with that tarball, than with 
the 2.4 source that got archived.


I reopend a bug requesting an upgrade for vulture.
___
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: Heads up: gdal-3.1.0 coming to rawhide

2020-05-22 Thread Sandro Mani



On 21.05.20 00:55, Sandro Mani wrote:

Hi

I'm building gdal-3.1.0 in a f33 side-tag, and I'll also rebuild all 
dependencies:


bes
cloudcompare
dans-gdal-scripts
gazebo
GMT
grass
gtatool
liblas
mapnik
mapserver
merkaartor
ncl
nodejs-gdal
opencv
OpenSceneGraph
osgearth
postgis
python-fiona
python-rasterio
qgis
qlandkartegt
qmapshack
R-rgdal
saga
vfrnav


This is now done: 
https://bodhi.fedoraproject.org/updates/FEDORA-2020-12c975ff70


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

Re: Location of executable code

On Friday, May 22, 2020 10:39:43 AM EDT Petr Viktorin wrote:
> On 2020-05-22 16:30, Steve Grubb wrote:
> > Hello,
> > 
> > I am working on our application whitelisting daemon. It uses the rpmdb to
> > derive trust in what's on disk. If we use the whole rpmdb, then the
> > number of files is large. So, to prune the amount of entries in the
> > trust db down to a reasonable number, I thought we could jettison
> > anything in /usr/share.
> > 
> > According to the Filesystem Hierarchy Standard [1] it says this about
> > /usr/ share:
> > 
> > The /usr/share hierarchy is for all read-only architecture independent
> > data files.
> > 
> > But what I'm finding in practice is that cinnamon places its javascript
> > there, there are libexec dirs that contain executable code, there are
> > python and byte compiled python over there. In short, the system doesn't
> > work because critical executables are in /usr/share.
> > 
> > The question is what should be done about this? Do we care that things
> > are in /usr/share that are not following the Filesystem Hierarchy
> > Standard? If we do, what is the proper fix this this? Should bz be
> > opened against each component?
> 
> Does "read-only architecture independent data" mean the files must not
> be programs?

I personally think of data and applications/modules/libraries as distinct 
entities.

> Javascript, Python scripts and Python bytecode are all read-only and
> architecture independent. 

But they are not data. What I'm trying to do is constrain the notion of what 
can be executed.

> And everything on disk is data.
> The document you linked explicitly gives troff macros and "perl" as
> examples of what goes in /usr/share/.

Indeed it does. But it also suggests /usr/lib as another home for that. If 
there was a /usr/share/code  or /usr/share/perl or some convention like that, 
it would make the job easier because applications are discoverable. Instead 
they are hidden and in unexpected places. And its hard to tell what are 
example programs from something that the system depends on. There needs to be 
clarity about the intentions of any system code that lives in /usr/share. At 
least the libexec dirs are obvious. Is it possible to make this system code 
discoverable?

-Steve

> IMO, /usr/share/ would be a better place for *all* pure-Python modules
> than /usr/lib/, where they are now. The main reason they weren't moved
> is that the move would cause a lot of disruption.
> 
> > 1 - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html



___
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: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)


On Fri, May 22, 2020 at 09:56:48 -0500,
 Bruno Wolff III  wrote:

On Fri, May 22, 2020 at 09:03:31 -0500,
Bruno Wolff III  wrote:


I'll look harder to see if I can get a copy of 3.67. It isn't 
available any more from where I got it and I may have lost the copy 
I had downloaded to evalute a number of years ago.


The version I saw should have been 2.3.67. So the 2.4 community addition 
would have been a sucessor to that from about 3 to 4 years later.

___
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: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)


On Fri, May 22, 2020 at 09:03:31 -0500,
 Bruno Wolff III  wrote:


I'll look harder to see if I can get a copy of 3.67. It isn't 
available any more from where I got it and I may have lost the copy I 
had downloaded to evalute a number of years ago.


There is some source code archived at:
https://archive.org/details/VultureForNetHackCommunityEdition2.4

It doesn't have as much coverage as 3.67. I haven't verified that this is 
the modified nethack code. If it is unmodified, then it's useless for 
vulture. The build instructions seemed to be for nethack and so might 
turn out not to be very useful. This was archived in 2017 and probably is 
from no earlier than 2015.


Steam still seems to to the package and a slash'em version as well. They 
are supposed to come with source if you get them, but I don't know if 
it will be really usable. I'm not getting a Steam account to check out 
what is there. (When I get proprietory games, they are DRM free from GoG.)

___
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: looking for scipy on python 3.8 (RISCV Fedora Release 32)

2020-05-22 Thread Arun Sukumaran Latha

Thanks David for looking into the same.

One more package I would need help build in fedora riscv for ultimately
getting tensorflow compiled.

The other dependency is:
h5py<2.11.0,>=2.10.0

I did try getting the latest one available at
http://fedora.riscv.rocks/koji/buildinfo?buildID=149390, but that is 2.9
version and I will need at-least 2.10 of the same for tensorflow.

Let me know if that could be compiled as well.

Regards,
Arun SL

On Mon, May 18, 2020 at 11:11 PM David Abdurachmanov <
david.abdurachma...@gmail.com> wrote:

> On Mon, May 18, 2020 at 7:45 PM Arun Sukumaran Latha
>  wrote:
> >
> > Yes please,  do let me know if we can build thos one.
> >
>
> I will let you know.
>
> I found some dependencies misaligned due to some packages failing to
> build or failing to pass tests.
> I am slowly rebuilding/checking those, but that will take some time.
>
> Cheers,
> david
>
> > Regards,
> > Arun SL
> >
> > On Sun, May 17, 2020, 17:25 David Abdurachmanov <
> david.abdurachma...@gmail.com> wrote:
> >>
> >> On Sun, May 17, 2020 at 1:52 PM Arun Sukumaran Latha
> >>  wrote:
> >> >
> >> > Thanks David,
> >> >
> >> > That helped a lot.
> >> >
> >> > But unfortunately, we have ran into the next issue ie. wrt  grpcio.
> >> >
> >> > [riscv@fedora-riscv tensorflow_pkg]$ sudo dnf install python3-grpcio
> >> > Last metadata expiration check: 0:17:52 ago on Sun 17 May 2020
> 06:20:36 AM EDT.
> >> > Error:
> >> >  Problem: conflicting requests
> >> >   - nothing provides libpython3.7m.so.1.0()(64bit) needed by
> python3-grpcio-1.20.1-2.fc31.riscv64
> >> >   - nothing provides python(abi) = 3.7 needed by
> python3-grpcio-1.20.1-2.fc31.riscv64
> >> >   - nothing provides python3.7dist(six) >= 1.5.2 needed by
> python3-grpcio-1.20.1-2.fc31.riscv64
> >> >
> >> > I tried following
> http://fedora.riscv.rocks/koji/packageinfo?packageID=23014
> >> > but still do not see the same available for Python 3.8
> >> >
> >> > let me know if you can help me here as well.
> >>
> >> This particular package failed to build last time (compile time errors).
> >> I can give a look into it.
> >>
> >> Cheers,
> >> david
> >>
> >> >
> >> > Regards,
> >> > Arun SL
> >> >
> >> > On Sun, May 17, 2020 at 2:02 PM David Abdurachmanov <
> david.abdurachma...@gmail.com> wrote:
> >> >>
> >> >> On Sat, May 16, 2020 at 8:26 PM Arun Sukumaran Latha
> >> >>  wrote:
> >> >> >
> >> >> > Hello All,
> >> >> >
> >> >> > I was working on getting tensorflow compiled within the RISCV
> Fedora environment.
> >> >> > I am using the latest release 32 build.
> >> >> > Currently I am unable to install the dependent library, scipy due
> to the same not being available for python 3.8.1 which is currently
> installed.
> >> >> >
> >> >> > [riscv@fedora-riscv ~]$ sudo dnf install python3-scipy
> >> >> > Last metadata expiration check: 0:22:10 ago on Sat 16 May 2020
> 12:02:37 PM EDT.
> >> >> > Error:
> >> >> >  Problem: conflicting requests
> >> >> >   - nothing provides libpython3.7m.so.1.0()(64bit) needed by
> python3-scipy-1.1.0-3.0.riscv64.fc29.riscv64
> >> >> >   - nothing provides python(abi) = 3.7 needed by
> python3-scipy-1.1.0-3.0.riscv64.fc29.riscv64
> >> >> > (try to add '--skip-broken' to skip uninstallable packages)
> >> >> > [riscv@fedora-riscv ~]$ cat /etc/redhat-release
> >> >> > Fedora release 32 (Rawhide)
> >> >> > [riscv@fedora-riscv ~]$ python3 --version
> >> >> > Python 3.8.1
> >> >> >
> >> >> > Can you please let me know if we can have the same soon?
> >> >>
> >> >> Hi,
> >> >>
> >> >> I have rebuilt scipy to Python 3.8 in Fedora/RISCV during mass
> rebuild
> >> >> for GCC 10, but it's not yet available directly from distro
> >> >> repository.
> >> >>
> >> >> You would need to install it directly from Fedora/RISCV Koji
> instance:
> >> >> http://fedora.riscv.rocks/koji/buildinfo?buildID=156446
> >> >>
> >> >> 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
> >> >
> >> > ___
> >> > 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

Re: Location of executable code

2020-05-22 Thread Petr Viktorin


On 2020-05-22 16:30, Steve Grubb wrote:

Hello,

I am working on our application whitelisting daemon. It uses the rpmdb to
derive trust in what's on disk. If we use the whole rpmdb, then the number of
files is large. So, to prune the amount of entries in the trust db down to a
reasonable number, I thought we could jettison anything in /usr/share.

According to the Filesystem Hierarchy Standard [1] it says this about /usr/
share:

The /usr/share hierarchy is for all read-only architecture independent data
files.

But what I'm finding in practice is that cinnamon places its javascript there,
there are libexec dirs that contain executable code, there are python and
byte compiled python over there. In short, the system doesn't work because
critical executables are in /usr/share.

The question is what should be done about this? Do we care that things are in
/usr/share that are not following the Filesystem Hierarchy Standard? If we
do, what is the proper fix this this? Should bz be opened against each
component?


Does "read-only architecture independent data" mean the files must not 
be programs?
Javascript, Python scripts and Python bytecode are all read-only and 
architecture independent. And everything on disk is data.
The document you linked explicitly gives troff macros and "perl" as 
examples of what goes in /usr/share/.


IMO, /usr/share/ would be a better place for *all* pure-Python modules 
than /usr/lib/, where they are now. The main reason they weren't moved 
is that the move would cause a lot of disruption.



1 - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html

___
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

Retiring nodejs-marked

2020-05-22 Thread Jared K. Smith

I retired nodejs-marked yesterday, as it was a duplicate of the "marked"
package, which wasn't caught at the time I packaged it.

--
Jared Smith
___
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

Location of executable code

Hello,

I am working on our application whitelisting daemon. It uses the rpmdb to 
derive trust in what's on disk. If we use the whole rpmdb, then the number of 
files is large. So, to prune the amount of entries in the trust db down to a 
reasonable number, I thought we could jettison anything in /usr/share.

According to the Filesystem Hierarchy Standard [1] it says this about /usr/
share:

The /usr/share hierarchy is for all read-only architecture independent data 
files.

But what I'm finding in practice is that cinnamon places its javascript there, 
there are libexec dirs that contain executable code, there are python and 
byte compiled python over there. In short, the system doesn't work because 
critical executables are in /usr/share.

The question is what should be done about this? Do we care that things are in 
/usr/share that are not following the Filesystem Hierarchy Standard? If we 
do, what is the proper fix this this? Should bz be opened against each 
component?

Best Regards,
-Steve


1 - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html

___
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

2020-05-22 Thread Petr Viktorin

On 2020-05-22 13:59, Tomasz Kłoczko wrote:
On Fri, 22 May 2020 at 12:02, Miro Hrončok > wrote:

On 22. 05. 20 12:43, Tomasz Kłoczko wrote:
> [mode=serious]
> On making transition from 3.8.x to 3.9.x all what would be
necessary to do would
> be just create compat-python3.8 package -> upgrade python.spec to
3.9 -> monitor
> number of packages still dependent on compat-python3.8 to focus
what still needs
> to be ported/rebuild. ...snip

This doesn't work. As long as you rebuild setuptools and other
essential
packages with 3.9, the entire 3.8 stack would be useless. You would
need compat
packages for hundreds of packages to make this work.

Is that not *the*target/goal?.. make whole old stack useless/obsolete ASAP?

And no you would not need that because as long as you will not remove
from repository all python---.f22
packages all dependencies will be fulfilled.
Remember that each package is not rebuild on entire system but on very
limited one with (theoretically) necessary dependencies. With that it is
possible to rebuild all packages one by one and move everything in one
batch. To make that whole transition easier all what will be
necessary to do is clone current repository to something like
fedora-transition-python and add keep all rebuild packages in that repo
and merge all that packages in one go when all will be finished.
No stress or time pressure. such transition can take weeks if not months
and decision about merge could be done instantly basing on only one
metric which is number of packages still dependent on compat-python3.8.

How is this "fedora-transition-python" different from a side tag?

The problem with "cloning" is that people build new versions in Fedora
all the time, so the "clone" gets out of date (with some additional
problems related to version/release numbers). Unless the "clone" is kept
up to date, merging the repo would mean downgrading some packages.

That is the main reason for the time pressure: the longer the rebuild
takes, the more the repos diverge.

Than if at the and will be still some remains hard quickly to port it
should be made decision about create some limited number of packages
like compat-python3.8- and/or to put some of those packages on
obsoletes list. > With single metric decision about actual transition will be no longer in

hands of anyone (as single person or comity).
It will be strict technical decision based on quite well defined set of
conditions hanging on that metric.

So, what conditions do you propose?

Why would a condition (decided by one person or commitee) be better than
that person (or comittee) deciding on the fly -- based on not just the
number, but the actual packages that still fail to build?

If we are talking about using that methodology not only for python in
some simple enough cases such decision could be done .. automatically!
Basing on my already +25y exp on building rpm packages I can even bet
that after some cleanups in all python related stuff it should be
possible to make python major release upgrade *automatically.*

I'm afraid the clean-ups, and keeping the clean-ups up to date, would be
more work than doing the work manually.

Whoever would want to help on that transition will be asked to add that
fedora-transition-python repository to own build systems or own personal
system. Initial set of rebuilds made automatically should provide enough
set of new dependencies allowing fixing one by one each package which
will need manual intervention in form of some patches.

That's very similar to what's been happening in COPR for months now.

Above and what I wrote in my prev email could be general methodology on
making any future transition of bigger groups of packages from one major
version to another one (not only python specific).

All this is just like git branching but on packages with packages
repositories as well.

Branching is not hard; merging is. Both Git and CVS could branch; Git
won because the *merging* (and thus the whole branch-based workflow) is
easier.

It is yet another consequence of what I've sketched. With that it
would be possible to remove all python packages bootstrap bconds:

[tkloczko@barrel SPECS.fedora]$ grep bootstrap python* | grep bcond
python3.spec:%bcond_with bootstrap
python-BTrees.spec:%bcond_with bootstrap
python-dask.spec:%bcond_without bootstrap
python-fsspec.spec:%bcond_without bootstrap
python-pbr.spec:%bcond_with bootstrap
python-setuptools.spec:%bcond_with bootstrap
python-setuptools.spec:# Warning, different bootstrap meaning here, has
nothing to do with our bcond

python-sphinx_rtd_theme.spec:%bcond_with bootstrap
python-stestr.spec:%bcond_without bootstrap
python-wheel.spec:%bcond_with bootstrap
python-zbase32.spec:%bcond_with bootstrap

Sorry, I don't see how this would be possible.

Of course to that picture needs to be added yet another small bit which
is

glassfish-hk2 - orphaning event notification

2020-05-22 Thread Alex Scheel

After much trimming, pruning, and hair-pulling by our fearless leader,
glassfish-hk2 was determined to be a spurious dependency which Fabio
replaced with one line of `sed` magic.

Please see: https://pagure.io/stewardship-sig/issue/91

If anyone is interested in taking this package back for whatever reason,
feel free to adopt it and claim ownership. However, the Stewardship SIG
no longer has use for this package and thus orphaned it.


Thanks,

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

Re: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)

Copying me directory was a good idea to get my attention. Fedora list 
mail goes to another folder and it is easy for me to miss stuff, though 
I was planning to double check this thread for objections before doing 
a retire.


On Thu, May 21, 2020 at 18:46:14 -0400,
 Dennis Payne  wrote:

The reason for the crashing on startup is that it is not loading the
font.

/usr/games/vultureseye/fonts/VeraSe.ttf -> /usr/share/fonts/bitstream-
vera/VeraSe.ttf

/usr/share/fonts/bitstream-vera/VeraSe.ttf does not exist.

/usr/share/fonts/bitstream-vera-serif-fonts/VeraSe.ttf


Thanks for doing this. I wasn't sure how to get to specific threads in gdb 
and wasn't sure what the error was. I fixed this issue for several other 
games and can do it for nethack-vulture pretty easily now that I know 
what the problem is.




Updating the link allows it to start. I'm against losing games. So I'd
rather keep the current version at the moment. When I get a chance I'll
look into new versions of the program.


I'm against losing games as well, but don't find the time to do as good a 
job on the ones I maintain, as I should.


Even getting Vulture's Eye up to 3.67 is going to take more work than I 
can commit to any time soon. That uses a pretty old version of nethack. 
While it will likely never be up to date again, since Vulture's Eye 
upstream looks like it might be dead now, it would be nice to get it closer. 
I found some indications the game was commercialized on Steam and was 
probably getting updates as recently as 2017. The code license would allow 
anyone who had gotten a binary to get source, but the developer wasn't 
making it generally available. I'm not even sure I can find my 3.67 
copy any more. And I have not seen any mention of anyone providing source 
later than that.


If you want to be added as a co-maintainer or take over the package, I'm 
fine with that. A decision should be made before f33 branches, if there 
is enough interest to keep it around in spite of its support shortcommings.


I'll get the font issue fixed and do new builds for f31, f32 and rawhide. 
It's a sort of generic fix to work around problems caused by a change 
in f32's font packaging. A temporary fix was added for f32, but is not 
going to be kept for f33. The idea is for a simple rebuild to be able to 
deal with changes in font paths.


I'll look harder to see if I can get a copy of 3.67. It isn't available 
any more from where I got it and I may have lost the copy I had downloaded 
to evalute a number of years ago.

___
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag


On 22/05/20 14:49 +0200, Miro Hrončok wrote:

On 22. 05. 20 13:06, Miro Hrončok wrote:

Could you give me the list of packages? Is it this?

$ repoquery -C --repo=rawhide{,-source} --whatrequires boost-devel | grep src$

I can see where the sets overlap. Maybe we can figure things out somehow.


If this is the list, there are only 67 common packages.

I think we can:

1. build current boost with Python 3.9 in f33-python target
2. build boost 1.73.0 with Python 3.8 in f33-boost target
3. do our rebuilds
4. once one of the side tag is ready to be merged, we coordinate:
5. build Boost 1.73.0 with Python 3.9 in the remaining side tag
6. rebuild the 67 common packages

WDYT? Of course if the common set is 500 hundred, we don't probably want to do 
this.


We discussed it on IRC and agreed to go ahead with this plan.
___
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: FreeCAD dist-git check, WAS:Re: Aggressive updating (Python 3.9): Are we trying to hard?

2020-05-22 Thread Aleksandra Fedorova

Hi, Nico,

On Fri, May 22, 2020 at 2:38 PM Nico Kadel-Garcia  wrote:
>
> On Thu, May 21, 2020 at 1:04 PM Richard Shaw  wrote:
> >
> > On Thu, May 21, 2020 at 11:56 AM Aleksandra Fedorova  
> > wrote:
> >>
> >> On Thu, May 21, 2020 at 6:30 PM Richard Shaw  wrote:
> >> >
> >> > On Thu, May 21, 2020 at 10:37 AM Przemo Firszt  wrote:
> >> >>
> >> >> "FreeCAD -t 0" performs approx 470 tests. No GUI required. Example
> >> >> output starts here:
> >> >> https://travis-ci.org/github/FreeCAD/FreeCAD/jobs/689681966#L9103
> >> >
> >> >
> >> > May need some work to get working from inside mock:
> >> >
> >> > # ./FreeCAD -t 0
> >> > FreeCAD 0.18, Libs: 0.18RUnknown
> >> > © Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2019
> >> >   #   ###   
> >> >   ##  # #   #   #
> >> >   # ##     # #   #  #   #
> >> >     # # #  # #  #  # #  #   #
> >> >   # #      ## # #   #
> >> >   # #   ## ## # #   #  ##  ##  ##
> >> >   # #       ### # #    ##  ##  ##
> >> >
> >> > Aborted (core dumped)
> >>
> >> Please don't run it inside mock.
>
> Mock testing is extremely useful for testing in a completely defined
> environment, for standalone laptop environments with no active
> network, and also for testing docker and small VM compatibility. If
> tests need to be segregated for entirely local, or isolated testing,
> then perhaps the tests can be segregated with some "local" option?
>
> Since a mistyped "%build" step can do "rm -rf /" as the build user,
> it's just a lot safer for everyonr in the build environments to use
> the mock or other chroot cages or docker images.

I used the wrong term here. Running tests in a mock environment is ok,
if it fits the use case.

What I tried to highlight was running tests as a part of the %check
section of the RPM spec file. This means running tests in a very
specific mock environment of the koji builder during the build of the
binary rpm.

The downsides of this approach are:

1) you don't test the installed package, you test a binary you have just built
You can not check this way that configuration files for that binary
are put into the right places

2) this environment is "dirty" as it has all build files in the
working directory and environment has all build requirements installed
These build files are not going to be packaged and won't appear on the
target environment, but they could cause side effects on the test run.

3) it couples testing with builds.
You can not test package you already have. You can not retrigger test
with the same package if the test failure was caused by infra issue or
the issue with the dependency. You can not reuse test from one package
to test the compose or another package.

4) it creates load on koji builders
When we run integration tests via Fedora CI we use cloud
infrastructure outside of Koji. We can run heavier tests and retrigger
them as much as needed.

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

[HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a 
side tag.


https://fedoraproject.org/wiki/Changes/Python3.9

If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
please don't rebuild it in regular rawhide.

If you need to, please let me know, so we can coordinate.

If you'd like to build the package, you should be able to build it in the side 
tag via:


on branch master:
$ fedpkg build --target=f33-python
$ koji wait-repo f33-python --build 

Note that it will take a while before all the essential packages are rebuilt, so 
don't except all your dependencies to be available right away. When in trouble, 
ask here or on IRC (#fedora-python on Freenode).


Builds: 
https://koji.fedoraproject.org/koji/builds?latest=0=22287=-build_id=0


Please avoid any potentially disturbing changes in Python packages until the 
rebuild is over.


Thanks. Let us know if you have any questions.

PS I've BCC'ed maintainers of the "initial bootstrap sequence". If your package 
is listed bellow, it means it is essential that you coordinate all rawhide 
changes -- if you don't, this may potentially make the disturbed experience 
longer than necessary. Thank You so much for your patience.


Maintainers by package:
Cython   churchyard ignatenkobrain nbecker stevetraylen
GitPythondgoodwin ignatenkobrain lsedlar
PyQt4rdieter than
PyYAML   jeckersb
abrt abrt-team ekulik jfilak mgrabovs mhabrnal mmarusak msuchy
anaconda anaconda-maint jkonecny m4rtink rvykydal sbueno vpodzime 
vponcova

asciidoc jridky nphilipp sochotni tmz
babelfschwarz nphilipp
bodhiabompard
boostdenisarnaud jwakely
breezy   churchyard dormouse opohorel
brotli   carlwgeorge pouar tagoh
clangairlied daveisfera sbergmann sergesanspaille siddharths 
tstellar

cloud-init   dustymabe gholms larsks mhayden otubo
createrepo_c dmach jrohel mblaha pkratoch tmlcoch
dblatex  alexlan jchaloup mjg
dbus-python  alexl amigadave besser82 caillon caolanm johnp mbarnes 
ngompa phuang rdieter rhughes rstrode ssp stefanok vtrefny

dnf  dmach jmracek jrohel mblaha pkratoch
dnf-plugins-core dmach jmracek mblaha pkratoch
dnf-plugins-extras   dmach jmracek mblaha pkratoch
fedmod   karsten nphilipp
fedmsg   clime
fedora-messaging abompard
fedpkg   cqi lsedlar onosek
file kdudka macermak odubaj svashisht vmihalko
fros jfilak
future   sagitter
gdb  jankratochvil keiths kevinb sergiodj
gladekalev
gobject-introspection dcbw otaylor walters
gpgmefkluknav ignatenkobrain isimluk rdieter tmraz
ipython  churchyard cstratak dcantrell ignatenkobrain lbalhar mrunge 
salimma tomspur

kernel-tools jcline jforbes jwboyer labbott pbrobinson
kobo dmach rohanpm
koji ausil kevin mikem puiterwijk
libblockdev  sbueno tbzatek vpodzime vtrefny
libbytesize  tbzatek vpodzime vtrefny
libcomps akozumpl dmach jluza jmracek mblaha pkratoch
libdnf   dmach jmracek jrohel mblaha pkratoch
libgit2-glib ignatenkobrain kalev nacho pwalter
libmodulemd  asamalik nphilipp sgallagh
libpwquality tmraz
librepo  dmach pkratoch tmlcoch
libreportabrt-team ekulik jfilak mgrabovs mhabrnal mmarusak msuchy
libselinux   dwalsh mgrepl pcmoore plautrba vmojzis
libsolv  dmach ignatenkobrain jmracek jrohel ngompa pkratoch
libxml2  ignatenkobrain jpokorny veillard
loraxbcl clumens dcantrell dshea wwoods
mesoncarlwgeorge ekulik ignatenkobrain wtaymans
mock jcwillia mebrown msuchy praiskup
mpichdeji zbyszek
numpycstratak jspaleta limb orion rdieter tomspur ttomecek
openmpi  deji dledford jhladky orion pkfed
pdc-client   bliu chcao cheng chuzhang lholecek lsedlar sochotni
policycoreutils  dwalsh lvrabec mgrepl pcmoore plautrba vmojzis
pungidmach lsedlar maxamillion onosek tdawson wwoods
pyOpenSSLjcline jlieskov lmacken tmraz
pycairo  alexl caillon caolanm johnp kalev ralph rhughes rstrode ssp
pydotbesser82 spot
pygobject3   johnp nacho walters
pykickstart  bcl clumens dcantrell jkonecny m4rtink rvykydal sbueno 
vponcova
pyparsingapevec jamatos sharkcz terjeros
pyparted bcl clumens dcantrell
pysendfile   russellb
pyserial stingray
pytest   churchyard mrunge radez thm
python-Automat   carlwgeorge eclipseo
python-Bottleneckbesser82
python-Pallets-Sphinx-Themes codeblock
python-PyPDF2aarem
python-WSGIProxy2

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22/05/20 13:06 +0200, Miro Hrončok wrote:

On 22. 05. 20 12:54, Jonathan Wakely wrote:

On 22/05/20 10:47 +0200, Miro Hrončok wrote:

On 22. 05. 20 8:28, Jonathan Wakely wrote:

On 22/05/20 03:06 +0200, Miro Hrončok wrote:
Hello, in order to deliver Python 3.9, we are running a
coordinated rebuild in a side tag.

https://fedoraproject.org/wiki/Changes/Python3.9

If you see a "Rebuilt for Python 3.9" (or similar) commit in
your package, please don't rebuild it in regular rawhide.

If you need to, please let me know, so we can coordinate.

I need to start doing the Boost 1.73.0 rebuilds in a boost side tag,
but I can wait until you've done it for Python.

How long do you expect it to take before your side tag is merged back
to rawhide?

From https://fedoraproject.org/wiki/Changes/Python3.9

2020-05-30: Expected side tag-merge (optimistic)
2020-06-18: Expected side tag-merge (realistic)
2020-07-18: Expected side tag-merge (pessimistic)

Ouch.

When do you need to start building?

I was going to start this week, but that didn't happen (and I probably
won't start today). I would have tried to complete most of it next week
though, and merge the week after, to get done before the data centre
move reduces capacity on the builders.

The mid-June date would be OK, but it would take longer due to reduced
capacity.

Waiting until mid-July would be a problem though, there's no way I
could do it before the mass rebuild (so I might as well not bother
using aside tag and just dump it in rawhide and let the mass rebuild
find all the problems).

This scenario is not very likely.

Could you give me the list of packages? Is it this?

$ repoquery -C --repo=rawhide{,-source} --whatrequires boost-devel | grep src$

That gives me:
Error: Unknown repo: 'rawhide'

And this fails too:

$ repoquery --releasever=rawhide --repo=fedora{,-source} --whatrequires
boost-devel | grep src$ > repoquery1
Last metadata expiration check: 0:01:59 ago on Fri 22 May 2020 13:42:32 BST.
Modular dependency problem:

Problem: conflicting requests
- nothing provides module(platform:f31) needed by module
gimp:2.10:3120191106095052:f636be4b-0.x86_64

I use the first command at
https://fedoraproject.org/wiki/Changes/F33Boost173#Dependencies which
only finds the packages that depend on the libboost_*.so libs, which
is a list about half the size.

Many packages that use Boost only use its headers without linking to
one of the shared libs, so I don't rebuild them as part of an update
that changes the SONAMEs of the shared libs (they'll get rebuilt in
the mass rebuild anyway).

I can see where the sets overlap. Maybe we can figure things out somehow.

I think I will just do the rebuilds using my own PC and report bugs in
the packages that FTBFS with the new boost, so that when I do the
builds in the side tag things go more smoothly.

We can do it in copr as well if needed.

There are two changes I'd like to do before you start, which I can
push today:

1) libboost_python3.so.1.69.0 currently links to libpython3.8.so which
is contrary to Boost upstream, and also contrary to guidance from
Python upstream (https://github.com/python/cpython/pull/12946). The
Fedora patches to do that are fragile (and one of the main reasons I
couldn't get new Boost releases to build for Fedora, and didn't update
it in F31 or F32). So I'd like to drop those patches.

2) I'd also like to include boost-python3 in the boost metapackage, as
suggested at
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/B4LDABNDO7E3PH263ZU6ZR4SLP6WMNCJ/#JOSRJAUDXN56TQJPAXKFPIFA3SDS4GIZ

With those patches in rawhide our boost-python3 package will be better
even if for some reason I have to abandon the update to Boost 1.73.0
(which is unlikely, because I've already got all the spec file changes
and scratch build done locally).

So can I push those before you rebuild in the side tag?

Please do.

PS We can also sync the plan on IRC for faster interaction.

Will do.
___
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag


On 22. 05. 20 13:06, Miro Hrončok wrote:

Could you give me the list of packages? Is it this?

$ repoquery -C --repo=rawhide{,-source} --whatrequires boost-devel | grep src$

I can see where the sets overlap. Maybe we can figure things out somehow.


If this is the list, there are only 67 common packages.

I think we can:

 1. build current boost with Python 3.9 in f33-python target
 2. build boost 1.73.0 with Python 3.8 in f33-boost target
 3. do our rebuilds
 4. once one of the side tag is ready to be merged, we coordinate:
 5. build Boost 1.73.0 with Python 3.9 in the remaining side tag
 6. rebuild the 67 common packages

WDYT? Of course if the common set is 500 hundred, we don't probably want to do 
this.

--
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On Fri, 22 May 2020 at 12:07, Jonathan Wakely 
wrote:
[..]

> Maybe you should make a proper change proposal to do this, instead of
> just being sarcastic about the work other people are doing?
>

I'm not 100% sure am I understand you correctly because I'm not sure is it
still something not clear or you are trying to push me on some exact rails
:P

1st ver of the answer:
Sorry I'm engineer not bureaucrat.
If someone do not understand what just has been written this is not my
problem (maybe it is brutal claim but it is only truth).
Yes, I'm not native English speaker and my English still is a bit clunky.

2nd:
I understand that Fedora has own bureaucracy and it (en)forces some
technical decisions by policies but all that decision should be strict
technical decision and whole bureaucracy should be done post factum after
discussion -> POC -> discussion of the POC results.
Writing policies is generally to cut off any misunderstanding on scaling
that decisions on other non-initial areas or to provide
clear justification on all not obvious "why that way?" question, and of
course keep entropy of everything on lowest possible level.

Nevertheless now we are not on any of those stages.
Simple I don't like when strict technical decisions are done because they
have been (en)forced by unproven political/strategical decisions. and what
IMO cracks in case of python says me that currently used policies at least
needs some remake.

Someone made the decision about python methodologies and because in the
past that person or people had the best set of facts in own brains they
should speak first to at least confirm that some cracks are not only
imaginary. With agreement that currently used methodologies something is
wrong ("errare humanum est perseverare diabolicum") only IMO is possible to
start new games on some rules/policies.

In cases like this it is really possible to do a lot only discussing
current state and some new possible states (by discussion I understand
conversation in which sides are using facts .. only).

If it is not obvious .. I'm already assuming that what I've described could
be wrong/bollocks/BS because some already tested (in combat) cases on areas
which I don't know/I'm not aware.
Despite that entry/top assumption what just sparked in my head looks
consistent and sound.

I'm not trying as well to challenge personally anyone.
No this is purely technical conversation and even if some wordings looks
harsh it is not absolutely the case.

kloczek
___
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: FreeCAD dist-git check, WAS:Re: Aggressive updating (Python 3.9): Are we trying to hard?

On Thu, May 21, 2020 at 1:04 PM Richard Shaw  wrote:
>
> On Thu, May 21, 2020 at 11:56 AM Aleksandra Fedorova  
> wrote:
>>
>> On Thu, May 21, 2020 at 6:30 PM Richard Shaw  wrote:
>> >
>> > On Thu, May 21, 2020 at 10:37 AM Przemo Firszt  wrote:
>> >>
>> >> "FreeCAD -t 0" performs approx 470 tests. No GUI required. Example
>> >> output starts here:
>> >> https://travis-ci.org/github/FreeCAD/FreeCAD/jobs/689681966#L9103
>> >
>> >
>> > May need some work to get working from inside mock:
>> >
>> > # ./FreeCAD -t 0
>> > FreeCAD 0.18, Libs: 0.18RUnknown
>> > © Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2019
>> >   #   ###   
>> >   ##  # #   #   #
>> >   # ##     # #   #  #   #
>> >     # # #  # #  #  # #  #   #
>> >   # #      ## # #   #
>> >   # #   ## ## # #   #  ##  ##  ##
>> >   # #       ### # #    ##  ##  ##
>> >
>> > Aborted (core dumped)
>>
>> Please don't run it inside mock.

Mock testing is extremely useful for testing in a completely defined
environment, for standalone laptop environments with no active
network, and also for testing docker and small VM compatibility. If
tests need to be segregated for entirely local, or isolated testing,
then perhaps the tests can be segregated with some "local" option?

Since a mistyped "%build" step can do "rm -rf /" as the build user,
it's just a lot safer for everyonr in the build environments to use
the mock or other chroot cages or docker images.
___
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

2020-05-22 Thread Antonio Trande

Scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44816285

-- 
---
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: FreeCAD dist-git check, WAS:Re: Aggressive updating (Python 3.9): Are we trying to hard?

2020-05-22 Thread Petr Pisar

On Fri, May 22, 2020 at 01:28:14PM +0200, Aleksandra Fedorova wrote:
> On Fri, May 22, 2020 at 9:29 AM Petr Pisar  wrote:
> >
> > I'd like to point out that there is a difference in the enviroments between
> > these two approaches.
> >
> > While the manual procedure only installs a binary package (and its
> > dependencies), the OSCI procedure installs all binary packages produced by 
> > the
> > source package (and their depenencies).
> 
> You are right here. Jenkins pipeline tries to install all packages
> from the koji build before running the test.
> 
> And this approach has already hit us many times: there are packages
> where binary subpackages conflict with each other (as in curl), or
> where different tests require different subpackages to be installed.
> There is also a case for reverse dependency check, where we would like
> to run test suite from a package A to test the package B, where the
> koji build we are installing is different from what is expected by the
> test.
> 
> In Fedora CI SIG we are discussing if we should just disable this
> functionality and make it mandatory to specify all packages explicitly
> in the tests.yml under "required_packages" tag, as in [1]
> 
> The downside is:
>  you would need to maintain list of required packages in the tests.yml
> 
> We haven't brought this topic to a wider audience yet, but we should.
> 
I don't have the statistics, but I believe that most of Fedora packages only
produce one binary package.

With that assumption, I would recommend defaulting to installing all of the
binary packages of the build. If there were a conflict, the installation would
fail, and a maintainer would fix the test by specifying the required_packages
explicitly. I.e. the required_packages tag should change a semantacs. Instead
of "the additional packages" it would mean "install these package only". In
other words the required_packages tag would default to the list of binary
packages produced by the build being tested.

That's my ideal approach from point of view of a package maintainer. Of course
I have no idea how difficult the implement is. Maybe it conflicts with the
currecnt OSCI design.

Regarding the case when a test of reverse dependcy fails because the build has
changed, I think it is a standard situation of breaking a compatibility and
the test should fail and the maintainer should decide what to do. E.g. to
move the update into a side tag and adjust the reverse dependency there.

> > In case of freecad, it does not matter, because the freecad component has 
> > only
> > one binary package. But in general it's not true.
> >
> > And here I'd like to ask Aleksandra whether the same applies to modules or
> > not. In general case, a module build produces two binary modules - a 
> > non-devel
> > module and a devel module. Does OSCI install components from both of them? 
> > And does
> > it install the components explicitly, or does it rather install a default
> > profile of the module ("dnf module install" command)?
> 
> We don't have test for modules yet in Fedora CI.

The thing is that producing the devel modules is a matter of MBS
configuration and I feel that Fedora does not produce them in contrast to
CentOS.

> So I would say the question here is:
> 
> how do you like it to work?
> 
> We can do "dnf module install" but then the same issues would appear:
> if you need additional flexibility to test parts of the module, you
> would need to revert this default behavior somehow.
> Or we can do nothing and only provide environment with repositories
> with the updates. So that configuration of the environment is done in
> the test metadata.
> 
The devel modules very often contain the pacakges that are only used for
building the non-devel module and building very often includes running unit
tests. That means that running tests for a module, will very probably need
packages from the devel module. Especially when the tests try to
reproduce the unit tests from the build time.

Since the non-devel module is supposed to work without the devel module, it
makes sense to run the tests by default without the devel module. To get to
the production environment as close as possible. On the other hand there will
be a need for having an acccess to the devel module packages.

I would not install the devel module by default, but provide a way of enabling
the devel module when needed.

Your question can also be understand as whether to preinstall all packages
produced by a module. Regardless of the mythical (in Fedora) devel modules.

On the one hand, modules are perceived as a cohesive group of packages. On the
other hand, I cannot preclude that somebody will create a module with curl
and the conflicting subpackages inside. I think I would resort to the same
approach as with the non-modular packages. Default to installing everything
with an option for overriding it to an explicit list.

-- Petr

signature.asc
Description: PGP signature
___

Fedora-Cloud-31-20200522.0 compose check report

2020-05-22 Thread 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: HEADS UP: libdav1d SONAME bump from .3 to .4

2020-05-22 Thread Igor Raits

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, 2020-05-22 at 11:56 +0200, Igor Raits wrote:
> Hello,
> 
> I'm upgrading dav1d from 0.5.x to 0.7.x that is changing SONAME.
> There
> is only one dependent package in Rawhide - libavif which I will take
> care of.

This is done: 
https://bodhi.fedoraproject.org/updates/FEDORA-2020-6fca4cf1de
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7HwVsACgkQEV1auJxc
Hh4GQA//X74k8UbekVhw8mtstwRikbWokMKSteOcwfRE4seRi+GEVQ6c82Ty9je/
8GyBMYuPjBMOvjSOynmktrjBIVtHkepPoEgtuAkWHkmwqDemhLxOOhbYju0CFqfN
WBhYN5QlmVqLX9O850WMuY6ucxBuSwkjMs6hRqp8Q2Wb/T9XhXqD71UhhezUvnZE
0VD+UmGvxItCJOtkRerh4zo1M3+gbNu8Xo1stRsiHZKoRN6J8f90kudtHtP43LYF
SQvm+gG2BIA9jMxgRWfumo8deVfyl6AFGZyZWw/nHzOz4AoQWZAzw4LRyLa9eQZG
jiF26P3QLxY6xcSAV+VyX4HTOD9BnCyll7tZvOikCzxgiCVGHxPho1bKD7xwRgl5
+6TRgiApRqIMJUAS7O6+IJdYl9GTMqgo/V53Q09tmKPyDXKYulbFI78k+pel3M0U
0P8vLaNdH4Y5YG3JIm1St48Lr0vtzgx73NOeoeeJ3AuiRO1/CCYTId24trzubjbl
u0P2F2fvXWM+D1NLjwaA0tS/OoMvnISpKR8m5VFdYQoNfRI5CnU1nONwit9Msju5
hWWyVOYdQfH83xRK9L5EF0mwC+YN91mQ5LeNB7V7vdmseyBxTp0VYtp5MO3/Zce7
k1jBSWdSLBRdliFU3r4zIUiQvm9/0B8X4sjKRIef3NGc9Boc6kI=
=b0GR
-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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On Fri, 22 May 2020 at 12:02, Miro Hrončok  wrote:

> On 22. 05. 20 12:43, Tomasz Kłoczko wrote:
> > [mode=serious]
> > On making transition from 3.8.x to 3.9.x all what would be necessary to
> do would
> > be just create compat-python3.8 package -> upgrade python.spec to 3.9 ->
> monitor
> > number of packages still dependent on compat-python3.8 to focus what
> still needs
> > to be ported/rebuild. ...snip
>
> This doesn't work. As long as you rebuild setuptools and other essential
> packages with 3.9, the entire 3.8 stack would be useless. You would need
> compat
> packages for hundreds of packages to make this work.
>

Is that not *the* target/goal? .. make whole old stack useless/obsolete
ASAP?

And no you would not need that because as long as you will not remove from
repository all python---.f22 packages all
dependencies will be fulfilled.
Remember that each package is not rebuild on entire system but on very
limited one with (theoretically) necessary dependencies. With that it is
possible to rebuild all packages one by one and move everything in one
batch. To make that whole transition easier all what will be necessary to
do is clone current repository to something like fedora-transition-python
and add keep all rebuild packages in that repo and merge all that packages
in one go when all will be finished. No stress or time pressure. such
transition can take weeks if not months and decision about merge could be
done instantly basing on only one metric which is number of packages still
dependent on compat-python3.8. Than if at the and will be still some
remains hard quickly to port it should be made decision about create some
limited number of packages like compat-python3.8- and/or to put
some of those packages on obsoletes list.
With single metric decision about actual transition will be no longer in
hands of anyone (as single person or comity).
It will be strict technical decision based on quite well defined set of
conditions hanging on that metric.
If we are talking about using that methodology not only for python in some
simple enough cases such decision could be done .. automatically!
Basing on my already +25y exp on building rpm packages I can even bet that
after some cleanups in all python related stuff it should be possible to
make python major release upgrade *automatically.*

Whoever would want to help on that transition will be asked to add that
fedora-transition-python repository to own build systems or own personal
system. Initial set of rebuilds made automatically should provide enough
set of new dependencies allowing fixing one by one each package which will
need manual intervention in form of some patches.

Above and what I wrote in my prev email could be general methodology on
making any future transition of bigger groups of packages from one major
version to another one (not only python specific).

All this is just like git branching but on packages with packages
repositories as well.

It is yet another consequence of what I've sketched. With that it would be
possible to remove all python packages bootstrap bconds:

[tkloczko@barrel SPECS.fedora]$ grep bootstrap python* | grep bcond
python3.spec:%bcond_with bootstrap
python-BTrees.spec:%bcond_with bootstrap
python-dask.spec:%bcond_without bootstrap
python-fsspec.spec:%bcond_without bootstrap
python-pbr.spec:%bcond_with bootstrap
python-setuptools.spec:%bcond_with bootstrap
python-setuptools.spec:# Warning, different bootstrap meaning here, has
nothing to do with our bcond
python-sphinx_rtd_theme.spec:%bcond_with bootstrap
python-stestr.spec:%bcond_without bootstrap
python-wheel.spec:%bcond_with bootstrap
python-zbase32.spec:%bcond_with bootstrap

Of course to that picture needs to be added yet another small bit which is
stop (the h*ll) using versioned symlinks in case tools like pytest,
sphins and few other to use them *only* in compat-* packages.

kloczek
___
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: TeXLive 2020 landing in rawhide

2020-05-22 Thread Fabio Valentini

On Thu, May 14, 2020 at 11:56 PM Tom Callaway  wrote:
>
> I've just kicked off new builds for texlive and texlive-base for TeXLive 2020 
> in rawhide. Hopefully, everything that depends on them will continue to work, 
> but if you notice any new issues generating docs (or any missing components 
> or broken dependencies), feel free to email me or open Bugzilla tickets.

Hi Tom,

It looks like the texlive 2020 update broke graphite2 builds somehow ...

According to koschei, the graphite2 BuildRequires now pull in *about
300 more (tex + perl) packages than before the 2020 update*, which is
slightly concerning?
See: https://koschei.fedoraproject.org/build/8369713

Also, the build now fails with "! LaTeX Error: File `hanging.sty' not
found.". graphite2 sources do not contain any .tex files, but
graphite2 uses LaTeX / pdf output when building documentation / manual
with doxygen, so I'm pretty sure the transitive dependency on
`tex(hanging)` is missing somewhere else?

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: FreeCAD dist-git check, WAS:Re: Aggressive updating (Python 3.9): Are we trying to hard?

2020-05-22 Thread Aleksandra Fedorova

Hi, Petr,

On Fri, May 22, 2020 at 9:29 AM Petr Pisar  wrote:
>
> On Thu, May 21, 2020 at 07:29:35PM +0200, Aleksandra Fedorova wrote:
> > On Thu, May 21, 2020 at 7:04 PM Richard Shaw  wrote:
> > >
> > > On Thu, May 21, 2020 at 11:56 AM Aleksandra Fedorova  
> > > wrote:
> > >>
> > >> To run the command above as the integration test you need to put
> > >> tests/tests.yml file in dist-git repo with the following content:
> > >>
> > >> - hosts: localhost
> > >>   roles:
> > >>   - role: standard-test-basic
> > >> tags:
> > >> - classic
> > >> tests:
> > >> - simple:
> > >> dir: .
> > >> run: "FreeCAD -t 0"
> > >>
> > >> Note how here you will be using the install FreeCAD binary, not the 
> > >> local one.
> > >
> > >
> > > Is this only run on "real" builds, or is it possible to run locally or 
> > > for scratch builds?
> >
> > We run it for pull-requests and for "real builds.
> >
> > It runs in the following way:
> >
> > 1) we take latest Fedora Rawhide qcow image,
> > 2) we run virtual machine via qemu-kvm from it,
> > 3) inside the vm we install the package,
> > 4) we run the command defined by "run" key in that YAML file.
> >
> > And it is all orchestrated by Ansible.
> >
> > It is possible to reproduce the test locally with all the CI wrappers
> > around it, but I wouldn't recommend it. To debug the test I would just
> > run the VM with the same Rawhide image [1], install the package and
> > run the test command manually.
>
> I'd like to point out that there is a difference in the enviroments between
> these two approaches.
>
> While the manual procedure only installs a binary package (and its
> dependencies), the OSCI procedure installs all binary packages produced by the
> source package (and their depenencies).

You are right here. Jenkins pipeline tries to install all packages
from the koji build before running the test.

And this approach has already hit us many times: there are packages
where binary subpackages conflict with each other (as in curl), or
where different tests require different subpackages to be installed.
There is also a case for reverse dependency check, where we would like
to run test suite from a package A to test the package B, where the
koji build we are installing is different from what is expected by the
test.

In Fedora CI SIG we are discussing if we should just disable this
functionality and make it mandatory to specify all packages explicitly
in the tests.yml under "required_packages" tag, as in [1]

The downside is:
 you would need to maintain list of required packages in the tests.yml

We haven't brought this topic to a wider audience yet, but we should.

> In case of freecad, it does not matter, because the freecad component has only
> one binary package. But in general it's not true.
>
> And here I'd like to ask Aleksandra whether the same applies to modules or
> not. In general case, a module build produces two binary modules - a non-devel
> module and a devel module. Does OSCI install components from both of them? 
> And does
> it install the components explicitly, or does it rather install a default
> profile of the module ("dnf module install" command)?

We don't have test for modules yet in Fedora CI. So I would say the
question here is:

how do you like it to work?

We can do "dnf module install" but then the same issues would appear:
if you need additional flexibility to test parts of the module, you
would need to revert this default behavior somehow.
Or we can do nothing and only provide environment with repositories
with the updates. So that configuration of the environment is done in
the test metadata.

[1] 
https://docs.fedoraproject.org/en-US/ci/how-to-add-dist-git-test/#_tests_in_a_subpackage


-- 
Aleksandra Fedorova
bookwar
___
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22. 05. 20 12:54, Jonathan Wakely wrote:

On 22/05/20 10:47 +0200, Miro Hrončok wrote:

On 22. 05. 20 8:28, Jonathan Wakely wrote:

On 22/05/20 03:06 +0200, Miro Hrončok wrote:
Hello, in order to deliver Python 3.9, we are running a coordinated rebuild
in a side tag.

https://fedoraproject.org/wiki/Changes/Python3.9

If you see a "Rebuilt for Python 3.9" (or similar) commit in your package,
please don't rebuild it in regular rawhide.

If you need to, please let me know, so we can coordinate.

I need to start doing the Boost 1.73.0 rebuilds in a boost side tag,
but I can wait until you've done it for Python.

How long do you expect it to take before your side tag is merged back
to rawhide?

From https://fedoraproject.org/wiki/Changes/Python3.9

2020-05-30: Expected side tag-merge (optimistic)
2020-06-18: Expected side tag-merge (realistic)
2020-07-18: Expected side tag-merge (pessimistic)

Ouch.

When do you need to start building?

The mid-June date would be OK, but it would take longer due to reduced
capacity.

This scenario is not very likely.

Could you give me the list of packages? Is it this?

$ repoquery -C --repo=rawhide{,-source} --whatrequires boost-devel | grep src$

I can see where the sets overlap. Maybe we can figure things out somehow.

I think I will just do the rebuilds using my own PC and report bugs in
the packages that FTBFS with the new boost, so that when I do the
builds in the side tag things go more smoothly.

We can do it in copr as well if needed.

There are two changes I'd like to do before you start, which I can
push today:

So can I push those before you rebuild in the side tag?

Please do.

PS We can also sync the plan on IRC for faster interaction.

--
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22/05/20 11:43 +0100, Tomasz Kłoczko wrote:

On Fri, 22 May 2020 at 10:42, Miro Hrončok wrote:
[..]

It is just the component name. The user installable package is still
python3.

I call it thing-which-should-not-exist or thing-which-shall-not-pass.
That way it is easier to pronounce 

Reasoning:

Build python3, python3-libs etc. from python39 SRPM on F33+:

https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/5QUN7FWI6AV7BTMQGF257BEVMEA4QFOG/

Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9):

https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/VIUS7WMQMDX6H2WEIH7TVTMBB6SUHY7E/

A .. yeah 臘‍♂️
You are right I forgot that Fedora on making new major release instead
branching all packages stored in git still provides on master full support
for all last three version of the distribution, three EPL/RHEL and
sometimes even few version of SuSE 

I must apologise: sorry looks like it is my mistake .. (mea culpa, mea
culpa, .. mea maxima culpa)

[mode=serious]
On making transition from 3.8.x to 3.9.x all what would be necessary to do
would be just create compat-python3.8 package -> upgrade python.spec to 3.9
-> monitor number of packages still dependent on compat-python3.8 to focus
what still needs to be ported/rebuild.
Because other factors the best moment to start such transition would be few
days after f32 official release and tag all git resources and just right
before first MR.
Because rawhide just after that will have in %{dist} "f33" it will be not
even necessary to do what started today (bumping all python packages
releases and committing those changes) because
-.f32 will be always lower than
-.f33.

To make all above possible all only what would be is to stop using python
packages names in Requires and BuildRequires and start using
%pythondist( similar to what is now with pkgconfig() dependencies
(nice clean and not even one new macro needs to be introduced/split on some
exact package major version release).

With above total entropy cost would be *ONLY*:
- one additional compat-python3.8 package
- redefine %pythondist macro to provide python versioned dependencies
(probably by change only version in the macro which should hold python
major version).

On top of such scheme it will be possible go back to old simpler
maintenance of the long term used systems by combing only all installed
compat-* packages .. nice, easy and clean.

pkgconfig proved that this is actually and already/perfectly working (only
adaptation still is sloppy), and I don't see literally even single reasons
why it should not work for python or gt4/kde4 vs. qt4/kde5 as well.

Isn't it?
[/mode]

Maybe you should make a proper change proposal to do this, instead of
just being sarcastic about the work other people are doing?
___
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22/05/20 10:47 +0200, Miro Hrončok wrote:

On 22. 05. 20 8:28, Jonathan Wakely wrote:

On 22/05/20 03:06 +0200, Miro Hrončok wrote:
Hello, in order to deliver Python 3.9, we are running a
coordinated rebuild in a side tag.

https://fedoraproject.org/wiki/Changes/Python3.9

If you see a "Rebuilt for Python 3.9" (or similar) commit in your
package, please don't rebuild it in regular rawhide.

If you need to, please let me know, so we can coordinate.

I need to start doing the Boost 1.73.0 rebuilds in a boost side tag,
but I can wait until you've done it for Python.

How long do you expect it to take before your side tag is merged back
to rawhide?

From https://fedoraproject.org/wiki/Changes/Python3.9

2020-05-30: Expected side tag-merge (optimistic)
2020-06-18: Expected side tag-merge (realistic)
2020-07-18: Expected side tag-merge (pessimistic)

Ouch.

When do you need to start building?

The mid-June date would be OK, but it would take longer due to reduced
capacity.

I think I will just do the rebuilds using my own PC and report bugs in
the packages that FTBFS with the new boost, so that when I do the
builds in the side tag things go more smoothly.

There are two changes I'd like to do before you start, which I can
push today:

So can I push those before you rebuild in the side tag?
___
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag


On 22. 05. 20 12:43, Tomasz Kłoczko wrote:

[mode=serious]
On making transition from 3.8.x to 3.9.x all what would be necessary to do would 
be just create compat-python3.8 package -> upgrade python.spec to 3.9 -> monitor 
number of packages still dependent on compat-python3.8 to focus what still needs 
to be ported/rebuild. ...snip


This doesn't work. As long as you rebuild setuptools and other essential 
packages with 3.9, the entire 3.8 stack would be useless. You would need compat 
packages for hundreds of packages to make this work.


--
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag


Am 22.05.20 um 12:47 schrieb Miro Hrončok:
>> I was not aware that python-genshi is still part of the initial bootstrap
>> sequence. The package does not work with Python 3.9 (upstream problem, the
>> usual AST changes). I hope that won't make your life too difficult.
> 
> genshi is used in some html5lib tests, hence it is in this list, but don't
> worry too much, the genshi tests are optional and can be skipped if needed.

Good to know :-)

>> I started to debug the failures but it seems it is not a one line fix. Then
>> I got distracted by trying to fix up borgbackup for Python 3.9.
> 
> Sorry about the distraction.

No problem. I think it's hardly possible to run these mass rebuilds without an
occasional mistake.

Felix
___
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag


On 22. 05. 20 9:42, Felix Schwarz wrote:


Am 22.05.20 um 03:06 schrieb Miro Hrončok:

fschwarz   babel python-genshi


I was not aware that python-genshi is still part of the initial bootstrap 
sequence. The package does not work with Python 3.9 (upstream problem, the usual 
AST changes). I hope that won't make your life too difficult.


genshi is used in some html5lib tests, hence it is in this list, but don't worry 
too much, the genshi tests are optional and can be skipped if needed.


I started to debug the failures but it seems it is not a one line fix. Then I 
got distracted by trying to fix up borgbackup for Python 3.9.


Sorry about the distraction.

--
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On Fri, 22 May 2020 at 10:42, Miro Hrončok  wrote:
[..]

> It is just the component name. The user installable package is still
> python3.
>

I call it thing-which-should-not-exist or thing-which-shall-not-pass.
That way it is easier to pronounce 

> Reasoning:
>
> Build python3, python3-libs etc. from python39 SRPM on F33+:
>
>
> https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/5QUN7FWI6AV7BTMQGF257BEVMEA4QFOG/
>
>
> Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9):
>
>
> https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/VIUS7WMQMDX6H2WEIH7TVTMBB6SUHY7E/

A .. yeah 臘‍♂️
You are right I forgot that Fedora on making new major release instead
branching all packages stored in git still provides on master full support
for all last three version of the distribution, three EPL/RHEL and
sometimes even few version of SuSE 

I must apologise: sorry looks like it is my mistake .. (mea culpa, mea
culpa, .. mea maxima culpa)

[mode=serious]
On making transition from 3.8.x to 3.9.x all what would be necessary to do
would be just create compat-python3.8 package -> upgrade python.spec to 3.9
-> monitor number of packages still dependent on  compat-python3.8 to focus
what still needs to be ported/rebuild.
Because other factors the best moment to start such transition would be few
days after f32 official release and tag all git resources and just right
before first MR.
Because rawhide just after that will have in %{dist} "f33" it will be not
even necessary to do what started today (bumping all python packages
releases and committing those changes) because
-.f32 will be always lower than
-.f33.

To make all above possible all only what would be is to stop using python
packages names in Requires and BuildRequires and start using
%pythondist( similar to what is now with  pkgconfig() dependencies
(nice clean and not even one new macro needs to be introduced/split on some
exact package major version release).

With above total entropy cost would be *ONLY*:
- one additional compat-python3.8 package
- redefine %pythondist macro to provide python versioned dependencies
(probably by change only version in the macro which should hold python
major version).

On top of such scheme it will be possible go back to old simpler
maintenance of the long term used systems by combing only all installed
compat-* packages .. nice, easy and clean.

pkgconfig proved that this is actually and already/perfectly working (only
adaptation still is sloppy), and I don't see literally even single reasons
why it should not work for python or gt4/kde4 vs. qt4/kde5 as well.

Isn't it?
[/mode]

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: Aggressive updating (Python 3.9): Are we trying to hard?

On Wed, May 20, 2020 at 3:39 PM Miroslav Suchý  wrote:
>
> Dne 19. 05. 20 v 14:03 Richard Shaw napsal(a):
> > Because Qt 5.13.x / PySide2 5.13.x is NOT compatible with Python 3.8. But 
> > instead of asking ourselves, "should we push
> > in the VERY latest Python and hope it's ok?", we just patch the build 
> > system to accept it anyway and hope for the best.
> >
> > Qt (et all) is a pretty organized upstream, so when asked about Python 3.8 
> > support in 5.13.x, they said, "Nope. Wait for
> > 5.14.x."
> >
>
> BTW this is scholar example of use-case for Modularity.

For *python*? Just. no. the overlap of python modules among and
alongside each  other would be extraordinarily destabilizing. That was
wha the "python2dist" and python3dist" macros provided when used
consistently, so that suites of software could be "python27" or
"python36" prefixed.

The software package name prefixing could be pesky, but was far
simpler to manage.
___
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

2020-05-22 Thread Charalampos Stratakis

- Original Message -

> From: "Tomasz Kłoczko" 
> To: "Development discussions related to Fedora"
> 
> Sent: Friday, May 22, 2020 11:51:48 AM
> Subject: Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side
> tag

> On Fri, 22 May 2020 at 10:27, Peter Pentchev < r...@ringlet.net > wrote:
> [..]

> > > Originally was python package. Than was python python2 and python3. Now
> > > it
> 
> > > is python3.9.
> 
> > > Why not is used still and just python and to provide necessary
> > > dependencies
> 
> > > during transition python3.8?
> 
> > > That way as well is casing that with each python major version upgrade
> > > all
> 
> > > macros needs to be multiplied.
> 

> > Are you asking why python3.8 and python3.9 are separate packages?
> 

> No I'm not.

> 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

I don't understand your concern though. The Python 3.9 package provides the 
exact same things that were provided with the unversioned package, other 
packages don't need to change anything related to macros. 

-- 
Regards, 

Charalampos Stratakis 
Software Engineer 
Python Maintenance 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

HEADS UP: libdav1d SONAME bump from .3 to .4

2020-05-22 Thread Igor Raits

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

I'm upgrading dav1d from 0.5.x to 0.7.x that is changing SONAME. There
is only one dependent package in Rawhide - libavif which I will take
care of.
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7HocQACgkQEV1auJxc
Hh4+lQ//aeevBJTlOEc5JlVdGIYPn1khqPMgU3AF4A5dPT3pvw/KprD3qYfMkAhJ
8bozXV4GAMvtnHFXeHxzE7+V2tTt+Pu2Cemch4PFE8TP2fOplYitv9Zc/lvEoSm1
spWKEdvUt2lWo8QOq+1W6y6LOZYYOBx6URceHk52/6beN1U6DNE+e+5OFmIhhxoF
GMUSlXypFtTZSQjVJSVWILWXEvuCSa2ux4Dce1IV6fva9Mw/O7CRU592pS0jTdT9
i+uK1oAHCc9EnsBNhXPf/iGP4Dty1wDx/73yoQGNfwV3i9D7CdJ4NgBrGk9gCtap
IOlSRx2aqoFuLOhroJx0+61dJCM8djtFkm1DsNn2r0fY8OmE8Q3CzPR5xiGWg+ve
BOP0j8wG02pvBPFhVyJrKwX3ZoE4y1zU2PAAglwKJPSyQaVmT0B519XcDMwrYyuP
rVFX1xx9pgrVeFodPJdOxYvJc4eqmglbSknhe6mYljwssRniuFMwP35oVRb3IHug
xJKC/bCnmYMi4hFzu5BLY34CBYR/ruO8n4KWFZLDseCdGTyyP+rtap/4VvPBoniC
6eaQ/EBJlE04dwC3eNxGtFiwfUrgs5QvZzpZJ4wCyVidMTazzc9uCuFuHFZTu7GV
Tu7ik8nT7KUmWMN5idTKJEC1UUekBu8KlKwByWkUsGQFPNOhqAU=
=Bx8w
-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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On Fri, 22 May 2020 at 10:27, Peter Pentchev  wrote:
[..]

> > Originally was python package. Than was python python2 and python3. Now
> it
> > is python3.9.
> > Why not is used still and just python and to provide necessary
> dependencies
> > during transition python3.8?
> > That way as well is casing that with each python major version upgrade
> all
> > macros needs to be multiplied.
>
> Are you asking why python3.8 and python3.9 are separate packages?
>

No I'm not.

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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag


On 22. 05. 20 11:08, Tomasz Kłoczko wrote:


I'm only curious why to make transition to python 3.9 was chosen "debianised 
way"?

Originally was python package. Than was python python2 and python3. Now it is 
python3.9.


It is just the component name. The user installable package is still python3.

Reasoning:

Build python3, python3-libs etc. from python39 SRPM on F33+:

https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/5QUN7FWI6AV7BTMQGF257BEVMEA4QFOG/


Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9):

https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/VIUS7WMQMDX6H2WEIH7TVTMBB6SUHY7E/

--
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

2020-05-22 Thread Peter Pentchev

On Fri, May 22, 2020 at 10:08:04AM +0100, Tomasz Kłoczko wrote:
> On Fri, 22 May 2020 at 02:17, Miro Hrončok  wrote:
> 
> > Hello, in order to deliver Python 3.9, we are running a coordinated
> > rebuild in a
> > side tag.
> >
> >  https://fedoraproject.org/wiki/Changes/Python3.9
> >
> [..]
> 
> I'm only curious why to make transition to python 3.9 was
> chosen "debianised way"?

(yes, I am aware of the slight irony of me replying to this message with
 my current e-mail signature :))

> Originally was python package. Than was python python2 and python3. Now it
> is python3.9.
> Why not is used still and just python and to provide necessary dependencies
> during transition python3.8?
> That way as well is casing that with each python major version upgrade all
> macros needs to be multiplied.

Are you asking why python3.8 and python3.9 are separate packages?
If so, I think that previous messages to this list mentioned that many
people need to have more than one Python interpreter installed.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On Fri, 22 May 2020 at 02:17, Miro Hrončok  wrote:

> Hello, in order to deliver Python 3.9, we are running a coordinated
> rebuild in a
> side tag.
>
>  https://fedoraproject.org/wiki/Changes/Python3.9
>
[..]

I'm only curious why to make transition to python 3.9 was
chosen "debianised way"?

Originally was python package. Than was python python2 and python3. Now it
is python3.9.
Why not is used still and just python and to provide necessary dependencies
during transition python3.8?
That way as well is casing that with each python major version upgrade all
macros needs to be multiplied.
All that was possible to avoid bu just unversioned packages names and
unversioned python macros hiding major version transitions in macros.
All that is causing that for each that many packages will needs to be
specially modified to produce proper results on new python version as well
instead just retesting new standard macros definition on new python and/or
do couple of tweaks only ion those macros definitions and nothing more).
All that it is nothing more than creating huge amount of work which needs
to be done on each major version upgrade on mny packages.

"Making some mistakes is not the problem but repeating them again and again
really is".
>From that point of view with 3rd iteration should be enough to learn some
lessons because now (again) looks like it will be necessary to add many
modifications across many packages with python modules .. pointless!!!

Generalised build procedure with macros suppose to hide some details like
versions and other.
For some reasons looks like that completely stopped in case of only python
IMO because some people saw how some things has been done on Debian
(successfully but with way to big overhead).

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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag


On 22. 05. 20 8:28, Jonathan Wakely wrote:

On 22/05/20 03:06 +0200, Miro Hrončok wrote:
Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in 
a side tag.


   https://fedoraproject.org/wiki/Changes/Python3.9

If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
please don't rebuild it in regular rawhide.

If you need to, please let me know, so we can coordinate.


I need to start doing the Boost 1.73.0 rebuilds in a boost side tag,
but I can wait until you've done it for Python.

How long do you expect it to take before your side tag is merged back
to rawhide?


From https://fedoraproject.org/wiki/Changes/Python3.9

2020-05-30: Expected side tag-merge (optimistic)
2020-06-18: Expected side tag-merge (realistic)
2020-07-18: Expected side tag-merge (pessimistic)

When do you need to start building?

--
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 1838904] perl-perlfaq-5.20200523 is available

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-6471c56f67 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-6471c56f67


-- 
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 1838904] perl-perlfaq-5.20200523 is available

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-b96953d5ef has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-b96953d5ef


-- 
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 1838904] perl-perlfaq-5.20200523 is available

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-1a910e5253 has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-1a910e5253


-- 
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 1838904] perl-perlfaq-5.20200523 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-perlfaq-5.20200523-1.f
   ||c33



--- Comment #2 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.


-- 
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 1838904] perl-perlfaq-5.20200523 is available