Re: peek package
Awesome! On 1/8/20 10:09 AM, Artem Tim wrote: vokoscreenNG packaged now. Nice to have such app available in official repos. F31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a489a2436a F30: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aa27dbce21 ___ 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 ___ 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
Re: peek package
vokoscreenNG packaged now. Nice to have such app available in official repos. F31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a489a2436a F30: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aa27dbce21 ___ 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
Re: Fedora 32 System-Wide Change proposal: Move fonts language Provides to Langpacks
Hi,
Thank you Igor for your review.
On Thu, Jan 2, 2020 at 10:52 PM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:
> I think it would be useful to mention in the change page that
> langpacks-core-* already depend on "good quality font". If that is
> already there, I apologize.
>
>
I think this is covered under "User Experience" section.
Another thing which is not mentioned on the change page is that you
> are going to drop Requires: font(:lang=…) from fontconfig (otherwise
> it is going to pull all langpacks-core-* packages).
>
>
Yes, once fontconfig updated, mass rebuild of all packages providing some
kind of "Provides: font(:lang=)" will drop that dependency.
I think this has been mentioned in Scope section.
Otherwise I'm happy with this change since this will finally solve the
> problem where you install some game like teeworlds, get some fonts
> pulled in and autoremove will never remove it since fontconfig depend
> on font(:lang=xx) and libsolv never auto-removes "alternative"
> packages. So you never remove fonts unless explicitly ask DNF to do
> so.
>
>
Regards,
Parag
On Thu, Jan 2, 2020 at 4:17 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/FontLanguageProvidesToLangpacks
> >
> > == Summary ==
> > Move `Provides: font(:lang=...)` from fonts packages into the
> > `langpacks` package,
> > giving predictable default fonts for language scripts.
> >
> > === Motivation ===
> > Currently fonts packages has auto-generated `font(:lang=...)`
> > provides, which can be used as a dependency identifier to satisfy font
> > coverage required for a certain language requirement. This is used by
> > GTK application to install missing fonts via PackageKit for example.
> > However in practice it has not been very useful since usually there
> > are assorted multiple fonts that provide the language coverage and so
> > an arbitrary fonts of unknown quality would get selected, so the
> > mechanism is not unreliable.
> >
> > This change uses instead the default fonts chosen in `langpacks` for
> > each language, to give reliable predictable default fonts for each
> > language and improve the user application experience around fonts.
> >
> > == Owner ==
> > * Name: [[User:Tagoh| Akira TAGOH]], [[User:Pnemade| Parag Nemade]]
> > * Email: ta...@redhat.com, pnem...@redhat.com
> >
> >
> > == Detailed Description ==
> > The language based metadata for fonts packages was introduced in
> > Fedora 11. The idea being to provide a mechanism to find and install
> > a font for missing glyphs through PackageKit and was useful for
> > minority languages which might be missing default installed fonts
> > packages. But the user experience was generally not terribly good.
> >
> > Users cannot predict which fonts will be installed. This often leads
> > to poor fonts choices installed, particularly for languages with too
> > many available fonts such as English, since the first font found
> > lexically will be arbitrarily chosen with gurantee of quality or
> > expected style.
> > This random dependency resolution sometimes introduces highly
> > unexpected results too - for example a font from an external
> > repository may get chosen by chance. This would be particularly
> > problematic when composing ISOs, eg when including EPEL.
> >
> > So this Changes proposal aims to improve the user experience around
> > font dependencies by moving the meta-provides the `langpacks` package
> > instead. Langpacks contains various dependencies to use for certain
> > languages, including dependencies for default fonts. so it will
> > resolve the above issues.
> >
> > Specifically speaking, currently font provides are generated like this:
> >
> > $ fc-query -f %{=pkgkit} /usr/share/fonts/dejavu/DejaVuSans.ttf
> > font(dejavusans)
> > font(:lang=aa)
> > font(:lang=ab)
> > ...
> >
> >
> > and at the build time, it is transformed to:
> >
> > Provides: font(dejavusans)
> > Provides: font(:lang=aa)
> > Provides: font(:lang=ab)
> > ...
> >
> >
> > After this proposal, the above result will be:
> >
> > Provides: font(dejavusans)
> >
> >
> > and then add `Provides: font(:lang=...)` line to corresponding
> > sub-packages langpacks-core-*.
> >
> > So asking for a font for a certain language through PackageKit will be
> > achieved by langpacks-core-* instead of a random font package.
> >
> > == Benefit to Fedora ==
> > This proposal will provide reliable, predictable, and consistent font
> > dependencies.
> >
> > == Scope ==
> > * Proposal owners:
> > ** Update fontconfig to drop `font(:lang=...)` from the alias of the
> > formatter for `%{=pkgkit}`
> > ** Add a line of `Provides: font(:lang=...)` to each
> > `langpacks-core-...`. For instance, `Provides: font(:lang=hi)` needs
> > to be added to `langpacks-core-hi`.
> >
> > * Other developers: Release Engineers needs to rebuild all fonts
> > packages with the updated fontconfig package.
> > * Release engineering: [https://pagure.io/releng/issue/9132 #9132]
> > * Policies an
Re: Big change to free maxmind GeoLite2 databases, limiting distribution
Once upon a time, Dave Dykstra said: > And whoever maintains RPM Fusion would have to ensure somehow that all > users of the rpm update within 30 days ... Seriously, I don't think > anybody can put the data up on a server with no per-user authentication > without violating the license. Not really. Basically, there's no practical way for anybody to continue to redistribute the database (I don't think RPM Fusion would/should do it, the license it not acceptable to them either). The only database that can be redistributed is the last free database, from December 2019. However, the software that uses that database can still be redistributed under Open Source licenses. Fedora could keep distributing the software, especially since it's a compile-time dependency of some things (like BIND has GeoIP functionality, but only if named is compiled against the MaxMind library). If Fedora wants to keep distributing a database, the last free version from December would be okay as a reference, although it'll get out of date over time. IMHO this seems like an over-reaction by MaxMind, but they pay their lawyers to protect them (and presumably they know the California law), so I guess that's that. IMHO if you want the right to be forgotten for your IP address' geographic location, the answer should be you don't get an Internet IP address anymore. -- 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
Re: [minimization] Feedback Pipeline feedback wanted
On Fri, 2019-12-13 at 17:13 -0800, Adam Williamson wrote: > On Fri, 2019-12-13 at 11:17 -0800, Adam Williamson wrote: > > It...*could* also work for non-candidate (i.e. nightly) Pungi 4 > > composes that have been garbage collected by retrieving the info from > > PDC, but this thread has made me realize that's a path that I've sort > > of shut off with some design choices and I need to think about how to > > open it up again. > > So count me as thoroughly nerdsniped - I spent all of today coming up > with a (somewhat icky) fix for this: > > https://pagure.io/fedora-qa/fedfind/c/3e7a261be9faf9045ac2a5b3ba648536af86b010?branch=master > > so with fedfind git master, the sample script now will also give you > date for old composes that are no longer present on any mirror, but for > which the metadata was uploaded to PDC. Try it with e.g. > Fedora-Rawhide-20171230.n.1 . > > I also thought about the 'get image sizes for old releases that are > still on the mirrors' problem a bit and came up with this: > > https://pagure.io/quick-fedora-mirror/pull-request/82 > > which basically enhances the magic file fedfind uses to *find* all the > image files from old releases to include each file's size as well; if > tibbs is OK with that change, I can enhance fedfind to use that info > and include the size in the image dicts it synthesizes for old > releases. Just to follow up on this a bit more: I'm currently sending a new fedfind release, 4.3.0, out to Bodhi with both these changes. Once it goes stable for all releases I'll ask tibbs to merge the quick-fedora- mirror PR so the real imagelist files get the size data, and then sizes for all old stable releases will be available via fedfind. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://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
Outage for 2020-01-15: Fedora Prod Environment
#8506 Planned Outage - Fedoraproject.org - 2020-01-15 21:00 UTC Opened a day ago by smooge. Modified a day ago Open Planned Outage - Fedoraproject.org - 2020-01-15 21:00 UTC There will be an outage starting at 2020-01-15 21:00UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2020-01-15 21:00UTC' Reason for outage: Update all production servers to latest kernels and glibc. Get any associated security fixes pushed into production Affected Services: All Fedora websites will see short term outages as reboots occur. Other services will be impacted during updates and reboots. Ticket Link: https://pagure.io/fedora-infrastructure/issue/8506 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. -- Stephen J Smoogen. ___ 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
Outage for 2020-01-14: Fedora Build Environment
8505 Planned Outage - Fedora Build Systems - 2020-01-14 21:00 UTC Opened a day ago by smooge. Modified 2 minutes ago Open Planned Outage - Fedora Build Systems - 2020-01-14 21:00 UTC There will be an outage starting at 2020-01-14 21:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2020-01-14 21:00UTC' Reason for outage: Update build systems to latest kernel and glibc. Get associated security fixes Affected Services: koji and related services in fedoraproject.org Ticket Link: https://pagure.io/fedora-infrastructure/issue/8505 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. -- Stephen J Smoogen. ___ 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
Outage for 2020-01-13: Fedora Infrastructure Staging Environment
#8504 Planned Outage - Fedora Staging - 2020-01-13 21:00 UTC Opened a day ago by smooge. Modified 4 hours ago Open There will be an outage starting at 2020-01-13 21:00UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2020-01-13 21:00UTC' Reason for outage: Update servers and services to newest glibc and kernels. Get any other security fixes onto systems also. Affected Services: All of *.stg.fedoraproject.org Ticket Link: https://pagure.io/fedora-infrastructure/issue/8504 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. -- Stephen J Smoogen. ___ 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Tue, Jan 7, 2020 at 1:48 PM Mark Otaris wrote: > > I intended to demonstrate that cgroups can be used to cause the kernel OOM > killer to react appropriately and fast enough, implying that replacing the > OOM killer is not necessary and that replacing it by a userspace OOM killer > that does not account for cgroups can be undesirable. The exact same controls > set with my example commands, and others, can be set with scopes as well, > so this should be applicable. > > > https://lore.kernel.org/linux-fsdevel/20200104090955.gf23...@dread.disaster.area/T/#m8b25fd42501d780d8053fc7aa9f4e3a28a19c49f > > Okay, interesting. But that’s a statement from just one person, and it has to > be interpreted in the context of what it is confirming; that is, that the OOM > killer is “mainly concerned about kernel survival in low memory situations”, > which is weaker than your claim that “their concern with kernel oom-killer is > strictly with keeping the kernel functioning”. I don’t know if the OOM > killer’s > main purpose is to keep the kernel alive (Michal Hocko appears to think so, > maybe others disagree), but it is in any case not an abuse of the OOM killer > to > also use it to keep userspace responsive, The oom killer doesn't keep user space responsive per se, in your example that's done by cgroups restricting resources. And that's neat, and necessary to keep making forward progress on. But we don't have that for unprivileged process right now, unless the user knows the secret decoder ring command to use to do this every time they run something in Terminal; and then have some idea to hint at what resources are needed for the task to succeed rather than just get clobbered anyway. That's maybe the elephant in the room with earlyoom (or one of them), yes we've recovered sooner, the user can hopefully save their data and reboot. But did their task succeed? No. It got clobbered. >and there is no reason to think that > kernel folks are not interested in helping achieve this goal. I did mean with a kernel only solution. I've been tracking this issue for 6-7 months including the congestion and kswapd discussions on-going, so I know they do care broadly about providing some mechanisms by which user space can better behave. But all of that requires varying degrees of opt-in, and quite a lot of it involves considerable work to even understand it, let alone implement it. >The only > advantage I see to earlyoom so far is that it sends SIGTERM before taking > further steps that will kill processes. Yes and it happens sooner. Probably not soon enough for many users. There may be some risk by overpromising and under delivering: by making it the default and then for the vast majority of cases it doesn't matter, because users are long since conditioned to just force power off within a minute or less of the GUI stuttering or freezing up on them. It is very workload and system specific. -- 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
I intended to demonstrate that cgroups can be used to cause the kernel OOM killer to react appropriately and fast enough, implying that replacing the OOM killer is not necessary and that replacing it by a userspace OOM killer that does not account for cgroups can be undesirable. The exact same controls set with my example commands, and others, can be set with scopes as well, so this should be applicable. > https://lore.kernel.org/linux-fsdevel/20200104090955.gf23...@dread.disaster.area/T/#m8b25fd42501d780d8053fc7aa9f4e3a28a19c49f Okay, interesting. But that’s a statement from just one person, and it has to be interpreted in the context of what it is confirming; that is, that the OOM killer is “mainly concerned about kernel survival in low memory situations”, which is weaker than your claim that “their concern with kernel oom-killer is strictly with keeping the kernel functioning”. I don’t know if the OOM killer’s main purpose is to keep the kernel alive (Michal Hocko appears to think so, maybe others disagree), but it is in any case not an abuse of the OOM killer to also use it to keep userspace responsive, and there is no reason to think that kernel folks are not interested in helping achieve this goal. The only advantage I see to earlyoom so far is that it sends SIGTERM before taking further steps that will kill processes. ___ 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
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Sun, Jan 5, 2020, at 12:08 PM, Chris Murphy wrote: > I've pretty much concluded Fedora is best off dropping the nested ext4 > in favor of plain squashfs, and using zstd. Fedora CoreOS already uses zstd for squashfs: https://github.com/coreos/coreos-assembler/blob/master/src/cmd-buildextend-installer#L57 (I'm also working to rebase Fedora Silverblue on Fedora CoreOS' toolchain and I'd like the same to happen for IoT, which would mean this proposal should more clearly call out it's affecting Fedora images that use Anaconda) ___ 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
Re: Big change to free maxmind GeoLite2 databases, limiting distribution
And whoever maintains RPM Fusion would have to ensure somehow that all users of the rpm update within 30 days ... Seriously, I don't think anybody can put the data up on a server with no per-user authentication without violating the license. Dave On Tue, Jan 07, 2020 at 05:31:48PM +0100, Kevin Kofler wrote: > Vitaly Zaitsev via devel wrote: > > In this case geolite2 packages can be moved to RPM Fusion. > > It would have to be in the nonfree section, and everything depending on it > directly or indirectly would also have to move from Fedora to RPM Fusion > nonfree. > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ 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
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Tue, Jan 7, 2020 at 4:21 PM Kevin Kofler wrote: > Kamil Paral wrote: > > Well for the general user, everything is one-time. One download, one > write > > to USB, one install. Saving a minute in one step and adding it to a > > different step doesn't really matter, it's the same sum overall (unless > > you pay considerable money for the extra downloaded data, of course). > > But the larger download will take several minutes extra even on a low-end > "broadband" connection. On slower connections, which are still standard in > parts of the world, it will take hours longer. > Sorry, but your argument is just wrong. We've had a similar discussion regarding RPM payload compression and so we know we're talking about small percent number increase by changing the compression, if any. That means a few tens of MBs for e.g. the Workstation image. And if you spend *hours* to download the extra 50 MBs, that means you're on a dial-up connection and the whole image would take you a *week* to download. This whole example is simply unrealistic. Anyone who has a problem to download extra 50-100 MBs can hardly use Fedora at all, because even the first dnf metadata update will consume exactly this amount of data, and then they will be presented with 1 GB worth of system updates. Not to mention we're talking here about removing the nested ext4 filesystem, which is likely to *reduce* the image size (and combined with changing the compression type can equal out to no change at all). It makes no sense to pre-emptively hate the discussed changes. Let's try them and then discuss the cost/benefit of the output with actual numbers in hand. ___ 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
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 7, 2020 at 12:51 PM Nicolas Mailhot via devel wrote: > > Yes, it worked because it was a press-friendly “fairy tale” story, not > because of the cash spent on marketing (or because of the quality of > the marketed product). > It's both, though. Having a good story is part of the answer, funding the telling of that story is the other part. It doesn't necessarily have to be a lot either. Imagine if we had one full-time marketing person who could work with upstreams to get their demos using Fedora. That's momentum that we can build off of. Like other parts of the project our marketing efforts have ebbed and flowed, but over the last few years in particular (despite the hard work of x3mboy, bt0dotninja, and other volunteers), we haven't had consistent marketing effort. -- 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
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
Chris Murphy wrote: > Even at 8% bigger it would be worth it. And probably 16%. I disagree. We need to stop treating bloat like a feature. And please see my other replies for why this is a particularly bad tradeoff in this particular case. > Gaining additional features, like on the fly checksumming is worth > considering (at least not making it harder to implement in the future, > by taking it into account with the work implied in this proposal). The > monolithic ISO check is terrible. It's dog slow. It's optional. And > it's a one time check. Typically real optical media tends to work or > persistently fail; whereas USB sticks can have transient bad reads > (explicit or silently corrupt). Can't we just drop the mediacheck entirely? It is optional for a reason. > Stacked images on the same media functionality is in the kernel, it's > not complicated, it's well tested, doesn't require any gymnastics in > the initramfs - your bootloader entries can each point to different > root=UUIDs and image assembly is figured out entirely in kernel code, > no special handling in the client side deliverable. Yes the image > creator needs to know some things to achieve this. > > Why stacked images? Consider a single base.img that's maybe 1G, and > now you don't have to do separate composes for server, cloud, GNOME, > KDE, Cinnamon, LXQt, Astronomy that repeat a lot of the same steps, > including expensive steps like compressing the same things over and > over again. Just do a 'dnf group install' tacked onto that base.img, > the work being done is custom for that output, rather than repetitive. > Not complicated. It would be fast enough that the high level variants > could be composed on demand. Seconds. It'd be fast enough to queue it > for download within the hour. Then how do you deliver the stacked images? Either the user still needs to download base.img + the specific image the user actually wants, either as 2 downloads (but then how does the user reliably get them onto bootable media? Surely you don't want to require 2 media!) or as 1 combined download, or you ship one image with base.img and all the specific layers at once, which will waste a lot of download size for all the images the user does not care about. I do not see what use case would be served by stacked images. What would be a much more useful feature is hybrid netinstall, i.e., allowing liveinst to netinstall additional packages on top of the installed live image. See the Calamares netinstall module (e.g., on my old Kannolo 27 images, as long as I don't have newer ones) for how the user experience can look like. And that requires only installer support, no file system or compression support. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
Gary Buhrmaster wrote: > While not exactly the same, the measured increase in size > by the Arch community for their packaging by moving from > xz to zstd was ~0.8% (and gaining a huge reduction in CPU > utilization at the decompress end). I don't know what xz settings Arch was using, but in the case of our RPMs, xz was being used with very conservative settings, mainly so that applying DeltaRPMs (which recompresses the RPMs) can be done in a reasonable time (and by the way, IIRC, the switch to zstd actually slows down that use case!), though decompression time was also a criterion. That's why switching to zstd was not a huge size increase. But we could have saved significant size by using higher xz compression rates. If Arch was using similar settings, that would explain the relatively small size increase. But it is still a size increase. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
Chris Murphy wrote: > It's untenable to consider ISO size alone. It is a legitimate concern, but > it can't be reasonable to soak every single CPU, times thousands. You're > willing to exchange less download time for longer install time and higher > energy demand, but there are quite a lot of other uses occurring that are > relevant. Downloads also require energy, on the client, on the server, on the intermediate hops, and even for the actual information transmission in the cables. So I am not convinced that you are going to save any energy by making the image significantly larger just so that it is faster to decompress. (As for the time factor, I already explained how that does not compute either, at least in large, less-privileged parts of the world.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
Brian C. Lane wrote: > Yes, according to the manpage it supports xattrs. Does that include file capabilities and ACLs? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction: Joerg Kastning
Hello Ankur, Hello Community, During the holidays I read a lot about the responsibilities and how to build and maintain a package in Fedora and EPEL. I understand that many people rely on the quality of packages maintained for a large time. And that's the reason why I have to step down. Following the discussions on the different lists and reading docs and wiki articles showed me that I do not have the time and effort to do this. All of you guys have my respect for the work you are doing here. Keep on going. @Ankur: You could go ahead and revoke the rights you gave to my FAS account. I will go on and unsubscribe and unregister my accounts as well. Best regards, Joerg On 13.12.19 16:49, Ankur Sinha wrote: > On Fri, Dec 13, 2019 13:36:58 +0100, jkastn...@my-it-brain.de wrote: >> Hello to everyone, > > Hello Joerg, > >> My name is Joerg Kastning and I'm a Sysadmin who is currently working >> for the Bielefeld University. >> >> On my carreer counter I have round about 15 years of expierience as >> Sysadmin, DevOp and IT Project Manager. Using Linux since 2009 as a >> user and working with it as a professional (more or less) since 2012. >> Some of my Open Source Projects and the ones I have contributed to, >> you could find at [0]. >> >> At the office I'm using Timewarrior (timew) to track the time I spend >> on different topics. And it came to my mind that it would be nice to >> package this software to be able to install it using the package >> manager that I know. And why build the package only for me when I >> could build it could get it into an official repository? >> >> So I did some reading [1] and have found Ankur who maintains timew for >> Fedora. I've told him that I'm eager to learn the bits of package >> building and maintainig and he agreed coaching me to become a >> co-maintainer for timew. And here I am. Looking forward to learn new >> things about the operating system I enjoy. > > Welcome to Fedora, again! > > Yes, please e-mail me whenever you need to, and please also feel free to > discuss and query the community. The sum total of knowledge the > community has is *orders* of magnitude more than mine :) > > > ___ > 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 > signature.asc Description: OpenPGP digital signature ___ 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
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Tue, Jan 07, 2020 at 09:56:21AM +0100, Kevin Kofler wrote: > Brian C. Lane wrote: > > I agree with Chris here, I think we should make the switch to plain > > squashfs unless someone can come up something dramatic that it will > > break :) > > Does SquashFS support all the advanced features that are needed, such as > extended attributes (used at least by SELinux), file system capabilities, > etc.? Yes, according to the manpage it supports xattrs. -- 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
Re: Trouble creating modular metadata for local repo
On 2020-01-07 9:05 a.m., Petr Pisar wrote: > On 2020-01-07, Digimer wrote: >> I'm trying to create a local repo of an offline collection of systems. >> When I try to install, I get: >> >> >> No available modular metadata for modular package 'foo.arch', it cannot >> be installed on the system >> >> > I guess the 'foo.arch' name is made up and it is actually a package > provided by Fedora. Because there is no such package in Fedora and thus > DNF should not suppose that the package is modular. > > Otherwise if it were a new unique yet modular package, there have to be > the "modules.yaml" file listing it. And in that case you would know what > modules are and how they are built and put into a repository. > > Could you explain us what the 'foo.arch' is in your case? > > -- Petr Since I wrote this, I've made some progress. I've taken the 'modules.yaml' file from the RHEL 8.1 ISO as a source, and now I can generate the modules.yaml file. The resolves the error for all RPMs already listed, but I am trying to add 'libssh2' without luck. I followed: https://docs.fedoraproject.org/en-US/modularity/making-modules/defining-modules/ and tried to add this; --- document: modulemd version: 2 data: name: libssh2 stream: 1.8 arch: x86_64 summary: A library implementing the SSH2 protocol description: >- libssh2 is a library implementing the SSH2 protocol as defined by Internet Drafts: SECSH-TRANS(22), SECSH-USERAUTH(25), SECSH-CONNECTION(23), SECSH-ARCH(20), SECSH-FILEXFER(06)*, SECSH-DHGEX(04), and SECSH-NUMBERS(10). license: module: - BSD dependencies: - buildrequires: platform: [] requires: platform: [] profiles: default: rpms: - libssh2 api: rpms: - libssh2 components: rpms: libssh2: rationale: Main libssh2 Package ref: latest arches: [aarch64, i686, ppc64le, s390x, x86_64] ... --- document: modulemd-defaults version: 1 data: module: libssh2 stream: 1.8 profiles: default [common] ... When I generate the modules.yaml using 'modifyrepo_c', I can see the libssh2 entries get added to the repodata/-modules.yaml.gz file. However, when I try to install, it still throws; Dependencies resolved. Package Architecture Version Repository Size Installing: libssh2 x86_64 1.8.0-8.module+el8.0.0+4084+cceb9f44.1 el8-striker01-repo 99 k Transaction Summary Install 1 Package Total download size: 99 k Installed size: 199 k Is this ok [y/N]: y Downloading Packages: libssh2-1.8.0-8.module+el8.0.0+4084+cceb9f44.1.x86_64.rpm 41 MB/s | 99 kB 00:00 Total 9.7 MB/s | 99 kB 00:00 Running transaction check No available modular metadata for modular package 'libssh2-1.8.0-8.module+el8.0.0+4084+cceb9f44.1.x86_64', it cannot be installed on the system The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: No available modular metadata for modular package I know this is RHEL 8, but the documentation is from Fedora (I can't find anything related to this regarding RHEL specifically). Hopefully I can still get help here. :) -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould ___ 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
Re: Qt 5.14 rawhide
Damian Ivanov wrote: > Qt 5.14 is out since November. According to: https://wiki.qt.io/Qt_5.14_Release final release was not until Dec 12. Patience grasshopper. -- Rex ___ 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
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Tue, Jan 7, 2020 at 9:58 AM Gary Buhrmaster wrote: > > On Tue, Jan 7, 2020 at 9:00 AM Kevin Kofler wrote: > > > I think increasing the size of the live images, also affecting the download > > time and the time to write the image to media (even USB sticks are not > > instant), to get a one-time installation speedup is a very bad tradeoff. > > While not exactly the same, the measured increase in size > by the Arch community for their packaging by moving from > xz to zstd was ~0.8% (and gaining a huge reduction in CPU > utilization at the decompress end). > > If those (approximate) numbers hold for this use case > (someone would clearly have to test to confirm or > refute those numbers) I would have to suggest that is > likely a good tradeoff that is worth further consideration. Even at 8% bigger it would be worth it. And probably 16%. Gaining additional features, like on the fly checksumming is worth considering (at least not making it harder to implement in the future, by taking it into account with the work implied in this proposal). The monolithic ISO check is terrible. It's dog slow. It's optional. And it's a one time check. Typically real optical media tends to work or persistently fail; whereas USB sticks can have transient bad reads (explicit or silently corrupt). Stacked images on the same media functionality is in the kernel, it's not complicated, it's well tested, doesn't require any gymnastics in the initramfs - your bootloader entries can each point to different root=UUIDs and image assembly is figured out entirely in kernel code, no special handling in the client side deliverable. Yes the image creator needs to know some things to achieve this. Why stacked images? Consider a single base.img that's maybe 1G, and now you don't have to do separate composes for server, cloud, GNOME, KDE, Cinnamon, LXQt, Astronomy that repeat a lot of the same steps, including expensive steps like compressing the same things over and over again. Just do a 'dnf group install' tacked onto that base.img, the work being done is custom for that output, rather than repetitive. Not complicated. It would be fast enough that the high level variants could be composed on demand. Seconds. It'd be fast enough to queue it for download within the hour. -- 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
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Tue, 2020-01-07 at 11:20 -0700, Chris Murphy wrote: > On Tue, Jan 7, 2020 at 11:07 AM Martin Kolman wrote: > > On Mon, 2020-01-06 at 16:35 -0800, Brian C. Lane wrote: > > > On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote: > > > > I've pretty much concluded Fedora is best off dropping the nested ext4 > > > > in favor of plain squashfs, and using zstd. It's not required to do > > > > both, but the benefit is additive and significant. The work in dracut > > > > and lorax to support plain squashfs, assembling it using overlayfs > > > > instead of device-mapper is already done, and tested. > > > > > > I agree with Chris here, I think we should make the switch to plain > > > squashfs unless someone can come up something dramatic that it will > > > break :) Tweaking the current settings would be fine if we didn't have a > > > better, simpler, solution. > > > > > > A side note about the xz bcj compression -- in some experiments I > > > noticed that enabling x86 and armthumb resulted in further reduction > > > (about 400k with the default block size). My guess was due to use of ARM > > > instructions in the firmware blobs. > > Also does squashfs support zstd compression ? > > Yes, that's what I was referring to in the first sentence quoted above. Oh right, now I see it. :D In any case, nice! :) > ___ 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
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Tue, Jan 7, 2020 at 11:07 AM Martin Kolman wrote: > > On Mon, 2020-01-06 at 16:35 -0800, Brian C. Lane wrote: > > On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote: > > > I've pretty much concluded Fedora is best off dropping the nested ext4 > > > in favor of plain squashfs, and using zstd. It's not required to do > > > both, but the benefit is additive and significant. The work in dracut > > > and lorax to support plain squashfs, assembling it using overlayfs > > > instead of device-mapper is already done, and tested. > > > > I agree with Chris here, I think we should make the switch to plain > > squashfs unless someone can come up something dramatic that it will > > break :) Tweaking the current settings would be fine if we didn't have a > > better, simpler, solution. > > > > A side note about the xz bcj compression -- in some experiments I > > noticed that enabling x86 and armthumb resulted in further reduction > > (about 400k with the default block size). My guess was due to use of ARM > > instructions in the firmware blobs. > Also does squashfs support zstd compression ? Yes, that's what I was referring to in the first sentence quoted above. -- 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
Re: Fedora 32 System-Wide Change proposal: iptables-nft-default
On Mon, Jan 06, 2020 at 06:02:12PM +0100, Phil Sutter wrote: > Hi Kevin, > > I just noticed we didn't finish discussing the package rename proposal > in related releng issue[1]: > > On Wed, Oct 30, 2019 at 05:02:08PM -0400, Ben Cotton wrote: > [...] > > To change the status quo, two measures are planned: > > > > === Raise priority of nft-variants in alternatives === > > > > Currently, legacy variants are installed with priority 10 and nft > > variants with priority 5. This must be changed as otherwise installing > > iptables-legacy in a system with > > iptables-nft installed would change the active > > alternative (since they are in automatic mode by default). > > > > On the other hand, existing systems using legacy variants should not > > be changed by a system update. Therefore nft variants' priorities > > should be chosen to match legacy ones. > > > > === Rename iptables package === > > > > New name should be iptables-legacy which aligns with > > ebtables and arptables and reflects upstream status. To resolve > > dependencies, Provides: iptables statement will be added > > to iptables-nft package. This should automatically change > > the default variant to nft. > > My motivation for the rename is to abstract 'iptables' keyword other > packages depend upon if they need (an implementation of) iptables. > > With matching Alternatives priorities, the first installed variant > package wins and with given lexical ordering, if both legacy and nft > variants are installed by default Alternatives will point at legacy. > > I want to avoid this (and also avoid legacy being installed if not used) > by making sure a 'Requires: iptables' in any package may be satisfied by > iptables-nft package as well. If adding 'Provides: iptables' to the > latter is sufficient, that's fine with me. That should work yeah, but also might need Obsoletes to handle upgrades? (ie, remove the old 'iptables' package in favor of 'iptables-nft') > > If my assumptions are correct, I assume there is still a 'Suggests: > iptables-nft' required in an always installed package like > fedora-release, right? Also, which package would that be? I don't see > fedora-release package being used for these things. Not that I know of, Theres several places base sort of packages get installed via: comps groups and kickstarts. It looks like iptables is in the networkmanager-submodules comps group, and I don't see it in kickstarts, but might be it's pulled via firewalld by anaconda or the like? kevin signature.asc Description: PGP signature ___ 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Tue, Jan 07, 2020 at 09:19:47AM -0600, Michael Catanzaro wrote: > On Tue, Jan 7, 2020 at 5:27 am, Mark Otaris wrote: > >Try it. With a memory limit, > > > >podman run --rm -it --memory=1G fedora bash -c 'dnf install -y > >stress-ng && stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm > >100' > > > >will use CPU but keep your system responsive. Without the memory limit > >(this will hang your system), > > > >podman run --rm -it fedora bash -c 'dnf install -y stress-ng && > >stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm 100' > > > >the system hangs and doesn’t recover after 15 minutes. > > I don't think we can use this, though; or at least, I don't see how. > systemd allows limiting the memory accessible to a scope, but it > doesn't allow carving out memory for one particular scope that is > not to be accessible to other scopes. So I don't see a way to use > these memory limits to ensure sufficient memory remains available to > critical session processes. (Am I missing something?) systemd is just a proxy for the kernel here. The kernel allows memory.min to be set, which is defined as [1] > Hard memory protection. If the memory usage of a cgroup is within > its effective min boundary, the cgroup’s memory won’t be reclaimed > under any conditions. There is also memory.low which is weaker: > Best-effort memory protection. If the memory usage of a cgroup is > within its effective low boundary, the cgroup’s memory won’t be > reclaimed unless there is no reclaimable memory available in > unprotected cgroups. I think that a combination of those two settings could be sufficient to give us appropriate memory protection for a graphical session. I envision the limits as being set using some simple formula based on the total RAM available and the desktop environment used at machine boot. [1] https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-interface-files 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
Re: Let's talk about Fedora in the '20s!
On Tue, 7 Jan 2020 at 19:03, Matthew Miller wrote: > > Red Hat has also always invested its marketing dollars in _product_; the > sponsorship of Fedora is _mostly_ from an engineering side. I'd *like* to > get more for these wider efforts, but in a very real way that Red Hat > investment is like the investment of anyone voluntarily contributing. We > each focus on the things that we care about personally. Red Hat puts some > money towards community health and growth (and funds the FCAIC position to > support that), but the main interest is in Fedora as a good RHEL upstream > from the RHEL engineering part of the company. To be known and trustworthy means more users, which means a bigger community, which means more contributors, which results in a better upstream for RHEL. :) -- Iñaki Úcar ___ 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
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Mon, 2020-01-06 at 16:35 -0800, Brian C. Lane wrote: > On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote: > > I've pretty much concluded Fedora is best off dropping the nested ext4 > > in favor of plain squashfs, and using zstd. It's not required to do > > both, but the benefit is additive and significant. The work in dracut > > and lorax to support plain squashfs, assembling it using overlayfs > > instead of device-mapper is already done, and tested. > > I agree with Chris here, I think we should make the switch to plain > squashfs unless someone can come up something dramatic that it will > break :) Tweaking the current settings would be fine if we didn't have a > better, simpler, solution. > > A side note about the xz bcj compression -- in some experiments I > noticed that enabling x86 and armthumb resulted in further reduction > (about 400k with the default block size). My guess was due to use of ARM > instructions in the firmware blobs. Also does squashfs support zstd compression ? IIRC the speedups in compression and decompression speed we got for RPMs[0] with zstd were pretty nice, so having the same for the media would be nice as well. :) [0] https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression > > -- > 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 ___ 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
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 07, 2020 at 06:48:05PM +0100, Nicolas Mailhot via devel wrote: > IBM could waste 10 times the money in marketing with less results, “Big > Blue spending loads of cash” is not a coverage-worthy story. Although to be clear if anyone from IBM is reading: _we'll take it_. :) -- Matthew Miller Fedora Project Leader ___ 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
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 07, 2020 at 11:37:28AM -0600, Joe Doss wrote: > > If anyone has a handy generous multi-millionaire up their sleeve, > > please call Matt. :) > *coughs* Red Hat... Red Hat *does* contribute millions of dollars to Fedora annually in time, hardware, and of course literal money. Disclaimer: the below is my view and opinions and I'm not speaking for Red Hat officially. I'm definitely over here on the open source side not the business side. That said: Red Hat has also always invested its marketing dollars in _product_; the sponsorship of Fedora is _mostly_ from an engineering side. I'd *like* to get more for these wider efforts, but in a very real way that Red Hat investment is like the investment of anyone voluntarily contributing. We each focus on the things that we care about personally. Red Hat puts some money towards community health and growth (and funds the FCAIC position to support that), but the main interest is in Fedora as a good RHEL upstream from the RHEL engineering part of the company. Do I think we could use money from Red Hat for marketing Fedora in a way that would ultimately benefit the company? Yes, yes I do. But this competes with, say, investment needed to close deals with large telecom providers or ineternational banks, and because Red Hat is an enterprise product company and likes near-term and *predictable* long-termreturn on investment... so, well, here we are, doing the best with what we can. Or, tl;dr: if we want to be successful as a community, we can't count on Red Hat for everything. -- Matthew Miller Fedora Project Leader ___ 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
Re: Let's talk about Fedora in the '20s!
Le mardi 07 janvier 2020 à 18:37 +0100, Clement Verna a écrit : > > > On Tue, Jan 7, 2020, 18:21 Nicolas Mailhot via devel < > devel@lists.fedoraproject.org> wrote: > > Le mardi 07 janvier 2020 à 17:14 +0100, Iñaki Ucar a écrit : > > > > > > I'm far from having a satisfactory response to that, but I see > > two > > > fronts here. First, marketing. How does Ubuntu managed to be so > > > popular among less-experienced Linux users? I'm not sure, but I > > > suspect that good marketing has something to do with it. > > > > They had good marketing in the form of a billionaire publicly > > showering > > cash around “in the public interest”. The press (especially the > > non- > > technical press) loves this kind of story. Unfortunately, it’s not > > something cheap or easy to replicate. > > In my opinion it is more about story telling rather than actual > marketing involving a big pile of cash. Yes, it worked because it was a press-friendly “fairy tale” story, not because of the cash spent on marketing (or because of the quality of the marketed product). IBM could waste 10 times the money in marketing with less results, “Big Blue spending loads of cash” is not a coverage-worthy story. -- Nicolas Mailhot ___ 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Di, 07.01.20 09:27, Michael Catanzaro (mcatanz...@gnome.org) wrote: > On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering > wrote: > > - oomd currently polls some parameters in time intervals too, > > still. They are working on getting rid of that too, so that > > everything is event based via PSI. Given their own focus on servers > > it's not a primary goal, but still a goal. > > Alexey seems really pessimistic about PSI. It looks like he expects any > solution based on PSI will fail: > > https://pagure.io/fedora-workstation/issue/98#comment-619086 > > So that seems like the most important problem right now. Looks like Benjamin > has already solved the problem of isolating apps into separate systemd > scopes. Alexey's concern about browser tabs is similarly solvable. But if > PSI in general is too difficult to configure, this plan isn't going to work. Well, I personally certainly trust Tejun to deliver if he says he'll deliver. He has a pretty good track record, and it's his explicit goal to make this stuff work. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 07, 2020 at 09:33:55AM -0800, Adam Williamson wrote: > > They had good marketing in the form of a billionaire publicly showering > > cash around “in the public interest”. The press (especially the non- > > technical press) loves this kind of story. Unfortunately, it’s not > > something cheap or easy to replicate. > If anyone has a handy generous multi-millionaire up their sleeve, > please call Matt. :) True! Phone lines are standing by! I do think that we can do some things to make a difference short of that. But it _is_ an uphill, underfunded project. -- Matthew Miller Fedora Project Leader ___ 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
Re: Let's talk about Fedora in the '20s!
On Tue, 2020-01-07 at 11:37 -0600, Joe Doss wrote: > On 1/7/20 11:33 AM, Adam Williamson wrote: > > If anyone has a handy generous multi-millionaire up their sleeve, > > please call Matt. :) > > *coughs* Red Hat... I *did* say "generous" -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://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
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 7, 2020, 18:21 Nicolas Mailhot via devel < devel@lists.fedoraproject.org> wrote: > Le mardi 07 janvier 2020 à 17:14 +0100, Iñaki Ucar a écrit : > > > > I'm far from having a satisfactory response to that, but I see two > > fronts here. First, marketing. How does Ubuntu managed to be so > > popular among less-experienced Linux users? I'm not sure, but I > > suspect that good marketing has something to do with it. > > They had good marketing in the form of a billionaire publicly showering > cash around “in the public interest”. The press (especially the non- > technical press) loves this kind of story. Unfortunately, it’s not > something cheap or easy to replicate. > In my opinion it is more about story telling rather than actual marketing involving a big pile of cash. What are the stories we can share about Fedora ? What kind of cool stuff it allows you to do ? There is very little content (blog, article, tutorials, video etc ..) based on Fedora. For example we now have modularity and I have yet to read or watch someone showing the cool stuff they did with it. I think the project needs different story to tell, for example "How Fedora can help in a DevSecOps pipeline" or "Why should I run my python microservice on Fedora" etc ... > -- > Nicolas Mailhot > ___ > 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 > ___ 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
Re: Let's talk about Fedora in the '20s!
On 1/7/20 11:33 AM, Adam Williamson wrote: > If anyone has a handy generous multi-millionaire up their sleeve, > please call Matt. :) *coughs* Red Hat... Joe -- Joe Doss j...@solidadmin.com pEpkey.asc Description: application/pgp-keys ___ 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
RE: Let's talk about Fedora in the '20s!
> > On Tue, Jan 07, 2020 at 03:22:45PM +0100, Iñaki Ucar wrote: > > > For me, the main challenge Fedora faces is **positioning**. > > > > > > Let me explain: (I don't have numbers but) in my (limited) experience, > > > when seasoned sysadmins need to launch a new system, they usually > > > think "Debian" as something reliable; when seasoned as well as > > > not-very-seasoned-in-Linux research engineers (I know better this > > > category, since I'm a researcher) need to setup a system for some demo > > > or experiment, they mostly think "Ubuntu" (yes, I know...); when we > > > see a new exciting service (such as Travis CI and the like) coming > > > out, they usually support Ubuntu; and so on and so forth, and I'm not > > > even talking about the desktop use case. > > > > > > So I think there's the challenge for Fedora, for all those people to > > > consider Fedora as a first option for their use cases. > > > > I agree that's a challenge. Any ideas for how to address it and change these > > perceptions? > > I'm far from having a satisfactory response to that, but I see two > fronts here. First, marketing. How does Ubuntu managed to be so > popular among less-experienced Linux users? I'm not sure, but I > suspect that good marketing has something to do with it. Yup, their website is pretty slick and well organized. Compare that to this: in Firefox I type fedoraproject.org and get redirected to getfedora.org. And then for docs or the wiki I get redirected to fp.o. I think there's room for improvement there to be consistent and clearly organized. Their site seems nicely tailored to their target markets so there's Marketing for ya. Admittedly they are a commercial company so that determines their look and feel too. But looking at debian.org and archlinux.org they too seem better organized (under a single domain). > Second, > exposure. If someone wants to configure a Travis CI instance, or a > Google Cloud instance for some data science pipeline, etc., etc., and > Fedora is there among the options available, then Fedora will > automatically come to mind as an option for the next project. Agree, establishing and/or improving relations with cloud providers & (embedded) hardware vendors would drive that. There's Marketing in there because you'll probably have to sell Fedora's USPs why those vendors would also want to carry Fedora or carry it as their prime distro. > Of > course that's not under our direct control, but if we know the > requirements for such third-party services, we can build specially > tailored spins and try to promote them in those > communities/projects/enterprises at all levels. > So 1) stay on the cutting edge, Yes, definitely. > 2) make it as easy as possible to choose Fedora over > other options, and That would require some market(ing) research so you know based on 'what' the choice is made. @Matthew: maybe do some research at FOSDEM? > 3) marketing and promotion may be a good recipe. Yes and frequent news releases that don't necessary focus on the technical side of things but more on meeting the needs of various target markets with a wording that non-technical people understand. Aka corporate marketing-speak :-) Best, Patrick ___ 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
Re: Let's talk about Fedora in the '20s!
On Tue, 2020-01-07 at 18:20 +0100, Nicolas Mailhot via devel wrote: > Le mardi 07 janvier 2020 à 17:14 +0100, Iñaki Ucar a écrit : > > I'm far from having a satisfactory response to that, but I see two > > fronts here. First, marketing. How does Ubuntu managed to be so > > popular among less-experienced Linux users? I'm not sure, but I > > suspect that good marketing has something to do with it. > > They had good marketing in the form of a billionaire publicly showering > cash around “in the public interest”. The press (especially the non- > technical press) loves this kind of story. Unfortunately, it’s not > something cheap or easy to replicate. If anyone has a handy generous multi-millionaire up their sleeve, please call Matt. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://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
Re: Let's talk about Fedora in the '20s!
Le mardi 07 janvier 2020 à 17:14 +0100, Iñaki Ucar a écrit : > > I'm far from having a satisfactory response to that, but I see two > fronts here. First, marketing. How does Ubuntu managed to be so > popular among less-experienced Linux users? I'm not sure, but I > suspect that good marketing has something to do with it. They had good marketing in the form of a billionaire publicly showering cash around “in the public interest”. The press (especially the non- technical press) loves this kind of story. Unfortunately, it’s not something cheap or easy to replicate. -- Nicolas Mailhot ___ 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
Orphaned Java leaf packages
Hi everybody, I've orphaned 5 packages that were previously maintained by the Stewardship SIG, but which are now no longer required by any fedora package: - jboss-transaction-1.2-api - jettison - jetty-artifact-remote-resources - jetty-assembly-descriptors - jetty-test-policy It should be safe to let them get retired in six weeks. 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
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Tue, Jan 7, 2020 at 9:00 AM Kevin Kofler wrote: > I think increasing the size of the live images, also affecting the download > time and the time to write the image to media (even USB sticks are not > instant), to get a one-time installation speedup is a very bad tradeoff. While not exactly the same, the measured increase in size by the Arch community for their packaging by moving from xz to zstd was ~0.8% (and gaining a huge reduction in CPU utilization at the decompress end). If those (approximate) numbers hold for this use case (someone would clearly have to test to confirm or refute those numbers) I would have to suggest that is likely a good tradeoff that is worth further consideration. ___ 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
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
It's untenable to consider ISO size alone. It is a legitimate concern, but it can't be reasonable to soak every single CPU, times thousands. You're willing to exchange less download time for longer install time and higher energy demand, but there are quite a lot of other uses occurring that are relevant. I don't have an immediate breakdown but RPM switching from xz to zstd increased RPM sizes somewhat, but the installation performance makes up for the extra download time. -- 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
Re: Big change to free maxmind GeoLite2 databases, limiting distribution
Vitaly Zaitsev via devel wrote: > In this case geolite2 packages can be moved to RPM Fusion. It would have to be in the nonfree section, and everything depending on it directly or indirectly would also have to move from Fedora to RPM Fusion nonfree. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Big change to free maxmind GeoLite2 databases, limiting distribution
On 07.01.2020 16:16, Kevin Kofler wrote: > To me, it looks crystal clear that the new licensing conditions are not > acceptable for Fedora. In this case geolite2 packages can be moved to RPM Fusion. -- 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
Re: Let's talk about Fedora in the '20s!
On Tue, 7 Jan 2020 at 16:38, Matthew Miller wrote: > > On Tue, Jan 07, 2020 at 03:22:45PM +0100, Iñaki Ucar wrote: > > For me, the main challenge Fedora faces is **positioning**. > > > > Let me explain: (I don't have numbers but) in my (limited) experience, > > when seasoned sysadmins need to launch a new system, they usually > > think "Debian" as something reliable; when seasoned as well as > > not-very-seasoned-in-Linux research engineers (I know better this > > category, since I'm a researcher) need to setup a system for some demo > > or experiment, they mostly think "Ubuntu" (yes, I know...); when we > > see a new exciting service (such as Travis CI and the like) coming > > out, they usually support Ubuntu; and so on and so forth, and I'm not > > even talking about the desktop use case. > > > > So I think there's the challenge for Fedora, for all those people to > > consider Fedora as a first option for their use cases. > > I agree that's a challenge. Any ideas for how to address it and change these > perceptions? I'm far from having a satisfactory response to that, but I see two fronts here. First, marketing. How does Ubuntu managed to be so popular among less-experienced Linux users? I'm not sure, but I suspect that good marketing has something to do with it. Second, exposure. If someone wants to configure a Travis CI instance, or a Google Cloud instance for some data science pipeline, etc., etc., and Fedora is there among the options available, then Fedora will automatically come to mind as an option for the next project. Of course that's not under our direct control, but if we know the requirements for such third-party services, we can build specially tailored spins and try to promote them in those communities/projects/enterprises at all levels. So 1) stay on the cutting edge, 2) make it as easy as possible to choose Fedora over other options, and 3) marketing and promotion may be a good recipe. -- Iñaki Úcar ___ 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
Re: Qt 5.14 rawhide
I asked the same thing. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JKYCD27AXOSZWVRQWOJ4NFNM7NNGM6SQ/#JKYCD27AXOSZWVRQWOJ4NFNM7NNGM6SQ Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Tue, Jan 7, 2020 at 8:55 AM Chris Murphy wrote: > > On Mon, Jan 6, 2020 at 10:28 PM Mark Otaris wrote: > > > > > For now, kernel developers have made it clear they do not care about > > > user space responsiveness. At all. Their concern with kernel > > > oom-killer is strictly with keeping the kernel functioning. > > > > This is false. The stated purpose of the OOM killer is not only to keep the > > kernel alive. > > https://lore.kernel.org/linux-fsdevel/20200104090955.gf23...@dread.disaster.area/T/#m8b25fd42501d780d8053fc7aa9f4e3a28a19c49f Sorry, that's a long email and set of threads. As it relates to the above, the phrase to search for is: "This is indeed the case." -- 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mon, Jan 6, 2020 at 10:28 PM Mark Otaris wrote: > > > For now, kernel developers have made it clear they do not care about > > user space responsiveness. At all. Their concern with kernel > > oom-killer is strictly with keeping the kernel functioning. > > This is false. The stated purpose of the OOM killer is not only to keep the > kernel alive. https://lore.kernel.org/linux-fsdevel/20200104090955.gf23...@dread.disaster.area/T/#m8b25fd42501d780d8053fc7aa9f4e3a28a19c49f >Nor does the fact the kernel has not solved userspace > responsiveness yet imply that kernel folks do not care. Rather, it means that > they will not solve it on their own because the kernel does not have all the > information it needs. Kernel folks do care, or we wouldn’t have PSI or > cgroups. OK. > > Can it be done with cgroupv2 and PSI alone? Unclear. > > Of course it can. Just run 100 instances of every stress-ng memory worker in > a podman container with a cgroup memory limit. The system will not hang. a. Not everything is running or will run in a container; b. To what degree cgroups and PSI, making no other changes, solves/avoids the problem under discussion is workload dependent. That's stated in the last part of the email response I reference above. Of course, Fedora Workstation is a general purpose operating system. It's untenable to have workload specific operating systems. By what mechanism is the workload categorized? And by what mechanism is the system dynamical (re)configured? > Try it. With a memory limit, > > podman run --rm -it --memory=1G fedora bash -c 'dnf install -y stress-ng && > stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm 100' When I ask the question "can it be done" I'm asking for cake and eating it too. I'm not asking for an example of running something that doesn't implode the system, I know about that. I want to compile something, and have the system figure out the resources it can give to that task, without killing it, and without impacting the responsivity of my computer. -- 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
Re: Let's talk about Fedora in the '20s!
> On Tue, Jan 7, 2020, at 6:41 AM, Tom Hughes wrote: > > Implicit in this is the idea that value should be captured at a secondary > distribution > layer. Implicit in this is the idea that distribution forks *need* to > happen. But they > don't. > > In fact, everyone here can work upstream too! If e.g. someone upstream > messes up > licensing, the mindset shouldn't be "oh man those upstream developers are > incompetent, let's patch it downstream". The current problem with that is that Tom and other packagers would need to join a couple of hundred up-streams and do all the emotional, social work to be considered someone they will listen to and trust to make the changes you might need to get it into a distribution. [And yes it takes time and energy to do that.. just going by how much it takes for our own development groups to take things in from random 'strangers'.] That takes up a lot of time which then cuts down the time the person has to work on Fedora. The issue is always going to be about scalability and the fact that each upstream is usually a community as much as Fedora is with its own joining/acceptance/social time needed to become active in. We have currently about 400 active packagers (depending on the definition of active) and about 22000 src.rpms usually a separate community. We either need to grow our active packagers to a much larger amount or shrink our distribution greatly OR some combination of the two. There would also need to be some duplication of people per community so we don't end up with a lot of SPOF's. [Well we have to drop being able to boot anymore.. pjones left and no one can deal with the shim community except him... but take it to every src.rpm package.] Now we could also say we outline which packages we really really care about and make sure we have upstream community liasons with.. but that will also need to scale out because every dependency of those packages would also need to be dealt with also which then grows out everytime Mozilla, Libreoffice, hot-web-app-of-the week grows a new requirement. I know I am sounding like a long list of why this can't be done.. but deep down I agree with the sentiment. I just don't see that we can actually accomplish it without giant changes. ___ 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
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 07, 2020 at 03:22:45PM +0100, Iñaki Ucar wrote: > For me, the main challenge Fedora faces is **positioning**. > > Let me explain: (I don't have numbers but) in my (limited) experience, > when seasoned sysadmins need to launch a new system, they usually > think "Debian" as something reliable; when seasoned as well as > not-very-seasoned-in-Linux research engineers (I know better this > category, since I'm a researcher) need to setup a system for some demo > or experiment, they mostly think "Ubuntu" (yes, I know...); when we > see a new exciting service (such as Travis CI and the like) coming > out, they usually support Ubuntu; and so on and so forth, and I'm not > even talking about the desktop use case. > > So I think there's the challenge for Fedora, for all those people to > consider Fedora as a first option for their use cases. I agree that's a challenge. Any ideas for how to address it and change these perceptions? -- Matthew Miller Fedora Project Leader ___ 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering wrote: - oomd currently polls some parameters in time intervals too, still. They are working on getting rid of that too, so that everything is event based via PSI. Given their own focus on servers it's not a primary goal, but still a goal. Alexey seems really pessimistic about PSI. It looks like he expects any solution based on PSI will fail: https://pagure.io/fedora-workstation/issue/98#comment-619086 So that seems like the most important problem right now. Looks like Benjamin has already solved the problem of isolating apps into separate systemd scopes. Alexey's concern about browser tabs is similarly solvable. But if PSI in general is too difficult to configure, this plan isn't going to work. ___ 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
Re: Let's talk about Fedora in the '20s!
On Mon, Jan 06, 2020 at 08:27:41PM -0500, Neal Gompa wrote: > At the minimum, democratizing Koji would make it easier for Teams to > build their own stuff using any of the tools supported by Koji... Then > it's a question of documentation of how to make custom media and > describing things like how to do branding. Yes, I think this democratization is key. Having an easy, straightforward (and well-documented!) interface is more important than having a flashy one. -- Matthew Miller Fedora Project Leader ___ 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
Re: Let's talk about Fedora in the '20s!
Dne 07. 01. 20 v 14:19 Tom Hughes napsal(a): > On 07/01/2020 13:06, Fabio Valentini wrote: > >> - ruby is weird, packaging gems is a bit of a chore, upstream has many >> knobs to fiddle with to make distro packaging hard (for example, not >> including test sources in .gem files seems to be a common practice), >> there's no canonical way of running test suites, and I think the >> %check section of all my rubygem packages is different and >> specifically tailored to the package ... > > Yeah npm does many of those things as well... > > Test files often excluded from npmjs.com tar ball and only available > on github where people often forget to tag releases. > > While "npm test" is the normal way Just FTR, there used to be "gem test" command, which was removed, because it was found unusable. Mainly because the tests are typically designed to be executed from the source repository and have many different dependencies. Since there is no "gem test" command anymore, the test suites are more commonly omitted nowadays. Vít > I'm not sure it's safe to actually > run npm during the build - we certainly don't normally. In any case > that often runs all sorts of other stuff like linters or coverage > tests that aren't relevant and require extra dependencies so we > usually look at what "npm test" actually does and run that. > > Test dependencies is another issue - the devDependencies key in the > metadata often includes lots of things that aren't needed by the tests > but are needed for other reasons by people working on the package. > > Also the npmjs.com tar ball may not even have the real source if the > package is transpiled from typescript or a different js variant. Though > in that case it's often a road block at the moment as we typically won't > have the toolchain necessary to do those build steps packaged. > > Lots of npm packages that claim to be BSD or MIT are missing the license > text is another good one. > > Decoding whether a "bin" target declared in the metadata is actually > worth exporting in /usr/bin and if so by what name is another thorny > issue to automate. > > Then of course there's the whole issue of massive dependency trees > and version mismatches unless you start packaging multiple versions > of the same libraries. > > 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
Re: Upgrading libffi
Neal Gompa writes: > RPM does not use libffi at all. My bad.. rpmbuild, through it's use of gdb, which requires python, which requires libffi. So my naive use of mock to try to build a new version of libffi and all of it's dependencies fail. > That said, it's quite easy to do a > rebuild of libffi's reverse dependencies in a side-tag and then merge > it back in. Ok, I suppose I'm willing to try, but I have no idea what a side-tag is. Repoquery tells me there are 192 packages that depend directly on libffi. > You can always ask for help from releng or other folks > around here to help get it done. Could somebody please walk me through the first few steps? Maybe start by explaining side tags? AG -- Anthony Green ___ 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
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
Kamil Paral wrote: > Well for the general user, everything is one-time. One download, one write > to USB, one install. Saving a minute in one step and adding it to a > different step doesn't really matter, it's the same sum overall (unless > you pay considerable money for the extra downloaded data, of course). But the larger download will take several minutes extra even on a low-end "broadband" connection. On slower connections, which are still standard in parts of the world, it will take hours longer. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Tue, Jan 7, 2020 at 5:27 am, Mark Otaris wrote: Try it. With a memory limit, podman run --rm -it --memory=1G fedora bash -c 'dnf install -y stress-ng && stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm 100' will use CPU but keep your system responsive. Without the memory limit (this will hang your system), podman run --rm -it fedora bash -c 'dnf install -y stress-ng && stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm 100' the system hangs and doesn’t recover after 15 minutes. I don't think we can use this, though; or at least, I don't see how. systemd allows limiting the memory accessible to a scope, but it doesn't allow carving out memory for one particular scope that is not to be accessible to other scopes. So I don't see a way to use these memory limits to ensure sufficient memory remains available to critical session processes. (Am I missing something?) ___ 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
Re: Big change to free maxmind GeoLite2 databases, limiting distribution
Dave Dykstra wrote: > I see that currently Fedora rawhide gets new geolite2-*-YYYMMDD packages > (e.g. geolite2-city-20191217) each month in order to distribute the free > maxmind geo IP databases. Unfortunately, Maxmind just greatly tightened > down on the license for these data distributions and I think that Fedora > will no longer be able to distribute them. The databases may still be > downloaded for free, and they may be freely redistributed, but anybody > who does so must ensure that everybody that they distribute to updates > their database within 30 days after Maxmind updates them, and destroys > all old copies. Here's the blog entry where they announced the change, > late in December, effective the end of 2019, saying that they had to do > it because of privacy laws: > > https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/ > > Anybody may sign up for an account and free license key, but they have to > agree to The new End User License Agreement with the new stipulations. > https://www.maxmind.com/en/geolite2/eula To me, it looks crystal clear that the new licensing conditions are not acceptable for Fedora. > I welcome any suggestions for good alternative sources of geo IP data > that doesn't have these kinds of restrictions and also believes they can > adhere to the privacy laws without requiring a license key. Would forking the database be an option? But then how do we determine required changes? In any case, we should talk to other distros, who will undoubtedly be running into the same issue. Especially those that really care about freedom, such as Debian, such as the FSF-endorsed distros, etc. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 07, 2020 at 01:13:02PM +0100, Florian Weimer wrote: > > In support of that, I'd like to also have that page steer people into > > tooling for creating new spins —- and I'd like to see us invest in and > > rebuild the spin creation processes. (Particularly, I'd like spin releases > > to be decoupled from the main OS release, and for those to be self-service > > by their SIGs with minimal rel-eng involvement needed.) > Do you see this covering spins which rebuild mainline Fedora packages > (possibly from the same SRPMs)? Possibly? I would expect in this case these would use modularity to make variant streams. -- Matthew Miller Fedora Project Leader ___ 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Tue, Jan 7, 2020 at 11:23 am, Kamil Paral wrote: In your example you forget that swap needs to filled almost to full for early-oom to start reacting. That takes time during which the system responsibility is abysmal. The UX difference happens only after you've already suffered through a serious responsivity degradation, and the only difference is the end state, *if* you've managed to wait long enough for early-oom to kick in (which happens earlier than kernel oom and with better results about which process gets killed, according to Chris). Right, we understand this. earlyoom (or a systemd-level OOM solution) is only half the solution. The other half will be fixing swap. That will probably require (a) reducing the amount of swap created by anaconda, and/or (b) swap on zram. ___ 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Tue, Jan 7, 2020 at 10:09 am, Benjamin Berg wrote: Even if that is the case, on F31 (with GNOME 3.34.2) we do place most user processes into separate scopes[1]. This is not perfect, because it currently only affects processes launched by gnome-shell, gnome- settings-daemon and gnome-session. So everything spawned by e.g. nautilus (easily fixable) or the terminal may still end up in their parents scope. Awesome. What about D-Bus activation? ___ 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
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 07, 2020 at 02:28:46PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jan 07, 2020 at 03:18:16PM +0100, Pierre-Yves Chibon wrote: > > On Tue, Jan 07, 2020 at 02:06:20PM +0100, Fabio Valentini wrote: > > > Just to add my 2¢ here: I have experience with packaging stuff from > > > many language ecosystems (ruby/gems, python/pypi, go, Java/maven) and > > > with various build systems (autotools, meson, CMake, etc.). The > > > packaging burden is *vastly* different, depending on the ecosystem. > > > > > > - python / pypi works great for %build and %install, but until testing > > > with tox is automated in packaging macros, %check has to be specified > > > manually since upstream projects do different things there. > > > generate_buildrequires also works nicely here. > > > - ruby is weird, packaging gems is a bit of a chore, upstream has many > > > knobs to fiddle with to make distro packaging hard (for example, not > > > including test sources in .gem files seems to be a common practice), > > > there's no canonical way of running test suites, and I think the > > > %check section of all my rubygem packages is different and > > > specifically tailored to the package ... > > > - go and rust are pretty easily automated because there's not as many > > > things upstreams can mess with, %build, %install and %check are almost > > > always clean and easily automated with macros. generate_buildrequires > > > also helps with rust packaging. > > > - Java / maven has good support with packaging tools and macros in > > > fedora, but if upstream project deviates from the "standard way of > > > doing things", even if it is only slightly, you might end up modifying > > > maven XML project definitions with XPATH queries. The horror. > > > > > > For C / C++ / Vala, which don't have language-specific package managers: > > > > > > - meson is really nice, almost never manual intervention needed; but > > > even if it's necessary, patching meson.build files is pretty > > > straight-forward > > > - CMake is alright, even if it's hardly readable by humans; but > > > patching CMakeLists.txt files gets ugly > > > - I hope autotools dies a fiery death, and soon > > > > > > TL;DR: The packaging burden ranges from being small or near > > > non-existent (meson, python, go, rust) to being a chore (ruby, Java, > > > autotools). I don't know how nodejs packages compare, since I've been > > > lucky and didn't have to deal with them yet. > > > > > > Conclusion: Some things could and should be improved, but some of that > > > will only happen if we cooperate with upstreams (for example, right > > > now rubygems or Java/maven is just too wild to be tamed by any > > > downstream automation IMO, unless an omniscient AGI is just around the > > > corner and will do our packaging for us). > > > > > > What I read here is: there are ecosystem for which we could automate a good > > chunk of things. This means, if we don't degrade things for other > > ecosystem, we > > would still be improving the overall situation. > > Improving 20% of our work is less ideal than 90% but is still better than > > 0%. > > > > The advantage of this diversity is that we should be able to improve things > > by > > steps, working through each ecosystem one by one. > > One disadvantage that will quickly show up though will be the: if you're > > using X > > or Y languages you need to do things this way, otherwise you need to do > > things > > that way. > > I hear that our documentation is sometime confusing to new-comer or people > > who > > only do some packaging work every once in a while, I fear that this wouldn't > > help with that problem. > > I'm not saying that we can't or shouldn't try to improve what/where we can, > > just > > that this is something to be aware of, acknowledge and try to mitigate. > > I agree with pretty much everything you're saying, except for one thing: > documentation *will* help. After all, we've always had language-specific > packaging guidelines, nothing new here. Packaging of different ecosystems > is inherently different. Sorry, I think my wording was confusing, in "I fear that this wouldn't help", "this" was not meant to refer to the documentation but more to the idea of working/improving/automating some ecosystems separately from the others. I agree with you that documentation is essential, to be honest it is even the only thing I can think of at the moment that will help mitigating differences in workflow as we make changes. Pierre ___ 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
Re: Let's talk about Fedora in the '20s!
Le mardi 07 janvier 2020 à 14:06 +0100, Fabio Valentini a écrit : > > Conclusion: Some things could and should be improved Yes, there are lots of shades of gray. All recent package managers allow downloading stuff for use (or they'd have no users). Some manage to build things. Some manage deps. A small set manages tests (usually, very poorly). And the associated deps. Very few manage installs. Even less manage upgrades. The more they manage the easier they are to automate and convert into rpm. The less they manage the harder they are to do things with, with of without rpm. Improving things requires continuing to improve and fixing rpm (which, sadly, is ridiculously under-invested in), and then adding the corresponding features to language package managers when their community is willing to make use of it. Because, the only way to make mapping to rpm easier is to fix the feature holes in language package managers (that does not remove the need for something like rpm because none of those handle mixed language projects and reality is full of those). However, adding things when upstream has no intention to move from the stone age is a perfect waste of time, as shown by the lack of adoption of the Fedora maven fork. So that requires willingness from upstream. And that’s the real answer to "upstream does not want to deal with rpm". Making things work better our side. Feeding value back upstream. There is no value in dumping rpm or investing in a different packaging tech because rpm is used as an alias for lots of things upstreams disagree with, most of which are not actually rpm the software, and most of which would not go away with a packaging tech switch. It would be interesting to analyse all those things, not to plan an rpm replacement, but to actually fix the things upstreams are not happy about (and, a lot of time, those won't involve rpm, and when they do involve rpm fixing rpm will be easier than rewriting it from scratch). But, some of those are inherently unfixable. All of the people that do "open source" because that’s the condition to earn their paycheck, but do not understand or are not interested in free software or Linux, won’t work with use no matter how we costume ourselves. There are lots of those nowadays. The Microsoft stranglehold has been broken and replaced by a Google/Apple/Facebook/Amazon/Microsoft oligopoly. People feel "free" to switch corporate masters, they to not feel the urge to make commons work. -- Nicolas Mailhot ___ 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
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 07, 2020 at 03:18:16PM +0100, Pierre-Yves Chibon wrote: > On Tue, Jan 07, 2020 at 02:06:20PM +0100, Fabio Valentini wrote: > > Just to add my 2¢ here: I have experience with packaging stuff from > > many language ecosystems (ruby/gems, python/pypi, go, Java/maven) and > > with various build systems (autotools, meson, CMake, etc.). The > > packaging burden is *vastly* different, depending on the ecosystem. > > > > - python / pypi works great for %build and %install, but until testing > > with tox is automated in packaging macros, %check has to be specified > > manually since upstream projects do different things there. > > generate_buildrequires also works nicely here. > > - ruby is weird, packaging gems is a bit of a chore, upstream has many > > knobs to fiddle with to make distro packaging hard (for example, not > > including test sources in .gem files seems to be a common practice), > > there's no canonical way of running test suites, and I think the > > %check section of all my rubygem packages is different and > > specifically tailored to the package ... > > - go and rust are pretty easily automated because there's not as many > > things upstreams can mess with, %build, %install and %check are almost > > always clean and easily automated with macros. generate_buildrequires > > also helps with rust packaging. > > - Java / maven has good support with packaging tools and macros in > > fedora, but if upstream project deviates from the "standard way of > > doing things", even if it is only slightly, you might end up modifying > > maven XML project definitions with XPATH queries. The horror. > > > > For C / C++ / Vala, which don't have language-specific package managers: > > > > - meson is really nice, almost never manual intervention needed; but > > even if it's necessary, patching meson.build files is pretty > > straight-forward > > - CMake is alright, even if it's hardly readable by humans; but > > patching CMakeLists.txt files gets ugly > > - I hope autotools dies a fiery death, and soon > > > > TL;DR: The packaging burden ranges from being small or near > > non-existent (meson, python, go, rust) to being a chore (ruby, Java, > > autotools). I don't know how nodejs packages compare, since I've been > > lucky and didn't have to deal with them yet. > > > > Conclusion: Some things could and should be improved, but some of that > > will only happen if we cooperate with upstreams (for example, right > > now rubygems or Java/maven is just too wild to be tamed by any > > downstream automation IMO, unless an omniscient AGI is just around the > > corner and will do our packaging for us). > > > What I read here is: there are ecosystem for which we could automate a good > chunk of things. This means, if we don't degrade things for other ecosystem, > we > would still be improving the overall situation. > Improving 20% of our work is less ideal than 90% but is still better than 0%. > > The advantage of this diversity is that we should be able to improve things by > steps, working through each ecosystem one by one. > One disadvantage that will quickly show up though will be the: if you're > using X > or Y languages you need to do things this way, otherwise you need to do things > that way. > I hear that our documentation is sometime confusing to new-comer or people who > only do some packaging work every once in a while, I fear that this wouldn't > help with that problem. > I'm not saying that we can't or shouldn't try to improve what/where we can, > just > that this is something to be aware of, acknowledge and try to mitigate. I agree with pretty much everything you're saying, except for one thing: documentation *will* help. After all, we've always had language-specific packaging guidelines, nothing new here. Packaging of different ecosystems is inherently different. 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
Re: Let's talk about Fedora in the '20s!
On Mon, 6 Jan 2020 at 18:28, Matthew Miller wrote: > > Hi everyone! Since it's a new year and a new decade [*], it seems like a > good time to look forward and talk about what we want the Fedora Project to > be in the next five and even ten years. How do we take the awesome > foundation we have now and build and grow and make something that continues > to thrive and be useful, valuable, and fun? > > [...] > > Those are my thoughts. What other challenges and opportunities do you see, > and what would you like us to focus on? For me, the main challenge Fedora faces is **positioning**. Let me explain: (I don't have numbers but) in my (limited) experience, when seasoned sysadmins need to launch a new system, they usually think "Debian" as something reliable; when seasoned as well as not-very-seasoned-in-Linux research engineers (I know better this category, since I'm a researcher) need to setup a system for some demo or experiment, they mostly think "Ubuntu" (yes, I know...); when we see a new exciting service (such as Travis CI and the like) coming out, they usually support Ubuntu; and so on and so forth, and I'm not even talking about the desktop use case. So I think there's the challenge for Fedora, for all those people to consider Fedora as a first option for their use cases. -- Iñaki Úcar ___ 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
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 07, 2020 at 02:06:20PM +0100, Fabio Valentini wrote: > Just to add my 2¢ here: I have experience with packaging stuff from > many language ecosystems (ruby/gems, python/pypi, go, Java/maven) and > with various build systems (autotools, meson, CMake, etc.). The > packaging burden is *vastly* different, depending on the ecosystem. > > - python / pypi works great for %build and %install, but until testing > with tox is automated in packaging macros, %check has to be specified > manually since upstream projects do different things there. > generate_buildrequires also works nicely here. > - ruby is weird, packaging gems is a bit of a chore, upstream has many > knobs to fiddle with to make distro packaging hard (for example, not > including test sources in .gem files seems to be a common practice), > there's no canonical way of running test suites, and I think the > %check section of all my rubygem packages is different and > specifically tailored to the package ... > - go and rust are pretty easily automated because there's not as many > things upstreams can mess with, %build, %install and %check are almost > always clean and easily automated with macros. generate_buildrequires > also helps with rust packaging. > - Java / maven has good support with packaging tools and macros in > fedora, but if upstream project deviates from the "standard way of > doing things", even if it is only slightly, you might end up modifying > maven XML project definitions with XPATH queries. The horror. > > For C / C++ / Vala, which don't have language-specific package managers: > > - meson is really nice, almost never manual intervention needed; but > even if it's necessary, patching meson.build files is pretty > straight-forward > - CMake is alright, even if it's hardly readable by humans; but > patching CMakeLists.txt files gets ugly > - I hope autotools dies a fiery death, and soon > > TL;DR: The packaging burden ranges from being small or near > non-existent (meson, python, go, rust) to being a chore (ruby, Java, > autotools). I don't know how nodejs packages compare, since I've been > lucky and didn't have to deal with them yet. > > Conclusion: Some things could and should be improved, but some of that > will only happen if we cooperate with upstreams (for example, right > now rubygems or Java/maven is just too wild to be tamed by any > downstream automation IMO, unless an omniscient AGI is just around the > corner and will do our packaging for us). What I read here is: there are ecosystem for which we could automate a good chunk of things. This means, if we don't degrade things for other ecosystem, we would still be improving the overall situation. Improving 20% of our work is less ideal than 90% but is still better than 0%. The advantage of this diversity is that we should be able to improve things by steps, working through each ecosystem one by one. One disadvantage that will quickly show up though will be the: if you're using X or Y languages you need to do things this way, otherwise you need to do things that way. I hear that our documentation is sometime confusing to new-comer or people who only do some packaging work every once in a while, I fear that this wouldn't help with that problem. I'm not saying that we can't or shouldn't try to improve what/where we can, just that this is something to be aware of, acknowledge and try to mitigate. Pierre ___ 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
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 7, 2020, at 6:41 AM, Tom Hughes wrote: > > I'd love to find a way to directly integrate the likes of gem, npm > etc directly into our packaging rather than us having to repackage > everything by hand but I just don't see any way of doing it without > compromising what we do to the extent that we're not really doing > anything useful at all and are just shoveling out whatever nonsense > upstreams perpetrate without question. Implicit in this is the idea that value should be captured at a secondary distribution layer. Implicit in this is the idea that distribution forks *need* to happen. But they don't. In fact, everyone here can work upstream too! If e.g. someone upstream messes up licensing, the mindset shouldn't be "oh man those upstream developers are incompetent, let's patch it downstream". Join upstream. Review *code* not spec files. Fix *code* not spec files. That's the most valuable thing for FOSS - not spec files. If there's an upstream that isn't doing the right thing (consistently) - fork the upstream, don't fork it at the package level. That way, work can be shared across multiple distributions. Even ignoring others, the Red Hat ecosystem today has 3 distributions - it's simply better to work upstream as much as possible, and avoid duplicating work across those 3 downstreams. ___ 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
Re: Trouble creating modular metadata for local repo
On 2020-01-07, Digimer wrote: > I'm trying to create a local repo of an offline collection of systems. > When I try to install, I get: > > > No available modular metadata for modular package 'foo.arch', it cannot > be installed on the system > > I guess the 'foo.arch' name is made up and it is actually a package provided by Fedora. Because there is no such package in Fedora and thus DNF should not suppose that the package is modular. Otherwise if it were a new unique yet modular package, there have to be the "modules.yaml" file listing it. And in that case you would know what modules are and how they are built and put into a repository. Could you explain us what the 'foo.arch' is in your case? -- Petr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Let's talk about Fedora in the '20s!
On Tue, 7 Jan 2020 at 13:58, Miro Hrončok wrote: > > [...] > > For me, an ultimate success would be if upstream projects would actually use > Fedora-family distros in their CI testing. And I don't mean that they would > use > Copr or packit to package RPM packages, or that they deploy their own Jenkins > on > CentOS, I mean that they would use something as easy as Travis CI, but instead > of ancient Ubuntu, they could choose from a variety of Fedora systems. I cannot agree more. The same applies for GitHub Actions. COPR and packit are great, but at the end of the day, the visibility in all these other widely used services is what matters. -- Iñaki Úcar ___ 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
Re: Let's talk about Fedora in the '20s!
On Tue, 7 Jan 2020 at 13:28, Neal Gompa wrote: > > On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman wrote: > > > > On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote: > > > Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a): > > > > Le 2020-01-06 19:05, Nicolas Mailhot a écrit : > > > > > > > > > Handling those checks is where the packaging toil is (that is, as long > > > > > as Fedora is a deployment project). It is not something the packaging > > > > > format makes harder. > > > > > > > > However, because our packaging format streamlines those checks, and > > > > forces to apply them, it is blamed by devs for the impedance mismatch > > > > between dev and deployment requirements. > > > > > > > > But, this mismatch is not caused by our packaging format. It is caused > > > > by devs taking shortcuts because their language packaging format lets > > > > them. > > > > > > > > > > Well said Nicolas. > > > > > > Embracing the "language-native packaging" and "git repos" is giving up > > > on what Fedora maintainers have always did and that is kicking forward > > > all the upstreams, because we force them to keep updating the > > > dependencies (or to maintain compatibility with old versions of > > > dependencies). Once we embrace "git repos" etc, we will lose our soul > > > IMO. There won't be any collaboration between upstream projects, which > > > was cultivated by distribution maintainers. Upstreams will sit in their > > > silos and bundle everything. > > Just recently I've read a discussion (IIRC on Hacker News) about an article > > about yet another mess due to NPM (I think this was for a change some > > licensing mess, > > not another malware) where someone suggested a radical new idea: "Lets have > > a > > crowd sourced set of packages that are known to have sane licenses, don't > > contain > > malware/CVEs and can work together!". Yeah, like, say a Linux distro such > > as Fedora ? > > > > Basically, it seems to me that the language specific package management > > systems > > are already creaking under load & display critical issues almost on a daily > > basis. > > Issues people with distro packaging background pointed out long ago, only > > to be ignored. > > > > So I think it really makes much more sense to continue with all the nice > > nice improvements > > we have been doing in RPM packaging, rather than throwing it all away and > > switching to > > a fundamentally inferior technology. > > > > > > > > Also, just today I had discussion if Ruby packages should be more Fedora > > > tailored or more upstream like and there is no right way which could > > > reasonably satisfy both worlds. > > > > > > E.g. if upstream package has Windows specific dependencies, it is kind > > > of natural to strip this dependency on Fedora. OTOH, it possibly breaks > > > a dependency resolving on other platforms, if the project was created > > > using Fedora packages. This is unfortunately the reason for devs to take > > > some shortcut, probably to go with upstream way, because if nothing > > > else, it is typically better documented. > > > > > There's some interesting cognitive dissonance here. In HN threads > where I've seen this, people seem to be naturally discovering that > what they want is a curation point for these modules, but when someone > points out that the Linux distribution essentially functions in that > role, there's some recoil. They say that they don't want that. Language-specific packaging formats share a common thing: they are designed to be installed in the users' home, or equivalently, in a virtual environment without root permissions. I'm guessing here, but the recoil you reference probably comes from the fact that distro-wide packaging systems require admin privileges. If that's true, then I think we should further promote Fedora toolbox. Iñaki > I think the underlying problem here is that we don't sell ourselves > well in the value proposition to these people. Most people sadly > reference Debian as their idea of a Linux distribution. While they > certainly provide certainty and curation, they are often too slow to > be usable by developers to leverage new features and capabilities for > their software. This is something we need to figure out how to market > better for Fedora desktop, server, and cloud variants. We provide much > of the same benefits that Debian does, except we also provide fresher > stacks and new features more quickly for people to leverage. > > "Friends. Features. Freedom. First. Fedora" > > > > -- > 真実はいつも一つ！/ 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.fedo
Re: Big change to free maxmind GeoLite2 databases, limiting distribution
FWIW, I am investigating the geolite2 license situation with Red Hat. Thanks, Tom On Mon, Jan 6, 2020 at 4:45 PM Dave Dykstra wrote: > I see that currently Fedora rawhide gets new geolite2-*-YYYMMDD packages > (e.g. geolite2-city-20191217) each month in order to distribute the free > maxmind geo IP databases. Unfortunately, Maxmind just greatly tightened > down on the license for these data distributions and I think that Fedora > will no longer be able to distribute them. The databases may still be > downloaded for free, and they may be freely redistributed, but anybody > who does so must ensure that everybody that they distribute to updates > their database within 30 days after Maxmind updates them, and destroys > all old copies. Here's the blog entry where they announced the change, > late in December, effective the end of 2019, saying that they had to do > it because of privacy laws: > > https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/ > > Anybody may sign up for an account and free license key, but they have to > agree to The new End User License Agreement with the new stipulations. > https://www.maxmind.com/en/geolite2/eula > > I welcome any suggestions for good alternative sources of geo IP data > that doesn't have these kinds of restrictions and also believes they can > adhere to the privacy laws without requiring a license key. > > Dave > ___ > 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 > ___ 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
Re: Let's talk about Fedora in the '20s!
On 07. 01. 20 14:32, Martin Kolman wrote: On Tue, 2020-01-07 at 13:50 +0100, Miro Hrončok wrote: For me, an ultimate success would be if upstream projects would actually use Fedora-family distros in their CI testing. And I don't mean that they would use Copr or packit to package RPM packages, or that they deploy their own Jenkins on CentOS, I mean that they would use something as easy as Travis CI, but instead of ancient Ubuntu, they could choose from a variety of Fedora systems. For example: Today, an upstream maintainer expressed dissatisfaction about Python 3.9 missing on Travis CI: https://github.com/benjaminp/six/issues/317#issuecomment-571408737 In this case it seems it's mainly lack of resources on the Travis side - they have been lagging with updates even for their single Ubuntu based environment for years. Yes, bacause they create their own tarballs instead of leveraging the distro - because the distro of they choice has no benefits for this. Fedora could have. It would be so cool to be able to say: Put "distro: fedora" to your CI config to get Python 3.9, because in Fedora, we already have that for a month+. This is actually possibly if a bit hacky, as you can launch containers in the Travis environment. So you can checkout a Fedora container and then run the tests inside it: https://github.com/weldr/lorax/blob/master/.travis.yml#L10 https://github.com/weldr/lorax/blob/master/Makefile#L130 Unfortunately you loose many of the Travis provided simple configuration options, but at least yo don't have to suffer the quirks of the default outdated Ubuntu. Sure, we do that as well: https://github.com/fedora-python/taskotron-python-versions/blob/develop/.travis.yml https://github.com/fedora-python/taskotron-python-versions/blob/develop/Dockerfile (In that particular example we are running mock (the rpm one, not Python mocking library) in pytest in tox in Docker with Fedora on Travis with Ubuntu which itself probably runs in some kind of container.) However it is far from easy and far from fast. As much as you might never expected me to say this: It would be even better with modularity, in case we actually offer alternate versions for most of our developer facing things. Instead of compiling my own stuff or downloading precomiled suspicious tarballs on Ubuntu/Travis, I could use Fedora and in the CI config, lists the streams of my database, webservers etc. and use it to expand my testing matrix. Having a strong presence on upstream CIs would help us get visibility. Later, people might choose Fedora as their base container platform to match their CI environment or even consider it for their workstations. Unfortunately I don't see this happening without RH partnering up with a major CI provider or without significant investment in providing our own public CI (sans RPM) - however we are now discontinuing services, not adding new. Indeed, an easy upstream usable Fedora/CentOS based upstream CI environment is sorely needed. BTW, with CentOS streams, it should now be possibly to even test in environment reasonably similar to the next upcoming release or RHEL, which was something that was missing before. Yes! We just need an environment that can be used easily - just as Travis, but Fedora/CentOS based and up to date. For example for CPython upstream, we manage our own test servers with RHEL and Fedora for this. Instead, ti would be nice if the upstream could just pick some. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 7, 2020 at 8:34 AM Martin Kolman wrote: > > On Tue, 2020-01-07 at 13:50 +0100, Miro Hrončok wrote: > > On 07. 01. 20 13:17, Neal Gompa wrote: > > > On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman wrote: > > > > On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote: > > > > > Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a): > > > > > > Le 2020-01-06 19:05, Nicolas Mailhot a écrit : > > > > > > > > > > > > > Handling those checks is where the packaging toil is (that is, as > > > > > > > long > > > > > > > as Fedora is a deployment project). It is not something the > > > > > > > packaging > > > > > > > format makes harder. > > > > > > > > > > > > However, because our packaging format streamlines those checks, and > > > > > > forces to apply them, it is blamed by devs for the impedance > > > > > > mismatch > > > > > > between dev and deployment requirements. > > > > > > > > > > > > But, this mismatch is not caused by our packaging format. It is > > > > > > caused > > > > > > by devs taking shortcuts because their language packaging format > > > > > > lets > > > > > > them. > > > > > > > > > > > > > > > > Well said Nicolas. > > > > > > > > > > Embracing the "language-native packaging" and "git repos" is giving up > > > > > on what Fedora maintainers have always did and that is kicking forward > > > > > all the upstreams, because we force them to keep updating the > > > > > dependencies (or to maintain compatibility with old versions of > > > > > dependencies). Once we embrace "git repos" etc, we will lose our soul > > > > > IMO. There won't be any collaboration between upstream projects, which > > > > > was cultivated by distribution maintainers. Upstreams will sit in > > > > > their > > > > > silos and bundle everything. > > > > Just recently I've read a discussion (IIRC on Hacker News) about an > > > > article > > > > about yet another mess due to NPM (I think this was for a change some > > > > licensing mess, > > > > not another malware) where someone suggested a radical new idea: "Lets > > > > have a > > > > crowd sourced set of packages that are known to have sane licenses, > > > > don't contain > > > > malware/CVEs and can work together!". Yeah, like, say a Linux distro > > > > such as Fedora ? > > > > > > > > Basically, it seems to me that the language specific package management > > > > systems > > > > are already creaking under load & display critical issues almost on a > > > > daily basis. > > > > Issues people with distro packaging background pointed out long ago, > > > > only to be ignored. > > > > > > > > So I think it really makes much more sense to continue with all the > > > > nice nice improvements > > > > we have been doing in RPM packaging, rather than throwing it all away > > > > and switching to > > > > a fundamentally inferior technology. > > > > > > > > > Also, just today I had discussion if Ruby packages should be more > > > > > Fedora > > > > > tailored or more upstream like and there is no right way which could > > > > > reasonably satisfy both worlds. > > > > > > > > > > E.g. if upstream package has Windows specific dependencies, it is kind > > > > > of natural to strip this dependency on Fedora. OTOH, it possibly > > > > > breaks > > > > > a dependency resolving on other platforms, if the project was created > > > > > using Fedora packages. This is unfortunately the reason for devs to > > > > > take > > > > > some shortcut, probably to go with upstream way, because if nothing > > > > > else, it is typically better documented. > > > > > > > > > > > There's some interesting cognitive dissonance here. In HN threads > > > where I've seen this, people seem to be naturally discovering that > > > what they want is a curation point for these modules, but when someone > > > points out that the Linux distribution essentially functions in that > > > role, there's some recoil. They say that they don't want that. > > > > > > I think the underlying problem here is that we don't sell ourselves > > > well in the value proposition to these people. Most people sadly > > > reference Debian as their idea of a Linux distribution. While they > > > certainly provide certainty and curation, they are often too slow to > > > be usable by developers to leverage new features and capabilities for > > > their software. This is something we need to figure out how to market > > > better for Fedora desktop, server, and cloud variants. We provide much > > > of the same benefits that Debian does, except we also provide fresher > > > stacks and new features more quickly for people to leverage. > > > > > > "Friends. Features. Freedom. First. Fedora" > > > > For me, an ultimate success would be if upstream projects would actually use > > Fedora-family distros in their CI testing. And I don't mean that they would > > use > > Copr or packit to package RPM packages, or that they deploy their own > > Jenkins on > > CentOS, I mean that they would use something as easy as Travis CI, bu
Re: Let's talk about Fedora in the '20s!
On Tue, 2020-01-07 at 13:50 +0100, Miro Hrončok wrote: > On 07. 01. 20 13:17, Neal Gompa wrote: > > On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman wrote: > > > On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote: > > > > Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a): > > > > > Le 2020-01-06 19:05, Nicolas Mailhot a écrit : > > > > > > > > > > > Handling those checks is where the packaging toil is (that is, as > > > > > > long > > > > > > as Fedora is a deployment project). It is not something the > > > > > > packaging > > > > > > format makes harder. > > > > > > > > > > However, because our packaging format streamlines those checks, and > > > > > forces to apply them, it is blamed by devs for the impedance mismatch > > > > > between dev and deployment requirements. > > > > > > > > > > But, this mismatch is not caused by our packaging format. It is caused > > > > > by devs taking shortcuts because their language packaging format lets > > > > > them. > > > > > > > > > > > > > Well said Nicolas. > > > > > > > > Embracing the "language-native packaging" and "git repos" is giving up > > > > on what Fedora maintainers have always did and that is kicking forward > > > > all the upstreams, because we force them to keep updating the > > > > dependencies (or to maintain compatibility with old versions of > > > > dependencies). Once we embrace "git repos" etc, we will lose our soul > > > > IMO. There won't be any collaboration between upstream projects, which > > > > was cultivated by distribution maintainers. Upstreams will sit in their > > > > silos and bundle everything. > > > Just recently I've read a discussion (IIRC on Hacker News) about an > > > article > > > about yet another mess due to NPM (I think this was for a change some > > > licensing mess, > > > not another malware) where someone suggested a radical new idea: "Lets > > > have a > > > crowd sourced set of packages that are known to have sane licenses, don't > > > contain > > > malware/CVEs and can work together!". Yeah, like, say a Linux distro such > > > as Fedora ? > > > > > > Basically, it seems to me that the language specific package management > > > systems > > > are already creaking under load & display critical issues almost on a > > > daily basis. > > > Issues people with distro packaging background pointed out long ago, only > > > to be ignored. > > > > > > So I think it really makes much more sense to continue with all the nice > > > nice improvements > > > we have been doing in RPM packaging, rather than throwing it all away and > > > switching to > > > a fundamentally inferior technology. > > > > > > > Also, just today I had discussion if Ruby packages should be more Fedora > > > > tailored or more upstream like and there is no right way which could > > > > reasonably satisfy both worlds. > > > > > > > > E.g. if upstream package has Windows specific dependencies, it is kind > > > > of natural to strip this dependency on Fedora. OTOH, it possibly breaks > > > > a dependency resolving on other platforms, if the project was created > > > > using Fedora packages. This is unfortunately the reason for devs to take > > > > some shortcut, probably to go with upstream way, because if nothing > > > > else, it is typically better documented. > > > > > > > > There's some interesting cognitive dissonance here. In HN threads > > where I've seen this, people seem to be naturally discovering that > > what they want is a curation point for these modules, but when someone > > points out that the Linux distribution essentially functions in that > > role, there's some recoil. They say that they don't want that. > > > > I think the underlying problem here is that we don't sell ourselves > > well in the value proposition to these people. Most people sadly > > reference Debian as their idea of a Linux distribution. While they > > certainly provide certainty and curation, they are often too slow to > > be usable by developers to leverage new features and capabilities for > > their software. This is something we need to figure out how to market > > better for Fedora desktop, server, and cloud variants. We provide much > > of the same benefits that Debian does, except we also provide fresher > > stacks and new features more quickly for people to leverage. > > > > "Friends. Features. Freedom. First. Fedora" > > For me, an ultimate success would be if upstream projects would actually use > Fedora-family distros in their CI testing. And I don't mean that they would > use > Copr or packit to package RPM packages, or that they deploy their own Jenkins > on > CentOS, I mean that they would use something as easy as Travis CI, but > instead > of ancient Ubuntu, they could choose from a variety of Fedora systems. > > For example: Today, an upstream maintainer expressed dissatisfaction about > Python 3.9 missing on Travis CI: > > https://github.com/benjaminp/six/issues/317#issuecomment-571408737 In this case it seems it's ma
Re: Tox automation in packaging macros
On Tue, Jan 7, 2020 at 2:18 PM Miro Hrončok wrote: > > On 07. 01. 20 14:06, Fabio Valentini wrote: > > - python / pypi works great for %build and %install, but until testing > > with tox is automated in packaging macros, %check has to be specified > > manually since upstream projects do different things there. > > generate_buildrequires also works nicely here. > > See the %tox macro from > https://src.fedoraproject.org/rpms/pyproject-rpm-macros > > Examples: > > https://src.fedoraproject.org/rpms/python-xmlschema/blob/master/f/python-xmlschema.spec > > https://src.fedoraproject.org/rpms/python-elementpath/blob/master/f/python-elementpath.spec Ooh, shiny. I knew that somebody was working on this because it was presented at flock, but I didn't know that it was in a usable state now. I'll try using it in the next python package I touch :) Thanks for the pointers, Miro! Fabio > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Let's talk about Fedora in the '20s!
On 07/01/2020 13:06, Fabio Valentini wrote: - ruby is weird, packaging gems is a bit of a chore, upstream has many knobs to fiddle with to make distro packaging hard (for example, not including test sources in .gem files seems to be a common practice), there's no canonical way of running test suites, and I think the %check section of all my rubygem packages is different and specifically tailored to the package ... Yeah npm does many of those things as well... Test files often excluded from npmjs.com tar ball and only available on github where people often forget to tag releases. While "npm test" is the normal way I'm not sure it's safe to actually run npm during the build - we certainly don't normally. In any case that often runs all sorts of other stuff like linters or coverage tests that aren't relevant and require extra dependencies so we usually look at what "npm test" actually does and run that. Test dependencies is another issue - the devDependencies key in the metadata often includes lots of things that aren't needed by the tests but are needed for other reasons by people working on the package. Also the npmjs.com tar ball may not even have the real source if the package is transpiled from typescript or a different js variant. Though in that case it's often a road block at the moment as we typically won't have the toolchain necessary to do those build steps packaged. Lots of npm packages that claim to be BSD or MIT are missing the license text is another good one. Decoding whether a "bin" target declared in the metadata is actually worth exporting in /usr/bin and if so by what name is another thorny issue to automate. Then of course there's the whole issue of massive dependency trees and version mismatches unless you start packaging multiple versions of the same libraries. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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
Tox automation in packaging macros
On 07. 01. 20 14:06, Fabio Valentini wrote: - python / pypi works great for %build and %install, but until testing with tox is automated in packaging macros, %check has to be specified manually since upstream projects do different things there. generate_buildrequires also works nicely here. See the %tox macro from https://src.fedoraproject.org/rpms/pyproject-rpm-macros Examples: https://src.fedoraproject.org/rpms/python-xmlschema/blob/master/f/python-xmlschema.spec https://src.fedoraproject.org/rpms/python-elementpath/blob/master/f/python-elementpath.spec -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20200107.n.0 compose check report
No missing expected images. Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 7/155 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20200106.n.0): ID: 507832 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/507832 ID: 507871 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/507871 ID: 507914 Test: x86_64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/507914 Old failures (same test failed in Fedora-Rawhide-20200106.n.0): ID: 507780 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/507780 ID: 507782 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/507782 ID: 507823 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/507823 ID: 507835 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/507835 ID: 507913 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/507913 Soft failed openQA tests: 85/155 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20200106.n.0): ID: 507761 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/507761 ID: 507762 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/507762 ID: 507766 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/507766 ID: 507767 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/507767 ID: 507768 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/507768 ID: 507769 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/507769 ID: 507770 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/507770 ID: 507771 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/507771 ID: 507772 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/507772 ID: 507774 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/507774 ID: 507775 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/507775 ID: 507786 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/507786 ID: 507791 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/507791 ID: 507794 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/507794 ID: 507800 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/507800 ID: 507801 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/507801 ID: 507809 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/507809 ID: 507814 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/507814 ID: 507837 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/507837 ID: 507838 Test: x86_64 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/507838 ID: 507839 Test: x86_64 universal install_no_swap URL: https://openqa.fedoraproject.org/tests/507839 ID: 507840 Test: x86_64 universal install_updates_img_local URL: https://openqa.fedoraproject.org/tests/507840 ID: 507841 Test: x86_64 universal install_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/507841 ID: 507843 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/507843 ID: 507844 Test: x86_64 universal install_kickstart_firewall_disabled URL: https://openqa.fedoraproject.org/tests/507844 ID: 507845 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/507845 ID: 507846 Test: x86_64 universal install_sata@uefi URL: https://openqa.fedoraproject.org/tests/507846 ID: 507847 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/507847 ID: 507848 Test: x86_64 universal install_shrink_ntfs URL: https://openqa.fedoraproject.org/tests/507848 ID: 507850 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/507850 ID: 507851 Test: x86_64 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/507851 ID: 507852
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 7, 2020 at 1:31 PM Tom Hughes wrote: > > On 07/01/2020 12:22, Miroslav Suchý wrote: > > Dne 07. 01. 20 v 12:41 Tom Hughes napsal(a): > >> The thing is that no matter how much you can manage to automate the > >> creation of spec files for a given ecosystem, and I've never seen one > >> where the typical spec file doesn't need some manual tweaking, you > >> are still going to hit the fundamental problem that those specs then > >> need to be reviewed. > > > > I disagree. > > Especially with libraries - be it python, gems... it can be very well > > automated without the need for review. > > Well that depends on the reason for the review, doesn't it? > > Just to take a few things, how does automation check that the license > declared in the upstream metadata is correct? or that the upstream > package is obeying FHS and not installing files in the wrong place? (snip) > I have extensive experience with npm and packaging Node.js libraries > in Fedora and even a well behaved upstream is rarely fully automatable > and many upstreams are not well behaved. > > Tom Just to add my 2¢ here: I have experience with packaging stuff from many language ecosystems (ruby/gems, python/pypi, go, Java/maven) and with various build systems (autotools, meson, CMake, etc.). The packaging burden is *vastly* different, depending on the ecosystem. - python / pypi works great for %build and %install, but until testing with tox is automated in packaging macros, %check has to be specified manually since upstream projects do different things there. generate_buildrequires also works nicely here. - ruby is weird, packaging gems is a bit of a chore, upstream has many knobs to fiddle with to make distro packaging hard (for example, not including test sources in .gem files seems to be a common practice), there's no canonical way of running test suites, and I think the %check section of all my rubygem packages is different and specifically tailored to the package ... - go and rust are pretty easily automated because there's not as many things upstreams can mess with, %build, %install and %check are almost always clean and easily automated with macros. generate_buildrequires also helps with rust packaging. - Java / maven has good support with packaging tools and macros in fedora, but if upstream project deviates from the "standard way of doing things", even if it is only slightly, you might end up modifying maven XML project definitions with XPATH queries. The horror. For C / C++ / Vala, which don't have language-specific package managers: - meson is really nice, almost never manual intervention needed; but even if it's necessary, patching meson.build files is pretty straight-forward - CMake is alright, even if it's hardly readable by humans; but patching CMakeLists.txt files gets ugly - I hope autotools dies a fiery death, and soon TL;DR: The packaging burden ranges from being small or near non-existent (meson, python, go, rust) to being a chore (ruby, Java, autotools). I don't know how nodejs packages compare, since I've been lucky and didn't have to deal with them yet. Conclusion: Some things could and should be improved, but some of that will only happen if we cooperate with upstreams (for example, right now rubygems or Java/maven is just too wild to be tamed by any downstream automation IMO, unless an omniscient AGI is just around the corner and will do our packaging for us). Idea: What would be nice to see from more tools would provide introspection or machine-readable output from stuff run in %build and/or %install. For example, maven/XMvn automatically generates file lists. I think automating things in %files should be doable for more ecosystems (python? ruby?). PS: I *do* think packagers add value by packaging upstream projects *correctly*, basically by providing a unified abstraction over all the weird things that upstream projects can do, and sometimes actually do. It makes it easier for consumers, because they know what to expect when they "dnf install rubygem-foo", whereas "gem install foo" or "pip install foo" might run and do all sorts of weird shit you don't want. Fabio > -- > Tom Hughes (t...@compton.nu) > http://compton.nu/ > ___ > 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 ___ 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.fed
Re: Let's talk about Fedora in the '20s!
On 07. 01. 20 13:17, Neal Gompa wrote: On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman wrote: On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote: Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a): Le 2020-01-06 19:05, Nicolas Mailhot a écrit : Handling those checks is where the packaging toil is (that is, as long as Fedora is a deployment project). It is not something the packaging format makes harder. However, because our packaging format streamlines those checks, and forces to apply them, it is blamed by devs for the impedance mismatch between dev and deployment requirements. But, this mismatch is not caused by our packaging format. It is caused by devs taking shortcuts because their language packaging format lets them. Well said Nicolas. Embracing the "language-native packaging" and "git repos" is giving up on what Fedora maintainers have always did and that is kicking forward all the upstreams, because we force them to keep updating the dependencies (or to maintain compatibility with old versions of dependencies). Once we embrace "git repos" etc, we will lose our soul IMO. There won't be any collaboration between upstream projects, which was cultivated by distribution maintainers. Upstreams will sit in their silos and bundle everything. Just recently I've read a discussion (IIRC on Hacker News) about an article about yet another mess due to NPM (I think this was for a change some licensing mess, not another malware) where someone suggested a radical new idea: "Lets have a crowd sourced set of packages that are known to have sane licenses, don't contain malware/CVEs and can work together!". Yeah, like, say a Linux distro such as Fedora ? Basically, it seems to me that the language specific package management systems are already creaking under load & display critical issues almost on a daily basis. Issues people with distro packaging background pointed out long ago, only to be ignored. So I think it really makes much more sense to continue with all the nice nice improvements we have been doing in RPM packaging, rather than throwing it all away and switching to a fundamentally inferior technology. Also, just today I had discussion if Ruby packages should be more Fedora tailored or more upstream like and there is no right way which could reasonably satisfy both worlds. E.g. if upstream package has Windows specific dependencies, it is kind of natural to strip this dependency on Fedora. OTOH, it possibly breaks a dependency resolving on other platforms, if the project was created using Fedora packages. This is unfortunately the reason for devs to take some shortcut, probably to go with upstream way, because if nothing else, it is typically better documented. There's some interesting cognitive dissonance here. In HN threads where I've seen this, people seem to be naturally discovering that what they want is a curation point for these modules, but when someone points out that the Linux distribution essentially functions in that role, there's some recoil. They say that they don't want that. I think the underlying problem here is that we don't sell ourselves well in the value proposition to these people. Most people sadly reference Debian as their idea of a Linux distribution. While they certainly provide certainty and curation, they are often too slow to be usable by developers to leverage new features and capabilities for their software. This is something we need to figure out how to market better for Fedora desktop, server, and cloud variants. We provide much of the same benefits that Debian does, except we also provide fresher stacks and new features more quickly for people to leverage. "Friends. Features. Freedom. First. Fedora" For me, an ultimate success would be if upstream projects would actually use Fedora-family distros in their CI testing. And I don't mean that they would use Copr or packit to package RPM packages, or that they deploy their own Jenkins on CentOS, I mean that they would use something as easy as Travis CI, but instead of ancient Ubuntu, they could choose from a variety of Fedora systems. For example: Today, an upstream maintainer expressed dissatisfaction about Python 3.9 missing on Travis CI: https://github.com/benjaminp/six/issues/317#issuecomment-571408737 It would be so cool to be able to say: Put "distro: fedora" to your CI config to get Python 3.9, because in Fedora, we already have that for a month+. As much as you might never expected me to say this: It would be even better with modularity, in case we actually offer alternate versions for most of our developer facing things. Instead of compiling my own stuff or downloading precomiled suspicious tarballs on Ubuntu/Travis, I could use Fedora and in the CI config, lists the streams of my database, webservers etc. and use it to expand my testing matrix. Having a strong presence on upstream CIs would help us get visibility. Later, people might choose Fedora as their b
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 07, 2020 at 12:30:25PM +, Tom Hughes wrote: > On 07/01/2020 12:22, Miroslav Suchý wrote: > >Dne 07. 01. 20 v 12:41 Tom Hughes napsal(a): > >>The thing is that no matter how much you can manage to automate the > >>creation of spec files for a given ecosystem, and I've never seen one > >>where the typical spec file doesn't need some manual tweaking, you > >>are still going to hit the fundamental problem that those specs then > >>need to be reviewed. > > > >I disagree. > >Especially with libraries - be it python, gems... it can be very well > >automated without the need for review. > > Well that depends on the reason for the review, doesn't it? > > Just to take a few things, how does automation check that the license > declared in the upstream metadata is correct? or that the upstream > package is obeying FHS and not installing files in the wrong place? Yes, it does, or at least it should. This is the kind of thing that absolutely can be automated. For licensing in particular, we have machine-readable spdx tags on files, and automatic conversion of sdpx tags to Fedora tags. And language-specific packaging formats have a metadata field for the license field. If both those sources agree, then automation should be able to say that the license is correct with a very high degree of confidence. Automation is not going to catch every case, but neither would a human. And for FHS compliance, similar checks can be easily implemented. Fedora-review certainly does some. But if language-specific packaging framework provides a way to do installation automatically, then actually the chances of an upstream project inventing their own paths is diminished, so this should be less of an issue in the future. > I have extensive experience with npm and packaging Node.js libraries > in Fedora and even a well behaved upstream is rarely fully automatable > and many upstreams are not well behaved. No doubt. That's why I said elsewhere in the thread that automation is something that requires cooperation from both upstream and our side. 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
Re: Let's talk about Fedora in the '20s!
Tom Hughes writes: > On 07/01/2020 12:22, Miroslav Suchý wrote: >> Dne 07. 01. 20 v 12:41 Tom Hughes napsal(a): >>> The thing is that no matter how much you can manage to automate the >>> creation of spec files for a given ecosystem, and I've never seen one >>> where the typical spec file doesn't need some manual tweaking, you >>> are still going to hit the fundamental problem that those specs then >>> need to be reviewed. >> >> I disagree. >> Especially with libraries - be it python, gems... it can be very well >> automated without the need for review. > > Well that depends on the reason for the review, doesn't it? > > Just to take a few things, how does automation check that the license > declared in the upstream metadata is correct? openSUSE actually has a bot for exactly this in the Open Build Service (it's not perfect of course, but it takes a good chunk of the legal review burden from humans): https://github.com/openSUSE/cavil. Iirc Neal has been trying to get it into Fedora. signature.asc Description: PGP signature ___ 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
Re: Let's talk about Fedora in the '20s!
On 07/01/2020 12:22, Miroslav Suchý wrote: Dne 07. 01. 20 v 12:41 Tom Hughes napsal(a): The thing is that no matter how much you can manage to automate the creation of spec files for a given ecosystem, and I've never seen one where the typical spec file doesn't need some manual tweaking, you are still going to hit the fundamental problem that those specs then need to be reviewed. I disagree. Especially with libraries - be it python, gems... it can be very well automated without the need for review. Well that depends on the reason for the review, doesn't it? Just to take a few things, how does automation check that the license declared in the upstream metadata is correct? or that the upstream package is obeying FHS and not installing files in the wrong place? I have extensive experience with npm and packaging Node.js libraries in Fedora and even a well behaved upstream is rarely fully automatable and many upstreams are not well behaved. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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
Re: Let's talk about Fedora in the '20s!
Dne 07. 01. 20 v 12:41 Tom Hughes napsal(a): > The thing is that no matter how much you can manage to automate the > creation of spec files for a given ecosystem, and I've never seen one > where the typical spec file doesn't need some manual tweaking, you > are still going to hit the fundamental problem that those specs then > need to be reviewed. I disagree. Especially with libraries - be it python, gems... it can be very well automated without the need for review. Of course, you will hit some hard pieces which will require human intervention. But it is big difference if you manually package 100 000 gems or if you automatically package 99 900 gems and manually touch 100 gems. > I'd love to find a way to directly integrate the likes of gem, npm > etc directly into our packaging +1 I'd love to see this as part of packaging management (rpm?) too. But only as an option. It is hard to predict if those ideas will be viable. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman wrote: > > On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote: > > Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a): > > > Le 2020-01-06 19:05, Nicolas Mailhot a écrit : > > > > > > > Handling those checks is where the packaging toil is (that is, as long > > > > as Fedora is a deployment project). It is not something the packaging > > > > format makes harder. > > > > > > However, because our packaging format streamlines those checks, and > > > forces to apply them, it is blamed by devs for the impedance mismatch > > > between dev and deployment requirements. > > > > > > But, this mismatch is not caused by our packaging format. It is caused > > > by devs taking shortcuts because their language packaging format lets > > > them. > > > > > > > Well said Nicolas. > > > > Embracing the "language-native packaging" and "git repos" is giving up > > on what Fedora maintainers have always did and that is kicking forward > > all the upstreams, because we force them to keep updating the > > dependencies (or to maintain compatibility with old versions of > > dependencies). Once we embrace "git repos" etc, we will lose our soul > > IMO. There won't be any collaboration between upstream projects, which > > was cultivated by distribution maintainers. Upstreams will sit in their > > silos and bundle everything. > Just recently I've read a discussion (IIRC on Hacker News) about an article > about yet another mess due to NPM (I think this was for a change some > licensing mess, > not another malware) where someone suggested a radical new idea: "Lets have a > crowd sourced set of packages that are known to have sane licenses, don't > contain > malware/CVEs and can work together!". Yeah, like, say a Linux distro such as > Fedora ? > > Basically, it seems to me that the language specific package management > systems > are already creaking under load & display critical issues almost on a daily > basis. > Issues people with distro packaging background pointed out long ago, only to > be ignored. > > So I think it really makes much more sense to continue with all the nice nice > improvements > we have been doing in RPM packaging, rather than throwing it all away and > switching to > a fundamentally inferior technology. > > > > > Also, just today I had discussion if Ruby packages should be more Fedora > > tailored or more upstream like and there is no right way which could > > reasonably satisfy both worlds. > > > > E.g. if upstream package has Windows specific dependencies, it is kind > > of natural to strip this dependency on Fedora. OTOH, it possibly breaks > > a dependency resolving on other platforms, if the project was created > > using Fedora packages. This is unfortunately the reason for devs to take > > some shortcut, probably to go with upstream way, because if nothing > > else, it is typically better documented. > > There's some interesting cognitive dissonance here. In HN threads where I've seen this, people seem to be naturally discovering that what they want is a curation point for these modules, but when someone points out that the Linux distribution essentially functions in that role, there's some recoil. They say that they don't want that. I think the underlying problem here is that we don't sell ourselves well in the value proposition to these people. Most people sadly reference Debian as their idea of a Linux distribution. While they certainly provide certainty and curation, they are often too slow to be usable by developers to leverage new features and capabilities for their software. This is something we need to figure out how to market better for Fedora desktop, server, and cloud variants. We provide much of the same benefits that Debian does, except we also provide fresher stacks and new features more quickly for people to leverage. "Friends. Features. Freedom. First. Fedora" -- 真実はいつも一つ！/ 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
Re: Let's talk about Fedora in the '20s!
* Matthew Miller: > In support of that, I'd like to also have that page steer people into > tooling for creating new spins —- and I'd like to see us invest in and > rebuild the spin creation processes. (Particularly, I'd like spin releases > to be decoupled from the main OS release, and for those to be self-service > by their SIGs with minimal rel-eng involvement needed.) Do you see this covering spins which rebuild mainline Fedora packages (possibly from the same SRPMs)? 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
Re: Let's talk about Fedora in the '20s!
On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote: > Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a): > > Le 2020-01-06 19:05, Nicolas Mailhot a écrit : > > > > > Handling those checks is where the packaging toil is (that is, as long > > > as Fedora is a deployment project). It is not something the packaging > > > format makes harder. > > > > However, because our packaging format streamlines those checks, and > > forces to apply them, it is blamed by devs for the impedance mismatch > > between dev and deployment requirements. > > > > But, this mismatch is not caused by our packaging format. It is caused > > by devs taking shortcuts because their language packaging format lets > > them. > > > > Well said Nicolas. > > Embracing the "language-native packaging" and "git repos" is giving up > on what Fedora maintainers have always did and that is kicking forward > all the upstreams, because we force them to keep updating the > dependencies (or to maintain compatibility with old versions of > dependencies). Once we embrace "git repos" etc, we will lose our soul > IMO. There won't be any collaboration between upstream projects, which > was cultivated by distribution maintainers. Upstreams will sit in their > silos and bundle everything. Just recently I've read a discussion (IIRC on Hacker News) about an article about yet another mess due to NPM (I think this was for a change some licensing mess, not another malware) where someone suggested a radical new idea: "Lets have a crowd sourced set of packages that are known to have sane licenses, don't contain malware/CVEs and can work together!". Yeah, like, say a Linux distro such as Fedora ? Basically, it seems to me that the language specific package management systems are already creaking under load & display critical issues almost on a daily basis. Issues people with distro packaging background pointed out long ago, only to be ignored. So I think it really makes much more sense to continue with all the nice nice improvements we have been doing in RPM packaging, rather than throwing it all away and switching to a fundamentally inferior technology. > > Also, just today I had discussion if Ruby packages should be more Fedora > tailored or more upstream like and there is no right way which could > reasonably satisfy both worlds. > > E.g. if upstream package has Windows specific dependencies, it is kind > of natural to strip this dependency on Fedora. OTOH, it possibly breaks > a dependency resolving on other platforms, if the project was created > using Fedora packages. This is unfortunately the reason for devs to take > some shortcut, probably to go with upstream way, because if nothing > else, it is typically better documented. > > > > Vít > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ 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
Re: Let's talk about Fedora in the '20s!
On 07/01/2020 10:57, Zbigniew Jędrzejewski-Szmek wrote: It is pretty clear that we've simplified rpm packaging massively over the last few years. It is enough to take a random spec file from 10 years ago, with all the fragile manual steps and compare it with modern spec file that is often just a bit of boilerplate to provide the name, version, license and description, and then call some macros that do all the heavy lifting. We've made great strides in making to bring rpm and upstream packaging closer. And this has been an effort on both sides, both upstream to accommodate workflows required by distros, and on the distro side to wrap those workflows: automatically generated spec for rust packages, pyproject macros, etc, etc. Also spdx licenses, automatic github tarballs… But it is clear that this automatization process is far from complete. And to stay relevant, we (and other distros) need to keep up this work. Without that, we'll never keep up with the infinite supply of upstream projects and we'll stop being useful to users. The thing is that no matter how much you can manage to automate the creation of spec files for a given ecosystem, and I've never seen one where the typical spec file doesn't need some manual tweaking, you are still going to hit the fundamental problem that those specs then need to be reviewed. In the typical "modern" ecosystem where everything is split into hundreds of every tinier components review bandwidth is the single biggest limitation and unless you're going to abandon reviews as part of automating distribution of upstream components I just don't see how this can work. I'd love to find a way to directly integrate the likes of gem, npm etc directly into our packaging rather than us having to repackage everything by hand but I just don't see any way of doing it without compromising what we do to the extent that we're not really doing anything useful at all and are just shoveling out whatever nonsense upstreams perpetrate without question. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Sat, 2020-01-04 at 12:17 -0600, Michael Catanzaro wrote: > On Sat, Jan 4, 2020 at 11:38 am, Zbigniew Jędrzejewski-Szmek > wrote: > > What about using the memory controller for user units to allocate > > memory resources between the processes in the user session? Thanks > > to > > recent developments, the gnome session uses separate systemd units > > (and thus separate cgroups) for various services. We could set > > attributes > > like memory.low for "the basic components of the user session", > > and on the other hand, memory.swap.max for "the payload", i.e. > > various > > user processes on top. > > This looks interesting. I'd love to see more serious discussion of > this > proposal. Carving out dedicated memory for essential desktop > processes > seems like something we should be able to do in 2020. > And it seems like it is: In the issue about this whole topic some implemented solutions where mentioned: https://github.com/Nefelim4ag/Ananicy But not further commented at least on pagure. https://pagure.io/fedora-workstation/issue/98#comment-615424 Which I think is quite sad as those seem to be the way better way to handle those things. Having a daemon that assigns cgroups to processes seems to let the kernel do its thing and keep us all sane and keeps the system reasonable responsive. I guess the important question here is: Does it really prevent hanging and what's the origin of hanging? Is it that the kernel starts to swap and therefore eats up all CPU time or is it the programs in foreground that suddenly all try to get their piece of memory back that forces kswapd onto the CPU? My guess would be the latter, but I'm sure the group who did the research on this topic has a better insight into this. -- Signed Sheogorath OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt signature.asc Description: This is a digitally signed message part ___ 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
Re: Fedora 33 System-Wide Change proposal: binutils 2.34
On Tue, Jan 07, 2020 at 12:08:02PM +0100, Vít Ondruch wrote: > > Dne 07. 01. 20 v 11:03 Zbigniew Jędrzejewski-Szmek napsal(a): > > On Tue, Jan 07, 2020 at 09:49:21AM +0100, Kevin Kofler wrote: > >> Vít Ondruch wrote: > >>> Dne 04. 01. 20 v 11:52 Zbigniew Jędrzejewski-Szmek napsal(a): > I think that is too late. > >>> For Fedora 33? I don't think so :) > >> I think the issue Zbyszek is complaining about is not that the feature is > >> being filed too late (which is clearly not the case), but that the Beta > >> freeze is, in his view, too late to enact the contingency deadline. > > Yes, that might be the case, but then the statement 'Maybe set the > contingency deadline at "Change Checkpoint: 100% Code Complete Deadline > Tue 2020-02-25"' just adds to confusion. Yep, that should be Tue 2020-08-25. 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
Qt 5.14 rawhide
Qt 5.14 is out since November. I understand that it may not be suitable for 31 yet (why not? rebuilds?) but at least should be in rawhide. It contains a bunch of fixes regarding high dpi and other stuff where custom patches were carried out by Fedora are fixed now upstream. Can we have Fedora Rawhide with Qt.5.14 or at least some copr or easy way to rebuild the Qt rpms as 5.14 using fedpkg or rpmrebuild? Thanks! Regards, Damian ___ 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
Re: Fedora 33 System-Wide Change proposal: binutils 2.34
Dne 07. 01. 20 v 11:03 Zbigniew Jędrzejewski-Szmek napsal(a): > On Tue, Jan 07, 2020 at 09:49:21AM +0100, Kevin Kofler wrote: >> Vít Ondruch wrote: >>> Dne 04. 01. 20 v 11:52 Zbigniew Jędrzejewski-Szmek napsal(a): I think that is too late. >>> For Fedora 33? I don't think so :) >> I think the issue Zbyszek is complaining about is not that the feature is >> being filed too late (which is clearly not the case), but that the Beta >> freeze is, in his view, too late to enact the contingency deadline. Yes, that might be the case, but then the statement 'Maybe set the contingency deadline at "Change Checkpoint: 100% Code Complete Deadline Tue 2020-02-25"' just adds to confusion. ¯\_(ツ)_/¯ > Yep, exactly. Thank you for clarifying. Vít > > 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 ___ 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
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Tue, Jan 7, 2020 at 10:01 AM Kevin Kofler wrote: > Chris Murphy wrote: > > Has zstandard been evaluated? In my testing of images compressed with > > zstd, the CPU hit is cut by more than 50%, and is no longer a > > bottleneck during installations. Image size does increase, although I > > haven't tested mksquashfs block size higher than 256K. > > I think increasing the size of the live images, also affecting the > download > time and the time to write the image to media (even USB sticks are not > instant), to get a one-time installation speedup is a very bad tradeoff. > Well for the general user, everything is one-time. One download, one write to USB, one install. Saving a minute in one step and adding it to a different step doesn't really matter, it's the same sum overall (unless you pay considerable money for the extra downloaded data, of course). Where it matters is when you do a high amount of operations. And those operations are likely to be installations. Either in some school lab, where you install 20 machines, or, in our very specific example, when you perform automated testing/CI as part of the release process, and perform tens or hundreds of installation every single day. The time difference (and CPU usage difference) saved during installation gets really noticeable in such cases. ___ 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Tue, 2020-01-07 at 11:28 +0100, Lennart Poettering wrote:
> On Mo, 06.01.20 14:53, Michael Catanzaro (mcatanz...@gnome.org) wrote:
>
> > On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
> > wrote:
> > > - facebook is working on making oomd something that just works for
> > > everyone, they are in the final rounds of canonicalizing the
> > > configuration so that it can just work for all workloads without
> > > tuning. The last bits for this to be deployable are currently being
> > > done on the kernel side ("iocost"), when that's in, they'll submit
> > > oomd (or simplified parts of it) to systemd, so that it's just there
> > > and works. It's their expressive intention to make this something
> > > that also works for desktop stuff and requires no further
> > > tuning. they also will do the systemd work necessary. time frame:
> > > half a year, maybe one year, but no guarantees.
> >
> > Asking around, I understand oomd only operates at the cgroup level, i.e. it
> > kills an entire cgroup at once, not individual processes. So I understand
> > this would also depend on GNOME-level work to ensure individual applications
> > get launched in their own systemd scopes, yes?
>
> That would be a good idea, yes. But there'd be a knob for that in the
> unit files.
>
> I mean, OOMPolicy= currently can be set to "stop", "kill" or
> "continue", where "stop" means "when a process of service X is OOM
> killed, attempt to shutdown all of X in a friendly way"; "kill" means
> "when a process of service X is OOM killed, forcibly kill all other
> processes of X too"; "continue" means "if a process of service X is
> OOM killed, do nothing else".
Yep, changing the OOMPolicy was considered at first. But creating new
scopes for spawned children is simple enough and it also solves some
other issues (e.g. not killing children when gnome-shell is restarted).
> The expectation here is that most services will want "stop" but
> services that are more "application servers" than an individual
> service (think: apache with its cgi scripts or crond with its
> cronjobs) would set OOMPolicy=continue, since if one of their jobs
> misbheaves they probably should continue running.
>
> But yeah, the focus where things are going are clearly towards making
> a cgroup the unit that is managed as a whole.
Benjamin
signature.asc
Description: This is a digitally signed message part
___
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
Re: Let's talk about Fedora in the '20s!
On Tue, Jan 07, 2020 at 10:36:33AM +0100, Vít Ondruch wrote: > > Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a): > > Le 2020-01-06 19:05, Nicolas Mailhot a écrit : > > > >> Handling those checks is where the packaging toil is (that is, as long > >> as Fedora is a deployment project). It is not something the packaging > >> format makes harder. > > > > However, because our packaging format streamlines those checks, and > > forces to apply them, it is blamed by devs for the impedance mismatch > > between dev and deployment requirements. I think everyone is right ;) It is pretty clear that we've simplified rpm packaging massively over the last few years. It is enough to take a random spec file from 10 years ago, with all the fragile manual steps and compare it with modern spec file that is often just a bit of boilerplate to provide the name, version, license and description, and then call some macros that do all the heavy lifting. We've made great strides in making to bring rpm and upstream packaging closer. And this has been an effort on both sides, both upstream to accommodate workflows required by distros, and on the distro side to wrap those workflows: automatically generated spec for rust packages, pyproject macros, etc, etc. Also spdx licenses, automatic github tarballs… But it is clear that this automatization process is far from complete. And to stay relevant, we (and other distros) need to keep up this work. Without that, we'll never keep up with the infinite supply of upstream projects and we'll stop being useful to users. > We're not adding meaningful end-user value by manually repackaging these in > our own format. We _do_ add value by vetting licenses and insuring > availability and consistency, but I think we can find better ways to do > that. Agreed, with the "manually" part. I think we need to streamline the process, and only require manual operation when unavoidable. I would like to be in a state where "packaging" of various projects using language-specific frameworks is as simple as flipping a switch in some web interface. Matthew Miller wrote: > I think the "source git" project is an interesting step here. OK, as long as we're "just" changing the delivery format (i.e. git archive instead of a tarball), but not trying to package the master branches of various projects. I.e. this must not be about absolving upstreams from having to do releases, but just about cutting out the antiquated intermediate tarball step. > > But, this mismatch is not caused by our packaging format. It is caused > > by devs taking shortcuts because their language packaging format lets > > them. > > > > Well said Nicolas. > > Embracing the "language-native packaging" and "git repos" is giving up > on what Fedora maintainers have always did and that is kicking forward > all the upstreams, because we force them to keep updating the > dependencies (or to maintain compatibility with old versions of > dependencies). Once we embrace "git repos" etc, we will lose our soul > IMO. There won't be any collaboration between upstream projects, which > was cultivated by distribution maintainers. Upstreams will sit in their > silos and bundle everything. > > Also, just today I had discussion if Ruby packages should be more Fedora > tailored or more upstream like and there is no right way which could > reasonably satisfy both worlds. > > E.g. if upstream package has Windows specific dependencies, it is kind > of natural to strip this dependency on Fedora. OTOH, it possibly breaks > a dependency resolving on other platforms, if the project was created > using Fedora packages. This is unfortunately the reason for devs to take > some shortcut, probably to go with upstream way, because if nothing > else, it is typically better documented. I don't know anything about ruby packaging, but I assume that this issue is similar in rust: a solution where upstream and the distro cooperate is required. Dependencies need to be conditionalized by architecture, and downstream packaging needs to use those conditionals as appropriate. In rust, sadly, this is still not the case (https://pagure.io/fedora-rust/rust2rpm/issue/2, https://github.com/rust-lang/cargo/issues/5133). I'm sure we need to and can "reasonably satisfy both worlds". 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
Hi,
[resend this older message for the list]
On Mon, 2020-01-06 at 14:53 -0600, Michael Catanzaro wrote:
> On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
> wrote:
> > - facebook is working on making oomd something that just works for
> > everyone, they are in the final rounds of canonicalizing the
> > configuration so that it can just work for all workloads without
> > tuning. The last bits for this to be deployable are currently being
> > done on the kernel side ("iocost"), when that's in, they'll submit
> > oomd (or simplified parts of it) to systemd, so that it's just there
> > and works. It's their expressive intention to make this something
> > that also works for desktop stuff and requires no further
> > tuning. they also will do the systemd work necessary. time frame:
> > half a year, maybe one year, but no guarantees.
>
> Asking around, I understand oomd only operates at the cgroup level,
> i.e. it kills an entire cgroup at once, not individual processes. So I
> understand this would also depend on GNOME-level work to ensure
> individual applications get launched in their own systemd scopes, yes?
Even if that is the case, on F31 (with GNOME 3.34.2) we do place most
user processes into separate scopes[1]. This is not perfect, because it
currently only affects processes launched by gnome-shell, gnome-
settings-daemon and gnome-session. So everything spawned by e.g.
nautilus (easily fixable) or the terminal may still end up in their
parents scope.
But, I would say the cgroup separation is pretty much good enough
already. So even if it is a requirement, I would not worry about it
beyond making sure that some applications like nautilus get fixes.
Benjamin
[1] They are named gnome-launched-X-Y.scope and get bound to the
lifetime of the session using a drop-in.
Personally I also added a drop-in to limit memory consumption for
Evolution that way. It tends to just disappear sometimes now. Which is
kind of neat but it would be nice to also get a notification.
signature.asc
Description: This is a digitally signed message part
___
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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Tue, 2020-01-07 at 11:44 +0100, Benjamin Berg wrote: > On Tue, 2020-01-07 at 10:21 +, Zbigniew Jędrzejewski-Szmek wrote: > > I'm quoting from my mail from this same thread: > > > > │ ├─gnome-shell-wayland.service > > │ │ ├─1501571 /usr/bin/gnome-shell > > │ │ ├─1501606 /usr/bin/Xwayland :0 -rootless -noreset -accessx > > -core > > -auth /run/user/1000/.mutter-Xwaylandauth.SCXID0 > > -listen 4 -listen 5 -displayfd 6 > > │ │ ├─1501713 ibus-daemon --panel disable -r --xim > > │ │ ├─1501718 /usr/libexec/ibus-dconf > > │ │ ├─1501719 /usr/libexec/ibus-extension-gtk3 > > │ │ ├─1501724 /usr/libexec/ibus-x11 --kill-daemon > > │ │ ├─1501980 /usr/libexec/ibus-engine-simple > > │ │ ├─1503586 /usr/lib64/firefox/firefox > > │ │ ├─1503691 /usr/lib64/firefox/firefox -contentproc -childID 2 > > -isForBrowser ... > > │ │ ├─1503701 /usr/lib64/firefox/firefox -contentproc -childID 3 > > -isForBrowser ... > > │ │ ├─1503747 /usr/lib64/firefox/firefox -contentproc -childID 4 > > -isForBrowser ... > > │ │ ├─1520219 bwrap --args 35 telegram-desktop -- > > │ │ ├─1520229 bwrap --args 35 xdg-dbus-proxy --args=37 > > │ │ ├─1520230 xdg-dbus-proxy --args=37 > > │ │ ├─1520232 bwrap --args 35 telegram-desktop -- > > │ │ ├─1520233 /app/bin/Telegram -- > > │ │ ├─1540753 pavucontrol > > ... > > (Oh, what is the command to get this output?) Aha, systemd-cgls, and this should be a normal F31: │ │ ├─gnome-shell-wayland.service │ │ │ ├─2160536 /usr/bin/gnome-shell │ │ │ ├─2160575 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth /run/user/1000/.mutter-Xwaylandauth.4R9ED0 -listen 4 -listen 5 -displayfd 6 │ │ │ ├─2160744 ibus-daemon --panel disable -r --xim │ │ │ ├─2160754 /usr/libexec/ibus-dconf │ │ │ ├─2160755 /usr/libexec/ibus-extension-gtk3 │ │ │ ├─2160759 /usr/libexec/ibus-x11 --kill-daemon │ │ │ └─2160998 /usr/libexec/ibus-engine-simple Benjamin ___ 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Tue, 2020-01-07 at 10:21 +, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jan 07, 2020 at 11:07:49AM +0100, Benjamin Berg wrote: > > On Tue, 2020-01-07 at 09:47 +, Zbigniew Jędrzejewski-Szmek wrote: > > > I wanted to ask about this too... but didn't know where ;) > > > As of today, gnome-shell in F31 seems to start almost everything > > > as separate systemd user scopes: > > > > > > - various services started automaticlly like /usr/libexec/gsd- > > > power, > > > /usr/libexec/gsd-sound, etc. > > > > > > - flatpaks (this seems to be new, I had them running under > > > gnome-shell-wayland.service last week!) > > > > Hmm, pretty sure flatpaks have always created their own scopes. > > I'm quoting from my mail from this same thread: > > │ ├─gnome-shell-wayland.service > │ │ ├─1501571 /usr/bin/gnome-shell > │ │ ├─1501606 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core > -auth /run/user/1000/.mutter-Xwaylandauth.SCXID0 > -listen 4 -listen 5 -displayfd 6 > │ │ ├─1501713 ibus-daemon --panel disable -r --xim > │ │ ├─1501718 /usr/libexec/ibus-dconf > │ │ ├─1501719 /usr/libexec/ibus-extension-gtk3 > │ │ ├─1501724 /usr/libexec/ibus-x11 --kill-daemon > │ │ ├─1501980 /usr/libexec/ibus-engine-simple > │ │ ├─1503586 /usr/lib64/firefox/firefox > │ │ ├─1503691 /usr/lib64/firefox/firefox -contentproc -childID 2 > -isForBrowser ... > │ │ ├─1503701 /usr/lib64/firefox/firefox -contentproc -childID 3 > -isForBrowser ... > │ │ ├─1503747 /usr/lib64/firefox/firefox -contentproc -childID 4 > -isForBrowser ... > │ │ ├─1520219 bwrap --args 35 telegram-desktop -- > │ │ ├─1520229 bwrap --args 35 xdg-dbus-proxy --args=37 > │ │ ├─1520230 xdg-dbus-proxy --args=37 > │ │ ├─1520232 bwrap --args 35 telegram-desktop -- > │ │ ├─1520233 /app/bin/Telegram -- > │ │ ├─1540753 pavucontrol > ... (Oh, what is the command to get this output?) This is not what I am seeing here. My gnome-shell cgroup only contains the gnome-shell, Xwayland and ibus. And I have separate .scope units for Telegram (flatpak-org.telegram.desktop-2162569.scope), evolution (gnome-launched-org.gnome.Epiphany.desktop-2162690.scope), … And I am pretty sure that flatpak/bwrap has always taken care of scoping flatpaks correctly. Benjamin > > So maybe a bug? I'll keep watching if it happens again. > > > > Stuff started from the run dialog (alt-f2) and from > > > the overview still seems to land in gnome-shell-wayland.service, > > > but maybe this is fixed in gnome-shell 3.35? > > > > This should have changed with the gnome-shell 3.34.2 update in > > Fedora > > 31. It may be that it has not reached rawhide yet though. > > I'm still on gnome-shell-3.34.1-4.fc31.x86_64. I'll try the latest > version. > > > > Another issue is that things that are started through the gnome > > > terminal also land in gnome-terminal-server.service. They need to > > > get their own scopes to make resource allocation robust. > > > > Do you think we should just place each VT into its own scope? > > Yes. Everything starting at the shell (or whatever command is > configured as the "payload", should get its own scope) and a separate > set of resources than gnome-terminal-server.service. > > > That seems like a reasonable start in principle, though graphical > > applications launched from the terminal may still not be moved into > > their own scope then. > > I think it is OK. After all, starting graphical applications from > the terminal is a special case. If desired, the user may run > 'systemd-run --user foo' if they want to segregate it. (Actually, > we might teach some apps to put themselves into a scope when started > from a command line. This makes sense for stuff like firefox, but > also > screen/tmux and others. But I consider this a completely separate > issue.) > > Zbyszek > > > > It seems we're quite close! Do we just need to wait for another > > > gnome release and then we'll have everything nicely segregated? > > > > Likely not perfect, but hopefully close enough for many purposes :) > > > > Benjamin > > ___ 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On 1/7/20 11:07 AM, Benjamin Berg wrote:
> On Tue, 2020-01-07 at 09:47 +, Zbigniew Jędrzejewski-Szmek wrote:
>> On Mon, Jan 06, 2020 at 02:53:13PM -0600, Michael Catanzaro wrote:
>>> On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
>>> wrote:
- facebook is working on making oomd something that just works for
everyone, they are in the final rounds of canonicalizing the
configuration so that it can just work for all workloads without
tuning. The last bits for this to be deployable are currently being
done on the kernel side ("iocost"), when that's in, they'll submit
oomd (or simplified parts of it) to systemd, so that it's just there
and works. It's their expressive intention to make this something
that also works for desktop stuff and requires no further
tuning. they also will do the systemd work necessary. time frame:
half a year, maybe one year, but no guarantees.
>>>
>>> Asking around, I understand oomd only operates at the cgroup level,
>>> i.e. it kills an entire cgroup at once, not individual processes. So
>>> I understand this would also depend on GNOME-level work to ensure
>>> individual applications get launched in their own systemd scopes,
>>> yes?
>>
>> I wanted to ask about this too... but didn't know where ;)
>> As of today, gnome-shell in F31 seems to start almost everything
>> as separate systemd user scopes:
>>
>> - various services started automaticlly like /usr/libexec/gsd-power,
>> /usr/libexec/gsd-sound, etc.
>>
>> - flatpaks (this seems to be new, I had them running under
>> gnome-shell-wayland.service last week!)
>
> Hmm, pretty sure flatpaks have always created their own scopes.
>
>> Stuff started from the run dialog (alt-f2) and from
>> the overview still seems to land in gnome-shell-wayland.service,
>> but maybe this is fixed in gnome-shell 3.35?
>
> This should have changed with the gnome-shell 3.34.2 update in Fedora
> 31. It may be that it has not reached rawhide yet though.
>
Just had a look at awesome, all applications seem to be in the same
cgroup, according to systemd-cgtop. Thus if the whole cgroup would be
killed, that means rather then stopping firefox if it uses to much
memory, my whole session would be terminated.
>> Another issue is that things that are started through the gnome
>> terminal also land in gnome-terminal-server.service. They need to
>> get their own scopes to make resource allocation robust.
>
> Do you think we should just place each VT into its own scope?
>
> That seems like a reasonable start in principle, though graphical
> applications launched from the terminal may still not be moved into
> their own scope then.
>
>> It seems we're quite close! Do we just need to wait for another
>> gnome release and then we'll have everything nicely segregated?
>
> Likely not perfect, but hopefully close enough for many purposes :)
>
> Benjamin
___
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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mo, 06.01.20 14:53, Michael Catanzaro (mcatanz...@gnome.org) wrote:
> On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
> wrote:
> > - facebook is working on making oomd something that just works for
> > everyone, they are in the final rounds of canonicalizing the
> > configuration so that it can just work for all workloads without
> > tuning. The last bits for this to be deployable are currently being
> > done on the kernel side ("iocost"), when that's in, they'll submit
> > oomd (or simplified parts of it) to systemd, so that it's just there
> > and works. It's their expressive intention to make this something
> > that also works for desktop stuff and requires no further
> > tuning. they also will do the systemd work necessary. time frame:
> > half a year, maybe one year, but no guarantees.
>
> Asking around, I understand oomd only operates at the cgroup level, i.e. it
> kills an entire cgroup at once, not individual processes. So I understand
> this would also depend on GNOME-level work to ensure individual applications
> get launched in their own systemd scopes, yes?
That would be a good idea, yes. But there'd be a knob for that in the
unit files.
I mean, OOMPolicy= currently can be set to "stop", "kill" or
"continue", where "stop" means "when a process of service X is OOM
killed, attempt to shutdown all of X in a friendly way"; "kill" means
"when a process of service X is OOM killed, forcibly kill all other
processes of X too"; "continue" means "if a process of service X is
OOM killed, do nothing else".
The expectation here is that most services will want "stop" but
services that are more "application servers" than an individual
service (think: apache with its cgi scripts or crond with its
cronjobs) would set OOMPolicy=continue, since if one of their jobs
misbheaves they probably should continue running.
But yeah, the focus where things are going are clearly towards making
a cgroup the unit that is managed as a whole.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
