[Test-Announce] Fedora 38 Candidate RC-1.4 Available Now!

[rawhide]

According to the schedule [1], Fedora 38 Candidate RC-1.4 is now
available for testing. Please help us complete all the validation
testing! For more information on 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/38

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_38_RC_1.4_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_38_RC_1.4_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_38_RC_1.4_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_38_RC_1.4_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_38_RC_1.4_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_38_RC_1.4_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_38_RC_1.4_Security_Lab

All RC priority test cases for each of these test pages [2] must
pass in order to meet the RC Release Criteria [3].

Help is available on #fedora-qa on libera.chat [4], or on the
test list [5].

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-38/f-38-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_38_RC_Release_Criteria
[4] https://web.libera.chat/?channels=#fedora-qa
[5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
___
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

Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

[Jeff Law]

On 4/11/23 19:14, przemek klosowski via devel wrote:

On 4/4/23 10:28, Dan Čermák wrote:

Chris Adams  writes:


Yeah, it'd be back to the i386/i586/i686 days... which was a bit of a
PITA sometimes.  But cramming multiple architectures of core libraries
into a single RPM would be bad for disk space, image size, downloads,
etc.

But something that didn't exist in the i386/i686 days is containers -
whether base images like for podman or full things like Flatpaks.
Before going too deep into multi-level architectures, that should be
taken into account.

Afaik at least container runtimes do not support really support x86_64
subarchitectures: https://github.com/containers/podman/discussions/15256


The situation in the RISC-V universe is even more complicated because of 
all the extensions


https://en.wikichip.org/wiki/risc-v/standard_extensions

It'll be challenging to write and package software that is portable 
between all those variants---the fat binaries are just not practical due 
to combinatorial complexity, so it'll have to be either install-time or 
link-time configuration.


Whatever standard scheme Fedora uses for x86 will hopefully be very 
useful for RiSC-V era that is apparently coming, with Linux-capable SBC 
boards like VisionFive ($65)  and Pine64 ($70 and $8 (!) ox64) just 
becoming available, and a lot of activity on the horizon.
Rather than trying to track all the individual extensions and 
combinations thereof, I would suggest focusing on RVI defined profiles. 
Essentially they provide a set of mandatory features the architecture 
must support (to be compliant with the profile).


That may rule out certain processors, but it ultimately provides a 
higher performing baseline architecture for systems that are (hopefully) 
going to be good performing parts rather than embedded focused parts.


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

Re: Any interest in maintaining spyder (python IDE)?

[Jonathan Wright via devel]

If you can do a review on
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2186056 it will help
unblock the updates.

On Tue, Apr 4, 2023 at 8:46 PM Mukundan Ragavan 
wrote:

>
> On 4/3/23 12:53, Blaise Pabon wrote:
>
> Hi Mukundan, Jonathan,
>
> I have been working on becoming a fedora maintainer and I would love to
> help.
> When I followed the links to the build logs I got a 404.
>
> Blaise
>
>
>
> Hi Blaise,
>
> I will be happy to help you with becoming a packager. I am also happy to
> add you as a collaborator on my COPR.
>
> Build logs may have been deleted since these packages were built sometime
> ago.
>
> Let me know if you would like to be added to COPR.
>
> Mukundan.
>
> --
> GPG Key: E5C8BC67
>
>

-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
___
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

subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

[przemek klosowski via devel]

On 4/4/23 10:28, Dan Čermák wrote:

Chris Adams  writes:


Yeah, it'd be back to the i386/i586/i686 days... which was a bit of a
PITA sometimes.  But cramming multiple architectures of core libraries
into a single RPM would be bad for disk space, image size, downloads,
etc.

But something that didn't exist in the i386/i686 days is containers -
whether base images like for podman or full things like Flatpaks.
Before going too deep into multi-level architectures, that should be
taken into account.

Afaik at least container runtimes do not support really support x86_64
subarchitectures: https://github.com/containers/podman/discussions/15256


The situation in the RISC-V universe is even more complicated because of 
all the extensions


https://en.wikichip.org/wiki/risc-v/standard_extensions

It'll be challenging to write and package software that is portable 
between all those variants---the fat binaries are just not practical due 
to combinatorial complexity, so it'll have to be either install-time or 
link-time configuration.


Whatever standard scheme Fedora uses for x86 will hopefully be very 
useful for RiSC-V era that is apparently coming, with Linux-capable SBC 
boards like VisionFive ($65)  and Pine64 ($70 and $8 (!) ox64) just 
becoming available, and a lot of activity on the horizon.


https://www.reddit.com/r/RISCV/comments/11wdk2i/riscv_linux_sbcs_how_are_we_doing/
___
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: default bash history (non)preservation

[Todd Zullinger]

Chris Adams wrote:
> Once upon a time, Michael Catanzaro  said:
>> On Tue, Apr 11 2023 at 12:18:58 PM -0500, Chris Adams
>>  wrote:
>>>I wouldn't do that part; that's additional disk I/O for every prompt.
>>>Especially when the system might be having issues, users (especially
>>>root) don't need something interfering with every command.  This would
>>>mean an NFS home would insta-hang at the slightest issue.
>> 
>> Hm, but consider also that if the filesystem is slow or unreliable,
>> then your entire desktop is going to hang as well. (It probably
>> _shouldn't_ hang, but it absolutely does.) You cannot even open
>> gnome-terminal until the I/O operations complete. With that baseline
>> in mind, I'd say the benefits outweigh the costs, but we should make
>> it easy to opt out somehow.
> 
> You are assuming Fedora is only used for desktops.

Indeed.  I think that setting PROMPT_COMMAND as an array in
the default configuration would be the place to start.  Then
packages which enable such functionality can be added with
more granularity.

If the desktop working group wants to default to having such
a configuration enabled, it can be done without affecting
the server images, etc.  And folks can easily opt-out even
on the desktop.  (I'd still prefer if it was opt-in for the
desktop, but that's just an opinion.)

That makes it easier to add snippets to /etc/profile.d
rather than coordinating everything via the setup package.
Hard-coding a default for everyone which leaves a good
number of folks unhappy in either case is not ideal.

-- 
Todd


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: default bash history (non)preservation

[Chris Adams]

Once upon a time, Michael Catanzaro  said:
> On Tue, Apr 11 2023 at 12:18:58 PM -0500, Chris Adams
>  wrote:
> >I wouldn't do that part; that's additional disk I/O for every prompt.
> >Especially when the system might be having issues, users (especially
> >root) don't need something interfering with every command.  This would
> >mean an NFS home would insta-hang at the slightest issue.
> 
> Hm, but consider also that if the filesystem is slow or unreliable,
> then your entire desktop is going to hang as well. (It probably
> _shouldn't_ hang, but it absolutely does.) You cannot even open
> gnome-terminal until the I/O operations complete. With that baseline
> in mind, I'd say the benefits outweigh the costs, but we should make
> it easy to opt out somehow.

You are assuming Fedora is only used for desktops.
-- 
Chris Adams 
___
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: default bash history (non)preservation

[Michael Catanzaro]

On Tue, Apr 11 2023 at 12:18:58 PM -0500, Chris Adams 
 wrote:

I wouldn't do that part; that's additional disk I/O for every prompt.
Especially when the system might be having issues, users (especially
root) don't need something interfering with every command.  This would
mean an NFS home would insta-hang at the slightest issue.


Hm, but consider also that if the filesystem is slow or unreliable, 
then your entire desktop is going to hang as well. (It probably 
_shouldn't_ hang, but it absolutely does.) You cannot even open 
gnome-terminal until the I/O operations complete. With that baseline in 
mind, I'd say the benefits outweigh the costs, but we should make it 
easy to opt out somehow.


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: default bash history (non)preservation

[Roberto Ragusa]

On 4/11/23 19:20, Adam Williamson wrote:


The version I use is a file in /etc/profile.d that does this:

HISTSIZE=1048576
HISTFILESIZE=1048576

LAST_HISTORY_WRITE=$SECONDS
function prompt_command {
 if [ $(($SECONDS - $LAST_HISTORY_WRITE)) -gt 60 ]; then
 history -a && history -c && history -r
 LAST_HISTORY_WRITE=$SECONDS
 fi
}

PROMPT_COMMAND="${PROMPT_COMMAND:-:} ; prompt_command"

so I guess that's the difference; mine clears and reloads the history
(if it's been more than 60 seconds since the last time it did it).


Very similar to what I've been using for years, in /etc/profile.d

HISTSIZE=19
PROMPT_COMMAND='if [ $SECONDS -gt $[${lastsavedhistory-0}+10] ]; then history -a; 
lastsavedhistory="$SECONDS"; fi; '"$PROMPT_COMMAND"

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: default bash history (non)preservation

[Todd Zullinger]

Chris Murphy wrote:
> I've implemented the suggested two line change to
> .bash_profile:
> 
> # User specific environment and startup programs
> shopt -s histappend
> PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
> 
[...]
> Any thoughts?

As others have said, enabling this by default has
consequences which would make a good number of folks
unhappy, so it's probably not an ideal candidate to enable
by default.

One thing worth noting, I think, is that since bash-5.1,
PROMPT_COMMAND may be an array.  This lends itself to adding
something in /etc/profile.d which appends 'history -a' to
the PROMPT_COMMAND array, e.g.:

PROMPT_COMMAND+=( history -a )

(which would grow half a dozen or so lines with the needed
checking that 'history -a' wasn't already present, that
PROMPT_COMMAND was an array instead of a string, etc.)

I don't believe that Fedora's defaults from the setup
package currently use an array, so perhaps working toward
that change would be a good first step.  Once in place, a
package which provides the history appending behavior could
be easily added and those who prefer it could install it.

-- 
Todd


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: [HEADS UP] util-linux based on new mount API coming to rawhide/f39

[Jonathan Lebon]

On Tue, Apr 11, 2023 at 1:05 PM Colin Walters  wrote:
> Looks like this broke our mounting of zram:
>
> https://github.com/coreos/fedora-coreos-tracker/issues/1462

To follow up on this, I filed
https://github.com/util-linux/util-linux/issues/2161 upstream with the
requested logs.
___
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: default bash history (non)preservation

[Richard W.M. Jones]

On Tue, Apr 11, 2023 at 10:48:11AM -0400, Chris Murphy wrote:
> Hi,
> 
> For a long time I've noticed lost history from multiple Terminal tab/windows. 
> It seems like the last tab or window to close is the history that gets 
> written to .bash_history, and everything else is just lost.
> 
> Somehow I found this:
> https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/11/update-bash-history-in-realtime.html
> 
> I've implemented the suggested two line change to .bash_profile:
> 
> # User specific environment and startup programs
> shopt -s histappend
> PROMPT_COMMAND="history -a;$PROMPT_COMMAND"

> The resulting behavior appears to be shells still have their own unique 
> histories while active. But once closed, their histories become merged 
> (interlaced based on the time they were issued?) and available when a new 
> shell is created.
> 
> I think this would be a pretty cool yet subtle Fedora 39 feature. However, 

I'm glad that you've found something that you like, but please don't
mess with the default.  I don't need extra I/O on every command, and
for other reasons prefer the current behaviour.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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: default bash history (non)preservation

[Adam Williamson]

On Tue, 2023-04-11 at 13:06 -0400, Chris Murphy wrote:
> 
> On Tue, Apr 11, 2023, at 12:07 PM, Adam Williamson wrote:
> 
> > I've been doing something like this for years, but I wouldn't
> > necessarily recommend it as an OOTB default. It has some interesting
> > subtleties, like the order of the command history you get when you hit
> > 'up' changes depending on when the history is updated by other
> > terminals and when the terminal you're in reloads it.
> 
> I'm not seeing this effect. While active, the shells apparently have 
> completely unique histories, and don't interact with each other (until 
> they're closed). From time to time I see zero length files, e.g.  
> .bash_history-04863.tmp appear but I don't know what they do, there's nothing 
> in them.

The version I use is a file in /etc/profile.d that does this:

HISTSIZE=1048576
HISTFILESIZE=1048576

LAST_HISTORY_WRITE=$SECONDS
function prompt_command {
if [ $(($SECONDS - $LAST_HISTORY_WRITE)) -gt 60 ]; then
history -a && history -c && history -r
LAST_HISTORY_WRITE=$SECONDS
fi
}

PROMPT_COMMAND="${PROMPT_COMMAND:-:} ; prompt_command"

so I guess that's the difference; mine clears and reloads the history
(if it's been more than 60 seconds since the last time it did it).
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Re: default bash history (non)preservation

[Chris Adams]

Once upon a time, Chris Murphy  said:
> I've implemented the suggested two line change to .bash_profile:
> 
> # User specific environment and startup programs
> shopt -s histappend

This is already in the default /etc/bashrc, at least on Fedora 37 on
CentOS 7 (systems at hand I checked).

> PROMPT_COMMAND="history -a;$PROMPT_COMMAND"

I wouldn't do that part; that's additional disk I/O for every prompt.
Especially when the system might be having issues, users (especially
root) don't need something interfering with every command.  This would
mean an NFS home would insta-hang at the slightest issue.

-- 
Chris Adams 
___
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: default bash history (non)preservation

[Adam Williamson]

On Tue, 2023-04-11 at 13:15 -0400, Chris Murphy wrote:
> 
> On Tue, Apr 11, 2023, at 12:02 PM, stan via devel wrote:
> > On Tue, 11 Apr 2023 10:48:11 -0400
> > "Chris Murphy"  wrote:
> > 
> > > Hi,
> > > 
> > > For a long time I've noticed lost history from multiple Terminal
> > > tab/windows. It seems like the last tab or window to close is the
> > > history that gets written to .bash_history, and everything else is
> > > just lost.
> > > 
> > > Somehow I found this:
> > > https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/11/update-bash-history-in-realtime.html
> > > 
> > > I've implemented the suggested two line change to .bash_profile:
> > > 
> > > # User specific environment and startup programs
> > > shopt -s histappend
> > > PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
> > > 
> > > The resulting behavior appears to be shells still have their own
> > > unique histories while active. But once closed, their histories
> > > become merged (interlaced based on the time they were issued?) and
> > > available when a new shell is created.
> > > 
> > > I think this would be a pretty cool yet subtle Fedora 39 feature.
> > > However, 
> > > 
> > > a) I'm uncertain exactly where this belongs as a default, .bashrc or
> > > .bash_profile or some parent file that's copied to create these files
> > > (for new users); 
> > 
> > I like option 3 if it is going to be automatic.
> 
> Right.
> 
> Which raises the question whether existing user profiles should be modified. 
> There's pros and cons either way.
> 
> And whether that more strongly favors adding this to .bashrc or 
> .bash_profile, and whether there are subtleties in the resulting behavior 
> depending on which file is used; or if they're equivalent.
> 
> Normally I'd said don't apply a change to existing users. But in this case, I 
> think the risk of modifying existing user behavior is low,  meanwhile the 
> potential for even more confusion is high if we don't change it.

It is a pretty strong principle in Fedora that we do *not* mess with
users' home directories and configuration after creation. (Software
packaged in Fedora might of course mess with its own configuration, but
Fedora itself should not go around poking stuff like this).
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Re: default bash history (non)preservation

[Chris Murphy]

On Tue, Apr 11, 2023, at 12:02 PM, stan via devel wrote:
> On Tue, 11 Apr 2023 10:48:11 -0400
> "Chris Murphy"  wrote:
>
>> Hi,
>> 
>> For a long time I've noticed lost history from multiple Terminal
>> tab/windows. It seems like the last tab or window to close is the
>> history that gets written to .bash_history, and everything else is
>> just lost.
>> 
>> Somehow I found this:
>> https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/11/update-bash-history-in-realtime.html
>> 
>> I've implemented the suggested two line change to .bash_profile:
>> 
>> # User specific environment and startup programs
>> shopt -s histappend
>> PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
>> 
>> The resulting behavior appears to be shells still have their own
>> unique histories while active. But once closed, their histories
>> become merged (interlaced based on the time they were issued?) and
>> available when a new shell is created.
>> 
>> I think this would be a pretty cool yet subtle Fedora 39 feature.
>> However, 
>> 
>> a) I'm uncertain exactly where this belongs as a default, .bashrc or
>> .bash_profile or some parent file that's copied to create these files
>> (for new users); 
>
> I like option 3 if it is going to be automatic.

Right.

Which raises the question whether existing user profiles should be modified. 
There's pros and cons either way.

And whether that more strongly favors adding this to .bashrc or .bash_profile, 
and whether there are subtleties in the resulting behavior depending on which 
file is used; or if they're equivalent.

Normally I'd said don't apply a change to existing users. But in this case, I 
think the risk of modifying existing user behavior is low,  meanwhile the 
potential for even more confusion is high if we don't change it.



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

Re: Schedule for Tuesday's FESCo Meeting (2023-04-11)

[Kevin Fenzi]

We didn't really have quoroum today, so the meeting ended up being
canceled. 

Meeting ended Tue Apr 11 17:07:51 2023 UTC. Information about Zodbot's MeetBot 
at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting/2023-04-11/fesco.2023-04-11-17.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting/2023-04-11/fesco.2023-04-11-17.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting/2023-04-11/fesco.2023-04-11-17.00.log.html


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: default bash history (non)preservation

[Chris Murphy]

On Tue, Apr 11, 2023, at 12:07 PM, Adam Williamson wrote:

> I've been doing something like this for years, but I wouldn't
> necessarily recommend it as an OOTB default. It has some interesting
> subtleties, like the order of the command history you get when you hit
> 'up' changes depending on when the history is updated by other
> terminals and when the terminal you're in reloads it.

I'm not seeing this effect. While active, the shells apparently have completely 
unique histories, and don't interact with each other (until they're closed). 
From time to time I see zero length files, e.g.  .bash_history-04863.tmp appear 
but I don't know what they do, there's nothing in them.



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

Re: [HEADS UP] util-linux based on new mount API coming to rawhide/f39

[Colin Walters]

On Tue, Mar 21, 2023, at 8:16 AM, Karel Zak wrote:
> Hey all,
>
>
>  util-linux v2.39-rc1 coming to rawhide, Release Notes:
>  https://kernel.org/pub/linux/utils/util-linux/v2.39/v2.39-ReleaseNotes
>
>  I usually don't report util-linux Fedora updates, but this one is
>  special. This new version provides libmount with support for new
>  kernel mount API (syscalls fsconfig, fsmount, open_tree, etc.).
>
>  Some kernel parts may not be fully ported to the new API. Unfortunately,
>  the reliable way to detect possible issues is to test all less usual use
>  cases and mount options combinations in the real distribution.

Looks like this broke our mounting of zram:

https://github.com/coreos/fedora-coreos-tracker/issues/1462
___
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: default bash history (non)preservation

[Adam Williamson]

On Tue, 2023-04-11 at 10:48 -0400, Chris Murphy wrote:
> Hi,
> 
> For a long time I've noticed lost history from multiple Terminal tab/windows. 
> It seems like the last tab or window to close is the history that gets 
> written to .bash_history, and everything else is just lost.
> 
> Somehow I found this:
> https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/11/update-bash-history-in-realtime.html
> 
> I've implemented the suggested two line change to .bash_profile:
> 
> # User specific environment and startup programs
> shopt -s histappend
> PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
> 
> The resulting behavior appears to be shells still have their own unique 
> histories while active. But once closed, their histories become merged 
> (interlaced based on the time they were issued?) and available when a new 
> shell is created.
> 
> I think this would be a pretty cool yet subtle Fedora 39 feature. However, 
> 
> a) I'm uncertain exactly where this belongs as a default, .bashrc or 
> .bash_profile or some parent file that's copied to create these files (for 
> new users); 
> 
> b) if this is (still) an optimal way to go about it;
> 
> c) what are the possible negative side effects?
> 
> Any thoughts?

I've been doing something like this for years, but I wouldn't
necessarily recommend it as an OOTB default. It has some interesting
subtleties, like the order of the command history you get when you hit
'up' changes depending on when the history is updated by other
terminals and when the terminal you're in reloads it.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Re: default bash history (non)preservation

[stan via devel]

On Tue, 11 Apr 2023 10:48:11 -0400
"Chris Murphy"  wrote:

> Hi,
> 
> For a long time I've noticed lost history from multiple Terminal
> tab/windows. It seems like the last tab or window to close is the
> history that gets written to .bash_history, and everything else is
> just lost.
> 
> Somehow I found this:
> https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/11/update-bash-history-in-realtime.html
> 
> I've implemented the suggested two line change to .bash_profile:
> 
> # User specific environment and startup programs
> shopt -s histappend
> PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
> 
> The resulting behavior appears to be shells still have their own
> unique histories while active. But once closed, their histories
> become merged (interlaced based on the time they were issued?) and
> available when a new shell is created.
> 
> I think this would be a pretty cool yet subtle Fedora 39 feature.
> However, 
> 
> a) I'm uncertain exactly where this belongs as a default, .bashrc or
> .bash_profile or some parent file that's copied to create these files
> (for new users); 

I like option 3 if it is going to be automatic.

> b) if this is (still) an optimal way to go about it;

Providing it without effort or awareness for users seems like the way
to go.

> c) what are the possible negative side effects?

I can't think of any.  What good is a history that doesn't include all
the commands that have been used?  Well, complex commands.  I've turned
off some common commands, like ls, because all they are is clutter.  I
also turned off saving duplicate commands, though that only works if
they are contiguous in history.  I think that would be a downside to
this if people weren't used to all the clutter in their history.
Though, with Ctrl-R, it really doesn't matter.

I actually wrote a little python program to load history, and eliminate
all duplicate commands in history while preserving order of the
commands.  So, the last duplicate command is always the one saved.
> 
> Any thoughts?

I have the following defined in .bashrc:

# this logs the history explicitly before exiting a shell
hx ()
{
  history -a;
  exit;
}

It means that I have to exit using the command hx when closing a
terminal.  Not as elegant as an automatic process you are suggesting,
but it seems to work.  I'll have to try the process you are
suggesting, (from the link you gave), to see if it results in the
same effect.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

default bash history (non)preservation

[Chris Murphy]

Hi,

For a long time I've noticed lost history from multiple Terminal tab/windows. 
It seems like the last tab or window to close is the history that gets written 
to .bash_history, and everything else is just lost.

Somehow I found this:
https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/11/update-bash-history-in-realtime.html

I've implemented the suggested two line change to .bash_profile:

# User specific environment and startup programs
shopt -s histappend
PROMPT_COMMAND="history -a;$PROMPT_COMMAND"

The resulting behavior appears to be shells still have their own unique 
histories while active. But once closed, their histories become merged 
(interlaced based on the time they were issued?) and available when a new shell 
is created.

I think this would be a pretty cool yet subtle Fedora 39 feature. However, 

a) I'm uncertain exactly where this belongs as a default, .bashrc or 
.bash_profile or some parent file that's copied to create these files (for new 
users); 

b) if this is (still) an optimal way to go about it;

c) what are the possible negative side effects?

Any thoughts?


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

Re: Self Introduction: Miguel Bernal Marin

[Miguel Bernal Marin]

On Tue, Apr 11, 2023 at 09:16:07AM +0300, Benson Muite wrote:
> On 4/11/23 00:10, Joe Doss wrote:
> > On 4/8/23 7:52 PM, Miguel Bernal Marin wrote:
> >> Hi Fedora community,
> >>
> >> My name is Miguel Bernal Marin and usually my nickname is miguelinux,
> >> I work at Intel corporation in Guadalajara, Jalisco, Mexico and I
> >> would like
> >> to add some new packages from Intel to Fedora and keep maintaining them.
> >> I will look for a sponsor for those package in a near future.
> >>
> >> Regarded my past experience on open source projects, I was in the
> >> Clear Linux
> >> team maintaining some packages, and I had contributed to others open
> >> source
> >> projects.
> >>
> >> My FAS user is miguelinux.
> > 
> > Welcome Miguel. I am glad you have joined us! :)
> > 
> > Joe
> > 
> > 
> > 
> Welcome Miguel.

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

Re: Self Introduction: Miguel Bernal Marin

[Miguel Bernal Marin]

On Mon, Apr 10, 2023 at 04:10:24PM -0500, Joe Doss wrote:
> On 4/8/23 7:52 PM, Miguel Bernal Marin wrote:
> > Hi Fedora community,
> > 
> > My name is Miguel Bernal Marin and usually my nickname is miguelinux,
> > I work at Intel corporation in Guadalajara, Jalisco, Mexico and I would like
> > to add some new packages from Intel to Fedora and keep maintaining them.
> > I will look for a sponsor for those package in a near future.
> > 
> > Regarded my past experience on open source projects, I was in the Clear 
> > Linux
> > team maintaining some packages, and I had contributed to others open source
> > projects.
> > 
> > My FAS user is miguelinux.
> 
> Welcome Miguel. I am glad you have joined us! :)
> 

Thanks :-)

> Joe
___
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: Recommendations for patching bundled meson subprojects

[Leigh Scott]

Maybe ask   https://github.com/mesonbuild/mocklibc
___
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 20230411.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora-IoT 38 RC 20230411.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_20230411.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_38_RC_20230411.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 38 compose report: 20230411.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-38-20230409.n.0
NEW: Fedora-38-20230411.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   1
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   6.37 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   54.25 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-38-20230409.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  nginx-1:1.23.4-1.module_f38+16434+0e18d518
Old package:  nginx-1:1.23.3-1.module_f38+15813+42bcfef8
Summary:  A high performance web server and reverse proxy server
RPMs: nginx nginx-all-modules nginx-core nginx-filesystem 
nginx-mod-devel nginx-mod-http-image-filter nginx-mod-http-perl 
nginx-mod-http-xslt-filter nginx-mod-mail nginx-mod-stream
Size: 6.37 MiB
Size change:  54.25 KiB
Changelog:
  * Tue Mar 28 2023 Felix Kaechele  - 1:1.23.4-1
  - update to 1.23.4
  - Remove perl(MODULE_COMPAT), it will be replaced by generators



= DOWNGRADED PACKAGES =
___
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: 20230411.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230410.n.0
NEW: Fedora-Rawhide-20230411.n.0

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

Size of added packages:  2.13 MiB
Size of dropped packages:0 B
Size of upgraded packages:   1.72 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -81.17 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230411.n.0.iso

= DROPPED IMAGES =
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20230410.n.0.x86_64.vagrant-virtualbox.box
Image: Python_Classroom raw-xz aarch64
Path: 
Labs/aarch64/images/Fedora-Python-Classroom-Rawhide-20230410.n.0.aarch64.raw.xz
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20230410.n.0.x86_64.vagrant-libvirt.box
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20230410.n.0.iso
Image: Python_Classroom live x86_64
Path: 
Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20230410.n.0.iso

= ADDED PACKAGES =
Package: ghc-fmt-0.6.3.0-1.fc39
Summary: A new formatting library
RPMs:ghc-fmt ghc-fmt-devel ghc-fmt-doc ghc-fmt-prof
Size:2.13 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  cfn-lint-0.77.0-1.fc39
Old package:  cfn-lint-0.76.2-1.fc39
Summary:  CloudFormation Linter
RPMs: cfn-lint
Size: 1.42 MiB
Size change:  5.28 KiB
Changelog:
  * Mon Apr 10 2023 Benjamin A. Beasley  - 0.77.0-1
  - Update to 0.77.0 (close RHBZ#2185615)


Package:  cheese-2:44.0-1.fc39
Old package:  cheese-2:43~alpha-3.fc38
Summary:  Application for taking pictures and movies from a webcam
RPMs: cheese cheese-libs cheese-libs-devel
Size: 5.76 MiB
Size change:  11.35 KiB
Changelog:
  * Mon Apr 10 2023 David King  - 44.0-1
  - Update to 44.0


Package:  cldr-emoji-annotation-1:43~beta5-1.fc39
Old package:  cldr-emoji-annotation-1:43~beta2-1.fc39
Summary:  Emoji annotation files in CLDR
RPMs: cldr-emoji-annotation cldr-emoji-annotation-devel 
cldr-emoji-annotation-dtd
Size: 7.02 MiB
Size change:  -10.42 KiB
Changelog:
  * Tue Apr 11 2023 Takao Fujiwara  - 1:43~beta5-1
  - Bump to release-43-beta5


Package:  containers-common-4:1-89.fc39
Old package:  containers-common-4:1-87.fc39
Summary:  Common configuration and documentation for containers
RPMs: containers-common containers-common-extra
Size: 108.08 KiB
Size change:  1.65 KiB
Changelog:
  * Mon Apr 10 2023 Daniel J Walsh  - 4:1-88
  - local build

  * Mon Apr 10 2023 Daniel J Walsh  - 4:1-89
  - local build


Package:  egl-wayland-1.1.11-3.fc39
Old package:  egl-wayland-1.1.11-2.fc38
Summary:  Wayland EGL External Platform library
RPMs: egl-wayland egl-wayland-devel
Size: 270.29 KiB
Size change:  -856 B
Changelog:
  * Mon Apr 10 2023 Jonathan Schleifer  - 1.1.11-3
  - Fix Firefox and Thunderbird crashing on start


Package:  fapolicy-analyzer-1.0.1-1.fc39
Old package:  fapolicy-analyzer-1.0.0-1.fc39
Summary:  File Access Policy Analyzer
RPMs: fapolicy-analyzer
Size: 4.59 MiB
Size change:  1.22 KiB
Changelog:
  * Mon Apr 10 2023 John Wass  1.0.1-1
  - Release v1.0.1


Package:  fontawesome-fonts-1:6.4.0-2.fc39
Old package:  fontawesome-fonts-1:6.4.0-1.fc39
Summary:  Support files for the FontAwesome fonts
RPMs: fontawesome-6-brands-fonts fontawesome-6-free-fonts 
fontawesome-fonts-all fontawesome-fonts-web
Size: 2.73 MiB
Size change:  692 B
Changelog:
  * Mon Apr 10 2023 Jerry James  - 1:6.4.0-2
  - Move obsoletes/provides to the right package (rhbz#2185459)


Package:  fontawesome4-fonts-1:4.7.0-17.fc39
Old package:  fontawesome4-fonts-1:4.7.0-16.fc39
Summary:  Iconic font set
RPMs: fontawesome4-fonts fontawesome4-fonts-web
Size: 627.16 KiB
Size change:  244 B
Changelog:
  * Mon Apr 10 2023 Jerry James  - 1:4.7.0-17
  - Move fonts back to /usr/share/fonts/fontawesome


Package:  glib2-2.76.1-2.fc39
Old package:  glib2-2.76.1-1.fc39
Summary:  A library of handy utility functions
RPMs: glib2 glib2-devel glib2-doc glib2-static glib2-tests
Size: 37.28 MiB
Size change:  -147.11 KiB
Changelog:
  * Mon Apr 10 2023 David King  - 2.76.1-2
  - Add python3-setuptools Requires to -devel


Package:  grub2-1:2.06-94.fc39
Old package:  grub2-1:2.06-93.fc39
Summary:  Bootloader with support for Linux, Multiboot and more
RPMs: grub2-common grub2-efi-aa64 grub2-efi-aa64-cdboot 
grub2-efi-aa64-modules grub2-efi-ia32 grub2-efi-ia32-cdboot 
grub2-efi-ia32-modules grub2-efi-x64 grub2-efi-x64-cdboot grub2-efi-x64-modules 
grub2-emu grub2-emu-modules grub2-pc

Recommendations for patching bundled meson subprojects

[Florian Weimer]

I need to patch the bundled mocklib in accountsservice to fix a build
issue with future compilers:

  accountsservice: C99 compatibility issue in bundled copy of mocklib
  

The RPM spec file copies mocklibc-1.0.tar.gz and mocklibc-1.0-2-wrap.zip
into the build directory.  Meson does not appear to support patching
bundled subprojects.  What's the best way to deal with this?

I don't think there is an upstream left for mocklib, so fixing it there
and asking for a new release doesn't seem to be an option.

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

Re: TeXLive 2023

[Iñaki Ucar]

On Tue, 11 Apr 2023 at 09:32, Petr Pisar  wrote:
>
> V Sun, Apr 09, 2023 at 11:19:37PM +0200, Iñaki Ucar napsal(a):
> > I'm not sure what could be the issue, but I can reproduce this by
> > creating the simplest hello-world package containing:
> >
> > Recommends: tex(latex)
> >
> > When I build this package and try to install it in Fedora <= 38,
> > texlive is pulled. But nothing else (apart from the package itself) is
> > installed in rawhide.
> >
> "dnf install 'tex(latex)'" gives me 386 packages (with
> texlive-collection-latexrecommended-11:svn65512-69.fc39.noarch root) to
> install in Fedora 39.  Don't you have simply disabled week dependencies
> (install_weak_deps=false) in /etc/dnf/dnf.conf?

No, I don't. Here's a report with a reproducible example:
https://bugzilla.redhat.com/show_bug.cgi?id=2185620

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

python-orjson Review Swap

[Maxwell G]

Hi everyone,

I'm looking for a review swap for python-orjson [1], preferably
something in Go or Python. This package is needed by newer versions of
bottles and is starting to be used by other Python projects as well.

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

--
Thanks,


Maxwell G (@gotmax23)
Pronouns: He/They
___
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: TeXLive 2023

[Petr Pisar]

V Sun, Apr 09, 2023 at 11:19:37PM +0200, Iñaki Ucar napsal(a):
> I'm not sure what could be the issue, but I can reproduce this by
> creating the simplest hello-world package containing:
> 
> Recommends: tex(latex)
> 
> When I build this package and try to install it in Fedora <= 38,
> texlive is pulled. But nothing else (apart from the package itself) is
> installed in rawhide.
> 
"dnf install 'tex(latex)'" gives me 386 packages (with
texlive-collection-latexrecommended-11:svn65512-69.fc39.noarch root) to
install in Fedora 39.  Don't you have simply disabled week dependencies
(install_weak_deps=false) in /etc/dnf/dnf.conf?

-- Petr


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: purpose of dummy-test-package-* updates?

[Mattia Verga via devel]

Il 10/04/23 17:50, Kevin Fenzi ha scritto:
> On Mon, Apr 10, 2023 at 03:18:22PM +, Mattia Verga via devel wrote:
>> Il 10/04/23 17:01, Kevin Fenzi ha scritto:
>>> I've not seen any errors from it in a long while... but I'm not sure if
>>> thats because everything has been working or because it isn't erroring
>>> properly.
>>>
>>> Anyhow, I think we should/can adjust it to not make big changelogs...
>>>
>> Well, now the problem is no more, since Bodhi will handle such big
>> changelogs.
>>
>> Anyway, I'm not sure if it is working as expected, as updates are always
>> gated due to a failing test, so the next one will obsolete the older
>> (and that's why the changelog keeps growing).
> yeah, it deliberatly has a failed test so it can waive it and test that
> waiving works. Sadly, on looking, thats the problem. It tries to waive
> it but fails:
>
> 13:14:21 - Waiving test results for bodhi update
> Command `bodhi updates waive FEDORA-2023-47cf5a0c4b 'This is fine, we are 
> testing the workflow
> ' --debug --user packagerbot --password ` return code: `1`
> stdout:
> ---
> b'Waiving unsatisfied requirements: \n'
> stderr:
> ---
> b'Invalid request: Check your FAS username & password\n'
>
> So, auth isn't working right there.
>
I think authenticating with '--user --password' is not working anymore
since the client was migrated to OIDC [1] (bodhi 6)

Mattia

[1]
https://github.com/fedora-infra/bodhi/commit/32fa9f4fcd850558b8f9f024989dd151bb068452

___
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