Lector de Feeds

In Mageia/cauldron/x86_64: The nouveau project aims to build high-quality, open source drivers for NVIDIA cards.

In Mageia/cauldron/i586: The nouveau project aims to build high-quality, open source drivers for NVIDIA cards.

In Mageia/cauldron/i586: Optimized handling of `&[u8]` and `Vec` for Serde.

In Mageia/cauldron/x86_64: Optimized handling of `&[u8]` and `Vec` for Serde.

In Mageia/cauldron/x86_64: rclone is a "rsync for cloud storage" - Google Drive, Amazon Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Cloudfiles, Google Cloud Storage, Yandex Files https://rclone.org

In Mageia/cauldron/i586: rclone is a "rsync for cloud storage" - Google Drive, Amazon Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Cloudfiles, Google Cloud Storage, Yandex Files https://rclone.org

In Mageia/cauldron/x86_64: The goal of the CGAL Open Source Project is to provide easy access to efficient and reliable geometric algorithms in the form of a C++ library. CGAL is used in various areas needing geometric computation, such as: computer graphics, scientific visualization, computer aided design and modeling, geographic information systems, molecular biology, medical imaging, robotics and motion planning, mesh generation, numerical methods... More on the projects using CGAL web page.

In Mageia/cauldron/i586: The goal of the CGAL Open Source Project is to provide easy access to efficient and reliable geometric algorithms in the form of a C++ library. CGAL is used in various areas needing geometric computation, such as: computer graphics, scientific visualization, computer aided design and modeling, geographic information systems, molecular biology, medical imaging, robotics and motion planning, mesh generation, numerical methods... More on the projects using CGAL web page.

In Mageia/cauldron/i586: Macros 1.1 implementation of #[derive(Serialize, Deserialize)].

In Mageia/cauldron/x86_64: Macros 1.1 implementation of #[derive(Serialize, Deserialize)].

Publication date: 28 Sep 2024
Type: security
Affected Mageia releases : 9
CVE: CVE-2024-6472 Description The Certificate Validation user interface in LibreOffice allows a potential vulnerability. Signed macros are scripts that have been digitally signed by the developer using a cryptographic signature. When a document with a signed macro is opened a warning is displayed by LibreOffice before the macro is executed. Previously, if verification failed the user could fail to understand the failure and choose to enable the macros anyway. This issue affects LibreOffice: from 24.2 before 24.2.5. Also our current version is EOL, so we are updating to a supported version. References

• https://bugs.mageia.org/show_bug.cgi?id=33449
• https://bugs.mageia.org/show_bug.cgi?id=33528
• https://ubuntu.com/security/notices/USN-6962-1
• https://www.libreoffice.org/about-us/security/advisories/cve-2024-6472/
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-6472

SRPMS 9/core

• libreoffice-24.2.5.2-1.1.mga9
• zxcvbn-c-2.5-2.mga9

Publication date: 28 Sep 2024
Type: bugfix
Affected Mageia releases : 9
Description Haproxy has one major, few medium and few minor bugs fixed in last upstream version 2.8.11 of branch 2.8 Fixed major bug list: - mux-h1: Wake SC to perform 0-copy forwarding in CLOSING state Fixed medium bug list: - bwlim: Be sure to never set the analyze expiration date in past - cache/stats: Wait to have the request before sending the response - cli: Always release back endpoint between two commands on the mcli - clock: also update the date offset on time jumps - clock: detect and cover jumps during execution - debug/cli: fix "show threads" crashing with low thread counts - h1: Reject empty Transfer-encoding header - h2: Only report early HTX EOM for tunneled streams - h3: ensure the ":method" pseudo header is totally valid - h3: ensure the ":scheme" pseudo header is totally valid - http-ana: Report error on write error waiting for the response - init: fix fd_hard_limit default in compute_ideal_maxconn - init: set default for fd_hard_limit via DEFAULT_MAXFD (take #2) - jwt: Clear SSL error queue on error when checking the signature - mux-h1: Properly handle empty message when an error is triggered - mux-h2: Propagate term flags to SE on error in h2s_wake_one_stream - mux-pt/mux-h1: Release the pipe on connection error on sending path - mworker/cli: fix pipelined modes on master CLI - pattern: prevent UAF on reused pattern expr - promex: Wait to have the request before sending the response - queue: deal with a rare TOCTOU in assign_server_and_queue() - queue: implement a flag to check for the dequeuing - quic: fix possible exit from qc_check_dcid() without unlocking - quic: fix race-condition in quic_get_cid_tid() - quic: prevent conn freeze on 0RTT undeciphered content - spoe: Be sure to create a SPOE applet if none on the current thread - ssl: initialize the SSL stack explicitely - ssl_sock: fix deadlock in ssl_sock_load_ocsp() on error path - stconn: Report error on SC on send if a previous SE error was set - stream: Prevent mux upgrades if client connection is no longer ready - trace: fix null deref in lockon mechanism since TRACE_ENABLED() References

• https://bugs.mageia.org/show_bug.cgi?id=33593
• https://www.haproxy.org/download/2.8/src/CHANGELOG

SRPMS 9/core

• haproxy-2.8.11-1.mga9

← Older revision Revision as of 18:54, 28 September 2024 (10 intermediate revisions by the same user not shown)Line 1: Line 1: −=Explanation=+{{introduction|     This page is meant to give an overview of all ideas that come up when brainstorming about how to increase the number of active contributors.<br> This page is meant to give an overview of all ideas that come up when brainstorming about how to increase the number of active contributors.<br> Line 7: Line 7:  Every idea may be added. When brainstorming, there are no wrong or stupid ideas. That said, ideas that don't comply with our [https://www.mageia.org/en/about/code-of-conduct/ code of conduct], will be removed. Every idea may be added. When brainstorming, there are no wrong or stupid ideas. That said, ideas that don't comply with our [https://www.mageia.org/en/about/code-of-conduct/ code of conduct], will be removed.    −The intention is to sort the ideas by general topic (like whom to reach out to, or proposed changes to Mageia, or how to reach potential contributors) on this page, to make later reviewing them easier. Topics can be added when needed.+The intention is to sort the ideas by general topic (like whom to reach out to, or proposed changes to Mageia, or how to reach potential contributors) on this page, to make later reviewing them easier. Topics can be added when needed.}}    −==Whom to reach out to==+=Whom to reach out to=    −==How to reach potential contributors==+==IT students who get plenty of education about Windows, but not about Linux==  +They still exist, universities and schools that ignore Linux. Just about everything one former IT student knew about Linux when he graduated, was what he had learnt in Mageia. Thanks to what he had learnt here, he became a Linux developer and has now been working in the tech industry for a decade.    −==How to revive sleeping contributors==+==Young people without a future==  +Like asylum seekers who come from a "safe country" and can do nothing but wait till they get kicked out. Or like students who are not allowed to continue their study, because they don't fit well into the educational system. <br>  +Wouldn't some of them be perfectly capable of learning Linux and learning so much of it that they would then be able to find a job (and in case that matters: a job that can be done remotely, so that they can return to their home country), earn a living and have a future? Isn't there is a better place to start than with Mageia and in Mageia.    −==Proposed changes to Mageia, to attract more contributors==+=How to reach potential contributors=    −'''Change to a state of the art, easy to use, powerfull and efficient build system like https://openbuildservice.org/.'''+=How to revive sleeping contributors=  +   +=Proposed changes to Mageia, to attract more contributors=  +   +=='''Change to a state of the art, easy to use, powerfull and efficient build system==  +Like https://openbuildservice.org/.'''     Everybody (who has a Mageia account) would be able to branch a package, apply fixes, update, test the build and submit the branched package via service request for review. The last few maintainers of Mageia can accept the service request, recommand changes or reject the request. This would ease the workload of the last few maintainers because they only would need to review the service request instead of doing all the packaging work alone. In this way, also packages without fixed maintainers would get updates and some attention. Everybody (who has a Mageia account) would be able to branch a package, apply fixes, update, test the build and submit the branched package via service request for review. The last few maintainers of Mageia can accept the service request, recommand changes or reject the request. This would ease the workload of the last few maintainers because they only would need to review the service request instead of doing all the packaging work alone. In this way, also packages without fixed maintainers would get updates and some attention.    −This would also work around the absolutely inefficient, outdated, frustrating and longsome way of [https://wiki.mageia.org/en/Becoming_a_Mageia_Packager Becoming a Mageia packager].+===Make it easier to become a packager===  +   +This (the above) would also work around the absolutely inefficient, outdated, frustrating and longsome way of [https://wiki.mageia.org/en/Becoming_a_Mageia_Packager Becoming a Mageia packager].  +   +==A contributor works for free for a project if he has confidence in its future.==  +The foundations of mageia are sound. It's a community distribution with clear values. However, Our association governance doesn't work.  +===Improve our Association Governance:===  + *    => Membership of the association is based on merit and choice. However, this process is subjective and not based on clear rules.  + *    => There aren't enough ordinary meetings or general assemblies to make decisions. Exchanges between the Council and the Board are almost non-existent. At the very least, the Board should validate the major orientations of distribution.  + *    => What is our roadmap, what are our medium- and long-term objectives? If we don't know ourselves what we need to do and what we need to prioritize, how can we communicate calmly and attract new contributors?  +   +===Make it easier to become a contributor===  +In line with [https://wiki.mageia.org/en/Brainstorming_about_how_to_get_more_active_contributors#Make_it_easier_to_become_a_packager a previous item], but more general,is this idea:<br>  +A contributor will work on a project if he finds the tools he knows and if they are efficient.  +I think it might be useful to take stock of the onboarding process for new arrivals, and improve it. On the other hand, I'm not sure we take the time to step back and look at what's not working and improve it. I recognize that this requires teamwork.....  +   +===Make more decisions===  +We don't make enough decisions. At the moment, I think we still have IRC and matrix running in parallel. We should stop using IRC and invest more in Matrix, which makes sharing easier and is evolving to include video and sound.  +===Work on the servers===  +It is essential to improve speed and comfort for our developers. Perhaps we should reinforce the system team if it needs it, and call on new volunteers.  +===Use tools such as jira===  +They might enable a simple kanban to know what to do and what to prioritize. Each team could have its own space to manage its actions.  +===Invest in the sysadmin team===  +I don't know how our current solutions work, but investing in the system team to work on the architecture to automate/consolidate the build of packages, images and tests on recognized standards known to potential external contributors would be a plus.  +   +==Real Life and/or video meetings==  +We don't know enough about each other and we don't have enough opportunities to exchange ideas.  +How about getting together at least once in a while, face-to-face or remotely via video conferences, etc.? It's not easy to organize, but linux fairs are a good opportunity. It used to be done, but with covid we've lost those good habits. A small restaurant between contributors helps reinforce team spirit.  +==Evolve faster==  +In France, there is a very lively community that is developing around the promotion of video games under Linux. I think that some of these members are ready to help if we trust them and help them. Some of them are technically solid. They have an understanding of the graphic stacks under Linux and are attracted by the new features available (Wayland, Nvidia drivers, Mesa, Lutris, etc., kernel optimization settings). I am registered on their discord and can see how they manage to attract young people. Unfortunately, even if some use Mageia, many are on other distributions because Mageia does not evolve quickly enough. Some have proposed things to improve the look of the distribution, but they quickly stopped because they felt that we did not like breaking our habits and that ultimately we did not want to evolve.  +   +=Most recent ideas from the Association members list, not yet merged (if possible) with the above=  +I write something just to the brainstorming Marja request. Don't take as written in stone.  +   +==The update to the new infra hardware should be pretty close.==  +Once it will be made it should bring a breath of fresh air to the distribution and let it be more "efficient" also to the packaging process. With the newer cpu power/storage there should be enough room/power to test new stuff, new developing tools (that are already used elsewhere in other distro) and new ideas/scheme beside to the classic tools, at least for the size and the ambition of the distro.  +   +==Maintainership has growing costs==  +Beside personal life balance, developers or maintainers are actually not paid/rewarded so sometimes they could slowly fading or just slow down, as under certain circumstances the maintainership has growing costs (consider for instance following some upstream project having a release cycle of a month, if not weeks requiring continuosly updates), as might become almost a halftime or fulltime unpaid job.  +   +==Statistics needed regarding younger newgen developers==  +to remain in the linux world, I guess many of them are developing on other linux forks, e.g. android os or android apps, but here we need more statistics.  +   +==Have small, self-organized packager groups==  +An idea for getting more packagers could be to let them self-organize in small groups of 2-3 people maximum, based on close, but complementary skills, to cooperate on building some package. One member of the group could help the other and viceversa.  +=Most recent idea from the Forums, not yet merged (if possible) with the above=  +Well, if we are brainstorming about how to increase contributors, I would say that there are several things that would help.  +   +  * Demonstrate that contributing has tangible benefit to the community.  +  * Share details of what, specifically, help is needed with.  +  * Provide a clear path for getting involved.  +   +   +I contribute to more than one Linux distro but reviewing [https://www.mageia.org/contribute/ the contribution link] provides no information that would make me want to get involved. That is just a list of the things that all distros need to operate. It tells me nothing about where Mageia most needs help and what needs to be done.  +   +If we are trying to figure out how to increase contributors, I would speculate that we have contribution shortfalls that are either causing things to not get done in a timely manner, we are too much burden on a small group of people or both.  +   +We must know the areas in which we most need to help and what needs to be done. If a list of priorities hasn't been developed yet, I would recommend creating one. Marja

‎Most recent ideas from the Association members list, not yet merged (if possible) with the above

← Older revision Revision as of 17:33, 28 September 2024 (7 intermediate revisions by the same user not shown)Line 10: Line 10:     ==Whom to reach out to== ==Whom to reach out to==  +  +===IT students who get plenty of education about Windows, but not about Linux===  +They still exist, universities and schools that ignore Linux. Just about everything one former IT student knew about Linux when he graduated, was what he had learnt in Mageia. Thanks to what he had learnt here, he became a Linux developer and has now been working in the tech industry for a decade.  +  +===Young people without a future===  +Like asylum seekers who come from a "safe country" and can do nothing but wait till they get kicked out. Or like students who are not allowed to continue their study, because they don't fit well into the educational system. <br>  +Wouldn't some of them be perfectly capable of learning Linux and learning so much of it that they would then be able to find a job (and in case that matters: a job that can be done remotely, so that they can return to their home country), earn a living and have a future? Isn't there is a better place to start than with Mageia and in Mageia.     ==How to reach potential contributors== ==How to reach potential contributors== Line 17: Line 24:  ==Proposed changes to Mageia, to attract more contributors== ==Proposed changes to Mageia, to attract more contributors==    −'''Change to a state of the art, easy to use, powerfull and efficient build system like https://openbuildservice.org/.'''+==='''Change to a state of the art, easy to use, powerfull and efficient build system===  +Like https://openbuildservice.org/.'''     Everybody (who has a Mageia account) would be able to branch a package, apply fixes, update, test the build and submit the branched package via service request for review. The last few maintainers of Mageia can accept the service request, recommand changes or reject the request. This would ease the workload of the last few maintainers because they only would need to review the service request instead of doing all the packaging work alone. In this way, also packages without fixed maintainers would get updates and some attention. Everybody (who has a Mageia account) would be able to branch a package, apply fixes, update, test the build and submit the branched package via service request for review. The last few maintainers of Mageia can accept the service request, recommand changes or reject the request. This would ease the workload of the last few maintainers because they only would need to review the service request instead of doing all the packaging work alone. In this way, also packages without fixed maintainers would get updates and some attention.    −This would also work around the absolutely inefficient, outdated, frustrating and longsome way of [https://wiki.mageia.org/en/Becoming_a_Mageia_Packager Becoming a Mageia packager].+====Make it easier to become a packager====  +   +This (the above) would also work around the absolutely inefficient, outdated, frustrating and longsome way of [https://wiki.mageia.org/en/Becoming_a_Mageia_Packager Becoming a Mageia packager].  +   +===A contributor works for free for a project if he has confidence in its future.===  +The foundations of mageia are sound. It's a community distribution with clear values. However, Our association governance doesn't work.  +====Improve our Association Governance:====  + *    => Membership of the association is based on merit and choice. However, this process is subjective and not based on clear rules.  + *    => There aren't enough ordinary meetings or general assemblies to make decisions. Exchanges between the Council and the Board are almost non-existent. At the very least, the Board should validate the major orientations of distribution.  + *    => What is our roadmap, what are our medium- and long-term objectives? If we don't know ourselves what we need to do and what we need to prioritize, how can we communicate calmly and attract new contributors?  +   +====Make it easier to become a contributor====  +In line with [https://wiki.mageia.org/en/Brainstorming_about_how_to_get_more_active_contributors#Make_it_easier_to_become_a_packager a previous item], but more general,is this idea:<br>  +A contributor will work on a project if he finds the tools he knows and if they are efficient.  +I think it might be useful to take stock of the onboarding process for new arrivals, and improve it. On the other hand, I'm not sure we take the time to step back and look at what's not working and improve it. I recognize that this requires teamwork.....  +   +====Make more decisions====  +We don't make enough decisions. At the moment, I think we still have IRC and matrix running in parallel. We should stop using IRC and invest more in Matrix, which makes sharing easier and is evolving to include video and sound.  +====Work on the servers====  +It is essential to improve speed and comfort for our developers. Perhaps we should reinforce the system team if it needs it, and call on new volunteers.  +====Use tools such as jira====  +They might enable a simple kanban to know what to do and what to prioritize. Each team could have its own space to manage its actions.  +====Invest in the sysadmin team====  +I don't know how our current solutions work, but investing in the system team to work on the architecture to automate/consolidate the build of packages, images and tests on recognized standards known to potential external contributors would be a plus.  +   +===Real Life and/or video meetings===  +We don't know enough about each other and we don't have enough opportunities to exchange ideas.  +How about getting together at least once in a while, face-to-face or remotely via video conferences, etc.? It's not easy to organize, but linux fairs are a good opportunity. It used to be done, but with covid we've lost those good habits. A small restaurant between contributors helps reinforce team spirit.  +===Evolve faster===  +In France, there is a very lively community that is developing around the promotion of video games under Linux. I think that some of these members are ready to help if we trust them and help them. Some of them are technically solid. They have an understanding of the graphic stacks under Linux and are attracted by the new features available (Wayland, Nvidia drivers, Mesa, Lutris, etc., kernel optimization settings). I am registered on their discord and can see how they manage to attract young people. Unfortunately, even if some use Mageia, many are on other distributions because Mageia does not evolve quickly enough. Some have proposed things to improve the look of the distribution, but they quickly stopped because they felt that we did not like breaking our habits and that ultimately we did not want to evolve.  +   +==Most recent ideas from the Association members list, not yet merged (if possible) with the above==  +I write something just to the brainstorming Marja request. Don't take as written in stone.  +   +===The update to the new infra hardware should be pretty close.===  +Once it will be made it should bring a breath of fresh air to the distribution and let it be more "efficient" also to the packaging process. With the newer cpu power/storage there should be enough room/power to test new stuff, new developing tools (that are already used elsewhere in other distro) and new ideas/scheme beside to the classic tools, at least for the size and the ambition of the distro.  +   +===Maintainership has growing costs===  +Beside personal life balance, developers or maintainers are actually not paid/rewarded so sometimes they could slowly fading or just slow down, as under certain circumstances the maintainership has growing costs (consider for instance following some upstream project having a release cycle of a month, if not weeks requiring continuosly updates), as might become almost a halftime or fulltime unpaid job.  +   +===Statistics needed regarding younger newgen developers===  +to remain in the linux world, I guess many of them are developing on other linux forks, e.g. android os or android apps, but here we need more statistics.  +   +===Have small, self-orgaized packager groups===  +An idea for getting more packagers could be to let them self-organize in small groups of 2-3 people maximum, based on close, but complementary skills, to cooperate on building some package. One member of the group could help the other and viceversa.  +==Most recent idea from the Forums, not yet merged (if possible) with the above==  +Well, if we are brainstorming about how to increase contributors, I would say that there are several things that would help.  +   +  * Demonstrate that contributing has tangible benefit to the community.  +  * Share details of what, specifically, help is needed with.  +  * Provide a clear path for getting involved.  +   +   +I contribute to more than one Linux distro but reviewing the contribution link above provides no information that would make me want to get involved. That is just a list of the things that all distros need to operate. It tells me nothing about where Mageia most needs help and what needs to be done.  +   +If we are trying to figure out how to increase contributors, I would speculate that we have contribution shortfalls that are either causing things to not get done in a timely manner, we are too much burden on a small group of people or both.  +   +We must know the areas in which we most need to help and what needs to be done. If a list of priorities hasn't been developed yet, I would recommend creating one. Marja

In Mageia/9/armv7hl: Mesa is an OpenGL 4.6 compatible 3D graphics library.

In Mageia/9/aarch64: Mesa is an OpenGL 4.6 compatible 3D graphics library.

In Mageia/9/i586: Mesa is an OpenGL 4.6 compatible 3D graphics library.