[-- Attachment #1: Type: text/plain, Size: 2450 bytes --] Hello, bzip2 supporters: Many thanks for your work to develop BZip2 and make it freely available in the world. I am using it, and it works well for me. I had a question, for which I could not find an answer at the documentation[1]. If I have two input files, F1 and F2, and I compress them with bzip2 on different machines at different times, maybe with different versions of bzip2, or with different implementations of the bzip2 algorithm, are the resulting archives F1.bz2 and F2.bz2 guaranteed to be bit-for-bit identical if and only iff the inputs F1 and F2 are bit-for-bit identical? Or are they guaranteed to be different? Or is this property undefined? Reasons why they could be guaranteed identical: * The algorithm is 100% deterministic in the output it generates * The test suite of the implementation tests this property Reasons why they could be guaranteed to be different: * The algorithm calls for putting a date stamp or nonce value in the output. * The algorithm calls for putting the name or version of the compression tool used into the output. * The compression algorithm is not deterministic. * The uncompression algorithm is not deterministic, the same archive could generate different uncompressed output depending on circumstances. (This would surprise me, but I suppose it is logically possible.) Reasons why the property could be undefined: * No-one specified this property or tested it. * There are known cases where the property is true, and known cases where the property is not true, and you never can tell which case a user fill find themselves in. The motivation for this question: I was cleaning up a file server. I had just finished compressing a very large file F1 to an archive F1.bz2, and had just irretrievably deleted F1. I came across another large file F2, with the same byte count as F1. I want to know if F2 is identical to F1. I could uncompress F1.bz2 to recreate F1, then diff F1 and F2. Or, if the archives are guaranteed to be the same if and only if inputs are the same, then I could compress F2 to archive F2.bz2, and diff F1.bz2 with F2.bz2. Best regards, —Jim DeLaHunt, Vancouver, Canada [1] bzip2 documentation <https://sourceware.org/bzip2/manual/manual.html> -- . --Jim DeLaHunt,jdlh@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant, Vancouver, B.C., Canada
Sourceware infrastructure community updates for Q1 2024 A summary of news about Sourceware, the Free Software hosting project for core toolchain and developer tools, from the last 3 months. - Sourceware now has an official donation page - StarFive VisionFive-2 RISC-V boards for builder.sourceware.org - server2 and server3 disk drive updates - Upgrading project websites from CVS to GIT - Sourceware @ Fosdem - Security policy updates for a CVE system out of control - Summer of Code = Sourceware now has an official donation page Sourceware is a Free Software hosting project for core toolchain and developer tools. Sourceware is maintained by volunteers. Hardware and bandwidth is provided by sponsors. Sourceware is a Software Freedom Conservancy member project. Conservancy handles all non-profit administrivia for Sourceware. Thanks to the Conservancy we already have collected enough money for an emergency hardware replacement fund. In case one of our hardware partners would suddenly and unexpectedly drop support we can now simply buy new hardware. And we now also have an official donation page to help fund accelerating tasks the community feels most useful. https://sourceware.org/donate.html = StarFive VisionFive-2 RISC-V boards for builder.sourceware.org StarFive has donated 4 VisionFive-2 risc-v boards with 8GB, 4-core JH7110 supporting the RV64GC ISA for the CI running on builder.sourceware.org. Which has allowed us to setup CI (and try) builders for various projects: annobin, binutils(+try), bzip2, debugedit, dwz, elfutils(+try), glibc, poke and libabigail(+try). Please contact the builder project if you want to help out with the CI services. https://sourceware.org/mailman/listinfo/buildbot = server2 and server3 disk drive updates One of the drives in server2 broke down. It was part of a 10 drive raid6 setup, which can take 2 bad disks before full failure. We also have a full mirror on server3, which has a similar raid6 setup. We ordered 3 new disks, one as replacement for the bad disk and a spare for server2 and server3 in case of future drive failures. The drive has been replaced and everything is running smoothly. We have a fund for replacing hardware when needed. But if you want to help out keeping everything running smoothly you can donate on our new donation page https://sourceware.org/donate.html = Upgrading project websites from CVS to GIT. Various projects were still creating their project homepages from CVS. We upgraded both glibc and binutils to have a public git htdocs repository now to which the whole community can contribute. https://sourceware.org/cgit/binutils-htdocs/ https://sourceware.org/cgit/glibc-htdocs/ Please contact us if you want to upgrade how you publish your projects homepage. https://sourceware.org/mission.html#organization = Sourceware @ Fosdem 2024 started strong with various Sourceware core toolchain and developer tool projects presenting at Fosdem. If you missed the in person meetings, most talks have video recordings: https://fosdem.org/2024/schedule/track/gcc/ https://fosdem.org/2024/schedule/track/debuggers-and-analysis/ https://fosdem.org/2024/schedule/event/fosdem-2024-2207-the-plan-for-gccrs/ Various Sourceware volunteers, overseers and project leadership committee members also met informally with FSF/GNU and SFC admins to coordinate cross free software infrastructure administration matters. And if you like to organize an online virtual mini-BoF around some topic or project then the Conservancy BBB server is available for all Sourceware projects. You can create your own account at https://bbb.sfconservancy.org/b/signup which we can then activate for you. Note: Anyone is able to join a meeting, accounts are only required to create new meetings. = Security policy updates for a CVE system out of control The Common Vulnerabilities and Exposures (CVE) system seems broken and has been issuing more and more questionable advisories. Various Sourceware hosted projects have been writing security policies to help users know which bugs might have security implications. https://sourceware.org/cgit/elfutils/tree/SECURITY https://sourceware.org/cgit/binutils-gdb/tree/binutils/SECURITY.txt https://gcc.gnu.org/cgit/gcc/tree/SECURITY.txt The glibc project even setup their own security mailinglist and CNA (CVE Numbering Authority) publishing their own advisories: https://sourceware.org/glibc/security.html https://sourceware.org/cgit/glibc/tree/advisories If you need any help adding infrastructure services for your security projects, please reach out: https://sourceware.org/mission.html#organization = Summer of Code Some Sourceware hosted projects will take part in Summer of Code 2024. If you are interested in participating please see https://gcc.gnu.org/wiki/SummerOfCode https://www.gnu.org/software/soc-projects/ideas-2024.html
bzip2 yocto recipe does not create libbz2.so.1.0 as a result /usr/lib/gcc/aarch64-poky-linux/11.4.0/../../../../aarch64-poky-linux/bin/ld: warning: libbz2.so.1.0, needed by /home/nvidia/.vs/trunk/c1545438-b69f-4060-bbe2-cc55a2c7de59/src/Common/ThirdParty/boost/1.72/gcc_aarch64/lib/libboost_iostreams.so.1.72.0, not found (try using -rpath or -rpath-link) so I had to create a bbapend to create just that link It is obviously an oversight... please correct Thanks /Patrick
Sourceware infrastructure community updates for Q4 2023 - 6 months with the Software Freedom Conservancy - Sourceware @ Fosdem - OSUOSL provides extra larger arm64 and x86_64 buildbot servers - No more From rewriting for patches mailinglists = 6 months with the Software Freedom Conservancy Sourceware thanks Conservancy for their support and urges the community to support Conservancy. Sourceware has only been a Software Freedom Conservancy member project for just 6 months. But the story started a long time ago and a lot has happened in that time: https://sfconservancy.org/blog/2023/nov/27/sourceware-thanks-conservancy/ We hope the community will support the Software Freedom Conservancy 2023 Fundraiser and become a Conservancy Sustainer https://sfconservancy.org/sustainer = Sourceware @ Fosdem Various Sourceware projects will be present at Fosdem plus some overseers and of course Conservancy staff. Get your talk submissions in before end of the week (December 1st) to these developer rooms: Debuggers and Analysis tools gdb, libabigail, systemtap, valgrind, binutils, elfutils, gnupoke, cgen https://inbox.sourceware.org/6a2e8cbf-0d63-24e7-e3c2-c3d286e2e6d9@redhat.com/ GCC compiler devroom gcc, binutils, glibc, newlib https://inbox.sourceware.org/36fadb0549c3dca716eb3b923d66a11be2c67a61.camel@redhat.com/ And if you like to organize an online virtual mini-BoF around some topic or project then the @conservancy BBB server is available for all Sourceware projects. https://inbox.sourceware.org/9ca90cd013675a960d47ee09fa4403f69405e9f2.camel@klomp.org/ = OSUOSL provides extra larger arm64 and x86_64 buildbot servers There have been complaints about overloaded builders. So OSUOSL have provided us with another arm64 and x86_64 server. The new servers do the larger gcc and glibc builds so the other builders can do quicker (smaller) CI builds without having to wait on the big jobs. This also frees up the other container builders to do more automated jobs like the recently added autotools generated files checker for gcc, binutils and gdb: https://inbox.sourceware.org/20231115194803.GW31613@gnu.wildebeest.org/ Please contact the builder project buildbot@sourceware.org if you want to run some automated jobs on https://builder.sourceware.org/ = No more From rewriting for patches mailinglists Because of dkim, strict dmarc policies and an old mailman setup Sourceware mailinglists used From rewriting. No more! We upgraded mailman, gave up subject prefixes, mail footers, html stripping and reply-to mangling. After the libc-alpha and gcc-patches mailinglist tests to avoid From rewriting worked out nicely we enabled the same settings to some other mailinglists. The gcc patches lists for libstdc++, libgccjit, fortran and gcc-rust. And for those projects that use patchwork, newlib, elfutils, libabigail and gdb. This hopefully makes mailing patches and using git am on them a bit nicer. Outgoing sourceware email now also includes ARC headers. https://en.wikipedia.org/wiki/Authenticated_Received_Chain Feedback on whether this helps email delivery appreciated. Please contact overseers if you would like the new setting for any other Sourceware mailinglist. Thanks to the FSF tech-team for walking us through their setup for lists.gnu.org
Sourceware infrastructure community updates for Q3 2023 - Sourceware 25 Roadmap - git source code integrity - inbox.sourceware.org vs HTML email - Continuous glibc src and manual snapshots - Conservancy BBB server for Sourceware projects - Working on individual tech sovereignty together - Sourceware Overseers Open Office hour = Sourceware 25 Roadmap Preparing Sourceware for the next 25 years. In the last couple of years we have started to diversify our hardware partners, setup new services using containers and isolated VMs, investigated secure supply chain issues, added redundant mirrors, created a non-profit home, collected funds, invested in open communication, open office hours and introduced community oversight by a Sourceware Project Leadership Committee with the help from the Software Freedom Conservancy. https://sourceware.org/sourceware-25-roadmap.html = git source code integrity. gitsigur for protecting git repo integrity. With comparisons, developer workflow examples and composition possibilities for gitsigur, b4 and sigstore. https://inbox.sourceware.org/ZJ3Tihvu6GbOb8%2FR@elastic.org/ Sourceware now also allows signed git pushes (in addition to signed git commits). = inbox.sourceware.org vs HTML email HTML email. Most Sourceware projects allow it, if there is at least a text/plain alternative. But public-inbox is not so forgiving, it only allows plain-text emails, HTML is rejected by default. So the https://inbox.sourceware.org archive was incomplete. We now have a filter that removes redundant HTML parts before storing in public-inbox. And we re-imported missing emails to make the archive complete. But please don't sent HTML email. It will make DKIM verification of your email impossible. = Continuous glibc src and manual snapshots glibc is the latest Sourceware project that provides continuous snapshots from current git with both source archives and manuals. https://snapshots.sourceware.org This helps to make sure the release process always works and that manuals can be produced in various formats. Thanks to OSUOSL for hosting the snapshots server. = Conservancy BBB server for Sourceware projects The Software Freedom Conservancy is extending the use of their Big Blue Button instance https://bbb.sfconservancy.org/ to Sourceware projects that want to host video meetings. https://sfconservancy.org/news/2023/aug/15/exit-zoom/ Please contact overseers@sourceware.org for instructions on how to create an account for your project. Note: Anyone is able to join a meeting, accounts are only required to create new meetings. = Working on individual tech sovereignty together Valgrind was picked for a FUTO https://futo.org Microgrant, which has been donated to Sourceware through the Software Freedom Conservancy for maintaining and expanding the infrastructure for Valgrind and other core toolchain and developer tool projects. https://www.youtube.com/watch?v=aYzzOfQehPg If you want to donate to Sourceware please see https://sfconservancy.org/donate and become a Conservancy Sustainer or give directly by mentioning Sourceware as comment or on the memo line. = Sourceware Overseers Open Office hour Every second Friday of the month is the Sourceware Overseers Open Office hour in #overseers on irc.libera.chat from 18:00 till 19:00 UTC. The next one will be Friday September 4th. Please feel free to drop by with any Sourceware services and hosting questions. Feedback and questions about the Sourceware 25 Roadmap are also very appreciated. https://sourceware.org/sourceware-25-roadmap.html Of course you are welcome to drop into the #overseers channel at any time and we can also be reached through email and bugzilla: https://sourceware.org/mission.html#organization If you aren't already and want to keep up to date on Sourceware infrastructure services then please also subscribe to the overseers mailinglist. https://sourceware.org/mailman/listinfo/overseers We are also on the fediverse these days: https://fosstodon.org/@sourceware The Sourceware Project Leadership Committee also meets once a month to discuss all community input. The committee will set priorities and decide how to spend any funds, negotiate with hardware and service partners, create budgets together with the Conservancy, or decide when a new fundraising campaign is needed. Up till now we have been able to add new services without needing to use any of the collected funds. Our hardware partners have also been very generous with providing extra servers when requested. The current committee includes Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor, Tom Tromey, Jon Turney, Mark J. Wielaard and Elena Zannoni.
Sourceware infrastructure community updates for Q2 2023 - https://dwarfstd.org/ joins Sourceware - https://snapshots.sourceware.org/ - Simpler b4 setup - Sourceware joins Software Freedom Conservancy - Sourceware joins the fediverse @sourceware@fosstodon.org - Mirrors and Software Heritage - Open Office Hours (this Friday) = dwarfstd.org joins Sourceware The DWARF Debugging Standard, are now hosted on Sourceware. This includes git.dwarfstd.org, wiki.dwarfstd.org and lists.dwarfstd.org. Sourceware already hosted the old dwarf2 archives https://sourceware.org/legacy-ml/dwarf2/ = snapshots.sourceware.org Thanks to OSUOSL we now have a snapshots server to publish static artifacts from current git repos created in isolated containers. It can be used as alternative to git hooks or cron jobs to generate snapshots for things like: GNU poke code and doc snapshots: https://snapshots.sourceware.org/gnupoke/trunk/latest/ elfutils code coverage: https://snapshots.sourceware.org/elfutils/coverage/latest/ libabigail website, manuals and api docs: https://snapshots.sourceware.org/libabigail/html-doc/latest/ valgrind snapshots and manuals: https://snapshots.sourceware.org/valgrind/trunk/latest/ DWARF draft spec: https://snapshots.sourceware.org/dwarfstd/dwarf-spec/latest/ The container files and build steps are defined through the builder project. https://inbox.sourceware.org/20230409113050.GA6496@gnu.wildebeest.org = Simpler b4 setup Previously the guidance for adding b4 support through inbox.sourceware.org was to add per project mailing-list b4 settings. But if all your projects have an inbox.sourceware.org mailinglist you can simply use: $ git config --global b4.midmask https://inbox.sourceware.org/%s $ git config --global b4.linkmask https://inbox.sourceware.org/%s Since public-inbox knows about all message-ids independent of which mailinglist they were posted in and b4 just needs the message-id. Thanks to Thomas Schwinge for the hint. = Sourceware joins Software Freedom Conservancy https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/ As the fiscal host of Sourceware, Software Freedom Conservancy will provide a home for fundraising, legal protection and governance that will benefit all projects under Sourceware's care. We share one mission: developing, distributing and advocating for Software Freedom. Together we will offer a worry-free, friendly home for core toolchain and developer tool projects. There will be no big changes, this is just an oppertunity to protect the confidence in the long term future of Sourceware. There is a small budget already available which we would like to use for extra redundancy and backup services. But we are happy to discuss other ideas like mentioned in the original proposal and Sourceware technical roadmap. https://inbox.sourceware.org/Yw5Q4b%2F2nqvAi3K4@elastic.org/ https://inbox.sourceware.org/YrLdfDWzq1T4k5xg@wildebeest.org/ = Sourceware joins the fediverse Sourceware joined the fediverse at @sourceware@fosstodon.org https://fosstodon.org/@sourceware The account will be used for Sourceware announcements, notices about downtime and temporary issues with our network. = Mirrors and Software Heritage We added two rsync and http mirrors in China https://sourceware.org/mirrors.html And the Software Heritage project https://www.softwareheritage.org/ started archiving the active git repos. We are working on also adding the (historic) subversion and cvs archives. This is in addition to the mirrors at SourceHut https://sr.ht/~sourceware/ Thanks to Paul Wise for getting the ball rolling. https://sourceware.org/bugzilla/show_bug.cgi?id=29618 = Overseers Open Office hours Every second Friday of the month is the Overseers Open Office hour in #overseers on irc.libera.chat from 18:00 till 19:00 UTC. That is this Friday June 9th. Of course you are welcome to drop into the #overseers channel at any time and we can also be reached through email and bugzilla: https://sourceware.org/mission.html#organization If you aren't already and want to keep up to date on Sourceware infrastructure services then please also subscribe to the overseers mailinglist. https://sourceware.org/mailman/listinfo/overseers
https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/ After various discussions and lots of positive feedback [1] [2] [3] [4] Software Freedom Conservancy and Sourceware proudly announce that Sourceware today joins SFC as a member project! As the fiscal host of Sourceware, Software Freedom Conservancy will provide a home for fundraising, legal protection and governance that will benefit all projects under Sourceware's care. We share one mission: developing, distributing and advocactingfor Software Freedom. Together we will offer a worry-free, friendly home for core toolchain and developer tool projects. We are happy to discuss this in #overseers on irc.libera.chat now 18:00-19:00 UTC. And we will also start regular Overseers Open Office Hours every second Friday of the month on irc at the same time. Of course you are welcome to drop into the #overseers channel at any time and we can also be reached through email and bugzilla: https://sourceware.org/mission.html#organization To support the Software Freedom Conservancy, please become a Sustainer https://sfconservancy.org/sustainer You can also donate directly to Sourceware: https://sfconservancy.org/members/current/#Sourceware as a directed donation (mention Sourceware in the comment or memo line) See https://sfconservancy.org/donate/ for other ways to donate. [1] https://sourceware.org/pipermail/overseers/2022q3/018802.html [2] https://sourceware.org/pipermail/overseers/2022q3/018804.html [3] https://sourceware.org/pipermail/overseers/2022q3/018834.html [4] https://www.fsf.org/events/sourceware-infrastructure-a-presentation-and-community-q-a https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/ Sourceware, one of the longest standing Free Software hosting platforms, joins SFC Important Free Software infrastructure project finds non-profit home May 15, 2023 As a home for Free Software projects since 1998, Sourceware is a keystone in Free Software infrastructure. For almost 25 years Sourceware has been the long-time home of various core toolchain project communities. Projects like Cygwin, a UNIX API for Win32 systems, the GNU Toolchain, including GCC, the GNU Compiler Colection, two C libraries, glibc and newlib, binary tools, binutils and elfutils, debuggers and profilers, GDB, systemtap and valgrind. Sourceware also hosts standard groups like gnu-gabi and the DWARF Debugging Standard. See the full list project hosted and services provided on the [1]Sourceware projects page. Becoming an SFC member project will improve future operations carried out by dedicated volunteers to and furthering the mission of Free Software hosting. This will accelerate the Sourceware [2]technical roadmap to improve and modernize the infrastructure. As the fiscal host of Sourceware, Software Freedom Conservancy will provide a home for fundraising, legal assistance and governance that will benefit all projects under Sourceware's care. We share one mission: developing, distributing and advocating for Software Freedom. And to offer a worry-free, friendly home for Free Software communities. We see a bright future working together. With Conservancy as fiscal sponsor, Sourceware will also be able to fundraise and have the community of volunteers work together with paid contractors and enter into contracts for managed infrastructure where appropriate. SFC looks to Sourceware's years of experience in providing outstanding infrastructure as an inspiration for improving the Free Software ecosystem both for other SFC projects, and also in furthering SFC's mission around campaigns to promote Software Freedom Infrastructure. For decades, Sourceware has shown that hosting Free Software projects with Free Software infrastructure is not only possible, but helps create and fosters the growth of relationships and networks within the Free Software communities. SFC is thrilled to join the powerful history of demonstrable experience to grow hosting options that are 100% free software, in the future to bring in new ideas, communities, and projects! Projects hosted by Sourceware are part of the core toolchain for GNU/Linux distros, embedded systems, the cloud and, through Cygwin, Windows. Back in 1984 Ken Thompson's Reflections on Trusting Trust already described how making the source code for these tools available is essential to create what today we call secure software supply chains. Sourceware provides robust infrastructure and services for projects to adopt secure collaboration and release policies. We forsee future cooperation with other Conservancy member projects, such as the [3]Reproducible Builds project which provides an independently-verifiable path to supply chain security. Additionally, Sourceware will leverage Conservancy advisory role in how community projects are impacted by and can comply with regulations like NIST, CISA, USA Cyber Security Directives and the EU Cyber Resilience act. Each SFC member project is led by a Project Leadership Committee (PLC). Each individual member of the PLC participates in their own capacity, but nevertheless the majority of the PLC never includes a majority of people affiliated with the same organization. Sourceware's PLC includes various volunteers, past and present, from the Sourceware community. The founding PLC is: Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor, Tom Tromey, Jon Turney, and Mark J. Wielaard. Recent discussions have inspired the Sourceware volunteers to think carefully about the future and succession of the leadership for this important hosting project. By joining SFC, Sourceware gains access to strategic advice and governance expertise to recruit new volunteers and raise funds to support work on Sourceware infrastructure. As part of this governance improvement, Sourceware also announces today regular irc office hours for guest project admins to advise and discuss any needs and issues in hosting. The [4]Sourceware mission page lists various other ways to contact and participate in the community. Sourceware will continue its long standing mission of providing free software infrastructure to the projects it supports, and this will not change moving forward. The affiliation with SFC will be transparent to the projects hosted on Sourceware. Project admins will keep being in charge of how they utilize the services Sourceware provides. To support the Software Freedom Conservancy, please become a [5]Sustainer. You can also [6]donate directly to Sourceware (mention Sourceware in the comment or memo line). See [7]the donation page for other ways to donate. Sourceware may be volunteer managed, but wouldn't be possible without the hardware, network resources and services provided by Red Hat and OSUOSL. Additionally [8]build/CI testing machines are provided by various individuals and the Brno University, Marist College, IBM, the Works on Arm initiative and the Gentoo Foundation. References 1. https://sourceware.org/projects.html 2. https://inbox.sourceware.org/overseers/YrLdfDWzq1T4k5xg@wildebeest.org/ 3. https://reproducible-builds.org/ 4. https://sourceware.org/mission.html 5. https://sfconservancy.org/sustainer/ 6. https://sfconservancy.org/donate/#wire 7. https://sfconservancy.org/donate/ 8. https://builder.sourceware.org/
Sourceware infrastructure community updates for Q1 2023. = New cgit setup gitweb has been working out pretty nicely for many years, but cgit is cgit is nicer looking, has easier to understand URLs and is much faster. The first experimental setup can be found here: https://cygwin.com/cgit/ https://gcc.gnu.org/cgit/ https://sourceware.org/cgit/ Thanks to Jon Turney for the cygwin work. If this works out, we would like to deploy a script written by Arsen Arsenović to switch the main /git/ to cgit while keeping all old gitweb URLs working. See https://sourceware.org/bugzilla/show_bug.cgi?id=29769 = New sparc builder for builder.sourceware.org Thanks to the Gentoo Foundation and OSUOSL [*] there is now a large (and small) gentoo-sparc worker: https://builder.sourceware.org/buildbot/#/workers/35 https://builder.sourceware.org/buildbot/#/workers/36 Please contact the buildbot mailinglis if you want to do specific builds on it: https://sourceware.org/mailman/listinfo/buildbot = AI comes to the bunsen test results It isn't a large language model chatbot, but probably more useful. https://builder.sourceware.org/testruns/ will now predict what it believes the the dejagnu test results should be. It will give a score for what it expected a result to be. e.g for a new FAIL it could say: mispredicted PASS 81% which means in 81% of similar test runs that test PASSed. So you can concentrate on those FAILing tests that have a high PASSing score. For more info see: https://inbox.sourceware.org/buildbot/20230206160507.GA31394@redhat.com/ = openssh update produces misleading invalid key length warning Connecting to sourceware through ssh with a newer openssh or crypto policy might produce a misleading warning about the key length being too short: Bad server host key: Invalid key length Please don't try to replace your ssh key, there is nothing wrong with it. The issue is that you might have an old server key in your ~/.ssh/known_hosts file. Simply remove it and reconnect to get the new server key: ssh-keygen -R sourceware.org ssh-keygen -R cygwin.com ssh-keygen -R gcc.gnu.org See also https://bugzilla.redhat.com/show_bug.cgi?id=2164016 = inbox.sourceware.org and '/' in Message-ID Those using public-inbox might have noticed that when a Message-ID contains a slash character '/' it is not always correctly encoded or decoded as %2F in the inbox.sourceware.org path URLs. If you are using a newer mutt as email client then you might want to make sure that your Message-ID doesn't contain any characters that might need URL encoding. For mutt 2.2 you might want to set the following in your ~/.muttrc to produce a uuid-like Message-ID as other email clients do: set message_id_format="<%x%x%x%x-%x%x-%x%x-%x%x-%x%x%x%x%x%x@%f>" For older mutt, and some more background, see: https://people.kernel.org/monsieuricon/fix-your-mutt = Happy hacking And as always please feel free join the overseers mailinglist https://sourceware.org/mailman/listinfo/overseers file infrastructure issues in bugzilla https://sourceware.org/bugzilla/describecomponents.cgi?product=sourceware or join us in #overseers on irc.libera.chat [*] But specifically Sam James. We should also thank the following other individuals and organisations for maintaining and/or providing hardware for builder.sourceware.org Brno University, Dan Horák, Marist University, Thomas Fitzsimmons, Mark Wielaard, Frank Eigler, IBM, Carl Love, The Works on Arm initiative, Christophe Lyon, and Red Hat
https://sourceware.org/bugzilla/show_bug.cgi?id=30001 Jeffrey Walton <noloader at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |noloader at gmail dot com --- Comment #3 from Jeffrey Walton <noloader at gmail dot com> --- (In reply to Eli Schwartz from comment #2) > In general my understanding is that autoconfiscation patch you linked was > explicitly rejected several times due to the "Incompatible changes" section. > > My patch series solves this problem and a number of other problems. It > should also still work fine with cross-compilation, just specify > `./configure --host=<triplet>` and it will set up e.g. `$CC` correctly. One comment... To cross-compile, you should specify both --build and --host. --build is easy. config.guess gives that triplet: $ find /usr/share -name config.guess ... /usr/share/autoconf/build-aux/config.guess $ /usr/share/autoconf/build-aux/config.guess x86_64-pc-linux-gnu --host is the trickier one. There is no list of cross-compile triplets. Also see https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html . -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30001 --- Comment #2 from Eli Schwartz <eschwartz at archlinux dot org> --- In general my understanding is that autoconfiscation patch you linked was explicitly rejected several times due to the "Incompatible changes" section. My patch series solves this problem and a number of other problems. It should also still work fine with cross-compilation, just specify `./configure --host=<triplet>` and it will set up e.g. `$CC` correctly. -- You are receiving this mail because: You are on the CC list for the bug.
We've received word from our data centre hosts that they will have a network infrastructure outage tomorrow, Tuesday 2023-01-31, between 8am and 12am EST (UTC-5). We may follow that up with a server firmware-related update/boot. This impacts sourceware.org, builder.sourceware.org, patchwork.sourceware.org, inbox.sourceware.org, valgrind.org, elfutils.org, cygwin.com and gcc.gnu.org, which all may be unreachable for a couple of hours. Note that there are read-only mirrors of the git repositories at https://sr.ht/~sourceware/ if you need access during the outage. Please feel free to hang out at irc.libera.chat #overseers to follow the current status.
https://sourceware.org/bugzilla/show_bug.cgi?id=30001 Sam James <sam at gentoo dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eschwartz at archlinux dot org, | |sam at gentoo dot org --- Comment #1 from Sam James <sam at gentoo dot org> --- See Eli's patch series: https://sourceware.org/pipermail/bzip2-devel/2022q2/000166.html. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30001 Bug ID: 30001 Summary: Port to autoconf build system (maybe use sbrabec's patch?) Product: bzip2 Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: bzip2 Assignee: nobody at sourceware dot org Reporter: slyich at gmail dot com CC: bzip2-devel at sourceware dot org Target Milestone: --- To ease cross-compilation of bzip2 NixOS uses https://ftp.suse.com/pub/people/sbrabec/bzip2/for_downstream/bzip2-1.0.6.2-autoconfiscated.patch version of autoconf build system for bzip2. WDYT of merging it upstream in some form? Currently NixOS generates ./configure using autoconf and automake. NixOS would prefer using autoconf-based upstream bzip2 release tarball without a dependency on these development tools. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
On Tue, Nov 15, 2022 at 10:35:41PM +0100, Mark Wielaard wrote: > https://www.fsf.org/events/sourceware-infrastructure-a-presentation-and-community-q-a > https://inbox.sourceware.org/overseers/6e9cde97-d880-5343-6cfd-16a648cf67f6@fsf.org/ > > We like to discuss how to use the new infrastructure setup this last > year, builder, try/ci/full buildbots, bunsen testsuite analysis, > patchwork patch tracking, handling patches/email with public-inbox, > b4, the sourcehut mirror. And the future of Sourceware as a Software > Freedom Conservancy member project. (*) Thanks to everybody who could attend last month. For those who couldn't the html slides and markdown sources with the presenter notes are here: https://gnu.wildebeest.org/blog/mjw/2022/11/20/new-services-for-sourceware-sfc-fsf/ And a (video) recording is here: https://media.libreplanet.org/u/libreplanet/m/sourceware-infrastructure-a-presentation-and-community-q-a/ We hope to have answered all questions, but if we missed anything, or you want to help with the infrastructure please contact us at the overseers mailinglist or file a sourceware infrastucture bug: https://sourceware.org/mailman/listinfo/overseers https://sourceware.org/bugzilla/buglist.cgi?component=Infrastructure&product=sourceware Next year Sourceware will be 25 years. Happy new year! (*) The Software Freedom Conservancy is currently running a fundraiser: https://sfconservancy.org/sustainer/#YearInReview
https://sourceware.org/bugzilla/show_bug.cgi?id=28283 Mark Wielaard <mark at klomp dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mark at klomp dot org --- Comment #2 from Mark Wielaard <mark at klomp dot org> --- So both cases the chars tested are user supplied and could in theory be signed chars. So casting to Int32 or int could create negative values. Which isspace and isdigit don't handle. Proposed patch: diff --git a/bzip2.c b/bzip2.c index 1538faf..9ef7536 100644 --- a/bzip2.c +++ b/bzip2.c @@ -1767,8 +1767,8 @@ void addFlagsFromEnvVar ( Cell** argList, Char* varName ) if (p[i] == 0) break; p += i; i = 0; - while (isspace((Int32)(p[0]))) p++; - while (p[i] != 0 && !isspace((Int32)(p[i]))) i++; + while (isspace((UChar)(p[0]))) p++; + while (p[i] != 0 && !isspace((UChar)(p[i]))) i++; if (i > 0) { k = i; if (k > FILE_NAME_LEN-10) k = FILE_NAME_LEN-10; for (j = 0; j < k; j++) tmpName[j] = p[j]; diff --git a/bzlib.c b/bzlib.c index 2178655..100873c 100644 --- a/bzlib.c +++ b/bzlib.c @@ -1408,7 +1408,7 @@ BZFILE * bzopen_or_bzdopen case 's': smallMode = 1; break; default: - if (isdigit((int)(*mode))) { + if (isdigit((unsigned char)(*mode))) { blockSize100k = *mode-BZ_HDR_0; } } -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=28283 Paul Marquess <pmqs at outlook dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pmqs at outlook dot com --- Comment #1 from Paul Marquess <pmqs at outlook dot com> --- This issue has been reported downstream in the Perl sources, which include a sub-set of the bzip2 source. Believe that OpenBSD is a candidate for this issue causing a problem. Also, see https://wiki.sei.cmu.edu/confluence/display/c/STR37-C.+Arguments+to+character-handling+functions+must+be+representable+as+an+unsigned+char for details on a coding standard that mentions the isdigit issue. -- You are receiving this mail because: You are on the CC list for the bug.
This Friday, 18 November, at 16:00 UTC (11:00am Eastern, 17:00 Central European Time) the FSF will host a session on their BBB server about the current sourceware infrastructure and future plans. https://www.fsf.org/events/sourceware-infrastructure-a-presentation-and-community-q-a https://inbox.sourceware.org/overseers/6e9cde97-d880-5343-6cfd-16a648cf67f6@fsf.org/ We like to discuss how to use the new infrastructure setup this last year, builder, try/ci/full buildbots, bunsen testsuite analysis, patchwork patch tracking, handling patches/email with public-inbox, b4, the sourcehut mirror. And the future of Sourceware as a Software Freedom Conservancy member project. (*) This presentation is for everybody who likes to discuss (and wants to help with) automating the infrastructure to make contributing to our projects more fun and more productive. (*) Similar to the BoF we intended to do at the Cauldron this year: https://gnu.wildebeest.org/~mark/sourceware/presentation.html
https://sourceware.org/bugzilla/show_bug.cgi?id=29280 --- Comment #1 from Sean McBride <sean@rogue-research.com> --- Created attachment 14412 --> https://sourceware.org/bugzilla/attachment.cgi?id=14412&action=edit Patch to replace sprintf with snprintf -- You are receiving this mail because: You are on the CC list for the bug.
[-- Attachment #1: Type: text/plain, Size: 1205 bytes --] > On 9 Jun 2022, at 06:52, Eli Schwartz via Bzip2-devel <bzip2-devel@sourceware.org> wrote: > > On 6/3/22 1:09 AM, ~eschwartz wrote: >> From: Eli Schwartz <eschwartz93@gmail.com> >> >> A pkg-config file is necessary in order to robustly communicate across >> build systems that bz2 is installed, *where* it is installed, and the >> correct CFLAGS / LDFLAGS to use in order to compile and link against it. > > > Some distros already provide one of these, so it's currently a bit > inconsistent how to look for the library. As a result, there is software > in the wild that probes for the library name, and fails if the library > is installed to a custom prefix, and other software that checks for > pkg-config, and fails on distros that don't provide their own bzip2.pc > > In general it's good to have. > > And particularly, it makes it much easier to detect bzip2 as "a > dependency" instead of "manual linker flags" from the Meson build > system, which can then toggle between multiple "dependency" providers > via e.g. > https://mesonbuild.com/Wrap-dependency-system-manual.html#provide-section > The whole series looks great, thanks for doing this. Best, sam [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 358 bytes --]
Hi, We are very grateful for the public replies and suggestions received to our proposal, which were all very positive. And we are happy to report that the SFC's Evaluations Committee has voted to accept Sourceware as a Conservancy member project. If people are interested in, or want to help out with, the next steps they are invited to join the sourceware overseers list. https://sourceware.org/pipermail/overseers/2022q3/018834.html Thanks, Chris Faylor <cgf@sourceware.org> Frank Eigler <fche@sourceware.org> Mark Wielaard <mark@klomp.org>
Hi! If you have an interest in the long term future of the sourceware hosting server which this project is using, please consider checking out this thread on our local overseers@ mailing list. Everything is fine, we're just thinking ahead. https://sourceware.org/pipermail/overseers/2022q3/018802.html Chris Faylor <cgf@sourceware.org> Frank Eigler <fche@sourceware.org> Mark Wielaard <mark@klomp.org>
https://sourceware.org/bugzilla/show_bug.cgi?id=29280 Bug ID: 29280 Summary: Replace sprintf with safer snprintf Product: bzip2 Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: bzip2 Assignee: nobody at sourceware dot org Reporter: sean@rogue-research.com CC: bzip2-devel at sourceware dot org Target Milestone: --- bzip2 has one call to sprintf in git master. sprintf is dangerous because it's easy to overrun the buffer. Building on OpenBSD and macOS produce compiler warnings upon any use of the function. Would be nice to change this one use to snprintf, which takes the buffer size. -- You are receiving this mail because: You are on the CC list for the bug.
On 6/3/22 12:20 AM, ~eschwartz wrote:
> From: Eli Schwartz <eschwartz93@gmail.com>
>
> This doesn't investigate the topic of fully autotools'ing the build,
> with automake and libtool, as there are libtool compatibility
> considerations to take into account.
>
> All we do for now is make the standard ./configure script that formats
> the Makefile in order to respect some low-level standards:
>
> - GNU directory variables to control output locations.
> - respect $DESTDIR if given.
> - check for $CC, $CFLAGS, etc
> - including cross-compile support
> ---
I was unable to actually test `make dist`, by the way, as it didn't seem
to want to play nicely with texlive on my system.
$ make manual.pdf
./xmlproc.sh -pdf manual.xml
Creating manual.pdf ...
Making portrait pages on USletter paper (8.5inx11in)
Cleaning up: output manual.fmt *.aux manual.fo manual.log texput.log *.out
deleting output
deleting manual.fmt
deleting *.aux
rm: cannot remove '*.aux': No such file or directory
deleting manual.fo
deleting manual.log
deleting texput.log
deleting *.out
rm: cannot remove '*.out': No such file or directory
make: *** [Makefile:234: manual.pdf] Error 1
This shell script for creating the manual fails to create either the pdf
file, or the temporary files that it then fails to remove... but it
doesn't say why it failed so it's not clear whether I have a
misconfiguration or what.
--
Eli Schwartz