Sinking Fund meaning

[Stanlee's Studio]

https://aliceblueonline.com/what-is-a-sinking-fund/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Rust bindings for Python (pyo3 versions <0.19, cpython) broken with Python 3.12

[Kevin Fenzi]

On Mon, Nov 13, 2023 at 07:25:10PM +0100, Fabio Valentini wrote:
> 
> Yup, I've mentioned that in the bug I filed for python-bcrypt -
> It might be as simple as bumping the dependency on pyo3 from v0.15 to v0.19.

I've made an attempt here: 
https://src.fedoraproject.org/rpms/python-bcrypt/pull-request/9

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

Re: Groff: Revert the mapping of special characters for UTF-8 devices introduced in 1.23.0 version

[Adam Williamson]

On Thu, 2023-11-16 at 23:41 +0100, Lukas Javorsky wrote:
> > 
> > I think an upstream only wants to adhere to the language specification
> > (groff_char(7)). These small differences became prominent with the advent
> > of
> > UTF-8 capable terminals. They have always been visible in a PostScript
> > output.
> > 
> > Imagine you are the upstream and a user sends you a bug report that groff
> > does
> > not behave according to the specification. While another user complains
> > that
> > his nonconforming input behaves weirdly. There is no solution which would
> > satisfy both.
> > 
> 
> I totally understand why they made the change, I just don't see the reason
> for requesting them to put the mapping back.
> 
> I think the right decision would be that upstreams of the packages that
> have the man pages written with the wrong character, should be the ones to
> fix their man pages.

But they *don't* have their man pages written with the "wrong
character". That's one reason why this is awkward and controversial.

The man pages are written with the *right* character - an ASCII dash,
the character that is actually used for arguments to console commands.
groff is converting this to a Unicode dash based on the expectation
that it's being used for something more "text-y", and the writer just
used an ASCII dash because it's much more convenient to type, but they
really want a more text-ish dash. This may be the case for a lot of
text, but it's definitely not the case for CLI tool manpages. When they
write an ASCII dash, they want it to stay as an ASCII dash.

With the 'new' behaviour, you have to markup or escape your ASCII
dashes somehow to prevent groff turning them into unicode dashes.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
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: Groff: Revert the mapping of special characters for UTF-8 devices introduced in 1.23.0 version

[Lukas Javorsky]

>
> I think an upstream only wants to adhere to the language specification
> (groff_char(7)). These small differences became prominent with the advent
> of
> UTF-8 capable terminals. They have always been visible in a PostScript
> output.
>
> Imagine you are the upstream and a user sends you a bug report that groff
> does
> not behave according to the specification. While another user complains
> that
> his nonconforming input behaves weirdly. There is no solution which would
> satisfy both.
>

I totally understand why they made the change, I just don't see the reason
for requesting them to put the mapping back.

I think the right decision would be that upstreams of the packages that
have the man pages written with the wrong character, should be the ones to
fix their man pages.
However, I'm not very confident that they would willingly do that, and not
sure if there are enough volunteers to do that for them.

That being said, the new groff version with the mapping for the old
characters is now in stable for both Fedora 39 and Fedora Rawhide.

On Thu, Nov 9, 2023 at 12:41 PM Petr Pisar  wrote:

> V Thu, Nov 09, 2023 at 12:11:55PM +0100, Lukas Javorsky napsal(a):
> > >
> > > Did we try to persuade upstream to revert the problem?  But if they're
> > > not receptive then a downstream fix aligned with Debian looks right.
> > >
> >
> > I didn't yet. However, if they decided to stop mapping these characters,
> I
> > don't think they would be willing to revert it back. They mentioned the
> > option to map it locally as I did in the PR. I assume they want to stop
> > mapping it on their end and let distros decide if they want to do it
> > themselves.
> >
> I think an upstream only wants to adhere to the language specification
> (groff_char(7)). These small differences became prominent with the advent
> of
> UTF-8 capable terminals. They have always been visible in a PostScript
> output.
>
> Imagine you are the upstream and a user sends you a bug report that groff
> does
> not behave according to the specification. While another user complains
> that
> his nonconforming input behaves weirdly. There is no solution which would
> satisfy both.
>
> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
>


-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

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

Planned Outage - pagure.io network switch updates - 2023-11-17 13:00 UTC

[Kevin Fenzi]

Planned Outage - pagure.io network switch updates - 2023-11-17 13:00 UTC

There will be an outage starting at 2023-11-17 13:00UTC,
which will last approximately 4 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2023-11-17 13:00UTC'

Reason for outage:

Network switches in the datacenter that hosts pagure.io will be
updated and rebooted. This should result in a small (~20m) break
in connectivity sometime in the outage window.

Affected Services:

pagure.io

Ticket Link:

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

Please join #fedora-admin or #fedora-noc on irc.libera.chat
or #admin:fedoraproject.org / #noc:fedoraproject.org on matrix.
Please add comments to the ticket for this outage above.

Updated status for this outage may be available at
https://www.fedorastatus.org/



signature.asc
Description: PGP signature
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel-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

Re: Can we assume all chroots follow UsrMove?

[Neal Gompa]

On Thu, Nov 16, 2023 at 10:37 AM John Reiser  wrote:
>
> > Is it safe to assume that this symbolic link [/lib64 -> usr/lib64]
> > exists in all chroots?
> > This includes the initial ramdisk, recovery environments, and chroots
> > for confining services.
>
> It is unsafe unless prominently documented in the places that are likely
> to be seen by affected developers, now and especially *in the future*:
> man glibc, info glibc, man chroot, info chroot, man docker, man virtmgr, etc.
> Such a change has aspects of being a System-Wide Change for Fedora.
> For instance, I have a recipe for an "embedded" Docker
> that will have to add the symlink.

Unless you are somehow excluding the "filesystem" package when
building a Fedora rootfs (which is a required package, so it's quite
hard to avoid), you are not going to be missing that symlink.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Summary/Minutes from today's FESCo Meeting (2023-11-16)

[Zbigniew Jędrzejewski-Szmek]

#info This meeting is cancelled because of lack of quorum.
#info Next meeting will be in two weeks (because of Thanksgiving in U.S.)
#action zbyszek will chair the next meeting

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2023-11-16/fesco.2023-11-16-17.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-2/2023-11-16/fesco.2023-11-16-17.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2023-11-16/fesco.2023-11-16-17.00.log.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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Linker Error on Security Issues (System-Wide)

[Dominik 'Rathann' Mierzejewski]

On Thursday, 16 November 2023 at 09:43, Nick Clifton wrote:
> Hi Dominik,
> 
> > Does the `--no-warn-rwx-segments` disable erroring out on both loadable
> > rwx segments and tls rwx segments?
> 
> Yes.
> 
> At the time I wrote the feature I did consider having separate options
> for the two tests, but it seemed like overkill, so I decided to go
> with just a single controlling option.

That's fine, thank you. Can you please mention which option disables
which error(s) explicitly in the Change?

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

Re: Can we assume all chroots follow UsrMove?

[John Reiser]

Is it safe to assume that this symbolic link [/lib64 -> usr/lib64]
exists in all chroots?
This includes the initial ramdisk, recovery environments, and chroots
for confining services.


It is unsafe unless prominently documented in the places that are likely
to be seen by affected developers, now and especially *in the future*:
man glibc, info glibc, man chroot, info chroot, man docker, man virtmgr, etc.
Such a change has aspects of being a System-Wide Change for Fedora.
For instance, I have a recipe for an "embedded" Docker
that will have to add the symlink.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Summary/Minutes from today's FESCo Meeting (2023-11-09)

[Stephen Smoogen]

On Thu, 16 Nov 2023 at 07:46, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Zbigniew Jędrzejewski-Szmek wrote:
> > This is called "shooting the messenger".
>
> It is not. See my reply to Fabio.
>
> > LSB requires various obsolete interfaces, in particular it requires
> > Python 2 to be available as /usr/bin/python. Comment [1] contains a
> > nice listing. We are not going to bring back Python 2 or old PERL
> > modules to satisfy LSB.
>
> That is exactly the attitude I am complaining about!
>
> It would be very much possible to support the Python 2 parts of the spec,
> without even shipping unmaintained software: Package Tauthon 2.8.4, and
> make
> both /usr/bin/python and /usr/bin/python2 symlinks to /usr/bin/tauthon.
> That


1. It is not clear that would actually be 'valid' for being LSB compliant.
The LSB was written to be very specific in the 'actual' software used.
Substitutes would need approval by the now defunct LSB committee.
2. The packages in Fedora are put in there by individuals who are
interested in maintaining them.  The only things I know of stopping you or
a group of individuals from packing up tauthon or the other 'dead' software
is just the sheer size of the work required. However, that is just the easy
stuff. The perl changes also require similar locked older versions of perl
and module trees so every perl script would also need to now be changed to
refer to specific versions (one being the perl5 approved by LSB and the
other not).

In the end, the real work needed is getting LSB 'going' again. The last
version was over 10 years old and based on what the state of the 'OS' was
in 2012 (it takes time to standardize so even with the last version being
from 2015, it is going to aim at what is generally available in 2012). It
needs a 'reboot' which either meets what is the state of things are in say
2019 or newer. Or interested people can make an OS which will stick to
LSB-5.0 forever.

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Schedule for Thursday's FESCo Meeting (2023-11-16)

[Stephen Gallagher]

On Thu, Nov 16, 2023 at 7:43 AM Major Hayden  wrote:
>
> On Thu, Nov 16, 2023, at 05:59, Zbigniew Jędrzejewski-Szmek wrote:
> > Following is the list of topics that will be discussed in the
> > FESCo meeting Thursday at 17:00UTC in #fedora-meeting-2 on
> > irc.libera.chat.
>
> I won't be able to attend today's meeting as I have two other meetings in the 
> same slot. 😢
>
> As soon as I figure out how to put myself in the copier... 🤔
>

Didn't you do exactly that at last year's holiday party? 🤪
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Summary/Minutes from today's FESCo Meeting (2023-11-09)

[Miro Hrončok]

On 16. 11. 23 13:45, Kevin Kofler via devel wrote:

It would be very much possible to support the Python 2 parts of the spec,
without even shipping unmaintained software: Package Tauthon 2.8.4, and make
both /usr/bin/python and /usr/bin/python2 symlinks to /usr/bin/tauthon. That
should have been the Python 2 migration plan from the beginning, instead of
the package mass retirement spree that was done instead. (And Python 3
should never have been installed as /usr/bin/python. Scripts with
#!/usr/bin/python expect Python 2, silently replacing it with Python 3
breaks the scripts. Anything aware that a Python 3 exists uses, or at least
SHOULD use, #!/usr/bin/python3.)


Thank you for your very constructive suggestion, Kevin!

Why don't you package Tauthon in Fedora, keep it secure by backporting CVE 
fixes from Python 3 (because upstream Tauthon does not) and propose that Fedora 
should go against Python PEPs and Python Software Foundation wishes because... 
scripts.


I would certainly oppose that proposal, but I realize I am biased.

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

Re: HEADS UP: gdal-3.8.0 coming to rawhide

[Sandro Mani]

This is now done, there are two unrelated failures:

- gazebo: graphviz 9.x incompatibility
- vfrnav: broken build dependencies (nothing provides 
libsundials_sunlinsolklu.so.4.6.1()(64bit) needed by 
octave-6:8.4.0-1.fc40.x86_64 from build)


Sandro

On 15.11.23 11:42, Sandro Mani wrote:


Hi

I'll be building gdal-3.8.0 in the f40-build-side-77750 side tag. It 
carries a soname bump, and I'll rebuild the following dependencies:


  GMT
  mapserver
  liblas
  python-fiona
  postgis
  merkaartor
  R-rgdal
  bes
  qmapshack
  PDAL
  ncl
  vfrnav
  python-rasterio
  vtk
  paraview
  kealib
  OpenSceneGraph
  cloudcompare
  grass
  mapnik
  opencv
  mingw-opencv
  osgearth
  qgis
  gazebo

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

Re: Summary/Minutes from today's FESCo Meeting (2023-11-09)

[Daniel P . Berrangé]

On Thu, Nov 16, 2023 at 01:39:14PM +0100, Kevin Kofler via devel wrote:
> Fabio Valentini wrote:
> > There's a difference between *claiming* LSB compliance (what you refer
> > to as backwards compatibility ?) and actually *achieving* it.
> > Claiming it (the thing we objected to) without achieving it (i.e. the
> > status quo for many Fedora releases) is a lie that helps nobody.
> 
> True, but the issue is that FESCo sees the bug in the claim and not in the 
> failure to achieve it, which is where the real issue lies.

Attaining LSB compliance requires some interested persons to step up and
volunteer their time to make it happen. FESCo doesn't have the ability to
force people to work on features they're not interested in. So in the
absence of any volunteers, the FESCo decision is the only outcome that
was reasonably possible at this point in time.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Can we assume all chroots follow UsrMove?

[Neal Gompa]

On Thu, Nov 16, 2023 at 7:42 AM Florian Weimer  wrote:
>
> A while back, we made /lib64 a symbolic link to /usr/lib64:
>
>   
>
> Is it safe to assume that this symbolic link exists in all chroots?
> This includes the initial ramdisk, recovery environments, and chroots
> for confining services.
>
> If we can assume that, we can tell glibc to stop searching for shared
> objects in /lib64 in addition to /usr/lib64.  It will avoid an
> additional failing openat system call if the application calls dlopen
> with a shared object name that the system cannot find.
>

In all practical cases we have, you can make that assumption.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Summary/Minutes from today's FESCo Meeting (2023-11-09)

[Kevin Kofler via devel]

Zbigniew Jędrzejewski-Szmek wrote:
> This is called "shooting the messenger".

It is not. See my reply to Fabio.

> LSB requires various obsolete interfaces, in particular it requires
> Python 2 to be available as /usr/bin/python. Comment [1] contains a
> nice listing. We are not going to bring back Python 2 or old PERL
> modules to satisfy LSB.

That is exactly the attitude I am complaining about!

It would be very much possible to support the Python 2 parts of the spec, 
without even shipping unmaintained software: Package Tauthon 2.8.4, and make 
both /usr/bin/python and /usr/bin/python2 symlinks to /usr/bin/tauthon. That 
should have been the Python 2 migration plan from the beginning, instead of 
the package mass retirement spree that was done instead. (And Python 3 
should never have been installed as /usr/bin/python. Scripts with 
#!/usr/bin/python expect Python 2, silently replacing it with Python 3 
breaks the scripts. Anything aware that a Python 3 exists uses, or at least 
SHOULD use, #!/usr/bin/python3.)

But Fedora just does not care about keeping working software working.

> The decision of FESCo is to not claim compatibility when we don't provide
> it.

That makes sense, but the issue is the latter part, not the former.

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

Re: Schedule for Thursday's FESCo Meeting (2023-11-16)

[Major Hayden]

On Thu, Nov 16, 2023, at 05:59, Zbigniew Jędrzejewski-Szmek wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Thursday at 17:00UTC in #fedora-meeting-2 on
> irc.libera.chat.

I won't be able to attend today's meeting as I have two other meetings in the 
same slot. 😢

As soon as I figure out how to put myself in the copier... 🤔

-- 
Major Hayden
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Can we assume all chroots follow UsrMove?

[Florian Weimer]

A while back, we made /lib64 a symbolic link to /usr/lib64:

  

Is it safe to assume that this symbolic link exists in all chroots?
This includes the initial ramdisk, recovery environments, and chroots
for confining services.

If we can assume that, we can tell glibc to stop searching for shared
objects in /lib64 in addition to /usr/lib64.  It will avoid an
additional failing openat system call if the application calls dlopen
with a shared object name that the system cannot find.

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

Re: Summary/Minutes from today's FESCo Meeting (2023-11-09)

[Kevin Kofler via devel]

Fabio Valentini wrote:
> There's a difference between *claiming* LSB compliance (what you refer
> to as backwards compatibility ?) and actually *achieving* it.
> Claiming it (the thing we objected to) without achieving it (i.e. the
> status quo for many Fedora releases) is a lie that helps nobody.

True, but the issue is that FESCo sees the bug in the claim and not in the 
failure to achieve it, which is where the real issue lies.

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

Fedora rawhide compose report: 20231116.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20231115.n.0
NEW: Fedora-Rawhide-20231116.n.0

= SUMMARY =
Added images:1
Dropped images:  3
Added packages:  5
Dropped packages:2
Upgraded packages:   87
Downgraded packages: 0

Size of added packages:  7.11 MiB
Size of dropped packages:199.17 KiB
Size of upgraded packages:   4.84 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20231116.n.0.iso

= DROPPED IMAGES =
Image: Onyx dvd-ostree x86_64
Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20231115.n.0.iso
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20231115.n.0.iso
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20231115.n.0.iso

= ADDED PACKAGES =
Package: chirp-0.4.0^20231101git35c8a1c0-3.fc40
Summary: A tool for programming two-way radio equipment
RPMs:chirp chirp+wx
Size:2.28 MiB

Package: nodejs-undici-5.27.2-5.fc40
Summary: An HTTP/1.1 client, written from scratch for Node.js
RPMs:nodejs-undici
Size:326.36 KiB

Package: orage-4.18.0-1.fc40
Summary: A calendar application
RPMs:orage
Size:4.23 MiB

Package: rdfind-1.6.0-1.fc40
Summary: Program that finds duplicate files
RPMs:rdfind
Size:235.13 KiB

Package: rust-colorgrad-0.6.2-1.fc40
Summary: Color scales library for data visualization, charts, games, generative 
art and others
RPMs:rust-colorgrad+default-devel rust-colorgrad+named-colors-devel 
rust-colorgrad-devel
Size:55.68 KiB


= DROPPED PACKAGES =
Package: antlr-maven-plugin-2.2-37.fc39
Summary: Maven plugin that generates files based on grammar file(s)
RPMs:antlr-maven-plugin antlr-maven-plugin-javadoc
Size:156.50 KiB

Package: python-oslo-sphinx-4.18.0-19.fc39
Summary: OpenStack Sphinx Extensions
RPMs:python3-oslo-sphinx
Size:42.67 KiB


= UPGRADED PACKAGES =
Package:  Thunar-4.18.8-1.fc40
Old package:  Thunar-4.18.7-1.fc40
Summary:  Thunar File Manager
RPMs: Thunar Thunar-devel Thunar-docs
Size: 10.29 MiB
Size change:  8.01 KiB
Changelog:
  * Thu Nov 16 2023 Mukundan Ragavan  - 4.18.8-1
  - Update to v4.18.8


Package:  annobin-12.31-1.fc40
Old package:  annobin-12.30-1.fc40
Summary:  Annotate and examine compiled binary files
RPMs: annobin-annocheck annobin-docs annobin-libannocheck 
annobin-plugin-clang annobin-plugin-gcc annobin-plugin-llvm
Size: 5.42 MiB
Size change:  780 B
Changelog:
  * Wed Nov 15 2023 Nick Clifron   - 12.31-1
  - Update glibc detection heuristics for PPC64.  (RHEL-16453)


Package:  asnmap-1.0.6-1.fc40
Old package:  asnmap-1.0.5-1.fc40
Summary:  Go CLI and Library for quickly mapping organization network 
ranges using ASN information
RPMs: asnmap golang-github-projectdiscovery-asnmap-devel
Size: 23.57 MiB
Size change:  293.58 KiB
Changelog:
  * Wed Nov 15 2023 Mikel Olasagasti Uranga  - 1.0.6-1
  - Update to 1.0.6 - Closes rhbz#2249177


Package:  c-ares-1.21.0-1.fc40
Old package:  c-ares-1.19.1-1.fc39
Summary:  A library that performs asynchronous DNS operations
RPMs: c-ares c-ares-devel
Size: 1.19 MiB
Size change:  96.53 KiB
Changelog:
  * Sun Nov 05 2023 Tom Callaway  - 1.21.0-1
  - update to 1.21.0


Package:  ceph-2:18.2.1-1.fc40
Old package:  ceph-2:18.2.0-3.fc40
Summary:  User space components of the Ceph file system
RPMs: ceph ceph-base ceph-common ceph-exporter ceph-fuse 
ceph-grafana-dashboards ceph-immutable-object-cache ceph-mds ceph-mgr 
ceph-mgr-cephadm ceph-mgr-dashboard ceph-mgr-diskprediction-local 
ceph-mgr-k8sevents ceph-mgr-modules-core ceph-mgr-rook ceph-mib ceph-mon 
ceph-osd ceph-prometheus-alerts ceph-radosgw ceph-resource-agents ceph-selinux 
ceph-test ceph-volume cephadm cephfs-mirror cephfs-shell cephfs-top 
libcephfs-devel libcephfs2 libcephsqlite libcephsqlite-devel librados-devel 
librados2 libradospp-devel libradosstriper-devel libradosstriper1 librbd-devel 
librbd1 librgw-devel librgw2 python3-ceph-argparse python3-ceph-common 
python3-cephfs python3-rados python3-rbd python3-rgw rados-objclass-devel 
rbd-fuse rbd-mirror rbd-nbd
Size: 418.68 MiB
Size change:  1.50 MiB
Changelog:
  * Wed Nov 01 2023 Terje Rosten  - 2:18.2.0-4
  - Rebuild for gtest 1.14.0 and libarrow 14.0.0

  * Wed Nov 15 2023 Kaleb S. KEITHLEY  - 2:18.2.1-1
  - ceph-18.2.1 GA


Package:  checkpolicy-3.6-0.rc1.1.fc40
Old package:  checkpolicy-3.5-3.fc39
Summary:  SELinux policy compiler
RPMs: checkpolicy
Size: 1.40 MiB
Size change:  10.81 KiB
Changelog:
  * Tue Nov 14 2023 Petr Lautrbach  - 3.6-0.rc1.1
  - SELinux userspace 3.6-rc1 release


Package:  cockpit-305-1.fc40
Old package:  cockpit-304-1.fc40
Summary:  Web Console for Linux

[Fedocal] Reminder meeting : ELN SIG

[sgallagh]

Dear all,

You are kindly invited to the meeting:
   ELN SIG on 2023-11-17 from 12:00:00 to 13:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:



Source: https://calendar.fedoraproject.org//meeting/10568/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Schedule for Thursday's FESCo Meeting (2023-11-16)

[Zbigniew Jędrzejewski-Szmek]

Following is the list of topics that will be discussed in the
FESCo meeting Thursday at 17:00UTC in #fedora-meeting-2 on
irc.libera.chat.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2023-11-16 17:00 UTC'

Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda


= Discussed and Voted in the Ticket =

#3091 F40 Change: BogofilterSqlite
https://pagure.io/fesco/issue/3091
APPROVED (+5, 0, 0)

#3092 Change: MariaDB & MySQL repackaging
https://pagure.io/fesco/issue/3092
APPROVED (+6, 0, 0)

#3094 Election Interview Questions Review for F39
https://pagure.io/fesco/issue/3094
In a week, there were no comments to the contrary, so we're going to
use the same questions as for the last election.


= Followups =

#3089 retiring redhat-lsb in Fedora
https://pagure.io/fesco/issue/3089


= New business =

#3097 Change: DNF Conditional File Lists
https://pagure.io/fesco/issue/3097

#3098 Change: Drop sshd Socket
https://pagure.io/fesco/issue/3098

#3101 Change: Remove OpenSSL Compat
https://pagure.io/fesco/issue/3101


= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Summary/Minutes from today's FESCo Meeting (2023-11-09)

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 16, 2023 at 01:28:31AM +0100, Kevin Kofler via devel wrote:
> Neal Gompa wrote:
> > * AGREED: Fedora explicitly declines to support the LSB 5.0 or
> > earlier. Packagers will remove any information that implies
> > otherwise. No implementation of an LSB package may expressly state
> > or offer compliance for any LSB module that Fedora does not or
> > cannot comply with. (+6, 0, 0)  (Son_Goku, 17:59:18)
> 
> So Fedora has completely discarded any notion of backwards compatibility. 
> Sad.

This is called "shooting the messenger".

LSB requires various obsolete interfaces, in particular it requires
Python 2 to be available as /usr/bin/python. Comment [1] contains a
nice listing. We are not going to bring back Python 2 or old PERL
modules to satisfy LSB. The decision of FESCo is to not claim
compatibility when we don't provide it.

[1] https://pagure.io/fesco/issue/3089#comment-881313

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: Summary/Minutes from today's FESCo Meeting (2023-11-09)

[Fabio Valentini]

On Thu, Nov 16, 2023 at 1:30 AM Kevin Kofler via devel
 wrote:
>
> Neal Gompa wrote:
> > * AGREED: Fedora explicitly declines to support the LSB 5.0 or
> > earlier. Packagers will remove any information that implies
> > otherwise. No implementation of an LSB package may expressly state
> > or offer compliance for any LSB module that Fedora does not or
> > cannot comply with. (+6, 0, 0)  (Son_Goku, 17:59:18)
>
> So Fedora has completely discarded any notion of backwards compatibility.
> Sad.

There's a difference between *claiming* LSB compliance (what you refer
to as backwards compatibility ?) and actually *achieving* it.
Claiming it (the thing we objected to) without achieving it (i.e. the
status quo for many Fedora releases) is a lie that helps nobody.

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

Re: SPDX Statistics - Kristallnacht edition

[Michael J Gruber]

Am Do., 16. Nov. 2023 um 01:27 Uhr schrieb Kevin Kofler via devel <
devel@lists.fedoraproject.org>:

> Miroslav Suchý wrote:
> > Why Kristallnachte edition? On today's date at 1938, was i Kristallnacht
> > (Night of Broken Glass) - a pogrom against Jews in Germany. It was first
> > step where every other step was worse than the previous one. It was
> > basicaly a first step that lead to holocaust.
> >
> >
>
> https://en.wikipedia.org/wiki/Kristallnacht#Kristallnacht_as_a_turning_point
>
> Note that the term "Kristallnacht" (or "Reichskristallnacht") is itself a
> nazi propaganda term, and it is nowadays generally agreed in Austria and
> Germany that that term should not be used. Broken glass is just broken
> glass, not "crystal". And the term only (euphemistically) mentions the
> violence against things and neglects to mention the violence against
> people.
>
> ... and that is why Miro mentioned all of that explicitly (and
diligently), and even pointed to a source for more information.

Historical events do not vanish by renaming them - and no single word can
describe the horror, be it "massacre" or "catastrophe" in the language of
your choice. We need to educate ourselves (and then others) about events
and names, and in fact that is what Miro's historical connotations can do,
even when they give us shivers.

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Change Proposal: Linker Error on Security Issues (System-Wide)

[Nick Clifton]

Hi Dominik,

> Does the `--no-warn-rwx-segments` disable erroring out on both loadable
> rwx segments and tls rwx segments?

Yes.

At the time I wrote the feature I did consider having separate options for the 
two tests, but it seemed like overkill, so I decided to go with just a single 
controlling option.

Cheers
  Nick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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