Re: Heads up! OpenImageIO 2.4 series coming to rawhide

2022-10-27 Thread Adam Williamson 
On Thu, 2022-10-27 at 19:42 -0500, Richard Shaw wrote:
> On Thu, Oct 27, 2022 at 5:15 PM Tom Rix  wrote:
> 
> > Sorry, I did not run into the freeglut-devel problem with the manual build
> > 
> 
> I think I have something funny going on with the conditionals. Initially
> they were negative conditionals:
> 
> %if ! 0%{?bootstrap} || ! 0%{?rhel}
> %global docs 1
> %global tests 1
> %endif
> 
> 
> And I noticed that the build was trying to pull in build deps that it
> should not. As an experiment I changed it to a full positive conditional
> and that seemed to have *MOSTLY* worked:
> 
> %if 0%{?bootstrap} || 0%{?rhel}
> %global docs 0
> %global tests 0
> %else
> %global docs 1
> %global tests 1
> %endif
> 
> The BR's are not getting pulled in, and yet, on the cmake command, both
> docs and tests are still true, which from what I can tell should not be:
> 
> %cmake -DCMAKE_CXX_STANDARD=14 \
>-DOCIO_BUILD_DOCS=%{?docs:ON}%{?!docs:OFF} \
>-DOCIO_BUILD_TESTS=%{?tests:ON}%{?!tests:OFF} \
>-DOCIO_USE_HEADLESS=ON \
>-DOCIO_INSTALL_EXT_PACKAGES=NONE \
> %ifnarch x86_64
>-DOCIO_USE_SSE=OFF \
> %endif
>-DOpenGL_GL_PREFERENCE=GLVND
> 
> ...
> 
> + /usr/bin/cmake -S . -B redhat-linux-build
> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF
> -DCMAKE_INSTALL_PREFIX:PATH=/usr
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include
> -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
> -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
> -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_CXX_STANDARD=14
> *-DOCIO_BUILD_DOCS=ON -DOCIO_BUILD_TESTS=ON* -DOCIO_USE_HEADLESS=ON
> -DOCIO_INSTALL_EXT_PACKAGES=NONE -DOpenGL_GL_PREFERENCE=GLVND
> 
> So I'm pretty much at a WTF moment...

I think the problem may be that this:

%{?docs:ON}%{?!docs:OFF}

will give you ON if %docs is *defined*, not if it's *truthy*.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: LXQt image for aarch64 (Self-Contained Change proposal)

2022-10-27 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Oct 14, 2022 at 03:39:42PM -0400, Ben Cotton wrote:
> == How To Test ==
> 
> Install using the ISO or the disk image on aarch64 system. The system
> should work as it should be by manually installing on top of any
> existing aarch64 system.

Does our QA have the necessary resources (hardware, people, time) to
test an additional image?

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads up! OpenImageIO 2.4 series coming to rawhide

2022-10-27 Thread Richard Shaw 
On Thu, Oct 27, 2022 at 5:15 PM Tom Rix  wrote:

> Sorry, I did not run into the freeglut-devel problem with the manual build
>

I think I have something funny going on with the conditionals. Initially
they were negative conditionals:

%if ! 0%{?bootstrap} || ! 0%{?rhel}
%global docs 1
%global tests 1
%endif


And I noticed that the build was trying to pull in build deps that it
should not. As an experiment I changed it to a full positive conditional
and that seemed to have *MOSTLY* worked:

%if 0%{?bootstrap} || 0%{?rhel}
%global docs 0
%global tests 0
%else
%global docs 1
%global tests 1
%endif

The BR's are not getting pulled in, and yet, on the cmake command, both
docs and tests are still true, which from what I can tell should not be:

%cmake -DCMAKE_CXX_STANDARD=14 \
   -DOCIO_BUILD_DOCS=%{?docs:ON}%{?!docs:OFF} \
   -DOCIO_BUILD_TESTS=%{?tests:ON}%{?!tests:OFF} \
   -DOCIO_USE_HEADLESS=ON \
   -DOCIO_INSTALL_EXT_PACKAGES=NONE \
%ifnarch x86_64
   -DOCIO_USE_SSE=OFF \
%endif
   -DOpenGL_GL_PREFERENCE=GLVND

...

+ /usr/bin/cmake -S . -B redhat-linux-build
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF
-DCMAKE_INSTALL_PREFIX:PATH=/usr
-DINCLUDE_INSTALL_DIR:PATH=/usr/include
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
-DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_CXX_STANDARD=14
*-DOCIO_BUILD_DOCS=ON -DOCIO_BUILD_TESTS=ON* -DOCIO_USE_HEADLESS=ON
-DOCIO_INSTALL_EXT_PACKAGES=NONE -DOpenGL_GL_PREFERENCE=GLVND

So I'm pretty much at a WTF moment...

Any help appreciated...

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads up! OpenImageIO 2.4 series coming to rawhide

2022-10-27 Thread Tom Rix 

Sorry, I did not run into the freeglut-devel problem with the manual build

I am using rhel 9.1, from poking around, i see there is a problem that 
it is missing only on rhel 9.0.


I am not sure of how to fix without ifdef-ing out for all rhel 9.

I am assuming there is a knob in ocio that makes freeglut optional.

Which i whip up and submit a pr, if that is as good as it gets.

Tom

On 10/27/22 2:58 PM, Richard Shaw wrote:
Until the issues with OCIO can be fixed or worked around, I went ahead 
and submitted an update for the bootstrap build of OIIO since it may 
still be useful even without OCIO and I didn't want to leave it in limbo.


https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1297e820b2 



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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 Final blocker status update

2022-10-27 Thread Ben Cotton 
Because of the openssl blocker, we are targeting 15 November. See the
Fedora Magazine article for more information behind the reasoning:
https://fedoramagazine.org/fedora-linux-37-update/


Action summary


Accepted blockers
-

1. gnome-calendar — Editing the recurring event freezes Calendar. — NEW
ACTION: Upstream to diagnose and fix issue

2. kwin — Plasma on Wayland hangs at startup when booting with
nomodeset ("basic graphics" mode) on UEFI) — NEW
ACTION: Kernel maintainers to build update with patch

3. openssl — upcoming critical openssl vulnerability — NEW
ACTION: openssl maintainers to build version 3.0.7 when released

Proposed blockers
-

(none)


Bug-by-bug detail
=

Accepted blockers
-

1. gnome-calendar — https://bugzilla.redhat.com/show_bug.cgi?id=2135772 — NEW
Editing the recurring event freezes Calendar.

Fixing other recurring-event handling in Calendar reveals that the
handling in general is, as upstream calls it, "stupidly broken." In
short: with both (and only) weekly recurrence and "until date"
termination, editing a recurring event causes Calendar to crash.

2. kwin — https://bugzilla.redhat.com/show_bug.cgi?id=2136234 — NEW
Plasma on Wayland hangs at startup when booting with nomodeset ("basic
graphics" mode) on UEFI

The DRM driver advertises some formats that aren't actually supported
by the hardware. Kwin naively believes the kernel, resulting in a
failure to launch Plasma under certain conditions. A patch has been
discussed upstream and will be added to an F37 kernel udpate.

3. openssl — https://bugzilla.redhat.com/show_bug.cgi?id=2137661 — NEW
upcoming critical openssl vulnerability

A "critical" severity bug is fixed in an openssl release due Tuesday 1
November. That's about all we know at this point.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads up! OpenImageIO 2.4 series coming to rawhide

2022-10-27 Thread Richard Shaw 
Until the issues with OCIO can be fixed or worked around, I went ahead and
submitted an update for the bootstrap build of OIIO since it may still be
useful even without OCIO and I didn't want to leave it in limbo.

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1297e820b2

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Test-Announce] Fedora Linux 37 Final is NO-GO

2022-10-27 Thread Ben Cotton 
Due to outstanding blocker bugs[1], F37 Final release candidate 3 was
declared NO-GO. Because of the upcoming OpenSSL critical vulnerability
disclosure, we are pushing the next target date out a week. See the
Fedora Magazine article[2] for more information.

The next Fedora Linux 37 Final Go/No-Go meeting[3] will be held at
1700 UTC on Thursday 10 November in #fedora-meeting. We will aim for
the "target date #3" milestone of 15 November. The release schedule[4]
has been updated accordingly.

Minutes[5] and full logs[6] are available on Meetbot.

[1] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist
[2] https://fedoramagazine.org/fedora-linux-37-update/
[3] https://calendar.fedoraproject.org/meeting/10360/
[4] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html
[5] 
https://meetbot.fedoraproject.org/fedora-meeting/2022-10-27/f37-final-go_no_go-meeting.2022-10-27-17.01.html
[6] 
https://meetbot.fedoraproject.org/fedora-meeting/2022-10-27/f37-final-go_no_go-meeting.2022-10-27-17.01.log.html

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora CoreOS Meeting Minutes 2022-10-26

2022-10-27 Thread Dusty Mabe 
Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-10-26/fedora_coreos_meeting.2022-10-26-16.30.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-10-26/fedora_coreos_meeting.2022-10-26-16.30.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-10-26/fedora_coreos_meeting.2022-10-26-16.30.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:30:38 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-10-26/fedora_coreos_meeting.2022-10-26-16.30.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:30:44)

* Action items from last meeting  (dustymabe, 16:35:19)
  * ACTION: bgilbert will follow up on
https://github.com/coreos/fedora-coreos-tracker/issues/567 re.
VMware   (dustymabe, 16:36:05)

* 20221101: CRITICAL OpenSSL vulnerability  (dustymabe, 16:36:27)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1329
(dustymabe, 16:36:46)
  * LINK:

https://developers.redhat.com/blog/2019/06/24/go-and-fips-140-2-on-red-hat-enterprise-linux
(travier, 16:49:25)
  * LINK:

https://developers.redhat.com/articles/2022/05/31/your-go-application-fips-compliant
(travier, 16:50:08)
  * LINK:

https://developers.redhat.com/articles/2022/05/31/your-go-application-fips-compliant
> this one seems to confirm that this is not the case on Fedora so
we should be good for ignition  (travier, 16:51:54)
  * we will meet again tomorrow once Fedora decides if F37 will ship
next week to discuss the scenarios here.  (dustymabe, 17:17:42)

* including audit in Fedora CoreOS  (dustymabe, 17:21:34)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/461
(dustymabe, 17:21:40)

* open floor   (dustymabe, 17:22:27)

Meeting ended at 17:32:19 UTC.




Action Items

* bgilbert will follow up on
  https://github.com/coreos/fedora-coreos-tracker/issues/567 re. VMware




Action Items, by person
---
* bgilbert
  * bgilbert will follow up on
https://github.com/coreos/fedora-coreos-tracker/issues/567 re.
VMware
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (99)
* bgilbert (82)
* travier (56)
* zodbot (24)
* jlebon (11)
* lucab (7)
* adamw (5)
* fifofonix (3)
* mnguyen (1)
* gursewak (1)
* jbrooks (1)
* aaradhak (1)
* Nemric (1)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: No response on BCC releated bugs

2022-10-27 Thread David Stux 
Great, thank you guys, looking forward for it.(I mistyped FC35 but meant FC36, not working with FC35 and not aware what's the state there.) 27.10.2022, 10:17, "Jiri Olsa" :On Thu, Oct 27, 2022 at 07:45:39AM +0900, Dominique Martinet wrote: +Jiri in To  Dave Stux wrote on Wed, Oct 26, 2022 at 09:39:23PM -: > I have opened bugs relating to bcc, and I see no reply on them. > Currently, at least in my testing, the state of ,pst pf the bcc dependent tools in F35 is broken. > Examples: > https://bugzilla.redhat.com/show_bug.cgi?id=2127642 > https://bugzilla.redhat.com/show_bug.cgi?id=2057139  bcc 0.22 is quite old and I think you have it right in this bug: just updating to a newer bcc version would likely fix all these issues.  fedora 37+ have bcc 0.24 which is more reasonable and probably works, so I guess it'd just be a matter of pushing it for f35/36 as well.  (note there's a bcc 0.25 that might be good for rawhide, but it breaks API on bcc_prog_load_xattr() breaking e.g. older gobpf or bpftrace, see https://github.com/iovisor/bpftrace/issues/2340 , so that one should not be backported -- but I'm not aware of any such problem for bcc 0.22 to 0.24)  > I have filled non-responsive bug, but there's no reply on it too: > https://bugzilla.redhat.com/show_bug.cgi?id=2136222 > > Can anyone contact Jiri Olsa or update if he is out on vacation? > Is there an additional package maintainer?hi,sorry for delay.. I talked to Jerome on Monday and he willtake care of thatjirka___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-27 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, Oct 26, 2022 at 09:33:34AM +0200, Jakub Jelinek wrote:
> On Wed, Oct 26, 2022 at 07:06:43AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > == User Experience ==
> > > User experience does not change.
> > 
> > "The new default for C standard is -c99. Users who want to use
> > an older standard need to specify something like -c89." (???)
> 
> It is -std=c89/-std=gnu89 actually.

Something like this [with any necessary corrections] should be part of
the Change text, in a way that is easy for users to find.

> > > == Dependencies ==
> > > To avoid regressing the porting effort, GCC as the system compiler
> > > needs to reject obsolete constructs by default. This is expected for
> > > GCC 14, to be released as part of Fedora 40 in Spring 2024.
> > > 
> > > == Contingency Plan ==
> > > * Contingency mechanism: Upstream GCC will probably accept obsolete
> > > constructs longer in case distributions like Fedora cannot port to
> > > modern C in time.
> > 
> > Hmm, this sounds ominous, like if GCC might stop accepting old C syntax
> > altogether. Isn't this just a question of specifying the right standard
> > in compilation options?
> 
> GCC hasn't changed anything yet, the obsolete constructs are accepted
> for decades with warnings, some of them in -Wall, others in -Wextra.
> The goal of Florian's work is to determine if it is feasible to reject them
> in -std={c,gnu}{9x,99,1x,11,17,18,2x} modes by default in GCC 14.
> 
> Examples of the obsolescent syntax:

I'm generally understand what is happening. I was complaining that the
Change page doesn't do a very good job of providing a quick explanation
to a casual reader.

> > > == Release Notes ==
> > > Probably not needed because no user visible impact is intended.
> > 
> > It's not clear from the description: what about users who compile programs?
> 
> It would be GCC that rejects those by default, so it would affect users
> compiling programs as well.

Right. So both "Upgrade/compatibility impact" and "Release notes" need
to be adjusted.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

python-rdflib updated to 6.2.0 without advance notification

2022-10-27 Thread Sandro 

Dear rdflib maintainers,

A friendly reminder for the future to please notify the devel list and 
maintainers of dependent packages (see below) *a week in advance* before 
pushing major updates entailing ABI/API changes to rawhide [1].


The update has also made it into F37 without notification. As a result 
python-odml is FTBFS [2]. This is because python-odml has not yet moved 
to rdflib 6.x and still depends on 5.x. Upstream is still working on 
adapting to rdfllib 6.x.


There was also some fallout along the way related to the inclusion of 
jsonld in rdflib >= 6. [3]


Quick dependency check:

$ dnf -q --repo=rawhide repoquery --whatrequires python3-rdflib \
--alldeps
lv2-devel-0:1.18.8-4.fc38.i686
lv2-devel-0:1.18.8-4.fc38.x86_64
python3-biopython-0:1.79-4.fc37.x86_64
python3-odml-0:1.5.1-4.fc37.noarch
python3-owl_rl-0:6.0.2-3.fc38.noarch
python3-prov-0:1.5.2-16.fc37.noarch
python3-pynlpl-0:1.2.7-14.fc37.noarch
python3-rdflib-jsonld-0:0.6.0-6.fc38.noarch
python3-selenium-0:3.141.0-1.fc38.noarch

[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2113639
[3] 
https://lists.fedoraproject.org/archives/list/neurofed...@lists.fedoraproject.org/thread/WMSD5KMHJNTSEUS7SAEXVJT4GV7M32FR/


Best regards,
--
Sandro
FAS: gui1ty
IRC: Penguinpee
Elsewhere: [Pp]enguinpee
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: IMA testing, Re: Fedora Linux 37 Beta Released

2022-10-27 Thread David Sastre 
Hello and apologies for resurrecting an old thread.

I was looking for information regarding IMA in F37 and found it was asked
but I could not see any replies.
My question is exactly the same as the OP, I do not see security.ima
attributes on files after upgrading to F37.
(https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents)

```
$ getfattr --absolute-names -d -m - /usr/bin/cp
# file: /usr/bin/cp
security.selinux="system_u:object_r:bin_t:s0"
```

This output is after reinstalling coreutils. I have rpm-plugin-ima
installed.

Also, where could one find the publiccert.der certificate to perform manual
validation?
It is not published at https://getfedora.org/security/

I do not have any custom policy defined for IMA, but that should not matter:

```
$ sudo cat /sys/kernel/security/ima/policy
measure func=KEXEC_KERNEL_CHECK
measure func=MODULE_CHECK
```

Thanks.


On Tue, Sep 13, 2022 at 9:28 PM Frank Ch. Eigler  wrote:

>
> bcotton wrote:
>
> > [...]
> > ## Beta Release Highlights
> > [...]
> > # RPM content is now signed with IMA signatures
>
> How can one observe this?  Even with rpm-plugin-ima installed, steps in:
>
> https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents#How_To_Test
>
> produce no output for any of the files I tried in a f37-beta install.
> The appropriate "publiccert.der" file does not seem to be available
> either.
>
> - FChE
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora 37 compose report: 20221027.n.0 changes

2022-10-27 Thread Fedora Rawhide Report 
OLD: Fedora-37-20221026.n.0
NEW: Fedora-37-20221027.n.0

= SUMMARY =
Added images:0
Dropped images:  9
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-37-20221026.n.0.iso
Image: Container_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Base-37-20221026.n.0.s390x.tar.xz
Image: Server_KVM qcow2 s390x
Path: Server/s390x/images/Fedora-Server-KVM-37-20221026.n.0.s390x.qcow2
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-37-20221026.n.0.s390x.raw.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-37-20221026.n.0.s390x.qcow2
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-37-20221026.n.0.iso
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-37-20221026.n.0.s390x.tar.xz
Image: Container_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Base-37-20221026.n.0.aarch64.tar.xz
Image: Everything boot s390x
Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-37-20221026.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads up! OpenImageIO 2.4 series coming to rawhide

2022-10-27 Thread Richard Shaw 
I have both repos now and I have the bootstrap build of OIIO done.

The problem is OCIO. It looks like freeglut-devel is not available in EPEL
9. Also I found a dependency on openshadinglanguage I was previously
unaware of.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Packaging a cross-compilation environment (wasi-libc)

2022-10-27 Thread Jun Aruga (he / him) 
On Mon, Oct 24, 2022 at 1:19 PM Jan Staněk  wrote:
>
> Hi Jun,
>
> "Jun Aruga (he / him)"  writes:
> > Do you have a plan to create the RPM package for wasi-sdk[1]?
>
> Not really, since we already (almost) have it available :)
>
> The wasi-sdk consists of llvm toolchain (clang & friends) compiled so
> that it can emit WASM code, and the wasi-libc, which implements standard
> C library atop WebAssembly System Interface "syscalls".
>
> Fedora's clang is already capable of emitting wasm
> (`clang --target=wasm32-wasi -nostdlib …` works), so I see no need to
> package it again. The thing we are missing is the wasi-libc,
> which I aimed to package.
>
> In other words, packaging wasi-sdk seems redundant to me
> – you would have to maintain separate version of clang,
> while the Fedora one is already able to compile what you need.
> We still need the C lib.
>
> Unfortunately, recent NodeJS releases had me occupied pretty much entirely,
> so I was unable to work on this.
> I hope I can get back to it this week. Fingers crossed.

Hi Jan,
Thanks for sharing the info.
I understand that when the clang supports the WASI (wasm32-wasi)
target, we don't need to build wasi-sdk or use the wasi-sdk RPM
package. It's just redundant.
Our encouraged way to use WebAssembly from Ruby can be to build the
Ruby source with the `clang --target=wasm32-wasi -nostdlib …` without
using the Ruby RPM.

> > But I
> > feel it takes more than 60 minutes, and is still in progress.
> > I wonder how other program languages supporting WebAssembly manage
> > this situation.
>
> Yeah, building entire compiler toolchain takes a while :)
>
> I had a COPR of the WIP wasi-sdk, but I set it to expire automatically,
> so it is currently not available. I'll try to spin in back up today
> and send you a link, in case you want to start testing the Ruby stuff
> with it already.
>
> Have a nice day!

As I see building Ruby with the WASI (wasm32-wasi) target on clang (or
wasi-sdk) is exclusive with the current normal built Ruby on GCC in
the Ruby RPM. I have no plan to include the WASI target build in the
current Ruby RPM package. I have already tested the Ruby built from
source with the wasi-sdk. That's ok for now. I don't need additional
tests for now. Thanks.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mailman3 on Fedora 36

2022-10-27 Thread Andreas Schneider 
On Tuesday, 25 October 2022 19:16:32 CEST Sjoerd Mullender wrote:
> > The issue with installing mailman3 might be due to sqlalchemy, though:
> > There is a 1.3 compat package but it conflicts with the update. If you
> > want to "rescue" mailman3 in f36 even though it is retired in rawhide
> > this might be an option.
> 
> In my version, I indeed require sqlalchemy1.3.

The patch to support sqlalchem 1.4 is pretty simple. See

https://build.opensuse.org/package/view_file/
devel:languages:python:mailman:backports/python-mailman/mailman-support-
sqlalchemy-1-4.patch?expand=1

I'm using this in production while waiting for a better fix from upstream.

https://gitlab.com/mailman/mailman/-/merge_requests/1034

FYI: mailman 3.3.6 has been released yesterday.

Cheers


Andreas

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-27 Thread Vít Ondruch 


Dne 27. 10. 22 v 6:57 Florian Weimer napsal(a):

* Kevin Fenzi:


On Wed, Oct 26, 2022 at 10:23:40AM +0200, Florian Weimer wrote:

* Zbigniew Jędrzejewski-Szmek:


More recently, I was explicitly told not to keep the compiler changes on
a branch in Fedora dist-git.

It is not really possible to get realistic testing through compiler flag
injection because crufty old code that is problematic for these changes
often does not inject flags properly.  Certain likely changes cannot be
modeled through -Werror= options (but can be patched into GCC).  Some
build systems explicitly filter out -Werror= options during the
configure stage (generally a good idea, but not helpful here).

So I'm a bit at a loss what to do here.  Maybe releng can reconsider
their approach.

So, can you say that copr definitely will not work for this?

As far as I can tell, COPR doesn't do scratch builds.  So if I publish a
repository in COPR with everything required in it, Fedora developers
still cannot run a single command that uploads some SRPMs and runs a
build with the right buildroot configuration.  They have to create their
own COPR project first and build into that.



They have to create their own Copr, righ, but they can specify 
repositories of your Copr to include everything needed via Settings > 
Project Details > 2. Build options > External Repositories:



And of course, you can give access to your repository to anybody who 
asks Settings > Request Permissions



There is also Other Actions > Fork this project option, but I have no 
experience with this option if this is feasible way or not.




Vít



  Maybe it's possible to
script this in some way.  Maybe it's also possible to provide a
reference mock configuration for local builds.  But I think it's going
to be less convenient for packagers than running a scratch build against
Koji.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue