Re: Will there be a gnu/hurd spin when a 64bit hurd is released?
A very very long time ago, I helped set up the filename structure for downloads that Fedora uses now of `/pub/fedora/linux` when I set up the 'new' Red Hat Linux download structure for mirrors in 2000. The reason was that I figured that at some point we might expand to Hurd, a BSD, or other items as products might grow. When Fedora set up its file structure around 2003, this naming structure was kept and has been around for the last 20 years. In that time, it has been proposed multiple times that `we should do a `, but no one has actually done the work to make it happen. It takes a LOT more than just proposing something on a mailing list to make a new port or release work. It takes a lot of hard work to first learn how the other operating system works, how it compiles, can the tools which make an operating system 'Fedora' be ported to that tool, and it then takes the work of making those things happen more than once. At that point, it takes a lot of ground effort to figure out how much of the software in the Fedora ecosystem can be compiled for the new operating system and will actually work in it. Going from the amount of time it took to get the original Debian Hurd and BSD to actually work (with some idea of how much work the people getting a RiscV port have done)... my guess would be it would take about 10-15 people with about 2x that many systems and about 2 to 4 years to get it to a port where it could be 'releasable' outside of that small group of people interested in it. Which I think is why after 24 years, there isn't any other base kernel under /pub/fedora/ than linux. Just getting a port to a new architecture takes anywhere from 5-10 people multiple years to make a stable and repeatable release cycle. These are people who have worked in Linux for a long time and have experience with the many tools which 'make Fedora' with previous porting efforts. It would take people who have been running HURD in some way to know what it does and know how to make things like rpm, mock, dnf work on a different fundamental architecture (Micro kernel based versus unikernel). I wish the people who are interested in it as much luck as I can give. On Mon, 27 May 2024 at 16:39, Ryan Bach via devel < devel@lists.fedoraproject.org> wrote: > That would be awesome. Thoughts? > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: rpm-ostree, dnf and bootc in a bootable containers world
On Tue, 21 May 2024 at 03:18, Petr Pisar wrote: > V Mon, May 20, 2024 at 02:15:49PM -0400, Joseph Marrero napsal(a): > > * dnf4 & dnf5 should provide a more helpful error when a user types > > `dnf install` on a booted image-based system (pointing them to unlock > > the system or use rpm-ostree). > [...] > > * dnf should be used during container builds of image-based Fedora for > > most applications and examples. > > > How is it that DNF is not good enough for users, but at the same time it's > good enough for building the images? > > My guess was that automatic builds will have an unlocked layer and failure to have one means that something broke in the build system before then and needs to be fixed. The error message wanted to be added would help the release engineers also diagnose the problem and look for a fix. > -- Petr > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: LLVM Packaging Ideas for Fedora 41
On Wed, 15 May 2024 at 04:09, Vít Ondruch wrote: > > > Every time I bring up such discussion, I am told "the reason it is > called python3 and not python is well know" and yes, it is know to some, > including me. But advocating for less experienced users. I advocating > for users which are not experts on Python ecosystem. I am advocating for > conventions. > > Going from the convention I am finding on my MacOS-X brew and the Windows box.. the convention is some variant of calling both the command and package some variant of python3. Brew only gives you a python3 command and will say the package is some name like python@3.-3.. Windows does have a python package but also calls it python3 in places. Also going from things I run into regularly.. python2 is still the most used language in many places with it being provided as /usr/local/bin/python or some other variant. Scripts which call /usr/bin/python are still mostly python2 scripts and will break if run with python3 on the first `print ""` statement or some other thing. With EL7 and similar long lived python2 distributions going EOL this year.. I expect that this python2 will start to move, but I figure we are still a decade out (going from how long I was dealing with perl4 after perl5 had been out). > I am trying to demonstrate that things should be obvious. There is > "Python" language. Not "Python 3" language. There is e.g. > https://www.python.org/ not https://www.python3.org/ etc. > > Therefore, I'd rather hear "you are right, that does not make too much > sense (these days). It is confusing and it is about the time to make the > things right (finally)". In your words "We are in 2024, so I suppose we > could rename everything python3 to python now" is what I would appreciate. > > > Vít > > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Intent to start ARC investigation git-forge replacement
On Wed, 8 May 2024 at 10:17, Akashdeep Dhar wrote: > Hello folks, > > It has been a couple of weeks since Tomas announced the requirements > gathering phase and till now we have received about nine of those - all > from Maxwell G (by the way, thanks for your inputs) in the Fedora ARC issue > ticket[1]. > > I want to bump this up to folks' attention and ensure we account for as > many usecase requirements as possible. Please take some time and let us > know about it as comments under the ticket - multiple comments are totally > fine. > > It is going to be hard to make 'requirements' without knowing what is being done now and where with the current pagure system. A lot of functionality has been built in over a decade or so of improvements, and would only show up as 'oh we really required this' when comparing a built example of GitForge2 to current GitForge. Only a couple of people are going to know the internals of say fedpkg, pagure, packaging internals to speak to what is a 'requirement'. Most people are going to expect that 'whoever knows that' is going to answer, which then tends to be few answers at all. Having some sort of framework around what is expected can help elicit clearer input (especially when you leave out things and the usual suspects rattle on about 'clearly you have no idea how this works because you forgot about...') > If you agree with the usecase requirements mentioned in someone else's > comment, please use the reactions to let us know of the importance of the > same. Please take until 29th May 2024 to communicate your requirements with > us. > > As always, this thread can be responded to if you have any questions or > concerns. > > Index > [1] - https://pagure.io/fedora-infra/arc/issue/164 > > Regards, > Akashdeep Dhar (he/him), > Red Hat Community Platform Engineering > Elected Representative, Fedora Council > t0xic0...@fedoraproject.org > akashd...@redhat.com > TZ = Asia/Kolkata (UTC+05:30) > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d
I guess we need to see what RPM owns that symlink and get it into the build root Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren On Mon, Apr 29, 2024 at 08:22 Florian Weimer wrote: > * Richard W. M. Jones: > > >> I don't want us to have RPM spec file hacks just to get RISC-V to > >> install in the correct locations. The symbolic link evidently does not > >> cover all cases. > > > > What cases aren't covered by the symlink? We have a full, working > > Fedora/RISC-V distro using it at the moment. > > The symbolic link isn't in the buildroot. If shared objects are listed > explicitly in %files (as some guidelines recommend) and upstream > hard-codes the ABI directory names for installation purposes, the build > fails. > > Setting %_libdir to /usr/lib64/lp64d instead might work. Fixing > upstream to honor --libdir=/usr/lib64 in ./configure might be another > 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 > -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Thu, 4 Apr 2024 at 16:37, Przemek Klosowski via devel < devel@lists.fedoraproject.org> wrote: > On 4/3/24 17:49, Kevin Kofler via devel wrote: > > > Thanks for doing this. I would have loved to find a way to just have gnuplot do this nightly > And is there a statistical evaluation of that data somewhere? Downloading > 350 MiB (!) of raw CSV data does not sound to me like a convenient way to > work with it. > > It's messy, but interesting. Here's the architecture data for the last 3 > or so years: > I found using a 4 day moving average cleaned up a lot of issues ranging from Fedora proxy logs not being gotten due to script issues or similar. It also evened out the Friday night to Monday morning drop on all items we have seen in the older yum data also. > from top to bottom, x86_64 aarch64 ppc64le s390x armhfp i386 arm powerpc64 > riscv64 > > so you can see the decline of armhfp and i386. > > I don't know what to make of the relatively large population of ppc64le > and s390x; I think maybe IBM is eating their own dogfood and using it in > some internal datacenters? > When I looked at it several years ago it was being used all over from the IP space. Some of it was IBM, some of it was IBM cloud and some of it was various universities and stuff. > I am pleased to see RISC-V showing up within last year! > > > sqlite -csv :memory: > > .import totals.csv t > > select date(round(julianday(week_end)/30)*30) as Tx, count(os_arch) filter > (where os_arch like "x86_64") as x86_64, count(os_arch) filter (where > os_arch like "aarch64") as aarch64, count(os_arch) filter (where os_arch > like "ppc64le") as ppc64le, count(os_arch) filter (where os_arch like > "s390x") as s390x, count(os_arch) filter (where os_arch like "armhfp") as > armhfp, count(os_arch) filter (where os_arch like "i386") as > i386,count(os_arch) filter (where os_arch like "arm") as arm, > count(os_arch) filter (where os_arch like "powerpc64") as powerpc64, > count(os_arch) filter (where os_arch like "riscv64") as riscv64 from t > group by tx > > > > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Switching XZ for ZSTD?
On Thu, 4 Apr 2024 at 12:21, Arnie T via devel < devel@lists.fedoraproject.org> wrote: > Hello Stephen, > > How a decision to drop xz for some other compression library for software > would be a fairly slow process. First a person who is willing to do the > work would come up with a proposal on why it should be done and how it > could be done. They would be expected to also test to see how much trouble > this would be (aka find all the packages which use xz and could be changed > to another library, which ones couldn't and what the effects would be.) > Once that is done, they would make a general proposal to be reviewed by > whatever technical committee a distribution has (Fedora has one whose > acronym is FESCO, Debian has another or multiple others, etc). This would > be reviewed and if accepted it would go as a future release work with a > staged plan where some packages are moved in X release, some in X+1, and > some final plan for X+2 (or backed out completely for some reason before > then). There would be some amount of software which would rely on xz no > matter what because either the upstream has no interest in changing or it > is meant to use xz period. > ... > Currently most groups are between 0 and 1. There are a lot of things which > need to be looked at before moving off can be looked at as a goal to make > sure we aren't making things worse. > > I hope the above helps > > > Thanks, I understand more of your explanation of how it's done. > > I don't know how much time was needed to decide for example an Arch Distro > change > > "Now using Zstandard instead of xz for package compression" > > https://archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/ > > So that is an individual package choice a distribution maintainer(s) can make. In this case the pacman maintainers decided to use a different library for their packages. It doesn't change anything outside of that one tool though. It is also not getting rid of xz from Arch. They will need to keep xz around because older systems will have used the older compression and pacman and similar tools will need to 'read' that. It mainly means that newer packages will use zstandard versus xz. A similar change in Fedora would be that rpm uses zstandard by default etc. However rpm would need to keep xz because of 10 years of using xz as a compression standard in various RPMs and people need to install older software. > OK, that's my mistake. I thought that moving to open source Linux OS > Distro like Redhat-related Fedora would result big or important issues can > be fixed more efficiently than at Microsoft. > > Decisions are people issues and people issues move at people speeds. There are about 1600 packagers in Fedora and I think 22,000 packages. Changes take time to communicate, understand and implement. The worst thing to do in a security situation is actually move too fast because you think you are getting ahead of the attacker. I have seen too many times where the attacker was waiting for said move and it makes their life easier. In this case, a bit of time is needed to really get an idea of what else is screwed up and where we need to fix things. > I guess I'm learning that even important or wise choices (not saying _ > this_ is) can't be done with taking a long time. Even if they are > security related issues. > > Thanks one more time for the nice explanation! > > Cheers! > > Arnie > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Switching XZ for ZSTD?
On Thu, 4 Apr 2024 at 11:22, Arnie T via devel < devel@lists.fedoraproject.org> wrote: > > Hi, > > > There's no such thing as a "distro decision" on this one, as was > > explained in the thread already. > > I'm sure the 'explanation' is all clear to you and the other Developers. > > I'm also sure that it's not all that clear to non-Developers. > > If the explanation was clear and obvious to me, here or anywhere ales, I > wouldn't be asking the question. > > So, sorry, I guess. > > I guess I don't understand how a Distro decision is different from a > Distro IN-decision. > > Linux distributions are generally 'collective anarchies' where most packages are up to the individual packagers to support how they want things. 'Collectively' they will elect some group who will work out various high level things like 'where should the files go?' 'how should the files be packaged', 'what should we call ourselves', etc. These decisions may override what the upstream (aka the people who write the compiler, kernel, compression libraries, graphics, etc) but again it is usually a compromise. How a decision to drop xz for some other compression library for software would be a fairly slow process. First a person who is willing to do the work would come up with a proposal on why it should be done and how it could be done. They would be expected to also test to see how much trouble this would be (aka find all the packages which use xz and could be changed to another library, which ones couldn't and what the effects would be.) Once that is done, they would make a general proposal to be reviewed by whatever technical committee a distribution has (Fedora has one whose acronym is FESCO, Debian has another or multiple others, etc). This would be reviewed and if accepted it would go as a future release work with a staged plan where some packages are moved in X release, some in X+1, and some final plan for X+2 (or backed out completely for some reason before then). There would be some amount of software which would rely on xz no matter what because either the upstream has no interest in changing or it is meant to use xz period. Usually this would take a key person to drive it who understands the problem and a team of people who would be interested in actually doing the work. Without that the change will move slowly over many releases like the licensing change to SPDR. This is how a change would happen if it were decided to be done. At the moment the distributions are first trying to figure out a couple of more important things: 0. What happened? 1. What else might have been affected 2. What projects that are also in similar straights 3. What can be done to help these projects (is it inside our sphere of control or influence). 4. What is a list of things that need to change. ... N. Is moving off of these projects needed or possible? Currently most groups are between 0 and 1. There are a lot of things which need to be looked at before moving off can be looked at as a goal to make sure we aren't making things worse. I hope the above helps > For example from what I can read you were in contact with this Jia Tan > 'person' during this story. > > I hope that a Distro decision would support whatever it takes to give you > the tools, time and support to make sure that this sort of thing doesn't > sneak past you or anyone. > > If there's no way to make that kind of decision then it seems to me > Developers could use better support. > > This all seems like a very big deal. Which is why I guess I am reading > about it on The Economist. And why I'm hoping that the Distro has some > options to take some actions. > > Cheers! > > Arnie > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Thu, 4 Apr 2024 at 04:38, Vít Ondruch wrote: > > > Maybe you should give it second try. > > What I am going to say is not meant to be a bash in any way. I am on my 10th try for GNOME3/40. For everything they move to somewhere my brain says is intuitive, there always seems to be something else moved which I have to relearn or fight past patterns for. Just like code refactoring, I realize all the movements and changes are for good reasons versus just 'moving for movement sake'. My brain just rebels against it in an almost painful way. Again this isn't a rag on GNOME. I find that I can adapt only so much to desktop changes and prefer something which stays the same while I focus on my work. Other people find such changes easy and others find the lack of changes I want to be painful for their brains. I understand where GNOME is going and I agree that it is a purpose they should shoot for 100%. It just isn't easy for me to stay on the bus. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Wed, 3 Apr 2024 at 17:03, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Kevin Fenzi wrote: > > to you? They are quite relevent to others... > > I would really like to see what the proportion of users downloading the > Server, IoT, Cloud, and CoreOS Editions is compared to Workstation or the > Spins. I would not expect it to be very high. Most Fedora users are desktop Downloads are very hard to measure because too many things are grabbing everything from mirrors for different reasons. [Plus various people seem to think manipulating the stats for their particular spin on the number of downloads will make it more popular (I am looking at the several dozen ips which were downloading the same spin every ten minutes). The countme stats for 'running' systems https://data-analysis.fedoraproject.org/csv-reports/countme/ can probably give you the data on number of active systems. > > users. And server or cloud users will mostly install Fedora by picking > "Fedora" in a combo box at their commercial cloud, VPS, and/or dedicated > server provider's web interface, not from fedoraproject.org. I would be > surprised if the percentage of users both running a home server or a > private > cloud (as opposed to a hosted commercial offering in a remote datacenter) > AND picking Fedora as the OS to run on it (as opposed to a more > conservative > OS such as Rocky/Alma or Debian stable) were significant. CoreOS is also > mostly a server thing, desktop users get pointed to Atomic Desktop > variants > (Silverblue/Kinoite/"… Atomic") instead. And IoT is just completely niche. > So why do you expect those Editions to be more relevant to users > downloading > Fedora from fedoraproject.org than the Spins? > > Kevin Kofler > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: xz backdoor
On Tue, 2 Apr 2024 at 08:18, Lennart Poettering wrote: > On Di, 02.04.24 14:04, Petr Menšík (pemen...@redhat.com) wrote: > > > > Could be even smaller library libsystemd-notify linked from libsystemd, > > which would allow end applications to explicitly declare they need more > > limited set of functions? > > Why link? I'd really just suggest people to implement the trivial > client on their own. It's a trivial protocol for a reason: so that > people can implement it natively in their language and framwork > without bothering with our upstream libsystemd. > > I think because enough people have learned that anything which is listed as a 'trivial protocol' tends to get messed up if you don't really understand it. Many developers have also learned that if you mess up a 'trivial protocol' you tend to get blamed for being an idiot or worse so it is better to just find something which already implements it, is tested and known to work and move on with your day. I think the two combined with some other social reasons are why various modern languages (go, python, java, rust, etc) have grown giant ecosystems where packages focus on implementing a trivial thing and you are to include just that versus a library of other things. [Of course you then end up with 30 ways to implement the same trivial thing which pull in various other trivial things...] I am not saying this is good behaviour or what should be done, but it seems expected these days. > use libsystemd if you link against it anways and hack in C, or if you > really don't are about the extra dep for a single function, but > otherwise, why would you use the lib? > > It *literally* is just sending a text string "READY=1" in an AF_UNIX > datagram to a socket whose path is provided to you in the > $NOTIFY_SOCKET env var. Anyone with a moderate understanding of UNIX > APIs should be able to hack that up in a a few lines of code. It's a > protocol I can summarize and explain in *one* frickin' sentence. > > sshd upstream understood this btw: > > https://bugzilla.mindrot.org/show_bug.cgi?id=2641 > > Lennart > > -- > Lennart Poettering, Berlin > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Three steps we could take to make supply chain attacks a bit harder
On Mon, 1 Apr 2024 at 04:47, François Rigault wrote: > To echo > > > To trust code, it needs to be reviewed. > > If the code is reviewed, and the build system is sane, [..] > > I deduce from your response that the binary tests committed in systemd > were not reviewed neither by co-maintainers nor by downstream package > maintainers. > > Are we talking about the blobs which contained the malware? Those blobs were not in systemd, they were in the compression library. You are going to see weird blobs in any compression library because compression needs to test how it does against different data types.. especially binary data because you need to see if you improved or worsened the compression with a change. The places you are going to see binary data which may not make any 'sense' are: compression, anything graphics related, sound and general archiving tools. You will find actually 'binaries' in various parts of any compilation set because you may be linking or 'embedding' it into code that will run something else. But that is just where you are just sticking plain binary data. You can uuencode, base64 or many other things and put it into regular code in places where you might need to run some stuff. They went after ssh most likely because the main target was internet based attacks. However they could have gone a slightly different path and used dnf/apt (rpm/dpkg) as the target application and placed additional scripts to open systems up somewhere. This could be done with a nice bit of C code which usually does one thing but for what would look like legitimate reasons does something else after a certain date or code sequence. Anyone who has tried to read through an obfuscated C contest entry can see where this is going. > I understand that the build system used by systemd makes it much less > probable that some binary blob used in a test obfuscates something that > could be used for other purposes outside the test; still, wouldn't you > agree it would be a good practice to make sure everyone is able to review > everything in the source code repository? > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Three steps we could take to make supply chain attacks a bit harder
On Sat, 30 Mar 2024 at 15:29, Artem S. Tashkinov via devel < devel@lists.fedoraproject.org> wrote: > I'm not sure my proposal has been understood at all. > > Probably not.. proposals like this need to be thought about, reviewed and thought about. Some people who like to say NO to various things will of course voice their NO as soon as they see it. > Back to the topic. > > Then you have to painstakingly scour the web for distros already using > this package and check whether their have the same version with a hash. > Then you download the package and verify the hash and pray to God the > distro has at least given a cursory look to this package, so it's actually > safe to install. > > I guess I'm not coming from @fedora.org or @redhat.com, so my proposal is > "anti-freedom". > > No. You are taking one comment from a person who is known to yell at everyone and doesn't work for Red Hat as 'being an official comment'. Most everyone on this list does not speak for Fedora at all. This is the part of the proposal that I was trying to bring up earlier that needs work: 1. There is NO one who speaks for most distributions. There is a group of many people with many different opinions who speak for a part of a distribution. They work together as best they can, but they are all going to have differing opinions and any proposal has to understand that changing 400 people's minds (for the number of active devs in Fedora) takes time. 2. Red Hat sponsors Fedora but doesn't control what Fedora does. There are many developers who are paid by Red Hat but only work on Fedora in their spare time so Red Hat may 'influence' but can not command what they do. Debian and Arch are even further along the anarchy meter for who gets to decide what happens where. 3. Getting distros to work together is hard. People choose their distros like they choose their sports teams. When they see another distro doing something, their first reaction is to do the opposite. This is why it takes a long time to get changes done and it takes a lot of people time to make it happen. > Sorry for wasting your time. You have not even provided the very basic > counter-arguments why my proposal makes no sense. > > It isn't a waste of time, but I see this response with a lot of good proposals which get any criticism. You are going to get criticism, you are going to get people yelling about stupid things in any proposal you make. People don't change their minds quickly and there is a lot of meat-space circuitry to try and make sure it isn't easy. To get a proposal through, people need to be able to understand that most of the time the first thing they are going to get is NO. Some of it is because people have a lot going on in life and they need space and time to see something for what its worth. Other times they have seen a lot of empty proposals and are trying to see if the person making it is going to actually do something about it or not. > RedHat absolutely can start this initiative. You have all the means and > resources, and I'm not talking about something super complex or expensive. > For all I know, it could be the most basic website running on top of SQLite > which costing the company $50 a month to run. > > And of course, without this website, distros will continue to valiantly > include upstream packages and get royally screwed and screw their poor > users because a ton of your maintainers have neither the time/resources, > nor qualifications to check whether the code you happily push to users is > malware free. > > I guess we'll have to have a few more accidents like this before someone > will come up with a similar solution only not coming from me personally, > because I'm a no one and just rending the air. > > Sorry for intervening, > Artem > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Three steps we could take to make supply chain attacks a bit harder
On Sat, 30 Mar 2024 at 13:26, Artem S. Tashkinov via devel < devel@lists.fedoraproject.org> wrote: > > I propose this issue to be tackled in a centralized way by the > collaboration of major distros. > > There must be a website or a central authority which includes known to be > good/safe/verified/vetted open source packages along with e.g. > SHA256/384/512/whatever hashes of the source tarballs. In addition, the > source tarballs (not their compressed versions because people may use > different compressors and compression settings) and their hashes must be > digitally signed or have the appropriate PGP signatures from the trusted > parties. > > Some parties must be assigned trust to be able to push new packages to > this repository. Each push must be verified by at least two independent > parties, let's say RedHat and Ubuntu or Ubuntu and Arch, it doesn't matter. > The representatives of these parties must be people whose whereabouts are > known to confirm who they physically are. No nicknames allowed. > > This website must also have/allow a revocation mechanism for situations > like this. > > Now Fedora/Arch/Debian/Ubuntu/whatever distros can build packages knowing > they are safe to use. > > If that's the wrong place to come up with this proposal, please forward it > to the people who are responsible for making such decisions. I'm not > willing to dig through the dirt to understand how the Fedora project works, > who is responsible for what, and what are the appropriate communication > channels. If you care, you'll simply forward my message. Thanks a lot. > > There is no one who makes such decisions for any of the distros. Most of the distributions make decisions by consensus of hundreds of individuals who read a list and come to the conclusion that they are 'going to dig through the dirt' to make something happen or not. For changes like what you propose, you need groups of people to work for years to get all the agreements in place, get the various tooling adapted, and work out all the personalities involved. It will usually start with an email like this, and then various disagreements about how it will never work, and then some group of people to actually try to get something like it to work somewhere. At which point, the next round of 'well did you think about..' problems arrive and either the people are able to fix them or the idea gets shelved until later. > Best regards, > Artem > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: F41 Change Proposal: Change Compose Settings (system-wide)
On Wed, 20 Mar 2024 at 22:01, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Aoife Moloney wrote: > > The zstd compression type was chosen to match createrepo_c settings. > > As an alternative, we might want to choose xz, > > Since xz consistently compresses better than zstd, I would strongly > suggest > using xz everywhere to minimize download sizes. However: > > > especially after zlib-ng has been made the default in Fedora and brought > > performance improvements. > > zlib-ng is for gz, not xz, and gz is fast, but compresses extremely poorly > (which is mostly due to the format, so, while some implementations manage > to > do better than others at the expense of more compression time, there is a > limit to how well they can do and it is nowhere near xz or even zstd) and > should hence never be used at all. > > There are two parts to this which users will see as 'slowness'. Part one is downloading the data from a mirror. Part two is uncompressing the data. In work I have been a part of, we have found that while xz gave us much smaller files, the time to uncompress was so much larger that our download gains were lost. Using zstd gave larger downloads (maybe 10 to 20% bigger) but uncompressed much faster than xz. This is data dependent though so it would be good to see if someone could test to see if xz uncompression of the datafiles will be too slow. > Kevin Kofler > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: reprodubible builds (re)introduction
On Thu, 7 Mar 2024 at 18:38, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Mar 07, 2024 at 10:01:08PM +, Richard W.M. Jones wrote: > > On Thu, Mar 07, 2024 at 12:39:37PM +, Zbigniew Jędrzejewski-Szmek > wrote: > > > Nevertheless, for me, reproducibility is interesting because it aids > debugability, and "threats" are not an immediate concern. Essentially, > when the > builds are stable, any unexpected change in the build outputs is much > easier to > diagnose. We have already found and submitted a bunch of obvious fixes that > would not have been found otherwise. Also, when builds are stable, when > working > on the tools, it is easy to do a rebuild with the patched tools and > observe the > diff. If the build is "unstable", i.e. there are various other unrelated > changes, interesting differences often drown in noise. > > Now this is the part which is the real important part which gets overlooked a lot. As much as some people somehow make it out that reproducibility will make things secure.. it will only do so against a threat which isn't as existent as people injecting bad source code. [Supply chain attacks are already just including bad source code which will build reproducible but still be bad. It is much cheaper to make mostly useful but compromised code into pypi, cpan, some cargo place etc and getting other people to need to include it in a distro or just straight to a developer than it is to break into Fedora/Debian/etc and compromise a gcc ] The real fix is in Quality and catching things which silently make builds bad. A CPU problem, a memory problem, a builder kernel issue, etc are bigger problems and more likely to cause hard to fix bugs because they aren't bugs in the code. Of course this means that builds need to be built twice inside a build system to make sure that both builds match.. otherwise you can end up where someone rebuilding starts reporting problems with our build system but its because they used overclocked ram or cpu :) > E.g. today I ended up creating a pull request for intltool package [1], > backporting a patch to fix a race in cache creation which was corrupting > translations in files. The patch is from 2015, but seemingly nobody > noticed the > issue in Fedora so far. > > More examples are [2,3], one of the many examples of noarch packages using > arch-dependent macros, e.g. %_libdir, leading to packages that are > "noarch", > but actually depend on the build architecture, and misbehave when installed > on a system with a different architecture than the build machine. > > [1] https://src.fedoraproject.org/rpms/intltool/pull-request/2 > [2] https://src.fedoraproject.org/rpms/xbyak/pull-request/5 > [3] https://src.fedoraproject.org/rpms/python-virt-firmware/pull-request/3 > > Zbyszek > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Flock 2 Fedora 2024 Rochester New York USA
I expect that some sort of official announcement will go out with more details.. I just saw that a site had been announced and thought I probably missed the official ones but didn't see anything on devel On Wed, 28 Feb 2024 at 11:15, Michel Lind wrote: > Hi smooge, > > On Wed, Feb 28, 2024 at 08:36:19AM -0500, Stephen Smoogen wrote: > > I had not seen any announcements on this so wanted to drop it here > > https://flocktofedora.org > > > Thanks for posting this! Can we get it out to devel-announce too? > > Best regards, > > -- > Michel Lind (né Salim) > identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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
Flock 2 Fedora 2024 Rochester New York USA
I had not seen any announcements on this so wanted to drop it here https://flocktofedora.org the call for proposals has not opened up but there is the following is set: SCHEDULE 2024 EVENT DATES Flock will be held for four days from Wednesday, August 7th to Saturday, August 10th. You should plan to arrive by Tuesday, August 6th and to depart no sooner than Saturday evening, August 10th for the best experience. An optional social activity may be offered on Sunday, August 11th. VENUE AND HOTEL Flock to Fedora will be held in Rochester, New York, United States of America. The Hyatt Regency Rochester in Rochester, New York is both the conference venue as well as the conference hotel. A booking block is reserved at the hotel for Flock attendees and will be available soon. Check back soon for discounted rates for Flock attendees. Note: If you apply for and receive financial assistance to attend Flock, the organizers will book your travel arrangements (e.g. flight, hotel, train, bus, etc.) for you, depending on your sponsorship package. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: SPDX Statistics - Please Please Me edition
On Tue, 27 Feb 2024 at 09:44, Richard Hughes wrote: > On Mon, 26 Feb 2024 at 15:44, Stephen Smoogen wrote: > > I wonder if you have it from a group you are in or if it was the general > creep of time that has added you to a lot of packages? > > I'm a packager and a provenpackager, so I'm a bit confused why I'm on > so many packages as a separate committer. I've been at Red Hat for a > lng time, so it might be various things being imported from cvs > for example. I also see alexl is in the same boat as me. > > Is there any automated way to drop these? e.g. a git repo with ACLs > that I could send a patch for? > > I think it is all stored in the pagure database and would need to be removed with either direct database commands or something similar. This might be better to ask in a releng ticket so they can give direct answers. > Richard. > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: SPDX Statistics - Please Please Me edition
On Mon, 26 Feb 2024 at 09:54, Richard Hughes wrote: > On Fri, 16 Feb 2024 at 15:07, Miroslav Suchý wrote: > > * 23711 spec files in Fedora > > I was looking through the list for any of my packages, and I've found > that I'm "maintaining" long dead packages like > https://src.fedoraproject.org/rpms/GConf2 > > According to that I have "commit" ACLs, but I couldn't find any way to > relinquish those using the web UI. I suppose I could contact the "main > admin" of the package, but I don't think that would scale as I've also > got "commit" on ~250 other packages. > > If the SPDX listing isn't using src.fedoraproject.org and instead > using something like bugzilla please yell. Being listed as maintaining > all those also makes the packager-dashboard basically useless for me > too. :) > I wonder if you have it from a group you are in or if it was the general creep of time that has added you to a lot of packages? -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Fri, 23 Feb 2024 at 08:04, Sérgio Basto wrote: > On Thu, 2024-02-22 at 20:36 -0500, Neal Gompa wrote: > > On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto > > > No. This is one of those many myths about the "Unix FHS". And it > > doesn't even matter much these days anyway, since most newer > > administrative tools don't install in sbin anyway. > > > > name it one , I'm not aware. > > Fedora old school (or just me I don't know ) don't use sudo , sudo is a > bad idea that came from Ubuntu and turn computer much more insecure , > sudo has been part of the Red Hat/Fedora family since Red Hat Linux 7.0 https://archive.download.redhat.com/pub/redhat/linux/7.0/en/os/i386/RedHat/RPMS/ (2000-09) and had been in powertools since at least 5.2 https://archive.download.redhat.com/pub/redhat/linux/5.2/en/powertools/i386/ (1998-11). Both of those dates vastly predate Ubuntu. While they had been part of Debian before that they were included in Powertools in 5 due to requests for it being used on Unix systems which were being replaced with Red Hat Linux. [sudo was already a preferred tool in various university and corporate environments because it did allow for all kinds of policy decisions which were easily updated versus the standard at that time to make a chroot wrapper and control via group permissions. Many times these wrappers were the most insecure thing on a system. ] > since if a regular user is compromised the access to all computer is > much more easier . > https://xkcd.com/1200/ > And PATH at root user have sbin and PATH of regular user should not > have /sbin/ > > but checking we got this pearl in /etc/profile > > > if [ "$EUID" = "0" ]; then > pathmunge /usr/sbin > pathmunge /usr/local/sbin > else > pathmunge /usr/local/sbin after > pathmunge /usr/sbin after > fi > > There have been holy wars over /usr/sbin:/sbin:/usr/local/bin for as long as I have been a systems administrator in the 1980's. Different schools of thought have their world view of when/who/how people should have access to it and it would be even split into which Unix you used because of what was needed to act per system. In the end, this choice tends to be deeply personal where each person assumes the world should follow their model and then get increasingly angry that is not the case. I have seen it create complete forks of an operating system due to needing to compile in such paths in various tools. > > -- > Sérgio M. B. > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: mock: ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer
On Wed, 21 Feb 2024 at 12:38, Jun Aruga (he / him) wrote: > On Wed, Feb 21, 2024 at 6:09 PM Stephen Smoogen > wrote: > > > > > > > > On Wed, 21 Feb 2024 at 12:05, Miroslav Suchý wrote: > >> > >> Dne 21. 02. 24 v 17:38 Jun Aruga (he / him) napsal(a): > >> > >> $ mock -r fedora-rawhide-x86_64 --shell > >> > >> > >> > >> --setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off /usr/bin/dnf-3 > >> --disableplugin=versionlock install @buildsys-build > >> > >> This is suspicious. It should use DNF5 now. > >> > >> What is > >> > >> rpm -qf /etc/mock/fedora-rawhide-x86_64.cfg > >> > >> Since mock-core-configs-40.2-1 it should use DNF5. > >> > >> That said, DNF3 should work too. But instead of hunting this bug it may > be easier to update configs and use DNF5 that should be used anyway. > > > > > > Usually when I see errors like this.. it is usually a mixed up rawhide > cache stored somewhere.. aka something is pulling in something really old. > `mock --clean fedora-rawhide-x86_64` usually fixes these but it may also > need a local update first too. > > Thanks for your help. I still see the same error after running the > `mock --clean fedora-rawhide-x86_64`. > > ``` > $ mock --clean fedora-rawhide-x86_64 > > $ mock -r fedora-rawhide-x86_64 --shell > ... > ERROR: Command failed: > # /usr/bin/systemd-nspawn -q -M 46d4e94c6647468aa33584d8fb7d42ae -D > /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root -a > --capability=cap_ipc_lock > --bind=/tmp/mock-resolv.0la37cbp:/etc/resolv.conf --console=pipe > --setenv=TERM=vt100 --setenv=SHELL=/bin/bash > --setenv=HOME=/var/lib/mock/fedora-rawhide-x86_64/root/installation-homedir > --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin > '--setenv=PROMPT_COMMAND=printf "\033]0;\007"' > '--setenv=PS1= \s-\v\$ ' --setenv=LANG=C.UTF-8 > --setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off /usr/bin/dnf-3 > --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever > 35 --setopt=deltarpm=False --setopt=allow_vendor_change=yes > --allowerasing --disableplugin=local --disableplugin=spacewalk > --disableplugin=versionlock install @buildsys-build > --setopt=tsflags=nocontexts > Traceback (most recent call last): > File "/usr/bin/dnf-3", line 61, in > from dnf.cli import main > File "/usr/lib/python3.12/site-packages/dnf/__init__.py", line 30, in > > import dnf.base > File "/usr/lib/python3.12/site-packages/dnf/base.py", line 29, in > > import libdnf.transaction > File "/usr/lib64/python3.12/site-packages/libdnf/__init__.py", line > 14, in > from . import conf > File "/usr/lib64/python3.12/site-packages/libdnf/conf.py", line 10, > in > from . import _conf > ImportError: /lib64/libdnf.so.2: undefined symbol: > g_once_init_enter_pointer > ``` > > Ok what I Have on my system f39 toolbox is: ⬢[root@toolbox ~]# rpm -qa | grep -E 'dnf|mock|distribution-gpg|glib2' | sort distribution-gpg-keys-1.101-1.fc39.noarch dnf-4.18.2-1.fc39.noarch dnf-data-4.18.2-1.fc39.noarch dnf-plugins-core-4.4.4-1.fc39.noarch dnf-utils-4.4.4-1.fc39.noarch dnf5-5.1.12-1.fc39.x86_64 dnf5-plugins-5.1.12-1.fc39.x86_64 glib2-2.78.3-1.fc39.x86_64 libdnf-0.72.0-1.fc39.x86_64 libdnf5-5.1.12-1.fc39.x86_64 libdnf5-cli-5.1.12-1.fc39.x86_64 mock-5.5-1.fc39.noarch mock-core-configs-40.1-1.fc39.noarch mock-filesystem-5.5-1.fc39.noarch python3-dnf-4.18.2-1.fc39.noarch python3-dnf-plugins-core-4.4.4-1.fc39.noarch python3-libdnf-0.72.0-1.fc39.x86_64 I built a package against rawhide which worked.. and the dnf_cache for mock says it was using ./fedora-2d95c80a1fa0a67d/packages/glib2-2.79.1-1.fc40.x86_64.rpm ./fedora-2d95c80a1fa0a67d/packages/dnf-4.19.0-1.fc40.noarch.rpm ./fedora-2d95c80a1fa0a67d/packages/python3-dnf-4.19.0-1.fc40.noarch.rpm ./fedora-2d95c80a1fa0a67d/packages/dnf-data-4.19.0-1.fc40.noarch.rpm ./fedora-2d95c80a1fa0a67d/packages/python3-libdnf-0.73.0-1.fc40.x86_64.rpm ./fedora-2d95c80a1fa0a67d/packages/libdnf-0.73.0-1.fc40.x86_64.rpm [ -- > Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic > See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for > the timezone. > -- > ___ > 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.fedoraprojec
Re: mock: ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer
On Wed, 21 Feb 2024 at 12:05, Miroslav Suchý wrote: > Dne 21. 02. 24 v 17:38 Jun Aruga (he / him) napsal(a): > > $ mock -r fedora-rawhide-x86_64 --shell > > > > --setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off /usr/bin/dnf-3 > --disableplugin=versionlock install @buildsys-build > > This is suspicious. It should use DNF5 now. > > What is > > rpm -qf /etc/mock/fedora-rawhide-x86_64.cfg > > Since mock-core-configs-40.2-1 it should use DNF5. > > That said, DNF3 should work too. But instead of hunting this bug it may be > easier to update configs and use DNF5 that should be used anyway. > > Usually when I see errors like this.. it is usually a mixed up rawhide cache stored somewhere.. aka something is pulling in something really old. `mock --clean fedora-rawhide-x86_64` usually fixes these but it may also need a local update first too. > -- > Miroslav Suchy, RHCA > Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys > > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Feedback wanted - pruning old rawhide chroots in Copr
On Mon, 19 Feb 2024 at 10:08, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Stephen Smoogen wrote: > > 1. Drive size is not just what is needed but also throughput. The large > > drives needed to store the data COPR uses for its hundreds of chroots are > > much 'slower' on reads and writes even when adding in layers of RAID 1+0. > > Faster drives are possible but the price goes up considerably. > > 2. Throughput of individual drives also requires backplane speeds which > > match peek throughput of all the drives. Otherwise you end up with lots > of > > weird stalling (as seen on certain builders which have such drives). > > What kind of throughput is needed for a repository that has not seen any > new > builds for 2 years? Such a repository is going get only a handful > downloads > and no uploads. Instead of deleting old repositories, they can be moved to > a > low-throughput archive storage. This can be made transparent through > symlinks, union file systems, or even just at the HTTPS level if Copr > itself > knows how to unarchive a repository when internally needed (e.g., if a new > build is submitted after 2 years of inactivity). > > The throughput is actually in several places even for low/no usage repositories. 1. RAID rebuilds will need to go through and check data. RAID-1 might seem like a no-brainer but you tend to end up with 'which of these two disks is the correct bit' over time problems. 2. web-spiders and such regularly peruse pretty much every package regularly. Putting some repositories on slow disks and some on fast tend to cause web front ends to pause out for unrelated tasks unless you set up your caching and other middleware to deal with it. [This I know from when I tried to make something more 'efficient' on downloads.fedoraproject.org and from some other tooling.] It becomes a complete project of setting up the infrastructure to best handle mixed loads. If you have a limited staff then it may be too much work. That said, the above does sound like an interesting project to add to copr. I do not know how much work it would take or who would be able to do it these days. [My understanding is that COPR is 'one of many things' that the various developers work on with most of the work done as a volunteer task.] Kevin Kofler > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Feedback wanted - pruning old rawhide chroots in Copr
On Mon, 19 Feb 2024 at 08:59, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Miroslav Suchý wrote: > > What **you** would find as acceptable policy for pruning rawhide chroots? > > As I mentioned several times, I already find the existing policy for > pruning > EOL release chroots unacceptable (because deleting data must never be the > default – notifications can be and are still lost in spam filters, I still > do not ever get any notification from Copr! – and because the UI to extend > the lifetime follows dark patterns, requiring us to click separately for > every single chroot instead of having an "Extend all" button). > > Instead of coming up with new aggressive pruning schemes, Copr really > needs > to come up with a reasonable amount of storage to satisfy user demands. > HDDs > in the multi-TB-range are available for fairly low budgets (extremely low > by > the standards of a company like IBM), and it just takes 2 of them to build > a > RAID 1 that is safe against data loss. Of course, that means that Copr > needs > to stop locking itself into third-party cloud providers that charge > ridiculously high prices for storage. > Kevin, I agree with your general concerns but have problems with your analysis of costs. 1. Drive size is not just what is needed but also throughput. The large drives needed to store the data COPR uses for its hundreds of chroots are much 'slower' on reads and writes even when adding in layers of RAID 1+0. Faster drives are possible but the price goes up considerably. 2. Throughput of individual drives also requires backplane speeds which match peek throughput of all the drives. Otherwise you end up with lots of weird stalling (as seen on certain builders which have such drives). 3. Outside of that you need to have a fast network switch speed of 10G minimum and 40G to 100G to deal with the multiple builders and the storage server. The larger the storage, the more bandwidth needed all the way through as building software eats lots of space. 4. The builders need to be housed in a datacenter which charges for a. power b. cooling c. square footage used d. staff to deal with problems. e. racks and wiring and parts Going from the costs 5 years ago, it took using storage systems from 45drives and systems elsewhere.. The capital costs for COPR was around 350k. The operating expenses were around 80k per year. At the time, chroots and other things needed to be cleaned much more regularly than now. We would probably need to double or triple those costs to meet what we have now. [budgets like what was given then only came around 1/10 years or so.] The amazon systems cost Fedora $0.00 as long as it stays within 'modest' disk space and other resources. That said, I realize there will be a day when you can clearly said "I told you this would happen" when being locked in comes back to bite. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Does splint work for anyone?
On Fri, 16 Feb 2024 at 10:51, David Cantrell wrote: > On 2/15/24 11:19, Stephen Smoogen wrote: > > > > > > On Thu, 15 Feb 2024 at 10:15, David Cantrell > <mailto:dcantr...@redhat.com>> wrote: > > > > On 2/14/24 13:32, Stephen Smoogen wrote: > > > > > > > > > On Fri, 9 Feb 2024 at 17:17, Ian Laurie > <mailto:nixu...@mail.com> > > > <mailto:nixu...@mail.com <mailto:nixu...@mail.com>>> wrote: > > > > > > On 2/10/24 05:06, Stephen Smoogen wrote: > > > > > > > > I was trying out the splint program on some code and found > > that it > > > > doesn't seem to work on any recent release due to changes > > in various > > > > header files > > > I tried using splint many years ago in connection with > embedded > > > programming, and even though the GCC based embedded compiler > > I was using > > > was several major version numbers behind what was natively in > > Fedora, I > > > found splint to be hopelessly behind the times and utterly > > unusable. I > > > don't know why it is even packaged in Fedora. > > > > > > I wish I had the skills necessary to bring it up to date but > > I don't. > > > > > > > > > Me too. I saw it is FTBFS in F40 and added my data > > > to https://bugzilla.redhat.com/show_bug.cgi?id=2261709 > > <https://bugzilla.redhat.com/show_bug.cgi?id=2261709> > > > <https://bugzilla.redhat.com/show_bug.cgi?id=2261709 > > <https://bugzilla.redhat.com/show_bug.cgi?id=2261709>> > > > > I got it building and posted a PR: > > https://src.fedoraproject.org/rpms/splint/pull-request/1 > > <https://src.fedoraproject.org/rpms/splint/pull-request/1> > > > > The upstream project went dormant in 2010, but there are some other > > semi-active forks. I don't think that really matters. The program > > itself could be useful for research and just as another tool in the > > toolbox for development. > > > > > > Does it "work?" however. > > ``` > > [ssmoogen@toolbox phytool (fix_asprintf)]$ splint +posixlib phytool.c > > Splint 3.1.2 --- 22 Jul 2023 > > > > /usr/include/asm-generic/int-ll64.h:20:24: Parse Error: > > Suspect missing struct or union keyword: __signed__ : > > int. (For help on parse errors, see splint -help parseerrors.) > > *** Cannot continue. > > ``` > > > > Trying different flags, just got it to find even more 'parseerrors' on > > more and more layers of header files. I could not find any combination > > of flags which didn't result in the program not working with how our > > headers are done in post Fedora 38 (my oldest system). > > It depends on what you mean by "work". It's definitely clear there is a > lot of syntax it does not understand. > > It was mainly that I couldn't get it to 'parse' various simple C code without bombing out over standard headers it couldn't parse. I was mainly asking in case you had a standard flag set which made it work and I had missed the obvious. > There is at least one fork I found on github that has continued work on > splint, but its most recent commit is from 3 years ago and it has open > issues like "support C99 syntax". > > Yeah I could not get the one I found to compile (but it was even older) so not sure where things stood in forks either. > splint's days may be over. > > I will pour one compile out for it. > -- > David Cantrell > Red Hat, Inc. | Boston, MA | EST5EDT > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Does splint work for anyone?
On Thu, 15 Feb 2024 at 10:15, David Cantrell wrote: > On 2/14/24 13:32, Stephen Smoogen wrote: > > > > > > On Fri, 9 Feb 2024 at 17:17, Ian Laurie > <mailto:nixu...@mail.com>> wrote: > > > > On 2/10/24 05:06, Stephen Smoogen wrote: > > > > > > I was trying out the splint program on some code and found that it > > > doesn't seem to work on any recent release due to changes in > various > > > header files > > I tried using splint many years ago in connection with embedded > > programming, and even though the GCC based embedded compiler I was > using > > was several major version numbers behind what was natively in > Fedora, I > > found splint to be hopelessly behind the times and utterly > unusable. I > > don't know why it is even packaged in Fedora. > > > > I wish I had the skills necessary to bring it up to date but I don't. > > > > > > Me too. I saw it is FTBFS in F40 and added my data > > to https://bugzilla.redhat.com/show_bug.cgi?id=2261709 > > <https://bugzilla.redhat.com/show_bug.cgi?id=2261709> > > I got it building and posted a PR: > https://src.fedoraproject.org/rpms/splint/pull-request/1 > > The upstream project went dormant in 2010, but there are some other > semi-active forks. I don't think that really matters. The program > itself could be useful for research and just as another tool in the > toolbox for development. > > Does it "work?" however. ``` [ssmoogen@toolbox phytool (fix_asprintf)]$ splint +posixlib phytool.c Splint 3.1.2 --- 22 Jul 2023 /usr/include/asm-generic/int-ll64.h:20:24: Parse Error: Suspect missing struct or union keyword: __signed__ : int. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. ``` Trying different flags, just got it to find even more 'parseerrors' on more and more layers of header files. I could not find any combination of flags which didn't result in the program not working with how our headers are done in post Fedora 38 (my oldest system). > -- > David Cantrell > Red Hat, Inc. | Boston, MA | EST5EDT > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Does splint work for anyone?
On Fri, 9 Feb 2024 at 17:17, Ian Laurie wrote: > On 2/10/24 05:06, Stephen Smoogen wrote: > > > > I was trying out the splint program on some code and found that it > > doesn't seem to work on any recent release due to changes in various > > header files > I tried using splint many years ago in connection with embedded > programming, and even though the GCC based embedded compiler I was using > was several major version numbers behind what was natively in Fedora, I > found splint to be hopelessly behind the times and utterly unusable. I > don't know why it is even packaged in Fedora. > > I wish I had the skills necessary to bring it up to date but I don't. > > Me too. I saw it is FTBFS in F40 and added my data to https://bugzilla.redhat.com/show_bug.cgi?id=2261709 > -- > Ian Laurie > FAS: nixuser | IRC: nixuser > TZ: Australia/Sydney > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: FYI: removal of bastion server in DNSBL spam.dnsbl.anonmails.de requested
On Mon, 12 Feb 2024 at 06:12, Marius Schwarz wrote: > Hi, > > as die Infrastructure ML did not react ( or could not react ;) ), I > requested the removal at that antispam blacklist. > > I did not see any email to the infrastructure list about this so I am wondering if your email (and other emails) have gotten trashed? Did you open a ticket on this at https://pagure.io/fedora-infrastructure/ already? There is another email issue that was listed there earlier today but I don't know if they are related. > 2024-02-11 05:20:16 H=bastion-iad01.fedoraproject.org > (bastion.fedoraproject.org) [38.145.60.11] > X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=no > F= rejected RCPT > : found in spam.dnsbl.anonmails.de > > I hope it gets removed soon. > > best regards, > Marius Schwarz > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: x86-64 -mtls-dialect=gnu2 change needs to be postponed
On Sun, 11 Feb 2024 at 09:35, Florian Weimer wrote: > We've hit an ABI ambiguity/bug: > > gcc: -mtls-dialect=gnu2 produces wrong code on x86-64 > <https://bugzilla.redhat.com/show_bug.cgi?id=2263739> > > Was this set for the Fedora 40 mass rebuild or something that was put in later? If it was put into the mass rebuild, what problems would it cause currently? > Apart from that, support in the GNU toolchain seems to be quite good. > In particular, GDB handled the situation in the polymake crash quite > well (reporting TLS data as uninitialized for the thread before the > critical call, and producing the correct address for the variable > afterwards). > > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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
Does splint work for anyone?
I was trying out the splint program on some code and found that it doesn't seem to work on any recent release due to changes in various header files ``` [ssmoogen@toolbox phytool (fix_asprintf)]$ splint +posixlib phytool.c Splint 3.1.2 --- 22 Jul 2023 /usr/include/asm-generic/int-ll64.h:20:24: Parse Error: Suspect missing struct or union keyword: __signed__ : int. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. ``` I haven't figured out a set of flags to get past this to make the tool work. I looked upstream and the site has a 'we are no longer working on this tool'. So I am not sure if the software 'works', 'how to fix the software', or 'did I miss something obvious and everyone else knows this one trick'. Thanks for any help. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: cloud-init switching to udhcpc
On Wed, 7 Feb 2024 at 09:25, Major Hayden wrote: > On 2/7/24 07:36, Petr Menšík wrote: > > I am interested why two DHCP clients are required inside a single tool. > > Why it could not use NetworkManager in both times, but with some > > different settings? Maybe alternative service? If there is missing > > ability to change behaviour, it may make sense to fix just that. Instead > > of keeping another client maintained. Do we support any kind of images, > > which would not have Network Manager present? > > One of the design goals of cloud-init is to use the dhcp client to get > just enough networking done so the cloud instance can get to the cloud's > metadata service. That metadata service provides information about > network configuration, users, ssh keys, initial scripts, and more. > > cloud-init isn't used just for cloud systems. I have seen it used for similar reasons in enterprise locations where the configs are centrally located and Network-Manager's late start either sets up things which need to be replaced again post-install or might be 'blocked' without the info. > If NetworkManager is used for this step, then the network would need to > be fully reconfigured when cloud-init finishes. It's my understanding > that they block the boot until the network configuration is fully > completed (using data from the metadata service) and then NetworkManager > is allowed to continue. > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Figure out what killed an app (rhbz#2253099)
On Wed, 31 Jan 2024 at 12:00, Michael Catanzaro wrote: > On Wed, Jan 31 2024 at 04:42:08 PM +01:00:00, Clemens Lang > wrote: > > Throwing some ideas out there, is it possible that evolution runs > > with a seccomp filter or other BPF program configured to kill the > > process on violation, and that’s what’s happening here? > > I don't think so. flatpak does use seccomp filters [1], but on > violations the syscalls should just fail with EPERM or ENOSYS, not kill > the process. > > Could the problem with evolution be really with something else and getting masked out ? I saw there was another thread about bogofilter killing evolution due to the database needing to change from berkeley to sqllite by running a helper. If the helper is being run but it runs out of memory, would that cause the whole chain of OOM ? > [1] > > https://github.com/flatpak/flatpak/blob/d5f891e0035e50b24211688a7fa5f61924a2e51c/common/flatpak-run.c#L1791 > > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Lost KDC for FEDORAPROJECT.ORG realm
On Tue, 23 Jan 2024 at 10:09, Steve Dickson wrote: > Hello, > > I had to change my /etc/krb5.conf do to > some realm changes... and now when I > to a kinit to FEDORAPROJECT.ORG it > hangs for a while then errors with > > Currently the Fedora Project KRB is down and being worked on. Please see https://status.fedoraproject.org/ and related tickets for more information. There is currently no ETA on when this will be fixed but people have been working on it all night. > kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while > getting initial credentials > > My question is, what has to be in the /etc/krb5.conf > for the FEDORAPROJECT.ORG realm to be found? > > In the past I didn't think there was anything in > the file and assume the realm was found by the > > includedir /etc/krb5.conf.d/ > includedir /var/lib/sss/pubconf/krb5.include.d/ > > Any ideas? > > tia! > > steved. > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: ARM PAC on koji vs COPR
On Wed, 3 Jan 2024 at 15:01, Miroslav Suchý wrote: > Dne 03. 01. 24 v 14:46 Jarek Prokop napsal(a): > > 4. Why do koji and copr have CPU flag set that differs so much? Is our > koji infra OK? > > For convenience of readers: > > Koji: > Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp > cpuid asimdrdm lrcpc dcpop asimddp ssbs > > Copr: > Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid > asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit > uscat ilrcpc flagm ssbs paca pacg dcpodp svei8mm svebf16 i8mm bf16 dgh rng > > In Copr we use c7g.xlarge type from AWS as ARM builders. So if you spawn this > machine in AWS you should be able to reproduce. > > My information may be old, but I believe the Fedora systems will be mostly virtual machines running on Ampere systems from 2-3 years ago. I think there are a couple of other systems which may be in usage also. The AWS systems are a newer generation and different chipset. Another issue is that ARM like Intel systems may be of the same generation but have different flags. > Side note - hopefully in next release Copr will have functionality that will > allow you to SSH to host with the failed build > https://github.com/fedora-copr/copr/pull/2977 But that will take few weeks. :( > > -- > Miroslav Suchy, RHCA > Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys > > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
On Tue, 2 Jan 2024 at 10:24, Vít Ondruch wrote:
>
> Dne 02. 01. 24 v 13:42 Stephen Smoogen napsal(a):
>
>
>
> On Tue, 2 Jan 2024 at 06:21, Vít Ondruch wrote:
>
>>
>> Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
>>
>> The dynamic linker already has the `glibc-hwcaps` mechanism to load
>> optimized implementations of ''shared objects'' [3]. This means that
>> packages can provide optimized libraries and they linker will be
>> automatically load them from separate directories if appropriate.
>> (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
>>
>>
>>
>> Is this something specific to x86_64 that the libs needs to be nested in
>> a place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use
>> e.g. `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more
>> universal.
>>
>>
> Adding directories to the /usr sub-space generally gets bogged down into
> 'You are polluting my name-space' arguments which get no-where because some
> of the people getting angry is having to live with some 3rd party rules and
> regulations which stipulated how things look and will only get updated once
> a decade or so. [The same goes with subdirectories in /usr/bin etc where it
> causes similar problems.] There tends to be no 'general' case which works
> unless it gets 'agreed' upon by some outside of the distro body that
> publishes 'versioned' standards.
>
>
> Checking what Debian does, they have paths such as
> `/usr/lib/x86_64-linux-gnu/`. So we would not be alone.
>
Do they have /usr/bin/{arch} directories also? I thought they did the
/usr/lib/{arch-os-type}/ for libraries to deal with multiarch (aka x86_32,
x86_64, etc) libs . the main item will be if we are following
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s04.html or if there
is enough variation in
https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html
to allow subdirectories in /usr/bin.
It would seem that in the freedesktop version /usr/lib/{arch-id} is
acceptable and I think in the FHS-3.0, then /usr/lib{qualifier} is ok.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
On Tue, 2 Jan 2024 at 06:21, Vít Ondruch wrote:
>
> Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
>
> The dynamic linker already has the `glibc-hwcaps` mechanism to load
> optimized implementations of ''shared objects'' [3]. This means that
> packages can provide optimized libraries and they linker will be
> automatically load them from separate directories if appropriate.
> (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
>
>
>
> Is this something specific to x86_64 that the libs needs to be nested in a
> place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g.
> `/usr/x86-64-v{2,3,4}/lib`
> directories instead? Or something more universal.
>
>
Adding directories to the /usr sub-space generally gets bogged down into
'You are polluting my name-space' arguments which get no-where because some
of the people getting angry is having to live with some 3rd party rules and
regulations which stipulated how things look and will only get updated once
a decade or so. [The same goes with subdirectories in /usr/bin etc where it
causes similar problems.] There tends to be no 'general' case which works
unless it gets 'agreed' upon by some outside of the distro body that
publishes 'versioned' standards.
> Vít
> --
> ___
> 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
>
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
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: rpmbuild core dumps
On Thu, 28 Dec 2023 at 17:24, Sam Varshavchik wrote:
> Stephen Smoogen writes:
>
> > I am trying to figure out the logic of this section:
> >
> >
> > ```
> >
> > static char * lastUname = NULL; // So lastUname is NULL
> > static uid_t lastUid;
> >
> > if (!thisUname) {
> > lastUname = rfree(lastUname); // lastUname should still be NULL
> and
> > we are freeing NULL and setting itself back to NULL.
> > return -1;
> >
> > ```
> >
> >
> >
> > I expect this is where I am not understanding something basic in C from
> too
> > many years in non-pointer land. I looked at the change of these lines
> and
> > they date back to this commit.
>
> This is a fairly common kind of simple caching to avoid expensive
> username/userid and groupname/groupid lookups by caching the last one.
> This
Yeah I completely forgot that static allows for caching so I was misreading
this as 'always set to NULL at the beginning.'
>
> https://github.com/rpm-software-management/rpm/issues/2826
>
>
>
And thanks for opening a bug. I will watch to see what happens.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
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: rpmbuild core dumps
On Tue, 26 Dec 2023 at 07:32, Sam Varshavchik wrote:
> Stephen Smoogen writes:
>
> >
> > I am guessing the problem is really with the free(lastUname) since the
> rfree
>
> Yes. Multiple execution threads will reach lastUname and try to free the
> same pointer. glibc rightfully complains about the double-free.
>
>
I am trying to figure out the logic of this section:
```
static char * lastUname = NULL; // So lastUname is NULL
static uid_t lastUid;
if (!thisUname) {
lastUname = rfree(lastUname); // lastUname should still be NULL and
we are freeing NULL and setting itself back to NULL.
return -1;
```
I expect this is where I am not understanding something basic in C from too
many years in non-pointer land. I looked at the change of these lines and
they date back to this commit.
fe645f822d (Panu Matilainen 2023-05-04 11:59:36 +0300 136) lastUname =
rfree(lastUname);
commit fe645f822dbd71da4145f6174e526a09eb5c815e
Author: Panu Matilainen
Date: Thu May 4 11:59:36 2023 +0300
Simplify rpmug caching
The simple cache whose efficiency troubled ewt back in 1997
(see commit 97999ce92c1cad3315d85c02bb3c62007a75d846)
has proven more than adequate over the years.
In a local testcase based on Fedora 33 server iso contents, an install
of 1765 packages consisting of 201344 files did a whopping 27 user +
groups combined. So a few more alloc+free is not going to make the
damnest difference, don't bother with reallocing the cache buffer, just
strdup() a new one when needed.
And the code before that was gnarlier from days of yore.
> > isn't referred to (but not sure if an optimization would have removed
> it. The
> > comment before this code mentions that this is a hack to try and get
> things
> > done.. probably from long long ago when rpm was single threaded.
>
> The problem is in all of these functions. It's the same problem with all
> of
> them. Here's rpmugUname(), for example. You have two execution threads
> traversing that nest of "if" statements and all of them winding up here:
>
> } else {
> char *uname = NULL;
>
> if (lookup_str(pwfile(), uid, 2, 0, ))
> return NULL;
>
> lastUid = uid;
> free(lastUname);
>
> And now both execution threads will try to free() the same pointer.
>
> The next statement resets lastUname to the newly-allocated uname, but
> it's
> too late. If the code that executes in parallel calls rpmugUname, then
> just
> say good night.
>
> All of the static variables in all of the functions here must have a
> mutex
> wrapped around them.
>
> Or declared with a __thread attribute.
>
> The window of vulnerability is very tiny. But I have 32 cores and have 32
> execution threads churning. They have about a 5% chance of hitting the
> double-free on every build. Worse, I can see how this race condition may
> not
> result in a crash but produce a corrupted rpm.
>
>
That is ugly. The only mention of mutexes I found
lib/package.c
rpmio/macro.c
rpmio/rpmlog.c
The entries for __thread I found come in around 2019. Did you have a
bugzilla or a report on https://github.com/rpm-software-management/rpm/
which I can add anything I find?
and most date back from 2013.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
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: rpmbuild core dumps
On Mon, 25 Dec 2023 at 11:07, Stephen Smoogen wrote:
>
>
> On Sun, 24 Dec 2023 at 15:51, Sam Varshavchik
> wrote:
>
>> Stephen Smoogen writes:
>>
>> > »My apologies for bad quoting.. email from phone. What version of rpm
>> build
>> > is used and what are some packages which are rebuilt that show this
>> issue.
>> > This may be needed if the core dump is due to something else in the
>> > environment like memory limits etc
>>
>> It's 4.19.1 on FC39, and it's packages that I'm working on. It's glibc
>> complaining about a double-free, and not any resource limits. I can get
>> a
>> backtrace out of it:
>>
>> #1 0x7f05dd8588ee raise (libc.so.6 + 0x3e8ee)
>> #2 0x7f05dd8408ff abort (libc.so.6 + 0x268ff)
>> #3 0x7f05dd8417d0 __libc_message.cold (libc.so.6 +
>> 0x277d0)
>> #4 0x7f05dd8b47a5 malloc_printerr (libc.so.6 +
>> 0x9a7a5)
>> #5 0x7f05dd8b6a3a _int_free (libc.so.6 + 0x9ca3a)
>> #6 0x7f05dd8b93de free (libc.so.6 + 0x9f3de)
>> #7 0x7f05dda984ec rpmugUid (librpm.so.10 + 0x584ec)
>> #8 0x7f05dda84255 rpmfilesStat (librpm.so.10 +
>> 0x44255)
>> #9 0x7f05dda8438f rpmfiStat (librpm.so.10 + 0x4438f)
>> #10 0x7f05dda8 rpmfiArchiveWriteHeader
>> (librpm.so.10 + 0x4)
>> #11 0x7f05dda871c9 iterWriteArchiveNext (librpm.so.10
>> + 0x471c9)
>>
>> I am looking at this core dump. I see 32 active execution threads at the
>> time this whole thing went kaput, and all the code in rpmug.c is
>> definitely
>> not thread safe. I did not look very hard, I don't know if there are
>> mutexes
>> higher up the call chain, but the overall behavior – occasional core
>> dumps
>> -- is indicative of thread races.
>>
>>
> Thanks. I was wondering if it was dnf/rpm on the system or dnf/rpm in the
> chroot but it sounds like something changed between 4.19.0.1 (what I had on
> my system since September?) and 4.19.1 ( December)
>
> The changelog doesn't say much beyond
> * Tue Dec 12 2023 Michal Domonkos - 4.19.1-1
> - Update to 4.19.1 (https://rpm.org/wiki/Releases/4.19.1)
>
> I forget if there is a way to pin an rpm in a mock environment so that you
> don't update over 4.19.0 to see if you can see if
> a) the problem still happens with that (possibly indicating that whatever
> is calling into rpm is broken) or b) the problem doesn't occur and it is a
> change between .0.1 and .19.1
>
>
https://github.com/rpm-software-management/rpm/compare/rpm-4.19.0-release...rpm-4.19.1-release
```
void * rfree (void *ptr)
{
free(ptr);
return NULL;
}
/**
* Test for string equality
* @param s1string 1
* @param s2string 2
* @return 0 if strings differ, 1 if equal
*/
static inline int rstreq(const char *s1, const char *s2)
{
return (strcmp(s1, s2) == 0);
}
int rpmugUid(const char * thisUname, uid_t * uid) {
static char * lastUname = NULL;
static uid_t lastUid;
if (!thisUname) {
lastUname = rfree(lastUname);
return -1;
} else if (rstreq(thisUname, UID_0_USER)) {
*uid = 0;
return 0;
}
if (lastUname == NULL || !rstreq(thisUname, lastUname)) {
long id;
if (lookup_num(pwfile(), thisUname, 0, 2, ))
return -1;
free(lastUname);
lastUname = xstrdup(thisUname);
lastUid = id;
}
*uid = lastUid;
return 0;
}
```
I am guessing the problem is really with the free(lastUname) since the
rfree isn't referred to (but not sure if an optimization would have removed
it. The comment before this code mentions that this is a hack to try and
get things done.. probably from long long ago when rpm was single threaded.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
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: rpmbuild core dumps
On Sun, 24 Dec 2023 at 15:51, Sam Varshavchik wrote: > Stephen Smoogen writes: > > > »My apologies for bad quoting.. email from phone. What version of rpm > build > > is used and what are some packages which are rebuilt that show this > issue. > > This may be needed if the core dump is due to something else in the > > environment like memory limits etc > > It's 4.19.1 on FC39, and it's packages that I'm working on. It's glibc > complaining about a double-free, and not any resource limits. I can get a > backtrace out of it: > > #1 0x7f05dd8588ee raise (libc.so.6 + 0x3e8ee) > #2 0x7f05dd8408ff abort (libc.so.6 + 0x268ff) > #3 0x7f05dd8417d0 __libc_message.cold (libc.so.6 + > 0x277d0) > #4 0x7f05dd8b47a5 malloc_printerr (libc.so.6 + > 0x9a7a5) > #5 0x7f05dd8b6a3a _int_free (libc.so.6 + 0x9ca3a) > #6 0x7f05dd8b93de free (libc.so.6 + 0x9f3de) > #7 0x7f05dda984ec rpmugUid (librpm.so.10 + 0x584ec) > #8 0x7f05dda84255 rpmfilesStat (librpm.so.10 + > 0x44255) > #9 0x7f05dda8438f rpmfiStat (librpm.so.10 + 0x4438f) > #10 0x7f05dda8 rpmfiArchiveWriteHeader > (librpm.so.10 + 0x4) > #11 0x7f05dda871c9 iterWriteArchiveNext (librpm.so.10 > + 0x471c9) > > I am looking at this core dump. I see 32 active execution threads at the > time this whole thing went kaput, and all the code in rpmug.c is > definitely > not thread safe. I did not look very hard, I don't know if there are > mutexes > higher up the call chain, but the overall behavior – occasional core > dumps > -- is indicative of thread races. > > Thanks. I was wondering if it was dnf/rpm on the system or dnf/rpm in the chroot but it sounds like something changed between 4.19.0.1 (what I had on my system since September?) and 4.19.1 ( December) The changelog doesn't say much beyond * Tue Dec 12 2023 Michal Domonkos - 4.19.1-1 - Update to 4.19.1 (https://rpm.org/wiki/Releases/4.19.1) I forget if there is a way to pin an rpm in a mock environment so that you don't update over 4.19.0 to see if you can see if a) the problem still happens with that (possibly indicating that whatever is calling into rpm is broken) or b) the problem doesn't occur and it is a change between .0.1 and .19.1 > > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: rpmbuild core dumps
My apologies for bad quoting.. email from phone. What version of rpm build is used and what are some packages which are rebuilt that show this issue. This may be needed if the core dump is due to something else in the environment like memory limits etc Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren On Sun, Dec 24, 2023 at 14:27 Sam Varshavchik wrote: > It seems that rpmbuild dumps core at the end of the build process, every > once in a while. Typical: > > Wrote: > /__w/courier-libs/courier-libs/courier-authlib/rpm/RPMS/x86_64/courier-authlib-userdb-debuginfo-0.72.0.20231223-101.fc39.x86_64.rpm > Wrote: > /__w/courier-libs/courier-libs/courier-authlib/rpm/RPMS/x86_64/courier-authlib-devel-0.72.0.20231223-101.fc39.x86_64.rpm > double free or corruption (fasttop) > make[1]: *** [Makefile:2447: dorpm] Aborted (core dumped) > make[1]: Leaving directory '/__w/courier-libs/courier-libs/courier-authlib' > make: *** [Makefile:2439: rpm-build] Error 2 > > Just trying again, with the same build, typically succeeds. In my > estimate > it dumps core about 5% of the time, randomly. > > I can rule out a hardware issue on my side, because this just happened in > a > github workflow container: > > > https://github.com/svarshavchik/courier-libs/actions/runs/7315972215/job/19930137170 > > You'll probably need to be signed into github see the log, but that's > basically it. > > I can't find anything relevant in Bugzilla, is anyone else seeing this, > too? > > -- > ___ > 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 > -- ___ 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: goal: booting with an empty /etc
file in > > /etc needs to handle the "read in the default; then read in the optional > > local overrides" model. I know a lot of stuff already does this, but > > some things don't. It would be a nice goal to aim for and maybe we can > > submit patches to upstream projects where the functionality is missing. > > > > Indeed. > > > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Change of cronie and crontabs CIS compliance
On Wed, 6 Dec 2023 at 06:49, Ondrej Pohorelsky wrote: > > > On Wed, Dec 6, 2023 at 12:39 PM Fabio Valentini > wrote: > >> On Wed, Dec 6, 2023 at 11:17 AM Ondrej Pohorelsky >> wrote: >> > >> > Hi everyone, >> > >> > For F40 I would like to change file permissions of few files that are >> provided by cronie and crontabs and swap deny list for allow list. I'm not >> really sure if I should make a change proposal. I figured I'll send an >> email first and see the feedback. >> > >> > The driving force of this change is feedback from RHEL customers, that >> they would like to have cronie and crontabs CIS compliant out of the box. >> Which means changing some of the file permissions and swapping `cron.deny` >> for `cron.allow`. As it stands now, they have to run their own scripts or >> dnf plugin (post-transaction-actions) to ensure that each update doesn't >> overwrite the file permissions they manually set. >> >> Just out of curiosity - what does CIS even stand for? >> The linked Red Hat docs don't expand the acronym, and googling for it >> obviously yields results for something entirely different >> > > Basically, it is a Center for Internet Security (CIS) benchmark that some > companies use as a reference to limit configuration-based security > vulnerabilities. > I'm not really sure, but I think some governments require that their > systems are compliant. > > This standard is used in various Universities, local governments, hospitals, financial organizations, and can be required in some cases for PCI compliance (if your acreditor likes that kind of thing). Basically it is one of the major standards like the US DOD STIG https://en.wikipedia.org/wiki/Security_Technical_Implementation_Guide / https://ncp.nist.gov/repository Like any standard, there are things which are good and some which are 'that is a choice you could make, but...' > You can look at CIS wikipedia page for more info: > > https://en.wikipedia.org/wiki/Center_for_Internet_Security#CIS_Controls_and_CIS_Benchmarks > > -- > > Ondřej Pohořelský > > Software Engineer > > Red Hat <https://www.redhat.com> > > opoho...@redhat.com > <https://www.redhat.com> > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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
[EPEL-devel] Re: Network rules to use mock on RHEL8
On Sun, 3 Dec 2023 at 14:46, Emmanuel Seyman wrote: > > Hello, all. > > Wanting to promote RPM packages, I'm trying to use mock on an RHEL8 VM > that does not have unrestricted access to the internet. This fails > miserably, as you would expect it to. > > I've already established that I need access to: > * registry.access.redhat.com on port 443 > * cdn.redhat.com on port 443 > > Is there anything else I need to ask? Opening ports on internal VMs is a > lengthy process and I would really appreciate any help here. > > Regards, > Emmanuel > Depending on the network rules and other resources, it may be easier to do the following: 1. Make changes or additional specific template changes to use specific servers which will limit failover (aka dl.fedoraproject.org for epel and fedora packages) 2. Mirror the distro and other resources you need inside of the network. (optional) -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: https://releases.pagure.org/ is down
On Wed, 22 Nov 2023 at 17:05, Tomasz Kłoczko wrote: > Hi, > > Is it possible to do something about this?樂 > > There was a major cable cut to the ISP which houses pagure. This caused the main line to go down, and only IPv6 on a secondary network was available. [IPv4 was working for some people via the secondary network but not everyone.] The problem was causing issues with various infrastructure, so is probably the reason for this email > kloczek > -- > Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>* > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Missing notifications
It could be due to the retirement of the old notifications system earlier this month. See the email "intent to retire: fedmsg-irc, old fmn, osbs" sent to the mailing list earlier. FMN is the tool which sends notifications and it was replaced with a newer version earlier this year. Here is the April announcement: ``` The FMN replacement team has finished writing the new version of our notification system, and we are ready to deploy! We plan on deploying the new version on https://notifications.fedoraproject.org this week, we'll keep the old one around but move it to https://apps.fedoraproject.org/notifications-old, and redirect from https://apps.fedoraproject.org/notifications to the new place, notifications.fedoraproject.org. You will thus still be able to access the current FMN, and it will keep running until F39. Due to the difference in features, we can't import existing rules into the new system, so we encourage you to create new rules that suit you as soon as the new system is up and running. The change of URLs will happen with the planned outage set for 2023-04-24 08:30 UTC (this Wednesday), see ticket 11266 <https://pagure.io/fedora-infrastructure/issue/11266> for details. If you have issues with the new FMN, please open infra tickets at: https://pagure.io/fedora-infrastructure/new_issue We hope you will enjoy the simpler UI and faster processing speed that the new FMN brings. ``` On Sun, 19 Nov 2023 at 14:45, Christiano Anderson wrote: > Hi, > > Same issue here. I noticed that I'm not getting regular notifications, > even from BZ. > > Thanks > > On Sunday, 19 November 2023 at 20:19, Mikel Olasagasti < > mi...@olasagasti.info> wrote: > > > > Hi, > > > > I'm not receiving mails from some updates like koschei build status or > > src.f.o commits. > > > > Has something changed in this regard or is it the mail service having > > issues again? > > > > Kind regards, > > Mikel > > -- > > ___ > > 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 > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Summary/Minutes from today's FESCo Meeting (2023-11-09)
On Thu, 16 Nov 2023 at 07:46, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > This is called "shooting the messenger". > > It is not. See my reply to Fabio. > > > LSB requires various obsolete interfaces, in particular it requires > > Python 2 to be available as /usr/bin/python. Comment [1] contains a > > nice listing. We are not going to bring back Python 2 or old PERL > > modules to satisfy LSB. > > That is exactly the attitude I am complaining about! > > It would be very much possible to support the Python 2 parts of the spec, > without even shipping unmaintained software: Package Tauthon 2.8.4, and > make > both /usr/bin/python and /usr/bin/python2 symlinks to /usr/bin/tauthon. > That 1. It is not clear that would actually be 'valid' for being LSB compliant. The LSB was written to be very specific in the 'actual' software used. Substitutes would need approval by the now defunct LSB committee. 2. The packages in Fedora are put in there by individuals who are interested in maintaining them. The only things I know of stopping you or a group of individuals from packing up tauthon or the other 'dead' software is just the sheer size of the work required. However, that is just the easy stuff. The perl changes also require similar locked older versions of perl and module trees so every perl script would also need to now be changed to refer to specific versions (one being the perl5 approved by LSB and the other not). In the end, the real work needed is getting LSB 'going' again. The last version was over 10 years old and based on what the state of the 'OS' was in 2012 (it takes time to standardize so even with the last version being from 2015, it is going to aim at what is generally available in 2012). It needs a 'reboot' which either meets what is the state of things are in say 2019 or newer. Or interested people can make an OS which will stick to LSB-5.0 forever. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: argyllcms orphaned
On Thu, 19 Oct 2023 at 06:02, Andreas Schneider wrote: > On Thursday, 19 October 2023 10:20:52 CEST Richard Hughes wrote: > > Hi all, > > Hi, > > > I've orphaned argyllcms -- I'm no longer using the package, and > > haven't worked on color management for some time. If anyone wants to > > take on the package the upstream source is chucked over the wall (no > > source control) every few months, and it sometimes needs patches to > > fix the Linux support. Ohh and it uses jam as the build system > > upstream, which in honesty is going to be easier to rewrite with > > automake or meson before building. I'm happy to give advice to the new > > maintainer. Apologies, > > we don't have displaycal in the distribution anymore? :-( > > https://github.com/eoyilmaz/displaycal-py3 > > > This required it, it sounds like nobody uses Fedora for color work > anymore. > That would be sad. > > Very few people were doing it before. Color work is a 'niche' field in any distribution so unless people are paying for it, it is probably going to come and go as people get interested in it, work on it for a while, and then go do something else. That is the sadness of life. > Best regards > > > Andreas > > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Help running centpkg
On Mon, 9 Oct 2023 at 09:37, Florian Weimer wrote:
> * Stephen Smoogen:
>
> > could you add how you got it and how you ran it? I am trying to figure
> > out why a el8 config was pulled into a f38 system?
>
> This does it for me:
>
> $ mock -r c8s-x86_64 --init
>
>
OK my first problem was I misparsed your first email in thinking you were
build f38 and somehow pulling in c8s
> Even after:
>
> $ mock -r c8s-x86_64 --scrub all
>
>
So my system was out of date and I started with mock 5.0
INFO: calling preinit hooks
INFO: Using bootstrap image: fedora:latest
INFO: Pulling image: fedora:latest
INFO: Copy content of container fedora:latest to
/var/lib/mock/c8s-build-repo_356879-bootstrap/root
INFO: mounting fedora:latest with podman image mount
INFO: image fedora:latest as
/var/lib/containers/storage/overlay/f29face791dfb00155b668c68409ac8022a17e31230363148ee8145fd7cda6ab/merged
INFO: umounting image fedora:latest
(/var/lib/containers/storage/overlay/f29face791dfb00155b668c68409ac8022a17e31230363148ee8145fd7cda6ab/merged)
with podman image umount
INFO: Package manager dnf detected and used (fallback)
INFO: Bootstrap image not marked ready
Start(bootstrap): installing dnf tooling
I then went to 5.2 which gave the same issue but then went to the same
error everyone is seeing. The above errors were similar which I think made
me a possible realize the problem if both of you set up your configs the
same way.. you are mixing and matching koji which are using different
setups. The CentOS Stream Koji is set up to default to an older version of
mock while the Fedora one usually uses a newer option. In this case, the
config you are getting from the CentOS Stream Koji assumes that
bootstrapping is done one way, and the newer mock defaults to a different
way. The config to compare yours to is in
`/etc/mock/templates/centos-stream-8.tpl`
I did a bootstrap again with `mock -r centos-stream+epel-8-x86_64 --init`
which worked. Looking in the /etc/mock/templates file I see the additional
sets:
config_opts['chroot_setup_cmd'] = 'install tar gcc-c++ redhat-rpm-config
redhat-release which xz sed make bzip2 gzip gcc coreutils u
nzip diffutils cpio bash gawk rpm-build info patch util-linux findutils
grep'
config_opts['dist'] = 'el8' # only useful for --resultdir variable subst
config_opts['releasever'] = '8'
config_opts['package_manager'] = 'dnf'
config_opts['extra_chroot_dirs'] = [ '/run/lock', ]
config_opts['bootstrap_image'] = 'quay.io/centos/centos:stream8'
config_opts['dnf_vars'] = { 'stream': '8-stream',
'contentdir': 'centos',
}
so I think the bootstrap image needs to be added to make things work.. I
have attached a config where I combined the two together to work. [You will
need to put the number of teh buildroot you want to use versus latest to
match the original config]
> Package versions:
>
> mock-core-configs-39.1-1.fc38.noarch
> mock-filesystem-5.2-1.fc38.noarch
> mock-5.2-1.fc38.noarch
>
> > I have cut everything but lines causing the problems
> >
> >
> > config_opts['root'] = 'c8s-x86_64'
> > config_opts['yum.conf'] = '
> >
> [main]\ncachedir=/var/cache/yum\ndebuglevel=1\nlogfile=/var/log/yum.log\nreposdir=/dev/null\nretries=20\nobsoletes=1\ngpgcheck=0\nassumeyes=1\nkeepcache=1\ninstall_weak_deps=0\nstrict=1\n\n#
> > repos\n\n
> > [build]\nname=build\nbaseurl=
> https://kojihub.stream.centos.org/kojifiles/repos/c8s-build/latest/x86_64\nmodule_hotfixes=1\n
> '
> >
> > config_opts['macros']['%dist'] =
> '%{!?distprefix0:%{?distprefix}}%{expand:%{lua:for i=0,
> > do print("%{?distprefix" .. i .."}")
> end}}.el8%{?with_bootstrap:%{__bootstrap}}'
> >
> > This looks like a config from either the CentOS Stream koji or for
> > EPEL-next-8.
>
> It's generated with this command and lightly edited (to keep refering to
> the latest buildroot):
>
> $ koji -p stream mock-config --target c8s-candidate --arch x86_64
>
> Thanks,
> Florian
>
>
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
c8s-x86_64.cfg
Description: Binary data
___
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: Help running centpkg
On Mon, 9 Oct 2023 at 04:56, Florian Weimer wrote:
> * Michael Dawson:
>
> > I'm trying to build https://gitlab.com/redhat/centos-stream/rpms/nodejs
> using centpkg but am running into errors.
> >
> > I'm using Fedora 37 and get this error when I run centpkg mockbuild
> --with=bundled in the directory where I've cloned the
> https://gitlab.com/redhat/centos-stream/rpms/nodejs respository and
> switched to the stream-nodejs-18-rhel-8.10.0 branch.
> >
> > I'm getting this error:
> >
> > Total
> 3.7 MB/s | 50 MB
> 00:13
> > Running transaction check
> > Transaction check succeeded.
> > Running transaction test
> > Error: Transaction test error:
> > file /usr/sbin/alternatives from install of
> chkconfig-1.19.2-1.el8.x86_64 conflicts with file from package
> alternatives-1.24-1.fc38.x86_64
>
> I get a similar error when using a custom configuration generated by
> various EL Koji instances, only for EL8. The error occurs after this
> one:
>
>
could you add how you got it and how you ran it? I am trying to figure out
why a el8 config was pulled into a f38 system?
I have cut everything but lines causing the problems
> config_opts['root'] = 'c8s-x86_64'
> config_opts['yum.conf'] =
> '[main]\ncachedir=/var/cache/yum\ndebuglevel=1\nlogfile=/var/log/yum.log\nreposdir=/dev/null\nretries=20\nobsoletes=1\ngpgcheck=0\nassumeyes=1\nkeepcache=1\ninstall_weak_deps=0\nstrict=1\n\n#
> repos\n\n[build]\nname=build\nbaseurl=
> https://kojihub.stream.centos.org/kojifiles/repos/c8s-build/latest/x86_64\nmodule_hotfixes=1\n
> '
> config_opts['macros']['%dist'] =
> '%{!?distprefix0:%{?distprefix}}%{expand:%{lua:for i=0, do
> print("%{?distprefix" .. i .."}")
> end}}.el8%{?with_bootstrap:%{__bootstrap}}'
>
>
This looks like a config from either the CentOS Stream koji or for
EPEL-next-8. None of the others I know of should have any combination of
the above.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: ELN build order (was: Re: OCaml 5.1 rebuild)
On Fri, 6 Oct 2023 at 15:45, Richard W.M. Jones wrote: > On Fri, Oct 06, 2023 at 11:16:17AM -0400, Stephen Gallagher wrote: > > So, as we all know, build ordering is hard (and, despite intuitive > > belief, not actually deterministic). > > > > ELN actually "cheats" somewhat when we do our builds. When we process > > a batch of builds (triggered by a set of tag events that come in all > > at the same time, such as when a side-tag is merged), we create a new > > ELN side-tag, tag all of the new *Rawhide* builds into this side tag, > > then trigger a rebuild of all of those builds for ELN. The result here > > is that we use the Fedora build in the buildroot to avoid > > bootstrapping issues. Now, there are some special-case packages for > > which we do *NOT* automatically tag in the Fedora builds because they > > have known incompatibilities. All OCAML packages fall into this > > category, since we discovered about 9 months ago that we absolutely > > cannot mix Fedora's OCAML builds with ELN's (I don't recall the exact > > reason). > > It's probably because the build flags are different and > (unnecessarily) OCaml encodes the build flags into the hashes of one > of the base modules. I forget the exact details but there's an email > on this list about it somewhere. Anyway the upshot is that if the > build flags change at all, as they obviously do in Fedora vs RHEL, > then the hashes change. We ought to fix this upstream ... > > Anyway I was going to say why not order the packages by their original > build date in Koji? > Mass rebuilds and multiple developers can make this much harder than expected. The history looks linear, but it may be that the bootstrap blew up and had to be restarted OR it does need to do a double loop. Or developer A rebuilt something when it wasn't needed while B was doing something in a side tag at the same time. Or you find that rust or go needed to have old/new mixes which weren't needed last time because ordering didn't matter that time but does now (this can be due to flags or package differences.) Many of these things are things which the regular package maintainers know to do with their pets, but other people do not. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Help running centpkg
On Sat, 7 Oct 2023 at 10:50, stan via devel wrote: > On Fri, 06 Oct 2023 16:05:25 - > "Michael Dawson" wrote: > > > I'm trying to build > > https://gitlab.com/redhat/centos-stream/rpms/nodejs using centpkg but > > am running into errors. > > > > I'm using Fedora 37 and get this error when I run centpkg mockbuild > > --with=bundled in the directory where I've cloned the > > https://gitlab.com/redhat/centos-stream/rpms/nodejs respository and > > switched to the stream-nodejs-18-rhel-8.10.0 branch. > > > > I'm getting this error: > > > > Total > >3.7 MB/s | 50 MB > >00:13 Running transaction check Transaction check succeeded. > > Running transaction test > > Error: Transaction test error: > > file /usr/sbin/alternatives from install of > > chkconfig-1.19.2-1.el8.x86_64 conflicts with file from package > > alternatives-1.24-1.fc38.x86_64 > > > Good catch. You should not mix and match el and fedora packages or repositories like that. Michael if you are using Fedora 37 as you say lower down, you have 3 different releases trying to put packages on the system: EL8, Fedora 37 and Fedora 38. You can possibly match Fedora 37 and Fedora 38, but EL8 is like bringing in EL29 packages into the mix.. years of changing file locations and such. I generally use toolbox these days for this sort of development: 1. Install the Linux you want to use daily. Get it the way you want it for that day driving work. 2. `dnf install toolbox` 3. some variation of `toolbox create --image quay.io/toolbx-images/centos-toolbox centos-stream-9` 4. `toolbox enter centos-stream-9` 5. Do the package installs of centpkg 6. Do the builds > This sounds like a package conflict error. Two packages are trying to > manage the same file. I find no bugzillas for chkconfig or > alternatives. I infer from that that packages within the same fedora > version don't have this conflict. Thus, I suggest that you use an f38 > instance, so that this package conflict doesn't occur. No guarantees, > though, maybe no one else has hit this error. If it still doesn't work, > you should open a bugzilla against one of the packages with the > information you have provided in this email. > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: ELN build order (was: Re: OCaml 5.1 rebuild)
On Fri, 6 Oct 2023 at 07:38, Richard W.M. Jones wrote: > > On Fri, Oct 06, 2023 at 12:23:09PM +0100, Richard W.M. Jones wrote: > > On Fri, Oct 06, 2023 at 10:19:22AM +0100, Richard W.M. Jones wrote: > > > On Fri, Oct 06, 2023 at 08:48:52AM +0100, Richard W.M. Jones wrote: > > > > On Thu, Oct 05, 2023 at 10:03:59AM +0100, Richard W.M. Jones wrote: > > > > > Over the next few days I'm going to rebuild all OCaml packages in > > > > > Rawhide for OCaml 5.1, plus some non-OCaml packages that have OCaml > > > > > bindings. > > > > > > > > > > OCaml 5.1 is basically a small point release, but it does add back > > > > > native code support for riscv64 and s390x. The only remaining > > > > > architecture that hasn't been updated for OCaml 5 (and is therefore > > > > > still using the bytecode interpreter) is ppc64le. > > > > > > > > I think the builds are complete, except one which is running now. > > > > > > > > Only swig failed to build but that appears to be a general FTBFS bug: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2242372 > > > > > > > > I'll submit an update later today once I've done a few more checks. > > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-f0270d1637 > > > > ELN builds are failing because they need to be done in build order, > > not in random or alphabetical order or whatever ELN uses, so that's a > > thing ... > > Actually it's worse. Because this build of ocaml: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=107128822 > > was built before ocaml-srpm-macros was updated, it is being built > wrongly. The s390x build.log contains "--disable-native-compiler" but > it should be the opposite since native compilation is now supported. > > Now partly this is a mistake in the spec file which should BR > ocaml-srpm-macros >= 9 (I'll fix that shortly), but partly this is > caused by the wrong build ordering of ELN. > If they are using the standard mass rebuild method, it is just feeding everything in alphabetical order, but it may still get 'reordered' somewhat by koji. I believe the main problem is that no one has ever hacked any sort of 'build recipe' to koji for it to 'know' that things need specific build orders or bootstrap instructions. Instead that has been left to the 'maintainers' of the packages because in general most of them required a lot of specific knowledge of the code to do right (or various maintainers do not want ANYONE ELSE to touch their package.) [Recipes got pulled into modularity but you also got all the rest of modularity also which was not what many maintainers wanted either] -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: time is running: security issue BZ#2241470
On Sat, 30 Sept 2023 at 05:13, Marius Schwarz wrote: > > Hi, > > this is emerg ping for the security team, to take a look at this bz : > > https://bugzilla.redhat.com/show_bug.cgi?id=2241470 > > excuse me, for bringing this to the list, as a security bz is the way to > go, but time is running fast and the patched release needs to be build > and shipped in 36h hours from now. > > The deadline for having a fix shipped is the afternoon of SUN, 1. of Oct > 2023 . On this date, the patches in upstream go public and exploits > will be developed for them. this impacts ALL of redhat based > installations which run as servers and are publically reachable. The > component in question is the default package for rh based installations. > > best regards, > Marius Schwarz > > So does anyone know which of this weeks major security problems this was about? Since it is supposedly past the release date, I figure it is ok to ask. If it isn't due to some other delay.. my apologies. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Specify koji build machine mem req via. spec file
On Wed, 4 Oct 2023 at 09:48, Cristian Le via devel < devel@lists.fedoraproject.org> wrote: > Thank you Stephen, > > Didn't know we can have such control over koji scheduling. Is there any > documentation on koji side or fedora packaging guidelines about this? E.g. > what are the physical limits that can be queued, how to request specific > number of CPUs for mpi packages etc.? Which macro sets take this into > account? I believe %ctest ones do that, but I've found an MPI related > situation where I need to override this. > > Uhm sorry, I am communicating poorly today it would seem. The packager does not have any control on the number of CPUs, the amount of memory, amount of disk space, etc. Those are set by infrastructure in how builders are installed as virtual machines. Infrastructure in turn has to deal with hard limits of how much disk space, cpu, memory are in the systems infrastructure have which is further hard limited by the amount of rack space, power, and budgets that they get handed to them. Most of these are hard choices made by releng infrastructure on how to best divy up the resources to deal with lots of small builds and regular large builds. What a packager can control is how the package is configured and what options are given to subparts of the 'build' inside of the RPM: config options, make options, and debug size options. A packager could choose to use fewer CPUs by configuring their build to use 1 CPU (make -j1 ) or possibly less memory, but it would need to be options set in whatever equivalent to Makefiles etc that are there. I hope that better explains things.. if it doesn't... I ask anyone else to better explain things. Also are the options equivalent in copr as well? > On 2023/10/04 15:32, Stephen Smoogen wrote: > > > > On Wed, 4 Oct 2023 at 09:24, Cristian Le via devel < > devel@lists.fedoraproject.org> wrote: > >> Hi Stephen, >> >> Could you also share the links for where the strategies for large builds >> is, I am also curious about this? Is it within koji or another framework? >> > > Sorry I meant the email Kalev Lember sent out > > # Require 32 GB of RAM per CPU core for debuginfo processing > %global _find_debuginfo_opts %limit_build -m 32768 > > ... and see if it helps. With this, it should pass -j1 to find-debuginfo > when the builder has 32 GB RAM, -j2 when it has 64 GB etc. > > Other strategies are to limit the number of parallel parts of a build (aka > make or cmake flags) happening at the same time > > Outside of that it is mainly up to a package and what it uses. The problem > is that there are limited resources (number of builders, amount of memory > per builder, amount of cpu) and as a packager you have to manage that > > >> On 2023/10/04 14:41, Stephen Smoogen wrote: >> >> >> >> On Wed, 4 Oct 2023 at 05:44, Martin Stransky wrote: >> >>> Hello guys, >>> >>> Is there's a way how to set requested amount of ram for koji builders? >>> >>> >> No, the builders are mainly virtual machines on a set of hardware with a >> set amount of memory per virtual machine. There are some 'real' hardware >> servers but it is mainly a round robin to get them. As noted elsewhere >> there are other strategies to use with large builds. >> >> > > -- > Stephen Smoogen, Red Hat Automotive > Let us be kind to one another, for most of us are fighting a hard battle. > -- Ian MacClaren > > ___ > 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 > > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To
Re: Specify koji build machine mem req via. spec file
On Wed, 4 Oct 2023 at 09:24, Cristian Le via devel < devel@lists.fedoraproject.org> wrote: > Hi Stephen, > > Could you also share the links for where the strategies for large builds > is, I am also curious about this? Is it within koji or another framework? > Sorry I meant the email Kalev Lember sent out # Require 32 GB of RAM per CPU core for debuginfo processing %global _find_debuginfo_opts %limit_build -m 32768 ... and see if it helps. With this, it should pass -j1 to find-debuginfo when the builder has 32 GB RAM, -j2 when it has 64 GB etc. Other strategies are to limit the number of parallel parts of a build (aka make or cmake flags) happening at the same time Outside of that it is mainly up to a package and what it uses. The problem is that there are limited resources (number of builders, amount of memory per builder, amount of cpu) and as a packager you have to manage that > On 2023/10/04 14:41, Stephen Smoogen wrote: > > > > On Wed, 4 Oct 2023 at 05:44, Martin Stransky wrote: > >> Hello guys, >> >> Is there's a way how to set requested amount of ram for koji builders? >> >> > No, the builders are mainly virtual machines on a set of hardware with a > set amount of memory per virtual machine. There are some 'real' hardware > servers but it is mainly a round robin to get them. As noted elsewhere > there are other strategies to use with large builds. > > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Specify koji build machine mem req via. spec file
On Wed, 4 Oct 2023 at 05:44, Martin Stransky wrote: > Hello guys, > > Is there's a way how to set requested amount of ram for koji builders? > > No, the builders are mainly virtual machines on a set of hardware with a set amount of memory per virtual machine. There are some 'real' hardware servers but it is mainly a round robin to get them. As noted elsewhere there are other strategies to use with large builds. > I'd like to use it as Firefox builds fail recently due low memory, like > https://bugzilla.redhat.com/show_bug.cgi?id=2241690 > > Thanks, > Martin > > -- > Martin Stransky > Software Engineer / Red Hat, Inc > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Packaging guidelines - validation of AppStream metadata files
On Thu, 28 Sept 2023 at 08:03, Richard Hughes wrote: > On Wed, 27 Sept 2023 at 22:41, Kevin Fenzi wrote: > > I'm not sure at all that it would be possible to do at compose-time... > > composes are taking around 3.5-4hours and thats after I have done > > a lot to speed them up, but might be worth some benchmarking > > to see how much slower it would be. If we are going to go that route, we > > should see if support could be added to pungi. > > On server class hardware with fast disk access it's an additional 10 > minutes or so. > > Assume a virtual machine on a possibly busy server, with limited IO to a shared netapp server. I don't expect it will do more than double that estimate but the bigger question will be how often will it 'fail' on the Fedora repositories and what kind of failure. Most failures I remember on any architecture will kill the entire compose which then requires Kevin to mangle whatever broke, and relaunch a compose (which again will take 4 hours) > > Moving this from a package to in repodata would grow the repodata quite > > a lot right? > > 6.9Mfedora-39-icons.tar.gz > 6.3Mfedora-39.xml.gz > > So not small, but cough, passim, cough :) > > Richard. > ___ > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Package fails to build for aarch64, works for x86_64
On Thu, 21 Sept 2023 at 10:24, Ron Olson wrote: > Hey all- > > I was trying to submit the released version of Swift 5.9 to Fedora but I > get a build failure only for the aarch64 platform for Rawhide and F39: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=2291751 (F39) > https://koji.fedoraproject.org/koji/buildinfo?buildID=2291750 > (Rawhide/F40) > > While it compiled for both fine on F38: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=2291752 > > What is the rule/advice around a situation like this insofar as should I > release it for the current platforms (F38,F37,EPEL9) and try to figure out > what’s going on with the aarch64 build, or should it be an all-or-nothing, > release to every platform or none at all? I’d personally lean towards > trying to provide the new shiny where possible, but I can see making a case > for holding off due to F39 coming down the road. Complicating all this is > trying to gauge interest in there being an aarch64 version of Swift for > Fedora. > > In general it is never a good idea to have newer versions of a release in older Fedora releases than in newer releases. I would release for EPEL9 and try to work with other developers on why it is failing on F39/F40 . They both seem to fail for the same reasons swift::irgen::LinkEntity, llvm::Function *, llvm::DenseMapInfo, llvm::detail::DenseMapPair>::moveFromOldBuckets(BucketT *, BucketT *) [DerivedT = llvm::DenseMap, KeyT = swift::irgen::LinkEntity, ValueT = llvm::Function *, KeyInfoT = llvm::DenseMapInfo, BucketT = llvm::detail::DenseMapPair]: Assertion `!FoundVal && "Key already in new map?"' failed. Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace. Stack dump: 0. Program arguments: /builddir/build/BUILD/swift-source/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend ... 1. Swift version 5.9 (swift-5.9-RELEASE) 2. Compiling with the current language version 3. While evaluating request IRGenRequest(IR Generation for module _StringProcessing) 4. While emitting metadata for 'OpCode' (at /builddir/build/BUILD/swift-source/swift-experimental-string-processing/Sources/_StringProcessing/Engine/Instruction.swift:25:3) #0 0x06227940 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/builddir/build/BUILD/swift-source/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend+0x6227940) #1 0x062259b8 llvm::sys::RunSignalHandlers() (/builddir/build/BUILD/swift-source/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend+0x62259b8) #2 0x06227d58 SignalHandler(int) Signals.cpp:0:0 #3 0x9bba87f0 (linux-vdso.so.1+0x7f0) #4 0x9aeff038 __pthread_kill_implementation (/lib64/libc.so.6+0x8f038) #5 0x9aeb5680 gsignal (/lib64/libc.so.6+0x45680) #6 0x9aea0284 abort (/lib64/libc.so.6+0x30284) #7 0x9aeae46c __assert_fail_base (/lib64/libc.so.6+0x3e46c) #8 0x9aeae4e0 __assert_perror_fail (/lib64/libc.so.6+0x3e4e0) #9 0x00a52368 llvm::DenseMapBase, llvm::detail::DenseMapPair>, swift::irgen::LinkEntity, llvm::Function*, llvm::DenseMapInfo, llvm::detail::DenseMapPair>::moveFromOldBuckets(llvm::detail::DenseMapPair*, llvm::detail::DenseMapPair*) DLangDemangle.cpp:0:0 ... :0: error: unable to execute command: Aborted :0: error: compile command failed due to signal 6 (use -v to see invocation) > > The funny thing is that Apple has already started providing development > versions of Swift 5.10 and it does, in fact, build on both x86_64 and > aarch64. > > Ron > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: The new Change discussion process is painful
On Wed, 13 Sept 2023 at 14:14, Adam Williamson wrote: > On Wed, 2023-09-13 at 20:07 +0200, Kevin Kofler via devel wrote: > > Adam Williamson wrote: > > > From there, it's up to people where they see and respond to them. > > > > But every single announcement gets a reply on the mailing list (which is > not > > properly threaded in KNode/Gmane, by the way) saying something like: > > > > > The discussion thread to provide feedback for this change proposal can > be > > > found here https://yaddayadda.example.com/blablabla > > > > With this kind of wording, is it any wonder that people take that as > > mandatory and discussion on the mailing list has almost entirely drowned > > out? (The only Change that gets any discussion here seems to be the > Plasma 6 > > one, and only because it contains a completely outrageous > downstream-only > > change hidden in the fine print, silently killing Plasma X11 support.) > > No, per Matt's reply, you were right and I was wrong, the intent is to > direct discussion to Discourse. I was confused because I was just > following the process documentation (silly me!) which doesn't explain > any of this. > > The changes to how discussions were to go to discourse happened around the same time as Ben was laid off. I think the documentation not getting updated is just one of ... many things left undone. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Adding Passim as a Fedora 40 feature?
On Fri, 25 Aug 2023 at 13:31, Richard Hughes wrote: > On Fri, 25 Aug 2023 at 16:27, Stephen Smoogen wrote: > > It depends on the scanning from ports open to unknown shared files to > 'why did our network costs go up so much?' > > Surely if you're on a local network with bandwidth costs you'd turn > off avahi or lock down the firewall? Lots of stuff blasts out mDNS > traffic these days. > In the Windows world, you have a one-click which says 'I am on a metered line' which is supposed to do things like that. I don't see anything like that on the Mac but I am only 'learning' it now. I just realized.. is avahi even on in a default install or would this be an extra service needed to be turned on and 'configured' (not that avahi needs much configuring). It isn't on my F38 box, but I have been living in it for a long time so it could be something I did in the past or something I inherited from a long ago release. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
[EPEL-devel] Re: Take the EPEL user and contributor survey 2023!
On Fri, 1 Sept 2023 at 16:03, Diego Herrera wrote: > Hello, everyone > > The Fedora EPEL SIG is asking for feedback to improve EPEL via this survey! > > * https://fedoraproject.limequery.com/2023 > > The link is incorrect and should be https://fedoraproject.limequery.com/epelsurvey2023 > The survey is targeting EPEL users and contributors. It asks about > how you use EPEL, how you contribute to it, and on what would you need > to improve that experience. > > If you're someone who uses or works on Extra Packages for Enterprise > Linux, > please participate. Survey closes at the end of September! > > Thank you for your contribution! > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Adding Passim as a Fedora 40 feature?
On Mon, 28 Aug 2023 at 16:02, Richard Hughes wrote: > On Fri, 25 Aug 2023 at 12:42, Richard Hughes wrote: > > I was thinking of adding Passim as a default-installed and > > default-enabled dep of fwupd in the Fedora 40 release. Before I create > > lots of unnecessary drama, is there any early feedback on what's > > described in https://github.com/hughsie/passim/blob/main/README.md > > please. > > Given that I've not been flamed into a cave with the suggestion, > should this be a standalone change or a system-wide change? I could > argue it either way. > > I would say system wide change. It is affecting a security posture and the assumptions of use may expand to allowing things like RPMs and other things to be shared. > Richard. > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Adding Passim as a Fedora 40 feature?
On Fri, 25 Aug 2023 at 10:31, Richard Hughes wrote: > On Fri, 25 Aug 2023 at 13:19, Stephen Smoogen wrote: > > My understanding was that Microsoft found their own 'share updates' not > working as much as expected > > Hmm, I heard the opposite; can you give any more info? They have way > No, I only have some chatter from sysadmins at enterprise sites who had to deal with audits, failed updates, and being told to turn it off to fix them. So let's just assume I am talking to too many cranky old sysadmins and I believed their fish stories too much. > more telemetry than we do, and I was told it would not "be feasible" > to continue WU without the peer-to-peer functionality built into > windows. According to them they even have some kind of IPv6 tunnel > thing going on which seems alarming if true. > > either by network scans > > As in "port 27500 exists you have a security problem" kind of scans? > > It depends on the scanning from ports open to unknown shared files to 'why did our network costs go up so much?' > > or just the fact that as soon as someone puts up a service like this.. > it is profitable for the crooks to abuse it. > > Probably my naivety, but what kind of things did you have in mind? > > The following are just things I have seen from blackhat/defcon over the years and criminal gang stories. I don't expect (m)any of them may be related to passim, but most of the time the problems are with a protocol/service which says "Here we've assuming your local network (aka LAN) is a nice and friendly place, without evil people trying to overwhelm your system or feed you fake files." So when I read that these days, I get anxious. Going from other things it has been a way to inject bad packages, bad metadata, mass system slowdowns across a fleet, using the service on N systems as a DDOS against third parties (which they then charge fees for), etc. The bad packages are more of a problem because of stolen keys being used to sign something. The 'onion' layers of protection that might have been in place is that you get updates on that from a subset of 'secure' places. Instead now, this could be any system which presents the signed data on a distributed service which says its legitimate. [And depending on the P2P, it can be that like cockroaches the bad data will keep popping up and spreading so you need to make sure you have somewhere else a blacklist to remove things.. though you need to make sure that blacklist can't be manipulated also.] Mass slowdowns are where you find that the sharing does some sort of scan which can somehow be overloaded in some sort of CPU or disk usage loop (this is usually a chained flaw in say a compression routine which 'should never happen with legitimate data'.) DDOS are where the metadata being shared points everyone to download something from some place which isn't expecting it. [Or some packet lookup that the P2P service expects] > Richard. > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Adding Passim as a Fedora 40 feature?
On Fri, 25 Aug 2023 at 07:44, Richard Hughes wrote: > Hi all, > > I was thinking of adding Passim as a default-installed and > default-enabled dep of fwupd in the Fedora 40 release. Before I create > lots of unnecessary drama, is there any early feedback on what's > described in https://github.com/hughsie/passim/blob/main/README.md > please. > > The tl;dr: is I want to add a mDNS server that reshares the public > firmware update metadata from the LVFS on your LAN. The idea is that > rather than 25 users in an office downloading the same ~2MB file from > the CDN every day, the first downloads from the CDN and the other 24 > download from the first machine. All machines still download the > [tiny] jcat file from the CDN still so we know the SHA256 to search > for and verify. > > I am not sure how much this will actually help things. My understanding was that Microsoft found their own 'share updates' not working as much as expected and causing way too many security headaches even on 'nice friendly networks' either by network scans or just the fact that as soon as someone puts up a service like this.. it is profitable for the crooks to abuse it. I am not against it, but I think the days of "Here we've assuming your local network (aka LAN) is a nice and friendly place, without evil people trying to overwhelm your system or feed you fake files." is dead and whatever tool applied needs to be designed with the fact that it only takes 0.01% of 'evil people' in the population to make things crap. > The backstory is that as the fwupd grows and grows (to ChromeOS, > FreeBSD, Windows and macOS) we need to scale things up a couple of > orders of magnitude. This isn't specific to firmware stuff, although I > think it makes a great testcase which we could add dnf or ostree > content to in the future. Comments and questions are most welcome. > Thanks, > > Richard. > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Potential (security) issue for beginners/non-experts when release is End Of Life: Fedora doesn’t consider the behavior of beginners/non-experts sufficiently
On Mon, 14 Aug 2023 at 17:59, Przemek Klosowski via devel < devel@lists.fedoraproject.org> wrote: > On 8/13/23 16:57, Kevin Kofler via devel wrote: > > look at SUPPORT_END in /etc/os-release and nag more frequently. > > Highly recommend other Fedora editions consider similar notifications. > > I don't think more nagging is going to help. It is just going to be > considered yet another annoying nag to ignore or click away. Like it or not, > non-technical users are NEVER going to upgrade to a new operating system > release. Not now, not 10 years from now. Until their computer physically > breaks down, at least. There is just nothing you can do about it. > > I believe this is overly pessimistic: people tend to upgrade their Android > and iOS devices and applications, because the update process is > low-friction and well tested so that people tend to trust it. > > It is fairly well tested because the entire phone hardware set is a 'known' quantity. There are also several different layers of 'testing' and quality control which happen: 0. The OS manufacturer 1. The phone manufacturer (for android about 2 years, for iphone for 10) 2. The wireless carrier (for android about 3 years, for iphone for 7) 3. Sometimes major software app manufacturers Each of these groups have 'farms' of several hundred of each type of phone which get continual updates and they have a long certification process to make sure that they reach 'all the phones updated without problems and ran N hours without issues afterwards'. This is part of the reason it can take months for a release from The OS manufacturer (aka Android) to get pushed out to fleets of phones. It is fairly 'expensive' work with lots of little issues having to be tracked down and passed. [Because even when you 'built the phone' you find out that N% of that batch still acts slightly different from the rest on this update.] In the desktop/computer mode this is just outside of anything that I think a volunteer oriented organization could try to make work at scale. > I have personally had multiple Fedora upgrade issues due to lack of space > in the root filesystem, so maybe Fedora is not yet at a point where we can > unconditionally launch into upgrading, but it's a technical issue that can > be corrected. > > We already have SUPPORT_END so I think it makes sense to use 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Removal of Modular repos broke upgrades to Fedora 39: What now?
On Fri, 4 Aug 2023 at 06:16, Miro Hrončok wrote: > Hello folks, > > With the retirement of modularity, the modular dnf repositories for Fedora > 39 > no longer exist. However, this will introduce a problem during upgrades. > When > users try to upgrade from previous Fedora releases with > fedora-repos-modular > installed, they will hit fatal errors that will probably look like this: > > Errors during downloading metadata for repository 'fedora-modular': >- Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39=x86_64 > (IP: ...) >- Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39=x86_64 > (IP: ...) >- Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39=x86_64 > (IP: ...) > Error: Failed to download metadata for repo 'fedora-modular': Cannot > prepare > internal mirrorlist: Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39=x86_64 > (IP: ...) > > Or: > > Error: Failed to download metadata for repository 'fedora-modular': Cannot > download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were > tried > > (The actual error might differ depending on the exact state of the removal > of > the modular repos and their mirrorlist etc.) > > > This is caused by the combination of the following facts: > > - the modular repo configuration in Fedora 37/38 has > skip_if_unavailable=False > - when the releasever is set to 39, the URLs of the repos give error 404 > > This is a big deal, because even users who don't use modularity at all > (but > have not uninstalled fedora-repos-modular) will not be able to upgrade to > Fedora 39+ without reaching for help. > > Adam outlined 3 options to solve this problem in the bugzilla where he > reported > this: https://bugzilla.redhat.com/2228827 > > I slept on it and have found a fourth option (but I don't think it's very > viable). I'll present all 4 options here: > > I think we are going to need to do multiple of these solutions because there are too many ways people upgrade their systems (usually because someone told them there method would work years ago or they just found a doc which was written years ago, etc). As Petr Pisar points out elsewhere this is not a new problem. We regularly see someone on IRC for years asking why an upgrade didn't work and it comes down to something like skip_if_unavailable=true or some similar issue where a repository is not properly set up (say a copr or third party repo) for the current release. 1. We need to document that this failure could and can occur. We need to point out that we are only testing N methods for upgrades and anything else will need manual work arounds. The way to maybe find those will be to ask on . 2. We need to work out 1-2 methods we 'support' for upgrading which of the ones below I would say D and A where certain tooling will check to see if the upgrade is possible and then alert if it isn't and try a method of turning things off if ok. [If that is even possible with code paths not yet written.] 3. 4. Profit. I don't like B because it could be the most fragile as it will need work in pungi to make sure that the repositories are ALWAYS properly created in a way that doesn't cause problems. [They can't just be 'empty'. They need to be empty with repodata that allows for updates to always work. If this requires hacking pungi then any upgrade of the source code on the releng boxes could cause breakage weeks later or releases later.] It is also hard to ever turn this off. As much as we like to have people upgrade from 36->37 or 36->38, there is a large enough 'hump' of people who do a 36->40 turn that means we would be doing this til maybe 44. Of course if it is just a simple pungi config which doesn't make other things break, B may be the easiest.. > > A. Set skip_if_unavailable=True in the modular repo configuration on old > Fedora > > > > B. Mirror empty modular repositories for the time being > > > > C. Document this in the upgrade documentation > > > > D. Change our upgrade tools to disable modular repos on upgrades to F39+ > > > > > What do you think we should do? My preference would be to go with option > (B) > and fallback to option (A) if (B) isn't finished in reasonable time. > > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > Lis
Re: koji: No space left on device
On Tue, 1 Aug 2023 at 10:49, Ralf Corsépius wrote: > Hi, > > Right now, I have a package built in koji, which is in failed and > success state at the same time: > > Cf. > > https://koji.fedoraproject.org/koji/buildinfo?buildID=2267652 > > The link above redirects to > https://koji.fedoraproject.org/koji/taskinfo?taskID=104215785 > > Which contains: > ... > OSError: [Errno 28] No space left on device: '/var/tmp/koji/tasks/6001' > > The net result of all this is the package being in inconsistent state in > koji and bodhi. > > This is being tracked in https://pagure.io/fedora-infrastructure/issue/11440 . I believe all current sysadmins are on travel to Flock so this will need to wait until they are available. > > Ralf > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in August
On Tue, 25 Jul 2023 at 11:54, Josh Boyer wrote: > On Tue, Jul 25, 2023 at 11:44 AM Florian Weimer > wrote: > > > > * Josh Boyer: > > > > > On Tue, Jul 25, 2023 at 10:53 AM Miro Hrončok > wrote: > > >> > > >> On 25. 07. 23 16:42, Florian Weimer wrote: > > >> > * Miro Hrončok: > > >> > > > >> >> glibc32 codonell, fweimer, > jakub, mcermak > > >> > > > >> > Is this about FTBFS issues? There isn't any recent build failure in > > >> > Koji, so I don't get why it's on this list? > > >> > > >> The build currently in Rawhide was done on Fedora 36 which is end of > life. > > >> > > >> Apparently the release engineering team has not rebuilt this package > in a mass > > >> rebuild at least since Fedora 35. > > >> > > >> To remove it from the list, build the package on Rawhide please. > > > > > > Or we could not, and drop i686 completely. > > > > If we drop glibc32, we can't build any 32-bit code at all because GCC > > will no longer support -m32. In this regardm x86-64 is different than > > the other Fedora architectures which can target bare metal 32-bit even > > from 64-bit-only compilers. > > > > Are bootloaders fully treated as firmware and no longer built by Fedora? > > At least the shim package does not come with corresponding source code > > AFAICS. But I expect that there are other 32-bit pre-boot packages that > > we still rebuild. > > > > We need to fix this GCC build issue for CentOS 10 eventually, and at > > that point, we won't need glibc32 anymore. It's been a constant source > > of annoyance. > > Necessity is the mother of all invention. If you need this solved by > CentOS Stream 10, you really want to solve it now and get that > solution into F39 or F40 at the latest. > > As much as I would like to see the i686 problem dealt with finally, I am not sure what is done with a fundamental change like this after the closing period for such changes for Fedora 39. [It does lead to a funny problem.. if i686 were to get removed after the mass rebuild because a cascade of FTBFS or other reasons.. does FESCO need a change proposal :)] > josh > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: DNF5-5.0.1 has a stable API
On Mon, 24 Jul 2023 at 13:10, James Ralston wrote: > On Thu, Jul 20, 2023 at 5:46 AM Miroslav Suchý wrote: > > > Dne 20. 07. 23 v 10:08 Peter Robinson napsal(a): > > > > > So everything has to be rewritten across the entire ecosystem to > > > work with it? Wow, who thinks that's a good idea? It took the > > > ecosystem long enough to migrate from the yum "API" to dnf and now > > > they have to do that all over again? > > > > "Only dead projects has stable API" > > > > Me. > > The yum to dnf transition was supposed to be the “the old API was so > horribly broken that we had no choice but to throw it away and design > a new API completely from scratch” event. > > No it wasn't. It was 'the yum API has been rewritten multiple times to meet different small changes and has become a nightmare to keep things working. Let's try and build another one still using python but with a bit more planning.' I saw this as someone who heard Seth Vidal swear about all the things he wish hadn't added and then other people say the same thing. I am not going to say that a dead API is a dead project.. libc calls have been pretty stable for a long time. However, it is stable because a LOT of people work on it and require it to be stable to make things work. Pretty much every project below that tends to become more 'fluid' as the development base gets smaller and the API gets more fluid. It takes a lot of collective memory and tooling to know why X, Y, and Z are in the code base, and if they are still needed. Once the people who work on any version of code 'move on', the ability for others to pick it up and keep it the same way gets harder and harder. Large codeteams are able to handle this because A remembers why B did this and thinks changing X,Y, or Z would break W. Personally I would have preferred to call this a new tool versus trying to use dnf name still. It makes it clearer that the break is going to happen. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Should we provide current/previous release links in URLs?
On Tue, Jul 18, 2023 at 16:43 Kevin Fenzi wrote: > On Mon, Jul 17, 2023 at 05:59:50PM -0600, Orion Poplawski wrote: > > As part of the cobbler project testing, we need to test accessing Fedora > > releases with various URLs: > > > > " > http://download.fedoraproject.org/pub/fedora/linux/releases/35/Everything/x86_64/os > ", > > "https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-35=x86_64 > " > > "https://mirrors.fedoraproject.org/metalink?repo=fedora-35=x86_64;, > > > > These need to get updated continuously as Fedora progresses. Could we > > perhaps have a "current" and "previous" (or similar) that tracks the most > > recent and previous release? > > Could we? Sure... but... there's a big can of worms around the source of > truth as to what releases are in what state. We could add yet another > thing that we have to manually update here I suppose. Not a super fan of > that. > Having done something similar in the past you find out quickly people will use such urls or current/past in configs you don’t expect. Then when Fedora moves from 36 to 37 in current you get angry complaints that 5000 systems are broken because yum update tried to move a live system from one version to another and failed in a hundred different ways. > Someday I hope we will finally solve that... > > kevin > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: [Question] how to make Fedora linux os ?
On Thu, 13 Jul 2023 at 21:45, Miao, Jun wrote: > Hi Guys, > > > > AFAIK, the Yocto Project is an open source collaboration project that > provides tools, templates, and methods to help developers create custom > Linux-based systems for embedded devices. > > > > My confusion is that: > >1. what`s the tool to make our Fedora Linux 38 released like Yocto? >2. And Centos ? >3. And Ubuntu ? > > > > > I believe the Yocto system is based on a similar system as Gentoo. It was chosen because most embedded teams at the time were fairly small (maybe 1-2 engineers per 'board') and setting up a multi-system pipeline was too much for getting a system which may only have a 'lifetime' of 1-2 years with a large amount of NDAs and other legal entanglements involved. It also came with the advantage that one could pick and choose layers to change overall design so a basic chipset could be found in a camera, phone, or washing machine but have different additions/subtractions done to make it work for each. As teams got larger, the tooling has become more complex so you can stand up dedicated build clusters and such but in general, a developer can figure out what will make something work themselves without bothering other developers. My outsider look at Yocto OS development seems to have developers either focusing on specific problem sets: 'make this work on a refrigerator with this much memory/cpu/storage and these applications' or an overall 'layer' solution: 'Legal says no GPLv3 so please make sure none of them are included in an image' or 'we need to have one image with debug symbols and this debugger, and this image without', etc. One problem with this style of development is that you can easily end up with 2 developers working on the same board but having chosen completely different optimizations and compile time choices that applications and libraries can not easily mix between the two. The other operating systems you are looking at is aimed at a different problem where how do you get a large number of developers who may only focus on one bit be able to work with each other in a smooth as much manner. This means that the system is less about building the entire operating system in one location but more about makings sure that 400 developers can build stuff which will work together. This means that a developer builds only items which are for testing and developer, and then pushes changes to a central system which will attempt to rebuild things using choices (compiler options, disk layout, etc) set by either a Fedora Engineering Steering Committee decision or general agreement by the main maintainer of a subsystem. The Fedora and CentOS build systems are fairly complicated with about 70 to 100 interrelated applications from when a developer does a build to when someone can download a finished package on a mirror. I have tried writing out a 'map' like a subway system but I usually get lost somewhere in the middle. The general solution is something like [fedpkg] -> [Fedora Builders and Source Control] -> [Fedora QA] -> [Fedora Image Making (iso/containers/etc)] -> [Mirroring System] -> [User] The above 'loses' a lot of granular tools in that set of items with various message buses, various side tools, etc. The lost granularity covers various attempts to deal with concurrency problems where group A is updating the entire python stack while group B is still building updates based on the old stack. Group A's work may take weeks so stopping group B during that time could lead to security issues. [There are many other concurrency which the community has found over the years but that was the first one which came to mind.] -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: OCaml 5 rebuild and i686
On Tue, 4 Jul 2023 at 03:39, Richard W.M. Jones wrote: > We're planning to rebuild all the OCaml packages + dependencies with > the new OCaml 5 compiler (https://ocaml.org/releases/5.0.0). This has > a rewritten runtime system, and Jerry James has been doing amazing > work rebuilding everything in a COPR and fixing lots of issues > (https://copr.fedorainfracloud.org/coprs/jjames/OCaml5/). > > There are however three issues with i686. Firstly there are some > issues with LTO, possibly solvable. Secondly there no native code > backend for i686. It has been dropped upstream and apparently they > have no plans to re-add it. > > (Native code backends for s390x, riscv64 and ppc64le are also dropped > in 5.0, but with plans to add those back in 5.1. They're just taking > their time to port these ones across to the new architecture.) > > I am not too worried about i686, but the above seems more concerning. What happens with the tooling for this on these platforms? I believe that currently the Fedora builders for Power use Fedora as the KVM server using various virt tools which I believe are Ocaml based. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)
On Fri, 30 Jun 2023 at 11:50, Jonathan Wakely wrote: > On Fri, 30 Jun 2023 at 16:38, Ian Pilcher wrote: > > Rather than expecting runtimes and applications to be fixed to work > > without any timezone information, perhaps the best way forward would be > > to create a tzdata-utc (and similar Java and Python packages). > > > > (Sorry if this has already been suggested & rejected. I don't remember > > seeing it in this thread, but ...) > > From the change proposal: > > == Feedback == > In June of 2021, we proposed creating a new tzdata sub-package that > would only provide the UTC timezone. As part of the discussion around > this proposal, it was recommended that we completely remove tzdata. We > appreciated this input and welcome additional feedback. > > Thanks, I have enrolled in a basic reading and comprehension program since I missed this twice on read-through. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)
On Fri, 30 Jun 2023 at 11:39, Ian Pilcher wrote:
> On 6/30/23 10:22, Jonathan Wakely wrote:
> > On Mon, 26 Jun 2023 at 19:10, Miro Hrončok wrote:
> >> We would also need to ensure UTC work even without tzdata installed.
> >
> > Yes, that would be useful.
> >
> > Although IMHO even that seems like a nice-to-have not an absolute
> > showstopper. Most containerized workloads that don't need time zone
> > info probably aren't using ZoneInfo("UTC") to convert from UTC to UTC,
> > they're probably not using ZoneInfo at all.
> >
> >>
> >> I would be reluctant to carry this as a downstream-only patch. And the
> upstream
> >> window for changes like this has already closed for Python 3.12.
>
> Rather than expecting runtimes and applications to be fixed to work
> without any timezone information, perhaps the best way forward would be
> to create a tzdata-utc (and similar Java and Python packages).
>
> (Sorry if this has already been suggested & rejected. I don't remember
> seeing it in this thread, but ...)
>
>
I have not seen it and I think it is probably the best way to deal with
this. Going from how many sysadmin tasks I have dealt with where tzdata is
broken on a system.. a LOT of existing code being used in a lot of places
is silently relying on it.. usually in ways where you end up with a bad
crash long after startup, etc. A bare set of whatever fulfills utc and/or
defaults from LANG=C would at least get them working.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: Orphaning packages (was LibreOffice packages)
On Thu, 29 Jun 2023 at 10:48, Bastien Nocera wrote: > Hello, > > As part of the same process outlined in Matthias Clasen's "LibreOffice > packages" email, my upstream and downstream work on desktop Bluetooth, > multimedia applications (namely totem, rhythmbox and sound-juicer) and > libfprint/fprintd is being stopped, and all the rest of my upstream and > downstream work will be reassigned depending on Red Hat's own priorities, > as I am transferred to another team. > > 1. Thank you for all the work you have done on these and other packages in Fedora. The Bluetooth stack is not easy. 2. Thank you for announcing this early and allowing a quick transfer. 3. Good luck with the new team, they are lucky to have you. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Announcing fmt library soversion bump
On Wed, 28 Jun 2023 at 04:20, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 28/06/2023 08:32, Vitaly Zaitsev wrote: > > How I can fix that? > > Steps how to fix such issues for historical purposes: > > 1. Create a new side tag. > 2. Introduce compatibility fmt9 package. > 3. Build fmt9 compatibility package. > 4. Build fmt 10. > 5. Rebuild dnf5 against fmt 10. > 6. Untag fmt9 from this side tag. > 7. Retire fmt9 compatibility package. > Thanks for documenting this for other people to find in the future. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
[EPEL-devel] Re: EPEL working group: updating rocksdb to newer version
On Tue, 27 Jun 2023 at 09:11, Kaleb Keithley wrote: > Hi, > > I don't see a specific epel working group list on lists.fpo. > > The 'working group' is the EPEL Steering Committee which have meetings on Wednesday at #fedora-meeting at 20:00 UTC (I think). Changes like what you are looking at would be to open a ticket https://pagure.io/epel/issues so it can be discussed at the next meeting. Things to cover: 1. WHat versions of EPEL are you updating? (epel-8, epel-9, epel-8-next, epel-9-next) 2. What version is there already 3. What version are you updating to 4. What might break for someone when they do this update and how do they fix it? (aka recompile app, change config, etc). 5. Do you have a version in a COPR which can be tested to see that it works? 6. When do you plan to do the update after any approval > I'd like to update rocksdb to a newer version for consumption by ceph. > (Ceph currently bundles rocksdb-7.9.2 IIRC for when the distribution's > version is too old.) > > AFAIK, AFAICT, ceph is the only consumer of rocksdb in EPEL (or in Fedora > for that matter.) > > I asked the maintainer of the epel rpms, and he referred me to the working > group. > > Thoughts? > > Thanks > > -- > > Kaleb > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Modules without modularity
On Thu, 15 Jun 2023 at 03:04, Petr Pisar wrote: > V Thu, Jun 15, 2023 at 01:33:38AM +0200, Kevin Kofler via devel napsal(a): > > Petr Pisar wrote: > > > and accept that > > users now have to explicitly opt in to those modules. > > That's exactly what killed the current modularity. Nobody felt a presure to > fix the tooling because Modularity was off by default. > > I don't think anyone felt pressure to fix it before it was off by default. Fixes to problems with Fedora MBS were always 'coming real soon' for multiple releases before this decision was made. There have been multiple outages or slowdowns in the Fedora Build System over the years due to MBS issues which only got 'fixed' by herculean last minute efforts. The truth is that this has been a vicious loop from the beginning. There was a general feeling with many developers inside and outside of Red Hat that no matter what problems they saw, they were going to have to like it or lump it. People who were proponents from the start got burned out either by the lack of fixes to the tooling or community pushback. People working on it felt like they were having to put parts of it in before it was ready but also left to handle the fallout from things not working well. Reviewing the past 3+ years, I would say that modularity would only work well if the entire 'build system' and work flow around it was built with that in mind. The Fedora system had nearly 20 years of established work flows, tooling and ideas when modularity was added and it never worked well. The CentOS Stream build system was designed from scratch but with many of the tools Fedora already used, and MBS worked better but still has had many issues of square peg in round hole. Remi's modularity seems to have worked best because of at least two things: 1. He designed his entire build workflow to work with his modularity system. He redesigned how he was going to package and how he was going to deal with modules with tools which fit his workflow. 2. He controls what goes into his build system, when it goes into, and how packages look. 3. When it breaks, he is the only person affected by any breakage (aka there aren't 4000 developers trying to build other things at the same time). In many ways I think that the first 2 items are the core to making modularity work anywhere. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Fedora Copr builders updated to Fedora 38
On Tue, 13 Jun 2023 at 08:21, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Gary Buhrmaster wrote: > > Well, EL6 ELS support is still available for (around) > > another year, so it is a nice to have to support those > > limping along with EL6, but I would generally agree > > with the principal that if supporting a product past > > official EOL becomes overly onerous that support > > should end, or be explicitly funded out of the ELS > > fees if the ELS community needs that support. > > EPEL is not covered by ELS, hence EPEL is already EOL. > > If we are going to support distros that had their EOL 2½ years ago, I want > my Fedora 31 to 36 buildroots back! (Fedora 31 had its EOL only 6 days > before EPEL 6, Fedora 32 to 36 had theirs more recently.) > > I am in agreement with Kevin on this. While there are people who might still want to build for their EL6 systems (including myself *cough*), I think there is a point where its usage of the COPR project's limited resources. If you really need to build stuff against end of life releases, then one needs to do the work themselves or join together with other people who can help pay for those resources. > > I do not consider setting gpgcheck=0 overly > > onerous for EPEL6 > > I consider it a security risk and a no go. > > Kevin Kofler > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: LibreOffice packages
On Mon, 5 Jun 2023 at 16:14, Michael Catanzaro wrote: > > > On Mon, Jun 5 2023 at 01:37:24 PM -0400, Stephen Smoogen > wrote: > > > > 1. What is a flatpak and what does it mean to have an application in > > it? Is it everything bundled in it or does it use layers? > > Two layers: > > * Runtime (base platform, responsibility of runtime maintainers) > * Application (including bundled dependencies not present in the > runtime) > > It's a compromise between traditional distribution-style dynamic > linking for the most common dependencies (the runtime), plus bundling > for the less-common dependencies the application needs that are not > present in the runtime. > > I just wanted to say thank you for taking the time to answer these questions. It was very helpful. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: LibreOffice packages
On Mon, 5 Jun 2023 at 14:10, Steve Grubb wrote: > On Monday, June 5, 2023 1:37:24 PM EDT Stephen Smoogen wrote: > > On Mon, 5 Jun 2023 at 13:32, Michael Catanzaro > > > > wrote: > > > On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour > > > > > > wrote: > > > > zlib should be added to the standard freedesktop.org runtime if it > is > > > > not > > > > already included. > > > > > > zlib is included in both freedesktop-sdk and also GNOME runtimes, so > > > nobody should need to bundle it. > > > > > > Michael > > > > The problem I see in these conversations are: > > > > 1. What is a flatpak and what does it mean to have an application in it? > Is > > it everything bundled in it or does it use layers? > > 2. So there are these 'SDKs' that people mention? What is in them? How > are > > they built? How are they updated? Who maintains them and how can we > > 'verify' in the 'trust and verify' method (aka source code, build flags, > > build system). > > > > I think a FAQ around these and others would probably cut down a lot of > the > > uncertainty and doubt people feel. > > Yes. And how does it's security model work? > > What is the root of trust? Are they signed by a Fedora key that I already > have? How can we verify it's integrity? Once installed, how do I verify > it's > integrity? How do I check if anything has been modified? Does it integrate > well with SE Linux, IMA, fapolicyd, or openscap? On a locked down system, > are > there sysctls that I have undo such as user namespaces? If an app > coredumps, > does a problem report get generated? Who gets it? > > How can I tell what the security policy that the upstream chose to implement for me. > -Steve > > > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: LibreOffice packages
On Mon, 5 Jun 2023 at 13:32, Michael Catanzaro wrote: > On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour > wrote: > > zlib should be added to the standard freedesktop.org runtime if it is > > not > > already included. > > zlib is included in both freedesktop-sdk and also GNOME runtimes, so > nobody should need to bundle it. > > Michael > > The problem I see in these conversations are: 1. What is a flatpak and what does it mean to have an application in it? Is it everything bundled in it or does it use layers? 2. So there are these 'SDKs' that people mention? What is in them? How are they built? How are they updated? Who maintains them and how can we 'verify' in the 'trust and verify' method (aka source code, build flags, build system). I think a FAQ around these and others would probably cut down a lot of the uncertainty and doubt people feel. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
[EPEL-devel] Re: Cannot run fedpkg mockbuild for epel9 on f38
On Sat, 3 Jun 2023 at 11:57, Brad Bell wrote: > I am getting the error message below in response to a `fedpkg mockbuild` > command. What am I doing > wrong ? > > >fedpkg mockbuild > ... snip ... > ERROR: Mock config 'epel-9-x86_64' not found, see errors above. > > > Here is my system information: > > >git branch > * epel9 >rawhide > > >uname -a > Linux brad-mobile 6.2.15-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 > 17:37:39 UTC 2023 x86_64 > GNU/Linux > > >ls /etc/mock | grep epel-9 > alma+epel-9-aarch64.cfg > alma+epel-9-ppc64le.cfg > alma+epel-9-s390x.cfg > alma+epel-9-x86_64.cfg > centos-stream+epel-9-aarch64.cfg > centos-stream+epel-9-ppc64le.cfg > centos-stream+epel-9-s390x.cfg > centos-stream+epel-9-x86_64.cfg > oraclelinux+epel-9-aarch64.cfg > oraclelinux+epel-9-x86_64.cfg > rhel+epel-9-aarch64.cfg > rhel+epel-9-ppc64le.cfg > rhel+epel-9-s390x.cfg > rhel+epel-9-x86_64.cfg > rocky+epel-9-aarch64.cfg > rocky+epel-9-ppc64le.cfg > rocky+epel-9-s390x.cfg > rocky+epel-9-x86_64.cfg > > You need to choose a distribution to build against and set the configs for it ln -s /etc/mock/foobar+epel-9-x86_64.cfg /etc/mock/epel-9-x86_64.cfg ln -s /etc/mock/foobar+epel-8-x86_64.cfg /etc/mock/epel-8-x86_64.cfg > >dnf info fedpkg > Name : fedpkg > Version : 1.44 > Release : 4.fc38 > Architecture : noarch > Size : 333 k > Source : fedpkg-1.44-4.fc38.src.rpm > Repository : @System > From repo: updates > Summary : Fedora utility for working with dist-git > URL : https://pagure.io/fedpkg > License : GPLv2+ > Description : Provides the fedpkg command for working with dist-git > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LibreOffice packages
On Fri, 2 Jun 2023 at 09:40, Peter Robinson wrote: > On Fri, Jun 2, 2023 at 2:28 PM Stephen Smoogen > wrote: > > > > > > > > On Fri, 2 Jun 2023 at 07:20, Matthias Clasen wrote: > >> > >> Lets not make this a drama. > >> > >> Package maintenance changes have never gone through change proposals. > >> > > > > I am sorry, but this was made into a drama by the way this was > executed. Surprise is the opposite of engagement and dropping a ton of > packages and their dependencies and then announcing it is absolute surprise. > > > > This isn't just package maintenance. This is a major change in what is > expected to be included in the next workstation editions with the removal > of expected functionality. If the packages are not picked up within a > certain amount of time or can be rebuilt it means many packages will need > to be edited. Those changes need to be researched, announced, and pushed > through. > > > > It is also drama because people in the community have no idea what else > will take place? When uncertainty and doubt are allowed into the > conversation, people jump to the extremes so they can feel ready to deal > with it. > > > > Could we try something different for future changes? > > 1. Announce that Red Hat will be moving from owning said packages and > dependencies on X date. > > 2. Let people grieve about things for a short while but make it clear > its happening. See if community members or other companies will take up the > burden > > 3. Do the orphan or hand over of packages to the new group. > > > > Instead of 3,1,2? > > That may not always be possible, sometimes it involves departure or > changes of roles for people and those can be delicate and are not > always notifiable. I'm not sure that is the case here but I do know, > from a blog post [1], that the previous maintainer is no longer at Red > Hat. > > Yes, I did engage mouth before brain on this. It isn't alway possible, and real life is messy. My apologies to Matthias in my wording makes it sound like this dropping was his decision and the way it was executed was his doing and fault. > Peter > > [1] https://meeksfamily.uk/~michael/blog/2023-05-15-caolan.html > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: LibreOffice packages
On Fri, 2 Jun 2023 at 07:20, Matthias Clasen wrote: > Lets not make this a drama. > > Package maintenance changes have never gone through change proposals. > > I am sorry, but this was made into a drama by the way this was executed. Surprise is the opposite of engagement and dropping a ton of packages and their dependencies and then announcing it is absolute surprise. This isn't just package maintenance. This is a major change in what is expected to be included in the next workstation editions with the removal of expected functionality. If the packages are not picked up within a certain amount of time or can be rebuilt it means many packages will need to be edited. Those changes need to be researched, announced, and pushed through. It is also drama because people in the community have no idea what else will take place? When uncertainty and doubt are allowed into the conversation, people jump to the extremes so they can feel ready to deal with it. Could we try something different for future changes? 1. Announce that Red Hat will be moving from owning said packages and dependencies on X date. 2. Let people grieve about things for a short while but make it clear its happening. See if community members or other companies will take up the burden 3. Do the orphan or hand over of packages to the new group. Instead of 3,1,2? > > However, it surprises me that for a package, that is part of the > deliverables of Fedora releases, no coordination effort was made to > transition the package from Red Hat maintenance to Fedora maintenance. > > My email is that effort. > > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Plans for dhclient / ISC dhcp?
On Tue, 30 May 2023 at 14:45, Chris Adams wrote: > Once upon a time, Florian Weimer said: > > * Chris Adams: > > > > > Once upon a time, Richard W.M. Jones said: > > >> It seems as if the ISC dhcp package has been EOL'd upstream: > > >> > > >> https://www.isc.org/dhcp/ > > > > > > I'm a little surprised that nobody has forked this to continue > > > maintaining it. dhcpd is widely used, and kea is far from a drop-in > > > replacement. > > > > It's … just not very good. A lot of the logic resides in a shell script > > that runs as root, uses bash arithmetic expansion, and processes > > untrusted data from the network. That's not a good combination at all. > > Well, I was really talking about dhcpd, not dhclient. > > Yes. My apologies to you and everyone else. You said that several times and I just went blathering on dhcpd versus dhclient. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Plans for dhclient / ISC dhcp?
On Tue, 30 May 2023 at 08:46, Chris Adams wrote: > Once upon a time, Richard W.M. Jones said: > > It seems as if the ISC dhcp package has been EOL'd upstream: > > > > https://www.isc.org/dhcp/ > > I'm a little surprised that nobody has forked this to continue > maintaining it. dhcpd is widely used, and kea is far from a drop-in > replacement. > > It is also not sexy software and you have to deal with a very hornery set of bug reports where everything going wrong in any office is of course blamed on DHCP. [You also need to know about the deep intricacies of a ton of flags and settings which may have stated RFC uses but have been misused for decades because some hardware decided to reuse a flag for a boot-time option. You 'fix' an issue and you usually find you broke some key infrastructure no one 'knew' about except someone who retired 4 to 10 years ago. With that, I can see why ISC is 'burying' the software for some poor sucker to take up. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
[EPEL-devel] Re: python build package in epel9
On Fri, 26 May 2023 at 14:10, Brad Bell wrote:
> >uname -a
> Linux fedora 6.2.15-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11
> 15:56:33 UTC 2023 x86_64
> x86_64 x86_64 GNU/Linux
>
> >mock --version
> 3.5
>
> >git branch
> * epel9
>f37
>f38
>rawhide
>
> >dnf info fedpkg
> ... snip ...
> Name : fedpkg
> Version : 1.44
> Release : 4.fc37
> Architecture : noarch
> Size : 333 k
> Source : fedpkg-1.44-4.fc37.src.rpm
> Repository : @System
> From repo: updates
> Summary : Fedora utility for working with dist-git
> URL : https://pagure.io/fedpkg
> License : GPLv2+
> Description : Provides the fedpkg command for working with dist-git
>
>
> The command
> fedpkg mockbuid
> works on all the branches except epel9 where I get the error messages:
>
> No matching package to install: 'python3dist(build)'
> No matching package to install: 'python3dist(furo)'
> ... snip ...
> Not all dependencies satisfied
> Error: Some packages could not be found
>
>
Weird. I just did
```
[ssmoogen@xenadu Fedora]$ fedpkg clone -a screen
Cloning into 'screen'...
remote: Enumerating objects: 710, done.
remote: Counting objects: 100% (710/710), done.
remote: Compressing objects: 100% (533/533), done.
remote: Total 710 (delta 372), reused 344 (delta 157), pack-reused 0
Receiving objects: 100% (710/710), 142.71 KiB | 9.51 MiB/s, done.
Resolving deltas: 100% (372/372), done.
[ssmoogen@xenadu Fedora]$ cd screen/
[ssmoogen@xenadu screen (rawhide)]$ fedpkg switch-branch epel9
branch 'epel9' set up to track 'origin/epel9' by rebasing.
[ssmoogen@xenadu screen (epel9)]$ fedpkg srpm
Downloading screen-4.8.0.tar.gz
100.0%
[ssmoogen@xenadu screen (epel9)]$ fedpkg mockbuild
Not downloading already downloaded screen-4.8.0.tar.gz
setting SOURCE_DATE_EPOCH=1626998400
Wrote: /home/ssmoogen/Fedora/screen/screen-4.8.0-6.el9.src.rpm
INFO: mock.py version 3.5 starting (python version = 3.9.16, NVR =
mock-3.5-1.el9)...
Start(bootstrap): init plugins
INFO: selinux enabled
Finish(bootstrap): init plugins
Start: init plugins
INFO: selinux enabled
Finish: init plugins
INFO: Signal handler active
Start: run
INFO: Start(/home/ssmoogen/Fedora/screen/screen-4.8.0-6.el9.src.rpm)
Config(alma+epel-9-x86_64)
Start: clean chroot
Finish: clean chroot
Start(bootstrap): chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start(bootstrap): cleaning package manager metadata
Finish(bootstrap): cleaning package manager metadata
INFO: enabled HW Info plugin
Mock Version: 3.5
INFO: Mock Version: 3.5
Finish(bootstrap): chroot init
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
Start: unpacking root cache
Finish: unpacking root cache
INFO: enabled package manager cache
Start: cleaning package manager metadata
Finish: cleaning package manager metadata
INFO: enabled HW Info plugin
Mock Version: 3.5
INFO: Mock Version: 3.5
Start: dnf update
Finish: dnf update
Finish: chroot init
...
INFO: Done(/home/ssmoogen/Fedora/screen/screen-4.8.0-6.el9.src.rpm)
Config(epel-9-x86_64) 0 minutes 36 seconds
INFO: Results and/or logs in:
/home/ssmoogen/Fedora/screen/results_screen/4.8.0/6.el9
INFO: Cleaning up build root ('cleanup_on_success=True')
Start: clean chroot
Finish: clean chroot
Finish: run
```
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: python build package in epel9
On Fri, 26 May 2023 at 13:43, Brad Bell wrote: > I am getting the following message when I try to execute > fedpkg mockbuild > in the epel9 branch for my package: > No matching package to install: 'python3dist(build)' > > I don't see this when rebuilding something for epel9. 1. What is the base operating system and version you are using? 2. what is the version of mock and fedpkg (rpm -q mock fedpkg) On my alma9 $ rpm -q rpm mock fedpkg rpm-4.16.1.3-22.el9.x86_64 mock-3.5-1.el9.noarch fedpkg-1.44-4.el9.noarch on my fedora 38 system $ rpm -q rpm mock fedpkg rpm-4.18.1-3.fc38.x86_64 mock-3.5-2.fc38.noarch fedpkg-1.44-4.fc38.noarch > Does this mean that the python build package > https://pypi.org/project/build/ > is not available in epel9 ? > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Planned Outage of s390x affecting all koji 2023-06-01
Planned Outage - koji/s390x - 2023-06-01 05:00 UTC There will be an outage starting at 2023-06-01 05:00 UTC, which will last approximately 24 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2023-06-01 05:00UTC' Reason for outage: The Red Hat Westford location will have more power line work done. This will require the building to be powered down in places which will affect various services like network connections and s390x builders. Affected Services: koji builds and composes will be affected with builds waiting until the s390x builders are able to complete the work. Ticket Link: https://pagure.io/fedora-infrastructure/issue/11345 Please join #fedora-admin or #fedora-noc on irc.libera.chat or add comments to the ticket for this outage above. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Planned Outage of s390x affecting all koji 2023-06-01
Planned Outage - koji/s390x - 2023-06-01 05:00 UTC There will be an outage starting at 2023-06-01 05:00 UTC, which will last approximately 24 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2023-06-01 05:00UTC' Reason for outage: The Red Hat Westford location will have more power line work done. This will require the building to be powered down in places which will affect various services like network connections and s390x builders. Affected Services: koji builds and composes will be affected with builds waiting until the s390x builders are able to complete the work. Ticket Link: https://pagure.io/fedora-infrastructure/issue/11345 Please join #fedora-admin or #fedora-noc on irc.libera.chat or add comments to the ticket for this outage above. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
[EPEL-devel] Re: update needed for eccodes
On Thu, 18 May 2023 at 09:52, Jos de Kloe wrote: > Dear all, > > Thank you very much for sending a detailed upgrade email to the list covering why the upgrade is happening, etc. > I think an update of the epel eccodes packages is needed, since ECMWF > will be starting to generate data files soon that can only be accessed > using this version. > As stated on this page: > > https://confluence.ecmwf.int/display/COPSRV/Implementation+of+IFS+cycle+48r1+for+CAMS > > "To handle CCSDS compressed fields from 48r1 with ecCodes, version > 2.30.0 or newer is recommended." > > This version contains some changes needed to decode the new compressed > GRIB files. > > Apart from this the changes are mostly in the file definition tables > that come with this package, which are needed to read the latest fields > that have been added in the formal WMO (World Meteorological > Organization) table definitions. > > See also this user request: > https://bugzilla.redhat.com/show_bug.cgi?id=2208249 > > Therefore I plan to update the eccodes package for EPEL 7/8/9 soon from > version 2.23.0 / 2.26.0 to version 2.30.0. > > I am not aware of any significant API/interface changes, and therefore > the so version will not change. > > If there are any objections to updating this package please let me know. > > Jos de Kloe > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: java-1.8.0-openjdk orphaned Re: Orphaned packages looking for new maintainers
i > > rrelyea: java-1.8.0-openjdk, plexus-component-api > > rstoyanov: libvirt-sandbox > > rstrode: paktype-naskh-basic-fonts, ucs-miscfixed-fonts, sil-padauk- > > fonts > > runcom: gomtree > > rvykydal: ucs-miscfixed-fonts > > sagitter: f2c > > salimma: et, python-blosc > > sayanchowdhury: python-stomper > > sbluhm: java-1.8.0-openjdk, plexus-component-api > > sdgathman: java-1.8.0-openjdk, plexus-component-api > > sergesanspaille: clang10 > > sergiomb: java-1.8.0-openjdk, paktype-naskh-basic-fonts, sil-padauk- > > fonts, > > plexus-component-api > > sergiopr: python-blosc > > sgallagh: python-blosc > > sharkcz: mingw-gstreamer1 > > shlomiya: dmtcp > > slagle: ucs-miscfixed-fonts > > slankes: choqok > > slp: ucs-miscfixed-fonts > > smani: python-flask-login, mingw-gstreamer1-plugins-base, mingw- > > gstreamer1, > > gtksourceviewmm3 > > spike: java-1.8.0-openjdk, plexus-component-api > > spot: plexus-component-api, paktype-naskh-basic-fonts, mingw- > > gstreamer1, > > java-1.8.0-openjdk, genders, maven2, sil-padauk-fonts > > spstarr: genders > > stahnma: ruby-augeas > > stefw: ucs-miscfixed-fonts > > stevetraylen: java-1.8.0-openjdk, python-blosc, plexus-component-api > > susmit: openmolar > > tagoh: paktype-naskh-basic-fonts, sil-padauk-fonts > > tdawson: python-stomper > > tdecacqu: ucs-miscfixed-fonts > > terjeros: java-1.8.0-openjdk, ruby-augeas, plexus-component-api > > teuf: mingw-gstreamer1-plugins-base, mingw-gstreamer1 > > than: java-1.8.0-openjdk, plexus-component-api > > thrnciar: python-blosc > > tlavocat: ucs-miscfixed-fonts > > tmraz: java-1.8.0-openjdk, plexus-component-api > > tomegun: ucs-miscfixed-fonts > > tpopela: java-1.8.0-openjdk, plexus-component-api > > treydock: genders > > ttorling: java-1.8.0-openjdk, plexus-component-api > > twaugh: python-stomper > > vakwetu: java-1.8.0-openjdk, plexus-component-api > > van: java-1.8.0-openjdk, plexus-component-api > > vanessakris: python-blosc > > vascom: reaver, ucs-miscfixed-fonts > > victortoso: mingw-gstreamer1-plugins-base, mingw-gstreamer1 > > virtmaint-sig: ucs-miscfixed-fonts > > vishalvvr: lohit-malayalam-fonts, paktype-naqsh-fonts, paktype-ajrak- > > fonts, > > paktype-tehreer-fonts, lohit-nepali-fonts, paktype-naskh-basic-fonts, > > lohit-tamil-classical-fonts > > vladimirslavik: ucs-miscfixed-fonts > > vokac: edg-mkgridmap > > vpavlin: spin-kickstarts > > vpodzime: ucs-miscfixed-fonts > > vpolasek: ucs-miscfixed-fonts > > vponcova: ucs-miscfixed-fonts > > walters: java-1.8.0-openjdk, maven2, plexus-component-api > > wilqu: java-1.8.0-openjdk, plexus-component-api > > wsato: paktype-naskh-basic-fonts, ucs-miscfixed-fonts, sil-padauk- > > fonts > > wwoods: python-stomper, ucs-miscfixed-fonts > > xavierb: paktype-naskh-basic-fonts, sil-padauk-fonts > > yanqiyu: stardict > > yselkowitz: tse3 > > zbyszek: ViTables, python-blosc, ucs-miscfixed-fonts > > zmiklank: java-1.8.0-openjdk, plexus-component-api > > zuul: ucs-miscfixed-fonts > > > > -- > > The script creating this output is run and developed by Fedora > > Release Engineering. Please report issues at its pagure instance: > > https://pagure.io/releng/ > > The sources of this script can be found at: > > https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py > > > > Report finished at 2023-05-01 19:45:39 UTC > > ___ > > 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 > > > -- > Sérgio M. B. > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to get a rawhide i686 VM?
On Mon, 15 May 2023 at 07:45, Dmitry Belyavskiy wrote: > Dear Peter, > > On Mon, May 15, 2023 at 1:06 PM Peter Robinson > wrote: > > > > On Mon, May 15, 2023 at 11:39 AM Dmitry Belyavskiy > wrote: > > > > > > Dear colleagues, > > > > > > What is the simplest way to get a rawhide i686 VM? I came across a > > > nasty architecture-specific bug, and the code investigation isn't of > > > much help. There is no obvious way to access a core dump via mock > > > (could you please ping me if it exists?) and the VM looks like a > > > reasonable choice. > > > > run an i686 userspace in a x86_64 is about the best option these days. > > Is there a guideline on how to do it? > > Miroslav Suchy's answer earlier is the best one: ``` mock -r fedora-rawhide-i386 --no-cleanup-after foo.src.rpm mock -r fedora-rawhide-i386 install mock -r fedora-rawhide-i386 shell cd /builddir/build ``` -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: it builds in copr epel-9 (with RHEL-9) but fail to build on koji
On Tue, 9 May 2023 at 14:33, Stephen Smoogen wrote: > > > On Tue, 9 May 2023 at 14:20, Sérgio Basto wrote: > >> Hi, >> it builds in copr epel-9 (with RHEL-9) [1] but fail to build on koji >> [2] >> >> > COPR is using > > DEBUG util.py:445: xorg-x11-server-Xvfb x86_64 1.20.11-17.el9 > appstream 897 k > > EPEL at the time you tried the build was using > DEBUG util.py:445: xorg-x11-server-Xvfbx86_64 1.20.11-11.el9 >build 895 k > > which says to me that the CDN sync from Red Hat isn't complete so koji may > have some 9_2 and some 9.1 items in its build root. [Although I did not see > any 9_2 in the koji output but did see them in the COPR one.] > > I think the Fedora infrastructure is trying to get a download for koji > which may take some time. Try again tomorrow > > Looks like the sync is done already. I see that the `xorg-x11-server-Xvfb x86_64 1.20.11-17.el9` is now downloaded. If retriggering does not work I would put in a release engineering ticket to see if koji needs something 'kicked'. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: it builds in copr epel-9 (with RHEL-9) but fail to build on koji
On Tue, 9 May 2023 at 14:20, Sérgio Basto wrote: > Hi, > it builds in copr epel-9 (with RHEL-9) [1] but fail to build on koji > [2] > > COPR is using DEBUG util.py:445: xorg-x11-server-Xvfb x86_64 1.20.11-17.el9 appstream 897 k EPEL at the time you tried the build was using DEBUG util.py:445: xorg-x11-server-Xvfbx86_64 1.20.11-11.el9 build 895 k which says to me that the CDN sync from Red Hat isn't complete so koji may have some 9_2 and some 9.1 items in its build root. [Although I did not see any 9_2 in the koji output but did see them in the COPR one.] I think the Fedora infrastructure is trying to get a download for koji which may take some time. Try again tomorrow > the test with xvfb-run seg fault and fails on koji [3] any idea why ? > > Thank you > > > > [1] > https://copr.fedorainfracloud.org/coprs/build/5901019 > > [2] > https://koji.fedoraproject.org/koji/taskinfo?taskID=100929278 > > [3] > xvfb-run -a -s '-screen 0 1024x768x24 -ac +extension GLX +render - > noreset' pytest PyOpenGL-3.1.6/tests > -- > Sérgio M. B. > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
On Mon, 8 May 2023 at 19:35, Demi Marie Obenour wrote: > On 5/8/23 19:09, Neal Gompa wrote: > > On Mon, May 8, 2023 at 7:05 PM Demi Marie Obenour > wrote: > >> > >> On 5/8/23 18:49, Kevin Fenzi wrote: > >>> On Mon, May 08, 2023 at 09:29:02PM +0100, Sebastian Crane wrote: > >>>> Dear Kevin, > >>>> > >>>>>> Hmm, quoting from https://pagure.io/releng/issue/11092: > >>>>>>>> Also the aarch64 cluster is running on Fedora 33 boxes, so we > >>>>>>>> should probably try to do a full redeploy :-( > >>>>>>> We can't upgrade it from f33 because docker is no longer in f34+ > and > >>>>>>> openshift origin / 3.11 doesn't support any newer either. > >>>>>> > >>>>>> Is this still true? I don't think we want to make the Fedora release > >>>>>> process contingent on something that requires F33. > >>>>> > >>>>> yes, it's still true. Note thats the aarch64 osbs cluster. > >>>>> The x86_64 one is rhel7. > >>>> > >>>> Might it be possible to replace Docker with CRI-O on the OpenShift > >>>> cluster? > >>> > >>> Nope. openshift 3 / osbs1 uses docker. :( > >>> > >>> kevin > >> > >> alias docker=podman > > > > Using Podman with it through Podman's implementation of the Docker > > Host protocol *may* work, but a version of Podman that has it is not > > currently available for RHEL 7 (which is what OpenShift 3.11 runs on). > > Time for an OpenShift upgrade? > > I realize people are trying to help with suggestions, but the problem is that this is not a simple solution or it would have been done years ago. The Fedora Build System is a very complicated set of applications all tied together with custom scripting, schema, and various updates over time. There are somewhere around 40 core services and 30 more subsidiary ones which need to be continually working to allow for the daily builds for multiple releases. Many of those services have been added in at different times with different operating systems and rules. In order to work with each other a lot of 'glue' scripting, libraries and such are needed. You upgrade podman/docker in one section and you find that the message bus isn't sending in another because an API call isn't there anymore. You try putting in something which says it has a koji plugin and you find it doesn't work with our koji and then you need to extend the plugin 40 ways to work with bodhi, pdc, fedmsg and fedora-messaging, and a dozen other things which all are the actual build system. Once those get fixed, you find that it is now causing other glue parts to fail in odd ways no one remembers why without some archaeological coding. When dealing with the Build system side of things there is currently 1 senior system administrator and 1 senior release engineer. There are some volunteers who can work on subparts but mainly have day jobs doing other things. Looking at IRC, most of the 10-12 hour work day is dealing with compose problems, build issues, hardware failures, and similar things. Most of the 40 component subsystems like the Open Shift Build System (OSBS) are brought in by a dedicated team who have a budget time to get it working and into place. Once that time is done, any fixes are on the Fedora staff or working with available time from whatever team. tl;dr: The Fedora Build System is in total a very complicated set of tools where changing or upgrading any one part tends to cascade to fixing lots of glue throughout the system. Instead of looking to upgrade things to add more deliverables, it may be better to look at other ways to get those deliverables built. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
On Mon, 8 May 2023 at 15:58, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, May 08, 2023 at 09:24:08AM -0700, Kevin Fenzi wrote: > > > I'd like to note that making this blocking doesn't waive any kind of > > magic wand that makes our infrastructure more reliable. ;) > > The container build pipeline is a long collection of fragile things. > > It may well result in us slipping more based on things not working. ;( > > Hmm, quoting from https://pagure.io/releng/issue/11092: > >> Also the aarch64 cluster is running on Fedora 33 boxes, so we > >> should probably try to do a full redeploy :-( > > We can't upgrade it from f33 because docker is no longer in f34+ and > > openshift origin / 3.11 doesn't support any newer either. > > Is this still true? I don't think we want to make the Fedora release > process contingent on something that requires F33. > > ``` $ sudo -i ssh osbs-aarch64-node01.iad2.fedoraproject.org cat /etc/system-release Fedora release 33 (Thirty Three) ``` My memory of this is that this is not an easy thing to 'fix'. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
