date:20221005

Re: libharu soname bump in rawhide [part II]

2022-10-05 Thread Dmitrij S. Kryzhevich

If you need help with updating please note me.

--
Dmitrij S. Kryzhevich
___
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

libharu soname bump in rawhide [part II]

2022-10-05 Thread Dmitrij S. Kryzhevich

libharu is going to be updated with soname bump in the near future. This is a 
second attempt [1].
There is an ABI change AND API change: HPDF_Page_SetDash() and 
HPDF_Page_Create3DAnnot().

Syntax change.
1. HPDF_Page_Create3DAnnot()
was: HPDF_Page page, HPDF_Rect rect, HPDF_U3D u3d
new: HPDF_Page page, HPDF_Rect rect, HPDF_BOOL tb, HPDF_BOOL np, HPDF_U3D u3d, 
HPDF_Image ap
where:
tb - enable visibility of ToolBar
np - enable visibility of Navigation Panel
ap - not described, referenced to pointer where 'appearance' should be 
stored, but could be NULL so internal 'HPDF_Dict stream' will be used instead.

2. HPDF_Page_SetDash()
was: HPDF_Page page, const HPDF_UINT16 *dash_ptn, HPDF_UINT num_param, 
HPDF_UINT phase
new: HPDF_Page page, const   HPDF_REAL *dash_ptn, HPDF_UINT num_param, 
HPDF_REAL phase
so it's 'dash_ptn' and 'phase'
gcc will throw error with signed-unsigned convertion if not fixed. Error could 
be disabled with corresponding flag (but obviously should not).

Also hpdf.h does not include hpdf_version.h now. There is an issue opened in 
libharu apstream [2] which may be resolved.

Affected packages:
vtk
saga
mathgl
EMBOSS
plplot
perl-PDF-Haru
blender

Looks like blender and EMBOSS does not use those API and could be just rebuilt. 
Others rely on it.

I haven't permissions of proven packager so can't rebuild them (except mathgl 
where I'm comaintainer).

--
Dmitrij S. Kryzhevich

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZV4NIK4TRWYM666B46YHQ2HAMJ6RDS27/
[2] https://github.com/libharu/libharu/issues/246
___
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: DNF5 Blockers

2022-10-05 Thread Tommy Nguyen



On Wed, 2022-10-05 at 22:10 -0500, Maxwell G via devel wrote:
> On Wed Oct 5, 2022, Maxwell G via devel wrote:
> > Hi Fedorians,
> > 
> > I think we should define a more through list of blockers/criteria
> > that
> > dnf5 needs to meet before it can replace the current dnf.
> > 
> > The DNF maintainers have their list of requirements, but it would
> > be
> > helpful for the wider community to test dnf5 and report which
> > currently
> > unimplemented features/usecases would block them from adopting it.
> > Hopefully, the more popular, for lack of a better word, blockers
> > can be
> > incorporated into the Change Proposal or otherwise required by
> > FESCo as
> > a prerequisite for this change. This should help the DNF
> > maintainers
> > prioritize, keep everyone on the same page, and ensure that dnf5
> > doesn't
> > prematurely become the default.
> 
> Some of mine:
> 
> - `dnf repoquery` -- Currently, `dnf5 repoquery` nowhere near meets
> the
>   capabilities of the old version. This is the most important to me.
> - `dnf config-manager`
> - `dnf copr`
> - `dnf system-upgrade`
> - `dnf needs-restarting` - nice to have
> - Documentation for the Python API. Currently, the C++ library is
>   documented, but the Python bindings are not. I saw someone else ask
> for
>   this, and now I'm adding it to my blockers :). The current Python
> API
>   documentation is great, so I wouldn't want to lose that.
> - A fully populated manpage. dnf5's manpage is nearly empty
>   right now.
> 
> Compatibility:
> - The `dnf update` alias is missing
> - `--refresh` is missing
> - The old dnf has some zypper style aliases (e.g. in for install,
>   dsync for distro-sync). I don't use them, but I noticed they were
>   missing.
> - I'm not sure what will happen with the old yum-utils aliases (e.g.
>   /usr/bin/repoquery). I always use `dnf repoquery`, but I'd reckon
> that
>   many others use the alias.
> 
> 
> --
> Best,
> 
> Maxwell G (@gotmax23)
> Pronouns: He/Him/His
> ___
> 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

This is not a blocker but a "nice to have". dnf5 doesn't seem to
currently report unimplemented commands, you just infer it from it
doing nothing.

- `dnf5 search` is not implemented
- plugins like tracer, snapper, etc. these are not mandatory, but would
break my workflow
- better documentation than dnf4
- failover priority in repo files

So far the help/usage is good. This is more of a "when it's
implemented" type of thing. The help/usage for dnf4 is god awful and
hard to interpret. The man page is better, but not much. I suspect that
the documentation was written more for developers than end users.

Better machine readable output for scriptability. Maybe my dnf4 foo is
not good enough, but much of the command output is not machine readable
without using grep/sed etc. 


signature.asc
Description: This is a digitally signed message part
___
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: DNF5 Blockers

2022-10-05 Thread Maxwell G via devel

On Wed Oct 5, 2022, Maxwell G via devel wrote:
> Hi Fedorians,
>
> I think we should define a more through list of blockers/criteria that
> dnf5 needs to meet before it can replace the current dnf.
>
> The DNF maintainers have their list of requirements, but it would be
> helpful for the wider community to test dnf5 and report which currently
> unimplemented features/usecases would block them from adopting it.
> Hopefully, the more popular, for lack of a better word, blockers can be
> incorporated into the Change Proposal or otherwise required by FESCo as
> a prerequisite for this change. This should help the DNF maintainers
> prioritize, keep everyone on the same page, and ensure that dnf5 doesn't
> prematurely become the default.

Some of mine:

- `dnf repoquery` -- Currently, `dnf5 repoquery` nowhere near meets the
  capabilities of the old version. This is the most important to me.
- `dnf config-manager`
- `dnf copr`
- `dnf system-upgrade`
- `dnf needs-restarting` - nice to have
- Documentation for the Python API. Currently, the C++ library is
  documented, but the Python bindings are not. I saw someone else ask for
  this, and now I'm adding it to my blockers :). The current Python API
  documentation is great, so I wouldn't want to lose that.
- A fully populated manpage. dnf5's manpage is nearly empty
  right now.

Compatibility:
- The `dnf update` alias is missing
- `--refresh` is missing
- The old dnf has some zypper style aliases (e.g. in for install,
  dsync for distro-sync). I don't use them, but I noticed they were
  missing.
- I'm not sure what will happen with the old yum-utils aliases (e.g.
  /usr/bin/repoquery). I always use `dnf repoquery`, but I'd reckon that
  many others use the alias.


--
Best,

Maxwell G (@gotmax23)
Pronouns: He/Him/His


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

DNF5 Blockers

2022-10-05 Thread Maxwell G via devel

Hi Fedorians,

I think we should define a more through list of blockers/criteria that
dnf5 needs to meet before it can replace the current dnf.

The DNF maintainers have their list of requirements, but it would be
helpful for the wider community to test dnf5 and report which currently
unimplemented features/usecases would block them from adopting it.
Hopefully, the more popular, for lack of a better word, blockers can be
incorporated into the Change Proposal or otherwise required by FESCo as
a prerequisite for this change. This should help the DNF maintainers
prioritize, keep everyone on the same page, and ensure that dnf5 doesn't
prematurely become the default.

--
Best,

Maxwell G (@gotmax23)
Pronouns: He/Him/His


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: SRPM macros, EPEL, and side tags

2022-10-05 Thread Maxwell G via devel

On Thu Oct 6, 2022 at 1:35 AM +0200, Miro Hrončok wrote:
> On 05. 10. 22 23:24, Kevin Fenzi wrote:
> > On Wed, Oct 05, 2022 at 08:40:12PM -, Artur Frenszek-Iwicki wrote:
> >> Hi all,
> >>
> >> some time ago I've built the Free Pascal Compiler [0] for EPEL9,
> >> and recently I got the idea it might be good to do the same with
> >> the Lazarus IDE [1]. Testing things locally with mock,
> >> I realized that Lazarus used a macro from fpc-srpm-macros [2],
> >> which hasn't been built for EPEL9 yet.
> >>
> >> No biggie, I thought. I created a side tag, built fpc-srpm-macros there,
> >> then added "BuildRequires: fpc-srpm-macros" to the Lazarus spec
> >> and tried building it in the side tag. The build failed, and looking at
> >> root.log, the fpc-srpm-macros package was not installed [3].
> > 
> > srpm's are built in a different buildroot koji has defined as
> > 'srpm-build'.
> > 
> > You can see whats in this with a 'koji list-groups epel9-build'
> > 
> > So yeah, you need something to pull in that fpc-srpm-macros,
> > (likely epel-release) or have it added to the srpm-build group.
>
> I believe more appropriate package is epel-rpm-macros.
>
> $ repoquery --repo=epel9 --requires epel-rpm-macros
> (pyproject-rpm-macros if python3-rpm-macros)
> ansible-srpm-macros
> go-srpm-macros-epel
> redhat-release >= 9

Yup, this is my understanding as well. In Fedora, *-srpm-macros packages
are pulled in by adding having redhat-rpm-config depend on them. Macro
packages that we want in EPEL that aren't in RHEL are usually added as
dependencies of epel-rpm-macros.


--
Maxwell G (@gotmax23)
Pronouns: He/Him/His


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: libharu soname bump for rawhide

2022-10-05 Thread Dmitrij S. Kryzhevich

Oh. Found error in my repoquery. Thank you.

On Wed, 5 Oct 2022 22:11:31 +0900
Mamoru TASAKA  wrote:

> Dmitrij S. Kryzhevich wrote on 2022/10/05 18:02:
> > I understand the necessity of time to react, may be should handle it in a 
> > more proper way.
> > I was triggered by maintainer of only dependent package (directly 
> > dependent) so I strongly believe it's OK in this case.
> 
> Seems not actually:
> 
> dnf repoquery --repo=koji-38  --qf '%{sourcerpm}' --whatrequires 
> "libhpdf.so.2.3*" | cat -n
>   1   EMBOSS-6.6.0-22.fc38.src.rpm
>   2   blender-3.3.0-4.fc38.src.rpm
>   3   mathgl-2.4.4-18.fc38.src.rpm
>   4   perl-PDF-Haru-1.00-38.fc37.src.rpm
>   5   plplot-5.15.0-45.fc38.src.rpm
>   6   saga-7.6.1-16.fc38.src.rpm
>   7   vtk-9.1.0-17.fc37.src.rpm
> 
> Perhaps I am going to request untag for libharu-2.4.2-1.fc38.
> 
> Regards,
> Mamoru
> 
> 
> > 
> > On Wed, 5 Oct 2022 10:51:20 +0200
> > Fabio Valentini  wrote:
> > 
> >> On Wed, Oct 5, 2022 at 9:24 AM Dmitrij S. Kryzhevich  
> >> wrote:
> >>>
> >>> New version of libharu is building for rawhide with coresponding soname 
> >>> bump.
> >>> Only vtk should be affected right now.
> >>
> >> I see that you have already built libharu-2.4.2-1.fc38.
> >>
> >> Did you also handle rebuilding dependent packages, or should their
> >> maintainers handle that themselves?
> >> Usually there should be one week between such heads-up emails and
> >> pushing the actual build, especially when you don't rebuild dependent
> >> packages.
> >>
> >> 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
> > ___
> > 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

Re: SRPM macros, EPEL, and side tags

2022-10-05 Thread Miro Hrončok


On 05. 10. 22 23:24, Kevin Fenzi wrote:

On Wed, Oct 05, 2022 at 08:40:12PM -, Artur Frenszek-Iwicki wrote:

Hi all,

some time ago I've built the Free Pascal Compiler [0] for EPEL9,
and recently I got the idea it might be good to do the same with
the Lazarus IDE [1]. Testing things locally with mock,
I realized that Lazarus used a macro from fpc-srpm-macros [2],
which hasn't been built for EPEL9 yet.

No biggie, I thought. I created a side tag, built fpc-srpm-macros there,
then added "BuildRequires: fpc-srpm-macros" to the Lazarus spec
and tried building it in the side tag. The build failed, and looking at
root.log, the fpc-srpm-macros package was not installed [3].


srpm's are built in a different buildroot koji has defined as
'srpm-build'.

You can see whats in this with a 'koji list-groups epel9-build'

So yeah, you need something to pull in that fpc-srpm-macros,
(likely epel-release) or have it added to the srpm-build group.


I believe more appropriate package is epel-rpm-macros.

$ repoquery --repo=epel9 --requires epel-rpm-macros
(pyproject-rpm-macros if python3-rpm-macros)
ansible-srpm-macros
go-srpm-macros-epel
redhat-release >= 9

--
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: When is a file dependency appropriate?

2022-10-05 Thread Miro Hrončok


On 06. 10. 22 1:21, Otto Liljalaakso wrote:
Recently, I have run into some cases where file dependencies like Requires: 
/usr/bin/foo are used.


In a recent thread on this mailing list [1],
it is mentioned that such Requires should be avoided,
because resolving file dependencies requires a large amount of memory.


I don't believe that resolving file-Requires from directories listed at [2] 
from your email is more memory hungry. Where exactly was that said?
[1]: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CRREDQUPPJYWVRMA4DOKYU2KZZLKC4D5/ 

[2]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies 


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

When is a file dependency appropriate?

2022-10-05 Thread Otto Liljalaakso

Recently, I have run into some cases where file dependencies like 
Requires: /usr/bin/foo are used.


In a recent thread on this mailing list [1],
it is mentioned that such Requires should be avoided,
because resolving file dependencies requires a large amount of memory.

On the other hand, if the dependency really is to the named executable,
then such Require seems to be the most correct way to declare it.

Is there any recommendation which of these should be given more weight?
The packaging guidelines do not state any position currently [2].
Should they actually recommend using Requires: foo (the package name),
to help dnf memory usage?
Of course unless there is some specific reason to use the file 
dependency, like /usr/bin/ffmpeg that can come from Fedora or RPM 
Fusion, depending on which variant the user has chosen to install.


[1]: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CRREDQUPPJYWVRMA4DOKYU2KZZLKC4D5/
[2]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies

___
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: SRPM macros, EPEL, and side tags

2022-10-05 Thread Kevin Fenzi

On Wed, Oct 05, 2022 at 08:40:12PM -, Artur Frenszek-Iwicki wrote:
> Hi all,
> 
> some time ago I've built the Free Pascal Compiler [0] for EPEL9,
> and recently I got the idea it might be good to do the same with
> the Lazarus IDE [1]. Testing things locally with mock,
> I realized that Lazarus used a macro from fpc-srpm-macros [2],
> which hasn't been built for EPEL9 yet.
> 
> No biggie, I thought. I created a side tag, built fpc-srpm-macros there,
> then added "BuildRequires: fpc-srpm-macros" to the Lazarus spec
> and tried building it in the side tag. The build failed, and looking at
> root.log, the fpc-srpm-macros package was not installed [3].

srpm's are built in a different buildroot koji has defined as
'srpm-build'.

You can see whats in this with a 'koji list-groups epel9-build'

So yeah, you need something to pull in that fpc-srpm-macros, 
(likely epel-release) or have it added to the srpm-build group. 

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: Grub menu with 3 kernels by default

2022-10-05 Thread Chris Murphy



On Wed, Oct 5, 2022, at 3:01 PM, Vít Ondruch wrote:
>
> 3. "Boot menu" in GUI? Given that one can reach the GUI, why it should 
> not be possible to choose the boot entry for next boot? Or even choose 
> to open FW setup.

This could solve this other problem too.

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

The GUI tool can use efibootmgr to set bootnext or even bootorder.

-- 
Chris Murphy
___
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

SRPM macros, EPEL, and side tags

2022-10-05 Thread Artur Frenszek-Iwicki

Hi all,

some time ago I've built the Free Pascal Compiler [0] for EPEL9,
and recently I got the idea it might be good to do the same with
the Lazarus IDE [1]. Testing things locally with mock,
I realized that Lazarus used a macro from fpc-srpm-macros [2],
which hasn't been built for EPEL9 yet.

No biggie, I thought. I created a side tag, built fpc-srpm-macros there,
then added "BuildRequires: fpc-srpm-macros" to the Lazarus spec
and tried building it in the side tag. The build failed, and looking at
root.log, the fpc-srpm-macros package was not installed [3].

So I guess my question is, did I do something wrong,
or do srpm-macros packages need to be explicitly added to the buildroot?

Thanks in advance,
A.FI.

[0] https://src.fedoraproject.org/rpms/fpc
[1] https://src.fedoraproject.org/rpms/lazarus
[2] https://src.fedoraproject.org/rpms/fpc-srpm-macros
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=92624197
___
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: How to repoquery without false-evaluated conditional requires?

2022-10-05 Thread Miro Hrončok


On 05. 10. 22 14:15, Petr Pisar wrote:

V Wed, Oct 05, 2022 at 11:22:27AM +0200, Miro Hrončok napsal(a):

Hello.

I need to repoquery rawhide and rawhide-source for dependency on python3-toml.

Unfortunately, due to pyproject-rpm-macros, 413 packages BuildRequire:

   (python3dist(toml) if python3-devel < 3.11)

I am not interested in this dependency because python3-devel on rawhide is 
3.11+.


When I run a naïve repoquery on my Fedora 35 machine (with python3-devel
3.10), like this:

   $ repoquery --repo=rawhide{,-source} --whatrequires python3-toml

I get all the 413 packages in the results. I kinda expected that.

I've tried:

   $ repoquery --installroot ~/tmp/non-existent ... --whatrequires python3-toml

No dice, returns the same list as the first repoquery.


I feel repoquery should respect --installroot. It needs to take @system
repository (i.e. installad packages) from somewhere. --instalroot is that
place. If DNF does not do that, I recommend filing a bug.


I've opened https://bugzilla.redhat.com/show_bug.cgi?id=2132462

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

Fedora CoreOS Meeting Minutes 2022-10-05

2022-10-05 Thread Dusty Mabe


#fedora-meeting-1: fedora_coreos_meeting



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



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

* Action items from last meeting  (dustymabe, 16:33:26)

* Fedora CoreOS 37 test day  (dustymabe, 16:34:33)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1225
(dustymabe, 16:34:37)
  * we had a successful test day. No major issues were found with F37
based FCOS on the `next` stream. We had several documentation
updates that were proposed and some new documentation that was
created as well!  (dustymabe, 16:37:16)

* Supporting FIPS mode in FCOS  (dustymabe, 16:38:38)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/302
(dustymabe, 16:38:47)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/607
(dustymabe, 17:01:36)
  * AGREED: adding a fips=1 kernel argument via Ignition becomes the
canonical low level API to signal desire for FIPS mode, FCOS will
add glue to do the remaining userspace portions on firstboot, and we
will add a minimal kola test that verifies this works; no butane
sugar yet, and documentation that briefly describes this state
(dustymabe, 17:13:28)

* OstreeNativeContainerStable proposal  (dustymabe, 17:14:02)
  * LINK:
https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable
(dustymabe, 17:14:09)
  * Summary: there are a lot of subtopics within this proposal and we
think it would be useful to split up the proposal into smaller
proposals in order to focus discussion and help drive to conclusions
and actions.  (dustymabe, 17:41:16)

* open floor   (dustymabe, 17:45:49)
  * Fedora Final Freeze is now in effect and we will start building
`next` once a week to increase use/feedback of F37 in during this
time  (dustymabe, 17:47:34)
  * The new serial console defaults landed in `next`.  Please test!
(bgilbert, 17:47:48)
  * LINK:

https://lists.fedoraproject.org/archives/list/coreos-sta...@lists.fedoraproject.org/message/GHLXX4MXNHUEAXQLK6BZN45IQYHRVQB4/
(bgilbert, 17:48:04)

Meeting ended at 17:49:41 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (102)
* bgilbert (49)
* jlebon (47)
* walters (30)
* zodbot (19)
* fifofonix (10)
* jbrooks (2)
* gursewak (1)
* ravanelli (1)
* davdunc (1)
* cyberpear (1)




Generated by `MeetBot`_ 0.4

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

Re: Replacing GNOME Disks with Blivet GUI in comps' admin-tools?

2022-10-05 Thread Neal Gompa

On Wed, Oct 5, 2022 at 8:23 PM Ben Cotton  wrote:
>
> In going through the bugs against comps, I came across
> https://bugzilla.redhat.com/show_bug.cgi?id=1971338
>
> The "admin-tools" group in comps includes GNOME Disks, which is a
> surprise for KDE Plasma users. We can swap it out for blivet-gui (note
> that other groups for GTK-based desktops would still include GNOME
> Disks) easily enough, but I didn't want to do that without seeking
> comment.
>
> Does anyone have a good reason we shouldn't make this change?
>
> (I don't think this rises to the level of requiring a Self-Contained
> Change proposal, but I'm happy to submit one if the consensus is that
> it should have one)
>

Makes sense to me. +1



-- 
真実はいつも一つ！/ 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: Replacing GNOME Disks with Blivet GUI in comps' admin-tools?

2022-10-05 Thread Kevin Fenzi

On Wed, Oct 05, 2022 at 02:22:52PM -0400, Ben Cotton wrote:
> In going through the bugs against comps, I came across
> https://bugzilla.redhat.com/show_bug.cgi?id=1971338
> 
> The "admin-tools" group in comps includes GNOME Disks, which is a
> surprise for KDE Plasma users. We can swap it out for blivet-gui (note
> that other groups for GTK-based desktops would still include GNOME
> Disks) easily enough, but I didn't want to do that without seeking
> comment.
> 
> Does anyone have a good reason we shouldn't make this change?
> 
> (I don't think this rises to the level of requiring a Self-Contained
> Change proposal, but I'm happy to submit one if the consensus is that
> it should have one)

+1 to just do it. I don't think it needs a change. 

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: Grub menu with 3 kernels by default

2022-10-05 Thread Vít Ondruch



Dne 05. 10. 22 v 20:28 Hans de Goede napsal(a):

Hi,

On 10/5/22 19:59, Christopher Klooz wrote:

On 05/10/2022 18:39, Christopher Klooz wrote:

On 05/10/2022 17:33, Chris Murphy wrote:

On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote:


However, on ask.fp, a user mentioned that the grub menu is no longer
enabled by default on single boot systems so that changing the kernel is
no longer easily possible, and put forward
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for
this argument. Yet, the article indicates that the argument is not fully
correct and even with single boot installations, SHIFT can be used to
get into the grub menu.

I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found, because 
it's reserved by UEFI firmware for one of its menus. And SHIFT has never 
worked. Maybe Esc or TAB?

Holding left shift is the easiest method, but with firmware being
firmware does not work on all systems.

What does always work is ESC or F8, Fedora's grub supports both to
show the menu. On some systems one of those key get intercepted by
the firmware which is why there are 2 choices.


Given this inconsistency, I have a mixed opinion of the hidden GRUB menu.



Me, too. Especially as it makes support more problematic for unexperiened users. It is 
easy to say that people should push another kernel when they see the grub menu. They see 
text, and I can tell them which text to choose. But with unexperiened users, telling when 
to push tab/esc/shift/F8 can already need to start an elaboration of what 
"boot" means and when this happens and so on. Such elaborations are already 
annoying for them (and for the supporters).

The menu automatically unhides after a failed boot. Just blindly
doing ctrl + alt + f4 followed by ctrl + alt + delete; or just
power-cycling the machine counts as a failed boot.

We have spend a lot of time on creating a smooth boot experience
without any menus filled with "techno babble" which scare
novice users. Lets avoid regressing on this.

If anything what we need is to:

1. Detect we are running not the latest kernel
2. Pop up a dialog that 1. is true and ask the user if there
were issues with the latest kernel and if yes if they want
to pin the currently running kernel for say the next month ?



3. "Boot menu" in GUI? Given that one can reach the GUI, why it should 
not be possible to choose the boot entry for next boot? Or even choose 
to open FW setup.



Vít




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

Re: Grub menu with 3 kernels by default

2022-10-05 Thread Christopher Klooz



On 05/10/2022 20:28, Hans de Goede wrote:

Hi,

On 10/5/22 19:59, Christopher Klooz wrote:

On 05/10/2022 18:39, Christopher Klooz wrote:

On 05/10/2022 17:33, Chris Murphy wrote:

On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote:


However, on ask.fp, a user mentioned that the grub menu is no longer
enabled by default on single boot systems so that changing the kernel is
no longer easily possible, and put forward
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for
this argument. Yet, the article indicates that the argument is not fully
correct and even with single boot installations, SHIFT can be used to
get into the grub menu.

I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found, because 
it's reserved by UEFI firmware for one of its menus. And SHIFT has never 
worked. Maybe Esc or TAB?

Holding left shift is the easiest method, but with firmware being
firmware does not work on all systems.

What does always work is ESC or F8, Fedora's grub supports both to
show the menu. On some systems one of those key get intercepted by
the firmware which is why there are 2 choices.


Given this inconsistency, I have a mixed opinion of the hidden GRUB menu.



Me, too. Especially as it makes support more problematic for unexperiened users. It is 
easy to say that people should push another kernel when they see the grub menu. They see 
text, and I can tell them which text to choose. But with unexperiened users, telling when 
to push tab/esc/shift/F8 can already need to start an elaboration of what 
"boot" means and when this happens and so on. Such elaborations are already 
annoying for them (and for the supporters).

The menu automatically unhides after a failed boot. Just blindly
doing ctrl + alt + f4 followed by ctrl + alt + delete; or just
power-cycling the machine counts as a failed boot.
Many problems that can occur do not cause a failed boot. This starts 
with the current issue in 5.19.12. Another widespread issue is that 
users have problems with a piece of hardware (e.g., bluetooth 
controller), or with modules causing unintended behavior with one kernel 
(freeze, slow, something like wifi or bluetooth does not work, other 
acpi issues, and so on). All that does not necessarily cause failed 
boots, but is widespread among our "user base" at ask.fp especially 
because Fedora is used on much different hardware, and some needs 
additionally external modules.


We have spend a lot of time on creating a smooth boot experience
without any menus filled with "techno babble" which scare
novice users. Lets avoid regressing on this.


I am not sure if the outcome is even more scary for users, especially 
unexperienced users. Finding out which key to use seems to be not smooth 
even for experienced people in the devel mailing list. Also, I am not 
sure if this perception of unexperienced users who want to get rid of 
"seeing any type of text" reflects our less-techy user base. My 
perception at ask.fp or from conferences is different. But I already 
elaborated that in my previous mails.




If anything what we need is to:

1. Detect we are running not the latest kernel
2. Pop up a dialog that 1. is true and ask the user if there
were issues with the latest kernel and if yes if they want
to pin the currently running kernel for say the next month ?

Regards,

Hans


___
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: Grub menu with 3 kernels by default

2022-10-05 Thread Hans de Goede

Hi,

On 10/5/22 19:59, Christopher Klooz wrote:
> 
> On 05/10/2022 18:39, Christopher Klooz wrote:
>> On 05/10/2022 17:33, Chris Murphy wrote:
>>>
>>> On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote:
>>>
 However, on ask.fp, a user mentioned that the grub menu is no longer
 enabled by default on single boot systems so that changing the kernel is
 no longer easily possible, and put forward
 https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for
 this argument. Yet, the article indicates that the argument is not fully
 correct and even with single boot installations, SHIFT can be used to
 get into the grub menu.
>>> I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found, 
>>> because it's reserved by UEFI firmware for one of its menus. And SHIFT has 
>>> never worked. Maybe Esc or TAB?

Holding left shift is the easiest method, but with firmware being
firmware does not work on all systems.

What does always work is ESC or F8, Fedora's grub supports both to
show the menu. On some systems one of those key get intercepted by
the firmware which is why there are 2 choices.

>>> Given this inconsistency, I have a mixed opinion of the hidden GRUB menu.
>>>
>>>
>> Me, too. Especially as it makes support more problematic for unexperiened 
>> users. It is easy to say that people should push another kernel when they 
>> see the grub menu. They see text, and I can tell them which text to choose. 
>> But with unexperiened users, telling when to push tab/esc/shift/F8 can 
>> already need to start an elaboration of what "boot" means and when this 
>> happens and so on. Such elaborations are already annoying for them (and for 
>> the supporters).

The menu automatically unhides after a failed boot. Just blindly
doing ctrl + alt + f4 followed by ctrl + alt + delete; or just
power-cycling the machine counts as a failed boot.

We have spend a lot of time on creating a smooth boot experience
without any menus filled with "techno babble" which scare
novice users. Lets avoid regressing on this.

If anything what we need is to:

1. Detect we are running not the latest kernel
2. Pop up a dialog that 1. is true and ask the user if there
were issues with the latest kernel and if yes if they want
to pin the currently running kernel for say the next month ?

Regards,

Hans

___
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: Grub menu with 3 kernels by default

2022-10-05 Thread Ralf Corsépius




Am 05.10.22 um 17:33 schrieb Chris Murphy:

Given this inconsistency, I have a mixed opinion of the hidden GRUB menu.

I have a very clear opinion - It's a fault and usability regression.

Ralf

___
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

Replacing GNOME Disks with Blivet GUI in comps' admin-tools?

2022-10-05 Thread Ben Cotton

In going through the bugs against comps, I came across
https://bugzilla.redhat.com/show_bug.cgi?id=1971338

The "admin-tools" group in comps includes GNOME Disks, which is a
surprise for KDE Plasma users. We can swap it out for blivet-gui (note
that other groups for GTK-based desktops would still include GNOME
Disks) easily enough, but I didn't want to do that without seeking
comment.

Does anyone have a good reason we shouldn't make this change?

(I don't think this rises to the level of requiring a Self-Contained
Change proposal, but I'm happy to submit one if the consensus is that
it should have one)

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

Re: Grub menu with 3 kernels by default

2022-10-05 Thread Hans de Goede

Hi,

On 10/5/22 17:16, Christopher Klooz wrote:
> The current issue on 5.19.12 made it necessary for some users to change their 
> kernel on boot to avoid 5.19.12 until the update to 5.19.13 was pushed to 
> stable. Obviously, the option to easily boot recent kernels can be necessary 
> in several circumstances, especially for non-advanced users it has proven to 
> be very helpful on ask.fp to achieve that with two easily-to-describe clicks.
> 
> However, on ask.fp, a user mentioned that the grub menu is no longer enabled 
> by default on single boot systems so that changing the kernel is no longer 
> easily possible, and put forward 
> https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for this 
> argument. Yet, the article indicates that the argument is not fully correct 
> and even with single boot installations, SHIFT can be used to get into the 
> grub menu. Generally, my experience with non-advanced users on ask.fp and in 
> general does not correspond to the arguments in the article. However, on all 
> my Workstation and KDE/lxqt spin installations (one originally installed 
> before F29, others between F33 & F36), this article does not apply at all, 
> and by default, I can choose between the recent three kernels for 5 seconds 
> in the grub menu on all single boot systems, unless I change the grub config 
> myself.
> 
> So first of all, does the article currently apply to any edition? If not, we 
> might change the content to avoid further confusion...

We still hide the grub menu by default on single OS installs, at least in the 
Workstation product.

On EFI systems where holding down SHIFT relies on the EFI implementation 
actually giving us modififier key presses even when no "normal" key is pressed 
might not work, there are several other options documented in the hidden boot 
menu FAQ (also linked from the change page):

https://hansdegoede.dreamwidth.org/19180.html

Regards,

Hans
___
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: Grub menu with 3 kernels by default

2022-10-05 Thread Christopher Klooz

On 05/10/2022 18:39, Christopher Klooz wrote:

On 05/10/2022 17:33, Chris Murphy wrote:

On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote:

However, on ask.fp, a user mentioned that the grub menu is no longer
enabled by default on single boot systems so that changing the
kernel is

no longer easily possible, and put forward
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for
this argument. Yet, the article indicates that the argument is not
fully

correct and even with single boot installations, SHIFT can be used to
get into the grub menu.
I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found,
because it's reserved by UEFI firmware for one of its menus. And
SHIFT has never worked. Maybe Esc or TAB?

Given this inconsistency, I have a mixed opinion of the hidden GRUB
menu.

Me, too. Especially as it makes support more problematic for
unexperiened users. It is easy to say that people should push another
kernel when they see the grub menu. They see text, and I can tell them
which text to choose. But with unexperiened users, telling when to
push tab/esc/shift/F8 can already need to start an elaboration of what
"boot" means and when this happens and so on. Such elaborations are
already annoying for them (and for the supporters).

I know that many unexperienced users don't like if they have to work
in text mode, or if they have to work with these texts. But the
appearance of a grub menu that automatically makes the choice for them
is something I have never heard a complaint about. Also, people don't
like if they are urged to seek help (which they have to because
unexperiened users will often not formulate search queries that makes
them end up on helpful/related documentation). If they see the menu,
many find out themselves what this is and for what they can use it,
supporting their independence (others simply ignore it).

Maybe it makes sense to revert the hiding of the menu?

In any case, the information we provide should be updated to be
consistent. F8/SHIFT/ESC/TAB? I cannot verify which is currently the
correct button as I do not experience that behavior. However, it is
interesting that I have this behavior not on my single-boot systems.
Maybe further inconsistency can get introduced by firmware (another
complication that could make it more complicated for users - and
supporters obviously as well).
I cannot verify Jeff's comment (this one:
https://ask.fedoraproject.org/t/does-the-grub-menu-appear-by-default-on-single-boot-workstation-installations/27270/8
), but he says that the hiding of the grub menu was already reverted for
new installations in one of the recent releases.

___
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: Grub menu with 3 kernels by default

2022-10-05 Thread Peter Robinson

On Wed, Oct 5, 2022 at 6:16 PM Chris Murphy  wrote:
>
>
>
> On Wed, Oct 5, 2022, at 11:43 AM, Geraldo Simião Kutz wrote:
>
> On my acer Aspire laptop it's the "esc" key. Works everytime I want to see 
> the grub menu.
>
>
> The gotcha with ESC is that it brings up firmware settings on qemu-kvm when 
> using UEFI (edk2-ovmf).

I believe you can also hold down the left control key and have the same effect.
___
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: Grub menu with 3 kernels by default

2022-10-05 Thread Chris Murphy



On Wed, Oct 5, 2022, at 11:43 AM, Geraldo Simião Kutz wrote:
> On my acer Aspire laptop it's the "esc" key. Works everytime I want to see 
> the grub menu.

The gotcha with ESC is that it brings up firmware settings on qemu-kvm when 
using UEFI (edk2-ovmf).


--
Chris Murphy
___
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: Grub menu with 3 kernels by default

2022-10-05 Thread Christopher Klooz


On 05/10/2022 17:33, Chris Murphy wrote:


On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote:


However, on ask.fp, a user mentioned that the grub menu is no longer
enabled by default on single boot systems so that changing the kernel is
no longer easily possible, and put forward
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for
this argument. Yet, the article indicates that the argument is not fully
correct and even with single boot installations, SHIFT can be used to
get into the grub menu.
I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found, 
because it's reserved by UEFI firmware for one of its menus. And SHIFT 
has never worked. Maybe Esc or TAB?


Given this inconsistency, I have a mixed opinion of the hidden GRUB menu.


Me, too. Especially as it makes support more problematic for 
unexperiened users. It is easy to say that people should push another 
kernel when they see the grub menu. They see text, and I can tell them 
which text to choose. But with unexperiened users, telling when to push 
tab/esc/shift/F8 can already need to start an elaboration of what "boot" 
means and when this happens and so on. Such elaborations are already 
annoying for them (and for the supporters).


I know that many unexperienced users don't like if they have to work in 
text mode, or if they have to work with these texts. But the appearance 
of a grub menu that automatically makes the choice for them is something 
I have never heard a complaint about. Also, people don't like if they 
are urged to seek help (which they have to because unexperiened users 
will often not formulate search queries that makes them end up on 
helpful/related documentation). If they see the menu, many find out 
themselves what this is and for what they can use it, supporting their 
independence (others simply ignore it).


Maybe it makes sense to revert the hiding of the menu?

In any case, the information we provide should be updated to be 
consistent. F8/SHIFT/ESC/TAB? I cannot verify which is currently the 
correct button as I do not experience that behavior. However, it is 
interesting that I have this behavior not on my single-boot systems. 
Maybe further inconsistency can get introduced by firmware (another 
complication that could make it more complicated for users - and 
supporters obviously as well).

___
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: Grub menu with 3 kernels by default

2022-10-05 Thread Geraldo Simião Kutz

On my acer Aspire laptop it's the "esc" key. Works everytime I want to see
the grub menu.

geraldosimiao

Em qua, 5 de out de 2022 12:33, Chris Murphy 
escreveu:

>
>
> On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote:
>
> > However, on ask.fp, a user mentioned that the grub menu is no longer
> > enabled by default on single boot systems so that changing the kernel is
> > no longer easily possible, and put forward
> > https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for
> > this argument. Yet, the article indicates that the argument is not fully
> > correct and even with single boot installations, SHIFT can be used to
> > get into the grub menu.
>
> I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found,
> because it's reserved by UEFI firmware for one of its menus. And SHIFT has
> never worked. Maybe Esc or TAB?
>
> Given this inconsistency, I have a mixed opinion of the hidden GRUB menu.
>
>
> --
> Chris Murphy
> ___
> 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

Re: Grub menu with 3 kernels by default

2022-10-05 Thread Chris Murphy



On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote:

> However, on ask.fp, a user mentioned that the grub menu is no longer 
> enabled by default on single boot systems so that changing the kernel is 
> no longer easily possible, and put forward 
> https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for 
> this argument. Yet, the article indicates that the argument is not fully 
> correct and even with single boot installations, SHIFT can be used to 
> get into the grub menu. 

I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found, because 
it's reserved by UEFI firmware for one of its menus. And SHIFT has never 
worked. Maybe Esc or TAB?

Given this inconsistency, I have a mixed opinion of the hidden GRUB menu.


-- 
Chris Murphy
___
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

Grub menu with 3 kernels by default

2022-10-05 Thread Christopher Klooz

The current issue on 5.19.12 made it necessary for some users to change 
their kernel on boot to avoid 5.19.12 until the update to 5.19.13 was 
pushed to stable. Obviously, the option to easily boot recent kernels 
can be necessary in several circumstances, especially for non-advanced 
users it has proven to be very helpful on ask.fp to achieve that with 
two easily-to-describe clicks.


However, on ask.fp, a user mentioned that the grub menu is no longer 
enabled by default on single boot systems so that changing the kernel is 
no longer easily possible, and put forward 
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for 
this argument. Yet, the article indicates that the argument is not fully 
correct and even with single boot installations, SHIFT can be used to 
get into the grub menu. Generally, my experience with non-advanced users 
on ask.fp and in general does not correspond to the arguments in the 
article. However, on all my Workstation and KDE/lxqt spin installations 
(one originally installed before F29, others between F33 & F36), this 
article does not apply at all, and by default, I can choose between the 
recent three kernels for 5 seconds in the grub menu on all single boot 
systems, unless I change the grub config myself.


So first of all, does the article currently apply to any edition? If 
not, we might change the content to avoid further confusion...


Regards,

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

67 matches

Mail list logo