Re: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

[Siteshwar Vashisht]

On Wed, Apr 24, 2024 at 6:26 PM Siteshwar Vashisht 
wrote:

> Hello,
>
> This is a follow up on my previous email[1] about OpenScanHub Prototype
> for Fedora.
> Thank you to those who have provided early feedback. Your help is truly
> appreciated!
>
> I am writing this message to get feedback from the community on possibly
> new defects identified by static analyzers in Core Critical Path packages
> that have changed in Fedora 41.
>
> TLDR: This report[2] contains 14188 identified defects. Please review the
> report and provide feedback.
>
> A mass scan was performed this week on the packages that have changed in
> Fedora 41. This report[2] contains all the new defects that have been
> identified in the core packages listed in Critical Path Packages. Please
> review the report and fix or report any defects to upstream that may be
> real bugs. Not all defects reported by OpenScanHub may be actual bugs, so
> please verify reported defects before investing time into fixing or
> reporting them. We hope this is helpful for the packages you maintain and
> for the upstream projects. Questions can be asked on the OpenScanHub
> mailing list[3]. If you want to see the full logs of the scans, they are
> available on the tasks[4] page. User documentation for performing a scan is
> available on the Fedora wiki[5].
>
> If the feedback on this report is positive, there may be a possibility of
> increasing the scope of scans to cover a wider range of packages.
>

I plan to perform another mass scan this month. Please provide any
feedback, if you missed this message earlier.


>
> Please remember this is currently an early production stage for
> OpenScanHub scanning. Constructive feedback is appreciated. Thank you!
>
> [1]
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/
>
> [2] https://svashisht.fedorapeople.org/f41-22-Apr-2024/
>
> [3]
> https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/
>
> [4] https://openscanhub.fedoraproject.org/task/
>
> [5] https://fedoraproject.org/wiki/OpenScanHub
>
--
___
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: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

[Siteshwar Vashisht]

On Thu, Apr 25, 2024 at 2:18 AM Carlos Rodriguez-Fernandez <
carlosrodrifernan...@gmail.com> wrote:

> Actually, I see what the problem is.
>
> The task is for 2.69-8 [1], but the subtask runs for 2.69-3 first to
> then have a reference for the diff. So I guess it will work next time a
> new version of libcap goes out.
>

`koji latest-build f40 libcap` gives me: libcap-2.69-3.fc40

I used the mock profile from Fedora 41 to do the build, so probably that
caused the build failure.


>
> [1] https://openscanhub.fedoraproject.org/task/83/
>
> On 4/24/24 17:11, Carlos Rodriguez-Fernandez wrote:
> > Hi Siteshwar,
> >
> > Thank you for the report. The libcap subtask failed [1] for a known
> > issue, which is present in libcap 2.69-3 in Fedora rawhide, but was
> > already fixed two weeks ago. Fedora rawhide has 2.69-8, and I can
> > confirm it is the case when I run the fedora:41 images. 2.69-8 should
> > have been in the mirrors for more than one week. I'm surprised it wasn't
> > picked up when this report was run. Will the report be rerun eventually
> > with an updated version of Fedora 41?
> >
> > Thank you,
> > Carlos R.F.
> >
> > [1] https://openscanhub.fedoraproject.org/task/135/log/stdout.log
> >
> >
> > On 4/24/24 09:26, Siteshwar Vashisht wrote:
> >> Hello,
> >>
> >> This is a follow up on my previous email[1] about OpenScanHub
> >> Prototype for Fedora.
> >> Thank you to those who have provided early feedback. Your help is
> >> truly appreciated!
> >>
> >> I am writing this message to get feedback from the community on
> >> possibly new defects identified by static analyzers in Core Critical
> >> Path packages that have changed in Fedora 41.
> >>
> >> TLDR: This report[2] contains 14188 identified defects. Please review
> >> the report and provide feedback.
> >>
> >> A mass scan was performed this week on the packages that have changed
> >> in Fedora 41. This report[2] contains all the new defects that have
> >> been identified in the core packages listed in Critical Path Packages.
> >> Please review the report and fix or report any defects to upstream
> >> that may be real bugs. Not all defects reported by OpenScanHub may be
> >> actual bugs, so please verify reported defects before investing time
> >> into fixing or reporting them. We hope this is helpful for the
> >> packages you maintain and for the upstream projects. Questions can be
> >> asked on the OpenScanHub mailing list[3]. If you want to see the full
> >> logs of the scans, they are available on the tasks[4] page. User
> >> documentation for performing a scan is available on the Fedora wiki[5].
> >>
> >> If the feedback on this report is positive, there may be a possibility
> >> of increasing the scope of scans to cover a wider range of packages.
> >>
> >> Please remember this is currently an early production stage for
> >> OpenScanHub scanning. Constructive feedback is appreciated. Thank you!
> >>
> >> [1]
> >>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/
> <
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/
> >
> >>
> >> [2] https://svashisht.fedorapeople.org/f41-22-Apr-2024/
> >> <https://svashisht.fedorapeople.org/f41-22-Apr-2024/>
> >>
> >> [3]
> >>
> https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/
> <
> https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/
> >
> >>
> >> [4] https://openscanhub.fedoraproject.org/task/
> >> <https://openscanhub.fedoraproject.org/task/>
> >>
> >> [5] https://fedoraproject.org/wiki/OpenScanHub
> >> <https://fedoraproject.org/wiki/OpenScanHub>
> >>
> >> --
> >> ___
> >> 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/ne

Re: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

[Siteshwar Vashisht]

On Thu, Apr 25, 2024 at 2:12 AM Carlos Rodriguez-Fernandez <
carlosrodrifernan...@gmail.com> wrote:

> Hi Siteshwar,
>
> Thank you for the report. The libcap subtask failed [1] for a known
> issue, which is present in libcap 2.69-3 in Fedora rawhide, but was
> already fixed two weeks ago. Fedora rawhide has 2.69-8, and I can
> confirm it is the case when I run the fedora:41 images. 2.69-8 should
> have been in the mirrors for more than one week. I'm surprised it wasn't
> picked up when this report was run. Will the report be rerun eventually
> with an updated version of Fedora 41?
>

I plan to run the mass scans again based on the feedback from the
community. Although, I do not have a timeline for that. I would appreciate
any suggestions on when it fits in the Fedora release schedule to run a
mass scan.


>
> Thank you,
> Carlos R.F.
>
> [1] https://openscanhub.fedoraproject.org/task/135/log/stdout.log
>
>
> On 4/24/24 09:26, Siteshwar Vashisht wrote:
> > Hello,
> >
> > This is a follow up on my previous email[1] about OpenScanHub Prototype
> > for Fedora.
> > Thank you to those who have provided early feedback. Your help is truly
> > appreciated!
> >
> > I am writing this message to get feedback from the community on possibly
> > new defects identified by static analyzers in Core Critical Path
> > packages that have changed in Fedora 41.
> >
> > TLDR: This report[2] contains 14188 identified defects. Please review
> > the report and provide feedback.
> >
> > A mass scan was performed this week on the packages that have changed in
> > Fedora 41. This report[2] contains all the new defects that have been
> > identified in the core packages listed in Critical Path Packages. Please
> > review the report and fix or report any defects to upstream that may be
> > real bugs. Not all defects reported by OpenScanHub may be actual bugs,
> > so please verify reported defects before investing time into fixing or
> > reporting them. We hope this is helpful for the packages you maintain
> > and for the upstream projects. Questions can be asked on the OpenScanHub
> > mailing list[3]. If you want to see the full logs of the scans, they are
> > available on the tasks[4] page. User documentation for performing a scan
> > is available on the Fedora wiki[5].
> >
> > If the feedback on this report is positive, there may be a possibility
> > of increasing the scope of scans to cover a wider range of packages.
> >
> > Please remember this is currently an early production stage for
> > OpenScanHub scanning. Constructive feedback is appreciated. Thank you!
> >
> > [1]
> >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/
> <
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/
> >
> >
> > [2] https://svashisht.fedorapeople.org/f41-22-Apr-2024/
> > <https://svashisht.fedorapeople.org/f41-22-Apr-2024/>
> >
> > [3]
> >
> https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/
> <
> https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/
> >
> >
> > [4] https://openscanhub.fedoraproject.org/task/
> > <https://openscanhub.fedoraproject.org/task/>
> >
> > [5] https://fedoraproject.org/wiki/OpenScanHub
> > <https://fedoraproject.org/wiki/OpenScanHub>
> >
> > --
> > ___
> > 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
>
--
___
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

RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

[Siteshwar Vashisht]

Hello,

This is a follow up on my previous email[1] about OpenScanHub Prototype for
Fedora.
Thank you to those who have provided early feedback. Your help is truly
appreciated!

I am writing this message to get feedback from the community on possibly
new defects identified by static analyzers in Core Critical Path packages
that have changed in Fedora 41.

TLDR: This report[2] contains 14188 identified defects. Please review the
report and provide feedback.

A mass scan was performed this week on the packages that have changed in
Fedora 41. This report[2] contains all the new defects that have been
identified in the core packages listed in Critical Path Packages. Please
review the report and fix or report any defects to upstream that may be
real bugs. Not all defects reported by OpenScanHub may be actual bugs, so
please verify reported defects before investing time into fixing or
reporting them. We hope this is helpful for the packages you maintain and
for the upstream projects. Questions can be asked on the OpenScanHub
mailing list[3]. If you want to see the full logs of the scans, they are
available on the tasks[4] page. User documentation for performing a scan is
available on the Fedora wiki[5].

If the feedback on this report is positive, there may be a possibility of
increasing the scope of scans to cover a wider range of packages.

Please remember this is currently an early production stage for OpenScanHub
scanning. Constructive feedback is appreciated. Thank you!

[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/

[2] https://svashisht.fedorapeople.org/f41-22-Apr-2024/

[3]
https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/

[4] https://openscanhub.fedoraproject.org/task/

[5] https://fedoraproject.org/wiki/OpenScanHub
--
___
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: RFC: OpenScanHub Prototype for Fedora

[Siteshwar Vashisht]

On Tue, Dec 12, 2023 at 4:30 PM Siteshwar Vashisht 
wrote:

> Hello,
>
> I am writing this email to get feedback from the members of the Fedora
> development community about OpenScanHub for Fedora.
>
> # tl;dr
>
> OpenScanHub does static and dynamic analysis of rpm packages and it may be
> helpful in the Fedora community. Please take a look at our staging proof of
> concept[4] and provide feedback. The proof of concept is in its early
> stages so there may be some bugs here or there! If the feedback is positive
> we may roll this out in official infrastructure and integrate with Fedora
> CI and Packit.
>
> # What
>
> OpenScanHub is a service for static and dynamic analysis. It has been in
> development inside Red Hat[1] for more than 12 years and was open sourced
> on GitHub[2] earlier this year. You can read a brief explanation of this
> service on my blog[3]. We would like to deploy this service on the Fedora
> infrastructure and start scanning packages shipped in the Fedora project
> through it.
>
> # Why
>
> I am sharing a prototype[4] of this service to get feedback from the
> community. This prototype is running on the staging instance of the Fedora
> infrastructure, so you would have to login[5] to the staging instance
> before submitting any scan. If you have never logged into that account, it
> may require you to do a password reset.
>
I have received a couple of comments[1][2] from contributors inside and
outside Red Hat. There were several scans submitted by community members
that can be seen on the tasks[3] page. I may bring this prototype down at
some point next week. So if anyone interested in this idea missed this
email earlier, please try it before I bring the prototype down. Thank you!


> Once you are logged into the staging instance, you can login through the
> `krb5login` button[6] on the top right corner of the homepage and submit a
> scan through this form[7].
>
> There are 3 different types of scans supported by OpenScanHub:
>
>-
>
>MockBuild performs a full scan of the package including downstream
>patches. Example[8] mockbuild for `openssl-3.1.1-4.fc39`.
>-
>
>DiffBuild performs a differential scan on the downstream patches. So
>you can find only the defects that are introduced by the downstream
>patches. Example[9] diffbuild for `openssl-3.1.1-4.fc39`. This option would
>not work if the package fails to compile without patches.
>-
>
>VersionDiffBuild performs a differential scan between 2 different
>versions of the package, and you can see defects introduced by the “newer”
>version of the package. Example[10] differential build between
>`openssl-3.1.1-4.fc39` and `openssl-3.0.9-2.fc38`.
>
> All the submitted scans can be seen on the tasks[11] page.
>
> This prototype is running on very limited resources, so please do not
> submit scan for any resource consuming package. Not all defects reported by
> OpenScanHub may be actual bugs, so please avoid fixing reported defects
> without careful examination. If we receive positive feedback on this
> prototype, there may be a possibility of integrating this service with the
> Fedora CI and Packit projects.
>
> This is a very early stage prototype and may behave inconsistently. Please
> keep the discussion in this thread constructive. Thank you!
>
> [1] https://kdudka.fedorapeople.org/muni23.pdf
>
> [2] https://github.com/openscanhub/openscanhub
>
> [3] https://situ.im/posts/openscanhub
>
> [4] https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/
>
> [5] https://accounts.stg.fedoraproject.org
>
> [6]
> https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/auth/krb5login/
> <https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/auth/krb5login/?next=/>
>
> [7] https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/scan/new/
>
> [8]
> https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/task/6/log/openssl-3.1.1-4.fc39/scan-results.html
>
> [9]
> https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/task/9/log/openssl-3.1.1-4.fc39/scan-results.html
>
> [10]
> https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/task/7/log/added.html
> [11] https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/task/
>

[1] https://github.com/openscanhub/openscanhub/issues/211

[2] https://github.com/openscanhub/openscanhub/issues/214

[3] https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/task/
--
___
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

RFC: OpenScanHub Prototype for Fedora

[Siteshwar Vashisht]

Hello,

I am writing this email to get feedback from the members of the Fedora
development community about OpenScanHub for Fedora.

# tl;dr

OpenScanHub does static and dynamic analysis of rpm packages and it may be
helpful in the Fedora community. Please take a look at our staging proof of
concept[4] and provide feedback. The proof of concept is in its early
stages so there may be some bugs here or there! If the feedback is positive
we may roll this out in official infrastructure and integrate with Fedora
CI and Packit.

# What

OpenScanHub is a service for static and dynamic analysis. It has been in
development inside Red Hat[1] for more than 12 years and was open sourced
on GitHub[2] earlier this year. You can read a brief explanation of this
service on my blog[3]. We would like to deploy this service on the Fedora
infrastructure and start scanning packages shipped in the Fedora project
through it.

# Why

I am sharing a prototype[4] of this service to get feedback from the
community. This prototype is running on the staging instance of the Fedora
infrastructure, so you would have to login[5] to the staging instance
before submitting any scan. If you have never logged into that account, it
may require you to do a password reset.

Once you are logged into the staging instance, you can login through the
`krb5login` button[6] on the top right corner of the homepage and submit a
scan through this form[7].

There are 3 different types of scans supported by OpenScanHub:

   -

   MockBuild performs a full scan of the package including downstream
   patches. Example[8] mockbuild for `openssl-3.1.1-4.fc39`.
   -

   DiffBuild performs a differential scan on the downstream patches. So you
   can find only the defects that are introduced by the downstream patches.
   Example[9] diffbuild for `openssl-3.1.1-4.fc39`. This option would not work
   if the package fails to compile without patches.
   -

   VersionDiffBuild performs a differential scan between 2 different
   versions of the package, and you can see defects introduced by the “newer”
   version of the package. Example[10] differential build between
   `openssl-3.1.1-4.fc39` and `openssl-3.0.9-2.fc38`.

All the submitted scans can be seen on the tasks[11] page.

This prototype is running on very limited resources, so please do not
submit scan for any resource consuming package. Not all defects reported by
OpenScanHub may be actual bugs, so please avoid fixing reported defects
without careful examination. If we receive positive feedback on this
prototype, there may be a possibility of integrating this service with the
Fedora CI and Packit projects.

This is a very early stage prototype and may behave inconsistently. Please
keep the discussion in this thread constructive. Thank you!

[1] https://kdudka.fedorapeople.org/muni23.pdf

[2] https://github.com/openscanhub/openscanhub

[3] https://situ.im/posts/openscanhub

[4] https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/

[5] https://accounts.stg.fedoraproject.org

[6]
https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/auth/krb5login/


[7] https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/scan/new/

[8]
https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/task/6/log/openssl-3.1.1-4.fc39/scan-results.html

[9]
https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/task/9/log/openssl-3.1.1-4.fc39/scan-results.html

[10]
https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/task/7/log/added.html
[11] https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/task/
--
___
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: F30 Self-Contained Change proposal: Bash 5.0

[Siteshwar Vashisht]

- Original Message -
> From: "Adam Williamson" 
> To: "Development discussions related to Fedora" 
> , "Neal Gompa" 
> Cc: "Stef Walter" , svashi...@redhat.com
> Sent: Wednesday, January 30, 2019 10:32:32 AM
> Subject: Re: F30 Self-Contained Change proposal: Bash 5.0
> 
> So for the record, I looked into this a bit further, and in fact it has
> already been done. There are tests in bash dist-git:
> 
> https://src.fedoraproject.org/rpms/bash/blob/master/f/tests
> 
> and they are actually being run by the pipeline:
> 
> https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-f29-build-pipeline/detail/fedora-f29-build-pipeline/282/pipeline
> 
> and the results show up in Bodhi (albeit under the heading
> 'undefined', which is a bug we should fix):
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-9d006f6254 (see
> Automated Tests tab)
> 
> which means Greenwave knows about them, because Bodhi now uses
> Greenwave as its source of result data (so anything that shows up in
> Bodhi is definitely in Greenwave).
> 
> I don't know if the tests that have been imported into dist-git are
> *all* of RH's internal tests - Sitesh might know. But certainly some or
> all of them have been upstreamed, and are properly set up such that
> they will run on any builds done in Fedora and will be available for
> the Rawhide gating stuff once that's fully implemented.

Currently there are just 3 tests that have been upstreamed from our internal 
repos[1].

I wanted to get all of them upstreamed in fedora, but it can't be done due to 
other priorities.


> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

[1] https://src.fedoraproject.org/tests/shell/tree/master

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

Re: [Late] F30 System-Wide Change proposal: GCC9

[Siteshwar Vashisht]

- Original Message -
> From: "Jakub Jelinek" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, January 21, 2019 10:51:32 PM
> Subject: Re: [Late] F30 System-Wide Change proposal: GCC9
> 
> The release notes are WIP, more will come when it is written, many new
> features
> are just not described there yet.

One of my packages broke because gcc now prints line numbers with error 
messages. Just in case anyone else is facing similar issue.

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

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

Re: F30 Self-Contained Change proposal: Bash 5.0

[Siteshwar Vashisht]

- Original Message -
> From: "Adam Williamson" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, January 28, 2019 11:38:58 PM
> Subject: Re: F30 Self-Contained Change proposal: Bash 5.0
> 
> It's not the "only" issue, because it was submitted over two weeks
> *after* the deadline for system-wide changes.
> 
> I am somewhat concerned about dropping in a major new bash version
> quite late in the cycle and just before the mass rebuild, particularly
> when there are bits like this in the announcement:
> 
> "There are a number of changes to the
> expansion of $@ and $* in various contexts where word splitting is not
> performed to conform to a Posix standard interpretation, and additional
> changes to resolve corner cases for Posix conformance." (are you *sure*
> all our corner cases are expecting Posix-conformant behaviour? I'm not)
> 
> "The `globasciiranges' shell option
> is now enabled by default; it can be set to off by default at
> configuration time." (OK, so we can turn it off again if necessary, but
> still, could be interesting)
> 
> "There are a few incompatible changes between bash-4.4 and bash-5.0"
> (sure, these are in 'rarely used' things, but we have an awful *lot* of
> shell scripts in us. We're a Linux distribution, it comes with the
> territory. I'm pretty sure we use those 'rarely used' thing at least
> somewhere)
> 
> that *plus* the required readline version bump *plus* the suggestion
> that some significant bugs were already discovered in the .0 release
> makes me a little hesitant about this. I'm not saying "no!", but...it
> certainly strikes me as a potentially disruptive change that needs some
> kind of justification to go in late beyond "NEW SHINY".

I agree that it would be much safer to target it for Fedora 31. I have no 
objection if we change target release.

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

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

Re: F30 Self-Contained Change proposal: Bash 5.0

[Siteshwar Vashisht]

- Original Message -
> From: "Neal Gompa" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Stef Walter" 
> Sent: Monday, January 28, 2019 4:28:15 AM
> Subject: Re: F30 Self-Contained Change proposal: Bash 5.0
> 
> Have you run these tests on bash 5.0 rebase yet? Also, would it be
> possible to get this into Fedora Dist-Git so that the checks could be
> run as part of any build/update/PR to the package?

I have not managed to do the rebase yet. Ideally these tests should be put in 
Fedora dist-git by our QE people, but it's really upto them how they handle it.

> 
> 
> 
> --
> 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

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

Re: F30 Self-Contained Change proposal: Bash 5.0

[Siteshwar Vashisht]

- Original Message -
> From: "Neal Gompa" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Mikolaj Izdebski" , "Michael Simacek" 
> 
> Sent: Monday, January 28, 2019 3:52:32 AM
> Subject: Re: F30 Self-Contained Change proposal: Bash 5.0
> 
> Is there some way we can (ab)use Koschei to see how things would look
> for bash 5.0 in Rawhide? Personally, I really don't think we'd have as
> many problems as people fear, but if there's a way we could do
> something interesting to prove it, that'd be great too.

During bash-4.4 rebase, I ran all Red Hat internal tests on it to verify 
nothing would break. I would check about the option to test with Koschei too.

> 
> 
> 
> --
> 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

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

Re: F30 Self-Contained Change proposal: Bash 5.0

[Siteshwar Vashisht]

- Original Message -
> From: "Frantisek Zatloukal" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, January 25, 2019 4:16:45 PM
> Subject: Re: F30 Self-Contained Change proposal: Bash 5.0
> 
> Why is this Self-Contained Change and not a System Wide Change?
> 
> It seems, at least to me, that it should be System Wide Change, according to
> https://fedoraproject.org/wiki/Changes/Policy#Complex_system_wide_changes .

Although it's a major version, upstream is not intending to break any existing 
scripts. That's why I kept it as a self-contained change.

> 
> 
> 
> --
> 
> Best regards / S pozdravem,
> 
> František Zatloukal
> Quality Engineer
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

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

Re: F30 Self-Contained Change proposal: Bash 5.0

[Siteshwar Vashisht]

- Original Message -
> From: "Nico Kadel-Garcia" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Saturday, January 26, 2019 11:06:39 PM
> Subject: Re: F30 Self-Contained Change proposal: Bash 5.0
> 
> It's also only been released for barely 2 weeks, it's marked as a
> major revision number, and it seems a bit late to accept for Fedora
> 30. Mark it as a candidate for Fedora 31, and move on?

I am fine with doing that. But we are missing a chance to get some early 
testing on the latest release.

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

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

Re: [HEADS UP] Rebasing to Readline-8.0 in rawhide

[Siteshwar Vashisht]

- Original Message -
> From: "Jason L Tibbitts III" 
> To: "Siteshwar Vashisht" 
> Cc: "Development discussions related to Fedora" 
> 
> Sent: Thursday, January 24, 2019 6:54:59 PM
> Subject: Re: [HEADS UP] Rebasing to Readline-8.0 in rawhide
> 
> SV> Readline-8.0 was released earlier this month[1]. I am going to
> SV> rebase it in rawhide in couple of weeks.
> 
> Note that a couple of things break in weird ways every time readline gets a
> new
> major version.  For me that's the command line editing functionality of
> the kerberos tools like kadmin.  The root cause of this is something
> called "libss" which is part of e2fsprogs (!).  It tries to abstract
> readline functionality and has a hardcoded list of libraries that it
> looks for:
> 
> get_readline.c:#define DEFAULT_LIBPATH
> "libreadline.so.7:libreadline.so.6:libreadline.so.5:libreadline.so.4:libreadline.so:libedit.so.2:libedit.so:libeditline.so.0:libeditline.so"
> 
> Could you work with the e2fsprogs maintainer to make sure that libss
> continues to work as expected?

I would do that. I will also provide a compatibility package for readline 7.


> 
> Thanks,
> 
>  - J<
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

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

[HEADS UP] Rebasing to Readline-8.0 in rawhide

[Siteshwar Vashisht]

Readline-8.0 was released earlier this month[1]. I am going to rebase it in 
rawhide in couple of weeks.

[1] http://lists.gnu.org/archive/html/bug-bash/2019-01/msg00064.html

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

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Siteshwar Vashisht]

- Original Message -
> From: "Sorin Sbarnea" 
> To: "Miro Hrončok" 
> Cc: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, May 29, 2018 11:19:02 AM
> Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
> 
> I ended up creating
> https://fedoraproject.org/wiki/Changes/UserPathPrioritization and I invite
> others to improve its description.

This change was approved by FESCo, so I have merged related pull request[1].

> 
> --
> /sorin
> 
> On Tue, May 29, 2018 at 9:25 AM, Miro Hrončok < mhron...@redhat.com > wrote:
> 
> 
> 
> 
> On 29.5.2018 09:34, Sorin Sbarnea wrote:
> 
> 
> What do we need to do to make Fedora do the right thing (add it to the top of
> the list), just like Debian/Ubuntu. I am sure that they had similar
> discussions and in the end they decided to do the right thing.
> 
> A Fedora change proposal.
> 
> https://fedoraproject.org/wiki/Changes/Policy
> 
> --
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VB2E4CRXYFXXISRWK2YXPVSTM4OWSAJO/
> 

[1] https://src.fedoraproject.org/rpms/bash/pull-request/7
-- 
--
Siteshwar Vashisht
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3H33AHT4WH3QENFFEDOVPXL7IAINM7DI/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Siteshwar Vashisht]

- Original Message -
> From: "Lennart Poettering" <mzerq...@0pointer.de>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Cc: "Miro Hrončok" <mhron...@redhat.com>
> Sent: Wednesday, May 2, 2018 4:28:35 PM
> Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
> 
> So this came up again recently here:
> 
> https://lists.freedesktop.org/archives/xdg/2017-August/013938.html
> 
> (see the full thread)
> 
> And I even promised to merge the proposed spec addition there, but
> never actually did that. Maybe I really should now...

Is it going to specify ordering of the paths too ? It would be good to have 
some standard in ordering or at least some recommendation around it, so that 
all distributions behave same.

> 
> Lennart
> 
> --
> Lennart Poettering, Red Hat
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

-- 
--
Siteshwar Vashisht
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Siteshwar Vashisht]

- Original Message -
> From: "Daniel P. Berrangé" <berra...@redhat.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Cc: "Kamil Dudka" <kdu...@redhat.com>
> Sent: Wednesday, May 2, 2018 4:49:18 PM
> Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
> 
> On Wed, May 02, 2018 at 10:35:28AM -0400, Siteshwar Vashisht wrote:
> > 
> > 
> > - Original Message -
> > > From: "Tomas Orsava" <tors...@redhat.com>
> > > To: "Development discussions related to Fedora"
> > > <devel@lists.fedoraproject.org>, "David Kaspar" <dkas...@redhat.com>,
> > > "Kamil Dudka" <kdu...@redhat.com>, "Miro Hrončok" <mhron...@redhat.com>,
> > > "Petr Viktorin" <pvikt...@redhat.com>,
> > > "Siteshwar Vashisht" <svash...@redhat.com>
> > > Sent: Wednesday, May 2, 2018 3:23:10 PM
> > > Subject: Prioritizing ~/.local/bin over /usr/bin on the PATH
> > > 
> > > Hi!
> > > I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
> > > the PATH.
> > > 
> > > Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
> > > where the old system-installed executable written in Python (from
> > > /usr/bin) is launched, but it finds new Python sources (installed into
> > > $HOME) which it doesn't work with and crashes.
> > > 
> > > [bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
> > > 
> > > I believe the current configuration breaks the intuitive expectation
> > > that things installed closer to the user should take priority. That's
> > > for example how it works with Python.
> > > Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
> > > PATH (though Ubuntu has ~/bin) so we can't take guidance there.
> > > 
> > > Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
> > 
> > Most of the discussion in this thread focuses on security rather than
> > sane behavior. It is going to be a system wide change. An application
> > may get affected if it depends on system provided utilites which gets
> > overridden by ~/.local/bin.
> 
> [snip]
> 
> > So this change breaks something that is outside user's installation.
> > This should happen only if a user has explicitly overriden $PATH to
> > prioritize user installation paths.
> 
> Not prioritizing user paths by default will break other things though.
> For example, python pip installations done with --user.

Things may break both ways, whether you choose to prioritize user installation 
paths or not. I will prefer if they break when user installation paths are not 
prioritized.

> 
> eg.  if jenkins-job-builder is installed by RPM and the user decides to
> add a local override, the  "pip install --user jenkins-job-builder"  will
> place the new python libs + binary in $HOME/.local/{bin,lib} and will
> just work because those dirs are both searched first.
> 
> If, however, python searches $HOME/.local/lib/... first, but $PATH has
> /usr/bin first, you are going to end up with the /usr/bin/jenkins-jobs
> command from RPM using the python modules from the pip install we just
> did. This mis-match will end badly for the user.
> 
> 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
> 

-- 
--
Siteshwar Vashisht
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Siteshwar Vashisht]

- Original Message -
> From: "Vít Ondruch" <vondr...@redhat.com>
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, May 2, 2018 4:46:12 PM
> Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
> 
> 
> 
> Dne 2.5.2018 v 16:35 Siteshwar Vashisht napsal(a):
> >
> > - Original Message -
> >> From: "Tomas Orsava" <tors...@redhat.com>
> >> To: "Development discussions related to Fedora"
> >> <devel@lists.fedoraproject.org>, "David Kaspar" <dkas...@redhat.com>,
> >> "Kamil Dudka" <kdu...@redhat.com>, "Miro Hrončok" <mhron...@redhat.com>,
> >> "Petr Viktorin" <pvikt...@redhat.com>,
> >> "Siteshwar Vashisht" <svash...@redhat.com>
> >> Sent: Wednesday, May 2, 2018 3:23:10 PM
> >> Subject: Prioritizing ~/.local/bin over /usr/bin on the PATH
> >>
> >> Hi!
> >> I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
> >> the PATH.
> >>
> >> Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
> >> where the old system-installed executable written in Python (from
> >> /usr/bin) is launched, but it finds new Python sources (installed into
> >> $HOME) which it doesn't work with and crashes.
> >>
> >> [bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
> >>
> >> I believe the current configuration breaks the intuitive expectation
> >> that things installed closer to the user should take priority. That's
> >> for example how it works with Python.
> >> Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
> >> PATH (though Ubuntu has ~/bin) so we can't take guidance there.
> >>
> >> Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
> > Most of the discussion in this thread focuses on security rather than sane
> > behavior. It is going to be a system wide change. An application may get
> > affected if it depends on system provided utilites which gets overridden
> > by ~/.local/bin.
> >
> > For e.g.
> >
> >> cat /bin/foo
> > #!/bin/bash
> > ls -l
> >> cat ~/.local/bin/ls
> > #!/bin/bash
> > echo "Strange world!"
> >> /bin/foo
> > Strange world!
> >
> > So this change breaks something that is outside user's installation. This
> > should happen only if a user has explicitly overriden $PATH to prioritize
> > user installation paths.
> 
> User explicitly installed SW into his home directory. Why (s)he needs to
> override the $PATH in addition to make the SW work?

Users should be aware too that there are 2 different versions of the same 
utility on their system. And they should be explicit about not using system 
provided one.

> 
> Vít
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

-- 
--
Siteshwar Vashisht
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Siteshwar Vashisht]

- Original Message -
> From: "Tomas Orsava" <tors...@redhat.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>, "David Kaspar" <dkas...@redhat.com>,
> "Kamil Dudka" <kdu...@redhat.com>, "Miro Hrončok" <mhron...@redhat.com>, 
> "Petr Viktorin" <pvikt...@redhat.com>,
> "Siteshwar Vashisht" <svash...@redhat.com>
> Sent: Wednesday, May 2, 2018 3:23:10 PM
> Subject: Prioritizing ~/.local/bin over /usr/bin on the PATH
> 
> Hi!
> I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
> the PATH.
> 
> Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
> where the old system-installed executable written in Python (from
> /usr/bin) is launched, but it finds new Python sources (installed into
> $HOME) which it doesn't work with and crashes.
> 
> [bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
> 
> I believe the current configuration breaks the intuitive expectation
> that things installed closer to the user should take priority. That's
> for example how it works with Python.
> Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
> PATH (though Ubuntu has ~/bin) so we can't take guidance there.
> 
> Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?

Most of the discussion in this thread focuses on security rather than sane 
behavior. It is going to be a system wide change. An application may get 
affected if it depends on system provided utilites which gets overridden by 
~/.local/bin.

For e.g.

> cat /bin/foo
#!/bin/bash
ls -l
> cat ~/.local/bin/ls 
#!/bin/bash
echo "Strange world!"
> /bin/foo
Strange world!

So this change breaks something that is outside user's installation. This 
should happen only if a user has explicitly overriden $PATH to prioritize user 
installation paths.

> 
> Regards,
> Tomas
> 
> 

-- 
--
Siteshwar Vashisht
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Siteshwar Vashisht]

- Original Message -
> From: "Miro Hrončok" <mhron...@redhat.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>, "Panu Matilainen"
> <pmati...@redhat.com>
> Sent: Wednesday, May 2, 2018 3:45:55 PM
> Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
> 
> On 2.5.2018 15:39, Panu Matilainen wrote> Not quite what you're asking,
> but actually not having a hidden directory
> > as a part of default PATH in the first place seems like a rather good
> > idea to me...
> 
> It's already there. And it is XDG complaint. The question here is about
> order (what takes priority).

Can you point me to the XDG specification that requires it ? It was mentioned 
by Lenart on the bug, but he later clarified his comment[1].

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

[1] https://lists.fedoraproject.org/pipermail/devel/2011-July/154902.html

-- 
--
Siteshwar Vashisht
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Always sourcing /etc/bashrc for interactive mode in bash

[Siteshwar Vashisht]

- Original Message -
> From: "Siteshwar Vashisht" <svashi...@redhat.com>
> To: devel@lists.fedoraproject.org
> Sent: Tuesday, May 2, 2017 3:42:14 PM
> Subject: RFC: Always sourcing /etc/bashrc for interactive mode in bash
> 
> We are discussing about always sourcing /etc/bashrc for interactive mode in
> bug 1193590 [1]. Currently /etc/bashrc is sourced by user's bashrc script
> and if a user forgets to source it, some of the default configurations will
> not be set (for e.g. see bug 1390780 [2]). I am pondering over the idea to
> source /etc/bashrc by default (see commmit at [3]) and fix current
> /etc/bashrc script to avoid double sourcing [4]. This change may cause
> undesirable effects if a custom /etc/bashrc is prone to double sourcing and
> might break some systems. Any comments about this change are welcome.

This breaks some use cases as it modifies order of sourcing of /etc/bashrc 
file. Due to this change /etc/bashrc gets sourced before user's ~/.bashrc and 
there is no way to set configurations before /etc/bashrc is sourced (See 
comment here[1]). It looks like making this work will possibly require 
significant refactoring of startup scripts in fedora (that might cause some 
compatbility issues). The scripts under /etc/profile.d are sourced by 
/etc/profile for login shells and by /etc/bashrc for non-login shells. 
Refactoring the startup scripts will lead to a more cleaner solution, however 
it may also break existing setups.

> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1193590
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1390780
> [3]
> https://github.com/fedora-testing/bash/commit/87ac935a6643a9afee44a9575771418d7be15fcb
> [4] https://bugzilla.redhat.com/show_bug.cgi?id=1193590#c20
> 
> --
> --
> Siteshwar Vashisht
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1193590#c40

-- 
--
Siteshwar Vashisht
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

RFC: Always sourcing /etc/bashrc for interactive mode in bash

[Siteshwar Vashisht]

We are discussing about always sourcing /etc/bashrc for interactive mode in bug 
1193590 [1]. Currently /etc/bashrc is sourced by user's bashrc script and if a 
user forgets to source it, some of the default configurations will not be set 
(for e.g. see bug 1390780 [2]). I am pondering over the idea to source 
/etc/bashrc by default (see commmit at [3]) and fix current /etc/bashrc script 
to avoid double sourcing [4]. This change may cause undesirable effects if a 
custom /etc/bashrc is prone to double sourcing and might break some systems. 
Any comments about this change are welcome.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1193590
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1390780
[3] 
https://github.com/fedora-testing/bash/commit/87ac935a6643a9afee44a9575771418d7be15fcb
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1193590#c20

-- 
--
Siteshwar Vashisht
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

HEADS UP: Rebasing to Readline-7.0 in rawhide

[Siteshwar Vashisht]

 to 'unsigned long int 
rl_readline_state' at readline.h:500:1:
size of symbol (in bytes) changed from 4 to 8
type of variable changed:
 type name changed from 'int' to 'unsigned long int'
 type size changed from 32 to 64 bits




I would be happy to help if any package maintainers need my help with updating 
to readline-7.0.

[1] 
https://src.fedoraproject.org/cgit/rpms/gdb.git/commit/?id=194c0860de7383cb82bbc6d28c64ba07bb5bea72

-- 
--
Siteshwar Vashisht
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org