[Bug 2162191] New: perl-Dist-Zilla-6.030 is available

[bugzilla]

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

Bug ID: 2162191
   Summary: perl-Dist-Zilla-6.030 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Dist-Zilla
  Keywords: FutureFeature, Triaged
  Assignee: mspa...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 6.030
Upstream release that is considered latest: 6.030
Current version/release in rawhide: 6.029-1.fc38
URL: http://search.cpan.org/dist/Dist-Zilla/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/5898/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Dist-Zilla


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2162191
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Improving Fedora boot time when libvirt is installed

[Michael Catanzaro]

On Wed, Jan 18 2023 at 08:27:02 PM +0100, Fabio Valentini 
 wrote:

Suggests are useful for the case where multiple packages (let's say
packages A and B) provide "foo", a package C depends on something that
provides "foo" (i.e. works with both A and B), but C prefers A over B
if neither of them are installed yet.


Very interesting.

___
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: Bodhi 7.0.1 deployed to prod

[Adam Williamson]

On Tue, 2023-01-17 at 05:39 +, Mattia Verga via devel wrote:
> Hello folks,
> 
> I'd like to announce that Bodhi 7.0.1 has been deployed to production.
> Apart from a webUI new look, due to the switch to fedora-bootstrap 2.x,
> these are the main changes that may interest you:
> 
> - Bodhi client now autenticates using Kerberos by default and falls back
> to browser-based OIDC mechanism. Also, Bodhi client will not show the
> secret in terminal while typing the password when logging in via browser.
> 
> - Frozen releases updates will now be forced into testing before being
> pushed to stable. Previously, when a release was frozen, an update which
> was just submitted (pending), but had received enough votes to be pushed
> directly to stable, was not pushed in testing nor stable. Now it will be
> pushed to testing and remain there until the release is un-frozen.
> 
> - The new update form UI will now display a warning when a release is
> approaching EOL. Also, a warning box will be showed in the update
> details page to inform the user that the update will not be pushed out
> to stable until the freeze is over.
> 
> You can find the full changelog at
> https://fedora-infra.github.io/bodhi/7.0/user/release_notes.html (note
> that the link at the bottom of Bodhi web pages is currently broken, as
> it points to 6.x docs... )

Awesome news! I am working on the PR to have Bodhi generate its own
grouped critpath data daily, instead of using the non-grouped data in
PDC that is updated whenever anyone remembers to fix the script and do
it (so, about once a year on average). =)
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Re: Automation of Fedora SCM requests

[Kevin Fenzi]

On Wed, Jan 18, 2023 at 12:36:35PM -0600, Michel Alexandre Salim wrote:
> Hi Michal,
> 
> On Wed, 2023-01-11 at 17:13 +0100, Michal Konecny wrote:
> >  Hi everyone,
> >  
> >  all the remaining issues were solved and the bot is now processing
> > tickets as it should. I will watch the SCM request repository for
> > next few days to see if everything is working as it should.
> >  Thanks for your patience.
> >  
> Where can I direct feature requests? Per
> https://pagure.io/releng/fedora-scm-requests/issue/50507 seems like
> requesting repos with exceptions (e.g. for Rust compat packages) is
> currently not automated.

I'm not sure how we can automate this. 

I mean I guess we could just check that the requestor is a packager and
let them create any package name they wish? Or is there some programic
way we can tell it's a compat package and that its correctly named?

Perhaps we could extend fedpkg to ask for and provide more info to the
processing ticket? like name of orig package (check that it exists, etc)
and that the new compat package has a name thats based on it?

Thoughts?

kevin


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

Re: Improving Fedora boot time when libvirt is installed

[Gordon Messmer]

On 2023-01-18 11:20, Michael Catanzaro wrote:

Several people suggested using a weak dependency (Suggests:) on the
iscsi driver, but I don't think that would solve the problem for most
users because weak dependencies are installed by default and nothing
really communicates to users that unless they add an obscure option,
their boot times will increase.


No, Suggests basically does nothing.



In case "Suggests" is an acceptable option, I've opened:

https://src.fedoraproject.org/rpms/libvirt/pull-request/15

I've built a package with that change, locally, and verified that I can 
remove the iscsi utils.
___
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: Improving Fedora boot time when libvirt is installed

[Gordon Messmer]

On 2023-01-18 11:20, Michael Catanzaro wrote:

No, Suggests basically does nothing. See this table here:

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



Recommends and Supplements are real dependencies that are installed 
automatically but which you can opt out of. Suggests and Enhances are 
just kinda there, and will not be installed automatically. Not sure if 
they are really useful. 



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

Fedora 38 mass rebuild started

[Tomas Hrcka]

Hi all,

Per the Fedora f38 schedule[1] we have started a mass rebuild
on 2022-01-18 for Fedora f38. We are running this mass rebuild
for the changes listed in:

https://pagure.io/releng/issues?status=Open=mass+rebuild

This mass rebuild will be done in a side tag (f38-rebuild) and merged
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f38-failures.html

Things still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f38-need-rebuild.html

FTBFS (Fails To Build From Source) bugs will be filed shortly after
the mass rebuild is complete.

Please be sure to let releng know if you see any bugs in the
reporting. You can contact releng in #fedora-releng channel on Libera.Chat,
the #releng:fedoraproject.org room on Matrix, or by dropping an email
to our list[2] or filing an issue in pagure[3].

This email template is also in https://pagure.io/releng if you wish to
propose improvements or changes to it.

Regards,
Tomas Hrcka,
Fedora Release Engineering

[1] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora 38 mass rebuild started

[Tomas Hrcka]

Hi all,

Per the Fedora f38 schedule[1] we have started a mass rebuild
on 2022-01-18 for Fedora f38. We are running this mass rebuild
for the changes listed in:

https://pagure.io/releng/issues?status=Open=mass+rebuild

This mass rebuild will be done in a side tag (f38-rebuild) and merged
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f38-failures.html

Things still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f38-need-rebuild.html

FTBFS (Fails To Build From Source) bugs will be filed shortly after
the mass rebuild is complete.

Please be sure to let releng know if you see any bugs in the
reporting. You can contact releng in #fedora-releng channel on Libera.Chat,
the #releng:fedoraproject.org room on Matrix, or by dropping an email
to our list[2] or filing an issue in pagure[3].

This email template is also in https://pagure.io/releng if you wish to
propose improvements or changes to it.

Regards,
Tomas Hrcka,
Fedora Release Engineering

[1] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Improving Fedora boot time when libvirt is installed

[Fabio Valentini]

On Wed, Jan 18, 2023 at 8:20 PM Michael Catanzaro  wrote:
>
> On Wed, Jan 18 2023 at 10:19:24 AM -0800, Gordon Messmer
>  wrote:
> > Several people suggested using a weak dependency (Suggests:) on the
> > iscsi driver, but I don't think that would solve the problem for most
> > users because weak dependencies are installed by default and nothing
> > really communicates to users that unless they add an obscure option,
> > their boot times will increase.
>
> No, Suggests basically does nothing. See this table here:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/
>
> Recommends and Supplements are real dependencies that are installed
> automatically but which you can opt out of. Suggests and Enhances are
> just kinda there, and will not be installed automatically. Not sure if
> they are really useful.

Suggests are useful for the case where multiple packages (let's say
packages A and B) provide "foo", a package C depends on something that
provides "foo" (i.e. works with both A and B), but C prefers A over B
if neither of them are installed yet. Then package C can add
"Suggests: B" to make dependency resolution preferentially resolve
"Requires: foo" to B. Otherwise, dependency resolution apparently
prefers packages that sort lower alphabetically (so A instead of B, in
this simplified example).

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

Re: Improving Fedora boot time when libvirt is installed

[Michael Catanzaro]

On Wed, Jan 18 2023 at 10:19:24 AM -0800, Gordon Messmer 
 wrote:

Several people suggested using a weak dependency (Suggests:) on the
iscsi driver, but I don't think that would solve the problem for most
users because weak dependencies are installed by default and nothing
really communicates to users that unless they add an obscure option,
their boot times will increase.


No, Suggests basically does nothing. See this table here:

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

Recommends and Supplements are real dependencies that are installed 
automatically but which you can opt out of. Suggests and Enhances are 
just kinda there, and will not be installed automatically. Not sure if 
they are really useful.


FESCo could also revisit 2386 and reconsider whether enabled by 
default

is the right decision for this service. I assume there was an explicit
decision for this because of the policy that an enabled-by-default
service "must not require manual configuration to function", which 
iscsi

does. Maybe the fact that it requires manual configuration means that
interested users should also be required to enable the service, given
the pain that the status quo causes for what seems like the far more
common case that this service is installed by all users of libvirt but
not needed by most of them. (also addressing condition 2)


This sounds attractive too.

Michael

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

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

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

[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: Automation of Fedora SCM requests

[Michel Alexandre Salim]

Hi Michal,

On Wed, 2023-01-11 at 17:13 +0100, Michal Konecny wrote:
>  Hi everyone,
>  
>  all the remaining issues were solved and the bot is now processing
> tickets as it should. I will watch the SCM request repository for
> next few days to see if everything is working as it should.
>  Thanks for your patience.
>  
Where can I direct feature requests? Per
https://pagure.io/releng/fedora-scm-requests/issue/50507 seems like
requesting repos with exceptions (e.g. for Rust compat packages) is
currently not automated.

Thanks,

-- 
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

Improving Fedora boot time when libvirt is installed

[Gordon Messmer]

(apologies for the long-ish message, but I'd like to save people the 
trouble of re-reading a year-old very long email thread)


Early last year there was a thread on this list (Re: "Is 
NetworkManager-wait-online.service necessary by default?") in which 
maintainers discussed the issue of boot times increasing when libvirt 
was installed as a result of iscsi creating a service order dependency 
between network-online and remote-fs-pre.  If I'm not mistaken, it was 
unanimously agreed that it was undesirable for this dependency to exist.


This delay is still the most common cause that I find among people who 
complain that it takes a long time to boot Fedora, and unfortunately the 
most common advice given to those people is "disable network-online".  
It's difficult to explain why this is a Bad Thing (TM).


A number of possible solutions were discussed in that thread. 
Unfortunately many of them don't work (or don't work reliably), which I 
assume is why the problem is not solved, so I'm hoping to revive 
discussion of the ones that will work.  The problem occurs because: 1) 
libvirt requires libvirt-daemon-driver-storage-iscsi and 
iscsi-initiator-utils, 2) iscsi.service is enabled by default (per 
https://pagure.io/fesco/issue/2386), 3) iscsi.service is ordered after 
network-online and 4) before remote-fs-pre.target.


iscsi.service already has a "ConditionDirectoryNotEmpty", but that's 
evaluated when the service would be executed, so the ordering dependency 
between network-online and remote-fs-pre exists even though iscsi won't 
start.  There was some discussion of using ".path" units, but that seems 
to have the same problem.


There was also discussion of disabling the service by default and using 
a generator to enable the service, and Lennart thought this was the best 
solution.  I started work to add a simple generator, but the 
documentation for systemd.generator states "Non-essential file systems 
like /var/ and /home/ are mounted after generators have run," and the 
purpose of the generator would be to enable the service when there are 
files in /var/lib/iscsi/nodes.


Several people suggested using a weak dependency (Suggests:) on the 
iscsi driver, but I don't think that would solve the problem for most 
users because weak dependencies are installed by default and nothing 
really communicates to users that unless they add an obscure option, 
their boot times will increase.


So, things that could work:

The package dependency could be dropped from libvirt entirely. Libvirt 
users who want iscsi support can install that storage driver manually. 
(addressing condition 1)


A generator would work if the iscsi node configs were in /etc instead of 
/var.  Would we consider changing the package layout? Possibly, moving 
the node configurations to /etc and changing /var/lib/iscsi/nodes to a 
symlink, with a pre-install script to handle existing installations?  
We'd also need to change the default service state to disabled. 
(addressing condition 2)


The ordering dependency on remote-fs-pre.target could be dropped, though 
I expect that there will be objections and that option wouldn't be 
considered. (addressing condition 4)


FESCo could also revisit 2386 and reconsider whether enabled by default 
is the right decision for this service.  I assume there was an explicit 
decision for this because of the policy that an enabled-by-default 
service "must not require manual configuration to function", which iscsi 
does.  Maybe the fact that it requires manual configuration means that 
interested users should also be required to enable the service, given 
the pain that the status quo causes for what seems like the far more 
common case that this service is installed by all users of libvirt but 
not needed by most of them. (also addressing condition 2)

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

[Test-Announce] Fedora-IoT 38 RC 20230116.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora-IoT 38 RC 20230116.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/38iot

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_38_RC_20230116.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_38_RC_20230116.0_General

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora CoreOS Meeting Minutes 2023-01-18

[Jonathan Lebon]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-01-18/fedora_coreos_meeting.2023-01-18-16.30.html
Minutes (text):
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-01-18/fedora_coreos_meeting.2023-01-18-16.30.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-01-18/fedora_coreos_meeting.2023-01-18-16.30.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by jlebon at 16:30:02 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-01-18/fedora_coreos_meeting.2023-01-18-16.30.log.html
.



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

* Action items from last meeting  (jlebon, 16:33:45)

* "Kernel Errors w/latest next/testing likely CIFS related."  (jlebon,
  16:35:28)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1381
(jlebon, 16:35:31)
  * AGREED: It appears this issue may affect older machines that are
upgraded but we are still investigating to get more details. Since
currently this issue only has one reported affected user/environment
and they have pinned on a known working version we will release the
next `testing` as usual.  (dustymabe, 16:58:41)

* [CfP] Container Plumbing Days 2023  (jlebon, 17:00:16)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1378
(jlebon, 17:00:20)

* Podman begins CNI plugins deprecation  (jlebon, 17:03:49)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1374
(jlebon, 17:03:52)

* Create container repo tags for each FCOS release  (jlebon, 17:12:08)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1367
(jlebon, 17:12:10)

* Open Floor  (jlebon, 17:25:54)

Meeting ended at 17:30:13 UTC.




Action Items






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




People Present (lines said)
---
* jlebon (72)
* dustymabe (46)
* fifofonix (27)
* zodbot (17)
* bgilbert (12)
* walters (10)
* jmarrero (2)
* jbrooks (1)
* aaradhak[m] (1)




Generated by `MeetBot`_ 0.4

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

Re: Yet another unwinding approach

[Daniel Colascione]

Florian Weimer  writes:

> * Mark Wielaard:
>
>> On Wed, 2023-01-18 at 07:22 +0100, Florian Weimer wrote:
>
>>> If the unwind information is incomplete, this …
>>> 
>>> > 7) signal handler unwinds the calling thread however it wants (and can
>>> > sleep and take page faults if needed)
>>> 
>>> … might encounter segmentation faults and terminate the process.  So
>>> far, incorrect unwind information (whether it's a clobbered frame
>>> pointer, or missing DWARF information about clobbered registers) is not
>>> a problem, but it's kind of hard to validate this information from
>>> within the process itself.  Maybe we'd have to add a magic memcpy first
>>> to the vDSO, which the kernel recognizes based on the code addresses,
>>> and suppresses sending the signal for it.
>>
>> Yeah, I am not too afraid of that happening with an .eh_frame based
>> unwinder unless someone deliberately produced a bad table (or dlcloses
>> a library which still has code on the call stack). You still have to be
>> careful about the stack bounds of course.
>
> We won't have unwind data for JIT-compiled code, including libffi
> trampolines.  We could stop backtracing there (what does the ABI say
> about frames without unwinding information?), but I'm not sure if that's
> going to be useful for the desktop.

That's a good incentive to get managed runtimes to provide unwind
information for JIT-compiled code. It can't be that hard: these same
runtimes provide unwind information on Windows, where unwindability
is mandatory.

>> But it is something to keep in mind, accidents happen. I assume that
>> any (seg) fault caused by the unwind signal thread will simply end that
>> contribution of user space to the backtrace (instead of really
>> generating a SEGV)
>
> That smells like SEH. 8-/

SEH is good. So is vectored signal/exception support.

>> But it is tricky to handle that without kernel support. As a fallback
>> you could install a SIGSEGV handler that handles the fault and somehow
>> makes the original SIGPROF based handler (if you use that) sigreturn.
>
> Signal handlers are process-wide,

They don't have to be. I'd expect to be able to unwind a thread's stack
while other threads are running.

> and SIGPROF does not suspend the
> entire process.

Nor should it.

> So I really don't think this can be made to work
> reliably without kernel support.

Sure it can. This scenario is one of many that would benefit from adding
support to libc for multiple cooperating handlers for the same
process. No kernel changes are required. Such a feature is feasible,
useful, practical, and exists on other platforms.
___
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: Yet another unwinding approach

[Daniel Colascione]

Mark Wielaard  writes:

> Hi Florian,
>
> On Wed, 2023-01-18 at 07:22 +0100, Florian Weimer wrote:
>> * Daniel Colascione:
>> 
>> > See, both pro-FP and anti-FP camps think that it's the kernel that has
>> > to do the unwinding unless we copy whole stacks into traces.
>> 
>> Well, I think we should explore hardware-assisted backtraces (shadow
>> stacks), which hopefully are going to get merged in Linux 6.2.
>
> Yes, that is also a good alternative if available. The shadow stack
> seems to be ideal because it is just the function return addresses,
> which basically is just the backtrace you are looking for.
>
>> If the unwind information is incomplete, this …
>> 
>> > 7) signal handler unwinds the calling thread however it wants (and can
>> > sleep and take page faults if needed)
>> 
>> … might encounter segmentation faults and terminate the process.  So
>> far, incorrect unwind information (whether it's a clobbered frame
>> pointer, or missing DWARF information about clobbered registers) is not
>> a problem, but it's kind of hard to validate this information from
>> within the process itself.  Maybe we'd have to add a magic memcpy first
>> to the vDSO, which the kernel recognizes based on the code addresses,
>> and suppresses sending the signal for it.
>
> Yeah, I am not too afraid of that happening with an .eh_frame based
> unwinder unless someone deliberately produced a bad table (or dlcloses
> a library which still has code on the call stack). You still have to be
> careful about the stack bounds of course.
>
> But it is something to keep in mind, accidents happen. I assume that
> any (seg) fault caused by the unwind signal thread will simply end that
> contribution of user space to the backtrace (instead of really
> generating a SEGV)
>
> But it is tricky to handle that without kernel support. As a fallback
> you could install a SIGSEGV handler that handles the fault and somehow
> makes the original SIGPROF based handler (if you use that) sigreturn.

Yep. SIGSEGV in the unwinder could just longjmp back to the top of
the unwinder.

BTW: I'm imagining overloading SIGRTMIN+0, not SIGPROF, because
SIGRTMIN+0 is already reserved for libc.
___
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: Yet another unwinding approach

[Daniel Colascione]

Florian Weimer  writes:

> * Daniel Colascione:
>
>> See, both pro-FP and anti-FP camps think that it's the kernel that has
>> to do the unwinding unless we copy whole stacks into traces.
>
> Well, I think we should explore hardware-assisted backtraces (shadow
> stacks), which hopefully are going to get merged in Linux 6.2.

Shadow call stacks are fine, but they do nothing to help us profile
managed code. We have to think bigger than AOT-compiled
C++/Rust/C/etc. machine code.

>> Why should that be? As mentioned in [1], instead of finding a way to
>> have the kernel unwind user programs, we can create a protocol through
>> which the kernel can ask usermode to unwind itself. It could work like
>> this:
>
> If the unwind information is incomplete, this …
>
>> 7) signal handler unwinds the calling thread however it wants (and can
>> sleep and take page faults if needed)
>
> … might encounter segmentation faults and terminate the process.  So
> far, incorrect unwind information (whether it's a clobbered frame
> pointer, or missing DWARF information about clobbered registers) is not
> a problem, but it's kind of hard to validate this information from
> within the process itself.  Maybe we'd have to add a magic memcpy first
> to the vDSO, which the kernel recognizes based on the code addresses,
> and suppresses sending the signal for it.

Aren't we over-thinking this? We can just terminate the trace if we're
missing reliable (DWARF/ORC/etc.) unwind information for a frame. Why
would we expect a segfault and try to recover if we're unwinding using
debug information? That debug information would have to be wrong for
to segfault.

Granted, if we're trying to traverse frame pointers, that's a different
story, but...

> Maybe we'd have to add a magic memcpy first
> to the vDSO, which the kernel recognizes based on the code addresses,
> and suppresses sending the signal for it.

...if we implemented by 2018 proposed for shared signal handlers, we
could arrange that "magic memcpy" in userspace without the kernel's
help: libc's SIGSEGV signal handler (which, under my proposal, could
exist with other SIGSEGV handlers in the same process) could recognize
and ignore that "magic memcpy" function on its own by looking at
si_addr. Why do in the kernel what we can do in userspace?
___
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: Anyone know how to packet rust projects as rpms? stgit-2 specifically

[Fabio Valentini]

On Wed, Jan 18, 2023 at 4:48 PM David Howells  wrote:
>
> Hi,
>
> Does anyone know how to package a rust project as an rpm on Fedora 37,
> specifically stgit-2?

Looking at the upstream project, it doesn't look too bad. Should be
relatively straightforward to package for Fedora, with one caveat.

> stgit, of which I make heavy use, has been rewritten in rust but I can't
> manage to build it.
>
> https://github.com/stacked-git/stgit
>
> I've found rust2rpm to create a specfile, but that doesn't any insert
> BuildRequires for "dnf builddep" to pick up.

Rust packaging uses dynamically generated BuildRequires, similar to
modern Python packaging. "dnf builddep" does not work for packages
that use this feature, unless you take additional steps (I think
running "rpmbuild -br" first). However, recommend *in the strongest
possible way I can* to use *mock* for building Rust packages.
Everything else is a way towards pain.

> Running "rpmbuild -bb" shows a bunch of unsatisfied deps, but I can't find all
> of them as prepackaged rpms.

As I mentioned, please do not build Rust packages on your host OS. Use
mock. It supports building packages that use dynamic BuildRequires
OOTB.

> The git-repository crate that stgit depends on, if I download it with crate
> install, it can't be installed as it doesn't have an executable in it.  I
> think the problem is that it's just a library.

You will need to package missing dependencies - like the
git-repository crate - separately (as rust-git-repository).
Running "cargo install" does not work for library-only crates. And I
don't know running "cargo install git-repository" would help you?
Package builds do not have internet access.

I haven't looked at all of them individually, but at a glance, almost
all dependencies of stgit should already be packaged for fedora:
https://github.com/stacked-git/stgit/blob/master/Cargo.toml#L19-L47

Only the git-repository crate is not packaged yet, as far as I can
see. Other than that, the only problem I see straight away is that we
don't have clap v4 in Fedora yet (because clap v4 started to use
features of cargo that our tools do not support yet).
Looking back at the history of stgit, it seems that all releases of it
already use clap v4, so that will be a problem until I have time to
fix our tools for https://bugzilla.redhat.com/show_bug.cgi?id=2152697
.

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

Re: F38 proposal: IoT Simplified Installer (Self-Contained Change proposal)

[Dan Čermák]

Hi Peter,

Peter Robinson  writes:

> On Wed, Jan 18, 2023 at 11:20 AM Dan Čermák
>  wrote:
>>
>> Ben Cotton  writes:
>>
>> > https://fedoraproject.org/wiki/Changes/IoTSimplifiedInstaller
>> >
>> > 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 ==
>> > Offer Fedora IoT users a new method to create and deploy customized
>> > Fedora IoT disk images using a new installer called Simplified
>> > Installer.
>> >
>> > == Owner ==
>> > * Name: [[User:runcom| Antonio Murdaca]], [[User:pwhalen| Paul Whalen]]
>> > * Email: amurd...@redhat.com, pwha...@fedoraproject.org
>> >
>> >
>> > == Detailed Description ==
>> > The Fedora IoT Simplified Installer will use coreos-installer to write
>> > an OStree raw image straight to a disk specified in a kernel argument,
>> > without the need for a kickstart or user interaction. This type of
>> > installation is ideal for devices connected at the edge where
>> > connectivity can be slow or intermittent. It offers the ability to
>> > configure the system via osbuild itself, FDO and Ignition.
>> >
>> > == Feedback ==
>> >
>> >
>> > == Benefit to Fedora ==
>> > The addition of the Fedora IoT Simplified Installer will benefit IoT
>> > users by allowing them to create customized disk images for use on
>> > their edge devices. This feature is already available downstream,
>> > adding it to Fedora will once again bring Fedora back to the true
>> > upstream of RHEL for edge and allows testing and adoption of new
>> > functionality like FIDO Device Onboarding.
>> >
>> > == Scope ==
>> > * Proposal owners:
>> > ** Test building Fedora IoT Simplified Installer with `osbuild-composer`
>> > ** Update Fedora IoT documentation with usage instructions.
>> >
>> > * Other developers:
>> >
>> > * Release engineering:
>> > * 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 ==
>> > * Not applicable to this change.
>> >
>> > == How To Test ==
>> > Testable by installing `osbuild-composer` in Fedora 38 and using the
>> > command line tool or the Cockpit web interface to create a Fedora IoT
>> > Simplified Installer iso to deploy a UEFI enabled edge device.
>> >
>> >
>> > == User Experience ==
>> > This change will greatly enhance the Fedora IoT user experience by
>> > allowing users to utilize `osbuild-composer` and blueprints to create
>> > customized Fedora IoT deployments and leverage new features like FIDO
>> > Device Onboarding for secure zero touch device onboarding of edge
>> > devices as well as Ignition to configure the device once it starts.
>>
>> Will it still be possible to use something simple like zezere /
>> provision.fedoraproject.org to deploy your ssh keys? I find that to be
>> one of the major advantage of Fedora IoT over all the other images for
>> the Raspberry Pi out there, as I can easily get the IP of my newly
>> setup device and push my ssh keys from FAS there without ever having to
>> bother with ignition.
>
> Yes, we're looking to revitalize zezere too but I think that will more
> likely be a F-39 feature at this stage.

Thanks for keeping this on the table!

I don't want to be demanding here, but I would personally prefer if
zezere stayed also for the interim period, but I completely understand
if that has a low priority.


Cheers,

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

Anyone know how to packet rust projects as rpms? stgit-2 specifically

[David Howells]

Hi,

Does anyone know how to package a rust project as an rpm on Fedora 37,
specifically stgit-2?

stgit, of which I make heavy use, has been rewritten in rust but I can't
manage to build it.

https://github.com/stacked-git/stgit

I've found rust2rpm to create a specfile, but that doesn't any insert
BuildRequires for "dnf builddep" to pick up.

Running "rpmbuild -bb" shows a bunch of unsatisfied deps, but I can't find all
of them as prepackaged rpms.

The git-repository crate that stgit depends on, if I download it with crate
install, it can't be installed as it doesn't have an executable in it.  I
think the problem is that it's just a library.

Thanks,
David
___
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: Yet another unwinding approach

[Mark Wielaard]

Hi Florian,

On Wed, 2023-01-18 at 15:01 +0100, Florian Weimer wrote:
> We won't have unwind data for JIT-compiled code, including libffi
> trampolines.  We could stop backtracing there (what does the ABI say
> about frames without unwinding information?), but I'm not sure if
> that's
> going to be useful for the desktop.

In this model, such generated code would register their own unwinder
(or .eh_frame contribution).

> > But it is something to keep in mind, accidents happen. I assume
> > that
> > any (seg) fault caused by the unwind signal thread will simply end
> > that
> > contribution of user space to the backtrace (instead of really
> > generating a SEGV)
> 
> That smells like SEH. 8-/

Sorry, I don't know what SEH means in this context and whether that is
good or bad thing (8-/ isn't part
of https://en.wikipedia.org/wiki/List_of_emoticons)

> > But it is tricky to handle that without kernel support. As a fallback
> > you could install a SIGSEGV handler that handles the fault and somehow
> > makes the original SIGPROF based handler (if you use that) sigreturn.
> 
> Signal handlers are process-wide, and SIGPROF does not suspend the
> entire process.  So I really don't think this can be made to work
> reliably without kernel support.

I don't think any sampling profile based backtrace support is going to
be perfect, but I don't think that is the goal. Even gdb won't be able
to create perfect backtraces all the time. We just need something that
works out of the box most of the time. kernel support would be nice,
but I don't think we shouldn't try some experimentation first before we
settle on the perfect kernel interface. Whatever we can do in user
space we should first try out in user space imho.

Cheers,

Mark
___
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: Yet another unwinding approach

[Jakub Jelinek]

On Wed, Jan 18, 2023 at 03:01:19PM +0100, Florian Weimer wrote:
> > On Wed, 2023-01-18 at 07:22 +0100, Florian Weimer wrote:
> 
> >> If the unwind information is incomplete, this …
> >> 
> >> > 7) signal handler unwinds the calling thread however it wants (and can
> >> > sleep and take page faults if needed)
> >> 
> >> … might encounter segmentation faults and terminate the process.  So
> >> far, incorrect unwind information (whether it's a clobbered frame
> >> pointer, or missing DWARF information about clobbered registers) is not
> >> a problem, but it's kind of hard to validate this information from
> >> within the process itself.  Maybe we'd have to add a magic memcpy first
> >> to the vDSO, which the kernel recognizes based on the code addresses,
> >> and suppresses sending the signal for it.
> >
> > Yeah, I am not too afraid of that happening with an .eh_frame based
> > unwinder unless someone deliberately produced a bad table (or dlcloses
> > a library which still has code on the call stack). You still have to be
> > careful about the stack bounds of course.
> 
> We won't have unwind data for JIT-compiled code, including libffi
> trampolines.  We could stop backtracing there (what does the ABI say
> about frames without unwinding information?), but I'm not sure if that's
> going to be useful for the desktop.

I think some JITs register their on the fly created unwind info using
__{,de}register_frame_info* APIs (at least I think that was the reason
of Thomas Neumann's libgcc unwinder changes).

Jakub
___
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: Yet another unwinding approach

[Florian Weimer]

* Mark Wielaard:

> On Wed, 2023-01-18 at 07:22 +0100, Florian Weimer wrote:

>> If the unwind information is incomplete, this …
>> 
>> > 7) signal handler unwinds the calling thread however it wants (and can
>> > sleep and take page faults if needed)
>> 
>> … might encounter segmentation faults and terminate the process.  So
>> far, incorrect unwind information (whether it's a clobbered frame
>> pointer, or missing DWARF information about clobbered registers) is not
>> a problem, but it's kind of hard to validate this information from
>> within the process itself.  Maybe we'd have to add a magic memcpy first
>> to the vDSO, which the kernel recognizes based on the code addresses,
>> and suppresses sending the signal for it.
>
> Yeah, I am not too afraid of that happening with an .eh_frame based
> unwinder unless someone deliberately produced a bad table (or dlcloses
> a library which still has code on the call stack). You still have to be
> careful about the stack bounds of course.

We won't have unwind data for JIT-compiled code, including libffi
trampolines.  We could stop backtracing there (what does the ABI say
about frames without unwinding information?), but I'm not sure if that's
going to be useful for the desktop.

> But it is something to keep in mind, accidents happen. I assume that
> any (seg) fault caused by the unwind signal thread will simply end that
> contribution of user space to the backtrace (instead of really
> generating a SEGV)

That smells like SEH. 8-/

> But it is tricky to handle that without kernel support. As a fallback
> you could install a SIGSEGV handler that handles the fault and somehow
> makes the original SIGPROF based handler (if you use that) sigreturn.

Signal handlers are process-wide, and SIGPROF does not suspend the
entire process.  So I really don't think this can be made to work
reliably without kernel support.

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

[Bug 2159980] F38FailsToInstall: fusioninventory-agent-task-inventory

[bugzilla]

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

Fedora Fails To Install  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |WORKSFORME
Last Closed||2023-01-18 13:59:10



--- Comment #2 from Fedora Fails To Install  ---
Hello,

Please note that this comment was generated automatically by
https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py
If you feel that this output has mistakes, please open an issue at
https://pagure.io/releng/

All subpackages of a package against which this bug was filled are now
installable or removed from Fedora 38.

Thanks for taking care of it!


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2159980
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: List of long term FTBFS packages to be retired in February​

[Miro Hrončok]

On 18. 01. 23 14:29, Olivier Fourdan wrote:

On Wed, Jan 18, 2023 at 2:20 PM Miro Hrončok  wrote:

[…]

I've triggered the build (any packager can do that):

$ koji build rawhide --nowait --fail-fast
'git+https://src.fedoraproject.org/rpms/xorg-x11-drv-qxl.git#d7716591515d97b5cc4a146fbcf3ee7ca18f1808'
Created task: 96293694
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=96293694


Then I guess the issue is sorted now.


Yes, thank you!

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

Re: List of long term FTBFS packages to be retired in February​

[Olivier Fourdan]

On Wed, Jan 18, 2023 at 2:20 PM Miro Hrončok  wrote:
> […]
>
> I've triggered the build (any packager can do that):
>
> $ koji build rawhide --nowait --fail-fast
> 'git+https://src.fedoraproject.org/rpms/xorg-x11-drv-qxl.git#d7716591515d97b5cc4a146fbcf3ee7ca18f1808'
> Created task: 96293694
> Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=96293694

Then I guess the issue is sorted now.

Cheers
Olivier
___
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: IoT Simplified Installer (Self-Contained Change proposal)

[Peter Robinson]

On Wed, Jan 18, 2023 at 11:20 AM Dan Čermák
 wrote:
>
> Ben Cotton  writes:
>
> > https://fedoraproject.org/wiki/Changes/IoTSimplifiedInstaller
> >
> > 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 ==
> > Offer Fedora IoT users a new method to create and deploy customized
> > Fedora IoT disk images using a new installer called Simplified
> > Installer.
> >
> > == Owner ==
> > * Name: [[User:runcom| Antonio Murdaca]], [[User:pwhalen| Paul Whalen]]
> > * Email: amurd...@redhat.com, pwha...@fedoraproject.org
> >
> >
> > == Detailed Description ==
> > The Fedora IoT Simplified Installer will use coreos-installer to write
> > an OStree raw image straight to a disk specified in a kernel argument,
> > without the need for a kickstart or user interaction. This type of
> > installation is ideal for devices connected at the edge where
> > connectivity can be slow or intermittent. It offers the ability to
> > configure the system via osbuild itself, FDO and Ignition.
> >
> > == Feedback ==
> >
> >
> > == Benefit to Fedora ==
> > The addition of the Fedora IoT Simplified Installer will benefit IoT
> > users by allowing them to create customized disk images for use on
> > their edge devices. This feature is already available downstream,
> > adding it to Fedora will once again bring Fedora back to the true
> > upstream of RHEL for edge and allows testing and adoption of new
> > functionality like FIDO Device Onboarding.
> >
> > == Scope ==
> > * Proposal owners:
> > ** Test building Fedora IoT Simplified Installer with `osbuild-composer`
> > ** Update Fedora IoT documentation with usage instructions.
> >
> > * Other developers:
> >
> > * Release engineering:
> > * 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 ==
> > * Not applicable to this change.
> >
> > == How To Test ==
> > Testable by installing `osbuild-composer` in Fedora 38 and using the
> > command line tool or the Cockpit web interface to create a Fedora IoT
> > Simplified Installer iso to deploy a UEFI enabled edge device.
> >
> >
> > == User Experience ==
> > This change will greatly enhance the Fedora IoT user experience by
> > allowing users to utilize `osbuild-composer` and blueprints to create
> > customized Fedora IoT deployments and leverage new features like FIDO
> > Device Onboarding for secure zero touch device onboarding of edge
> > devices as well as Ignition to configure the device once it starts.
>
> Will it still be possible to use something simple like zezere /
> provision.fedoraproject.org to deploy your ssh keys? I find that to be
> one of the major advantage of Fedora IoT over all the other images for
> the Raspberry Pi out there, as I can easily get the IP of my newly
> setup device and push my ssh keys from FAS there without ever having to
> bother with ignition.

Yes, we're looking to revitalize zezere too but I think that will more
likely be a F-39 feature at this stage.
___
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: List of long term FTBFS packages to be retired in February​

[Miro Hrončok]

On 18. 01. 23 14:16, Olivier Fourdan wrote:

Hi

On Wed, Jan 18, 2023 at 1:58 PM Miro Hrončok  wrote:


Based on the current fail to build from source policy, the following packages
should be retired from Fedora 38 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
approximately in 5 weeks, i.e. around 2023-02-08.
Since this is unfortunately after the branching,
packages will be retired on rawhide and f38.

This is the second reminder. I apologize for starting this process a bit later
than required.

Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

The packages in rawhide were not successfully built at least since Fedora 35.

This report is based on dist tags.
[…]
xorg-x11-drv-qxl   airlied, alon, elmarco,
 jwrdegoede, ssp, teuf,
 victortoso


I had filed https://src.fedoraproject.org/rpms/xorg-x11-drv-qxl/pull-request/2
to fix the build in rawhide and Victor merged it 5 days ago.

The scratch built worked:
https://koji.fedoraproject.org/koji/taskinfo?taskID=96082966

I can't find the build there though
https://koji.fedoraproject.org/koji/packageinfo?packageID=9868


I've triggered the build (any packager can do that):

$ koji build rawhide --nowait --fail-fast 
'git+https://src.fedoraproject.org/rpms/xorg-x11-drv-qxl.git#d7716591515d97b5cc4a146fbcf3ee7ca18f1808'

Created task: 96293694
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=96293694

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

Re: List of long term FTBFS packages to be retired in February​

[Olivier Fourdan]

Hi

On Wed, Jan 18, 2023 at 1:58 PM Miro Hrončok  wrote:
>
> Based on the current fail to build from source policy, the following packages
> should be retired from Fedora 38 approximately one week before branching.
>
> 5 weekly reminders are required, hence the retirement will happen
> approximately in 5 weeks, i.e. around 2023-02-08.
> Since this is unfortunately after the branching,
> packages will be retired on rawhide and f38.
>
> This is the second reminder. I apologize for starting this process a bit later
> than required.
>
> Policy:
> https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
>
> The packages in rawhide were not successfully built at least since Fedora 35.
>
> This report is based on dist tags.
> […]
> xorg-x11-drv-qxl   airlied, alon, elmarco,
> jwrdegoede, ssp, teuf,
> victortoso

I had filed https://src.fedoraproject.org/rpms/xorg-x11-drv-qxl/pull-request/2
to fix the build in rawhide and Victor merged it 5 days ago.

The scratch built worked:
https://koji.fedoraproject.org/koji/taskinfo?taskID=96082966

I can't find the build there though
https://koji.fedoraproject.org/koji/packageinfo?packageID=9868

Cheers
Olivier
___
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: List of long term FTBFS packages to be retired in February​

[Miro Hrončok]

On 18. 01. 23 14:06, Neal Gompa wrote:

ngompa: xorg-x11-drv-qxl, golang-gopkg-mgo-2

Uhh, what? Why am I associated with the QXL driver?


livecd-tools -> lorax -> lorax -> anaconda -> xorg-x11-drivers -> 
xorg-x11-drv-qxl

livecd-tools (maintained by: bcl, bruno, ngompa)
python-imgcreate-sysdeps-1:31.0-2.fc37.x86_64 requires lorax = 38.4-2.fc38

lorax (maintained by: bcl, clumens, dcantrell, dshea, wwoods)
lorax-lmc-novirt-38.4-2.fc38.x86_64 requires anaconda-core = 38.15-1.fc38, 
anaconda-install-env-deps = 38.15-1.fc38, anaconda-tui = 38.15-1.fc38


anaconda (maintained by: anaconda-maint, jkonecny, m4rtink, rvykydal, 
vladimirslavik, vponcova)
anaconda-install-img-deps-38.15-1.fc38.x86_64 requires xorg-x11-drivers = 
2022-3.fc38



xorg-x11-drivers (maintained by: airlied, ajax, alexl, caolanm, glisse, 
mbarnes, rhughes, rstrode, ssp, whot)

xorg-x11-drivers-2022-3.fc38.x86_64 requires xorg-x11-drv-qxl = 
0.1.5-20.fc35

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

Re: List of long term FTBFS packages to be retired in February​

[Neal Gompa]

On Wed, Jan 18, 2023 at 7:58 AM Miro Hrončok  wrote:
>
> Dear maintainers.
>
> Based on the current fail to build from source policy, the following packages
> should be retired from Fedora 38 approximately one week before branching.
>
> 5 weekly reminders are required, hence the retirement will happen
> approximately in 5 weeks, i.e. around 2023-02-08.
> Since this is unfortunately after the branching,
> packages will be retired on rawhide and f38.
>
> This is the second reminder. I apologize for starting this process a bit later
> than required.
>
> Policy:
> https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
>
> The packages in rawhide were not successfully built at least since Fedora 35.
>
> This report is based on dist tags.
>
> Packages collected via:
> https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb
>
> If you see a package that was built, please let me know.
> If you see a package that should be exempted from the process,
> please let me know and we can work together to get a FESCo approval for that.

[...]

> ngompa: xorg-x11-drv-qxl, golang-gopkg-mgo-2

Uhh, what? Why am I associated with the QXL driver?


-- 
Neal Gompa (FAS: ngompa)
___
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 proposal: Remove pam_console (System-Wide Change proposal)

[Iker Pedrosa]

Hi Dmitry,

If I understand it correctly, what you mean is that once a user is
authenticated in a system with pam_console, then all subsequent
authentication attempts by this user are successful without having to input
the password. This is kind of dangerous, as somebody could open a session
for an already authenticated user without them knowing it. I'd recommend
you to use pam_timestamp instead, as it offers the same functionality with
additional security features (authentication origin, timeout, etc.).

On Tue, Jan 17, 2023 at 3:48 PM Dmitry Butskoy  wrote:

> Ben Cotton wrote:
> > == Summary ==
> > Remove pam_console as it is not enabled by default, can be replaced by
> > systemd and has security issues.
>
> Just to make sure -- pam_console provided an "auth" feature (see
> https://bugzilla.redhat.com/show_bug.cgi?id=137802 ), which allows to
> log just once when working on several virtual consoles (and yes, it was
> 19 years ago :) ). Is it possible with systemd-logind now?
>
>
> ~buc
> ___
> 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
>


-- 

Iker Pedrosa

Software Engineer, Identity Management team

Red Hat 

Txapela (gorria) buruan eta ibili munduan

(Red) hat on his head and walk the world

Basque proverb

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

Fedora rawhide compose report: 20230118.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230117.n.0
NEW: Fedora-Rawhide-20230118.n.0

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

Size of added packages:  1.19 MiB
Size of dropped packages:318.68 KiB
Size of upgraded packages:   3.92 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20230118.n.0.iso
Image: Server_KVM qcow2 ppc64le
Path: Server/ppc64le/images/Fedora-Server-KVM-Rawhide-20230118.n.0.ppc64le.qcow2

= DROPPED IMAGES =
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20230117.n.0.s390x.tar.xz
Image: Workstation live ppc64le
Path: 
Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-Rawhide-20230117.n.0.iso

= ADDED PACKAGES =
Package: alure-1.2-26.fc38
Summary: Audio Library Tools REloaded
RPMs:alure alure-devel
Size:533.99 KiB

Package: perl-Parse-EDID-1.0.7-14.fc38
Summary: Extended display identification data (EDID) parser
RPMs:perl-Parse-EDID
Size:28.25 KiB

Package: python-flake8-builtins-2.1.0-1.fc38
Summary: Check for python builtins being used as variables or parameters
RPMs:python3-flake8-builtins
Size:25.07 KiB

Package: python-pyproject-hooks-1.0.0-2.fc38
Summary: Wrappers to call pyproject.toml-based build backend hooks
RPMs:python3-pyproject-hooks
Size:31.91 KiB

Package: wult-1.10.54-1.fc38
Summary: A tool for measuring C-state latency in Linux
RPMs:python3-wult wult
Size:604.34 KiB


= DROPPED PACKAGES =
Package: ansible-collection-google-cloud-1.0.2-4.fc37
Summary: Google Cloud Platform collection
RPMs:ansible-collection-google-cloud
Size:318.68 KiB


= UPGRADED PACKAGES =
Package:  GtkAda-2.24.2-41.fc38
Old package:  GtkAda-2.24.2-40.fc37
Summary:  GTKada 2, an Ada binding to GTK+ 2
RPMs: GtkAda GtkAda-devel GtkAda-doc GtkAda-gl GtkAda-gnome
Size: 22.33 MiB
Size change:  198.10 KiB
Changelog:
  * Tue Jan 17 2023 Bj??rn Persson  - 2.24.2-41
  - Rebuilt with GCC 13.


Package:  GtkAda3-2020-8.fc38
Old package:  GtkAda3-2020-7.fc37
Summary:  GTKada 3, an Ada binding to GTK+ 3
RPMs: GtkAda3 GtkAda3-devel GtkAda3-doc GtkAda3-gl
Size: 31.51 MiB
Size change:  79.71 KiB
Changelog:
  * Tue Jan 17 2023 Bj??rn Persson  - 2020-8
  - Rebuilt with GCC 13.


Package:  PragmARC-20130728-28.fc38
Old package:  PragmARC-20130728-27.fc37
Summary:  PragmAda Reusable Components, a component library for Ada
RPMs: PragmARC PragmARC-devel
Size: 1.42 MiB
Size change:  10.78 KiB
Changelog:
  * Tue Jan 17 2023 Bj??rn Persson  - 20130728-28
  - Rebuilt with GCC 13.


Package:  Singular-4.3.1p1-1.fc38
Old package:  Singular-4.2.1p3-3.fc37
Summary:  Computer Algebra System for polynomial computations
RPMs: Singular Singular-devel Singular-doc Singular-emacs 
Singular-libpolys Singular-libpolys-devel Singular-libs factory factory-devel 
factory-gftables
Dropped RPMs: Singular-surfex
Size: 96.27 MiB
Size change:  803.59 KiB
Changelog:
  * Mon Jan 16 2023 Jerry James  - 4.3.1p1-1
  - Version 4.3.1p1
  - Remove the surfex subpackage
  - Drop upstreamed -format-specifier and -gcc12 patches
  - Drop obsolete -javac patch
  - Convert License tags to SPDX
  - Reenable building the index on ppc64le


Package:  abc-1.01-36.git20221229.fc38
Old package:  abc-1.01-35.git20220731.fc37
Summary:  Sequential logic synthesis and formal verification
RPMs: abc abc-devel abc-libs
Size: 29.38 MiB
Size change:  1.31 MiB
Changelog:
  * Tue Jan 17 2023 Jerry James  - 1.01-36.git20221229
  - Update to latest git snapshot
  - Add -use-after-free, -null-fprintf, and -weaken-assert patches
  - Minor spec file cleanups


Package:  ahven-2.8-5.fc38
Old package:  ahven-2.8-4.fc37
Summary:  A unit testing framework for Ada 95
RPMs: ahven ahven-devel
Size: 1.75 MiB
Size change:  25.61 KiB
Changelog:
  * Tue Jan 17 2023 Bj??rn Persson  - 2.8-5
  - Rebuilt with GCC 13.


Package:  anet-0.4.1-13.fc38
Old package:  anet-0.4.1-12.fc37
Summary:  Ada Networking Library
RPMs: anet anet-devel
Size: 909.70 KiB
Size change:  8.79 KiB
Changelog:
  * Tue Jan 17 2023 Bj??rn Persson  - 0.4.1-13
  - Rebuilt with GCC 13.


Package:  arpwatch-14:3.3-10.fc38
Old package:  arpwatch-14:3.3-9.fc38
Summary:  Network monitoring tools for tracking IP addresses on a network
RPMs: arpwatch
Size: 1.33 MiB
Size change:  5.46 KiB
Changelog:
  * Wed Jan 18 2023 Benjamin A. Beasley  - 14:3.3-10
  - Generate ethercodes.dat from latest oui.csv


Package:  aws-2020-9.fc38
Old package:  aws-2020-8.fc37
Summary:  Ada Web Server

Re: F38 proposal: IoT Simplified Installer (Self-Contained Change proposal)

[Dan Čermák]

Ben Cotton  writes:

> https://fedoraproject.org/wiki/Changes/IoTSimplifiedInstaller
>
> 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 ==
> Offer Fedora IoT users a new method to create and deploy customized
> Fedora IoT disk images using a new installer called Simplified
> Installer.
>
> == Owner ==
> * Name: [[User:runcom| Antonio Murdaca]], [[User:pwhalen| Paul Whalen]]
> * Email: amurd...@redhat.com, pwha...@fedoraproject.org
>
>
> == Detailed Description ==
> The Fedora IoT Simplified Installer will use coreos-installer to write
> an OStree raw image straight to a disk specified in a kernel argument,
> without the need for a kickstart or user interaction. This type of
> installation is ideal for devices connected at the edge where
> connectivity can be slow or intermittent. It offers the ability to
> configure the system via osbuild itself, FDO and Ignition.
>
> == Feedback ==
>
>
> == Benefit to Fedora ==
> The addition of the Fedora IoT Simplified Installer will benefit IoT
> users by allowing them to create customized disk images for use on
> their edge devices. This feature is already available downstream,
> adding it to Fedora will once again bring Fedora back to the true
> upstream of RHEL for edge and allows testing and adoption of new
> functionality like FIDO Device Onboarding.
>
> == Scope ==
> * Proposal owners:
> ** Test building Fedora IoT Simplified Installer with `osbuild-composer`
> ** Update Fedora IoT documentation with usage instructions.
>
> * Other developers:
>
> * Release engineering:
> * 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 ==
> * Not applicable to this change.
>
> == How To Test ==
> Testable by installing `osbuild-composer` in Fedora 38 and using the
> command line tool or the Cockpit web interface to create a Fedora IoT
> Simplified Installer iso to deploy a UEFI enabled edge device.
>
>
> == User Experience ==
> This change will greatly enhance the Fedora IoT user experience by
> allowing users to utilize `osbuild-composer` and blueprints to create
> customized Fedora IoT deployments and leverage new features like FIDO
> Device Onboarding for secure zero touch device onboarding of edge
> devices as well as Ignition to configure the device once it starts.

Will it still be possible to use something simple like zezere /
provision.fedoraproject.org to deploy your ssh keys? I find that to be
one of the major advantage of Fedora IoT over all the other images for
the Raspberry Pi out there, as I can easily get the IP of my newly
setup device and push my ssh keys from FAS there without ever having to
bother with ignition.


Cheers,

Dan
___
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: Yet another unwinding approach

[Mark Wielaard]

Hi Florian,

On Wed, 2023-01-18 at 07:22 +0100, Florian Weimer wrote:
> * Daniel Colascione:
> 
> > See, both pro-FP and anti-FP camps think that it's the kernel that has
> > to do the unwinding unless we copy whole stacks into traces.
> 
> Well, I think we should explore hardware-assisted backtraces (shadow
> stacks), which hopefully are going to get merged in Linux 6.2.

Yes, that is also a good alternative if available. The shadow stack
seems to be ideal because it is just the function return addresses,
which basically is just the backtrace you are looking for.

> If the unwind information is incomplete, this …
> 
> > 7) signal handler unwinds the calling thread however it wants (and can
> > sleep and take page faults if needed)
> 
> … might encounter segmentation faults and terminate the process.  So
> far, incorrect unwind information (whether it's a clobbered frame
> pointer, or missing DWARF information about clobbered registers) is not
> a problem, but it's kind of hard to validate this information from
> within the process itself.  Maybe we'd have to add a magic memcpy first
> to the vDSO, which the kernel recognizes based on the code addresses,
> and suppresses sending the signal for it.

Yeah, I am not too afraid of that happening with an .eh_frame based
unwinder unless someone deliberately produced a bad table (or dlcloses
a library which still has code on the call stack). You still have to be
careful about the stack bounds of course.

But it is something to keep in mind, accidents happen. I assume that
any (seg) fault caused by the unwind signal thread will simply end that
contribution of user space to the backtrace (instead of really
generating a SEGV)

But it is tricky to handle that without kernel support. As a fallback
you could install a SIGSEGV handler that handles the fault and somehow
makes the original SIGPROF based handler (if you use that) sigreturn.

Cheers,

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

Anaconda new Web UI is looking for your feedback!

[Jiri Konecny]

Hello everyone,

Anaconda team would like to ask you for your feedback. We are trying to 
design the storage partitioning for the new Web UI correctly and for 
that we would like to find out  how you use your storage. Please help us 
by filling in this questionnaire so we can make correct decisions!


The link to the questionnaire is in the blog post here:
https://fedoramagazine.org/anaconda-web-ui-storage-feedback-requested/#comment-544800

Best Regards,
Jirka
___
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

F38 mass rebuild is waiting for gcc build

[Tomas Hrcka]

Hi,

today is the day we are running a mass rebuild. Usually we start at 10:30am UTC.
Today we will wait for the latest GCC build[1] to get finished and
start a few hours later.


[1] - https://koji.fedoraproject.org/koji/taskinfo?taskID=96265376
-- 
Tomas Hrcka
Fedora Release Engineering
fas: humaton
libera: jednorozec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to build two flavors of the same package?

[Iñaki Ucar]

On Tue, 17 Jan 2023 at 22:28, Till Hofmann  wrote:
>
> Hi all,
>
> Someone (rightfully) suggested that we should build glfw twice, once
> with wayland support and once without:
> https://bugzilla.redhat.com/show_bug.cgi?id=2152319
>
> Is there any best practice how to build the same package in two
> different flavors, in this case cmake-based? I vaguely remember seeing a
> spec file that did that, but I don't remember where.
>
> Thanks for any pointers!

In flexiblas.spec, for 64-bit BLAS, we do

%build
%cmake -B build \

%make_build -C build
%if 0%{?__isa_bits} == 64
%cmake -B build64 \

%make_build -C build64
%endif

%install
%make_install -C build
%if 0%{?__isa_bits} == 64
%make_install -C build64
%endif

etc.

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

[Bug 2161894] New: Branch Request: perl-Net-GitHub for epel8

[bugzilla]

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

Bug ID: 2161894
   Summary: Branch Request: perl-Net-GitHub for epel8
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-Net-GitHub
  Assignee: lkund...@v3.sk
  Reporter: fed...@mj41.cz
QA Contact: extras...@fedoraproject.org
CC: jpazdzi...@redhat.com, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Hello,

Would you be so kind to build perl-Net-GitHub for EPEL8?

Thank you.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161894
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC 13 broke 50 packages requiring libgnat-12.so() and libgnarl-12.so()

[Frederic Berat]

On Wed, Jan 18, 2023 at 4:07 AM John Reiser  wrote:
>
> On 1/17/23 14:37, Björn Persson wrote:
>
> > So as things stand, these rebuilds need to be done by a human who knows
> > the dependency graph.
>
> Requiring "a human who knows the dependency graph" is *severely* broken.
> There should be a shell script which computes an acceptable order from the
> old installed version, and outputs the order for examination and modification.
> Probably the script involves ldd, "readelf --dynamic", and tsort.
> For new dependencies the script may need to be re-run during the builds.

I'm afraid, as of today, that can't be generalized without human
intervention. This may work with difficulty for binary packages, but
even then not in the general case. Take alone circular dependencies
that are due to documentation being generated, but that would be the
simplest case.

We are trying to solve this kind of problem in the mass pre-builder
project [1], if we succeed to do so, we have hope that the code base
could be used as a basis for all use cases that involve mass building
(whether it is Fedora mass rebuild or CI building reverse dependencies
for stability QE). Any help that would improve the code base and help
us move towards this is more than welcome.

In the current state, the mass prebuilder may try to calculate
building priorities based on the information collected out of the
dependency graph, but this has major flows:
1) Assumptions are made in order to break the circular dependencies
that are unlikely to be generally accurate
2) The calculation is computationally expensive (seems subjectively
exponential), and can't be realistically used for more than 2 or 3
thousand packages. (e.g. GCC and its 10k reverse dependencies is a
no-go)

For some use cases, as of now it looks more realistic to use brute
force (try to build until it works, or a general failure is
subjectively declared) unless someone with proper knowledge specifies
a meaningful list.

[1] https://gitlab.com/fedora/packager-tools/mass-prebuild
___
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