from:"Robert Marcano via devel"

Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

2024-01-19 Thread Robert Marcano via devel


On 1/19/24 12:58 PM, Robert Marcano wrote:

On 12/28/23 1:25 PM, Robert Marcano wrote:

On 12/28/23 12:58 PM, Chris Adams wrote:

Once upon a time, Aoife Moloney  said:

Systemd will be modified to insert the additional directories into the
`$PATH` environment variable (affecting all programs on the system)


Anything that depends on PATH entries is IMHO doomed to failure.  There
are way too many things that explicitly set PATH to "known" values (for
good and bad reasons) to be able to depend on extending it.  Heck, it
took a long time to get sudo just to include /usr/local/{bin,sbin}.



Maybe replacing the /usr/bin related entries with a generic wrapper 
that launch the best binary from the per architecture directories.


Note: This may affect a few programs that use argv[0] for something 
meaningful.


The more I think about this, I am more convinced that /usr/bin installed 
binaries must do this redirection too even in the case the PATH is 
modified as this proposal states.


What about programs intentionally use absolute paths? These programs 
will not take advantage of the optimizations of the binary they are 
trying to start.


There many reasons for sometimes using an absolute path is agood idea, 
like:


1. Security: avoid depending on a PATH that can be user manipulated.
2. Configuration files that allow to switch to alternate implementation 
of the tool they call. I found a few on my installation, and their 
defaults include /usr/bin absolute paths.
3. Programs that run inside PATH is reset for security like sudo, 
CGI-BIN, etc.


Notice this PATH based optimization will only work when callers invoke 
the program by name only, relative paths will not get optimized either, 
a rare case but it could happen.


I have a counter proposal without modifying $PATH:

With the already defined directories 
/usr/bin/glibc-hwcaps/x86-64-v{2,3,4}/ add two new ones:


  /usr/bin/glibc-hwcaps/x86-64
  /usr/bin/glibc-hwcaps/x86-64-dynamic

Applications with optimized binaries will continue to install them on 
/usr/bin/glibc-hwcaps/x86-64-v{2,3,4}/ but the non optimized version 
isn't installed on /usr/bin but on /usr/bin/glibc-hwcaps/x86-64.


/usr/bin/glibc-hwcaps/x86-64-dynamic will be a read only overlayfs 
mounted by systemd, stacked with x86-64v4 on top and x86-64 on the bottom.


There will not be /usr/bin binaries for the optimized packages but 
symlinks to /usr/bin/glibc-hwcaps/x86-64-dynamic


Advantages for systemd based environment:

1. The optimized binaries are available to all the system, without 
worrying about applications that reset $PATH, or executions by relative 
or absolute paths and not only by name.


2. Imagine if and application like Firefox (only an example) get a boost 
by having the main binary optimized. /usr/bin/firefox currently is a 
shell script, there is no way optimize it with the current proposal, 
only if the script duplicates the microachitecture selection logic. With 
this proposal, modifying /usr/lib64/firefox/firefox to point to 
/usr/bin/glibc-hwcaps/x86-64-dynamic/firefox could work to. In reality 
it can work for all binaries outside of $PATH.


There are two downsides I could find:

1. Fedora Container images must be build with 
/usr/bin/glibc-hwcaps/x86-64-dynamic being a symlink to 
/usr/bin/glibc-hwcaps/x86-64 in order to non optimized binaries to be 
the default. This current proposal doesn't optimize either for 
containers runtimes that don't run systemd inside the container. Maybe 
in the future if this kind of layout get adoption on other 
distributions, container runtimes could do the overlay mount by themselves


2. In the case of trying to rescue the system, the process to create a 
chroot from the installation media will need and extra bind mount for 
/usr/bin/glibc-hwcaps/x86-64-dynamic pointing to 
/usr/bin/glibc-hwcaps/x86-64


Note aside: I think that the Live CD image should get an script 
available that do the same rescue boot option when trying to build the 
disk tree on /mnt/sysimage, if that script were available on LiveCD, 
rescue operations would be easier.

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

Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

2024-01-19 Thread Robert Marcano via devel


On 12/28/23 1:25 PM, Robert Marcano wrote:

On 12/28/23 12:58 PM, Chris Adams wrote:

Once upon a time, Aoife Moloney  said:

Systemd will be modified to insert the additional directories into the
`$PATH` environment variable (affecting all programs on the system)


Anything that depends on PATH entries is IMHO doomed to failure.  There
are way too many things that explicitly set PATH to "known" values (for
good and bad reasons) to be able to depend on extending it.  Heck, it
took a long time to get sudo just to include /usr/local/{bin,sbin}.



Maybe replacing the /usr/bin related entries with a generic wrapper that 
launch the best binary from the per architecture directories.


Note: This may affect a few programs that use argv[0] for something 
meaningful.


The more I think about this, I am more convinced that /usr/bin installed 
binaries must do this redirection too even in the case the PATH is 
modified as this proposal states.


What about programs intentionally use absolute paths? These programs 
will not take advantage of the optimizations of the binary they are 
trying to start.


There many reasons for sometimes using an absolute path is agood idea, like:

1. Security: avoid depending on a PATH that can be user manipulated.
2. Configuration files that allow to switch to alternate implementation 
of the tool they call. I found a few on my installation, and their 
defaults include /usr/bin absolute paths.
3. Programs that run inside PATH is reset for security like sudo, 
CGI-BIN, etc.


Notice this PATH based optimization will only work when callers invoke 
the program by name only, relative paths will not get optimized either, 
a rare case but it could happen.

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

Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

2023-12-28 Thread Robert Marcano via devel


On 12/28/23 12:58 PM, Chris Adams wrote:

Once upon a time, Aoife Moloney  said:

Systemd will be modified to insert the additional directories into the
`$PATH` environment variable (affecting all programs on the system)


Anything that depends on PATH entries is IMHO doomed to failure.  There
are way too many things that explicitly set PATH to "known" values (for
good and bad reasons) to be able to depend on extending it.  Heck, it
took a long time to get sudo just to include /usr/local/{bin,sbin}.



Maybe replacing the /usr/bin related entries with a generic wrapper that 
launch the best binary from the per architecture directories.


Note: This may affect a few programs that use argv[0] for something 
meaningful.

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

Re: Packaging web extension native part and shared directory ownership

2023-10-18 Thread Robert Marcano via devel


On 10/18/23 11:36 AM, Jason L Tibbitts III wrote:

Robert Marcano via devel  writes:



I seriously don't know how gnome-browser-connector [1] has ownership
of:



   /usr/lib64/mozilla/native-messaging-hosts



and not have conflict problems with mozilla-filesystem at install
time, maybe because they usually get installed at the same time with
the system installer.


As long as the directories have the same ownership and permissions,
there is no conflict.  Multiple packages owning a single directory is
not uncommon, and the case is covered in the packaging guidelines:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership

"
To be specific, you do not need to require a package for the sole fact
that it happens to own a directory that your package places files in. If
your package already requires that package for other reasons, then your
package should not also own that directory.


Thanks for the reply, the problem was solved after reading:

When co-owning directories, you must ensure that the ownership and 
permissions on the directory match in all packages that own it.


The install script was setting a slightly different permission.


"

(Yes, the grammar there isn't the best.)

  - J<

___
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

Packaging web extension native part and shared directory ownership

2023-10-18 Thread Robert Marcano via devel

In order to install the native side of a web extension, It is needed to 
place a JSON manifest on predefined directories for each supported browser:


  /usr/lib64/mozilla/native-messaging-hosts
  /etc/chromium/native-messaging-hosts
  /etc/opt/chrome/native-messaging-hosts

Creating a package that support each browser without having to create 
one subpackage for each one has the problem of having to set the 
ownership for each of these directories to my package, but that 
generates conflicts with the real owners at install time.


I can maybe use an ugly workaround, not having ownership and removing 
empty directories by hand on uninstall.


I seriously don't know how gnome-browser-connector [1] has ownership of:

  /usr/lib64/mozilla/native-messaging-hosts

and not have conflict problems with mozilla-filesystem at install time, 
maybe because they usually get installed at the same time with the 
system installer.


Any recommendations? This is not a Fedora package but want it to be 
Fedora compatible, I just want the single package give support for any 
browser like gnome-browser-connector do, without leaving leftover 
directories at uninstall if the user doesn't have that browser installed.


[1] 
https://src.fedoraproject.org/rpms/gnome-browser-connector/blob/f38/f/gnome-browser-connector.spec

___
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: LibreOffice packages

2023-06-05 Thread Robert Marcano via devel


On 6/5/23 2:05 PM, Chris Adams wrote:

Once upon a time, Stephen Smoogen  said:

1. What is a flatpak and what does it mean to have an application in it? Is
it everything bundled in it or does it use layers?


It's layered, but from what I understand, an upper layer depends on a
specific build of a lower layer.  So using the up-thread example, if
there's a security update to zlib, the lower layer can rebuild to pick
it up, but until the upper layer (like say LO) also rebuilds on top of
the new lower layer, they'll be running on the old version.



These layers (runtimes and addons) can be updated and applications take 
the changes after being restarted, no nee to rebuild. The rebuild is 
only needed if the library is bundled with the applications because it 
isn't part of the chosen runtime or addons.


Runtimes contains aren´t and entire Linux distribution, so applications 
frequently need  to bundle libraries. Sites like flathub should add a 
way to check bundled dependencies in order to notify packagers of 
updating an application. Like server container need security audit tools.

___
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: LibreOffice packages

2023-06-03 Thread Robert Marcano via devel


On 6/2/23 8:49 AM, Terry Bowling wrote:
I appreciate and am empathetic to all of those carrying the burden of 
this and the thousands of other RPM packages.  As a users of Fedora + 
RPM Fusion + Cinnamon Desktop as my daily laptop driver since 2011, I 
love Fedora and am a heavy user of Flatpacks.  So thank you all.


That said, I will point out that I have heard of at least 4 
enterprise customers who use libreoffice as a headless file conversion 
utility.  I have seen it used in customer facing production workflows, 
such as a financial user support website to handle file uploads provided 
by end users, as well as medical health records systems used by 
hospitals and doctors offices. 
https://www.libreofficehelp.com/batch-convert-writer-documents-pdf-libreoffice/ 


I am not asking for a change in strategy.  I understand our resource 
challenges.  I only wanted to share this perspective.  Packaging the 
RPMS in EPEL could alleviate the pain for these customers in the RHEL 10 
timeframe, as well as a container image (maybe built from the rpms 
pulled from EPEL?).


Hope this is helpful.  And again, THANK YOU!


People using LibreOffice for a backend document conversions can use 
Collabora Online (supported or self build one), it not only has a web 
frontend for LibreOffice, it provides REST endpoints for doing conversions.


The flatpak replacement is a solution for desktop user that need the 
application, but don't forget that LibreOffice not only provides 
applications but an entire programmatic AP (UNO) where nearly everything 
can be automated. We use it at work to "embed" a document editor in 
desktop applications. To be fair, that is being migrated to the online 
version and everything done via web. But there are business apps 
interacting with a supported LibreOffice API provided by RHEL, that 
change will not be very welcomed. They will need to move to another 
enterprise distribution or pay extra for a enterprise supported version 
of LO.


But that is a RHEL problem. On the Fedora side, shipping Fedora without 
a desktop suite will make more people to jump ship. Live editions will 
be crippled because they will not include external flatpaks.


I say thanks to the maintainers that worked hard on packaging LO and 
hope they advance a lot on the infrastructure work they are doing, like 
color management in Wayland. Seriously I wish they find a way for 
Wayland applications are able to save their windows positions (there was 
a cookie proposal a long time ago that never advanced IIRC). The random 
window placement of GNOME Shell is the most irritating misfeature of the 
entire Fedora Workstation for me.




Terry Bowling
Sr. Product Manager - RHEL Installation & Build Services Experience
Red Hat, Inc.




On Thu, Jun 1, 2023 at 2:31 PM Matthias Clasen > wrote:


Hey,

as you've probably seen, the LibreOffice RPMS have recently been
orphaned, and I thought it would be good to explain the reasons
behind this.

The Red Hat Display Systems team (the team behind most of Red Hat’s
desktop efforts) has maintained the LibreOffice packages in Fedora
for years as part of our work to support LibreOffice for Red Hat
Enterprise Linux. We are adjusting our engineering priorities for
RHEL for Workstations and focusing on gaps in Wayland, building out
HDR support, building out what’s needed for color-sensitive work,
and a host of other refinements required by Workstation users. This
is work that will improve the workstation experience for Fedora as
well as RHEL users, and which, we hope, will be positively received
by the entire Linux community.

The tradeoff is that we are pivoting away from work we had been
doing on desktop applications and will cease shipping LibreOffice as
part of RHEL starting in a future RHEL version. This also limits our
ability to maintain it in future versions of Fedora.

We will continue to maintain LibreOffice in currently supported
versions of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for
the lifetime of those releases (as published on the Red Hat
website). As part of that, the engineers doing that work will
contribute some fixes upstream to ensure LibreOffice works better as
a Flatpak, which we expect to be the way that most people consume
LibreOffice in the long term.

Any community member is of course free to take over maintenance,
both for the RPMS in Fedora and the Fedora LibreOffice Flatpak, but
be aware that this is a sizable block of packages and dependencies
and a significant amount of work to keep up with.

Matthias
___
devel mailing list -- devel@lists.fedoraproject.org

To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-06-01 Thread Robert Marcano via devel


On 6/1/23 8:33 AM, Richard W.M. Jones wrote:

On Thu, Jun 01, 2023 at 08:28:18AM -0400, Robert Marcano via devel wrote:

On 6/1/23 3:51 AM, Richard W.M. Jones wrote:

On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote:

This was heavily discussed when we moved to portable build in rpms -
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
Long story short yes, if yo wish to distribute jdk *binary* it have
to pass java compliance suite.


It sounds like the problem is the software isn't really open source
because it has some field of use restrictions.  The best plan would be
to change this upstream, and if that isn't possible then to remove it

>from Fedora.


Rich.



It is the same discussion about Firefox that is already settled I
think. The JVM code is open source, even free software. The
trademark isn't. Mozilla doesn't allow anyone to call the browser
Firefox without some rules.


Both projects involve heavy-handed enforcement of trademarks, but
don't seem to be the same issue.  (I'll leave this to lawyers to
answer definitely though.)


Red Hat want to run the tests because Java corporate users want
that, so Red Hat does it and at the same time helps to have a more
robust Java ecosystem.


That's nice, and indeed RHEL ships OpenJDK.  The question is about
what we do in Fedora.

Rich.



All this change is about the burden of maintaining so many OpenJDK 
branches as packages in FEdora. Maybe Fedora should stop distributing 
ancient Java versions as one of our missions is to be cutting edge, 
maybe we are still encouraging too many projects to stay running on Java 8.


I am saying this as some that would be affected if Java 8 isn't packaged 
anymore, I still need to develop and test some things with Java 8 
because at work we have some customers still running ancient hardware 
and have been a pain to make them move to modern distributions. So I 
will have to us another universal OpenJDK build (like Temurin)


Maybe Fedora should just package the latest JDK needed for Android 
development and the latest LTS version. An even the Android (11 I think) 
could be skipped because Android Studio includes a build of it. If there 
are packages still requiring old things, help to update them could be 
offered by packagers, or dropped from the distribution.

___
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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-06-01 Thread Robert Marcano via devel


On 6/1/23 3:51 AM, Richard W.M. Jones wrote:

On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote:

This was heavily discussed when we moved to portable build in rpms -
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
Long story short yes, if yo wish to distribute jdk *binary* it have
to pass java compliance suite.


It sounds like the problem is the software isn't really open source
because it has some field of use restrictions.  The best plan would be
to change this upstream, and if that isn't possible then to remove it
from Fedora.

Rich.



It is the same discussion about Firefox that is already settled I think. 
The JVM code is open source, even free software. The trademark isn't. 
Mozilla doesn't allow anyone to call the browser Firefox without some rules.


Red Hat want to run the tests because Java corporate users want that, so 
Red Hat does it and at the same time helps to have a more robust Java 
ecosystem.

___
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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Robert Marcano via devel


On 5/31/23 2:02 PM, Chris Adams wrote:

Once upon a time, Vitaly Zaitsev  said:

All program binaries and program libraries included in Fedora
packages must be built from the source code that is included in
the source package.


So... aside from making an exception in the guidelines, it'd also be
trivial to put the entire "real" source RPM into the "packaged" source
RPM, which would satisfy the letter of the rule.


Only if it builds on the Fedora release, an RPM that is build on EL8 
then repackaged as a Fedora RPM may not build on Fedora (New compiler 
for example) so it should still gets notifications about not building 
from source.




Honestly, that is probably the way it should be done anyway, as
otherwise the public mirrors would not have the source code, unless the
JDKs are packaged like shim (with shim-unsigned-x64 and
shim-unsigned-aarch64 SRPMs along side the shim SRPM with the signed
binaries).


___
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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Robert Marcano via devel


On 5/31/23 9:44 AM, Gerd Hoffmann wrote:

On Wed, May 31, 2023 at 03:32:09PM +0200, Vitaly Zaitsev via devel wrote:

On 31/05/2023 14:53, Jiri Vanek wrote:

It is built from sources of course!
What make you think it is not?
For double ensurenes, see the fesco ticket in proposal.


IMO, repackaging prebuilt RPM packages is not building from sources.


The prebuilt RPMs are compiled on Fedora infrastructure too, so I don't
see how that violates the 'build from source' requirement.

We do similar things in other cases, see for example shim-unsigned.rpm +
shim.rpm


Will user be able to download SRPMS like

  dnf download --source java...

and get a real source RPM that can be rebuilt or the SRPM will have a 
prebuilt tarball and the user will need to hunt down the real SRPM, and 
do things like using a VM or container to built that, for later rebuild 
the "binray" SRPM from the Fedora repos?




take care,
   Gerd

___
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: It’s time to transform the Fedora devel list into something new

2023-04-21 Thread Robert Marcano via devel

On 4/21/23 8:17 AM, Robert Marcano wrote:

On 4/20/23 5:20 PM, Matthew Miller wrote:

It’s time to transform the Fedora devel list into something new
===

As someone that read this list 99% ot the time and 1% for replying, I 
have no problem with having a web based forum for discussions, but that 
kind of software if always awful for my kind of usage.

I like the mailing list methos because I get all the threads and I see 
what I wish to read in order to be informed of the general direction of 
the project and ignore the ones I don't want to, with a simple 
responsive UI, that even works when I am offline.

I know that there are people that love web based forums (I don't), but 
in order to not leave people behind with a lot of experience in the 
project, for new ones, maybe instead of only proposing a change, maybe 
proposing a change with good email integration is better.

Discourse default email integration is bad IMHO. The model I wish to 
have with email integration are the tools that were installed for the 
OpenJDK - GitHub integration. in that mailing list, you never notice you 
are reading a bunch of emails that comes from GitHub comments and I can 
pretty much read the entire discussions from my email client, without 
ever using a web browser.

On 4/20/23 5:20 PM, Matthew Miller wrote:
> That said, it is web-first software. (Or mobile, if that’s your thing.)
> That requires some adjustment, I know. I hope opening up a Fedora
> Discussion tab – or keeping one open — becomes an easy habit.

I forgot to add. Discourse is worse for mobile users, the "app" was just 
an embedded web browser, the only thing efficient it did was to get a 
notification and remembering your session, everything else is worse that 
writing an email on a email client for phones.

___
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: It’s time to transform the Fedora devel list into something new

2023-04-21 Thread Robert Marcano via devel


On 4/20/23 5:20 PM, Matthew Miller wrote:


It’s time to transform the Fedora devel list into something new
===




As someone that read this list 99% ot the time and 1% for replying, I 
have no problem with having a web based forum for discussions, but that 
kind of software if always awful for my kind of usage.


I like the mailing list methos because I get all the threads and I see 
what I wish to read in order to be informed of the general direction of 
the project and ignore the ones I don't want to, with a simple 
responsive UI, that even works when I am offline.


I know that there are people that love web based forums (I don't), but 
in order to not leave people behind with a lot of experience in the 
project, for new ones, maybe instead of only proposing a change, maybe 
proposing a change with good email integration is better.


Discourse default email integration is bad IMHO. The model I wish to 
have with email integration are the tools that were installed for the 
OpenJDK - GitHub integration. in that mailing list, you never notice you 
are reading a bunch of emails that comes from GitHub comments and I can 
pretty much read the entire discussions from my email client, without 
ever using a web browser.

___
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: Proposal: drop delta rpms (for real this time)

2023-02-24 Thread Robert Marcano via devel


On 2/24/23 12:35 PM, Gordon Messmer wrote:

On 2023-02-24 07:42, Robert Marcano via devel wrote:
Does DNF on RHEL for example do something different when --security is 
involved? Because the RHEL documentation talks about it as a feature 
to use. Is a lack of metadata for previous updates the problem or the 
implementation? 



I don't have the log, but I checked this about a month ago:

I can set up an 8.3 system (I used a UBI container, to be specific) and 
subscribe to Red Hat's repositories. Since 8.3, there has been a 
security update to bash, but the most recent bash package is not a 
security fix. If I run |dnf update --security bash|, the system will 
offer the most recent bash package, even though it is not a security 
fix. Naturally, if I run |dnf update bash|, I get the same offer.


So on RHEL, dnf will evidently offer to update a package to the current 
version if any of the available update candidates are marked as a 
security update.  And there are multiple update candidates in RHEL 
repositories, as well as CentOS Stream repositories, unlike Fedora.


Thanks for testing it. So, if there is a desire to "fix" this in Fedora, 
having the repository includes the latest package marked as a security 
update and the latest one. I am not sure that will solve much because it 
still depends, as other posts said, Fedora has more open rules for 
updates, than enterprise distributions and therea are entire version 
jumps without tracking errata metadata.


So, from my point of view the biggest problem with "dnf update 
--security" on Fedora is that rpm doesn't track minor-version 
dependencies of libraries without versioned symbols, which means that 
"dnf update --security" can easily break the system by updating a leaf 
package but not updating dependencies that have added new interfaces 
that it requires.  (But I'm working on fixing that.)

___
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: Proposal: drop delta rpms (for real this time)

2023-02-24 Thread Robert Marcano via devel


On 2/24/23 12:01 PM, Chris Adams wrote:

Once upon a time, Robert Marcano via devel  said:

Does DNF on RHEL for example do something different when --security
is involved? Because the RHEL documentation talks about it as a
feature to use. Is a lack of metadata for previous updates the
problem or the implementation?


Just a guess, but... updates in RHEL are different from updates in
Fedora because of policy.  In RHEL, updates outside of a point release
are much more targeted - mostly security and significant bug fixes.
Since there are fewer updates, the security updates stick around for a
while and stand out more.

In Fedora, essentially anything can be updated at any time for any
reason, whenever the packager(s) want.  It could be a minor bugfix, a
new upstream release, etc.  So the update "churn" tends to be higher.
There could be a security update today to a package (maybe just by
applying a quick patch), and then maybe upstream incorporates the patch
next week (along with other changes) and the Fedora packager updates to
that release.  From the Fedora point of view, the second new package is
not addressing any security issue, because the first new package did.

Neither are wrong, they're just different polices.


Right, but does a security update replaced by a non security update will 
hide the first security update on RHEL like happens on Fedora?


Because if the problem is how DNF process --security and not how Fedora 
and RHEL push security updates metadata, The Red Hat documenting how to 
use dnf-automatic to only install security updates is probably not at 
all secure. Just wondering where is the problem, metadata or implementation.

___
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: Proposal: drop delta rpms (for real this time)

2023-02-24 Thread Robert Marcano via devel

On 2/23/23 8:24 PM, Dennis Gilmore via devel wrote:

On Tue, Feb 21, 2023 at 2:48 PM Matthew Miller > wrote:

I was asked to weigh in on https://pagure.io/releng/issue/7215
as a
priority. Last time we talked about this we didn't really get
anywhere...

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E

... and that ticket hasn't moved, because fixing it isn't trivial.

What we're doing now — as has been the case for several years,
already noted
in the previous discussion — has very little end-user value. Also as
noted
in that thread (as in the ticket)... that's unfortunate, because it did
bring some real benefits (and could possibly do even more.)

But, I think it's time to move on. We have ostree and various
container-delta approaches. We should focus on those — and give
DeltaRPMs a
sad, fond farewell.

The last updates just now on three different machines gave me
Delta RPMs reduced 284.9 MB of updates to 281.0 MB (1.4% saved)
Delta RPMs reduced 14.3 MB of updates to 3.3 MB (76.9% saved)
and the third had no Delta RPMs

Outside of specific instances, the first or last results are typical. I
think it is time to say goodbye. Times are very different from what they
were when we added support.

Results may be better for applications that require a lot of data
outside the projects binaries, like games related packages as
wesnoth-data, built from the wesnoth main spec file, but not
xonotic-data (1.1G) that is a split from the binaries spec files.

Disabling deltarpms may not change much for a lot of people, but it may
affect a few ones using these games. maybe packagers will be forces to
split their data to different specs, how easy it is depends on the build
process of those games.

Dennis

___
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: Proposal: drop delta rpms (for real this time)

2023-02-24 Thread Robert Marcano via devel


On 2/23/23 8:04 PM, Michael Catanzaro wrote:
On Fri, Feb 24 2023 at 12:00:40 AM +0100, Björn Persson 
 wrote:

There are also other dangers with installing only security fixes. If a
bugfix is released and packaged, and later it's discovered that the bug
had security implications, then no security update will be made because
the fix is already packaged. It might be possible to set a security
flag on the update after the fact, but nobody will bother with that.

I would therefore advise against using --security. If one can't install
all the updates continuously, then one should use a more stable
distribution than Fedora.


tbh I'd go so far as to propose that this functionality should not be 
reimplemented in dnf5 at all.




Does DNF on RHEL for example do something different when --security is 
involved? Because the RHEL documentation talks about it as a feature to 
use. Is a lack of metadata for previous updates the problem or the 
implementation?



___
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: Retiring Bottles in favor of Flatpak provided by upstream

2023-01-26 Thread Robert Marcano via devel

On 1/26/23 8:42 AM, Jiri Eischmann wrote:

Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100:

Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a):

On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch
wrote:

I am not user of Bottles so I won't complain about this
particular case,
but the push towards (upstream) Flatpaks is unfortunate :/

Can you elaborate on why you feel that way?

I don't trust upstream Flatpacks. I don't trust they follow any
standard
except standard of their authors.

I maintain both packages in Fedora and flatpaks on Flathub, so I can
compare. The review to get an app to Flathub was as thorough as Fedora
package review. In some ways even stricter. It's not like "it builds,
it runs, you're good to go". They care about some standards, about
builds being verifiable etc.

That doesn't seems to be enforced because many builds scripts just
download binaries built by other projects, for example;

https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89

Note: building the entire pandoc and TeX toolchain is very hard and I
understand this example packager decision, but It doesn't make more
trustful that version that one on Fedora.

The Flathub CI seems to be more extensive than what we have in Fedora.

And I don't like Flatpacks, because their main advantage (their
isolation) is also their biggest disadvantage. There can't be both
without making compromises. If I am not mistaken, the isolation is
also
mostly myth, because it is disabled in most cases.

Why? Apps come with permissions they require (which you can override
btw). Just because some apps require access to your whole filesystem
doesn't mean the isolation is a myth. You know the permissions, you may
decide not to use such an app. None of the flatpaks maintained by me
require this kind of access and are well isolated.

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

Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)

2023-01-18 Thread Robert Marcano via devel


On 1/18/23 2:46 PM, Robert Marcano wrote:

On 1/17/23 8:19 AM, Zdenek Dohnal wrote:
Well in a matter of speaking this is doable even without IPP-USB 
advertised device. Every application can just send data to printer's 
port and IP or get USB interface handler and talk with the device via 
USB. Even an application which implements IPP client can omit CUPS and 
talk with IPP printer directly. In cases where application generates a 
printer ready file (f.e. in PCL format) which have all user's option 
applied already is desired to bypass CUPS and talk with the printer - 
I've heard there are such applications already bypassing CUPS, because 
they want to pass such a file.


So it is not something uncommon in my opinion.


Forgot to add this:

USB device access can be protected with filesystems permissions, so it 
is possible to protect direct access if some installation requires it. 
Way easier than firewall rules IMHO.

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

Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)

2023-01-18 Thread Robert Marcano via devel

On 1/17/23 8:19 AM, Zdenek Dohnal wrote:

Hi Robert,

On 1/13/23 15:12, Robert Marcano via devel wrote:
Nothing against driverless printing, this is something I really like,
bit I think all the move to HTTP is ignoring the feature that is being
removed, and that I have an use for. There is not possible to have a
printer connected to a computer that can't be restricted by CUPS to be
used by only a few authorized users. The admin can implement CUPS
authentication but an ipp://localhost:6 open port entirely open to
anyone on the local machine to submit print jobs directly bypassing CUPS.

Well in a matter of speaking this is doable even without IPP-USB
advertised device. Every application can just send data to printer's
port and IP or get USB interface handler and talk with the device via
USB. Even an application which implements IPP client can omit CUPS and
talk with IPP printer directly. In cases where application generates a
printer ready file (f.e. in PCL format) which have all user's option
applied already is desired to bypass CUPS and talk with the printer -
I've heard there are such applications already bypassing CUPS, because
they want to pass such a file.

So it is not something uncommon in my opinion.

There are many other reasons to disallow direct access to the printer
application, like wanting to do printing accounting with CUPS, for
example.
If an application uses CUPS API, the communication will go via CUPS
daemon (CUPS Local daemon in CUPS 3.x) which will do a printing
accounting (in CUPS 3.x it will be in CUPS sharing daemon). We can't
forbid the application to bypass CUPS if it is its developer's will, as
we can't now.

Unless every printer application support some kind of authentication
mechanism over their HTTP server, controlling direct access to the
printers is not possible. Do ipp-usb support at least basic
authentication so a permanent queue could be setup with these
credentials?

IPP-USB currently does not provide authentication functionality AFAIK
and how it looks from the code, but I've asked upstream. According
IPP-USB man page you can turn off mDNS advertising to don't share the
port existence on your localhost, or probably create a firewall rule
Chris mentioned. The ticket is here
https://github.com/OpenPrinting/ipp-usb/issues/61

Commented there, thanks.

Note: I really wish CUPS supported some kind of IPP over Unix domain
sockets so file system restrictions could be used to control access to
locally installed printer applications, but the last time I mentioned
that on a CUPS issue, sadly it was plainly rejected.

Do you have a link to the ticket? AFAIK Unix domain socket is one of the
features which is planned for CUPS 3.x, but it might not be the one you
mean.

It was all before the OpenPrinting fork, beware, hidden inside the Load
More (comments) actions:

https://github.com/apple/cups/issues/5271#issuecomment-630905653

https://github.com/apple/cups/issues/5271#issuecomment-630929217

Notice I wanted Unix domain socket support because of another use case.
Application provided virtual printer, I mean, an application running on
the user session being able to function as a printer to receive a
document for archival purposes.

Currently with printer driver, the print output is redirected from CUPS
to the application on the user session, with proper identification of
the user that requested the virtual print operation.

With everything moved to HTTP, the virtual printer being run on the user
session is now open to documents being printed by everyone and no way to
identify the originating connection uid. The originating connection can
be obtained for Unix sockets on Linux, so identifying it comes from CUPS
then the printer applications can now trust the information sent via IPP
about the user that is printing.

Zdenek

[https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_install_a_permanent_print_queue
here] is the manual. However if mDNS is enabled, the virtual device
shared by `ipp-usb` can be automatically picked up by other services
(as `cups` or `sane-airscan`), so no further configuration is required
to get the device installed. The feature is called ''temporary queue''
in CUPS and it is supported in applications using the up-to-date CUPS
API or toolkits using up-to-date CUPS API - f.e. GTK3+ based
applications, Libreoffice and Firefox. The fax functionality is
available at URI `ipp://localhost:6/ipp/faxout`, but the automatic
installation doesn't work for it and it has to be installed manually.

As mentioned above, the `ipp-usb` daemon claims the USB interface of
the device which supports IPP over USB standard. This behavior
conflicts with the previous driver approach, where the discovery
mechanism only scans USB ports for available devices, but doesn't try
to claim the USB interface, which is unavailable because `ipp-usb` has
claimed it already. The result is the device

Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)

2023-01-14 Thread Robert Marcano via devel


On 1/13/23 8:53 PM, Chris Adams wrote:

Once upon a time, Robert Marcano  said:

Nothing against driverless printing, this is something I really
like, bit I think all the move to HTTP is ignoring the feature that
is being removed, and that I have an use for. There is not possible
to have a printer connected to a computer that can't be restricted
by CUPS to be used by only a few authorized users. The admin can
implement CUPS authentication but an ipp://localhost:6 open port
entirely open to anyone on the local machine to submit print jobs
directly bypassing CUPS.


I haven't tried it with firewalld or the newer nftables, but old
iptables could set rules based on user ID.  I'd expect nftables also
implemented that, and firewalld could handle it in some fashion
(possibly a rich rule).  With that, you could limit HTTP access to root
(I think cups runs as root).



Sounds like an ugly workaround, but betther than nothing. Looks possible 
with nftables, it can even be possible to match the CUPS cgroup. But 
there isn't anything for UID or cgroups on firewalld rich language syntax.

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

Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)

2023-01-13 Thread Robert Marcano via devel

On 1/12/23 1:15 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/IPPUSBasPrintScanDependency

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Add `ipp-usb` as a weak dependency of packages which provide support
for driverless printing (`cups`), driverless scanning (`sane-airscan`)
and driverless fax for USB devices capable of using driverless
functionality (how to find out whether your USB device is driverless
[https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_find_out_if_my_usb_device_supports_ipp_over_usb
here]), so such devices will work without a specific driver. `ipp-usb`
design conflicts with the way how drivers work with the device, so a
user intervention is required after upgrade.

== Owner ==
* Name: [[User:Zdohnal | Zdenek Dohnal]]
* Email: zdoh...@redhat.com

== Detailed Description ==
Nowadays most printers and scanners from common vendors provide a way
how to work without a specific driver. This way relies on driverless
standards implemented in device's firmware and their support in the
operating system user has. At first (in 2010) network driverless
standards were implemented in devices and widely spread, such as
AirPrint, [https://www.pwg.org/ipp/everywhere.html IPP Everywhere] for
printers or eSCL (sometimes called AirScan) and WSD (Windows Service
Discovery) for scanners. Those network driverless standards and others
are already supported in `cups` (for printing) and `sane-airscan`
packages. Two years later USB devices got their own driverless
standard -
[https://robots.org.uk/IPPOverUSB?action=AttachFile=view=IPP+USB+Specification.pdf
IPP over USB] - which is now implemented by `ipp-usb`. The package
itself has been in Fedora for more than two years available for users
to opt-in USB driverless support.

The `ipp-usb` package contains `ipp-usb` daemon, which works as an
HTTP proxy over the claimed USB devices, provides printing (via
[http://ftp.pwg.org/pub/pwg/standards/std-ipp20-20151030-5100.12.pdf
IPP 2.0+] protocol), scanning (via eSCL) and fax (via
[http://ftp.pwg.org/pub/pwg/candidates/cs-ippfaxout10-20140618-5100.15.pdf
IPP Faxout]) support and advertises them on localhost by mDNS
protocol. mDNS is the key feature for automatic discovery, but it is
not required to use it - the virtual printer device provided by
`ipp-usb` can be accessed at URI `ipp://localhost:6/ipp/print` and
the URI can be used for permanent queue installation -

Nothing against driverless printing, this is something I really like,
bit I think all the move to HTTP is ignoring the feature that is being
removed, and that I have an use for. There is not possible to have a
printer connected to a computer that can't be restricted by CUPS to be
used by only a few authorized users. The admin can implement CUPS
authentication but an ipp://localhost:6 open port entirely open to
anyone on the local machine to submit print jobs directly bypassing CUPS.

There are many other reasons to disallow direct access to the printer
application, like wanting to do printing accounting with CUPS, for example.

Fedora 37 slow applications startup, maybe GTK4 / libadwaita???

2022-11-19 Thread Robert Marcano via devel

I have been experiencing slow applications startup on previous Fedora 
releases, but it was GNOME Settings and it wasn't something I opened too 
much, didn't dedicate too much time to investigate. I always thought it 
was some lack of optimizations on GTK4 or libadwaita since these were 
pretty new.


Now on Fedora 37 that GNOME Files (Nautilus) is having the same issues 
like taking 3 or more seconds to show a window when the Nautilus service 
isn't still running, I decided to run an strace. I found some delays 
when starting up related to access to sysfs PCI devices files, more 
frequently with:


openat(AT_FDCWD, "/sys/bus/pci/devices/:05:02.0/config", O_RDONLY) = 25

That device is Thunderbolt related, sometimes it is another one, but 
this one is the most frequent. Any ideas why this is happening? or 
anyone one about a bug report for something like this?.

___
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: Why install rsyslog by default?

2022-08-25 Thread Robert Marcano via devel


On 8/25/22 11:02 AM, Barry Scott wrote:

I just found that rsyslog is installed and by default creating legacy
log files in /var/log like messages and secure.

Now that journald has been in Fedora for so long this is useful
default to install rsyslog?



I don't have it installed. I think it is usually Chrome RPM (not 
Chromium) that bring a lot of awful dependencies because it requires 
some legacy lsb packages.


Last time I installed it even pulled perl packages.


Barry
___
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: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

2022-07-01 Thread Robert Marcano via devel


On 7/1/22 8:02 AM, Colin Walters wrote:



On Thu, Jun 30, 2022, at 10:23 AM, Michael Catanzaro wrote:


Regardless, Fedora will still be RPM-based no matter what. ;) Even if
our future is OS images composed of RPMs plus Flatpaks composed by
RPMs, it's still based on RPMs.


I don't think so.  I think RPM is a tool, a technique that can be used where it 
makes sense.  It is not and should not be the center of the universe.  Today in 
Fedora CoreOS we ship a bit of content that comes directly from the 
https://github.com/coreos/fedora-coreos-config git repository without gavina 
been pointlessly put into an RPM first.


It removes a step so it makes it easier, but at the same time remove the 
existence of a copy of the source code (SRPM) in parallel with the binaries.


There is a reason all Fedora RPMs sources are stored on Fedora 
infrastructure instead of automatic downloads from source repositories. 
Imagine an entire Fedora built that way and think about the 
reproducibility of that build. Maybe another process could replace it, 
but going directly to source repositories is a step backwards.




Building an intermediate RPM for content that is *only* intended to be run as a 
container is just awkward and strange.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Live USB rescue mode, do we still have one? Does it work?

2022-05-27 Thread Robert Marcano via devel


On 5/27/22 12:52 PM, Brian C. Lane wrote:

On Fri, May 27, 2022 at 09:38:43AM -0400, Stephen Snow wrote:

On Wed, 2022-05-25 at 14:02 -0700, Adam Williamson wrote:


The rescue mode has always been on the traditional installer images,
not the lives. It's still there.


Unfortunately there is no rescue option on the Fedora Linux Workstation
installer just the Server and the Everything.
Is this a part of Anaconda or a different package in Fedora Linux?


Rescue is an Anaconda feature:

https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/rescue.py

https://github.com/rhinstaller/anaconda/blob/master/docs/rescue.rst

It is not supported on live media since most of the steps just don't
make sense -- live already sets up the network and you should be able to
use the regular desktop tools to mount your existing partitions.

https://github.com/rhinstaller/anaconda/blob/master/data/liveinst/liveinst#L93


True, but the Live image needs something like a command like 
"fedora-prepare-rescue-image" or something like that that just do what 
the Fedora rescue option do and mount what it can find on /mnt/sysimage.


The steps to mount a complete /mnt/sysimage are a more than a few and it 
could help a lot not needing to type many things that an untrained 
person could make a big mistake.




Brian


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-07 Thread Robert Marcano via devel


On 4/7/22 10:28 AM, Lennart Poettering wrote:

On Di, 05.04.22 17:38, Chris Murphy (li...@colorremedies.com) wrote:


When users have a suboptimal experience by default, it makes Fedora
look bad. We can't have security concerns overriding all other
concerns. But it's really pernicious to simultaneously say security is
important, but we're also not going to sign proprietary drivers. This
highly incentivizes the user to disable Secure Boot because that's so
much easier than users signing kernel modules and enrolling keys with
the firmware, and therefore makes the user *less safe*.


Let me stress one thing though: Fedora *has* *no* working SecureBoot
implementation. The initrd is not authenticated. It has no signatures,
nothing.



Couldn't the other Fedora change about adding file signatures to the RPM 
installed files be used to close this hole?. Enabling some policy at 
boot that disallows execution on code not signed that is inside the 
initrd. I think all code copied to the initrd must come from Fedora 
packages, maybe the only exception are third party kernel modules.


Note: It appears cpio doesn't support extended attributes [1]

[1] https://bugzilla.redhat.com/show_bug.cgi?id=771926



By disabling SecureBoot you effectively lose exactly nothing in terms
of security right now.

What good is a trusted boot loader or kernel if it then goes on
loading an initrd that is not authenticated, super easy to modify (I
mean, seriously, any idiot script kiddie can unpack a cpio, add some
shell script and pack it up again, replacing the original one) – and
it's the component that actually reads your FDE LUKS password.

I mean, let's not pretend unsigned drivers were a big issue for
security right now. They are now, we have much much much wider gaping
holes in our stack.

Lennart

--
Lennart Poettering, Berlin
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RFI/RFC: Fedora Linux graphical recovery environment

2022-04-06 Thread Robert Marcano via devel


On 4/5/22 11:11 AM, Neal Gompa wrote:

On Tue, Apr 5, 2022 at 10:47 AM stan via devel
 wrote:


On Mon, 4 Apr 2022 15:58:14 -0500
Gregory Bartholomew  wrote:


Of topic but related: I wish there was supported option to remove
the current rescue kernel,


Is echo "dracut_rescue_image=no" > /etc/dracut.conf.d/rescue.conf not
sufficient?


That is an interesting option.  It isn't documented in man dracut.conf.
Is it new?  I just manually remove the rescue vmlinuz and initramfs and
then run
/usr/lib/kernel/install.d/51-dracut-rescue.install add $(uname -r) "" 
/lib/modules/$(uname -r)/vmlinuz
in the /boot directory to build a new rescue kernel from the currently
running kernel.  Is there an option to do that also?  i.e. I invoke
dracut from the command line and it automatically does all that if a
rescue_build.conf file is present in /etc/dracut.conf.d/


You could also just remove the "dracut-config-rescue" package from your system.



And this is the magic bit. Thanks.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-06 Thread Robert Marcano via devel


On 4/5/22 10:52 AM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS


...

It is inevitable that legacy BIOS will be removed in a future release.
To ease this transition as best we can, there will be a period (of at
least one Fedora release) where it will be possible to boot using the
legacy BIOS codepaths, but new installations will not be possible.
While it would be easier for us to cut support off today, our hope is
that this compromise position will make for a smoother transition.
Additional support with issues during the transition would be
appreciated.



Many people have already commented on having active and usable computers 
only supporting BIOS and not UEFI. You can count me on that list too. 
but I will really appreciate a clarification.


Is this change only related to install media support for booting with 
BIOS only? Would I be able to install newer Fedora releases using Legacy 
PXE on BIOS only machines?

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RFI/RFC: Fedora Linux graphical recovery environment

2022-04-04 Thread Robert Marcano via devel


On 3/31/22 5:38 PM, Neal Gompa wrote:

Hey all,

Earlier this week, the Fedora Workstation WG discussed a ticket
brought to us asking for a GUI-based rescue/recovery environment[1].
While we all agreed in principle that such a thing would be a very
good thing to have, we don't really know how to achieve such a thing.
Additionally, we're not really sure what the scope of things should be
provided in said recovery environment and what kind of things people
would expect to be able to fix in there.

So I come to y'all to ask about this and give us some feedback on the
idea, how to do it, and what kinds of things you expect people to need
a recovery environment for.

[1]: https://pagure.io/fedora-workstation/issue/288

I am not sure about having a full graphics environment, but it would be 
nice to have the functionality of the server installers rescue mode, 
where the system try to create a system tree at /mnt/sysimage IIRC and 
allows you to run `chroot /mnt/sysimage` to enter it.


This is the most basic functionality I would like to have on a rescue 
image. This allow someone to try to fix a badly modified or updated 
file. Some people would like to have network connectivity from the CLI 
at least.


And at the same time to have an option to not have this rescue menu 
option on the boot menu, like if I remove something like the package 
fedora-rescue or something like that, it isn't present on the menu.


Of topic but related: I wish there was supported option to remove the 
current rescue kernel, and hopefully a way to automate old kernels 
removals when the latest kernel is successfully installed and confirmed 
working. On company managed workstations I have a timer that checks the 
install date of the latest installed kernel and after a few days it 
removes the old kernels (if the users haven't complained for days, we 
assume the kernel is right). This is to avoid users reverting to older 
kernels in order to use some privilege escalation vulnerability.

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)

2021-12-29 Thread Robert Marcano via devel


On 12/29/21 2:20 PM, Neal Gompa wrote:

On Wed, Dec 29, 2021 at 12:27 PM Artem Tim  wrote:


Cantarell current default UI font in GNOME (Workstation) will be replaced by 
Noto font as well or remain?


The current plan is to keep Cantarell for now, though GNOME upstream
may decide to switch to Noto as KDE Plasma did years ago.



Does Noto have the default font-variant-numeric as tabular-nums? (non 
proportional decimal digits) because it will be a welcomed change.


The current default of Cantarell makes any number showing application a 
pain to style, specially on toolkits that use the system font but are 
unable to change font variants (Java Swing with GTK Look and Feel).


Even GNOME applications aren't properly styled for number entry use 
cases. See for example Calculator where 111,111,111 looks like a smaller 
number than 99,999,999 when the are one on top of the other, because the 
font is proportional by default.

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)

2021-12-29 Thread Robert Marcano via devel


On 12/29/21 6:38 PM, Elliott Sales de Andrade wrote:

On Wed, 29 Dec 2021 at 10:02, Ben Cotton  wrote:


https://fedoraproject.org/wiki/Changes/Hunspell_dictionary_dir_change

== Summary ==
Update Hunspell Dictionary system directory from /usr/share/myspell/
to /usr/share/hunspell/

== Owner ==
* Name: [[User:vishalvvr| Vishal Vijayraghavan]]
* Email: 


== Detailed Description ==
In most of Linux distributions the standard Hunspell dictionary path
is `/usr/share/hunspell/` but in Fedora still has
`/usr/share/myspell/`. This effort is to follow default standard to
install all Hunspell dictionary into `/usr/share/hunspell/` instead of
`/usr/share/myspell/`.


== Benefit to Fedora ==
This will future proof Fedora to use the correct current location for
hunspell spelling dictionaries.

== Scope ==
* Proposal owners:
In total there are `135` packages which is to be updated. libreoffice
& Firefox are the two main applications and rest are mostly language
dictionary packages.

* Other developers:

* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==


== How To Test ==
1. Check if default installed dictionary path is
`/usr/share/hunspell/` instead of `/usr/share/myspell/`

`$ hunspell -D` or `$ ls /usr/share/hunspell/`

2. Install any language dictionary and check if it getting installed
into '/usr/share/hunspell/'

`$ dnf install hunspell-hi`

`$ hunspell -D`



If, as mentioned above, this will possibly affect applications such as
Firefox and LibreOffice, then those should also be tested as well.


and Thunderbird. I came here to say this too but you won. I remember a 
few releases back a change like that broke dictionaries in Firefox and 
Thunderbird, the workaround and the patch later applied was to change 
some internal preference that pointed to the local installed dictionaries.






== User Experience ==
User should not notice any difference: their applications should
continue to work as expected after this directory migration.

== Dependencies ==


== Contingency Plan ==

* Contingency mechanism: revert release back to /usr/share/myspell
* Contingency deadline: Beta
* Blocks release? No

--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora  Java: The Death of Two SIGs

2021-09-28 Thread Robert Marcano via devel


On 9/27/21 7:54 PM, Kevin Kofler via devel wrote:

Robert Marcano via devel wrote:

I think the only way the Java ecosystem to survive in Fedora outside of
OpenJDK and some core components is to allow bundling (Even JavaScript
bundling is already allowed), but how do to it without compromising
security?


The problem is that Java projects typically bundle prebuilt binaries, which
is a complete no go. The big issue is not that the libraries are bundled, it
is that they are bundled in prebuilt binary form, often even without the
source code at all.


Even in the case of SCM repositories committed binaries, allowing 
bundling would help a lot, add some kind of automation that replace 
these jar for the proposed local created maven repository, and link to 
them, and add the metadata to the RPM to know it need to be rebuilt when 
that dependency is updated. This is a lot more easier than fighting old 
build scripts that don't use some kind of dependency manager. It will 
probably be hard for these kind of packages, but any modern application 
using using a modern build system could become easier to package.




Fixing this requires work no matter whether the packager works the way you
propose or whether they simply unbundle the dependencies. So I do not see
any valid reason to not just go ahead and unbundle. (At least for the
typical application. Things like Eclipse plugins, using nested JARs, are the
exception and might indeed need special treatment.)

The Go and Rust case is different because the library packages are shipped
as source code and the application packages then BuildRequire that source
code. Doing the same for Java would require modifying the upstream build
systems even more than just depending on a Fedora-built JAR would (because
the Go/Rust way is not how Java normally works). So I do not see any
advantage in doing things that way. (And for the record, I also think that
Go and Rust should not work that way either! It is possible to build shared
libraries of Go code, at least one Go toolchain supports it.)

The JavaScript case is also different because everything that is bundled is
bundled as source code. JavaScript does not have anything like a compiled
JAR file.

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


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora  Java: The Death of Two SIGs

2021-09-27 Thread Robert Marcano via devel


On 9/26/21 3:20 PM, Fabio Valentini wrote:

Good evening everybody,

Not sure why it's me who's writing this message, but somebody needs to do it.

Community maintenance of Java packages in Fedora is, for all intents
and purposes, dead. Mikolaj keeps a bare minimum of packages working
for the maven toolchain, but that's it. Fedora 35 will ship without
packages for the Eclipse IDE, and none of the Java applications I know
of are still in working order. While I had hoped that setting up a
"new" SIG and gathering members to shore up community maintenance of
the "extended core" Java stack, this effort fizzled out after mere
weeks.

"He's dead, Jim."


I will add my view as someone that use to package a tiny few Java 
packages for Fedora (maily Eclipse plugins). My view may be outdated so 
everyone is free to correct me as always.


I think saying the Java ecosystem isn't friendly to traditional 
packaging could be said for any other modern language Fedora has 
accepted without a fuss. Go and Rust applications has made some of the 
traditional rules of dynamic loaded code having a preference being 
challenged by these "newcomers" that don't support it.


Meanwhile Java packages still are difficult because of the need of 
everything to be split on multiple packages and every jar found being 
replaced by symlinks to files in /usr/java/*. In Eclipse plugins this 
remain more difficult, because plugins al already jars with embeeded 
jars where a custom classloader is able to load things withour having 
everything extracted on the filesystem.


I think the only way the Java ecosystem to survive in Fedora outside of 
OpenJDK and some core components is to allow bundling (Even JavaScript 
bundling is already allowed), but how do to it without compromising 
security?


1. I propose that every package should use a modern Java build system 
that resolve dependencies (Maven, Gradle, Ant+Ivy, etc), If the package 
doesn't have that, a patch should be provided and contributed upstream.


2. We have automation to extract the dependencies required by the main 
package and allow the Fedora build system to automate the creation of 
packages for these dependencies from source and generate for example 
subpackages *-mave or something like that, that provides these 
dependencies as maven repositories locally to be use by other packages.


3. Packages embeede thes libraries like they upstream do, without having 
to patch hundred of build script to use links to /usr/java.


4. Automate that dependencies updates should trigger dependent packages 
rebuild


This as dependent Jar files as "source code" like Rust and Go are 
currently packages.


Without a process simplification for the packages like this one, or 
something better. The Java applications ecosystem being packaged on 
Fedora will not be resurrected.




Now to the reason why I feel the need to beat a dead horse: I wonder
if the @java-maint-sig group should actually continue to exist (or
rather, be maintainer or bugzilla assignee for packages, because I
don't even know if FAS groups can be deleted). It seems that none of
the current members (I am no longer one of them) are active. Bugs,
including security issues with assigned CVE numbers, are collecting
dust. Packages get orphaned and retired one by one because they fail
to build or install.

At this point, I'm still the only person with the password for the
SIG's bugzilla account and the only administrator of the private
mailing list - just because I wouldn't even know who to hand those
things over to (fedora-infra?). There's nobody left, nobody is reading
the mailing lists. Only tumbleweeds are here.

Should the @java-maint-sig group be removed from any packages it is
still associated with? Should it be dissolved, and members be removed?
Should the remaining ruins that used to be packages be orphaned?
Retired? Buried? Forgotten?

I don't know.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Kernel thermal configuration issues in laptop

2021-08-13 Thread Robert Marcano via devel


On 8/11/21 6:31 AM, Iñaki Ucar wrote:

Hi,

This is so annoying. Recently, I've been experimenting
software-initiated shutdowns in my laptop (LG Gram) due to sudden
temperature rises in which the fan doesn't catch up and doesn't reach
maximum speed. In the journal, I see:

   kernel: thermal thermal_zone0: acpitz: critical temperature reached,
shutting down


Adding myself as another example, Running on a ThinkPad Extreme 2nd Gen, 
same shutdown and kernel log


Aug 13 11:07:53 kernel: thermal thermal_zone0: acpitz: critical 
temperature reached, shutting down
Aug 13 11:07:53 kernel: thermal thermal_zone0: acpitz: critical 
temperature reached, shutting down


Never happened before on this laptop running Fedora since I bought it.

thermald is enabled but quits itself with:

[/sys/devices/platform/thinkpad_acpi/dytc_lapmode] present: Thermald 
can't run on this platform


It must be the Lenovo firmware update that now make thermald 
unnecessary, I even used dptfxtract. I didn't notice before that 
thermald was quitting. The firmware now implement some kind of thermal 
control, but the latest firmware was updated many months ago, and that 
Lenovo change is from last year if IIRC.


I wasn't doing anything intensive at the moment, not that I noticed, 
some light text editing.


I will monitor if it happen again.



They happen as follows. When the laptop is still cool (e.g., recently
powered up), if I launch some compilation task, which is quite CPU
demanding, then the temperature rises quickly and I hear that the CPU
fan speeds up too slowly, so slowly that the critical temperature is
reached and the laptop shuts down. However, if the laptop was already
medium-hot due to other tasks, then the CPU fan catches up and reaches
maximum speed quickly, so the temperature is controlled.

This wasn't happening before, and I'm guessing that maybe some default
kernel thermal parameters have changed recently? (This is replicable
at least with all the kernels currently installed: 5.13.4, 5.13.5,
5.13.8). I see that the thermal policy is step_wise in some thermal
zones, and user_space in others (there are 8). I'll be happy to
provide more info if anyone has any clue on how to debug and/or fix
this.

Regards,
--
Iñaki Úcar
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)

2021-07-09 Thread Robert Marcano via devel


On 7/9/21 11:45 AM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Sqlite_SHA-1

== Summary ==
Removal of deprecated crypto algorithm SHA-1 from sqlite.

== Owner ==
* Name: [[User:odubaj| Ondrej Dubaj]]
* Email: odu...@redhat.com


== Detailed Description ==
The use of SHA-1 is no longer permitted for Digital Signatures or
authentication in RHEL-9. Due to this reason, there is a need to
remove SHA-1 extension from sqlite in RHEL-9 and therefore also
Fedora. The removal of the extension was discussed with sqlite
upstream development, who confirmed, that it is safe to remove it and
should not impact other functionality of sqlite.


== Benefit to Fedora ==
This change brings update in terms of removing usage of deprecated
crypto algorithms as users should not use them. Also it keeps Fedora
project up-to-date with the newest RHEL release, what is beneficial
for future releases.


Why is this a remove proposal and not a default disabling via crypto 
policies. Will RHEL-9 remove SHA1 code from Java and other developer 
tools too instead of the current default disabled?




== Scope ==
* Proposal owners:
** Prepare patch for removing SHA-1 algorithm from sqlite
** Discuss the possible issues with upstream
** Push the changes to Fedora

* Other developers:  Do not use SHA-1 algorithm in sqlite

* Release engineering: No further coordination is required for this change

* Policies and guidelines: No guidelines need to be updated according
to this change
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
SHA-1 algorithm will not be supported in sqlite. Instead SHA-3
algorithm can be used.

== How To Test ==
No special testing is required for this change.

== User Experience ==
Users won't be able to use SHA-1 algorithm with sqlite. Instead, they
can use SHA-3 algorithm, or any other supported algorithm.

== Dependencies ==


== Contingency Plan ==

* Contingency mechanism: moving this change to Fedora 36, if not
successfully finished until Fedora 35 branching from Rawhide
* Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
* Blocks release? No

== Documentation ==
Sqlite documentation: https://www.sqlite.org/docs.html

Discussion with upstream about removing SHA-1 algorithm:
https://sqlite.org/forum/forumpost/de1c4a92f3





___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: When is pappl going to be good enough to replace cups?

2021-05-26 Thread Robert Marcano via devel


On 5/26/21 7:05 AM, Zdenek Dohnal wrote:

Hi Robert,

On 5/24/21 2:39 PM, Robert Marcano via devel wrote:

On 5/24/21 3:29 AM, Zdenek Dohnal wrote:


Devices which currently depend on a deprecated functionality -
printer drivers and raw queues - will need a printer application once
the deprecated functionality is removed from CUPS. This application
will advertise the device on localhost via MDNS protocol and will
communicate with CUPS via IPP, both public well-known protocols. The
only place where the data can turn into proprietary is filtering, but
it's the same with printer drivers.

--


Greetings, Is there any plan to support these IPP printer applications
over Unix domain sockets?


pappl supports listening on domain sockets (IIUC the docs
https://www.msweet.org/pappl/pappl.html), so if a printer application
decides on it will use domain sockets, it is possible.


Thanks for the information. Last time I saw some reluctance from CUPS 
maintainers (before the fork) to add domain sockets support for IPP, 
that was the reason I asked. If pappl can do it now I presume CUPS will 
be able to use these printers.






I manage a virtual printer that uses CUPS filters and backends to
capture documents to an application database. We have been using CUPS
authentication features to control who can use the printer, and not to
have to reimplement authentication on the filter and backends. With
network bound IPP applications, anyone on the same multiuser machine
would be able to bypass CUPS and send documents directly unless I
duplicate CUPS authentication functionality. Unix sockets would help
with that,
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure



___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: When is pappl going to be good enough to replace cups?

2021-05-24 Thread Robert Marcano via devel


On 5/24/21 3:29 AM, Zdenek Dohnal wrote:


Devices which currently depend on a deprecated functionality - printer 
drivers and raw queues - will need a printer application once the 
deprecated functionality is removed from CUPS. This application will 
advertise the device on localhost via MDNS protocol and will communicate 
with CUPS via IPP, both public well-known protocols. The only place 
where the data can turn into proprietary is filtering, but it's the same 
with printer drivers.


--


Greetings, Is there any plan to support these IPP printer applications 
over Unix domain sockets?


I manage a virtual printer that uses CUPS filters and backends to 
capture documents to an application database. We have been using CUPS 
authentication features to control who can use the printer, and not to 
have to reimplement authentication on the filter and backends. With 
network bound IPP applications, anyone on the same multiuser machine 
would be able to bypass CUPS and send documents directly unless I 
duplicate CUPS authentication functionality. Unix sockets would help 
with that,

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: GNOME only: KeepassXC quirks

2021-04-30 Thread Robert Marcano via devel


On 4/30/21 8:17 AM, Germano Massullo wrote:

Il 30/04/21 14:11, Robert Marcano via devel ha scritto:

The bug about input fields not able to take text input happen
occasionally on passwords fields on XCA.


What is XCA?


Another Fedora package that uses QT

https://hohnstaedt.de/xca/



___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: GNOME only: KeepassXC quirks

2021-04-30 Thread Robert Marcano via devel


On 4/30/21 6:23 AM, Germano Massullo wrote:

KeepassXC comaintainer here.

There are many Fedora GNOME Wayland users experiencing quirks in using 
KeepassXC. Textboxes not showing text that is being written, other 
quirks with GNOME, etc.


Upstream developers said many times that this only happen with Fedora users.

Myself I do use KDE Spin and I do not experience these issues (tested on 
Wayland too)


I don't paste bugs titles since they are misleading

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

https://bugzilla.redhat.com/show_bug.cgi?id=1941731 (CentOS 8)

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

https://github.com/keepassxreboot/keepassxc/issues/5608

plus others that I cannot find again at the moment

I would like to ask if you have any idea about why this happens on GNOME 
only (and not on other distros too)


Thank you


The bug about input fields not able to take text input happen 
occasionally on passwords fields on XCA. Switching focus to another 
application and coming back usually workarounds the problem.

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

2021-04-23 Thread Robert Marcano via devel


On 4/23/21 12:52 PM, Tom Stellard wrote:

On 4/23/21 9:38 AM, Robert Marcano via devel wrote:

On 4/23/21 11:18 AM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/CompilerPolicy

== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM.  This
change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to build with gcc even if upstream does not support it.

The goal is to give the packager the ability to use their own
technical judgement to choose the best compiler.

Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.

== Owner ==
* Name: Jeff Law
* Name: Tom Stellard
* Email: tstel...@redhat.com


== Detailed Description ==

The main goal here is to give a packager some freedom to select the
best compiler for their package.  This policy change will allow
packagers to choose to use a non-default compiler for their package,
if they have a valid technical reason to do so.  The default compiler
for Fedora is gcc or when upstream doesn't support gcc, then the
default compiler is clang. Examples of valid technical reasons to not
use the default compiler, include but are not limited to:

* The default compiler cannot build a package correctly.
* The packager needs to disable a compiler feature (e.g. LTO) in order
for the default compiler to correctly compile their package.
* The default compiler takes significantly longer to build a package.
* The default compiler is missing a feature that would benefit the 
package.


If this policy is implemented, it may be beneficial for packagers to
use conditional macros to switch between different compilers.  This
could be useful when trying to make a comparison between the two
compilers or to make it easy to change back to the default compiler.
Therefore, in addition to updating the compiler policy, we are also
proposing to add the following macros to redhat-rpm-config to help
facilitate easily switching between different compilers:
The new macros are:

* %cc   - equivalent to %__cc (C Compiler)
* %cxx  - equivalent to %__cxx (C++ Compiler)
* %cpp  - equivalent to %_cpp (C preprocessor)

The policy update will also recommend that packagers use standardized
macro names when using conditional options to control the compiler
choice:

%bcond_with toolchain_clang
%bcond_with toolchain_gcc

[https://pagure.io/packaging-committee/pull-request/1066 Pull request]
with proposed policy changes.

Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.

It is worth noting that Clang/LLVM's implementation of
-fstack-clash-protection, which is one of Fedora's default compiler
flags, is under development and does not yet have an implementation
for AArch64.

== Feedback ==
* The original proposal stated that Fedora packagers should follow
upstream's compiler preferences, but based on feedback, the proposal
was updated to allow a packager to choose the compiler they feel is
best as long as there is a valid technical reason to do so.

== Benefit to Fedora ==

This change allows packagers more freedom to use the compiler that
produces the best version of their package, which helps to give our
users a better overall experience.  Also, giving package maintainers
more freedom to select the best compiler, let's them spend more time
focusing on package improvements and less time on debugging compiler
issues.

An example of a package that could benefit from this policy is
Firefox.  Upstream, the Firefox project builds primarily with
Clang/LLVM.  Yet we force the Fedora package owner to find and fix
issues building with GCC then either carry those custom fixes forward
in Fedora or negotiate with upstream to get those changes upstreamed.
While this process can be helpful in finding non-portable code, this
is ultimately a poor use of the packager's time.

Additionally Fedora loses the benefit of the testing provided by other
distributions where Firefox is compiled in the same way as the
upstream project -- when issues arise the Fedora team must consider
the possibility that the problem is due to using GCC instead of
Clang/LLVM or the patches to make that possible.  Again, this is a
poor use of Fedora developer's time.

Other packages that may benefit include:
* llvm/clang (currently has to disable LTO due to compilation failures).
* qemu (could take advantage of clang's CFI hardening feature).

== Scope ==
* Proposal owners:
** Update the Fedora Packaging Guidelines to reflect the policy change
and submit patch with new macros to redhat-rpm-config.
* Other developers:
** Developers that want to use a new compiler in accordance with the
policy may update their packages

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

2021-04-23 Thread Robert Marcano via devel


On 4/23/21 11:18 AM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/CompilerPolicy

== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM.  This
change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to build with gcc even if upstream does not support it.

The goal is to give the packager the ability to use their own
technical judgement to choose the best compiler.

Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.

== Owner ==
* Name: Jeff Law
* Name: Tom Stellard
* Email: tstel...@redhat.com


== Detailed Description ==

The main goal here is to give a packager some freedom to select the
best compiler for their package.  This policy change will allow
packagers to choose to use a non-default compiler for their package,
if they have a valid technical reason to do so.  The default compiler
for Fedora is gcc or when upstream doesn't support gcc, then the
default compiler is clang. Examples of valid technical reasons to not
use the default compiler, include but are not limited to:

* The default compiler cannot build a package correctly.
* The packager needs to disable a compiler feature (e.g. LTO) in order
for the default compiler to correctly compile their package.
* The default compiler takes significantly longer to build a package.
* The default compiler is missing a feature that would benefit the package.

If this policy is implemented, it may be beneficial for packagers to
use conditional macros to switch between different compilers.  This
could be useful when trying to make a comparison between the two
compilers or to make it easy to change back to the default compiler.
Therefore, in addition to updating the compiler policy, we are also
proposing to add the following macros to redhat-rpm-config to help
facilitate easily switching between different compilers:
The new macros are:

* %cc   - equivalent to %__cc (C Compiler)
* %cxx  - equivalent to %__cxx (C++ Compiler)
* %cpp  - equivalent to %_cpp (C preprocessor)

The policy update will also recommend that packagers use standardized
macro names when using conditional options to control the compiler
choice:

%bcond_with toolchain_clang
%bcond_with toolchain_gcc

[https://pagure.io/packaging-committee/pull-request/1066 Pull request]
with proposed policy changes.

Note this change is only for compiler selection.  It does not change
existing policies WRT runtime library selection, linker selection,
debuggers, etc.

It is worth noting that Clang/LLVM's implementation of
-fstack-clash-protection, which is one of Fedora's default compiler
flags, is under development and does not yet have an implementation
for AArch64.

== Feedback ==
* The original proposal stated that Fedora packagers should follow
upstream's compiler preferences, but based on feedback, the proposal
was updated to allow a packager to choose the compiler they feel is
best as long as there is a valid technical reason to do so.

== Benefit to Fedora ==

This change allows packagers more freedom to use the compiler that
produces the best version of their package, which helps to give our
users a better overall experience.  Also, giving package maintainers
more freedom to select the best compiler, let's them spend more time
focusing on package improvements and less time on debugging compiler
issues.

An example of a package that could benefit from this policy is
Firefox.  Upstream, the Firefox project builds primarily with
Clang/LLVM.  Yet we force the Fedora package owner to find and fix
issues building with GCC then either carry those custom fixes forward
in Fedora or negotiate with upstream to get those changes upstreamed.
While this process can be helpful in finding non-portable code, this
is ultimately a poor use of the packager's time.

Additionally Fedora loses the benefit of the testing provided by other
distributions where Firefox is compiled in the same way as the
upstream project -- when issues arise the Fedora team must consider
the possibility that the problem is due to using GCC instead of
Clang/LLVM or the patches to make that possible.  Again, this is a
poor use of Fedora developer's time.

Other packages that may benefit include:
* llvm/clang (currently has to disable LTO due to compilation failures).
* qemu (could take advantage of clang's CFI hardening feature).

== Scope ==
* Proposal owners:
** Update the Fedora Packaging Guidelines to reflect the policy change
and submit patch with new macros to redhat-rpm-config.
* Other developers:
** Developers that want to use a new compiler in accordance with the
policy may update their packages if they want, but there is no
required action for packagers with this change.
* Release engineering:

Re: Display a message on the console while upgrading a package

2021-03-30 Thread Robert Marcano via devel


On 3/30/21 1:17 PM, Robert Marcano wrote:

On 3/30/21 1:11 PM, Robert-André Mauchin wrote:

Hello,

Following a change in the config file of a program, I'd like to 
display a message to my users to indicate they need to update the 
config file with the new one. I try "echo" in the update scriptlet:


%postun
if [ "$1" -ge "1" ] ; then # Upgrade
   dnscrypt-proxy -service install --config 
%{_sysconfdir}/dnscrypt-proxy/dnscrypt-proxy.toml
   echo 'Since version 2.0.45, some of the configuration files have 
been renamed.
   Please merge your config to 
/etc/dnscrypt-proxy/dnscrypt-proxy.toml.rpmnew then

   replace dnscrypt-proxy.toml with that file.
   Read /usr/share/doc/dnscrypt-proxy/ChangeLog to merge files 
accordingly.'

fi

But it doesn't work as expected. Is there a way to transmit that 
message to my users?


The automatic message about the saving of the new configuration as an 
*.rpmnew file should tell any sysadmins that the configuration needs to 
be revised.




Let me add that DNF should show the list of configuration files saved as 
*.rpmsave or *.rpmnew at the end of the transaction. It is easy to skip 
those messages inside a long list of lines with  
as progress bars


If the service doesn't works fine with the old configuration. Maybe you 
could add a service ExecStartPre script that fails with a pretty message 
about the file migration required.





Best regards,

Robert-André
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure



___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Display a message on the console while upgrading a package

2021-03-30 Thread Robert Marcano via devel


On 3/30/21 1:11 PM, Robert-André Mauchin wrote:

Hello,

Following a change in the config file of a program, I'd like to display 
a message to my users to indicate they need to update the config file 
with the new one. I try "echo" in the update scriptlet:


%postun
if [ "$1" -ge "1" ] ; then # Upgrade
   dnscrypt-proxy -service install --config 
%{_sysconfdir}/dnscrypt-proxy/dnscrypt-proxy.toml
   echo 'Since version 2.0.45, some of the configuration files have been 
renamed.
   Please merge your config to 
/etc/dnscrypt-proxy/dnscrypt-proxy.toml.rpmnew then

   replace dnscrypt-proxy.toml with that file.
   Read /usr/share/doc/dnscrypt-proxy/ChangeLog to merge files 
accordingly.'

fi

But it doesn't work as expected. Is there a way to transmit that message 
to my users?


The automatic message about the saving of the new configuration as an 
*.rpmnew file should tell any sysadmins that the configuration needs to 
be revised.


If the service doesn't works fine with the old configuration. Maybe you 
could add a service ExecStartPre script that fails with a pretty message 
about the file migration required.





Best regards,

Robert-André
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Default 'fedora' hostname and failing split DNS VPN

2021-03-25 Thread Robert Marcano via devel


On 3/25/21 10:21 AM, Michael Catanzaro wrote:


On Thu, Mar 25 2021 at 08:37:03 AM -0400, Robert Marcano via devel 
 wrote:

IMHO the fedora name should be always resolvable the same way as
localhost or just remove it. It is not right thsat fedora is being
resolved only while the DHCP server isn't assigning you a new hostname.
You never know when a DHCP server will decide to send you one,
especially if you move around many WiFi hotspots


The problem is not specific to the name "fedora" though. Our intended 
behavior is to resolve the local hostname locally, without doing any 
DNS, regardless of what its name is. This broke in Fedora 33 and you're 
just the first person to notice and complain afaik.


Thank for looking at it. Without the broken VPN DNS and Firefox doing 
some weird lookup at startup for the hostname I would have never noticed it.


I wonder if the Firefox thing has to do with their policies. Apparently 
they have to be processed very early at startup and maybe there is 
something in there slowing things down, but that would be another bug 
than this one.




So editing /etc/hosts is not the right solution. We need to change our 
NSS configuration. I'll send another mail about this.




___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Default 'fedora' hostname and failing split DNS VPN

2021-03-25 Thread Robert Marcano via devel


On 3/24/21 9:51 PM, Robert Marcano wrote:
Currently I am connecting to a VPN that provides a few DNS search 
entries. One of these domains on the search path is having DNS 
resolution problems. This is not per se the the problem I am  writing 
this email for.


The problem is that starting Firefox and Thunderbird take a long time, 
it took time to detect the DNS resolution problem was the origin of 
these timeouts. I am not using that domain that is having resolution 
problems.


The real culprit is the default `fedora` hostname, instead of localhost. 
Starting a Wireshark capture there are DNS searches for 
fedora.domain_failing.tld, when starting Firefox and Thunderbird. The 
presence of the search path on generated /etc/resolv.conf isn't the 
cause of these DNS searches, I edited them out while the VPN was still 
active.


Even 'ping fedora' start doing these searches with the search paths 
appended. 'ping localhost' doesn't do that. The only workaround to this 
issue is to add fedora to the localhost entries on /etc/hosts.


This in some way is a DNS leak, even on a VPN with perfectly working DNS 
resolution, the fedora name should not be searched on these domains 
until I am using the fedora full hostname on these domains. Even worse 
when simply starting applications like Firefox o Thunderbird.


Maybe changing the default hostname to fedora wasn't a good idea after 
all, or at least fedora should be added to the default /etc/hosts.


About the default fedora transient hostname nchange. This has caused 
more problems that really solved.


Sometime ago the default HOSTNAME environment variable was changed to 
use in /etc/profile


  HOSTNAME=`/usr/bin/hostnamectl --transient`

This didn't cause any problems initially because the the default was 
localhost.localdomain, but now that is fedora. If you reach the desktop 
before plugin in your laptop to the network and your network DHCP server 
assigns you a hostname, you get a entire session where the HOSTNAME 
isn't resolvable, because fedora is only resolvable when the transient 
host name was set as fedora, but it was overriden by the DHCP server.


Tilix was one of the programs with problems with this, you get an 
annoying warning. I solved this by adding HOSTNAME=`hostname` to .bashrc


IMHO the fedora name should be always resolvable the same way as 
localhost or just remove it. It is not right thsat fedora is being 
resolved only while the DHCP server isn't assigning you a new hostname. 
You never know when a DHCP server will decide to send you one, 
especially if you move around many WiFi hotspots

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Default 'fedora' hostname and failing split DNS VPN

2021-03-25 Thread Robert Marcano via devel


On 3/25/21 7:30 AM, Petr Menšík wrote:

Hi,

I would guess your domainname is not (none), and hostname -f value is
fedora.domain_failing.tld. One of fixes might be to change hostname of
the machine to not contain domains suffix. Then only explicitly
configured search would apply.


No:

# hostname -f
fedora



On 3/25/21 2:51 AM, Robert Marcano via devel wrote:

Currently I am connecting to a VPN that provides a few DNS search
entries. One of these domains on the search path is having DNS
resolution problems. This is not per se the the problem I am  writing
this email for.

The problem is that starting Firefox and Thunderbird take a long time,
it took time to detect the DNS resolution problem was the origin of
these timeouts. I am not using that domain that is having resolution
problems.

Would dig fedora.domain_failing.tld take long before VPN is
estabilished? Does it timeout when connecting or after connected?
Timeout might mean some of connection provided servers does not respond
or route to it does not work. Even searches should mean just more
packets, not visibly longer delay.


It doesn't take long because fedora.domain_failing.tld fails fast on the 
default network DNS, domain_failing.tld is a domain only available on 
the VPN


The real culprit is the default `fedora` hostname, instead of localhost.
Starting a Wireshark capture there are DNS searches for
fedora.domain_failing.tld, when starting Firefox and Thunderbird. The
presence of the search path on generated /etc/resolv.conf isn't the
cause of these DNS searches, I edited them out while the VPN was still
active.

Try not commenting it out, but override default system value in
/etc/resolv.conf:
search .


Even 'ping fedora' start doing these searches with the search paths
appended. 'ping localhost' doesn't do that. The only workaround to this
issue is to add fedora to the localhost entries on /etc/hosts.

That would be likely because localhost is in /etc/hosts, read by files
in nsswitch. But dns queries (if systemd-resolved is disabled) are
configured by /etc/resolv.conf.


This in some way is a DNS leak, even on a VPN with perfectly working DNS
resolution, the fedora name should not be searched on these domains
until I am using the fedora full hostname on these domains. Even worse
when simply starting applications like Firefox o Thunderbird.

Are you sure you do not have hostname set to FQDN? Have you tried
setting it to relative name (no dots)?


Maybe changing the default hostname to fedora wasn't a good idea after
all, or at least fedora should be added to the default /etc/hosts.

It should not be necessary unless fqdn is used as a hostname. "fedora"
value should be completely ok. But I guess even when connecting to VPN,
it should not timeout. DNS settings should be changed only after VPN is
connected and ready to forward packets. Are you sure no IP range
conflicts with used DNS servers?

Cheers,
Petr


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

Re: Default 'fedora' hostname and failing split DNS VPN

2021-03-25 Thread Robert Marcano via devel


On 3/24/21 11:26 PM, Michael Catanzaro wrote:


Hi,

I have a couple different ideas of what could be going wrong. Let's test 
a few things. First, please run:


$ cat /etc/nsswitch.conf | grep hosts | tail -1

If it is our default configuration, it should say:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] 
myhostname dns


Exactly the same output, nsswitch.conf is pointing to 
/etc/authselect/nsswitch.conf default




Now, see what happens if you disable systemd-resolved:

$ sudo systemctl stop systemd-resolved.service


This doesn't properly disable systemd-resolved, There is a DNS 
resolution error or two and then the service is autostarted (probably 
socket activation)


I entirely disabled it by changing dns=default in NetworkManager and 
renaming the /etc/resolv.conf symlink to another name.




Does the bug go away? If so, it's likely a systemd-resolved bug to be 
fixed. (Reenable systemd-resolved with 'sudo systemctl start 
systemd-resolved.service'.)


No, the bug dosn't go away. The fedora name is still searched on all 
search domains (traced bu wireshark) and not a simple direct local 
response like happens with localhost





If the bug does NOT go away, then let's test one more thing: please edit 
/etc/authselect/user-nsswitch.conf as root and change the hosts line to 
look like this:


hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve 
[!UNAVAIL=return] dns


Then run:

$ sudo authselect apply-changes


With this the bug goes away.



Does the bug go away? I think that should almost certainly "fix" it. If 
so, you have a good workaround, and we know the problem must be caused 
by avahi, and we should reconsider our NSS configuration. But if the bug 
does not go away after this big hammer, then it must be a 
Firefox/Thunderbird bug, because if they try to resolve anything that 
doesn't exactly match the local hostname, then of course we have to do 
some DNS.


Notice that it isn't a Firefox and Thunderbird issue. 'ping fedora' have 
these long DNS timeouts looking fedora on the search domains. I agree 
that it is weird that these applications are doing lookups with the 
hostname, but ping should not be doing these either with fedora, exactly 
like localhost doesn't ends up as queries on the search domains.




I'm interested to see the your results,

Michael



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

Default 'fedora' hostname and failing split DNS VPN

2021-03-24 Thread Robert Marcano via devel

Currently I am connecting to a VPN that provides a few DNS search 
entries. One of these domains on the search path is having DNS 
resolution problems. This is not per se the the problem I am  writing 
this email for.


The problem is that starting Firefox and Thunderbird take a long time, 
it took time to detect the DNS resolution problem was the origin of 
these timeouts. I am not using that domain that is having resolution 
problems.


The real culprit is the default `fedora` hostname, instead of localhost. 
Starting a Wireshark capture there are DNS searches for 
fedora.domain_failing.tld, when starting Firefox and Thunderbird. The 
presence of the search path on generated /etc/resolv.conf isn't the 
cause of these DNS searches, I edited them out while the VPN was still 
active.


Even 'ping fedora' start doing these searches with the search paths 
appended. 'ping localhost' doesn't do that. The only workaround to this 
issue is to add fedora to the localhost entries on /etc/hosts.


This in some way is a DNS leak, even on a VPN with perfectly working DNS 
resolution, the fedora name should not be searched on these domains 
until I am using the fedora full hostname on these domains. Even worse 
when simply starting applications like Firefox o Thunderbird.


Maybe changing the default hostname to fedora wasn't a good idea after 
all, or at least fedora should be added to the default /etc/hosts.

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: OpenSSH SHA-1 deprecation, developing FAQ, etc

2021-03-11 Thread Robert Marcano via devel


On 3/11/21 1:01 PM, Richard W.M. Jones wrote:

On Thu, Mar 11, 2021 at 03:50:57PM +0100, Daniel Pocock wrote:



On 11/03/2021 12:13, Florian Weimer wrote:

* Richard W. M. Jones:


I really hope we don't remove the ability to connect to old servers
(eg. running RHEL 5).  At the moment you have to opt-in by setting the
crypto-policy to LEGACY and running update-crypto-policies(8), which
is bearable.


In the past (long, long ago), I had to enable Telnet on target devices
to work around incompatible cryptography policies.  I hope we are not
going to return to that.


Giving people an option to use broken crypto on-demand may appear
reasonable at first glance.  In practice, there are sites where people
turn it on to meet a deadline or end a service outage and then they
never go back to remove it.


Ideally there would be some ssh option to enable it on the single ssh
command (rather than globally).  This would solve the problem you've
outlined there.


+1 to this. I still connect to old appliances that I  don't manage so I 
can't migrate them, but I am OK with my current alias as:


  alias ssh-legacy='ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 
-oPubkeyAcceptedKeyTypes=+ssh-rsa'


In order to connect to those systems and still remember that I am using 
a relatively insecure connection. I preferred an alias than modifying 
the system crypto policy.



The context here is P2V/V2V where we are connecting to old physical
machines and virtualizing them or pulling VMs off them on to modern
systems.

Rich.


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 33 network configuration (ifcfg*) migration guide available?

2021-01-27 Thread Robert Marcano via devel


On 1/25/21 5:53 AM, Peter Boy wrote:

With Fedora 33 network configuration is by default persisted in 
/etc/NetworkManager/system-connections/*.nmconnection files. The old 
/etc/sysconfig/network-scripts/ifcfg* files are „legacy“. They are still being 
processed for the time being, but obviously it is time to migrate.
(cf 
https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh).


Is there a kind of „mapping“ ifcfg-* —> *-nmconnection. ?


You can "migrate" using nmcli:

Save the output of `nmcli connection show `, then 
create a new empty one a do a diff of the new `nmcli connection show 
` with the old one. Set set the differences on the 
new connection with `nmcli connection modify ...`







Most items are simple to migrate, but servers in particular sometimes have 
unusual configurations, e.g.

- for p2p Connections: SCOPE="peer xxx.yyy.zzz.aaa"
- and corresponding a lot of (ADDRESSx / NETMASKx / GATEWAYx ) entries in 
route-{ifname}   file

How do I handle that kind of config items in *.nmconnection ? The "search engine I 
trust" couldn't answer that for me (or I couldn’t ask the right question).



Thanks
Peter


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


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

Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)

2020-12-22 Thread Robert Marcano via devel

On Mon, Dec 21, 2020, 8:19 PM Davide Cavalca via devel <
devel@lists.fedoraproject.org> wrote:

> On Mon, 2020-12-21 at 12:54 -0400, Robert Marcano via devel wrote:
> > On 12/21/20 12:28 PM, Ben Cotton wrote:
> > > ...
> > >
> > > === New process ===
> > >
> > > # Resolve packaging request into a list of packages and operations
> > > # Download and '''decompress''' packages into a '''locally
> > > optimized''' rpm file
> > > # Install and/or upgrade packages sequentially using RPM files,
> > > using
> > > '''reference linking''' (reflinking) to reuse data already on disk.
> >
> > This sound great because free space requirements can be reduced,
> > specially when installing new packages.
> >
> > I have experimented building very small appliances using btrfs
> > compression on things like /usr/share. So I think this could disrupt
> > this because if I am correct the extends will be first downloaded to
> > a
> > temporary directory without compression enabled.
>
> For CoW to be beneficial, the package cache should be on the same
> filesystem used for the bulk of the system. In this scenario,
> compression should work just fine, as long as it's enabled on the
> appropriate subvolumes.
>

On btrfs there is a compression file flag so you can set compression on a
directory without having compression on the DNF cache directory on the same
volume

>
> > I am happy with an option to disable this behavior.
>
> To be clear, for this Change we do not plan to enable CoW by default.
> If would be a user opt-in via the dnf-plugin-cow package.
>

Good, thanks


> Cheers
> Davide
> ___
> 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
>  lol
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)

2020-12-21 Thread Robert Marcano via devel


On 12/21/20 12:28 PM, Ben Cotton wrote:

...

=== New process ===

# Resolve packaging request into a list of packages and operations
# Download and '''decompress''' packages into a '''locally optimized''' rpm file
# Install and/or upgrade packages sequentially using RPM files, using
'''reference linking''' (reflinking) to reuse data already on disk.


This sound great because free space requirements can be reduced, 
specially when installing new packages.


I have experimented building very small appliances using btrfs 
compression on things like /usr/share. So I think this could disrupt 
this because if I am correct the extends will be first downloaded to a 
temporary directory without compression enabled.


I am happy with an option to disable this behavior.



The outcome is intended to be the same, but the order of operations is
different.

# Decompression happens inline with download. This has a positive
effect on resource usage: downloads are typically limited by
bandwidth. Decompression and writing the full data into a single file
per rpm is essentially free. Additionally: if there is more than one
download at a time, a multi-CPU system can be better utilized. All
compression types supported in RPM work because this uses the rpm I/O
functions.
# RPMs are cached on local storage between downloading and
installation time as normal. This allows DNF to defer actual RPM
installation to when all the RPM are available. This is unchanged.
# The file format for RPMs is different with Copy on Write. The
headers are identical, but the payload is different. There is also a
footer.
## Files are converted (“transcoded”) locally during download using
/usr/bin/rpm2extents (part of rpm codebase). The format
is not intended to be “portable” - i.e. copying the files from the
cache is not supported.
## Regular RPMs use a compressed .cpio based payload. In contrast,
extent based RPMs contain uncompressed data aligned to the fundamental
page size of the architecture, e.g. 4KiB on x86_64. This alignment is
required for FICLONERANGE to work. Only files are
represented in the payload, other directory entries like symlinks,
device nodes etc are constructed entirely from rpm header information.
Files are referenced by their digest, so identical files are
de-duplicated.
## The footer currently has three sections
### Table of original (rpm) file digests, used to validate the
integrity of the download in dnf.
### Table of digest → offset used when actually installing files.
### Signature 8 bytes at the end of the file, used to differentiate
between traditional RPMs and extent based.

=== Notes ===

# The headers are preserved bit for bit during transcoding. This
preserves signatures. The signatures cover the main header blob, and
the main header blob ensures the integrity of data in two ways:
## Each file with content has a digest. Originally this was md5, but
today it’s usually sha256. In normal RPM this is only used to verify
the integrity of files, e.g. rpm -V. With CoW we use this
as a content key.
## There is/are one or two digests (PAYLOADDIGEST and
PAYLOADDIGESTALT) covering the payload archive
(compressed cpio). The header value is preserved, but transcoded RPMs
do not preserve the original structure so RPM’s pre-installation
verification (controlled by %_pkgverify_level will fail.
dnf-plugin-cow disables this check in dnf because it
verifies the whole file digest which is captured during
download/transcoding. The second one is likely used for delta rpm.
# This is untested, and possibly incompatible with delta RPM (drpm).
The process for reconstructing an rpm to install from a delta is
expensive from both a CPU and I/O perspective, while only providing
marginal benefits on download size. It is expected that having delta
rpm enabled (which is the default) will be handled gracefully.
# Disk space requirements are expected to be marginally higher than
before: all new packages or updates will consume their installed size
before installation instead of about half their size (regular rpms
with payloads still cost space).
# rpm-plugin-reflink will fall back to simple file
copying when the destination path is not on the same
filesystem/subvolume. A common example is /boot and/or
/boot/efi.
# The system will still work on other filesystem types, but will
''always'' fall back to simple copying. This is expected to be
slightly slower than not enabling CoW because the source for copying
will be the decompressed data.
# For systems that enable transparent filesystem compression: every
file will continue to be decompressed from the original rpm, and then
transparently re-compressed by the filesystem. There is no effective
change here. There is a future project to investigate alternate
distribution mechanics to provide parallel versions of file content
pre-compressed in a filesystem specific format, reducing both CPU
costs and I/O. It is expected that this will result in slightly higher
network utilization because filesystem

Re: Delay service startup but only on boot

2020-12-03 Thread Robert Marcano via devel


On 12/3/20 9:44 AM, Richard Shaw wrote:
On Thu, Dec 3, 2020 at 2:41 AM Gargoyle > wrote:


On 02/12/2020 16:09, Richard Shaw wrote:

Nope, it's an external networked device. They always "boot up" at
the same time, but the computer which runs the service boots up
faster than the device I need to connect to.


What difference does that make - what's the actual problem you're
having?


The service starts and tries to connect but the other system is up far 
enough yet to receive connections so it just fails. The only solution so 
far is to restart the service manually later, which is what I'm trying 
to work around.


For remote connections, specially when all servers are restarted at the 
same time I use a shell script on ExecStartPre that check for an open 
port on the remote server.


My case it is a database server that takes a long time on the firmware 
initialization, and the application servers start really fast, before 
the database server is started.


### wait-tcp-port  

#!/bin/bash

IP=$1
PORT=$2
MAX_TRIES=300

OPEN_RC=2
COUNTER=1
until [[ $OPEN_RC -eq 0 || $COUNTER -gt $MAX_TRIES ]]; do
  exec 3>&2 2>/dev/null
  exec 6<>/dev/tcp/$IP/$PORT
  OPEN_RC=$?
  exec 2>&3

  if [ $OPEN_RC -eq 0 ]; then
exec 6>&- # close output connection
exec 6<&- # close input connection
echo Port $IP:$PORT open
  else
sleep 2
COUNTER=$[$COUNTER +1]
  fi
done

if [ $COUNTER -gt $MAX_TRIES ]; then
  echo Max tries waiting for port $IP:$PORT reached
  exit 100
fi



Also, is this a standard Fedora package? (So there may at least be a
weak link to continued discussion on this list)


No, it's something custom. Thanks for the feedback though, I pretty much 
already decided to try the timer delay method


Thanks,
Richard

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


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

Re: Unable to disable SysRq

2020-11-17 Thread Robert Marcano via devel


On 11/17/20 8:26 AM, Robert Marcano wrote:


User d9k on IRC found the culprit. It is low-memory-monitor. The latest 
commit [1] for it tries to not mess with the value with 1 is set, but it 
should not mess with it ever.


The same documentation on that commit references [2] where it says:

Note that the value of ``/proc/sys/kernel/sysrq`` influences only the 
invocation
via a keyboard. Invocation of any operation via 
``/proc/sysrq-trigger`` is

always allowed (by a user with admin privileges).



[1] 
https://gitlab.freedesktop.org/hadess/low-memory-monitor/-/commit/11560bc102941c95890c0852f2d9b166853b4f6a 

[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/sysrq.rst 



Will submit a bug (if d9k already hasn't done that).



Reported upstream and a tracking bug on bugzilla

https://gitlab.freedesktop.org/hadess/low-memory-monitor/-/issues/11
https://bugzilla.redhat.com/show_bug.cgi?id=1898524
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unable to disable SysRq

2020-11-17 Thread Robert Marcano via devel

On 11/16/20 8:25 PM, Robert Marcano wrote:
I am using a ThinkPad with one of these keyboards where the PrtScr key
is between the right Alt and Ctrl, an awful position.

Two times in a week I have killed all processes trying to use Alt+i. Ts
is to easy to press the Alt and the PrtScr at the same, starting that
way the SysRq i command.

So before staring to write a kernel patch to add an option where the
SysRq is only triggered by the Left Alt key. I decided to initially
disable sysrq entirely.

My Fedora 33 kernel.sysrq value is 80, the default at
/usr/lib/sysctl.d/50-default.conf say that it should be 16.

Created /etc/sysctl.d/99-local.conf with kernel.sysrq=0, but after boot
the value is 64, only after a single user mode boot the value stays at 0.

Some other thing is enabling the 64 bit, Asked on IRC and another user
has 80 on Fedora Workstation and 16 on Server.

I tried disabling all non default services on my installation but to no
effect, the 64 bit is always enabled. Fedora 33 Live CD shows 16 as the
default is configured.

How can I log what process is changing values on the sysctl variables?
or anyone has aon idea of what is happening here?

User d9k on IRC found the culprit. It is low-memory-monitor. The latest
commit [1] for it tries to not mess with the value with 1 is set, but it
should not mess with it ever.

The same documentation on that commit references [2] where it says:

Note that the value of ``/proc/sys/kernel/sysrq`` influences only the invocation
via a keyboard. Invocation of any operation via ``/proc/sysrq-trigger`` is
always allowed (by a user with admin privileges).

[1]
https://gitlab.freedesktop.org/hadess/low-memory-monitor/-/commit/11560bc102941c95890c0852f2d9b166853b4f6a
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/sysrq.rst

Will submit a bug (if d9k already hasn't done that).
___
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

Unable to disable SysRq

2020-11-16 Thread Robert Marcano via devel

I am using a ThinkPad with one of these keyboards where the PrtScr key 
is between the right Alt and Ctrl, an awful position.


Two times in a week I have killed all processes trying to use Alt+i. Ts 
is to easy to press the Alt and the PrtScr at the same, starting that 
way the SysRq i command.


So before staring to write a kernel patch to add an option where the 
SysRq is only triggered by the Left Alt key. I decided to initially 
disable sysrq entirely.


My Fedora 33 kernel.sysrq value is 80, the default at 
/usr/lib/sysctl.d/50-default.conf say that it should be 16.


Created /etc/sysctl.d/99-local.conf with kernel.sysrq=0, but after boot 
the value is 64, only after a single user mode boot the value stays at 0.


Some other thing is enabling the 64 bit, Asked on IRC and another user 
has 80 on Fedora Workstation and 16 on Server.


I tried disabling all non default services on my installation but to no 
effect, the 64 bit is always enabled. Fedora 33 Live CD shows 16 as the 
default is configured.


How can I log what process is changing values on the sysctl variables? 
or anyone has aon idea of what is happening here?

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

Re: Driverless scanning for WSD and ESCL supported scanners is coming

2020-08-06 Thread Robert Marcano via devel


On 8/6/20 3:48 AM, Zdenek Dohnal wrote:

On 8/5/20 2:30 PM, Jiří Eischmann wrote:


  Will it be possible to use a Fedora machine as a server, so that I can
have an old scanner connected to it via USB and then shared with other
devices on the local network via those protocols?
That would be neat.

Jiri


Hi Jirka,

IIRC it is possible even now via saned on the server, but saned doesn't
use WSD or ESCL, just simple TCP transfer between client and server.

In practice it looks like - you have a proprietary or sane-backends
supported USB scanner (sane-airscan doesn't work for USB devices), you
set up ACL on saned and setup clients to connect to the server.


From the README, it looks like some manufacturers allow eSCL to work 
over USB too:


  However, most (all?) of the eSCL devices will also work over USB, if
  IPP-over-USB daemon is installed on your computer

and some are even USB only:

  [2]: this device is USB-only, but it works well with the IPP-over-USB
  daemon.

I hope this becomes a trend for non networked scanners too.



sane-airscan is a backend for communication with scanner supporting
WSD/ESCL, it doesn't use those protocols for sharing the device.

Zdenek


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



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


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

Re: Driverless scanning for WSD and ESCL supported scanners is coming

2020-08-05 Thread Robert Marcano via devel


On 8/5/20 8:30 AM, Jiří Eischmann wrote:

Zdenek Dohnal píše v St 05. 08. 2020 v 07:44 +0200:

Hi all,

I would like to announce sane-airscan project [1] will be shipped in
the
official Fedora repositories from Fedora 32 [2].

sane-airscan implements a backend for Microsoft WSD and ESCL (usually
called AirScan, originating from Apple) protocols, which are common
in
newer (2012+) scanners and multi-function devices for scanning.

Using sane-airscan, newer devices don't need vendor proprietary
software
for scanning any longer (e.g. hplip with its hp-plugin).

The project is divided into main package - sane-airscan - which
contains
helper tool - airscan-discover - for discovering devices in setups,
where automatic DNS-SD discovery doesn't do the trick, and subpackage
-
libsane-airscan - which the main package requires and the common
known
project for scanning - sane-backends - will require to get the
backend
into common scanning stack installation.

Please feel free to test it.


  Will it be possible to use a Fedora machine as a server, so that I can
have an old scanner connected to it via USB and then shared with other
devices on the local network via those protocols?
That would be neat.


If your clients are SANE supported OSs, you can already do that with 
saned. For example this documentation


https://wiki.debian.org/SaneOverNetwork




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


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

Re: Remove all non UK/USA English spell checker variants from default Fedora installation

2020-07-19 Thread Robert Marcano via devel


On 7/18/20 8:44 AM, Germano Massullo wrote:

All desktop oriented Fedora installers install on the system packages:
hunspell
hunspell-en
hunspell-en-GB
hunspell-en-US

When a user opens the language list of the spell checker, is has ~24 
different English options, like English (Antigua and Barbuda), English 
(Australia), English (Bahamas), English (Belize), etc. (See screenshot [1])
People who are not native English speakers have this list even bigger 
because they will have their own language entry, plus others.


That will be a good enhancement but I would argue that all country 
specific dictionaries should be on their own package. The Spanish list 
is no small either, that the Firefox and Thunderbird UI for selection 
becomes a popup menu bigger than most screens


Since the huge list is brought by hunspell-en, can we just ship Fedora 
with hunspell-en-GB and hunspell-en-US ?
Another option could be to move all non GB/USA English variants to other 
hunspell-en-* packages as I said in ticket [2]



[1]: https://bugzilla.redhat.com/attachment.cgi?id=1701536
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1858241

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


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

Re: User experience issue on btrfs

2020-06-30 Thread Robert Marcano via devel


On 6/29/20 2:26 AM, John M. Harris Jr wrote:

On Sunday, June 28, 2020 5:37:08 PM MST Chris Adams wrote:

Once upon a time, John M. Harris Jr  said:


XFS proved to be troublesome, and still is up to the latest of RHEL7. It's
not  uncommon to have to run xfs_repair on smaller XFS partitions,
especially / boot. I'm not sure if btrfs has the same issue there?



[citation needed]

I haven't run xfs_repair in probably 15 years (and so never on Fedora or
RHEL/CentOS).


I haven't had time to figure out why the RHEL systems I have that are
(mistakenly I assume, though they were created before I was hired) using XFS
run into that issue, after about a month, they report 100% disk space
utilization on /boot, and I've gotta run xfs_repair in order to fix that. In
the unlikely event that I have the time to figure out why, before I just re-
install them (which is already planned), I'd be happy to follow up with a
citation. :)



I had a similar experience in 2016 when stopping Squid timed out and the 
process was killed by systemd (fixed in RH BZ #1336940). For some reason 
the filesystem got to 100% (multiple times) with no eachable file using 
that.


As XFS has no reservation or space for root like ext4, the system was 
unbootable without user intervention to run xfs_repair. I remember 
sending a dump of the filesystem to a XFS developer on the mailing list, 
so it probably got resolved on the XFS side too.

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

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

2020-06-05 Thread Robert Marcano via devel

On 6/5/20 12:31 PM, Jeff Law wrote:

On Fri, 2020-06-05 at 16:23 +, devel-requ...@lists.fedoraproject.org wrote:

Date: Fri, 5 Jun 2020 11:15:39 -0500
From: Steven Munroe 
Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy
Change
To: devel@lists.fedoraproject.org
Message-ID:

Content-Type: text/plain; charset="UTF-8"

I would also add that Clang/LLVM is missing some of the newer C
language revisions at least for the pppc64le target.

Both IEEE/ISO  _Float128 and _Decimalxx support is missing. Ie the
type is not supported or if supported basic arithmetic and math.h
support is missing. Also finding bugs for in-line assembly and missing
constraints needed to work around the missing language features.

Also Clang's poor support for constant folding makes using __int128
(and vector __int128) harder than it needs to be.

This is a significant impact for enabling my project (PVECLIB) for
Clang. As-is a number of project features have been disabled for
Clang.

Clearly your upstream project is still using GCC then and as such the Fedora
package would continue to use GCC.

We're not changing the default here.  We're just removing the anti Clang/LLVM
policy and allowing upstreams to select the compiler that best suits their 
needs.
Clearly Clang/LLVM is not the right choice for your project.

This looks fine, but why not add to the policy that for upstream 
projects that have no defined preference of compiler, the package have 
to use GCC in order to have at least some standard and not let the 
packager bias be the rule, unless some measurable advantage is found to 
use LLVM

I think Clang needs more time to cook.

I'd respectfully disagree.  There are certain features that GCC supports that
Clang does not and vice-versa.  But broadly they are comparable.  What this 
means
is some projects that are using bleeding edge features may have a hard need for
one toolchain or the other.  And the proposal I've made accounts for that by
allowing the upstream project to select the compiler.  In your case it would be
GCC.  For others it could well be Clang/LLVM.

jeff

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

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

Re: Defining the future of the packager workflow in Fedora

2019-09-26 Thread Robert Marcano via devel


On 9/26/19 12:57 PM, Ken Dreyer wrote:

On Thu, Sep 26, 2019 at 7:11 AM Pierre-Yves Chibon  wrote:


On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:

Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :

Here is what the vision we came to and that we would like to discuss:

○ Every changes to dist-git is done via pull-requests


IMHO Have to stay optional, making this mandatory being a terrible headache.


What makes it a headache? What can we do to not have this be a terrible
headache? Can we fix/improve the tooling?


One of the reasons I push directly to branches in Pagure instead of
opening Pull Requests is that the workflow is too clunky and slow. I
have to toggle between the browser and the console, make sure I have a
Fedora Kerberos ticket, etc.


GitLab support creating merge request from a git push:

 https://docs.gitlab.com/ce/user/project/merge_requests/#git-push-options

Maybe something like this on Pagure could help alleviate the process.



Please get a stopwatch app and try the following workflows in GitHub
and Pagure, and compare the speed at which you can do these:

- Create a new personal fork of a repository

   This is almost instant on GitHub, and much slower in Pagure,
sometimes hanging entirely at the "waiting..." web page.

- Push a hundred commits to a topic branch

   GitHub can accept the ref updates very quickly, and Pagure has so
many hooks and operations that I've seen my Git client hang for
seconds or sometimes even minutes. I'm not sure what is going on, but
I suspect it involves ACL checks, Fedmesg, etc. I've seen this one
several times: I forked a project a year ago and I did not update my
forked copy of "master". I push a new topic branch to my clone, and
this topic branch has all the changes from todays' upstream master,
plus my new changes for the topic branch. When I run "git push" for my
new topic branch, Pagure.io will process all of those commits
one-by-one and emit fedmsgs for all of them *according to my old
version of master, not upstream*. I have no idea if that is single
reason for why I see my "git push" commits return very slowly, but it
is probably one of the reasons.

- Open a new pull request

   The GitHub web UI provides a lot of different buttons in a lot of
different places, allowing the user to fall into the "pit of success"
and submit the change upstream. GitHub always immediately knows "hey
this branch is ready to go upstream, do you want to open a PR?" With
Pagure, the UI to open a pull request requires many different clicks,
and if I open it from certain pages (like the origin repository), the
web UI makes some AJAX calls that just hang forever. GitHub also has a
really mature CLI ("hub") that makes opening PRs lightning quick
because the GitHub's REST API responds very fast.

You might wonder why I've not opened tickets for these, and it's
because I am not sure it's worth piling on your team when you guys are
already extremely overloaded. The UX problems I've encountered do not
strike me as trivial issues to resolve in an afternoon. Sometimes I
ask in #fedora-admin if it really looks like I've broken something.
Maybe that's lame and I should just open the tickets. I also have a
bigger concern though: I've played around with pygit2 in some smaller
applications in order to learn it, and I'm beginning to think that
it's simply not possible to get close to the performance and
functionality that GitHub has achieved.

I would like to hear if you see Pagure as still strategic, and if so,
how we can make these common user operations faster.

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


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

63 matches

Mail list logo