I'm the author of Bubblemail, a mail notification service providing a D-Bus interface :
Git Repo :
It's a brand new project coming from the fork of the mailnag project, with first goal to get it running on python3. Since then, I have rewritten almost all the code in a more modern and simplest way, get it pep8 compliant, improve stability, features and tests, and build a more modern gtk3 interface on it.
On top of that, I make the same work on the gnome-shell extension, already available on the gnome-shell extension website :
I currently maintain myself rpm and deb packages, and I'm looking for someone for the rpm part of the task, hopping for proper Fedora integration.
It's almost pure python3 code using setuptools, I suppose it should be easy to build and maintain an rpm package for someone used with the task.
Please contact me: razerraz AT free DOT fr
Improve compression ratio of SquashFS filesystem on the installation media.
Name: Bohdan Khomutskyi
Targeted release: I propose this change for Fedora 32
Last updated: Jan 5 2020
Pagure.io issue: https://pagure.io/releng/issue/9127
I was unable to create an article in Fedora wiki system.
As of Fedora 31, the LiveOS/squashfs.img file on the installation image, is
compressed with default settings of mksquashfs. The standard configuration
is set to XZ algorithm with block size of 128k and BCJ filter enabled.
Those parameters can be adjusted which will lead to a better compression
ratio and/or reduction of the CPU usage at build time.
This is simple to achieve. Recently, Lorax has gotten support for
adjusting the compression options for mksquashfs via the configuration
file. The file should be altered as following:
bcj = yes
args = -b 1M -Xdict-size 1M -no-recovery
Where -b 1M and -Xdict-size 1M are block and dictionary sizes respectively.
Could be adjusted.
Benefit to Fedora
Reduction of the installation media size and the cost of storing and
Reduction of the CPU usage at build time. Depending on which compression
See a graphical detail at https://pagure.io/releng/issue/9127.
The build environment should have support for adjusting the Lorax
configuration file.. Lorax is a program that produces the
LiveOS/squashfs.img file on the installation media.
One of the way to allow for such customization, is to add a feature in
Pungi, to allow for passing -c option to Lorax.
Release engineering: #9127 <https://pagure.io/releng/issue/9127>
Policies and guidelines: N/A
Trademark approval: N/A
This change comes at a cost of higher memory usage during the
installation. Based on my personal estimations, this should not be the
issue. Since the decompression should require up to 1MiB per thread.
Increasing the block size on the current configuration with EXT4 file
system, should increase latency while accessing the EXT4 filesystem. The
exact impact is to be evaluated.
The impact of latency will be reduced, if the plain SquashFS option is
Release notes See also
Release Configuration Management engineer
we try to rebuild all Python packages against Python 3.9 and report the
failures. I've seen several similar failures in a row now that can be reproduced
in Fedora rawhide with the new gcc version.
ld errors on multiple definitions of ..., for example:
multiple definition of `the_var';
first defined here
This is a known thing in gcc 10:
"Default to -fno-common
A common mistake in C is omitting extern when declaring a global variable in a
header file. If the header is included by several files it results in multiple
definitions of the same variable. In previous GCC versions this error is
ignored. GCC 10 defaults to -fno-common, which means a linker error will now be
reported. To fix this, use extern in header files when declaring global
variables, and ensure each global is defined in exactly one C file. As a
workaround, legacy C code can be compiled with -fcommon.
int x; // tentative definition - avoid in header files
extern int y; // correct declaration in a header file"
Here are some packages affected:
Before I go and file dozens of bugzillas, do we want to handle this somehow better?
I hope you are all well.
I would like to invite you to contribute to our new initiative: AAA
Currently, we have a team of 4 Red Hatters working on this. We have chosen
to work within a Scrum framework. Our first ( 2 week) sprint kicked off
last week 1/7/20 with a sprint planning session. Our first sprint review
will take place on Tuesday 1/21/20.
We will be publishing a blog each fortnight on community forums with a
summary of our sprint review and sprint planning session for the upcoming
sprint. You are invited to provide feedback on your review/plan for our
consideration. The first blog will be published Wednesday 1/22/20.
You will find our backlog ( issues ) here
<https://github.com/fedora-infra/securitas/issues> and our scrum board with
current sprint user stories here
<https://github.com/orgs/fedora-infra/projects/6>. Our Tech lead, will be
refining/prioritising the backlog as we work our way through each sprint,
preparing for the next sprint. The issues/user stories at the top of the
backlog are the user stories that have been flagged as must do/ high value
tasks to complete by the Tech lead. We do welcome your input on the backlog
(Issues) , so please add your thoughts, ideas, questions as a comment for
the Tech lead and team to review. These will be reviewed prior to each
sprint planning session for consideration.
We have a Freenode IRC channel #fedora-aaa where we welcome you to join. We
will be discussing ad hoc items regarding this project here. We also meet
regularly on this channel for stand up's four times a week. Mon & Wed at
0915 UTC and Tues &Thurs at 1530 UTC for 15 minutes.
I will be updating the Wiki page over the next couple of days with a high
level overview of the project and our communication plan. As with Scrum, we
may tweak our process as we progress through the project. If our process
does change, I will update the Wiki page.
If you have questions relating to an issue( user story ) on the backlog (
issues ) please comment on it, and tag a team member , we will revert back.
If you would like to add an issue, please create and issue, give as much
detail as possible and tag a team member so we can review.
If you have questions relating to anything else, please reply to this
Thanks a mill,
Red Hat <https://www.redhat.com/>
@RedHat <https://twitter.com/redhat> Red Hat
<https://www.linkedin.com/company/red-hat> Red Hat
NFS over UDP will be deprecated in the 5.6 kernel.
Its not clear what or if any havoc this could cause
but the commit (f745bfdc) has been accepted upstream.
Just letting the community know...
If by chance a bz is opened, please feel free to send me a
private email with the link... As we all know Bugzilla
is just another word for... spam! ;-)