[Test-Announce] 2022-12-12 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2022-12-12 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.libera.chat Greetings testers! It's time for a first meeting since Fedora 37 was released! Let's get together to check in on 37 and 38. Note that clocks have now gone back everywhere that does daylight savings time, so the meeting will be at 16:00 UTC (I'm almost sure I got this right this time). If your clocks changed a while back, the meeting will be at the same local time as always. If your clocks didn't change, the meeting will be an hour later in your local time than it was during the summer. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. Note, I'm gonna suggest at this meeting that we cancel the meeting scheduled for Boxing Day, as everyone will likely be off for the holidays. If so, the next scheduled meeting would January 9th. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 38 check-in 3. Test Day / community event status 4. Cancel 2022-12-26 meeting? 5. Open floor -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Sat, 2022-12-10 at 00:20 +0100, Fabio Valentini wrote: > On Fri, Dec 9, 2022 at 11:43 PM Adam Williamson > wrote: > > > > So since this turns out to be less important than I thought (thanks bcl > > for the correction) I won't poke it much further than I have today, but > > following up on the above, I've done a couple of PRs, one to strip more > > stuff in lorax: > > https://github.com/weldr/lorax/pull/1291 > > and one to dump a chunk of older iwlwifi firmwares: > > https://src.fedoraproject.org/rpms/linux-firmware/pull-request/9 > > those combined would get us some breathing room for a while... > > I wonder, hasn't this discussion been side-tracked a little bit? > Looking at the bug report linked in your first post, a big part of the > recent size increase were *media codecs*, which I'm pretty sure are > definitely not needed during install (decoders for JPEG-XL and AVIF > images, or AV1 video, etc.). > Unless I'm reading things wrong, dropping these from whatever they are > pulled in by (GStreamer / WebKitGTK?) would make a much bigger > difference than dropping a few firmware files? It's all part of the same discussion to me. I've filed https://bugzilla.redhat.com/show_bug.cgi?id=2152229 now for the original problem. Dropping the new deps of webkitgtk in lorax runtime- cleanup is possible, but would be rather ugly and fragile (any time the deps *changed*, we wouldn't necessarily notice and update the stripping; we already don't update it enough and it's probably missing stuff). It's much more robust if the unnecessary deps can be avoided at source. Still, that change in webkitgtk caused the images to grow by ~15M. The lorax change I filed today saves ~11M and the iwlwifi change should save ~30M I think. So no, actually, fixing the new webkitgtk deps wouldn't make a "much bigger difference", though I'd still like for it to happen! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On 12/8/22 07:31, Kevin Kofler via devel wrote: > Tomáš Popela wrote: >> firefox, because that's what the web based installer should/will use in >> the end > > 臘 A full-blown, 71 MB compressed (!) web browser just to show the UI for the > installer! > > IMHO, the web-based UI is a major mistake and should never be shipped in > Fedora. It is good as a prototype, but way too resource-heavy to be shipped > in production. We need a rewrite of the UI design in a desktop toolkit. (If > GTK is not suitable, how about Qt? ☺) I wholeheartedly agree. Not only because of resource consumption, but also because of the total disaster that is the NPM ecosystem. Do they really plan on building each and every Node module from the ACTUAL source code? What ‘npm install’ puts in node_modules is often NOT actual source code, but rather minified or transpiled in some way. Using a desktop toolkit would be far FAR better. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ 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: Small rant: installer environment size
On Fri, Dec 9, 2022 at 11:43 PM Adam Williamson wrote: > > So since this turns out to be less important than I thought (thanks bcl > for the correction) I won't poke it much further than I have today, but > following up on the above, I've done a couple of PRs, one to strip more > stuff in lorax: > https://github.com/weldr/lorax/pull/1291 > and one to dump a chunk of older iwlwifi firmwares: > https://src.fedoraproject.org/rpms/linux-firmware/pull-request/9 > those combined would get us some breathing room for a while... I wonder, hasn't this discussion been side-tracked a little bit? Looking at the bug report linked in your first post, a big part of the recent size increase were *media codecs*, which I'm pretty sure are definitely not needed during install (decoders for JPEG-XL and AVIF images, or AV1 video, etc.). Unless I'm reading things wrong, dropping these from whatever they are pulled in by (GStreamer / WebKitGTK?) would make a much bigger difference than dropping a few firmware files? Fabio ___ 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: Small rant: installer environment size
On Fri, 2022-12-09 at 09:48 -0800, Adam Williamson wrote: > On Fri, 2022-12-09 at 12:04 +0100, Florian Weimer wrote: > > * Richard W. M. Jones: > > > > > You only need network / wifi firmware blobs (although I'm sure they > > > are in themselves large) and then you can fetch anything else needed > > > for the hardware including graphics, right? > > > > I think you need graphics to set up wifi. > > Yeah, this is an awkward chicken-and-egg problem. Even if we assume > you're on a wired network, kernel modules generally - AIUI - try to > load the firmware once, on initial module load, and if they can't find > it, just give up, right? So we still have an ordering problem: how can > we delay the loading of modules that need firmware until the network is > up for us to be able to access the firmware files? > > Maybe I'm missing something that would help there, but it seems > tricky... > > Looking at sizes, iwlwifi firmware alone is 75M(!) ath10k is 6.8M, > ath11k is 12M, ath6k is 812K, so that's nearly another 20M. brcm/ is > another 6.4M and I *think* that's all wifi. There's a few other minor > ones, but that's a little over 100M of just wifi, with Intel by a huge > margin the worst offender. > > Does anyone know anyone we can talk to at Intel about this? It's pretty > obnoxious. > > In terms of what the other big space takers are in general: > > * amdgpu/ (AMD video cards) is ~20M > * intel/ (mainly Intel bluetooth) is ~15M [0] > * qed/ (some very high-end QLogic network cards) is ~10M [0] > * i915/ (Intel video firmware) is 8.4M > * mediatek/ is 7.7M [1] > * qcom/ is 7.3M > > Then it trails off from there. Just the wifi plus those 6 things are > around 170M, so the large majority of all the space taken. > > [0] No, we can't lose this - people install with Bluetooth > mice/keyboards > [1] For a quick win right now possibly we could assume nobody's going > to use one of those as the interface for a Fedora install and drop > that, not sure if it's a safe assumption > [2] We could possibly lose a bunch of this stuff, I'll look into it So since this turns out to be less important than I thought (thanks bcl for the correction) I won't poke it much further than I have today, but following up on the above, I've done a couple of PRs, one to strip more stuff in lorax: https://github.com/weldr/lorax/pull/1291 and one to dump a chunk of older iwlwifi firmwares: https://src.fedoraproject.org/rpms/linux-firmware/pull-request/9 those combined would get us some breathing room for a while... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Fri, 2022-12-09 at 14:45 -0700, Chris Murphy wrote: > > On Thu, Dec 8, 2022, at 12:08 PM, Adam Williamson wrote: > > > I mean, the modern systems that *need* GPU firmware generally seem to > > do pretty well with using native resolution and don't perform too > > badly, especially in the simple installer UI. When I test the fallback > > path on my bare metal test box on UEFI it uses the monitor's native > > resolution and performs fine (even, honestly, in GNOME), and that > > motherboard is nearly a decade old even. Don't know if this is the same > > for everyone, of course. > > > For what it's worth, this is back on the change list for Fedora 37. > > https://fedoraproject.org/wiki/Changes/Linux_Firmware_Minimization I hope they've co-ordinated with Peter this time, it seems kinda rude to keep pushing this without involving the package maintainer who's already done quite a lot of work on splitting things up and so on. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Fri, Dec 09, 2022 at 02:38:48PM -0600, Chris Adams wrote: > Once upon a time, Brian C. Lane said: > > On Thu, Dec 08, 2022 at 02:17:22PM -0600, Chris Adams wrote: > > > One other thing that I noticed a while back that takes up a chunk of > > > space is the kernel... it's included inside install.img (in two places > > > even, although I assume it's hardlinked?), even though it has to have > > > already been loaded before install.img can be read. > > > > What two places? On rawhide we have one on the iso under /images/pxeboot/ > > and another inside the install.img under /usr/lib/modules... > > There used to be two on the ISO with syslinux (but they were effectively > hardlinked, so that didn't matter), didn't realize that'd been reduced. > > There's also two inside install.img, /boot/vmlinux- and > /usr/lib/modules//vmlinuz. This is what I'm not sure if it's > linked, or if the squashfs compression makes it an effective wash, or > what; extracting the squashfs does not result in hardlinked files. I checked, it's not hardlinked. I'd hope that squashfs does the right thing and takes advantage of them being the same. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ 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: Small rant: installer environment size
On Fri, Dec 9, 2022, at 7:30 AM, Ray Strode wrote: > Hi, > > On Thu, Dec 8, 2022 at 2:55 PM Adam Williamson > wrote: >> This is the direction Daniel was thinking down. I'm waiting for someone >> with more expertise to reply, but I suspect the reply is going to be >> along the lines of "yes, we *can* do that, but it's somewhat tricky >> work that involves thinking about lots of paths that aren't obvious, >> and somebody would need to dedicate their time to working on that". > Presumably we could package the firmware separately and just unpack it > into place from a udev rule when the hardware is detected? > > But first, do we actually know this is a problem? > I think you're saying squashfs loads the whole decompressed image into > memory, but my expectation prior to your mail was that it performs I/O > on the usb stick (with a cache in between). If my intuition was right > and files only hit ram when accessed, then it seems like this is > pretty much not an issue, right? From a certain point of view there's a potential inefficiency with squashfs reads in that there's a minimum block size that it needs to read in order decompress its 128 KiB block. It's possible quite a lot of what's decompressed isn't (immediately) needed. But it's still a random access file system. It's not necessary to read the whole image into RAM. Repo metadata is the big hit for netinstall because it's downloaded into /tmp which is tmpfs. And DVD already has repomd on it, and only downloads more if you enable some other repo. Live doesn't need repomd. So initially netinstaller uses less memory up until the the Anaconda language selection screen appears, at which point it starts background downloading repomd. It quickly catches up to, and surpasses, Live media memory consumption. Off hand, I'm not sure what's producing all the anonymous pages during Live installation but it's a fairly linear increase as the installation progresses. Since it's an rsync based installation, I'm currently frownie facing pondering the cause of the anon page explosion. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Include minor version number in packaged Python shebangs
DNF modules let you install multiple different versions of Python 3, and the `alternatives` tool lets you change which is the default version invoked by `/usr/bin/python3`. However, at least for *Enterprise Linux 8, it seems a lot of packages were built assuming the distro's default Python 3.6, but at runtime only invoke "Python 3", not 3.6 specifically. It seems that I still need Python 3.6 for most packages installed via DNF on EL8, but I also definitely need Python 3.8+ for multiple packages I use installed with PIP. So, the workaround to having both installed on my system at the same time would be to edit the shebangs to include the minor version of Python that each application requires. ...Right? I wanted a sanity check before I bother sending spam to EPEL package maintainers. Or, is this even a reasonable thing to ask package maintainers to change, or should I just start patching the local shebangs myself? Or is there a better solution? ___ 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: Small rant: installer environment size
On Thu, Dec 8, 2022, at 12:08 PM, Adam Williamson wrote: > I mean, the modern systems that *need* GPU firmware generally seem to > do pretty well with using native resolution and don't perform too > badly, especially in the simple installer UI. When I test the fallback > path on my bare metal test box on UEFI it uses the monitor's native > resolution and performs fine (even, honestly, in GNOME), and that > motherboard is nearly a decade old even. Don't know if this is the same > for everyone, of course. For what it's worth, this is back on the change list for Fedora 37. https://fedoraproject.org/wiki/Changes/Linux_Firmware_Minimization -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Thu, Dec 8, 2022, at 10:28 AM, Adam Williamson wrote: > On Thu, 2022-12-08 at 17:10 +, Gary Buhrmaster wrote: >> On Thu, Dec 8, 2022 at 5:06 PM Adam Williamson >> wrote: >> >> > It already *is* compressed, which is why it doesn't get any smaller in >> > the compressed filesystem image, unlike the other things I mentioned. >> > Check for yourself - look under /lib/firmware and you'll see only >> > things ending in .xz. >> >> Right, but zstd *may* have a better compression >> ratio than .xz (that was at least one of the reasons >> given for the changes to support it). > > I actually spent half an hour looking into that yesterday as I got > diverted into the details of how the filesystem compression stuff > works, but all the references I found say xz consistently compresses > better than zstd. zstd's advantages over xz are in *performance* (time > taken to compress and decompress). So switching from xz to zstd seems > like it would make things bigger, not smaller. xz will use a larger computation cost upfront (compression) to achieve a higher compression ratio than zstd, i.e. you can always ask xz to spend more time to get a higher compression ratio and thus beat zstd on resulting file size. But zstd will always beat xz if you favor time to compress, and significantly beats xz on decompression time. Net costs: Fedora releng takes one compression hit per image created, but consumers of those images which also includes a ton of Fedora QA bot time as well as human users are in the dozens to thousands of hits per image created. The net energy cost is quite a lot higher using xz compared to zstd. Only focusing on image size is misleading. There's a very real energy hit of all this compression and decompression. I don't know how to weigh the costs and figure out a compromise, but totally ignoring one of the costs is probably incorrect. For all I know a balanced approach means using xz but at a lower compression ratio, but someone with round tuits and interest would need to look at it. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Thu, Dec 8, 2022, at 10:06 AM, Daniel P. Berrangé wrote: > Is there something that can be done to optimize the RAM usage, > in spite of the large installer env size ? What's wrong with the RAM usage now? We do semi-regularly run into issues with openQA VM's running out of memory. So far they're all been considered bugs when we hit them, and the change is reverted including a system change to bump tmpfs on /tmp quite a lot. But keeping the VMs at 2G has helped discover changes that in retrospect shouldn't have been changed. Ergo, even though it's a pain to regularly hit these bugs, I don't think there is a per se problem with the 2G RAM selection. When it's all working as expected, swap on zram is used rather significantly and works as expected. > If we're installing off DVD media, it shouldn't be required to > pull all of the content into RAM, since it can be fetched on > demand from the media. AFAIK this doesn't happen. Files are read in only on demand, not a monolithic read of everything and kept in cache somehow. > IOW, 99% of the firmware never need > leave the ISO, so shouldn't matter if firmware is GBs in size [1] > if we never load it off the media. Same for languages, only > the one we actually want to use should ever get into RAM. At first glance it might seem you can get memory savings by not having swap on zram enabled. But what happens is anonymous pages can't be compressed. And also they can't be dropped since they have no files backing them. The result is file pages get dropped in memory tight situations and we end up getting (file) page faults, and it's just super expensive. Yes you can read these pages back from files but it's extra costly because even if it's only a 4K read that's needed, it'll translate into potentially upwards of 1M reads: to find the 4K extent requires reading multiple 4K ext4 metadata blocks, which aren't necessarily colocated in a 128 KiB squashfs block, so we end up reading 1 to 10 of those, taking the ram and memory hit to decompress them to reveal their 4K content we need, dropping the rest. And then doing that every time there's a page fault. So I'd say it's probably asking for a performance hit that isn't really going to save much memory. On high latency devices like USB sticks, it's not a good UX. > If we're installing off a network source, we need to pull content > into RAM, but that doesn't mean we should pull everything in at > once upfront. Pretty sure netinstaller's big RAM hit is repo metadata. All of it is downloaded before we have partitioning done, thus the repo metadata isn't stored on disk, rather in memory and it's tmpfs so it may not be compressed either (at least it's not subject to swap on zram out of the gate). I'm pretty sure partitioning happens before the packages are downloaded though, which means they get stored on disk not in memory. But the repo metadata is pretty big now and that's a big memory hit for netinstallers. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
On Fri, Dec 9, 2022, at 10:59 AM, Timothée Ravier wrote: > Using layering will also conflict / not interact well with the move to > container based ostree image in F38: > https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable (I'm only kind of following this thread and I agree we should not enable layering by default) But a note: from the rpm-ostree perspective, we intend to still fully support client side layering. Obviously this change suddenly makes it very straightforward to do derivative server-side layering/builds, and there's been a lot of excitement around that. I do expect most even semi-technical users to do this. But it's not clear to me that we should say that's the *only* path and at a technical level today a lot of work went into keeping that functionality. For example, today for OpenShift for example we client side package layer kernel-rt and a few other things. I obviously want us to move to always building an image, but it needs some work. There's also valid use cases around things like "I want to ssh to this one machine and install kernel-debug". ___ 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: Small rant: installer environment size
Once upon a time, Brian C. Lane said: > On Thu, Dec 08, 2022 at 02:17:22PM -0600, Chris Adams wrote: > > One other thing that I noticed a while back that takes up a chunk of > > space is the kernel... it's included inside install.img (in two places > > even, although I assume it's hardlinked?), even though it has to have > > already been loaded before install.img can be read. > > What two places? On rawhide we have one on the iso under /images/pxeboot/ > and another inside the install.img under /usr/lib/modules... There used to be two on the ISO with syslinux (but they were effectively hardlinked, so that didn't matter), didn't realize that'd been reduced. There's also two inside install.img, /boot/vmlinux- and /usr/lib/modules//vmlinuz. This is what I'm not sure if it's linked, or if the squashfs compression makes it an effective wash, or what; extracting the squashfs does not result in hardlinked files. I know that /boot on an installed system is typically separate, so hard links don't work when installing the kernel, but separate-/boot is not always the case. It'd be nice if the kernel install scripts tried to hard link where possible. > I think I tried removing the kernel from the install.img at one point, > but it ended up being required for FIPS (see > https://github.com/weldr/lorax/issues/1021). Ahh. I think I brought it up (on fedora-devel or maybe anaconda-devel) too, but forgot (and forgot the reason why). I agree that it seems silly that looking at a kernel file that was not used to boot is considered acceptable. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Fri, 2022-12-09 at 12:18 -0800, Brian C. Lane wrote: > On Fri, Dec 09, 2022 at 09:30:29AM -0500, Ray Strode wrote: > > Hi, > > > > On Thu, Dec 8, 2022 at 2:55 PM Adam Williamson > > wrote: > > > This is the direction Daniel was thinking down. I'm waiting for someone > > > with more expertise to reply, but I suspect the reply is going to be > > > along the lines of "yes, we *can* do that, but it's somewhat tricky > > > work that involves thinking about lots of paths that aren't obvious, > > > and somebody would need to dedicate their time to working on that". > > Presumably we could package the firmware separately and just unpack it > > into place from a udev rule when the hardware is detected? > > > > But first, do we actually know this is a problem? > > I think you're saying squashfs loads the whole decompressed image into > > memory, but my expectation prior to your mail was that it performs I/O > > on the usb stick (with a cache in between). If my intuition was right > > and files only hit ram when accessed, then it seems like this is > > pretty much not an issue, right? > > > > Do you have stats on memory usage when running in a live environment? > > Your intuition is correct, if you boot from an ISO, USB, or NFS the > squashfs image is not read into memory. If you are PXE booting (without > using NFS for stage2) then it all goes into RAM. > > Loading firmware off the iso later isn't going to help things :) Thanks for the correction. So, image size and memory usage are only correlated in the specific case of a PXE install with no NFS? In that case, this is overall probably less important than I thought it was initially. Sorry for the error. In that case I guess we could be rather more relaxed about the size. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Fri, Dec 09, 2022 at 09:30:29AM -0500, Ray Strode wrote: > Hi, > > On Thu, Dec 8, 2022 at 2:55 PM Adam Williamson > wrote: > > This is the direction Daniel was thinking down. I'm waiting for someone > > with more expertise to reply, but I suspect the reply is going to be > > along the lines of "yes, we *can* do that, but it's somewhat tricky > > work that involves thinking about lots of paths that aren't obvious, > > and somebody would need to dedicate their time to working on that". > Presumably we could package the firmware separately and just unpack it > into place from a udev rule when the hardware is detected? > > But first, do we actually know this is a problem? > I think you're saying squashfs loads the whole decompressed image into > memory, but my expectation prior to your mail was that it performs I/O > on the usb stick (with a cache in between). If my intuition was right > and files only hit ram when accessed, then it seems like this is > pretty much not an issue, right? > > Do you have stats on memory usage when running in a live environment? Your intuition is correct, if you boot from an ISO, USB, or NFS the squashfs image is not read into memory. If you are PXE booting (without using NFS for stage2) then it all goes into RAM. Loading firmware off the iso later isn't going to help things :) Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ 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: Small rant: installer environment size
On Thu, Dec 08, 2022 at 02:17:22PM -0600, Chris Adams wrote: > Once upon a time, Adam Williamson said: > > This is the direction Daniel was thinking down. I'm waiting for someone > > with more expertise to reply, but I suspect the reply is going to be > > along the lines of "yes, we *can* do that, but it's somewhat tricky > > work that involves thinking about lots of paths that aren't obvious, > > and somebody would need to dedicate their time to working on that". > > One other thing that I noticed a while back that takes up a chunk of > space is the kernel... it's included inside install.img (in two places > even, although I assume it's hardlinked?), even though it has to have > already been loaded before install.img can be read. What two places? On rawhide we have one on the iso under /images/pxeboot/ and another inside the install.img under /usr/lib/modules... I think I tried removing the kernel from the install.img at one point, but it ended up being required for FIPS (see https://github.com/weldr/lorax/issues/1021). And when there were 2 kernels on the iso they were hardlinked (one under pxeboot and the other under isolinux). Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ 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] Retirement of findbugs-bcel in EPEL 7
Hi all, A couple of weeks ago I announced my intention to retire findbugs-bcel in EPEL 7: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/4VFERXQN6Y6TTVFI45JLX2O6SYLY6ELT/ This was approved by the EPEL Steering Committee on Wednesday: https://pagure.io/epel/issue/210 I'm therefore announcing that I will be retiring the package. I doubt anyone is using this package in EPEL 7 (FindBugs itself was never packaged for EPEL 7) - but in any case, it is still available from Maven Central. Regards, Richard -- Richard Fearn richardfe...@gmail.com ___ 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: Small rant: installer environment size
On Fri, 2022-12-09 at 20:33 +0100, drago01 wrote: > On Friday, December 9, 2022, Adam Williamson > wrote: > > > On Fri, 2022-12-09 at 12:04 +0100, Florian Weimer wrote: > > > * Richard W. M. Jones: > > > > > > > You only need network / wifi firmware blobs (although I'm sure they > > > > are in themselves large) and then you can fetch anything else needed > > > > for the hardware including graphics, right? > > > > > > I think you need graphics to set up wifi. > > > > Yeah, this is an awkward chicken-and-egg problem. Even if we assume > > you're on a wired network, kernel modules generally - AIUI - try to > > load the firmware once, on initial module load, and if they can't find > > it, just give up, right? So we still have an ordering problem: how can > > we delay the loading of modules that need firmware until the network is > > up for us to be able to access the firmware files? > > > > Maybe I'm missing something that would help there, but it seems > > tricky... > > > > Looking at sizes, iwlwifi firmware alone is 75M(!) ath10k is 6.8M, > > ath11k is 12M, ath6k is 812K, so that's nearly another 20M. brcm/ is > > another 6.4M and I *think* that's all wifi. There's a few other minor > > ones, but that's a little over 100M of just wifi, with Intel by a huge > > margin the worst offender. > > > > Does anyone know anyone we can talk to at Intel about this? It's pretty > > obnoxious. > > > > In terms of what the other big space takers are in general: > > > > * amdgpu/ (AMD video cards) is ~20M > > * intel/ (mainly Intel bluetooth) is ~15M [0] > > * qed/ (some very high-end QLogic network cards) is ~10M [0] > > * i915/ (Intel video firmware) is 8.4M > > * mediatek/ is 7.7M [1] > > * qcom/ is 7.3M > > > > Then it trails off from there. Just the wifi plus those 6 things are > > around 170M, so the large majority of all the space taken. > > > > [0] No, we can't lose this - people install with Bluetooth > > mice/keyboards > > [1] For a quick win right now possibly we could assume nobody's going > > to use one of those as the interface for a Fedora install and drop > > that, not sure if it's a safe assumption > > > > It's not given that AMD wifi is rebranded mediatek, meaning it will drop > wifi for lots of newer AMD laptops. Sorry, I messed up my numbering there. That note was meant for the qed/ directory, not mediatek/ . I've been working on this this morning. I'm pretty sure we can just drop every file but one in qed/ - it contains a lot of old versions that we don't need to care about any more. We can lose some stuff from mediatek/ - not any of the wifi stuff, but there's some firmware in there for ARM SoCs we do not even build the drivers for. I found a few other little cleanups, too. I *think* we can fairly safely drop about 31M of iwlwifi firmwares from linux-firmware, I'm testing a PR for that right now. We could potentially drop even more in lorax (since we don't really need to support booting the current installer with an older kernel - that's a constraint on dropping things from the linux-firmware package too soon, as it would be a bit mean to break things for people booting older kernels on installed systems for some reason). -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Fri, Dec 09, 2022 at 03:49:08PM +0100, Miroslav Suchý wrote: > Dne 08. 12. 22 v 19:33 Adam Williamson napsal(a): > >> On that note, /usr/share/doc, /usr/share/man, and /usr/share/info could be > >> removed from the installer image if they are present. That likely won't > >> free > >> a whole lot of space, but it's not nothing. > > All of those are already stripped: > > https://github.com/weldr/lorax/blob/master/share/templates.d/99-generic/runtime-cleanup.tmpl#L69 > > Am I blind, or there is no removal of /var/cache/* ? /var/cache doesn't need to be cleaned up, it only has directories created by installing rpm packages. Remember, this is not the rootfs of a running system, it is built by installing a pile of rpms and then selectively removing bits and pieces of those rpms to try and trim the size. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ 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: Small rant: installer environment size
On Friday, December 9, 2022, Adam Williamson wrote: > On Fri, 2022-12-09 at 12:04 +0100, Florian Weimer wrote: > > * Richard W. M. Jones: > > > > > You only need network / wifi firmware blobs (although I'm sure they > > > are in themselves large) and then you can fetch anything else needed > > > for the hardware including graphics, right? > > > > I think you need graphics to set up wifi. > > Yeah, this is an awkward chicken-and-egg problem. Even if we assume > you're on a wired network, kernel modules generally - AIUI - try to > load the firmware once, on initial module load, and if they can't find > it, just give up, right? So we still have an ordering problem: how can > we delay the loading of modules that need firmware until the network is > up for us to be able to access the firmware files? > > Maybe I'm missing something that would help there, but it seems > tricky... > > Looking at sizes, iwlwifi firmware alone is 75M(!) ath10k is 6.8M, > ath11k is 12M, ath6k is 812K, so that's nearly another 20M. brcm/ is > another 6.4M and I *think* that's all wifi. There's a few other minor > ones, but that's a little over 100M of just wifi, with Intel by a huge > margin the worst offender. > > Does anyone know anyone we can talk to at Intel about this? It's pretty > obnoxious. > > In terms of what the other big space takers are in general: > > * amdgpu/ (AMD video cards) is ~20M > * intel/ (mainly Intel bluetooth) is ~15M [0] > * qed/ (some very high-end QLogic network cards) is ~10M [0] > * i915/ (Intel video firmware) is 8.4M > * mediatek/ is 7.7M [1] > * qcom/ is 7.3M > > Then it trails off from there. Just the wifi plus those 6 things are > around 170M, so the large majority of all the space taken. > > [0] No, we can't lose this - people install with Bluetooth > mice/keyboards > [1] For a quick win right now possibly we could assume nobody's going > to use one of those as the interface for a Fedora install and drop > that, not sure if it's a safe assumption > It's not given that AMD wifi is rebranded mediatek, meaning it will drop wifi for lots of newer AMD laptops. ___ 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
[Bug 2144909] perl-Log-Any-1.712 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2144909 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Log-Any-1.711 is |perl-Log-Any-1.712 is |available |available --- Comment #1 from Upstream Release Monitoring --- Releases retrieved: 1.712 Upstream release that is considered latest: 1.712 Current version/release in rawhide: 1.710-4.fc37 URL: http://search.cpan.org/dist/Log-Any/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/6480/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Log-Any -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2144909 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Fri, 2022-12-09 at 12:04 +0100, Florian Weimer wrote: > * Richard W. M. Jones: > > > You only need network / wifi firmware blobs (although I'm sure they > > are in themselves large) and then you can fetch anything else needed > > for the hardware including graphics, right? > > I think you need graphics to set up wifi. Yeah, this is an awkward chicken-and-egg problem. Even if we assume you're on a wired network, kernel modules generally - AIUI - try to load the firmware once, on initial module load, and if they can't find it, just give up, right? So we still have an ordering problem: how can we delay the loading of modules that need firmware until the network is up for us to be able to access the firmware files? Maybe I'm missing something that would help there, but it seems tricky... Looking at sizes, iwlwifi firmware alone is 75M(!) ath10k is 6.8M, ath11k is 12M, ath6k is 812K, so that's nearly another 20M. brcm/ is another 6.4M and I *think* that's all wifi. There's a few other minor ones, but that's a little over 100M of just wifi, with Intel by a huge margin the worst offender. Does anyone know anyone we can talk to at Intel about this? It's pretty obnoxious. In terms of what the other big space takers are in general: * amdgpu/ (AMD video cards) is ~20M * intel/ (mainly Intel bluetooth) is ~15M [0] * qed/ (some very high-end QLogic network cards) is ~10M [0] * i915/ (Intel video firmware) is 8.4M * mediatek/ is 7.7M [1] * qcom/ is 7.3M Then it trails off from there. Just the wifi plus those 6 things are around 170M, so the large majority of all the space taken. [0] No, we can't lose this - people install with Bluetooth mice/keyboards [1] For a quick win right now possibly we could assume nobody's going to use one of those as the interface for a Fedora install and drop that, not sure if it's a safe assumption [2] We could possibly lose a bunch of this stuff, I'll look into it -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Wed, Dec 07, 2022 at 04:41:09PM -0500, Siddhesh Poyarekar wrote: > On Wed, Dec 7, 2022 at 3:15 PM Andrii Nakryiko > wrote: > > > > > On Tue, Dec 6, 2022 at 12:56 PM Andrii Nakryiko > > > > > > > > I don't think the two are comparable at all, neither in terms of > > > potential performance impact (register pressure across an entire > > > program vs at specific API call points in some unique cases) nor in > > > terms of the benefits it provides. > > > > It's irrelevant if they are comparable. This is a system-wide change that > > has potential to cause performance regression. By how much -- not clear. > > Hand-waiving such concerns is extremely disappointing in the face of the > > scrutiny given to https://pagure.io/fesco/issue/2817. So, please get > > inspiration from that proposal and do benchmarks. > > You're basically making a political statement, so I'll just leave that > bit for FESCO to deal with. Right. I'll say right away that I will NOT ask for an additional test mass rebuild and benchmarks. The size measurements that were posted in the google docs spreadsheet are enough for me. The size change is negative for most packages, and this generally means that the execution time will not go up. (To get noticeable slowdowns the dynamic checks would need to be called often, and the instructions for a call are fairly verbose, so a large number of added runtime checks would have to be visible in the instruction count. When we get a smaller code size, this strongly implies that the compiler was able to deduce that the constrains are satisfied in more cases and actually remove checks. I know this is not a "proof", but I expect those expectation to be confirmed after we have done the mass rebuild.) There are some packages for which runtime might go up. But this is not a blocker: either they can be "fixed" to avoid the issue, or they can opt out, or we can just ignore the difference because for most programs a slowdown of 10% is completely irrelevant. So for *this* change, I think the Owner has provided enough information and justification and I'll be voting +1. We could ask the Owner to do much more benchmarking, but it wouldn't really do much except burn their time. That said, I think the same reasoning applies to -fno-omit-framepointer. The Owners of *that* change provided benchmarking that showed that the impact is negligible for most packages, and if it were to turn out that there are some packages which are noticeably negatively affected, the same fix-or-opt-out-or-ignore trifecta would be applicable. I disagree with the decision of -fno-omit-framepointer and hope we can revisit it. Nevertheless, that is not a reason to block this change. The bar was raised unreasonably high for one proposal, but instead of trying to treat the next proposal the same and block it this way, let's just return the bar to a reasonable height. 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
Re: Small rant: installer environment size
On Fri, 2022-12-09 at 15:44 +0100, mkol...@redhat.com wrote: > Or perhaps drop even the help system ? The help content has actually > not been updated in a while and does not really have an active > "upstream" - the Fedora docs moved on to a very different format, that > can no longer be used to produce the per-screen content the current > help system needs. > > So maybe dropping the help support-yelp-webkit & getting 40 MB back for > now could be worth it ? Ehhh, I dunno, it seems like such a dead-end thing to do when clearly all the effort is going into the webUI. It'd be nicer to find something that will last. But maybe if we really need the space for an upcoming release and can't find anything else to cut we could consider it. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Fri, 2022-12-09 at 14:42 +0100, Miroslav Suchý wrote: > Dne 08. 12. 22 v 17:52 Adam Williamson napsal(a): > > > No, and we're looking at splitting those out, but the fact is they are > > > a tiny amount of the overall firmware collection. You could even argue > > > either way for something like bluetooth due to it sometimes being used > > > by keyboards. > > We actually already strip a lot of those in lorax. > ... > > then, in cleanup, we wipe a bunch of files that have not yet been split > > out from linux-firmware but which we know the installer env doesn't > > need: > > > > https://github.com/weldr/lorax/blob/master/share/templates.d/99-generic/runtime-cleanup.tmpl#L201 > > Thanks for the links. Putting aside the installer image... the firmware files > mentioned in last link are not so small: > > [msuchy@dri//tmp/linux-firmware-20221109-144.fc38.noarch]$ > du-hcusr/lib/firmware/dvb*usr/lib/firmware/*_12mhz*usr/lib/firmware/v4l*usr/lib/firmware/brcm/BCM-*usr/lib/firmware/ttusb- > budget/dspbootcode.bin*usr/lib/firmware/emi26/*usr/lib/firmware/emi62/*usr/lib/firmware/cpia2/*usr/lib/firmware/dabusb/*usr/lib/firmware/vicam/*usr/lib/firmware/dsp56k/*usr/lib/firmw > are/sun/*usr/lib/firmware/av7110/*usr/lib/firmware/usbdux*usr/lib/firmware/f2255usb.bin*usr/lib/firmware/lgs8g75.fw*usr/lib/firmware/tlg2300_firmware.bin*usr/lib/firmware/s5p-mfc*us > r/lib/firmware/go7007/*usr/lib/firmware/intel/IntcSST2.bin*usr/lib/firmware/intel/fw_sst*usr/lib/firmware/intel/dsp*usr/lib/firmware/as102*usr/lib/firmware/qcom/apq8096/*usr/lib/firmw > are/qcom/sdm845/*usr/lib/firmware/qcom/sm8250/*usr/lib/firmware/qcom/venus*/*usr/lib/firmware/qcom/vpu*/*usr/lib/firmware/meson/vdec/*usr/lib/firmware/phanfw.bin* > > > 28M total > > This is about 20 % of size of linux-firmware package. Can this be moved to to > separate subpackage? Peter is the domain expert on the process of carving off chunks of linux-firmware. It's a bit of a balancing act, because you kinda need a large enough, clearly thematically-related chunk to make it worthwhile. A lot of the things in that list aren't really related to each other and aren't big enough on their own to be worth splitting out, it's a whole compendium... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Fri, 2022-12-09 at 11:12 +, Peter Robinson wrote: > On Thu, Dec 8, 2022 at 4:56 PM Adam Williamson > wrote: > > > > On Thu, 2022-12-08 at 12:58 +, Peter Robinson wrote: > > > > > > I've done a few passes, dropping a bunch of older firmware upstream > > > that are no longer supported in any stable kernel release, also a > > > bunch of de-dupe and linking of files rather than shipping of multiple > > > copies of the same firmware. It's improved things a bit, unfortunately > > > a lot of the dead firmware was tiny compared to say average modern > > > devices like GPUs or WiFI. > > > > > > The problem with a lot of the firmware, and with the new nvidia "open > > > driver" which shoves a lot of stuff into firmware in order to have an > > > upstreamable driver apparently the firmwares there are going to be > > > 30+Mb each, is that they're needed to bring up graphics/network etc to > > > even just install so I don't know how we can get around this and still > > > have a device work enough to be able to install the needed firmware > > > across the network. > > > > > > Ideas on how to solve that problem welcome. > > > > Sorry if this is way off, but - do we need the GPU firmwares to run a > > graphical install on the fallback path, just using the framebuffer set > > up by the firmware? How crazy would it be to just do that - ship the > > installer env with no GPU firmware? > > That has crossed my mind, and with simpledrm that may be more straight > forward now, but TBH it's not something I am skilled enough to deal > with, nor have the resources to test, or actually care enough about, > but the big GPU firmwares are now all split out so that should be much > more straightforward for someone with the resources to investigate. Heck, if people want to try it out, we can. I can re-run the openQA test (the old one's assets will have been garbage collected by now) and pull the ISO out and upload it somewhere, and everyone can see how it behaves on their system. maybe I'll do that later... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Non-responsive maintainer for lz4 package (pjp)
Hey folks, I've started the non-responsive maintainer procedure for pjp (https://accounts.fedoraproject.org/user/pjp/) with https://bugzilla.redhat.com/show_bug.cgi?id=2152159 I currently have a pull request that has been blocked for 4 months now: https://src.fedoraproject.org/rpms/lz4/pull-request/5 I have not checked if other pull requests or bugs are blocked. fedora-active-user (https://github.com/pypingou/fedora-active-user) reports the last action as: ``` Last action on koji: Fri, 09 Sep 2022 tag_package_owners entry created by humaton [still active] ``` I'll CC this mail to him but if you know how to reach him that will be best. Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
> On Fri, Dec 9, 2022 at 8:23 AM Timothée Ravier wrote: > Adding network-online.target is not hard, I could do that easily > enough. I would need to change the way the service starts to use a > flag instead of purely relying on firstboot mode though, since I can't > make firstboot run on, well not firstboot if I rely on systemd > firstboot. It's likely that network-online.target won't be enough on first boot if the network has not been setup in Anaconda and for EOM installations, it won't be as far as I know. I don't remember if GNOME initial setup does it or not. So you'll indeed have to try again multiple times on next boots. But how many times should it retry? If the system is never connected to the internet, should it do that every boot? That's starting to become a lot of logic for a Bash script that runs as root and performs package changes. If not in the initial setup, it could also be added to GNOME Software. In KDE in the welcome app or in Plasma Discover. > Mutating the system is sort of the point? I could just make it a no-op > for Silverblue/Kinoite, but the Workstation WG wanted it universally > applicable, so I did that legwork. We need another solution for Silverblue/Kinoite to setup those libraries post installation without relying on layering. On Silverblue & Kinoite, updates are fast when there are no package layered. If we layer a package on all installations by default, then we just make updates slow for everyone. Note that a lot of users also don't use the browser as installed in the system (we get a lot of complains about that) and install their own instead and thus won't benefit from that change. Existing/upgrading users also won't benefit from it. Using layering will also conflict / not interact well with the move to container based ostree image in F38: https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable > Aside from GNOME and KDE Plasma, nobody has an initial setup > interface. We'd have to do this in Anaconda's initial setup wizard. I > would have to build a dedicated application instead, which would > displease everyone. :) This is not the first (and won't be the last) feature that won't have an interface on non GNOME/KDE desktops. We also have https://docs.fedoraproject.org/en-US/workstation-working-group/third-party-repos/ which is set up on first boot in GNOME Initial Setup and thus not setup on KDE desktops right now. Thus I'm not sure that this should be blocking us. --- Overall, I won't oppose adding that for DNF based variants of Fedora if the working groups / desktops spin SIGs are fine with all those constraints. For Silverblue & Kinoite, I think we need another solution. ___ 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: Small rant: installer environment size
On Fri, 2022-12-09 at 10:21 -0500, Neal Gompa wrote: > On Fri, Dec 9, 2022 at 10:17 AM wrote: > > > > On Thu, 2022-12-08 at 15:42 +, Gary Buhrmaster wrote: > > > On Thu, Dec 8, 2022 at 12:31 PM Kevin Kofler via devel > > > wrote: > > > > > > > IMHO, the web-based UI is a major mistake and should never be > > > > shipped in > > > > Fedora. > > > > > > As I am sure you are aware, it seems a number of distros > > > are experimenting with their next gen installer. OpenSUSE > > > has their new web based D-installer, > > The OpenSUSE effort is very close on the library/tooling level - > > they > > also use PatternFly/React/Cockkpit to build their Web UI, pretty > > much > > like we do for the Anaconda Web UI. > > > > > and Canonical is > > > writing an installer in flutter. > > > > > > While I have not personally tried them out, so don't have > > > any real opinion in whether they are good approaches, > > > maybe eventually some of the good ideas from all the > > > distros next generations of installer will eventually cross > > > pollinate even though we likely all agree that there will > > > not be one installer to rule them all. > > Agreed! I would hope it could help with say extending PatternFly > > widgets or some Cockpit tooling to better cover some installation > > specific use cases, more people looking into library/tooling bugs > > affecting installers, etc. > > > > What I'd like to see out of this effort is some API documentation of > how the frontend (web UI) and backend (privileged services) interact > so that other frontends for Anaconda could be developed in the > future. > Eliminating desktop frontends entirely is a painful regression. :( Actually the current GTK3 GUI and even the TUI do talk to the backend over DBus. They do talk to the backend directly in a few remaining places (IIRC related to the payload handling code) but this should be also all moved to DBus in the near future. As for reference documentation of the DBus API - that's indeed on our TODO list, and definitely necessary, not just for any alternative UI efforts but also for Anaconda addon authors. > > And this new model would let us have the installer UI operate > unprivileged and use the appropriate mechanisms for privilege > escalation like any other desktop app. We are I would say already half way there, with most of the priviledged actions already taking place in the backend providing a DBus API, which the GUI still running under root mostly due to the few remaining bits of direct interaction and inertia. And some specifics of keyboard layout configuration that Jiri Konecny knows more about than me. Definitely with the Web UI the Web view app does not need to run as root. > > > > > -- > 真実はいつも一つ！/ 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 ___ 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: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
On Fri, Dec 9, 2022 at 10:46 AM wrote:
>
> On Wed, 2022-11-23 at 15:08 -0500, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/AutoFirstBootServices
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if
> > approved
> > by the Fedora Engineering Steering Committee.
> >
> >
> > == Summary ==
> > Add {{package|fedora-autofirstboot}} to desktop variants to run a
> > predetermined set of tasks on first boot after post installation,
> > notably installing codecs and cleaning up installer packages from the
> > installed system.
> >
> > == Owner ==
> > * Name: [[User:Ngompa| Neal Gompa]]
> > * Email: ngomp...@gmail.com
> >
> >
> > == Detailed Description ==
> > {{package|fedora-autofirstboot}} is a collection of scripts that
> > invoke on firstboot of a freshly installed system to run a set of
> > predetermined tasks. It also provides a framework for third-parties
> > to
> > introduce their own firstboot tasks to run through this framework.
> > The
> > initial services included are to install OpenH264 and remove
> > Anaconda.
> >
> >
> > == Benefit to Fedora ==
> > The main benefit is to smooth out the new user experience for new
> > Fedora Linux installations. In particular, we can deal with a
> > long-standing sticking point that Anaconda remains installed on the
> > user's machine when it is not useful to do so.
> Aren't some Fedora spins still using Initial Setup (not to be confused
> with Gnome Initial Setup) ? That would get it removed as well, if the
> anaconda package is uninstaled.
>
> But I guess this new tool could be hooked only after Initial Setup has
> finished running during the first boot - by which point it should by
> fine to remove Anaconda & Initial Setup from the system.
>
We only do it if the firstboot wizard is either g-i-s (GNOME) or
pico-wizard (KDE Plasma), otherwise we do nothing.
--
真実はいつも一つ！/ 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
Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
On Fri, 2022-12-09 at 13:23 +, Timothée Ravier wrote: > Sorry I'm late here but while I agree with the idea, I don't think > the implementation is done at the right level. > > As currently implemented, this will likely fail as the network won't > be available / ready: > https://pagure.io/fedora-autofirstboot/blob/main/f/systemd/fedora-autofirstboot.service IIRC that was the issue we hit when we investigated the idea to do package updates or adding language packs in the target system chroot after the Live iso base layer has been rsynced to the disk. There might not be any network conectivity at this point, as the live image is by default offline capable and thus does not require the user to setup networking before starting the installation. > > This will also mutate rpm-ostree based systems on first boot > (Silverblue & Kinoite), losing all the benefits of using a single > image for everyone and making the update slower for everyone by > default. > > I think that this is better implemented in a per-desktop app on first > session startup on in the GNOME initial setup interface or > corresponding project for other desktops. > > Having that done in a user visible interface will also surface errors > where in this current implementation, any error will mostly be > silently ignored. > ___ > 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: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
On Wed, 2022-11-23 at 15:08 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/AutoFirstBootServices
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if
> approved
> by the Fedora Engineering Steering Committee.
>
>
> == Summary ==
> Add {{package|fedora-autofirstboot}} to desktop variants to run a
> predetermined set of tasks on first boot after post installation,
> notably installing codecs and cleaning up installer packages from the
> installed system.
>
> == Owner ==
> * Name: [[User:Ngompa| Neal Gompa]]
> * Email: ngomp...@gmail.com
>
>
> == Detailed Description ==
> {{package|fedora-autofirstboot}} is a collection of scripts that
> invoke on firstboot of a freshly installed system to run a set of
> predetermined tasks. It also provides a framework for third-parties
> to
> introduce their own firstboot tasks to run through this framework.
> The
> initial services included are to install OpenH264 and remove
> Anaconda.
>
>
> == Benefit to Fedora ==
> The main benefit is to smooth out the new user experience for new
> Fedora Linux installations. In particular, we can deal with a
> long-standing sticking point that Anaconda remains installed on the
> user's machine when it is not useful to do so.
Aren't some Fedora spins still using Initial Setup (not to be confused
with Gnome Initial Setup) ? That would get it removed as well, if the
anaconda package is uninstaled.
But I guess this new tool could be hooked only after Initial Setup has
finished running during the first boot - by which point it should by
fine to remove Anaconda & Initial Setup from the system.
>
> == Scope ==
> * Proposal owners:
> ** Add {{package|fedora-autofirstboot}} to the desktop kickstarts
> ** Add a preset to {{package|fedora-release}} for
> fedora-autofirstboot.service
>
> * Other developers: N/A (not needed for this Change)
>
> * Release engineering: [https://pagure.io/releng/issue/11148 #11148]
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives: N/A
>
>
> == Upgrade/compatibility impact ==
> This will have no impact on upgraded systems, since the firstboot
> condition is not true in that case.
>
>
> == How To Test ==
>
> # Install Fedora Workstation, KDE, etc.
> # Reboot into installed environment
> # Check to see openh264 is installed and
> anaconda-core is not.
>
> == User Experience ==
> The first boot will be slightly slower because of these tasks
> running,
> though they should happily run in the background as other services
> start up, so it should not be noticeable.
>
> == Dependencies ==
> The main dependency is {{package|fedora-release}}, though we will
> need
> to ensure all {{package|udisks2}} plugins get pulled in as
> dependencies for {{package|gnome-disks}} and {{package|blivet-gui}}
> so
> they don't get uninstalled when Anaconda is.
>
>
> == Contingency Plan ==
> * Contingency mechanism: Remove {{package|fedora-autofirstboot}} from
> the kickstarts
> * Contingency deadline: Final freeze
> * Blocks release? No
>
>
> == Documentation ==
> There is not currently much documentation in
> [https://pagure.io/fedora-autofirstboot the upstream project], though
> contributions are welcome.
>
> == Release Notes ==
> Fedora Linux now ships with a framework for setting up first-boot
> services and uses this to install multimedia software and remove the
> installer software from the system after installation.
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> 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: Small rant: installer environment size
On Fri, 2022-12-09 at 11:15 +, Richard W.M. Jones wrote: > On Fri, Dec 09, 2022 at 12:04:24PM +0100, Florian Weimer wrote: > > * Richard W. M. Jones: > > > > > You only need network / wifi firmware blobs (although I'm sure > > > they > > > are in themselves large) and then you can fetch anything else > > > needed > > > for the hardware including graphics, right? > > > > I think you need graphics to set up wifi. > > I long for old school text mode installers ... At least you knew > that the tab key would always work. Well, if you pass int.text on the boot command line, Anaconda will show you the TUI - which supports a sizeable sub-set of the GUI functionality. :) > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: > http://rwmj.wordpress.com > virt-builder quickly builds VMs from scratch > http://libguestfs.org/virt-builder.1.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 ___ 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: Small rant: installer environment size
On Fri, Dec 9, 2022 at 10:17 AM wrote: > > On Thu, 2022-12-08 at 15:42 +, Gary Buhrmaster wrote: > > On Thu, Dec 8, 2022 at 12:31 PM Kevin Kofler via devel > > wrote: > > > > > IMHO, the web-based UI is a major mistake and should never be > > > shipped in > > > Fedora. > > > > As I am sure you are aware, it seems a number of distros > > are experimenting with their next gen installer. OpenSUSE > > has their new web based D-installer, > The OpenSUSE effort is very close on the library/tooling level - they > also use PatternFly/React/Cockkpit to build their Web UI, pretty much > like we do for the Anaconda Web UI. > > > and Canonical is > > writing an installer in flutter. > > > > While I have not personally tried them out, so don't have > > any real opinion in whether they are good approaches, > > maybe eventually some of the good ideas from all the > > distros next generations of installer will eventually cross > > pollinate even though we likely all agree that there will > > not be one installer to rule them all. > Agreed! I would hope it could help with say extending PatternFly > widgets or some Cockpit tooling to better cover some installation > specific use cases, more people looking into library/tooling bugs > affecting installers, etc. > What I'd like to see out of this effort is some API documentation of how the frontend (web UI) and backend (privileged services) interact so that other frontends for Anaconda could be developed in the future. Eliminating desktop frontends entirely is a painful regression. :( And this new model would let us have the installer UI operate unprivileged and use the appropriate mechanisms for privilege escalation like any other desktop app. -- 真実はいつも一つ！/ 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
Re: Small rant: installer environment size
On Thu, 2022-12-08 at 15:42 +, Gary Buhrmaster wrote: > On Thu, Dec 8, 2022 at 12:31 PM Kevin Kofler via devel > wrote: > > > IMHO, the web-based UI is a major mistake and should never be > > shipped in > > Fedora. > > As I am sure you are aware, it seems a number of distros > are experimenting with their next gen installer. OpenSUSE > has their new web based D-installer, The OpenSUSE effort is very close on the library/tooling level - they also use PatternFly/React/Cockkpit to build their Web UI, pretty much like we do for the Anaconda Web UI. > and Canonical is > writing an installer in flutter. > > While I have not personally tried them out, so don't have > any real opinion in whether they are good approaches, > maybe eventually some of the good ideas from all the > distros next generations of installer will eventually cross > pollinate even though we likely all agree that there will > not be one installer to rule them all. Agreed! I would hope it could help with say extending PatternFly widgets or some Cockpit tooling to better cover some installation specific use cases, more people looking into library/tooling bugs affecting installers, etc. > ___ > 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: Small rant: installer environment size
On Thu, 2022-12-08 at 08:53 +0100, Tomáš Popela wrote: > Hi Adam, > > On Thu, Dec 8, 2022 at 5:30 AM Adam Williamson > wrote: > > On Thu, 2022-12-08 at 03:28 +, Gary Buhrmaster wrote: > > > On Thu, Dec 8, 2022 at 12:42 AM Adam Williamson > > > wrote: > > > > > > > > Hi folks! Today I woke up and found > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2151495 , which > > diverted me > > > > down a bit of an "installer environment size" rabbit hole. > > > > > > Does the "new and improved" web based installer help this > > > in any way? > > > > I haven't looked yet but I suspect it'll probably be a wash, > > mostly. If > > anything it's likely slightly negative because the new installer > > itself > > hard requires webkitgtk, so we can't really do anything to finesse > > that > > requirement any more. With the old installer, we could maybe try > > and > > figure out some way of being able to show the help pages without > > needing yelp/webkitgtk. Since the new installer itself needs > > webkitgtk, > > seems like there's no way we're getting rid of that ~40M > > compressed. > > > > > You should also try to do this - remove webkitgtk and yelp packages > and add firefox, because that's what the web based installer > should/will use in the end - see > https://bugzilla.redhat.com/show_bug.cgi?id=2142779. We already had a > meeting with Anaconda dev and told him to use Firefox instead of > WebKitGTK for the web installer - due to resources that are > internally (and frankly in upstream as well) allocated to WebKitGTK. While the currently published Web UI preview images use GTK3 WebKit to show the Web UI locally, I did some local image build using Firefox in kiosk mode (eq. using the --kiosk CLI option): - generally works fine - performance is good, does not exhibit the high CPU consumption for UI animations GTK WebKit has on VM with no GPU acceleration - no header bar ever shown (which is what we want at the moment) - no right click context menu, no right click copy paste menu (this is usable, be if possible we would like to show the web debug console option if anaconda runs in debug mode & the missing copa paste menu could be seen as a usability issue for users) - adds about 80 MB to image size (so about +40 MB in comparison to GTK WebKit as far as I can tell - *very rough/preliminary numbers*) - the memory consumption (measured at end of the installation) seems to be slightly higher when compared to GTK WebKit BTW, just an idea - would a "Firefox minimal" build make sense ? I don't think we (and other projects in need of a lightweight Web View) would ne advanced vide playback support, Web GL, VR support and other features that certainly make the Firefox binaries bigger than necessary for the usecase. > > Tom > ___ > 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: Small rant: installer environment size
On Thu, Dec 8, 2022 at 7:31 AM Kevin Kofler via devel wrote: > > Tomáš Popela wrote: > > firefox, because that's what the web based installer should/will use in > > the end > > 臘 A full-blown, 71 MB compressed (!) web browser just to show the UI for the > installer! > > IMHO, the web-based UI is a major mistake and should never be shipped in > Fedora. It is good as a prototype, but way too resource-heavy to be shipped > in production. We need a rewrite of the UI design in a desktop toolkit. (If > GTK is not suitable, how about Qt? ☺) > While I agree with you on a Qt-based frontend over a GTK-based one, what they're doing is valuable because it splits Anaconda into a service that lets anyone implement whatever frontends they want. If we wound up having an enterprising developer interested in Fedora KDE to make a frontend for Anaconda leveraging Kirigami, we absolutely could. Will we? I don't know, probably not (at least for a while), but it might happen someday. -- 真実はいつも一つ！/ 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
Re: Small rant: installer environment size
Dne 08. 12. 22 v 19:33 Adam Williamson napsal(a): On that note, /usr/share/doc, /usr/share/man, and /usr/share/info could be removed from the installer image if they are present. That likely won't free a whole lot of space, but it's not nothing. All of those are already stripped: https://github.com/weldr/lorax/blob/master/share/templates.d/99-generic/runtime-cleanup.tmpl#L69 Am I blind, or there is no removal of /var/cache/* ? Miroslav ___ 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: Small rant: installer environment size
On Wed, 2022-12-07 at 20:19 -0800, Adam Williamson wrote: > On Thu, 2022-12-08 at 03:28 +, Gary Buhrmaster wrote: > > On Thu, Dec 8, 2022 at 12:42 AM Adam Williamson > > wrote: > > > > > > Hi folks! Today I woke up and found > > > https://bugzilla.redhat.com/show_bug.cgi?id=2151495 , which > > > diverted me > > > down a bit of an "installer environment size" rabbit hole. > > > > Does the "new and improved" web based installer help this > > in any way? > > I haven't looked yet but I suspect it'll probably be a wash, mostly. Yeah - even when we drop the actual Python/GTK3 GUI code, I don't expect the size to change much, as GTK itself will end up on the imaage anyway - GTK WebKit needs it & AFAIK Firefox also uses it to setup it window (?) and related stuff. > If > anything it's likely slightly negative because the new installer > itself > hard requires webkitgtk, so we can't really do anything to finesse > that > requirement any more. On the other hand we expect the help to be just a part of the Web UI, so no need for yelp and likely some other GUI tools (eq. that thing that shows keyboard layouts, possibly network connection editor, etc.). But yet again I would not expect huge savings there as the tools themselves are likely tiny, the main size comming from the GUI toolikt they use. > With the old installer, we could maybe try and > figure out some way of being able to show the help pages without > needing yelp/webkitgtk. Or perhaps drop even the help system ? The help content has actually not been updated in a while and does not really have an active "upstream" - the Fedora docs moved on to a very different format, that can no longer be used to produce the per-screen content the current help system needs. So maybe dropping the help support-yelp-webkit & getting 40 MB back for now could be worth it ? (With the built-in-help system in the Web UI, we plan to have the installer UI specific help content maintained as part of the Anaconda project, with easy access to documentatrists and contributors to avoid the issues with up-to-date help content. It will also solve localization issues & makes it possible to update as changes in the code happen.) > Since the new installer itself needs webkitgtk, > seems like there's no way we're getting rid of that ~40M compressed. One possible option that could work in some use cases is to also build headless images, where you would connect to the Web UI remotely - this could be very useful for SBC, as it would avoid any CPU/RAM intensive local rendering, yet having the full GUI experience available. The resulting headless image could possibly quite small without GTK,X/Wayland,WebKit/Firefox, Gnome Kiosk and their transitive deps. > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ 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: Small rant: installer environment size
Hi, On Thu, Dec 8, 2022 at 2:55 PM Adam Williamson wrote: > This is the direction Daniel was thinking down. I'm waiting for someone > with more expertise to reply, but I suspect the reply is going to be > along the lines of "yes, we *can* do that, but it's somewhat tricky > work that involves thinking about lots of paths that aren't obvious, > and somebody would need to dedicate their time to working on that". Presumably we could package the firmware separately and just unpack it into place from a udev rule when the hardware is detected? But first, do we actually know this is a problem? I think you're saying squashfs loads the whole decompressed image into memory, but my expectation prior to your mail was that it performs I/O on the usb stick (with a cache in between). If my intuition was right and files only hit ram when accessed, then it seems like this is pretty much not an issue, right? Do you have stats on memory usage when running in a live environment? ___ 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
[rpms/perl-Pod-MinimumVersion] PR #2: Package tests and update license to SPDX format
mspacek merged a pull-request against the project: `perl-Pod-MinimumVersion` that you are following. Merged pull-request: `` Package tests and update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-Pod-MinimumVersion/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
On Fri, Dec 9, 2022 at 8:23 AM Timothée Ravier wrote: > > Sorry I'm late here but while I agree with the idea, I don't think the > implementation is done at the right level. > > As currently implemented, this will likely fail as the network won't be > available / ready: > https://pagure.io/fedora-autofirstboot/blob/main/f/systemd/fedora-autofirstboot.service > Adding network-online.target is not hard, I could do that easily enough. I would need to change the way the service starts to use a flag instead of purely relying on firstboot mode though, since I can't make firstboot run on, well not firstboot if I rely on systemd firstboot. > This will also mutate rpm-ostree based systems on first boot (Silverblue & > Kinoite), losing all the benefits of using a single image for everyone and > making the update slower for everyone by default. > Mutating the system is sort of the point? I could just make it a no-op for Silverblue/Kinoite, but the Workstation WG wanted it universally applicable, so I did that legwork. > I think that this is better implemented in a per-desktop app on first session > startup on in the GNOME initial setup interface or corresponding project for > other desktops. > Aside from GNOME and KDE Plasma, nobody has an initial setup interface. We'd have to do this in Anaconda's initial setup wizard. I would have to build a dedicated application instead, which would displease everyone. :) > Having that done in a user visible interface will also surface errors where > in this current implementation, any error will mostly be silently ignored. That was intentional. -- 真実はいつも一つ！/ 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
Re: How/Where to put git_archieve.tar.gz for packaging?
On Fri, Dec 09, 2022 at 09:20:13PM +0800, Ming Lei wrote:
> Hi Richard,
>
> On Fri, Dec 09, 2022 at 08:22:41AM +, Richard W.M. Jones wrote:
> > On Fri, Dec 09, 2022 at 04:12:18PM +0800, Ming Lei wrote:
> > > Hello Richard and Guys,
> > >
> > > I am trying to figure out one PR for ubdsrv to sync with upstream.
> > >
> > > I found the following change in history update:
> > >
> > > commit 2ab1e571717a13edddc572269608e918e449a3b8 (origin/main)
> > > Author: Richard W.M. Jones
> > > Date: Thu Nov 3 11:33:42 2022 +
> > >
> > > Move to a newer tag (1.0-rc3 + a couple of upstream patches)
> > >
> > > diff --git a/sources b/sources
> > > index 47e83d8..1735716 100644
> > > --- a/sources
> > > +++ b/sources
> > > @@ -1 +1 @@
> > > -SHA512 (ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz) =
> > > a12e218b6d97631b9726cdaa2e14dfb7f4df422dd77265701f40ba8704c7d4ccac6c632f635115863f8694bd626f06f67e2ebdf93ae92778a0dae3cddb0259c6
> > > +SHA512 (ubdsrv-ca8baff898868f2ee6f5cdda9c16cf8d94435262.tar.gz) =
> > > 9d85271cc73026e7ff8a58153cffb4fd9f760c136d790e0b681cd6b903813cd9d9b98bba934c7ef1248ee0514fe7a6967d3ee65afd6cc44ea0bd3a0796c62ff3
> > > diff --git a/ubdsrv.spec b/ubdsrv.spec
> >
> > These are generated by me running "fedpkg sources". I don't believe
> > it's possible for non-packagers to use this (since it actually uploads
> > the file to Fedora servers), but in any case it doesn't matter, just
> > make a note of the new commit has you want to use when creating the PR.
>
> I just created PR#2 for sync ubdsrv with upstream commit
> 483d710ab8630304d13b59c2776f7386a566c467, and one new public header
> is added.
I've merged this and will do an updated build shortly.
> Also nbdublk needs to sync with this API change, which is basically
> stable now, and the attached patch is verified, please update nbdublk
> too.
Fixed in:
https://gitlab.com/nbdkit/libnbd/-/commit/7a402ab853f480245767d72ae2f61e880893ea4d
Rich.
>
> thanks,
> Ming
> diff --git a/ublk/nbdublk.c b/ublk/nbdublk.c
> index 53af840..00aa23e 100644
> --- a/ublk/nbdublk.c
> +++ b/ublk/nbdublk.c
> @@ -166,6 +166,7 @@ main (int argc, char *argv[])
>uint64_t max_block_size;
>const char *s;
>struct ublksrv_dev_data data = { .dev_id = -1 };
> + const struct ublksrv_ctrl_dev_info *dinfo;
>struct sigaction sa = { 0 };
>
>for (;;) {
> @@ -420,6 +421,8 @@ main (int argc, char *argv[])
> exit (EXIT_FAILURE);
>}
>
> + dinfo = ublksrv_ctrl_get_dev_info(dev);
> +
>/* Register signal handlers to try to stop the device. */
>sa.sa_handler = signal_handler;
>sigaction (SIGHUP, , NULL);
> @@ -432,14 +435,14 @@ main (int argc, char *argv[])
>if (r < 0) {
> errno = -r;
> fprintf (stderr, "%s: ublksrv_ctrl_add_dev: "DEVICE_PREFIX "%d: %m\n",
> - argv[0], dev->dev_info.dev_id);
> + argv[0], dinfo->dev_id);
> ublksrv_ctrl_deinit (dev);
> exit (EXIT_FAILURE);
>}
>
>if (verbose)
> fprintf (stderr, "%s: created %s%d\n",
> - argv[0], DEVICE_PREFIX, dev->dev_info.dev_id);
> + argv[0], DEVICE_PREFIX, dinfo->dev_id);
>
>/* XXX nbdfuse creates a pid file. However I reason that you can
> * tell if the service is available when the block device is created
> diff --git a/ublk/tgt.c b/ublk/tgt.c
> index e25e072..3fb2223 100644
> --- a/ublk/tgt.c
> +++ b/ublk/tgt.c
> @@ -33,6 +33,7 @@
> #define _Atomic /**/
> #endif
>
> +#include
> #include
> #include
>
> @@ -53,7 +54,7 @@
> * The thread_info entry is shared between each pair of threads.
> */
> struct thread_info {
> - struct ublksrv_dev *dev;
> + const struct ublksrv_dev *dev;
>size_t i; /* index into nbd.ptr[], also q_id */
>pthread_t io_uring_thread;
>pthread_t nbd_work_thread;
> @@ -208,7 +209,7 @@ nbd_work_thread (void *vpinfo)
>
> ublksrv_aio_complete_worker (aio_ctx, );
>
> -if (nbd_poll2 (h, aio_ctx->efd, -1) == -1) {
> +if (nbd_poll2 (h, ublksrv_aio_get_efd(aio_ctx), -1) == -1) {
>fprintf (stderr, "%s\n", nbd_get_error ());
>exit (EXIT_FAILURE);
> }
> @@ -221,15 +222,17 @@ static void *
> io_uring_thread (void *vpinfo)
> {
>struct thread_info *thread_info = vpinfo;
> - struct ublksrv_dev *dev = thread_info->dev;
> - const unsigned dev_id = dev->ctrl_dev->dev_info.dev_id;
> + const struct ublksrv_dev *dev = thread_info->dev;
> + const struct ublksrv_ctrl_dev *cdev = ublksrv_get_ctrl_dev(dev);
> + const struct ublksrv_ctrl_dev_info *dinfo =
> ublksrv_ctrl_get_dev_info(cdev);
> + const unsigned dev_id = dinfo->dev_id;
>const size_t q_id = thread_info->i;
> - struct ublksrv_queue *q;
> + const struct ublksrv_queue *q;
>int r;
> + int tid = gettid();
>
>pthread_mutex_lock (_lock);
> - ublksrv_json_write_queue_info (dev->ctrl_dev, jbuf, sizeof jbuf,
> - q_id, gettid ());
> +
Re: Strange FTBS
Am 09.12.22 um 11:53 schrieb Mamoru TASAKA: Ralf Corsépius wrote on 2022/12/09 19:01: Hi, I am facing a FTBS when trying to rebuild povray due to SPDX-changes: Not sure this is povray side bug or SDL2 side bug. Neither am I ;) Another observation: Fedora 37's last successful build's build.log [1] contains this log message: ... [Parsing...] == error: XDG_RUNTIME_DIR not set in the environment. Couldn't initialize SDL: No available video device. ... The same part in current build attempts build.logs contain this [Parsing...] == error: XDG_RUNTIME_DIR is invalid or not set in the environment. libEGL warning: MESA-LOADER: failed to open swrast: /usr/lib64/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri) [many more identica libEGL warnings] ... So, ... no SDL warning this time, but one from mesa/libEGL. From what I can gather, formerly, "make check" seems to have failed hard as running povray failed to open SDL. Now, povray starts and waits for input (AFAICT, mouse input is necessary and keyboard input doesn't work at all ;) Makes me think there are several bugs interacting. A packaging bug/dependency issue involving libEGL/mesa, a bug in SDL (keyboard input) and a povray issue. Ralf [1] https://kojipkgs.fedoraproject.org//packages/povray/3.7.0.10/7.fc37/data/logs/x86_64/build.log) ___ 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: Small rant: installer environment size
Dne 08. 12. 22 v 17:52 Adam Williamson napsal(a): No, and we're looking at splitting those out, but the fact is they are a tiny amount of the overall firmware collection. You could even argue either way for something like bluetooth due to it sometimes being used by keyboards. We actually already strip a lot of those in lorax. ... then, in cleanup, we wipe a bunch of files that have not yet been split out from linux-firmware but which we know the installer env doesn't need: https://github.com/weldr/lorax/blob/master/share/templates.d/99-generic/runtime-cleanup.tmpl#L201 Thanks for the links. Putting aside the installer image... the firmware files mentioned in last link are not so small: [msuchy@dri//tmp/linux-firmware-20221109-144.fc38.noarch]$ du-hcusr/lib/firmware/dvb*usr/lib/firmware/*_12mhz*usr/lib/firmware/v4l*usr/lib/firmware/brcm/BCM-*usr/lib/firmware/ttusb- budget/dspbootcode.bin*usr/lib/firmware/emi26/*usr/lib/firmware/emi62/*usr/lib/firmware/cpia2/*usr/lib/firmware/dabusb/*usr/lib/firmware/vicam/*usr/lib/firmware/dsp56k/*usr/lib/firmw are/sun/*usr/lib/firmware/av7110/*usr/lib/firmware/usbdux*usr/lib/firmware/f2255usb.bin*usr/lib/firmware/lgs8g75.fw*usr/lib/firmware/tlg2300_firmware.bin*usr/lib/firmware/s5p-mfc*us r/lib/firmware/go7007/*usr/lib/firmware/intel/IntcSST2.bin*usr/lib/firmware/intel/fw_sst*usr/lib/firmware/intel/dsp*usr/lib/firmware/as102*usr/lib/firmware/qcom/apq8096/*usr/lib/firmw are/qcom/sdm845/*usr/lib/firmware/qcom/sm8250/*usr/lib/firmware/qcom/venus*/*usr/lib/firmware/qcom/vpu*/*usr/lib/firmware/meson/vdec/*usr/lib/firmware/phanfw.bin* 28M total This is about 20 % of size of linux-firmware package. Can this be moved to to separate subpackage? ___ 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: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
Sorry I'm late here but while I agree with the idea, I don't think the implementation is done at the right level. As currently implemented, this will likely fail as the network won't be available / ready: https://pagure.io/fedora-autofirstboot/blob/main/f/systemd/fedora-autofirstboot.service This will also mutate rpm-ostree based systems on first boot (Silverblue & Kinoite), losing all the benefits of using a single image for everyone and making the update slower for everyone by default. I think that this is better implemented in a per-desktop app on first session startup on in the GNOME initial setup interface or corresponding project for other desktops. Having that done in a user visible interface will also surface errors where in this current implementation, any error will mostly be silently ignored. ___ 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/Where to put git_archieve.tar.gz for packaging?
Hi Richard,
On Fri, Dec 09, 2022 at 08:22:41AM +, Richard W.M. Jones wrote:
> On Fri, Dec 09, 2022 at 04:12:18PM +0800, Ming Lei wrote:
> > Hello Richard and Guys,
> >
> > I am trying to figure out one PR for ubdsrv to sync with upstream.
> >
> > I found the following change in history update:
> >
> > commit 2ab1e571717a13edddc572269608e918e449a3b8 (origin/main)
> > Author: Richard W.M. Jones
> > Date: Thu Nov 3 11:33:42 2022 +
> >
> > Move to a newer tag (1.0-rc3 + a couple of upstream patches)
> >
> > diff --git a/sources b/sources
> > index 47e83d8..1735716 100644
> > --- a/sources
> > +++ b/sources
> > @@ -1 +1 @@
> > -SHA512 (ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz) =
> > a12e218b6d97631b9726cdaa2e14dfb7f4df422dd77265701f40ba8704c7d4ccac6c632f635115863f8694bd626f06f67e2ebdf93ae92778a0dae3cddb0259c6
> > +SHA512 (ubdsrv-ca8baff898868f2ee6f5cdda9c16cf8d94435262.tar.gz) =
> > 9d85271cc73026e7ff8a58153cffb4fd9f760c136d790e0b681cd6b903813cd9d9b98bba934c7ef1248ee0514fe7a6967d3ee65afd6cc44ea0bd3a0796c62ff3
> > diff --git a/ubdsrv.spec b/ubdsrv.spec
>
> These are generated by me running "fedpkg sources". I don't believe
> it's possible for non-packagers to use this (since it actually uploads
> the file to Fedora servers), but in any case it doesn't matter, just
> make a note of the new commit has you want to use when creating the PR.
I just created PR#2 for sync ubdsrv with upstream commit
483d710ab8630304d13b59c2776f7386a566c467, and one new public header
is added.
Also nbdublk needs to sync with this API change, which is basically
stable now, and the attached patch is verified, please update nbdublk
too.
thanks,
Ming
diff --git a/ublk/nbdublk.c b/ublk/nbdublk.c
index 53af840..00aa23e 100644
--- a/ublk/nbdublk.c
+++ b/ublk/nbdublk.c
@@ -166,6 +166,7 @@ main (int argc, char *argv[])
uint64_t max_block_size;
const char *s;
struct ublksrv_dev_data data = { .dev_id = -1 };
+ const struct ublksrv_ctrl_dev_info *dinfo;
struct sigaction sa = { 0 };
for (;;) {
@@ -420,6 +421,8 @@ main (int argc, char *argv[])
exit (EXIT_FAILURE);
}
+ dinfo = ublksrv_ctrl_get_dev_info(dev);
+
/* Register signal handlers to try to stop the device. */
sa.sa_handler = signal_handler;
sigaction (SIGHUP, , NULL);
@@ -432,14 +435,14 @@ main (int argc, char *argv[])
if (r < 0) {
errno = -r;
fprintf (stderr, "%s: ublksrv_ctrl_add_dev: "DEVICE_PREFIX "%d: %m\n",
- argv[0], dev->dev_info.dev_id);
+ argv[0], dinfo->dev_id);
ublksrv_ctrl_deinit (dev);
exit (EXIT_FAILURE);
}
if (verbose)
fprintf (stderr, "%s: created %s%d\n",
- argv[0], DEVICE_PREFIX, dev->dev_info.dev_id);
+ argv[0], DEVICE_PREFIX, dinfo->dev_id);
/* XXX nbdfuse creates a pid file. However I reason that you can
* tell if the service is available when the block device is created
diff --git a/ublk/tgt.c b/ublk/tgt.c
index e25e072..3fb2223 100644
--- a/ublk/tgt.c
+++ b/ublk/tgt.c
@@ -33,6 +33,7 @@
#define _Atomic /**/
#endif
+#include
#include
#include
@@ -53,7 +54,7 @@
* The thread_info entry is shared between each pair of threads.
*/
struct thread_info {
- struct ublksrv_dev *dev;
+ const struct ublksrv_dev *dev;
size_t i; /* index into nbd.ptr[], also q_id */
pthread_t io_uring_thread;
pthread_t nbd_work_thread;
@@ -208,7 +209,7 @@ nbd_work_thread (void *vpinfo)
ublksrv_aio_complete_worker (aio_ctx, );
-if (nbd_poll2 (h, aio_ctx->efd, -1) == -1) {
+if (nbd_poll2 (h, ublksrv_aio_get_efd(aio_ctx), -1) == -1) {
fprintf (stderr, "%s\n", nbd_get_error ());
exit (EXIT_FAILURE);
}
@@ -221,15 +222,17 @@ static void *
io_uring_thread (void *vpinfo)
{
struct thread_info *thread_info = vpinfo;
- struct ublksrv_dev *dev = thread_info->dev;
- const unsigned dev_id = dev->ctrl_dev->dev_info.dev_id;
+ const struct ublksrv_dev *dev = thread_info->dev;
+ const struct ublksrv_ctrl_dev *cdev = ublksrv_get_ctrl_dev(dev);
+ const struct ublksrv_ctrl_dev_info *dinfo = ublksrv_ctrl_get_dev_info(cdev);
+ const unsigned dev_id = dinfo->dev_id;
const size_t q_id = thread_info->i;
- struct ublksrv_queue *q;
+ const struct ublksrv_queue *q;
int r;
+ int tid = gettid();
pthread_mutex_lock (_lock);
- ublksrv_json_write_queue_info (dev->ctrl_dev, jbuf, sizeof jbuf,
- q_id, gettid ());
+ ublksrv_json_write_queue_info (cdev, jbuf, sizeof jbuf, q_id, tid);
pthread_mutex_unlock (_lock);
q = ublksrv_queue_init (dev, q_id, NULL);
@@ -240,7 +243,7 @@ io_uring_thread (void *vpinfo)
if (verbose)
fprintf (stderr, "%s: ublk tid %d dev %d queue %d started\n",
- "nbdublk", q->tid, dev_id, q->q_id);
+ "nbdublk", tid, dev_id, q->q_id);
for (;;) {
r = ublksrv_process_io (q);
@@ -255,7 +258,7 @@
Re: How/Where to put git_archieve.tar.gz for packaging?
On 09/12/2022 09:22, Richard W.M. Jones wrote: These are generated by me running "fedpkg sources". I don't believe it's possible for non-packagers to use this (since it actually uploads the file to Fedora servers), but in any case it doesn't matter, just make a note of the new commit has you want to use when creating the PR. fedpkg new-sources --offline ./foo.tar.xz ./bar.tar.xz -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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
[rpms/perl-Pod-MinimumVersion] PR #2: Package tests and update license to SPDX format
mspacek opened a new pull-request against the project: `perl-Pod-MinimumVersion` that you are following: `` Package tests and update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Pod-MinimumVersion/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20221209.n.0 changes
OLD: Fedora-Rawhide-20221208.n.0 NEW: Fedora-Rawhide-20221209.n.0 = SUMMARY = Added images:7 Dropped images: 0 Added packages: 2 Dropped packages:1 Upgraded packages: 101 Downgraded packages: 0 Size of added packages: 219.76 KiB Size of dropped packages:1.54 MiB Size of upgraded packages: 1.43 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -580.82 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20221209.n.0.ppc64le.tar.xz Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20221209.n.0.s390x.tar.xz Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20221209.n.0.s390x.tar.xz Image: Container_Minimal_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Minimal-Base-Rawhide-20221209.n.0.x86_64.tar.xz Image: Container_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Base-Rawhide-20221209.n.0.aarch64.tar.xz Image: Container_Minimal_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20221209.n.0.aarch64.tar.xz Image: Container_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Base-Rawhide-20221209.n.0.x86_64.tar.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: python-flake8-comprehensions-3.10.1-3.fc38 Summary: Flake8 plugin that helps you write better list/set/dict comprehensions RPMs:python3-flake8-comprehensions Size:22.84 KiB Package: python-pylero-0.0.4-1.fc38 Summary: Python SDK for Polarion RPMs:python3-pylero Size:196.92 KiB = DROPPED PACKAGES = Package: opencolorio1-1.1.1-3.fc37 Summary: Enables color transforms and image display across graphics apps RPMs:opencolorio1 opencolorio1-devel Size:1.54 MiB = UPGRADED PACKAGES = Package: R-gert-1.9.0-2.fc38 Old package: R-gert-1.9.0-1.fc38 Summary: Simple Git Client for R RPMs: R-gert Size: 1.12 MiB Size change: 422 B Changelog: * Fri Dec 09 2022 Pete Walter - 1.9.0-2 - Rebuild for libgit2 1.4 Package: R-git2r-0.30.1-2.fc38 Old package: R-git2r-0.30.1-1.fc38 Summary: Provides Access to Git Repositories RPMs: R-git2r Size: 1.98 MiB Size change: -1.01 KiB Changelog: * Fri Dec 09 2022 Pete Walter - 0.30.1-2 - Rebuild for libgit2 1.4 Package: annobin-10.94-1.fc38 Old package: annobin-10.92-1.fc38 Summary: Annotate and examine compiled binary files RPMs: annobin-annocheck annobin-docs annobin-libannocheck annobin-plugin-clang annobin-plugin-gcc annobin-plugin-llvm Size: 4.86 MiB Size change: -6.76 KiB Changelog: * Wed Nov 23 2022 Nick Clifton - 10.93-1 - Annocheck: Provide more information when a test is skipped because the file being tested was not compiled. * Wed Nov 30 2022 Nick Clifton - 10.94-1 - Annocheck: Better detection of binaries which do not contain code. (#2144533) Package: asahi-installer-0.5.2-1.fc38 Old package: asahi-installer-0.5pre9-1.fc38 Summary: Asahi Linux installer RPMs: python3-asahi_firmware Size: 140.23 KiB Size change: 73 B Changelog: * Fri Dec 09 2022 Davide Cavalca 0.5.2-1 - Update to 0.5.2; Fixes: RHBZ#2142330 Package: asahi-scripts-20221206-1.fc38 Old package: asahi-scripts-20221129-1.fc38 Summary: Miscellaneous admin scripts for Asahi Linux RPMs: asahi-fwextract asahi-scripts dracut-asahi linux-firmware-vendor update-m1n1 Size: 56.55 KiB Size change: 1.83 KiB Changelog: * Fri Dec 09 2022 Davide Cavalca 20221206-1 - Update to 20221206; Fixes: RHBZ#2151445 Package: autossh-1.4g-10.fc38 Old package: autossh-1.4g-9.fc37 Summary: Utility to autorestart SSH tunnels RPMs: autossh Size: 142.65 KiB Size change: -37 B Changelog: * Wed Dec 07 2022 Peter Fordham - 1.4g-10 - Port configure script to C99. Package: awscli-1.27.26-1.fc38 Old package: awscli-1.27.25-1.fc38 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 3.24 MiB Size change: -2.11 KiB Changelog: * Thu Dec 08 2022 Gwyn Ciesla - 1.27.26-1 - 1.27.26 Package: beecrypt-4.2.1-31.fc38 Old package: beecrypt-4.2.1-30.fc37 Summary: Open source cryptography library RPMs: beecrypt beecrypt-apidocs beecrypt-devel Size: 17.59 MiB Size change: 373.14 KiB Changelog: * Thu Dec 08 2022 Peter Fordham - 4.2.1-31 - Fixes for C99 conformance issues. Package: binutils-2.39-6.fc38 Old package: binutils-2.39-5.fc38 Summary: A GNU collection of binary utilities RPMs: binutils binutils-devel binutils-gold binutils-gprofng Size: 63.45 MiB Size change: 96.70 KiB Changelog: * Wed Nov 23 2022 Nick Clifton - 2.39-6
[rpms/perl-POE-Test-Loops] PR #1: Update license to SPDX format
mspacek merged a pull-request against the project: `perl-POE-Test-Loops` that you are following. Merged pull-request: `` Update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-POE-Test-Loops/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Thu, Dec 8, 2022 at 5:06 PM Adam Williamson wrote: > > On Thu, 2022-12-08 at 16:51 +, Gary Buhrmaster wrote: > > On Thu, Dec 8, 2022 at 12:58 PM Peter Robinson wrote: > > > > > I've done a few passes, dropping a bunch of older firmware upstream > > > that are no longer supported in any stable kernel release, also a > > > bunch of de-dupe and linking of files rather than shipping of multiple > > > copies of the same firmware. It's improved things a bit, unfortunately > > > a lot of the dead firmware was tiny compared to say average modern > > > devices like GPUs or WiFI. > > > > > > The problem with a lot of the firmware, and with the new nvidia "open > > > driver" which shoves a lot of stuff into firmware in order to have an > > > upstreamable driver apparently the firmwares there are going to be > > > 30+Mb each, is that they're needed to bring up graphics/network etc to > > > even just install so I don't know how we can get around this and still > > > have a device work enough to be able to install the needed firmware > > > across the network. > > > > > > Ideas on how to solve that problem welcome. > > > > Does compressing the firmware using zstd (perhaps > > at an aggressive level) level help at all? > > It already *is* compressed, which is why it doesn't get any smaller in > the compressed filesystem image, unlike the other things I mentioned. > Check for yourself - look under /lib/firmware and you'll see only > things ending in .xz. And "aggressive level zstd" makes little difference TBH, and we went with XZ over zstd because of the support matrix needed actoss various pieces to support compression wasn't there, and may not be yet, I've not revisited the whole end to end process since it landed to audit all the bits since the first feature. ___ 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: Small rant: installer environment size
On Fri, Dec 09, 2022 at 12:04:24PM +0100, Florian Weimer wrote: > * Richard W. M. Jones: > > > You only need network / wifi firmware blobs (although I'm sure they > > are in themselves large) and then you can fetch anything else needed > > for the hardware including graphics, right? > > I think you need graphics to set up wifi. I long for old school text mode installers ... At least you knew that the tab key would always work. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.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
Re: Small rant: installer environment size
On Thu, Dec 8, 2022 at 4:56 PM Adam Williamson wrote: > > On Thu, 2022-12-08 at 12:58 +, Peter Robinson wrote: > > > > I've done a few passes, dropping a bunch of older firmware upstream > > that are no longer supported in any stable kernel release, also a > > bunch of de-dupe and linking of files rather than shipping of multiple > > copies of the same firmware. It's improved things a bit, unfortunately > > a lot of the dead firmware was tiny compared to say average modern > > devices like GPUs or WiFI. > > > > The problem with a lot of the firmware, and with the new nvidia "open > > driver" which shoves a lot of stuff into firmware in order to have an > > upstreamable driver apparently the firmwares there are going to be > > 30+Mb each, is that they're needed to bring up graphics/network etc to > > even just install so I don't know how we can get around this and still > > have a device work enough to be able to install the needed firmware > > across the network. > > > > Ideas on how to solve that problem welcome. > > Sorry if this is way off, but - do we need the GPU firmwares to run a > graphical install on the fallback path, just using the framebuffer set > up by the firmware? How crazy would it be to just do that - ship the > installer env with no GPU firmware? That has crossed my mind, and with simpledrm that may be more straight forward now, but TBH it's not something I am skilled enough to deal with, nor have the resources to test, or actually care enough about, but the big GPU firmwares are now all split out so that should be much more straightforward for someone with the resources to investigate. ___ 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
[rpms/perl-POE-Test-Loops] PR #1: Update license to SPDX format
mspacek opened a new pull-request against the project: `perl-POE-Test-Loops` that you are following: `` Update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-POE-Test-Loops/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-File-Listing] PR #3: Update license to SPDX format
mspacek merged a pull-request against the project: `perl-File-Listing` that you are following. Merged pull-request: `` Update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-File-Listing/pull-request/3 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
* Richard W. M. Jones: > You only need network / wifi firmware blobs (although I'm sure they > are in themselves large) and then you can fetch anything else needed > for the hardware including graphics, right? I think you need graphics to set up wifi. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How/Where to put git_archieve.tar.gz for packaging?
On Fri, Dec 09, 2022 at 06:55:43PM +0800, Ming Lei wrote: > Hi Richard, > > On Fri, Dec 09, 2022 at 08:22:41AM +, Richard W.M. Jones wrote: > > On Fri, Dec 09, 2022 at 04:12:18PM +0800, Ming Lei wrote: > > > Hello Richard and Guys, > > > > > > I am trying to figure out one PR for ubdsrv to sync with upstream. > > > > > > I found the following change in history update: > > > > > > commit 2ab1e571717a13edddc572269608e918e449a3b8 (origin/main) > > > Author: Richard W.M. Jones > > > Date: Thu Nov 3 11:33:42 2022 + > > > > > > Move to a newer tag (1.0-rc3 + a couple of upstream patches) > > > > > > diff --git a/sources b/sources > > > index 47e83d8..1735716 100644 > > > --- a/sources > > > +++ b/sources > > > @@ -1 +1 @@ > > > -SHA512 (ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz) = > > > a12e218b6d97631b9726cdaa2e14dfb7f4df422dd77265701f40ba8704c7d4ccac6c632f635115863f8694bd626f06f67e2ebdf93ae92778a0dae3cddb0259c6 > > > +SHA512 (ubdsrv-ca8baff898868f2ee6f5cdda9c16cf8d94435262.tar.gz) = > > > 9d85271cc73026e7ff8a58153cffb4fd9f760c136d790e0b681cd6b903813cd9d9b98bba934c7ef1248ee0514fe7a6967d3ee65afd6cc44ea0bd3a0796c62ff3 > > > diff --git a/ubdsrv.spec b/ubdsrv.spec > > > > These are generated by me running "fedpkg sources". I don't believe Clarification: I meant fedpkg new-sources > > it's possible for non-packagers to use this (since it actually uploads > > the file to Fedora servers), but in any case it doesn't matter, just > > make a note of the new commit has you want to use when creating the PR. > > OK, got it, thanks for the clarification! I will prepare one PR later. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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/Where to put git_archieve.tar.gz for packaging?
Hi Richard, On Fri, Dec 09, 2022 at 08:22:41AM +, Richard W.M. Jones wrote: > On Fri, Dec 09, 2022 at 04:12:18PM +0800, Ming Lei wrote: > > Hello Richard and Guys, > > > > I am trying to figure out one PR for ubdsrv to sync with upstream. > > > > I found the following change in history update: > > > > commit 2ab1e571717a13edddc572269608e918e449a3b8 (origin/main) > > Author: Richard W.M. Jones > > Date: Thu Nov 3 11:33:42 2022 + > > > > Move to a newer tag (1.0-rc3 + a couple of upstream patches) > > > > diff --git a/sources b/sources > > index 47e83d8..1735716 100644 > > --- a/sources > > +++ b/sources > > @@ -1 +1 @@ > > -SHA512 (ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz) = > > a12e218b6d97631b9726cdaa2e14dfb7f4df422dd77265701f40ba8704c7d4ccac6c632f635115863f8694bd626f06f67e2ebdf93ae92778a0dae3cddb0259c6 > > +SHA512 (ubdsrv-ca8baff898868f2ee6f5cdda9c16cf8d94435262.tar.gz) = > > 9d85271cc73026e7ff8a58153cffb4fd9f760c136d790e0b681cd6b903813cd9d9b98bba934c7ef1248ee0514fe7a6967d3ee65afd6cc44ea0bd3a0796c62ff3 > > diff --git a/ubdsrv.spec b/ubdsrv.spec > > These are generated by me running "fedpkg sources". I don't believe > it's possible for non-packagers to use this (since it actually uploads > the file to Fedora servers), but in any case it doesn't matter, just > make a note of the new commit has you want to use when creating the PR. OK, got it, thanks for the clarification! I will prepare one PR later. thanks, Ming ___ 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: Strange FTBS
Ralf Corsépius wrote on 2022/12/09 19:01: Hi, I am facing a FTBS when trying to rebuild povray due to SPDX-changes: - In local mock environments, building suddenly waits for keyboard input. - In koji, building seemingly hangs and never times out (I killed a build job after 48h hours. Surprising to me is, this package had built flawlessly and not seen major changes for years. Details: https://bugzilla.redhat.com/show_bug.cgi?id=2152106 Ralf ___ $ make check , expecially $ ./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240 +a0.3 +L./include is hanging. When entering mock buildroot and manually executing the above command, it is hanging with the message: [Paused] == Press a key or click the display to continue... This is UnixSDLDisplay::PauseWhenDoneNotifyStart() in unix/disp_sdl.cpp. So I guess this is related with sdl side change. Actually with SDL2-2.24.0-1.fc38.x86_64 the above does not hang, but with SDL2-2.26.0-1.fc38.x86_64 this does hang. The last successful real build on koji was using SDL2-2.0.22-3.fc37, I've comfirmed that with SDL2-2.0.22-3.fc37 the above does not hang. Not sure this is povray side bug or SDL2 side bug. Regards, Mamoru ___ 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: Small rant: installer environment size
On Thu, Dec 08, 2022 at 11:49:16AM -0800, Adam Williamson wrote: > On Thu, 2022-12-08 at 20:23 +0100, drago01 wrote: > > The problem I see here is not the presence of the firmware on the > > image, > > but the fact that it seems to be loaded into memory despite not being > > used. > > This is the direction Daniel was thinking down. I'm waiting for someone > with more expertise to reply, but I suspect the reply is going to be > along the lines of "yes, we *can* do that, but it's somewhat tricky > work that involves thinking about lots of paths that aren't obvious, > and somebody would need to dedicate their time to working on that". Split install.img into install.img + firmware.img? I think we already have support for multiple images (I see requests for updates.img when watching httpd logs while doing network installs), so the split should be easy. The somewhat more tricky part is probably to figure whenever we need the firmware or not. take care, Gerd ___ 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
[rpms/perl-File-Listing] PR #3: Update license to SPDX format
mspacek opened a new pull-request against the project: `perl-File-Listing` that you are following: `` Update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-File-Listing/pull-request/3 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Strange FTBS
Hi, I am facing a FTBS when trying to rebuild povray due to SPDX-changes: - In local mock environments, building suddenly waits for keyboard input. - In koji, building seemingly hangs and never times out (I killed a build job after 48h hours. Surprising to me is, this package had built flawlessly and not seen major changes for years. Details: https://bugzilla.redhat.com/show_bug.cgi?id=2152106 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
CPE Weekly Update - Week 49 2022
Hi everyone, This is a weekly report from the CPE (Community Platform Engineering) Team. The report could be found at https://communityblog.fedoraproject.org/cpe-weekly-update-week-49-2022/. If you want to receive weekly reports by emails in the future, please subscribe to either https://communityblog.fedoraproject.org/ or https://discussion.fedoraproject.org/c/news/commblog/61. We will stop sending them in 2023. Regards, CPE Team ___ 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: split package cgnslib-common into ui and none-ui part
Hi, Am 08.12.22 um 11:05 schrieb Sandro Mani: Hi Like so? https://koji.fedoraproject.org/koji/taskinfo?taskID=95082476 Sandro I noticed, that parts of the content have been moved. I can't do final judge on that package, as it still contains the desktop files and if refered by other app (OpenShot) it will still get installed. But if those apps change theire dependencies, I thnik it will be perfect ;) Thanks. 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
Re: Small rant: installer environment size
On Fri, Dec 09, 2022 at 08:09:42AM +, Daniel P. Berrangé wrote: > On Thu, Dec 08, 2022 at 12:54:16PM -0800, Adam Williamson wrote: > > On Thu, 2022-12-08 at 20:43 +0100, drago01 wrote: > > > On Thursday, December 8, 2022, Chris Adams wrote: > > > > > > > Once upon a time, Daniel P. Berrangé said: > > > > > On Thu, Dec 08, 2022 at 07:59:20PM +0100, drago01 wrote: > > > > > > That would be very crazy, as you will have a degraded user > > > > > > experience > > > > > > (laggy UI, wrong resolution, ...) to save a couple of megabytes that > > > > are a > > > > > > non issue for today's hardware. > > > > > > > > > > Please bear in mind the difference between bare metal and virtual > > > > > machines. The bare metal machine may have 32 GB of RAM, making a > > > > > 800 MB install image a non-issue. For a public cloud virtual machine > > > > > though, this could bump your VM sizing up 1 level from 2 GB quota > > > > > to a 4 GB RAM quota, with correspondingly higher price point. > > > > > > > > Also "today's hardware" increasingly includes small devices like > > > > Raspberry Pi. ARM devices don't typically use anaconda, but there are > > > > also small x86 based devices competing with the small ARM devices. > > > > > > > > I think the answer is "no", but I'll ask anyway: is there a way to evict > > > > all the firmware once the system is started? I'm guessing that as long > > > > as it's all in one disk image, that's not possible. Can we tack on a > > > > second disk image with use-once (at most) stuff and then drop the whole > > > > image after startup? > > > > > > > > > > Again there is no reason why everything on the disk image had to be loaded > > > into memory in the first place. Same way when you boot your installed > > > system, not everything on disk is loaded into memory. If you don't need > > > the > > > firmware, it should stay on the install media and never be loaded into > > > memory. > > > > The problem is, what is "the install media"? We don't *only* support > > installs from USB sticks and DVDs - things the installer could > > potentially access as local storage after starting up. We also do > > installs where everything is retrieved over the network - PXE installs, > > for instance. > > > > There are possible ways to finesse things even in those cases - as I > > said, Daniel started thinking them through a bit - but it's not as > > simple as just "put this stuff on the ISO and read it off that". > > It could potentially be almost that simple actually > > qemu-nbd -c https:///some.server/path/to/second.iso > mount /dev/nbd0 /mnt/second-iso > > This uses QEMU's curl driver, which will fetch blocks of the ISO > content only as they are accessed, so you're not pulling down the > whole ISO if you only read 2 files from it. > > The 'nbdkit' program can be used instead of qemu-nbd, and probably > a better choice since it can layer into all sorts of interesting > functionality that QEMU's curl layer can't offer. This, but using kernel nbd root instead of a qemu nbd file: https://rwmj.wordpress.com/2019/02/19/nbdkit-linuxdisk-plugin/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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: Small rant: installer environment size
On Thu, Dec 08, 2022 at 02:12:22PM -0600, Chris Adams wrote: > Once upon a time, drago01 said: > > Again there is no reason why everything on the disk image had to be loaded > > into memory in the first place. Same way when you boot your installed > > system, not everything on disk is loaded into memory. If you don't need the > > firmware, it should stay on the install media and never be loaded into > > memory. > > That only works for cases where there is local install media. Network > installs require downloading and image and running it from RAM. That's not really true as long as the web server supports random access and/or you use NBD or NFS root. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit ___ 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: Small rant: installer environment size
On Thu, Dec 8, 2022 at 6:45 PM Adam Williamson wrote: > On Thu, 2022-12-08 at 08:53 +0100, Tomáš Popela wrote: > > Hi Adam, > > > > On Thu, Dec 8, 2022 at 5:30 AM Adam Williamson < > adamw...@fedoraproject.org> > > wrote: > > > > > On Thu, 2022-12-08 at 03:28 +, Gary Buhrmaster wrote: > > > > On Thu, Dec 8, 2022 at 12:42 AM Adam Williamson > > > > wrote: > > > > > > > > > > Hi folks! Today I woke up and found > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2151495 , which > diverted > > > me > > > > > down a bit of an "installer environment size" rabbit hole. > > > > > > > > Does the "new and improved" web based installer help this > > > > in any way? > > > > > > I haven't looked yet but I suspect it'll probably be a wash, mostly. If > > > anything it's likely slightly negative because the new installer itself > > > hard requires webkitgtk, so we can't really do anything to finesse that > > > requirement any more. With the old installer, we could maybe try and > > > figure out some way of being able to show the help pages without > > > needing yelp/webkitgtk. Since the new installer itself needs webkitgtk, > > > seems like there's no way we're getting rid of that ~40M compressed. > > > > > > > You should also try to do this - remove webkitgtk and yelp packages and > add > > firefox, because that's what the web based installer should/will use in > the > > end - see https://bugzilla.redhat.com/show_bug.cgi?id=2142779. We > already > > had a meeting with Anaconda dev and told him to use Firefox instead of > > WebKitGTK for the web installer - due to resources that are internally > (and > > frankly in upstream as well) allocated to WebKitGTK. > > I can try that. What will Firefox run on top of? Is that decided? A > bare X server? Weston? Something else? Thanks! > I think that it will run on top of gnome-kiosk (what anaconda uses now - implemented in https://github.com/rhinstaller/anaconda/pull/3307), but I will add @Radek Vykydal here to confirm. Tom ___ 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: Small rant: installer environment size
On Wed, Dec 07, 2022 at 04:42:05PM -0800, Adam Williamson wrote: > I've moaned about the sheer amount and size of firmware blobs in other > forums before, but 214M compressed is *really* obnoxious. We must be > able to do something to clean this up (further than it's already > cleaned up - this is *after* we dropped low-hanging fruit like > enterprise switch 'firmwares' and garbage like that; most of the > remaining size seems to be huge amounts of probably-very-similar > firmware files for AMD graphics adapters and Intel wireless adapters). > I know some folks were trying to work on this (there was talk that we > could drop quite a lot of files that would only be loaded by older > kernels no longer in Fedora); any news on how far along that effort is? You only need network / wifi firmware blobs (although I'm sure they are in themselves large) and then you can fetch anything else needed for the hardware including graphics, right? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.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
Re: How/Where to put git_archieve.tar.gz for packaging?
On Fri, Dec 09, 2022 at 04:12:18PM +0800, Ming Lei wrote:
> Hello Richard and Guys,
>
> I am trying to figure out one PR for ubdsrv to sync with upstream.
>
> I found the following change in history update:
>
> commit 2ab1e571717a13edddc572269608e918e449a3b8 (origin/main)
> Author: Richard W.M. Jones
> Date: Thu Nov 3 11:33:42 2022 +
>
> Move to a newer tag (1.0-rc3 + a couple of upstream patches)
>
> diff --git a/sources b/sources
> index 47e83d8..1735716 100644
> --- a/sources
> +++ b/sources
> @@ -1 +1 @@
> -SHA512 (ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz) =
> a12e218b6d97631b9726cdaa2e14dfb7f4df422dd77265701f40ba8704c7d4ccac6c632f635115863f8694bd626f06f67e2ebdf93ae92778a0dae3cddb0259c6
> +SHA512 (ubdsrv-ca8baff898868f2ee6f5cdda9c16cf8d94435262.tar.gz) =
> 9d85271cc73026e7ff8a58153cffb4fd9f760c136d790e0b681cd6b903813cd9d9b98bba934c7ef1248ee0514fe7a6967d3ee65afd6cc44ea0bd3a0796c62ff3
> diff --git a/ubdsrv.spec b/ubdsrv.spec
These are generated by me running "fedpkg sources". I don't believe
it's possible for non-packagers to use this (since it actually uploads
the file to Fedora servers), but in any case it doesn't matter, just
make a note of the new commit has you want to use when creating the PR.
> 'fedpkg build' needs ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz
> to be
> put somethere, and I guess when I sync with upstream for ubdsrv new change,
> I need to generate ubdsrv-${GIT_HASH}.tar.gz & its sha512sum, and put it
> somewhere so that 'fedpkg' can find it and test it first.
>
> Can anyone help to share how/where to upload ubdsrv-${GIT_HASH}.tar.gz?
>
> Also I don't know how to figure out the sha512sum hash? I tried to do that for
> ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz by plain sha512sum, but
> get different result compared with the value in above commit even though the
> comment of .tar.gz is same(same prefix, same 'diff -u').
It'll be different each time because of how github generates tarballs
on the fly.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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
How/Where to put git_archieve.tar.gz for packaging?
Hello Richard and Guys,
I am trying to figure out one PR for ubdsrv to sync with upstream.
I found the following change in history update:
commit 2ab1e571717a13edddc572269608e918e449a3b8 (origin/main)
Author: Richard W.M. Jones
Date: Thu Nov 3 11:33:42 2022 +
Move to a newer tag (1.0-rc3 + a couple of upstream patches)
diff --git a/sources b/sources
index 47e83d8..1735716 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz) =
a12e218b6d97631b9726cdaa2e14dfb7f4df422dd77265701f40ba8704c7d4ccac6c632f635115863f8694bd626f06f67e2ebdf93ae92778a0dae3cddb0259c6
+SHA512 (ubdsrv-ca8baff898868f2ee6f5cdda9c16cf8d94435262.tar.gz) =
9d85271cc73026e7ff8a58153cffb4fd9f760c136d790e0b681cd6b903813cd9d9b98bba934c7ef1248ee0514fe7a6967d3ee65afd6cc44ea0bd3a0796c62ff3
diff --git a/ubdsrv.spec b/ubdsrv.spec
'fedpkg build' needs ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz to
be
put somethere, and I guess when I sync with upstream for ubdsrv new change,
I need to generate ubdsrv-${GIT_HASH}.tar.gz & its sha512sum, and put it
somewhere so that 'fedpkg' can find it and test it first.
Can anyone help to share how/where to upload ubdsrv-${GIT_HASH}.tar.gz?
Also I don't know how to figure out the sha512sum hash? I tried to do that for
ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz by plain sha512sum, but
get different result compared with the value in above commit even though the
comment of .tar.gz is same(same prefix, same 'diff -u').
Thanks,
Ming
___
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: Small rant: installer environment size
On Thu, Dec 08, 2022 at 12:54:16PM -0800, Adam Williamson wrote: > On Thu, 2022-12-08 at 20:43 +0100, drago01 wrote: > > On Thursday, December 8, 2022, Chris Adams wrote: > > > > > Once upon a time, Daniel P. Berrangé said: > > > > On Thu, Dec 08, 2022 at 07:59:20PM +0100, drago01 wrote: > > > > > That would be very crazy, as you will have a degraded user experience > > > > > (laggy UI, wrong resolution, ...) to save a couple of megabytes that > > > are a > > > > > non issue for today's hardware. > > > > > > > > Please bear in mind the difference between bare metal and virtual > > > > machines. The bare metal machine may have 32 GB of RAM, making a > > > > 800 MB install image a non-issue. For a public cloud virtual machine > > > > though, this could bump your VM sizing up 1 level from 2 GB quota > > > > to a 4 GB RAM quota, with correspondingly higher price point. > > > > > > Also "today's hardware" increasingly includes small devices like > > > Raspberry Pi. ARM devices don't typically use anaconda, but there are > > > also small x86 based devices competing with the small ARM devices. > > > > > > I think the answer is "no", but I'll ask anyway: is there a way to evict > > > all the firmware once the system is started? I'm guessing that as long > > > as it's all in one disk image, that's not possible. Can we tack on a > > > second disk image with use-once (at most) stuff and then drop the whole > > > image after startup? > > > > > > > Again there is no reason why everything on the disk image had to be loaded > > into memory in the first place. Same way when you boot your installed > > system, not everything on disk is loaded into memory. If you don't need the > > firmware, it should stay on the install media and never be loaded into > > memory. > > The problem is, what is "the install media"? We don't *only* support > installs from USB sticks and DVDs - things the installer could > potentially access as local storage after starting up. We also do > installs where everything is retrieved over the network - PXE installs, > for instance. > > There are possible ways to finesse things even in those cases - as I > said, Daniel started thinking them through a bit - but it's not as > simple as just "put this stuff on the ISO and read it off that". It could potentially be almost that simple actually qemu-nbd -c https:///some.server/path/to/second.iso mount /dev/nbd0 /mnt/second-iso This uses QEMU's curl driver, which will fetch blocks of the ISO content only as they are accessed, so you're not pulling down the whole ISO if you only read 2 files from it. The 'nbdkit' program can be used instead of qemu-nbd, and probably a better choice since it can layer into all sorts of interesting functionality that QEMU's curl layer can't offer. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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
