Re: Referencing an upstream subdir in the sources
On Wed, Jan 10, 2024 at 12:14 PM Michael J Gruber wrote: > Alternatively, we (used to?) have several packages which need to clean > upstream sources before even committing them to the lookaside cache. I do it for MariaDB for example, deleting part of the sources under unapproved licenses: https://src.fedoraproject.org/rpms/mariadb/blob/rawhide/f/generate-modified-sources.sh Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, Jan 10, 2024 at 12:14 PM Michael J Gruber wrote: > > Am Mi., 10. Jan. 2024 um 11:39 Uhr schrieb Iñaki Ucar > : > > > > Hi, > > > > A package has its source code embedded as a subdirectory of a larger > > piece of software. Sometimes they publish this subdirectory as a > > separate tar as a release artifact, but sometimes they forget. > > > > To avoid depending on their memory (and opening an issue each time), I > > would like to simply download the full repo and produce the tar > > myself. How should I deal with this in the spec? (Note: building this > > subdir as a subpackage in the main one is not a good idea in this > > case, it's not an option). > > Hi, > > I assume you don't want to distribute the full tar and simply cd into > it the proper subdir during the build? That would be the easiest > solution. > > Alternatively, we (used to?) have several packages which need to clean > upstream sources before even committing them to the lookaside cache. > scribus comes to my mind, some crypto things were like that in the > past. What you typically do is: > - Write a simple script which mangles the upstream package.tar and > repackages it as package-free.tar or such. > - Add the script to dist-git. > - comment out the original source line in spec (and the signature if present) > - specify "source: package-free.tar" instead and comment on the use of > the script > - commit only package-free.tar to dist-git > > That way, everyone can reproduce the used source code from the > upstream source code if needed while we only have the actual used > source in dist-git (lookaside). > > Michael > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer wrote: > Asking individual maintainers for trivial changes does not scale. The > alternative would be not to address FTBFS and other build issues, maybe > file bugs, and rely on active maintainers instead. The alternative we want to achieve is: (1) write useful commit messages, so the reasons and goal of the proven package's commit would be clear and (2) give the maintainers the possibility to react. E.g. with a PR. No one responded to the PR in a week? Force merge it with proven packager rights. Even though I would want a longer time window and multiple iterations of trying to contact the maintainer, putting the PR up just for a week would make the current situation considerably better than it is. I would expect the maintainers to only react on PRs in three general ways: (1) asking for more information = likely means you haven't explained the commit or the problem well that marks problem on your side (2) rejecting the PR for a good reason = likely means there's a problem with the implementation of your solution. that marks problem on your side (3) coming up with an alternative solution = likely means you haven't thought of package specific approaches You might find out the packager has a better idea how to solve the problem in general. Or you just collaborated nicely. Each way leads to a valuable end, I believe. There may be more ways to react (e.g. not react at all), but for now let's assume they are not significant, as you'd end up anyway using the proven packagers rights to force merge. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer wrote: > > * Kevin Kofler via devel: > > > Michael J Gruber wrote: > >> I am sick of this. Really. I am so sick of this way of stomping on each > >> others' feet. > > > > My pet peeve is provenpackagers or comaintainers who add unwanted > > automagic (autorelease, autosetup, autochangelog) to my packages. I do > > not want any of that in my packages, it just makes my work harder (or > > in practice, just wastes my time for the revert that I am inevitably > > going to do). > > If the package does not contain any patches yet, it's not really > possible to infer the maintainer intentions. %setup vs %autosetup > doesn't matter much in that case, so it doesn't really tell us anything. > Likewise if the package uses %autosetup, but without -p1, and there are > no patches. Does the maintainer really prefer those awkarward -p-less > patches? We don't know. > > Asking individual maintainers for trivial changes does not scale. The > alternative would be not to address FTBFS and other build issues, maybe > file bugs, and rely on active maintainers instead. But I don't think > that can work for Fedora, practically speaking. Fedora lacks Debian's > ban on forcing packagers to do certain work. In the past, FESCo has > used that to order that certain packagers must keep carrying out certain > work they do not want to do, but I think that only means anything if the > victim packager is a Red Hatter on certain teams, I think. Others will > just quit if they disagree. > > Thanks, > Florian > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
On Tue, Dec 5, 2023 at 11:36 AM Daniel P. Berrangé wrote: > IMHO all changes should be opened as merge requests in pagure. This gives > the regular package maintainers a window of opportunity to review the > change before it is merged. If there's no response from the package > maintainer after a couple of weeks then a proven packager can go ahead > and approve the merge request. Well said. I'd advise to create PR - wait week or 2, if left without response - create BZ for the specific PR as not everyone watches PRs and PR notifications, and wait week or two, if left without response - send a direct mail to the package maintainer. But having at least the PR and a useful commit message would be much appreciated. > At the same time I think it is good to remember that Fedora package > maintainers should think of themselves as guardians, not owners, and > thus should expect to receive contributions from others, including > provenpackagers, doing cleanups to follow Fedora guidelines better. In the case of Fedora, for any part of the project - we should expect to receive contributions. I'd also level up and say, we all should encourage contributions to any part of Fedora. Every maintainer may be in for a different goal, so it may not be applicable to everyone, but I like the parable to maintainer being more of a guardian. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Tue, Dec 5, 2023 at 11:36 AM Daniel P. Berrangé wrote: > > On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote: > > [snip] > > > Granted, these are dissimilar to initial Michaels's issue. But how can I be > > sure that if I touch some of the packages, I won't be told that they were in > > such state for purpose? > > IMHO all changes should be opened as merge requests in pagure. This gives > the regular package maintainers a window of opportunity to review the > change before it is merged. If there's no response from the package > maintainer after a couple of weeks then a proven packager can go ahead > and approve the merge request. > > Essentially proven packagers can follow the same workflow as anyone else > does for contributing to a package that they are not a (co)maintainer of. > They just need the extra priv of being able to approve their own MR at > their discretion. Pushing directly to git, bypassing merge requests, > should not be required in order to achieve what provenpackagers exist > to do. > > At the same time I think it is good to remember that Fedora package > maintainers should think of themselves as guardians, not owners, and > thus should expect to receive contributions from others, including > provenpackagers, doing cleanups to follow Fedora guidelines better. > > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
In my experience through the years, I've found very little proven packagers that would work in what *I would see* as the right way. I too despise random interventions from the higher power to my packages. I rejoiced when the new process of removing inactive proven packagers took place. And I'd love to see the proven packagers losing their rights regularly for breaking the guidelines. (Especially when there's nothing much stopping them to request the proven packager status again and again, but I hope in the small PITA of doing that might give them time for a reflection on why they lost it and try better next time) "Prior to making changes, provenpackagers should try to communicate with owners of a package in bugzilla, dist-git pull request, IRC, matrix, or email. They should be careful not to change other people’s packages needlessly and try to do the minimal changes required to fix problems, as explained more in depth in Who is Allowed to Modify Which Packages." https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ In this particular case, if the commit was urgently needed by the proven packager, I'd expect at least an explanation in the commit message, what bigger whole this is part of (link to BZs or Fedora change, or something). If it wasn't urgent, I'd say PR would be in place instead. (with the same reasoning included in the commit message) I was raised (as a maintainer) watching closely the proven packager 'praiskup', which uses his powers conscientiously like no other proven packager I've ever experienced. Especially early in my packager career, I've gone to him many times, asking for proven packager intervention that would come handy to me. I was refused every time, with a good explanation of the processes I should take before residing to the very last option - the proven packager intervention. It taught me a lot. Through the years I was even thinking about becoming a proven packager myself several times. However I haven't requested it in the end, because, even when I did changes across dozens and dozen of packages, there was never ever a time, where I would *need* to reside to the proven packager powers to get my work done, as the standard ways of contacting regular owners of the packages before that always worked. (PR then BZ, then mail, then mailing list. I haven't even needed to activate 'Policy for nonresponsive package maintainers'.) But I have a strong feeling the proven packagers powers are commonly used because they are handy, instead of them being necessary. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Fri, Dec 1, 2023 at 11:35 PM Mamoru TASAKA wrote: > > Sérgio Basto wrote on 2023/12/02 0:49: > > On Fri, 2023-12-01 at 16:26 +0100, Michael J Gruber wrote: > >> So, due to me following my package (notmuch) upstream and testing > >> early against upstream's git, reporting and working with upstream, I > >> noticed a FTBFS and helped fixing it. Nothing urgent since it was > >> basically just a test failing for the wrong reasons. > >> > >> Within a few days, upstream releases a patch release. Within hours, > >> I'm testing (again, since it's basically what was on git already) on > >> copr and koji, writing a nice commit message, push to rawhide ... > >> > >> ... and get a reject because someone thought that pushing directly > >> without asking or at least notifying the maintainer would be in > >> order: > >> > >> https://src.fedoraproject.org/rpms/notmuch/c/f0d84b417694430874a150293ffdb1fdc35c7b31?branch=rawhide > > > > > >> Why? For a FTBFS due to a test? No bugzilla, no FTI, no security > >> issue whatsoever? > >> > > > > You may kindly ask to mtasaka why did it ? , and also alert him that > > package is well maintain and have a quick response and kindly ask to do > > PR instead , he is one provenpackager and I sure that he did that in > > hope of improve the package, I'm sure that he will understand. > > > > Best regards, > > So to explain, notmuch was FTBFS. > And we are going to rebuild packages which depends on libruby.so.3.2 as > announced as: > > https://fedoraproject.org/wiki/Changes/Ruby_3.3 > > We are testing beforehand whether packages can rebuild against new ruby > beforehand, and trying to fix **just** FTBFS beforehand because if the package > has FTBFS anyway (regardless of whether the reason is related to ruby or > not, such package will have broken deps after mass rebuild). > > notmuch is this target. > > Regards, > Mamoru > > > > > > > > >> I am sick of this. Really. I am so sick of this way of stomping on > >> each others' feet. > >> > >> It's made worse by failing automated no
Re: Ancient compilation flags in my pkg - still needed ?
On Thu, Nov 30, 2023 at 11:53 AM Priscila Gutierres wrote: > When reading your email I thought about this video > https://youtu.be/U4ALzqqUIS8?si=_D5seS8Nu_0fxYdO Yeah, on point :) But as long as I get commit messages explaining *what* has been done (which is obvious from the code), instead of *why* it was done, I'm more of an archeologist, than a software engineer. If people would write *useful* commit messages, I wouldn't need to ask such questions. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Nov 30, 2023 at 11:53 AM Priscila Gutierres wrote: > > When reading your email I thought about this video > > https://youtu.be/U4ALzqqUIS8?si=_D5seS8Nu_0fxYdO > > > Em qui., 30 de nov. de 2023 às 07:50, Michal Schorm > escreveu: >> >> I have this line in the SPECfile of 'mariadb' package: >> >> CFLAGS="$CFLAGS -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE" >> >> Git blame says this line will soon celebrate 20 years: >> https://src.fedoraproject.org/rpms/mysql/c/b3810a49b3125662999f444810efd0fd3223612b?branch=rawhide >> https://src.fedoraproject.org/rpms/mysql/c/45466935f338593601cf8653b582dce92752152f?branch=rawhide >> >> As I'm not very good at baking cakes, I'm researching the possibility >> of removing the line instead. >> >> I read through these macros explanations: >> https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html >> however as I do not navigate well in the problematic, I haven't understood >> much. >> >> My question is primarily, whether during the last 20 years something >> happened, making the line obsolete (e.g. these macros are no longer >> relevant, or they were added to the default build flags, ... ) >> >> Michal >> >> -- >> >> Michal Schorm >> Software Engineer >> Core Services - Databases Team >> Red Hat >> >> -- >> -- >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue > > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Ancient compilation flags in my pkg - still needed ?
I have this line in the SPECfile of 'mariadb' package: CFLAGS="$CFLAGS -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE" Git blame says this line will soon celebrate 20 years: https://src.fedoraproject.org/rpms/mysql/c/b3810a49b3125662999f444810efd0fd3223612b?branch=rawhide https://src.fedoraproject.org/rpms/mysql/c/45466935f338593601cf8653b582dce92752152f?branch=rawhide As I'm not very good at baking cakes, I'm researching the possibility of removing the line instead. I read through these macros explanations: https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html however as I do not navigate well in the problematic, I haven't understood much. My question is primarily, whether during the last 20 years something happened, making the line obsolete (e.g. these macros are no longer relevant, or they were added to the default build flags, ... ) Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: old RPM code in my package - safe to remove this bit ?
On Thu, Nov 30, 2023 at 1:19 AM Tom Hughes via devel
wrote:
> It hasn't been needed for a long time.
Good, thanks. Off it goes. :)
> It's just making %license an alias for %doc if your building
> for a release old enough that %license isn't supported, as
> detected by checking if %licensedir is defined.
Why is it checked through the %licensedir macro, and not the %license
VFT instead?
If %doc VFT could be used as an actual value for a macro, I'd assume
it could be used in conditional too. (to verify whether such VFT
exists)
Michal
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Thu, Nov 30, 2023 at 1:19 AM Tom Hughes via devel
wrote:
>
> On 30/11/2023 00:14, Michal Schorm wrote:
>
> > I've stumbled upon this piece of code in my package:
> ># Define license macro if not present
> >%{!?_licensedir:%global license %doc}
> >
> > https://src.fedoraproject.org/rpms/mariadb/blob/rawhide/f/mariadb.spec#_322
> >
> > Git blame points out 7 year old commit:
> > https://src.fedoraproject.org/rpms/mariadb/c/e3d4b2f14e5e0cb7b42b468ffb9de6ff39e3d248?branch=rawhide
> >
> > The RPM docs says the %license 'Virtual File Attribute' was added in
> > version 4.11, which has been added to Fedora years before the commit
> > above:
> > https://src.fedoraproject.org/rpms/rpm/c/2970ed07c98c8929eca0bdfebda389af5a2ef92d?branch=rawhide
> >
> > I tried to remove the line and I haven't noticed any differences in
> > output of "rpm -q -d " and "rpm -q -L " before and after.
> >
> > I'm not even sure what the line is trying to do - I read it as "under
> > some condition, create %license global macro with value %doc".
>
> It's just making %license an alias for %doc if your building
> for a release old enough that %license isn't supported, as
> detected by checking if %licensedir is defined.
>
> It hasn't been needed for a long time.
>
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Packaging guidelines - dynamic allocation of users and groups
On Thu, Nov 30, 2023 at 12:54 AM Zbigniew Jędrzejewski-Szmek
wrote:
> Yeah, there are no guidelines for this case because it didn't really
> come up before. I think this case can be used to figure out the best
> way to do this and then the guidelines can be informed by the solution.
Okay. I don't mind being a pioneer.
I asked to avoid reinventing the wheel.
> So actually systemd does _not_ exactly pick up the file. The macro
> generates code to create the user in %pre. The systemd-sysusers.service
> will also look at this sysusers file, but by the time it gets run,
> the user/group already exist to it doesn't do anything.
Alright, thanks for the explanation.
I hacked together a working example.
I'll present it after some polishing and testing that it actually works.
> There's yet another twist to this story: rpm is getting support
> for sysusers natively, so %sysusers_create_compat will go away and
> the guidelines will need to be updated. But I think it should be
> fine to start with %sysusers_create_compat and get the subpackage
> working, and then this details of the implementation can be adjusted
> later.
Given the several years delay before I noticed the change:
https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format
I doubt it wouldn't be worth updating at least to the *current* format :)
Michal
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Thu, Nov 30, 2023 at 12:54 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, Nov 29, 2023 at 08:04:11PM +0100, Michal Schorm wrote:
> > I maintain the packages 'mariadb' and 'community-mysql'.
> > Sub-packages of each of them need the user 'mysql' to be present prior
> > installation.
> > Both manually create the user in the %pre section.
> >
> > I found out a different system should be used nowadays:
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation
> > Introduced by this change:
> > https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format
> >
> > However while the change talks about the possibility of a setup of
> > multiple packages requiring the same user, the packaging guidelines do
> > not cover this topic.
> >
> > I'm not sure how to implement it properly, so I need help with my case,
> > and I ask for the guidelines to be extended.
>
> Yeah, there are no guidelines for this case because it didn't really
> come up before. I think this case can be used to figure out the best
> way to do this and then the guidelines can be informed by the solution.
>
> > The MariaDB upstream ships a simple 'sysusers.conf' file.
> > I already pack it, so the resulting RPM already has - thanks to this:
> > | Provides:
> > |group(mysql)
> > |user(mysql)
> > Based on the documentation in the guidelines, I guess it's never
> > actually applied though, since I always define the user manually,
> > before the sysuser file could take effect.
> >
> > I'd like to move the 'sysusers.conf' file to a separate sub-package,
> > and use it by both mariadb-server and community-mysql-server RPMs.
> >
> > I guess the following code would be for the sub-package shipping the
> > 'sysusers.conf' file:
> > | %package system-user-mysql
> > | Summary: This package provides system user 'mysql'
> > | %description system-user-mysql
> > | This package provides system user 'mysql'
> > |
> > | %files system-user-mysql
> > | %{_sysusersdir}/%{pkg_name}.conf
> >
> > And then for the 'mariadb-server', which needs the user, the code would be:
> > | Requires(pre): user(mysql)
> > | Requires(pre): group(mysql)
> This all looks reasonable.
>
> > but I'm not sure whether I'm not missing any of those, and/or where:
> > | BuildRequires: systemd-rpm-macros
> > | %{?sysusers_requires_compat}
> > |
> > | %pre
> > | %sysusers_create_compat %{SOURCE3}
> Those should be attached to the subpackage that has the sysusers file.
>
> > Likely because I don't understand where/when the systemd picks up,
> > recognizes the installed file and actually creates the user, if it
> > does not exist already.
> So actually systemd does _not_ exactly pick up the file. The macro
> generates code to create the user in %pre. The systemd-sysusers.service
> will also look at this sysusers file, but by the time it gets run,
> the user/group already exist to it doesn't do anything.
>
> There's yet another twist to this story: rpm is getting support
> for sysusers natively, so %sysusers_create_compat will go away and
> the guidelines will need to be updated. But I think it should be
> fine to start wi
old RPM code in my package - safe to remove this bit ?
Hi,
I've stumbled upon this piece of code in my package:
# Define license macro if not present
%{!?_licensedir:%global license %doc}
https://src.fedoraproject.org/rpms/mariadb/blob/rawhide/f/mariadb.spec#_322
Git blame points out 7 year old commit:
https://src.fedoraproject.org/rpms/mariadb/c/e3d4b2f14e5e0cb7b42b468ffb9de6ff39e3d248?branch=rawhide
The RPM docs says the %license 'Virtual File Attribute' was added in
version 4.11, which has been added to Fedora years before the commit
above:
https://src.fedoraproject.org/rpms/rpm/c/2970ed07c98c8929eca0bdfebda389af5a2ef92d?branch=rawhide
I tried to remove the line and I haven't noticed any differences in
output of "rpm -q -d " and "rpm -q -L " before and after.
I'm not even sure what the line is trying to do - I read it as "under
some condition, create %license global macro with value %doc".
However as %license and %doc are both Virtual File Attributes, I doubt
they can be overwritten to become macros. And if it could be, I can't
imagine what value will be given to the macro, as I'd guess that the
%doc Virtual File Attribute does not have any value but instead is
used as a keyword for the parser.
--
The questions are:
(1) is it safe to remove ?
(2) does it actually do anything?
(3) if yes, what does it do ?
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Packaging guidelines - dynamic allocation of users and groups
I maintain the packages 'mariadb' and 'community-mysql'.
Sub-packages of each of them need the user 'mysql' to be present prior
installation.
Both manually create the user in the %pre section.
I found out a different system should be used nowadays:
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation
Introduced by this change:
https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format
However while the change talks about the possibility of a setup of
multiple packages requiring the same user, the packaging guidelines do
not cover this topic.
I'm not sure how to implement it properly, so I need help with my case,
and I ask for the guidelines to be extended.
--
The MariaDB upstream ships a simple 'sysusers.conf' file.
I already pack it, so the resulting RPM already has - thanks to this:
| Provides:
|group(mysql)
|user(mysql)
Based on the documentation in the guidelines, I guess it's never
actually applied though, since I always define the user manually,
before the sysuser file could take effect.
I'd like to move the 'sysusers.conf' file to a separate sub-package,
and use it by both mariadb-server and community-mysql-server RPMs.
I guess the following code would be for the sub-package shipping the
'sysusers.conf' file:
| %package system-user-mysql
| Summary: This package provides system user 'mysql'
| %description system-user-mysql
| This package provides system user 'mysql'
|
| %files system-user-mysql
| %{_sysusersdir}/%{pkg_name}.conf
And then for the 'mariadb-server', which needs the user, the code would be:
| Requires(pre): user(mysql)
| Requires(pre): group(mysql)
but I'm not sure whether I'm not missing any of those, and/or where:
| BuildRequires: systemd-rpm-macros
| %{?sysusers_requires_compat}
|
| %pre
| %sysusers_create_compat %{SOURCE3}
Likely because I don't understand where/when the systemd picks up,
recognizes the installed file and actually creates the user, if it
does not exist already.
Michal
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 MariaDB MySQL repackaging (Self-Contained)
Hi,
On Fri, Oct 20, 2023 at 1:12 AM Kevin Kofler via devel
wrote:
>
> > * Rename package 'community-mysql' to 'mysql' and Stop providing
> > 'mysql' symbols by package 'mariadb'
>
> Why not just drop community-mysql (and keep mariadb as the provider of
> mysql*) instead? I really do not see why we need to ship 2 competing forks
> of the same database in Fedora. Applications typically do not even notice
> the difference.
>
> > When MariaDB was introduced to Fedora, it seemed like it eventually
> > replaces MySQL
>
> Is that not what has happened? Who still uses the Oracle crippleware?
>
> As I understand it, most distros are shipping only MariaDB.
MySQL is definitely still on the scene. Few examples from the big distros here:
Ubuntu:
https://packages.ubuntu.com/search?suite=default=all=any=mysql=names
Arch: https://aur.archlinux.org/packages/mysql
Some distros dropped MySQL entirely, some favors MariaDB. None of that
changes the fact that MySQL still is a popular DB.
Take a look how many people use, or want to learn MySQL:
https://survey.stackoverflow.co/2023/#most-popular-technologies-database
https://survey.stackoverflow.co/2022/#most-popular-technologies-database
What I want to do in Fedora is to merely recognize that MariaDB and
MySQL are not fully interchangeable (drop-in) anymore. Their abilities
and feature set grow diverse, so they both should have their own
designated place, without pretending or confusion on which is which.
> > I want to change the packaging structure so the result will look as
> > follows: * The unversioned name ('mariadb') will become a meta-package
> > ** It will point to the one versioned variant which I choose to be the
> > default one for the given Fedora release
> > ** It will provide all of the unversioned names for the versioned
> > variant that is default for the given Fedora release, to minimize the
> > changes visible to the users
> > * All other versions will have their own versioned package (e.g
> > "mariadb10.5" "mariadb10.11") and will conflict with each other
> >
> > This will allow for:
> > * users to keep using the unversioned names they are used to
> > * maintainer to change the default version for a given Fedora release
> > on a single, centralized place
> > * users to enjoy all of the features of the modularity I offered them,
> > in a simpler way
> > * maintainer to add new versions quickly, without any need of changing
> > the default version (other than adding new conflicts)
>
> There is a major issue with this approach: Users installing Fedora 40 will
> get the mariadb metapackages dragging in mariadb10.11. Then they upgrade to
> Fedora 41 or 42 or whatever that will ship mariadb10.whatever. So then
> mariadb will want to drag in mariadb10.whatever, but mariadb10.11 will also
> want to get upgraded, leading to a conflict that DNF will not be able to
> resolve in a satisfactory way. (Most likely, it will upgrade mariadb10.11,
> keep the old Fedora n-1 version of the mariadb metapackage, and never
> install the new mariadb10.whatever.)
>
> The default version should just be unversioned, instead of having the
> unversioned package be a metapackage.
Thanks for pointing that out, I'll look into it.
> > Note:
> > I specifically don't want the packages to be parallel installable. I
> > only want them to be parallel available.
>
> That makes it a lot less useful to use versioned package names.
>
> I suggest you ship one set of MariaDB packages in Fedora, and then use Copr
> to distribute different versions (which would also be named mariadb, not
> e.g. mariadb10.5 or mariadb10.11, and just have, say, Version: 10.5 and,
> since that is a downgrade compared to the official packages, Epoch: n+1,
> where n is the Epoch of the official packages). To switch to a non-default
> version, one would just dnf copr enable @mariadb-sig/mariadb-10.5 && dnf
> upgrade (or distro-sync, but since it would be an "upgrade" at RPM level,
> distro-sync is not needed here), and to switch back to the default version,
> dnf copr disable @mariadb-sig/mariadb-10.5 && dnf distro-sync (to
> "downgrade" to the official packages' lower EVR).
I would like to have the alternative versions "closer" to Fedora.
COPR is somehow "far", requiring users to be educated to know where to
look and what to search for.
I hope the parallel availability will significantly enhance the user
experience, over any kind of "distant" repos.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Fri, Oct 20, 2023 at 1:12 AM Kevin Kofler via devel
wrote:
>
> > * Rename package 'community-mysql' to 'mysql' and Stop pro
[rpms/perl-DBD-MySQL] PR #2: 5.001 bump; Package tests
mschorm commented on the pull-request: `5.001 bump; Package tests` that you are following: `` Also applies to the other 4 occurrences in the code. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-DBD-MySQL/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-DBD-MySQL] PR #2: 5.001 bump; Package tests
mschorm commented on the pull-request: `5.001 bump; Package tests` that you are following: `` I don't think the ` >= 8` is relevant. Unless you expect this code to be picked to the RHEL 7. :smile: RHEL 8 and later has MySQL 8 as a default version. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-DBD-MySQL/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Unannounced soname bump: libotf
On Wed, Jul 26, 2023 at 5:32 PM Jason L Tibbitts III wrote:
>
> >>>>> Gary Buhrmaster writes:
>
> > I have found that using something like libfoo.so.X{,.*} in the %files
> > directive can be a useful reminder (enforcer) to reduce such surprises
> > (that particular glob presumes semantic versioning, and that minor and
> > patch level updates do not require rebuilds, but that is true much of
> > the time).
>
> In fact, excessively wide globbing here is explicitly discouraged by the
> packaging guidelines:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files
>
> Looking at the current spec, it uses "%{_libdir}/*.so.*"; had it
> followed this guideline, I believe this issue would not have occurred.
I agree, fixed:
https://src.fedoraproject.org/rpms/libotf/c/0ccd534c?branch=rawhide
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Wed, Jul 26, 2023 at 5:32 PM Jason L Tibbitts III wrote:
>
> >>>>> Gary Buhrmaster writes:
>
> > I have found that using something like libfoo.so.X{,.*} in the %files
> > directive can be a useful reminder (enforcer) to reduce such surprises
> > (that particular glob presumes semantic versioning, and that minor and
> > patch level updates do not require rebuilds, but that is true much of
> > the time).
>
> In fact, excessively wide globbing here is explicitly discouraged by the
> packaging guidelines:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files
>
> Looking at the current spec, it uses "%{_libdir}/*.so.*"; had it
> followed this guideline, I believe this issue would not have occurred.
>
> - J<
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Unannounced soname bump: libotf
My apologies ! I built the new version when cleaning old PRs and I failed to check for the soname bump. Thank you for cleaning up after me. I will try my best to remember to check it next time. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, Jul 26, 2023 at 3:02 PM Scott Talbert wrote: > > On Tue, 25 Jul 2023, Scott Talbert wrote: > > >> libotf was just bumped from libotf.so.0 to libotf.so.1. > >> > >> $ dnf repoquery --whatrequires 'libotf.so.0()(64bit)' --disablerepo='*' > >> --enablerepo=rawhide > >> emacs-1:28.2-6.fc39.x86_64 > >> emacs-lucid-1:28.2-6.fc39.x86_64 > >> libotf-devel-0:0.9.13-22.fc38.x86_64 > >> m17n-lib-tools-0:1.8.2-1.fc39.x86_64 > >> > >> Please announce soname bumps in advance and coordinate rebuilds in side > >> tags. :) > > > > It looks like m17n-lib needs to be rebuilt first and then emacs can be > > rebuilt. > > > > @mfabian, can you please take care of m17n-lib? > > Thanks @besser82 for taking care of these! > > Scott > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 38 Cinnamon Desktop - LIGHTDM.SERVICE FAIL..!!!!
Might be a shot into the dark, but I had this problem a few times, when I had lightdm installed, but not the X-server. For example on my laptop, I have following packages present: # rpm -qa | grep -i Xorg xorg-x11-xauth-1.1.2-2.fc37.x86_64 xorg-x11-xbitmaps-1.1.2-2.fc37.noarch xorg-x11-xinit-1.4.0-15.fc37.x86_64 xorg-x11-fonts-ISO8859-1-100dpi-7.5-34.fc37.noarch xorg-x11-fonts-ISO8859-1-75dpi-7.5-34.fc37.noarch xorg-x11-fonts-misc-7.5-34.fc37.noarch xorg-x11-fonts-Type1-7.5-34.fc37.noarch xorg-x11-drv-libinput-1.2.1-2.fc37.x86_64 abrt-addon-xorg-2.16.1-1.fc37.x86_64 xorg-x11-server-common-1.20.14-23.fc37.x86_64 xorg-x11-server-Xorg-1.20.14-23.fc37.x86_64 xorg-x11-server-Xwayland-22.1.9-2.fc37.x86_64 Could you please share your list of Xorg packages ? -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Fri, Jun 30, 2023 at 12:48 PM Leigh Scott wrote: > > > sudo dnf -y in lightdm-autologin-greeter > > > > > > [+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log > > [+0.00s] DEBUG: Starting Light Display Manager 1.32.0, UID=0 PID=5256 > > [+0.00s] DEBUG: Loading configuration dirs from > > /usr/share/lightdm/lightdm.conf.d > > [+0.00s] DEBUG: Loading configuration from > > /usr/share/lightdm/lightdm.conf.d/50-backup-logs.conf > > [+0.00s] DEBUG: Loading configuration from > > /usr/share/lightdm/lightdm.conf.d/50-disable-guest.conf > > [+0.00s] DEBUG: Loading configuration from > > /usr/share/lightdm/lightdm.conf.d/50-minimum-vt.conf > > [+0.00s] DEBUG: Loading configuration from > > /usr/share/lightdm/lightdm.conf.d/50-run-directory.conf > > [+0.00s] DEBUG: Loading configuration from > > /usr/share/lightdm/lightdm.conf.d/50-session-wrapper.conf > > [+0.00s] DEBUG: Loading configuration from > > /usr/share/lightdm/lightdm.conf.d/50-user-authority-in-system-dir.conf > > [+0.00s] DEBUG: Loading configuration from > > /usr/share/lightdm/lightdm.conf.d/50-xserver-command.conf > > [+0.00s] DEBUG: Loading configuration from > > /usr/share/lightdm/lightdm.conf.d/60-lightdm-autologin-greeter.conf > > [+0.00s] DEBUG: Loading configuration from > > /usr/share/lightdm/lightdm.conf.d/60-lightdm-gtk-greeter.conf > > [+0.00s] DEBUG: Loading configuration from > > /usr/share/lightdm/lightdm.conf.d/90-slick-greeter.conf > > [+0.00s] DEBUG: Loading configuration dirs from > > /usr/local/share/lightdm/lightdm.conf.d > > [+0.00s] DEBUG: Loading configuration dirs from > > /etc/xdg/lightdm/lightdm.conf.d > > [+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf > > [+0.00s] DEBUG: Using Xephyr for X servers > > [+0.00s] DEBUG: Registered seat module local > > [+0.00s] DEBUG: Registered seat module xremote > > [+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager > > [+0.00s] DEBUG: Using cross-namespace EXTERNAL authentication (this will > > deadlock if > > server is GDBus < 2.73.3) > > [+0.00s] DEBUG: _g_io_module_get_default: Found default implementation > > local (GLocalVfs) > > for ?gio-vfs? > > [+0.01s] DEBUG: Monitoring logind for seats > > [+0.01s] DEBUG: New seat added from logind: seat0 > > [+0.01s] DEBUG: Seat seat0: Loading properties from config section Seat:* > > [+0.01s] DEBUG: Seat seat0 has property CanMultiSession=no > > [+0.01s] DEBUG: Seat seat0: Starting > > [+0.01s] DEBUG: Seat seat0: Creating greeter session > > [+0.01s] DEBUG: Seat seat0: Creating display server of type x > > [+0.01s] DEBUG: Using VT 1 > > [+0.01s] DEBUG: Seat seat0: Starting local X display on VT 1 > > [+0.01s] DEBUG: XServer 1: Logging to /var/log/lightdm/x-1.log > > [+0.01s] DEBUG: XServer 1: Can't launch X server Xephyr, not found in path > > [+0.01s] DEBUG: XServer 1: X server stopped > > [+0.01s] DEBUG: Releasing VT 1 > > [+0.01s] DEBUG: Seat seat0: Display server stopped > > [+0.01s] DEBUG: Seat seat0: Can't create display server for greeter > > [+0.01s] DEBUG: Seat seat0: Session stopped > > [+0.01s] DEBUG: Seat seat0: Stopping display server, no sessions require it > > [+0.01s] DEBUG: Seat seat0: Stopping > > [+0.01s] DEBUG: Seat seat0: Stopped > > [+0.01s] DEBUG: Failed to start seat: seat0 > > That output isn't useful, also lightdm-autologin-greeter has no gui, you > should remove it. > File a bugreport with the required logs from /var/log/lightdm > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wik
Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)
> Moreover, it's designed to give the end users a simple workflow to build > their own custom images. That's something I'd be interested in. I always have an USB drive (or several) with Fedora ISO(s) lying around, being handy from time to time. Having them customized *easily*, sounds like a great thing to have. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Mon, Jun 26, 2023 at 4:34 PM Aoife Moloney wrote: > > https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > > > == Summary == > Image Builder is a set of modern tools for building operating system > images. Its goal is to make the builds reliable and reproducible. > Moreover, it's designed to give the end users a simple workflow to > build their own custom images. The aim of this change is to switch the > build tool for Fedora Workstation live ISO from livemedia-creator to > Image Builder. > > == Owner == > * Name: [[User:obudai|Ondřej Budai]] > * Email: obu...@redhat.com > * Name: [[User:Supakeen|Simon de Vlieger]] > * Email: supak...@redhat.com > * Name: [[User:jkonecny|Jiří Konečný]] > * Email: jkone...@redhat.com > > > > == Detailed Description == > Image builder is currently getting support for building > [https://github.com/osbuild/osbuild-composer/pull/3440 live ISOs]. > Once the PR implementing the new image type is merged, > [https://pagure.io/pungi-fedora/blob/8b2c85799cce5c096484cdebe1dbe521eaf7fe92/f/fedora.conf#_530 > the pungi-fedora configuration] needs to be updated. This change will > ensure that pungi creates an osbuildImage task in koji instead of the > currently used livemedia one. > > Pungi and Koji already support Image Builder, so no additional work is > required there (refer to the > [https://docs.pagure.org/pungi/configuration.html#osbuild-composer-for-building-images > pungi] and [https://github.com/osbuild/koji-osbuild/ koji] > documentation). The only missing part in terms of infrastructure is > provisioning ppc64le worker machines for Image Builder, see the > relevant [https://pagure.io/fedora-infrastructure/issue/11243 > fedora-infra ticket]. > > Note that Image Builder is already used for > [https://fedoraproject.org/wiki/Changes/IoTArtifactsWithOSBuild > building ISOs and raw disks of Fedora IoT]. Therefore, this proposal > does not introduce a new tool to the Fedora build pipeline. > > == Feedback == > > Currently, Image Builder does not populate the DNF database correctly, > leading to all RPMs installed on the target system being marked as > user-installed. This is [https://github.com/osbuild/osbuild/issues/455 > a known issue] that the team is planning to address as soon as the > initial support for live ISOs is merged. > > > == Benefit to Fedora == > The maintainer team of Image Builder believes that the project > undergoes more comprehensive testing compared to > lorax/livemedia-creator. Thus, by switching to Image Builder, Fedora > should experience fewer issues with the image building pipeline. > > Another advantage is the project's emphasis on making Image Builder > more user-friendly. End users can easily build their own customized > version of the live ISO using a simple > [https://www.osbuild.org/guides/image-builder-on-premises/blueprint-reference.html > TOML blueprint file] and a > [https://www.osbuild.org/guides/image-builder-on-premises/building-an-image-from-cli.html > CLI interface]. This approach, utilizing well-known file formats, is a > positive step compared to livemedia-creator's kickstart files. More > information about building customized images can found on > [https://major.io/p/build-custom-centos-stream-cloud-image/ Major > Hayden's blog] or in > [https://www.youtube.com/watch?v=PsQySAEOeFs=17001s a conference > talk] given by Ondřej Budai, one of the proposal owners. Moreover, > Image Builder provides [https://github.com/osbuild/cockpit-composer/ a > graphical interface] for visually defining blueprints, further > simplifying the workflow. > > We believe that Image Builder can also be beneficial to the > [https://fedoraproject.org/wiki/Respins-SIG Respins SIG] as it nicely > aligns with their objective of providing a simple method for building > up-to-date, customizable images. > > == Scope == > * Proposal owners: > Finishing implementing support for the live ISO upstream and > collaborate with release engineering to switch the pungi config to use > Image Builder. > > * Other developers: > Our f
Re: Two Years of Fedora Releases
That depends on what you are looking for. There are a lot of distributions out there, each with different goals. Pick one which goals are closest to yours. However if you really want Fedora without upgrading often, try to run Fedora Rawhide - our development branch. You will have to deal with some downgrading of bugged package updates from time to time, but in the last few years, it's stability is quite good and I heard of a number of people using it on a daily basis. That should feel like a rolling release - without ever upgrading, just updating. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Fri, Jun 23, 2023 at 12:59 PM Arthur Bols wrote: > > On 23/06/2023 12:41, مصعب الزعبي wrote: > > It will be more stable, effective, natural-friendly and feasible if we > > make Fedora lifetime as: > > > > - One year between releases. > > - Two year of release lifetime. > > > > > That doesn't really work with our "First" goal [0]. Then we're just > another Ubuntu. > > [0]: https://docs.fedoraproject.org/en-US/project/#_first > > -- > Arthur Bols > fas/irc: principis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: What is Fedora?
I'm a Red Hat employed engineer, working on all Fedora, CentOS Stream and RHEL. This is what each means for me in particular (but should also be applicable in general) in practice: * RHEL - only when I'm bound by some legal requirement (embargo, etc.) I do work 'RHEL only' (not visible in CentOS stream). In practice, such work is expected to be seen in CentOS Stream once the legal barrier falls / expires. * CentOS Stream - all work (except abovementioned) for RHEL is done here. The code has been available here (for 2 years already for C9S): https://gitlab.com/redhat/centos-stream/ Are you missing anything? (codebase-wise) This means my work on RHEL is visible unlike ever before. Open to submissions via merge requests Also merge requests where I develop changes are open to examination during my development of them. (unlike anytime before) * Fedora - unlike RHEL or CentOS, this is the place where I can develop new features. I don't have this space downstream. So tuning packaging, trying out various enhancements, adopting big upstream changes, packing latest greatest upstream releases. All that will be branched to form a new RHEL one day. This is the only way for me to introduce big changes. As I see it, both RHEL and Fedora profit from that to maximum. And I don't expect this relationship to go away anytime soon. However I might have misunderstood the core of this discussion. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Jun 22, 2023 at 11:39 AM Miroslav Suchý wrote: > > Dne 22. 06. 23 v 10:44 Michael J Gruber napsal(a): > > In each case, the way it was done and communicated was literally begging > > for bad press. > > ... > > > > So, the signal is either "we don't care about our upstream" or "we do not > > understand upstream's importance and concerns". > > None of the last two. It is first one out of these three: wrongly > communicated and begging for bad press. > > I think that RH engineers are pretty bad in communicating things. Me included. > > -- > Miroslav Suchy, RHCA > Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Are we ready for ipv6-mostly networks?
Thought: (disclaimer: I don't know much about networking) IPv4 addresses are in some cases 'human readable' / 'human usable' / 'human friendly'. How can one set up a temporary network of several devices for a LAN party or any similar connecting application use cases? From my own experience, the vast majority of people have no idea that when one tells you "write in: ten zero zero eight", they have to put dots in between. Because they have no idea what IP address is and how it's formatted. I can't imagine I would say this out loud to even a tech experienced person and they would get it right the first time. 1a01:4204:b07d:af00:21c6:542a:611:73ea Not mentioning all the times I need to connect devices in many rooms across several floors in the whole building. Is there any easy way to keep exchanging the IP address 'human usable' ? -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, May 25, 2023 at 10:51 PM Petr Menšík wrote: > > Hello everyone, > > I have attended recently csnog.eu conference [1], where some interesting > presentations took place. They were usually in Czech, so it is not > something I am going to share more. But what took my interest were ipv6 > readiness with some exceptions. Fedora is ready to be run on dual-stack > IPv4 and IPv6 networks just fine. But the presentation were about future > case where we run most hosts on IPv6 network only, but allow some older > devices to take and use also IPv4 address. > > Fortunately there is roughly the same presentation[2] in English, which > took the place on RIPE 85 meeting. What catched my interest were talk > about Windows 11 and Apple systems are ready, but not really talk about > how any linux distribution is ready for such situation. It seems to me > we should improve the support for mentioned mechanisms in Fedora. > > What do you think about it? > > [1] https://indico.csnog.eu/event/13/contributions/121/ > [2] https://ripe85.ripe.net/archives/video/923/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPECfiles - conditionals with EOLed Fedora releases - any value in keeping them ?
On Thu, Jan 19, 2023 at 4:04 PM Ewoud Kohl van Wijngaarden
wrote:
> >Do you agree it would be safe to remove such conditionals and the code
> >they hold ?
>
> Only if they're purely for Fedora. In many examples you also see a rhel
> conditional and that could be used for EPEL. A good number of packagers
> like to use the same spec since it reduces maintenance burden on
> updates. So in that case the mentioned RHEL/EPEL version should also be
> EOL.
I agree.
I'd just add that the same may apply to the %{rhel} macros too - Is
there any need to check for *EOLed* RHEL releases?
> I'm not sure this is great. For example, it may introduce revbumps,
> which can cause a package rebuild but in the resulting RPM these should
> make no difference (otherwise they wouldn't be safe).
>
> To me the right time is to on version bump of a package where you're
> already making changes anyway.
I don't see a need to make a bump and build for every change, only for
changes that are expected to be built.
There are mass rebuilds anyway, so it will be bumped and built eventually.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Thu, Jan 19, 2023 at 4:04 PM Ewoud Kohl van Wijngaarden
wrote:
>
> On Thu, Jan 19, 2023 at 11:52:04AM +0100, Michal Schorm wrote:
> >While playing around with Sourcegraph, which indexed all Fedora
> >package repositories, I was able to craft a query listing all '%if'
> >conditionals referencing Fedora releases that reached EOL.
> >
> >https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproject%5C.org/rpms+file:.spec+%28%25if.*%25%7B%5C%3Ffedora%7D.*%5B%3C%3D%3E%5D.*%29%28%5B12%5D%5B0-9%5D%7C%5B3%5D%5B012345%5D.*%29+count:all=regexp=yes=0=group
> >
> >I don't believe such conditions have any value and I think we can
> >remove them right away.
> >I think the removal shouldn't affect neither Fedora nor derived
> >operating systems.
> >
> >If removed, they will be preserved in the git history anyway, for
> >anyone seeking historical code.
> >
> >In some cases the conditionals hold patches that could be removed with them:
> >
> >https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproject%5C.org/rpms+file:.spec+%28%25if.*%25%7B%5C%3Ffedora%7D.*%5B%3C%5D.*%29%28%5B12%5D%5B0-9%5D%7C%5B3%5D%5B0123456%5D.*%5Cn%2B%29%28.*%5Cn%3F%29%28%25patch.*%29+count:all=regexp=yes=0=group
> >
> >--
> >
> >Do you agree it would be safe to remove such conditionals and the code
> >they hold ?
>
> Only if they're purely for Fedora. In many examples you also see a rhel
> conditional and that could be used for EPEL. A good number of packagers
> like to use the same spec since it reduces maintenance burden on
> updates. So in that case the mentioned RHEL/EPEL version should also be
> EOL.
>
> >Do you agree that removing obsolete code such as this brings value to
> >the package codebase ?
>
> Yes, RFC 2119 SHOULD sense.
>
> >Would you see a value in e.g. some kind of a robot reminding
> >maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
> >check)
>
> I'm not sure this is great. For example, it may introduce revbumps,
> which can cause a package rebuild but in the resulting RPM these should
> make no difference (otherwise they wouldn't be safe).
>
> To me the right time is to on version bump of a package where you're
> already making changes anyway.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: SPECfiles - conditionals with EOLed Fedora releases - any value in keeping them ?
On Thu, Jan 19, 2023 at 3:36 PM Robbie Harwood wrote: > > Would you see a value in e.g. some kind of a robot reminding > > maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI > > check) > > Please don't. Would you mind expanding your answer a bit, please? I'd like to learn why people would (not) like such a check or reminder. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Jan 19, 2023 at 3:36 PM Robbie Harwood wrote: > > Michal Schorm writes: > > > While playing around with Sourcegraph, which indexed all Fedora > > package repositories, I was able to craft a query listing all '%if' > > conditionals referencing Fedora releases that reached EOL. > > > > Do you agree it would be safe to remove such conditionals and the code > > they hold ? > > Yes, at maintainer discretion. > > > Do you agree that removing obsolete code such as this brings value to > > the package codebase ? > > No - it's annoying code churn that usually serves no purpose. If > maintainers want them gone, generally they'll remove them. > > > Would you see a value in e.g. some kind of a robot reminding > > maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI > > check) > > Please don't. > > Be well, > --Robbie ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
SPECfiles - conditionals with EOLed Fedora releases - any value in keeping them ?
Hello, While playing around with Sourcegraph, which indexed all Fedora package repositories, I was able to craft a query listing all '%if' conditionals referencing Fedora releases that reached EOL. https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproject%5C.org/rpms+file:.spec+%28%25if.*%25%7B%5C%3Ffedora%7D.*%5B%3C%3D%3E%5D.*%29%28%5B12%5D%5B0-9%5D%7C%5B3%5D%5B012345%5D.*%29+count:all=regexp=yes=0=group I don't believe such conditions have any value and I think we can remove them right away. I think the removal shouldn't affect neither Fedora nor derived operating systems. If removed, they will be preserved in the git history anyway, for anyone seeking historical code. In some cases the conditionals hold patches that could be removed with them: https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproject%5C.org/rpms+file:.spec+%28%25if.*%25%7B%5C%3Ffedora%7D.*%5B%3C%5D.*%29%28%5B12%5D%5B0-9%5D%7C%5B3%5D%5B0123456%5D.*%5Cn%2B%29%28.*%5Cn%3F%29%28%25patch.*%29+count:all=regexp=yes=0=group -- Do you agree it would be safe to remove such conditionals and the code they hold ? Do you agree that removing obsolete code such as this brings value to the package codebase ? Would you see a value in e.g. some kind of a robot reminding maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI check) Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
The idea of faking this and that (timestamps, builder hostname, ... whatever) is weird. It always leads to a question: why do we even have / use such metadata, if we fake them anyway? Only either ditching such values entirely or always honoring them does make sense to me. Or inventing new ones that better fit the various use cases we have (like before mentioned splitting metadata from artifacts and so on) But if your proposal is the best we have, I'm fine with it. It's your time after all :) and I haven't noticed it would affect me (or rather "make my life harder") in any way both as a user and as a package maintainer. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Sat, Nov 26, 2022 at 11:09 PM Marek Marczykowski-Górecki wrote: > > On Fri, Nov 11, 2022 at 10:14:56AM -0500, Neal Gompa wrote: > > On Fri, Nov 11, 2022 at 8:46 AM Clemens Lang wrote: > > > > > > Hi, > > > > > > Alexander Sosedkin wrote: > > > > > > > In RPM world, I've even entertained an idea of having a subpackage for > > > > auditability not unlike how we have debuginfo, since rebuilding a > > > > package > > > > reproducibly requires builddep pinning. But if that's avoidable, I’d > > > > rather just not mix artifacts with meta. > > > > > > Debian is working on this already, they call those “buildinfo” files: > > > > > >https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles > > >https://manpages.debian.org/testing/dpkg-dev/deb-buildinfo.5.en.html > > > > > > If we want something similar, I’d propose not to completely re-invent the > > > wheel. > > > > > > > We've discussed an RPM-specific format upstream. Debian and Arch both > > have their own formats that are tailored to their package systems, and > > RPM may have one too, eventually. > > For context, the discussion is here: > https://github.com/rpm-software-management/rpm/pull/1532 > > -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Wed, Jan 11, 2023 at 5:36 PM Zbigniew Jędrzejewski-Szmek wrote: > Instead, the idea is to attack the problem from the other end: reduce > the timeout for everyone. Once this happens, we should start getting > feedback about what services where this doesn't work. Sound's terrible to me. Could we achieve this without knowingly breaking users' machine's shutdowns? Or annoying user base in general ? I can imagine a new standalone package, that only changes the timeout, and only people willing to test the short shutdowns would participate and install it? -- If somehow we end up with the terrible approach of "change crucial system-wide config and see what happens", could we at least do it step by step? Shortening the timeout by e.g. 10 or 30 seconds every Fedora release ? 30 minutes every half a year spent by copy-pasting the Fedora change from the last release sound's like a solid tradeoff for not gaining upset users. -- The different configuration for different Fedora editions doesn't sound right to me. The edition originally installed does tell us anything about any other software installed on that machine later. Hunting for well-known trouble-making services (regarding shutdown times) is a much cleaner approach. -- Is there any existing piece of software that can analyze the shutdowns and report the mean times and messages of each service / component ? I'd use it on my devices with problematic shutdowns. And I personally believe that strictly opt-in telemetry is a good way to gather user (telemetric) data. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, Jan 11, 2023 at 9:56 PM Michael Catanzaro wrote: > > On Wed, Jan 11 2023 at 11:48:27 AM -0800, Kevin Fenzi > wrote: > > I do appreciate the change to do an abort on these units. Will that > > get > > reported via abrt? > > It should, yes, the same as any other crash. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
KOJI builders running out of space
Hello, I'm working on a rebase of the MySQL package (community-mysql). I'm getting: 'No space left on device' errors very consistently. It happens on every single architecture, which is odd as usually such problems in KOJI are arch-specific. It happens very early during testsuite execution. Examples here: https://koji.fedoraproject.org/koji/taskinfo?taskID=92917358 https://koji.fedoraproject.org/koji/taskinfo?taskID=92919482 I've also tried to re-build the currently released commit, to eliminate any changes in behaviour during the package rebase. The errors are there too: https://koji.fedoraproject.org/koji/taskinfo?taskID=92945427 https://koji.fedoraproject.org/koji/taskinfo?taskID=92945615 Anyone recall any recent changes to KOJI? Would it be possible to allocate more space to the builders ? Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
KOJI Rawhide error: "Empty %files file ...../debugsourcefiles.list"
Hi, I've just started (scratch-)building MySQL 8.0.30. (package 'community-mysql'). And the build on Rawhide failed with an error message, I haven't seen before: " Processing files: community-mysql-debugsource-8.0.30-1.fc37.x86_64 error: Empty %files file /builddir/build/BUILD/mysql-8.0.30/debugsourcefiles.list RPM build errors: Empty %files file /builddir/build/BUILD/mysql-8.0.30/debugsourcefiles.list Child return code was: 1 " Here is the build: https://koji.fedoraproject.org/koji/taskinfo?taskID=90072976 The issue appeared on every architecture. A build from the same sources for F35 (scratch-)builds fine: https://koji.fedoraproject.org/koji/taskinfo?taskID=90073173 -- Does this error ring a bell to anyone? Since the RPM debug-stuff is automatically generated and the package builds fine for F35, I assume it's a KOJI issue rather than the package issue. I'll submit scratch builds for F36 & F37 in a moment. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Upstream Release Monitoring - bug report
Ah, It's a bit more tangled than I thought: I've somehow got an impression that the upstream release monitoring is not related to Fedora, but I expected the BZ bot should be. So I've looked for a place to report issues other than https://github.com/fedora-infra/anitya/issues, as I thought it is the upstream (not Fedora related) part of the project. Only after following the link I've seen it is a GitHub repo in the "fedora-infra" namespace. I've actually thought that the "monitoring status" option in the src.fedoraproject.org does something different (pings you when _anyone_ do a build or scratch-build of your package in KOJI - which would be useful for watching who touches your pkg and how) The Pagure documentation doesn't seem to know about that field: https://docs.pagure.org/pagure/search.html?q=monitoring So the 'Monitoring' value is likely what I am looking for, thanks ! :) -- On Mon, Jul 25, 2022 at 1:46 PM Fabio Valentini wrote: > This sounds like it's trying to process and create patches for *the > same version* again and again? > If that is the case, you might want to file a bug with anitya / > the-new-hotness, as that's certainly not its intended behaviour. Right, will report. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Mon, Jul 25, 2022 at 1:46 PM Fabio Valentini wrote: > > On Mon, Jul 25, 2022 at 1:39 PM Michal Schorm wrote: > > > > Hello, > > I don't know where to go, so I'm trying here. > > > > Package 'mariadb-connector-c' [1] I maintain has upstream release > > monitoring enabled [2]. > > The bot opened a BZ [3] for me to notify about a new upstream release > > - as expected. > > > > It tried to come up with a patch and try to scratch-build the package > > with the patch. > > However it failed. > > And now it tries again and again, failing every time. Littering the BZ > > ticket with more and more comments with zero value. Spamming people in > > CC every day or two. > > > > I want it to stop. > > > > Ideally, I would like the bot to stop trying making patches and doing > > scratch builds on all my packages at all. It's a wasted effort (and > > computing time; and KOJI resources). > > > > Is that possible? > > How? > > > > -- > > > > I logged into the https://release-monitoring.org/ , but there doesn't > > seem to be any setting regarding that. > > release-monitoring.org only has a mapping from upstream projects to > Fedora package names, but Fedora-specific settings live on > src.fedoraproject.org. > So, if you go to > https://src.fedoraproject.org/rpms/mariadb-connector-c (you actually > linked that page yourself), and are logged in: > > In the left-hand pane, there's a combobox where you can select "No > monitoring", "Monitoring", and "Scratch builds". > It's currently set to "Scratch builds", but if you know that those > won't work, then change the setting to "Monitoring". > That will at least cut down the number of notifications. > > > And now it tries again and again, failing every time. > > This sounds like it's trying to process and create patches for *the > same version* again and again? > If that is the case, you might want to file a bug with anitya / > the-new-hotness, as that's certainly not its intended behaviour. > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Upstream Release Monitoring - bug report
Hello, I don't know where to go, so I'm trying here. Package 'mariadb-connector-c' [1] I maintain has upstream release monitoring enabled [2]. The bot opened a BZ [3] for me to notify about a new upstream release - as expected. It tried to come up with a patch and try to scratch-build the package with the patch. However it failed. And now it tries again and again, failing every time. Littering the BZ ticket with more and more comments with zero value. Spamming people in CC every day or two. I want it to stop. Ideally, I would like the bot to stop trying making patches and doing scratch builds on all my packages at all. It's a wasted effort (and computing time; and KOJI resources). Is that possible? How? -- I logged into the https://release-monitoring.org/ , but there doesn't seem to be any setting regarding that. -- In the meanwhile, I've found one more tiny bug: (A) The link to Fedora wiki page about the upstream release monitoring leads to an obsoleted page: https://fedoraproject.org/wiki/Upstream_release_monitoring -- [1] https://src.fedoraproject.org/rpms/mariadb-connector-c [2] https://release-monitoring.org/project/16939/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=2090416 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
MariaDB in Fedora - retiring 10.3 & 10.4 series
Hello everyone, Due to several circumstances I am stopping all efforts in maintaining MariaDB 10.3 & 10.4 series in Fedora. Just before that, I rebased both series to the latest upstream versions, so you will get all the security patches released as for today ! MariaDB 10.3: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2022-0cd0202272 MariaDB 10.4: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2022-c58e1ae21e Also, please notice that neither series is available in Fedora > 35, because our efforts to cherry-pick the OpenSSL 3 patch from the 10.8 series were unsuccessful. Furthermore, please note that _on upstream_ : MariaDB 10.3 will reach 'end of standard support' and EOL on: 25 May 2023 MariaDB 10.4 reached 'end of standard support' on: 02 July 2022 and will reach EOL on: 02 July 2024 -- I strongly recommend updating your applications to at least MariaDB 10.5 series. MariaDB upstream changed it's release model some time ago [1]. The upstream expects to release a new _serie_ every three months. Every new series (starting 10.6) support period was shortened to _one year_ only. Some of the series will be marked as LTS (long term support) with support period being at least 5 years. First serie marked as LTS is 10.6 Second serie that will _likely_ be marked as LTS is 10.10 My personal focus - as the package maintainer - is on the MariaDB 10.5 ; and MariaDB 10.10 (should it be marked LTS). Please consider all other series maintained (by me in Fedora) on 'best effort' basis only. The golden rule in case of my packages is that the development is done in base Fedora (branch 'rawhide'), so whichever version there is, it is the one maintained with most care. -- As always, anyone is welcome to submit patches or (preferably) pull requests to packages I maintain, or step in to maintain MariaDB series I don't have capacity for. Feel free to ask more questions if you are interested, I'll answer what I can. I wish you a nice day and stable DB servers :) [1] https://mariadb.com/newsroom/press-releases/mariadb-announces-new-innovation-release-model/ [2] rel-eng ticket regarding setting the EOL date: https://pagure.io/releng/issue/10902 [3] Wiki page with info which series are in which Fedora releases: https://fedoraproject.org/wiki/MariaDB_software -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: CMake fails to configure when "-S ." source method is used
See: https://bugzilla.redhat.com/show_bug.cgi?id=2079833 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Sun, Jun 12, 2022 at 7:49 PM Richard Shaw wrote: > > Ok, this is a weird one. Apparently platform detection either fails or isn' > "remembered" when "-S ." is used to specify the source directory but if "." > is added to the end of the cmake command line it configures fine. > > Shouldn't these work exactly the same? > > When "-S ." is used (as it's set in %cmake) the configure fails in two ways: > > 1. GNUInstallDirs complains it can't set CMAKE_INSTALL_LIBDIR > > CMake Warning (dev) at /usr/share/cmake/Modules/GNUInstallDirs.cmake:239 > (message): > Unable to determine default CMAKE_INSTALL_LIBDIR directory because no > target architecture is known. Please enable at least one language before > including GNUInstallDirs. > > 2. Some libraries are not found, I think for the same reason. Using > --debug-find I see that no incarnation of "lib64" is checked: > > find_library considered the following locations: > > /builddir/.local/bin/lib/(lib)mbedtls(\.so|\.a) > /builddir/.local/bin/(lib)mbedtls(\.so|\.a) > /builddir/bin/lib/(lib)mbedtls(\.so|\.a) > /builddir/bin/(lib)mbedtls(\.so|\.a) > /usr/bin/lib/(lib)mbedtls(\.so|\.a) > /usr/bin/(lib)mbedtls(\.so|\.a) > /bin/lib/(lib)mbedtls(\.so|\.a) > /bin/(lib)mbedtls(\.so|\.a) > /usr/sbin/lib/(lib)mbedtls(\.so|\.a) > /usr/sbin/(lib)mbedtls(\.so|\.a) > /sbin/lib/(lib)mbedtls(\.so|\.a) > /sbin/(lib)mbedtls(\.so|\.a) > /usr/local/sbin/lib/(lib)mbedtls(\.so|\.a) > /usr/local/sbin/(lib)mbedtls(\.so|\.a) > /usr/local/lib/lib/(lib)mbedtls(\.so|\.a) > /usr/local/lib/(lib)mbedtls(\.so|\.a) > /usr/local/lib/(lib)mbedtls(\.so|\.a) > /usr/local/(lib)mbedtls(\.so|\.a) > /usr/lib/lib/(lib)mbedtls(\.so|\.a) > /usr/lib/(lib)mbedtls(\.so|\.a) > /usr/lib/(lib)mbedtls(\.so|\.a) > /usr/(lib)mbedtls(\.so|\.a) > /lib/lib/(lib)mbedtls(\.so|\.a) > /lib/(lib)mbedtls(\.so|\.a) > /usr/X11R6/lib/lib/(lib)mbedtls(\.so|\.a) > /usr/X11R6/lib/(lib)mbedtls(\.so|\.a) > /usr/X11R6/lib/(lib)mbedtls(\.so|\.a) > /usr/X11R6/(lib)mbedtls(\.so|\.a) > /usr/pkg/lib/lib/(lib)mbedtls(\.so|\.a) > /usr/pkg/lib/(lib)mbedtls(\.so|\.a) > /usr/pkg/lib/(lib)mbedtls(\.so|\.a) > /usr/pkg/(lib)mbedtls(\.so|\.a) > /opt/lib/lib/(lib)mbedtls(\.so|\.a) > /opt/lib/(lib)mbedtls(\.so|\.a) > /opt/lib/(lib)mbedtls(\.so|\.a) > /opt/(lib)mbedtls(\.so|\.a) > /usr/lib/X11/lib/(lib)mbedtls(\.so|\.a) > /usr/lib/X11/(lib)mbedtls(\.so|\.a) > > Looking at the source of GNUInstallDirs the only reason to see that message > is: > > if (NOT DEFINED CMAKE_SYSTEM_NAME OR NOT DEFINED CMAKE_SIZEOF_VOID_P) > message(AUTHOR_WARNING > "Unable to determine default CMAKE_INSTALL_LIBDIR directory because no > target architecture is known. " > "Please enable at least one language before including GNUInstallDirs.") > endif() > > So why the heck would using "-S ." make any difference? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Minizip pull requests
Forwarding to the package maintainers as a heads-up
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Fri, Apr 22, 2022 at 5:55 AM Julian Sikorski wrote:
>
> W dniu 21.04.2022 o 21:22, Julian Sikorski pisze:
> > Hello,
> >
> > I have created two PRs against minizip which are yet to be merged:
> >
> > - https://src.fedoraproject.org/rpms/minizip/pull-request/3
> > - https://src.fedoraproject.org/rpms/minizip/pull-request/4
> >
> > The first one should be a low risk one and should allow pkg-config using
> > dependencies like (shameless self-interest plug) to build against system
> > minizip again.
> > The second one needs support from a provenpackager. I tried rebuilding
> > the 18 dependencies of minizip and this is a bit tricky for two reasons:
> >
> > - libsmbl and libspatialite need to be rebuilt before the other
> > dependencies
> > - I cannot figure out how to get fedpkg srpm to work with libspatialite,
> > I am getting a Package already exists: %package debuginfo error from the
> > %{?mingw_debug_package} line. I am sure this is something someone
> > familiar with mingw can fix in a shortest amount of time.
> >
> > Other than that, I can confirm that 13 dependencies can be rebuilt with
> > no changes. How can we move this forward?
> >
> > Best regards,
> > Julian
>
> Update: everything but COPASI and dolphin-emu can be rebuilt with no
> changes. COPASI and dolphin-emu fail for unrelated reasons. The order of
> rebuilds is:
> 1. minizip
> 2. libsmbl and libspatialite
> 3. librasterlite
> 4. other packages
>
> Best regards,
> Julian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: CMake broken in rawhide?
On Fri, Jun 10, 2022 at 4:32 AM Richard Shaw wrote: > The %cmake line had a trailing ".". Removing it fixes the issue. ... 'workarounds', rather than 'fixes'. Soon it will be half a year since the breaking change has been silently introduced. In the meanwhile, the CMake upstream themselves noticed an email thread i started on Fedora devel and partly reverted the change. In the followup discussion it turned out, the %cmake macro we use in Fedora is fundamentally wrong and should be fixed. However the CMake maintainer doesn't seem to care at all, nor participates in upstream discussions. https://bugzilla.redhat.com/show_bug.cgi?id=2079833 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Fri, Jun 10, 2022 at 4:32 AM Richard Shaw wrote: > > DOH! > > The %cmake line had a trailing ".". Removing it fixes the issue. > > Thanks, > Richard > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[modules] 'fedpkg request-branch' - how ?
Hello, I want to create a new module stream. All the RPMs repos and the Module repo exist. I just need new branches in all of them. However I've run into a deadlock. Non-release branches require SL to be defined. And SL before it is defined checks that such a branch exists. | fedpkg request-branch 10.8 | Could not execute request_branch: You must provide SLs for non-release branches (10.8) | | fedpkg request-branch 10.8 --sl 10.8:2030-12-01 | Could not execute request_branch: The SL "10.8" is not in PDC -- Beside that, the | fedpkg request-branch -h doesn't explain what will be the content of the newly created branch. In my case it would suit me best to call the command from inside of repo and the new branch to be created as a copy of the currently checked out branch. (So it would be similar as 'git checkout -b ... ') Should I rather use the '--no-git-branch' argument to create the branch as I need ? Can I actually do that, since SL needs the branch to exist first ?? I also don't understand what happens when in a case of module named 'X', consisting of RPMs named 'X' and 'Y', I go to the RPM 'Y' and call the 'fedpkg-request branch' without '--no-auto-module'. Will that create a new modular repo named 'Y' ? Will that create a branch with a name I choosed in the modular repo 'X' ? -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: dist-git force push
On Fri, Apr 1, 2022 at 12:52 PM Michael J Gruber wrote: > In particular, this would allow to avoid the many "commit missing patch", > "actually commit the change", > "duh" commits which happen after a successful `fedpkg build --scratch --srpm` > followed by a half-(how do you say this nicely)ed commit. It would also allow to: 1/ messing with other people repositories 2/ ability to rewrite other contributor's work - even RelEngs and Proven Packager's The advice - even though only partial - really is "write better code". No one ever will write error-less code. But there are a lot of steps you can take to reduce the amount of errors in your code - testing of your own code and code review being amongst the first steps before pushing anything to production. And even when you push an error, there is no shame in correcting yourself. (This is the second part of the advice) It is a healthy behaviour to openly step out and correct what you messed up, rather than trying to hide it from everyone. Openness and trust are values this community is built upon. We already have so many ways to reduce errors in our code. 1/ Use pull requests from your forks instead of pushes directly to production branches 2/ You can ask people to review your code 3-A/ you can set up ZUUL CI to make a mock build for you 3-B/ or you can do mock build yourself 3-C/ or you can make a scratch build 4/ ZUUL CI can also run rpminspect and more to uncover a whole bunch of issues you would never find yourself 5/ Learn git better to ease your work with it e.g. never making more than a single change in a single commit That way your commits can be perfectly revertible - which is one of the intended ways to fix your errors I believe you look at it from the wrong end. Why wouldn't you try to avoid pushing the erroneous code in the first place - e.g. by testing ? -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Fri, Apr 1, 2022 at 12:52 PM Michael J Gruber wrote: > > Hi there > > I know why we do not allow to force push to dist-git in the rpms namespace, > but I am wondering whether we can implement this more in line with the reason: > > dist-git has to be a permanent record for the "source" (spec etc.) against > which a package is built, but currently we deny pushing even when there is no > build against the rewritten commits. Instead, I suggest the following > behaviour for the update-hook of git-receive-pack: > > - check which commit contained in "old object name" is the most recent one > (topology order) which has been built (successfully) - call it "old build > object name" > - check whether the "new object name" is descendant of (contains) "old build > object name" (rather than "old object name", which would forbid any force > push) > > This would allow to rewrite a branch as long as the last commit hasn't been > built yet (but allow only rewrites to commits since the last build). In > particular, this would allow to avoid the many "commit missing patch", > "actually commit the change", "duh" commits which happen after a successful > `fedpkg build --scratch --srpm` followed by a half-(how do you say this > nicely)ed commit. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedora-legal-list] How to make a Pagure Pull Request and How it is licensed by default for contributors outside of 'packagers' group ?
On Wed, Mar 23, 2022 at 9:36 AM Vít Ondruch wrote: > Dne 22. 03. 22 v 19:18 Michal Schorm napsal(a): > > On Tue, Mar 22, 2022 at 7:06 PM Richard Fontana wrote: > >> I would assert that the "unlicensed > >> contribution" scenario contemplated by the FPCA is actually going to > >> be fairly rare apart from the special case of spec files, which the > >> FPCA was particularly aimed at. In the typical case, a Fedora-related > >> project makes clear what the applicable license of a repository (or of > >> files within a repository) is/are, and under the "inbound=outbound" > >> convention, that will be understood to be the license of the > >> contribution. > > I've never heard about "inbound=outbound convention". > > I think you can get more information about this concept in Richard's > article: > > https://opensource.com/article/19/2/cla-problems What a great article ! That answers it to me. We don't need the contributors to sign the FPCA or any CLA. Thanks. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, Mar 23, 2022 at 9:36 AM Vít Ondruch wrote: > > > Dne 22. 03. 22 v 19:18 Michal Schorm napsal(a): > > On Tue, Mar 22, 2022 at 7:06 PM Richard Fontana wrote: > >> I would assert that the "unlicensed > >> contribution" scenario contemplated by the FPCA is actually going to > >> be fairly rare apart from the special case of spec files, which the > >> FPCA was particularly aimed at. In the typical case, a Fedora-related > >> project makes clear what the applicable license of a repository (or of > >> files within a repository) is/are, and under the "inbound=outbound" > >> convention, that will be understood to be the license of the > >> contribution. > > I've never heard about "inbound=outbound convention". > > > I think you can get more information about this concept in Richard's > article: > > https://opensource.com/article/19/2/cla-problems > > > > > > I understand your answer as that: > > it is irrelevant whether the contributor specified the license (e.g. > > text "I submit this under GPL-2.0 license" in the pull request > > comment) > > > If somebody states license of the contribution, then it has to be > respected. Otherwise it is assumed that the contribution has similar > licensing conditions as the target project. > > > Vít > > > > > or whether none was specified, or whether the FPCA was > > accepted by the contributor; since every contributor to a code (let's > > say a single package repository) is always legally assumed to be under > > the license othe code of that package has, unless specified > > differently by the contributor. > > > > Is my understanding correct ? > > > > Michal > > > > -- > > > > Michal Schorm > > Software Engineer > > Core Services - Databases Team > > Red Hat > > > > -- > > > > On Tue, Mar 22, 2022 at 7:06 PM Richard Fontana wrote: > >> On Tue, Mar 22, 2022 at 12:25 PM Michal Schorm wrote: > >>> Hello, > >>> > >>> I'm trying to answer this question: > >>> "Under which license are the contributions done to Fedora Project, > >>> unless license is specified - and how make this clear to the > >>> contributors (or whether we make this clear enough)". > >>> The answer is _probably_ FPCA [1]. > >> The FPCA basically says that there's a particular default license that > >> applies in cases where the contribution is not "covered by explicit > >> licensing terms that are conspicuous and readily discernible to > >> recipients." This does not spell out what "explicit", "conspicuous" > >> and "readily discernible" actually mean, much as you haven't explained > >> what you mean by "specified". I would assert that the "unlicensed > >> contribution" scenario contemplated by the FPCA is actually going to > >> be fairly rare apart from the special case of spec files, which the > >> FPCA was particularly aimed at. In the typical case, a Fedora-related > >> project makes clear what the applicable license of a repository (or of > >> files within a repository) is/are, and under the "inbound=outbound" > >> convention, that will be understood to be the license of the > >> contribution. > >> > >> I'm not aware of any reason to make anything clearer that it currently > >&
Re: [Fedora-legal-list] How to make a Pagure Pull Request and How it is licensed by default for contributors outside of 'packagers' group ?
On Tue, Mar 22, 2022 at 7:06 PM Richard Fontana wrote: > I would assert that the "unlicensed > contribution" scenario contemplated by the FPCA is actually going to > be fairly rare apart from the special case of spec files, which the > FPCA was particularly aimed at. In the typical case, a Fedora-related > project makes clear what the applicable license of a repository (or of > files within a repository) is/are, and under the "inbound=outbound" > convention, that will be understood to be the license of the > contribution. I've never heard about "inbound=outbound convention". I understand your answer as that: it is irrelevant whether the contributor specified the license (e.g. text "I submit this under GPL-2.0 license" in the pull request comment) or whether none was specified, or whether the FPCA was accepted by the contributor; since every contributor to a code (let's say a single package repository) is always legally assumed to be under the license othe code of that package has, unless specified differently by the contributor. Is my understanding correct ? Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Tue, Mar 22, 2022 at 7:06 PM Richard Fontana wrote: > > On Tue, Mar 22, 2022 at 12:25 PM Michal Schorm wrote: > > > > Hello, > > > > I'm trying to answer this question: > > "Under which license are the contributions done to Fedora Project, > > unless license is specified - and how make this clear to the > > contributors (or whether we make this clear enough)". > > The answer is _probably_ FPCA [1]. > > The FPCA basically says that there's a particular default license that > applies in cases where the contribution is not "covered by explicit > licensing terms that are conspicuous and readily discernible to > recipients." This does not spell out what "explicit", "conspicuous" > and "readily discernible" actually mean, much as you haven't explained > what you mean by "specified". I would assert that the "unlicensed > contribution" scenario contemplated by the FPCA is actually going to > be fairly rare apart from the special case of spec files, which the > FPCA was particularly aimed at. In the typical case, a Fedora-related > project makes clear what the applicable license of a repository (or of > files within a repository) is/are, and under the "inbound=outbound" > convention, that will be understood to be the license of the > contribution. > > I'm not aware of any reason to make anything clearer that it currently > is. I think at this point the FPCA is sort of a historical curiosity > that lives on because of inertia (other than as an indirect statement > of licensing policy around certain special things like spec files but > those could be addressed in a different way). > > > And this HTTPS workflow leads back to my original question - since FAS > > users outside of 'packager' group AFAIK don't need to sign FPCA [1], > > but can contribute a code - under which license or agreement it is > > contributed ? If it is FPCA - are such contributors aware ? > > If contributors haven't signed the FPCA, the FPCA doesn't apply to > their contributions. But this is most likely unproblematic, for much > the same reason that Fedora could abandon use of the FPCA altogether > without causing any significant problem. > > Richard > > > > [1] > > https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement > > [2] https://docs.fedoraproject.org/en-US/ci/pull-requests/ > > [3] https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits > > > > -- > > > > Michal Schorm > > Software Engineer > > Core Services - Databases Team > > Red Hat > > > > -- > > ___ > > legal mailing list -- le...@lists.fedoraproject.org > > To unsubscribe send an email to legal-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
How to make a Pagure Pull Request and How it is licensed by default for contributors outside of 'packagers' group ?
Hello, I'm trying to answer this question: "Under which license are the contributions done to Fedora Project, unless license is specified - and how make this clear to the contributors (or whether we make this clear enough)". The answer is _probably_ FPCA [1]. But I've run into practical questions of how contributions can be made to the Fedora Project in the first place. Let's start with contributions to Fedora Linux. -- The first Google result for "Fedora pull request" query points to [2]. On the first glance it looks fine, but it has two major issues. 1/ The instructions won't work and are holey 2/ It is a page under a "Fedora CI" project. 1/ Nowadays, we have a way for contributors outside of the 'packager' group to make pull requests. It is a git push via HTTPS [3]. Neither [2] nor [3] describes that you need to have a FAS account first, since without it you can't log in the pagure to fork a project (otherwise there's nowhere you can push to). I wanted to propose an update, but ... 2/ ... this leads to a belief that such an important piece of documentation should be probably placed outside of the "Fedora CI" project, as it can be generalized to any project. What could be this better location for a new documentation page to which other pieces of documentation would point to? And this HTTPS workflow leads back to my original question - since FAS users outside of 'packager' group AFAIK don't need to sign FPCA [1], but can contribute a code - under which license or agreement it is contributed ? If it is FPCA - are such contributors aware ? 3/ Are there any other ways to contribute to either Fedora Linux or the Fedora Project, which face the similar issue ? [1] https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement [2] https://docs.fedoraproject.org/en-US/ci/pull-requests/ [3] https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: FESCo wants to know what you use i686 packages for
I have ~230 i686 RPMs on my F34 system dedicated purely to gaming. Names I recognize are Wine and Steam. For the rest I can't tell whether they are just dependencies of those two, or something else. I have zero i686 RPMs on my F35 system dedicated purely to work. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Sun, Mar 20, 2022 at 12:40 PM Steven A. Falco wrote: > > On 3/20/22 04:38 AM, Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Mar 18, 2022 at 12:30:52AM -, Steven Ellis wrote: > >> The issue on our home systems is 3rd party printer drivers. > >> > >> Eg > >> mfc9140cdncupswrapper-1.1.4-0.i386 > >> dcpj4120dwlpr-3.0.1-1.i386 > >> dcpj4120dwcupswrapper-3.0.1-1.i386 > >> mfc9140cdnlpr-1.1.2-1.i386 > > > > Could you show 'rpm -qR mfc9140cdncupswrapper-1.1.4-0.i386 > > dcpj4120dwlpr-3.0.1-1.i386 dcpj4120dwcupswrapper-3.0.1-1.i386 > > mfc9140cdnlpr-1.1.2-1.i386' ? > > On my system, for dcpl2540dwcupswrapper-3.2.0-1.i386 and > dcpl2540dwlpr-3.2.0-1.i386, I get: > > # rpm -qR dcpl2540dwcupswrapper-3.2.0-1.i386 dcpl2540dwlpr-3.2.0-1.i38 > /bin/sh > /bin/sh > /bin/sh > /usr/bin/perl > cups > dcpl2540dwlpr > perl > rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > /bin/sh > /bin/sh > /bin/sh > /bin/sh > /usr/bin/perl > ghostscript > perl > perl(Cwd) > perl(File::Copy) > rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > > Steve > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
Small technical concern:
i686 packages depending on each other as follows:
A ---> B ---> C ---> D ---> E ---> F ---> G
When a maintainer of package "D" decides to stop building the package
"D" for i686 ("ExcludeArch: %{ix86}"), how do we ensure the packages
"E", "F", "G" will also adopt the "ExcludeArch: %{ix86}" instead of
FTBFS (or FTI) on i686 arch ?
The original change proposal is about _leaf_ packages, which I
understand as only package "G" in my example.
And the maintainer of "D" has to wait on the maintainer of "E" has to
wait on the maintainer of "F" has to wait on the maintainer of "G" to
stop building it for i686.
As voices appeared proposing to get rid of _all_ i686 but necessary
instead (which has +1 from me), I'm unsure whether the goal of the
original proposal changed.
I'm just asking to make sure whether that's somehow covered.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Tue, Mar 8, 2022 at 4:07 PM Dan Horák wrote:
>
> On Tue, 8 Mar 2022 15:46:29 +0100
> Fabio Valentini wrote:
>
> > On Tue, Mar 8, 2022 at 2:05 PM Chris Adams wrote:
> > >
> > > Once upon a time, Fabio Valentini said:
> > > > One of the most problematic things are transitive BuildRequires:
> > > > Even if you know you need to keep libfoo.i686 and libbar.i686, how do
> > > > you determine the transitive dependencies that are needed to keep
> > > > those packages around?
> > > > And by that, I don't only mean Requires, but also transitive
> > > > BuildRequires, i.e. if libfoo BuildRequires foolangc, which
> > > > BuildRequires some other stuff, etc, all of which still needs to be
> > > > there, or at some point, libfoo.i686 will either fail to build or fail
> > > > to install.
> > >
> > > All the necessary info is in the source RPM BuildRequires. Yes, you'll
> > > need a script to build the list recursively, but... that's not that
> > > hard.
> >
> > It's not that easy either.
> >
> > For example, if you're not careful to avoid dependency loops, you'll
> > create a program that will never terminate.
> > You'll need to recursively query Requires from those BuildRequired packages,
> > but you also need to map those their respective source packages, and
> > continue with querying BuildRequires recursively.
> >
> > I've tried to write a script that does that, but it doesn't provide
> > correct results yet.
> > If I manage to get it working, I can share it.
>
> please see my previous post, I have/had a solution for the transitive
> build requirements
>
>
> Dan
>
> >
> > > > I have thought about this issue for months before submitting this
> > > > Change proposal, and it's the best I think we can do without breaking
> > > > tons of stuff or requiring massive amounts of work from the Change
> > > > owner (me). At this point, I do think that a safe and officially
> > > > encouraged opt-out mechanism for individual package maintainers is the
> > > > only way we can do this *safely* at all.
> > >
> > > There are almost 23,000 source RPMs in rawhide. You are proposing a
> > > change that puts virtually all the effort on the maintainers of the
> > > majority of those packages, rather than write a script yourself (which
> > > should not be "massive amounts of work").
> > >
> > > It's easy to propose something when somebody else has to do the work;
> > > please instead put some work in yourself (or don't propose the change).
> >
> > I would appreciate it if you actually read the proposal instead of
> > making personal attacks like this: The proposal does not create a
> > mandate for package maintainers for dropping i686 from packages at
> > all.
> >
> > The goal is to make it easier for maintainers if they are already
> > thinking about dropping i686 from their package. I will also provide a
> > list of potential candidate packages, but it will still be up to the
> > maintainers whether they incorporate or ignore this change.
> >
> > So I don't understand how this "puts virtually all the effort on the
> > maintainers of the majority of those packages", if completely ignoring
> > the Change and/or inaction are both perfectly valid choices.
> >
> > Fabio
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an emai
Re: Problem with cmake 3.23.0
> On 3/4/22 10:17 AM, Sérgio Basto wrote: > I think you missed the > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds > (Targeted release: Fedora 33 ) and > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ I did not. CMake in-source / out-of-source building is an entirely different issue. And I made a good portion of fixing my packages to use the out-of-source build. I even contributed to those CMake guidelines at that time :) As you can see in the Comment #3 in the BZ #2057738, the standard, current, fedora-wide %cmake macro expands to | ... | /usr/bin/cmake \ | -S "." \ | -B "redhat-linux-build" \ | ... And I also mentioned using the -S "." instead of just a 'dot' also workaround the issue. Later in commnet #4 I showed my findings from the upstream code, which IMO strongly suggests, that it should be completely irrelevant how many times, how many ways you define that path, as long as it is always defined the same. Since the CMake command is expanded to /usr/bin/cmake -S . . I believe it should work and thus the current version released to Rawhide is either broken, or ill-documented and the change is badly handled. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Fri, Mar 4, 2022 at 4:24 PM Steven A. Falco wrote: > > On 3/4/22 10:17 AM, Sérgio Basto wrote: > > On Fri, 2022-03-04 at 16:04 +0100, Michal Schorm wrote: > >> On Fri, Mar 4, 2022 at 3:40 PM Sérgio Basto wrote: > >>> The fix is just remove "\ ." (the dot) on %cmake > >> > >> That isn't a fix, that's a workaround for a broken CMake - atleast > >> that I believe, as you can read in that BZ. > >> I haven't found anything on CMake upstream that would suggest such > >> change is needed, I found the contrary. > >> > > > >> And even if this change would be actually intended, it would be nice > >> from the CMake maintainer to announce it. > > > > > > I think you missed the > > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds > > (Targeted release: Fedora 33 ) and > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > > > > > My deduction also came from here: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IGQFBIEBMFHIAHY45SKF5MXOJP43TVQS/ > > > > i.e. the builds that still aren't completely out of the source (i.e. > > have the dot), can have (new) problems, one solution is make the build > > out of the source as recommended on > > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds > > I removed the "." from the %cmake macros, and the build is progressing > properly for rawhide. I still have to make sure that deleting the "." > doesn't break F34 through F36. > > Steve > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Problem with cmake 3.23.0
On Fri, Mar 4, 2022 at 3:40 PM Sérgio Basto wrote: > The fix is just remove "\ ." (the dot) on %cmake That isn't a fix, that's a workaround for a broken CMake - atleast that I believe, as you can read in that BZ. I haven't found anything on CMake upstream that would suggest such change is needed, I found the contrary. And even if this change would be actually intended, it would be nice from the CMake maintainer to announce it. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Fri, Mar 4, 2022 at 3:40 PM Sérgio Basto wrote: > > On Fri, 2022-03-04 at 09:26 -0500, Steven A. Falco wrote: > > There is a new FTBFS for KiCad [1]. I filed an issue with KiCad [2] > > and got a comment from the project leader: > > > > This looks like cmake issue to me. For some reason cmake is > > creating an incorrect build folder: > > > > -- Build files have been written to: /builddir/build/BUILD/kicad- > > 6.0.2 > > > > so the build command: > > > > + /usr/bin/cmake --build redhat-linux-build -j6 --verbose > > > > cannot find the redhat-linux-build folder that was passed on the > > cmake command line. > > > > In the last successful build, we have: > > > >-- Build files have been written to: /builddir/build/BUILD/kicad- > > 6.0.2/redhat-linux-build > >+ /usr/bin/cmake --build redhat-linux-build -j6 --verbose > > > > For some reason, the build file directory has changed: > > > > Success case: /builddir/build/BUILD/kicad-6.0.2/redhat-linux-build > > Failure case: /builddir/build/BUILD/kicad-6.0.2 > > > > Is this a bug in cmake or did something in RPM macros change? > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2060781 > > [2] https://gitlab.com/kicad/code/kicad/-/issues/11043 > > > > The fix is just remove "\ ." (the dot) on %cmake > in line > https://src.fedoraproject.org/rpms/kicad/blob/rawhide/f/kicad.spec#_92 > > > > > > Steve > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > -- > Sérgio M. B. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Problem with cmake 3.23.0
FTR there are more issues, e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=2057738 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Fri, Mar 4, 2022 at 3:27 PM Steven A. Falco wrote: > > There is a new FTBFS for KiCad [1]. I filed an issue with KiCad [2] and got > a comment from the project leader: > > This looks like cmake issue to me. For some reason cmake is creating an > incorrect build folder: > > -- Build files have been written to: /builddir/build/BUILD/kicad-6.0.2 > > so the build command: > > + /usr/bin/cmake --build redhat-linux-build -j6 --verbose > > cannot find the redhat-linux-build folder that was passed on the cmake > command line. > > In the last successful build, we have: > >-- Build files have been written to: > /builddir/build/BUILD/kicad-6.0.2/redhat-linux-build >+ /usr/bin/cmake --build redhat-linux-build -j6 --verbose > > For some reason, the build file directory has changed: > > Success case: /builddir/build/BUILD/kicad-6.0.2/redhat-linux-build > Failure case: /builddir/build/BUILD/kicad-6.0.2 > > Is this a bug in cmake or did something in RPM macros change? > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2060781 > [2] https://gitlab.com/kicad/code/kicad/-/issues/11043 > > Steve > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: s390x KOJI builders issue
In many cases, the build is killed during compilation itself. I'd understand the situation, if it would consistently fail somewhere during the testsuite on OOM errors, but it's weirder than that. Until now, I didn't have this issue. Why now? The tests are still important. Through the years I took several steps to reduce the resource usage for the testsuite. The most significant is that I ran the full testsuite only once or few times in scratch builds, and when I didn't find any issues worth investigating, I switch the testsuite to a minimal mode for every other build of the same minor versions. So e.g. mass rebuilds which only bump patch numbers in the NVR run only the 'main' suite. As well as other small patches during the life of that particular upstream release. The issue in general is: We have the majority of packages which are small and quick to build. Then we have a minority of insanely huge projects, whose resource thirst can never be quenched. :) Could we somehow just identify the huge packages, mark them in a special way, and when KOJI would pick up such marked packages, it would give it much more resources ? At the same time, the average amount of resources given should be lowered to only what most packages need. I believe all could benefit from this. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Mar 3, 2022 at 1:05 AM Kevin Fenzi wrote: > > On Wed, Mar 02, 2022 at 03:54:32PM +0100, Florian Weimer wrote: > > * Michael Catanzaro: > > > > > On Wed, Mar 2 2022 at 02:21:22 PM +0100, Dan Horák > > > wrote: > > >> those are weird, the build tasks have been restarted many times by the > > >> builder daemon, after something crashed there (OOM?) ... > > > > > > This was happening to me on armv7hl a few weeks ago. Kevin Fenzi > > > investigated and discovered that the builds kept hitting an OOM > > > condition and then restarting, which triggered an infinite loop. Each > > > build would work for 3-5 hours before failing, then it would start > > > over, then again, then again > > > > > > I think some configuration changed recently on the builders, because I > > > had never seen this happen before last month. If a build hits OOM, it > > > really needs to fail immediately. It should not restart, because it's > > > likely to fail again the same way. My builds had restarted four or > > > five times before Kevin manually handled them. > > > > Maybe Koji restarts the build because the builder has rebooted? > > Nope. > > What happens is: > > * 10: Build is taken by builder and starts building. > * Build takes up more than 90% of memory+swap > * OOm killer looks and says... oh hey, I need to kill something. This > kojid process/slice is taking up all the memory. > * kojid is killed. > * kojid is restarted (we have it set to restart in unit) > * builder checks into hub > * hub says, hey you are doing task X right? > * builder says... oh, yes, let me start that. > * goto 10 > > So in this case it seems like it's the tests that are causing this. > The s390x kvm builders have 2cpus and 10gb of memory. > > So, is there any way to decrease memory usage there? > I see the tests have -parallel=auto perhaps that could be set to 1 or 2? > > Perhaps there's some way to adjust the oom killer to kill the build > instead of kojid? I would prefer that because then the build would > quickly fail and you could see it was killed and need to reduce memory > consumption somehow. > > I suppose we could look at reducing the number of builders and > increasing memory on fewer of them, but it's hard to know what the right > value is there. it's definitely better for mass rebuilds to have more > smaller builders. > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
s390x KOJI builders issue
Hello, for the last few days, I'm not able to finish my builds of the 'mariadb' package on s390x architecture. Those builds freeze, e.g. several of these: https://koji.fedoraproject.org/koji/taskinfo?taskID=83297826 https://koji.fedoraproject.org/koji/taskinfo?taskID=83296979 https://koji.fedoraproject.org/koji/taskinfo?taskID=83292553 https://koji.fedoraproject.org/koji/taskinfo?taskID=83290439 https://koji.fedoraproject.org/koji/taskinfo?taskID=83295670 https://koji.fedoraproject.org/koji/taskinfo?taskID=83293919 have >100 hours total time before finally failing. Even the new one I submitte have already > 22 hours count: https://koji.fedoraproject.org/koji/taskinfo?taskID=83514145 The MariaDB build - especially with the full testsuite on - is very resource hungry. However the freezes are strange, since sometimes it freezes randomly even during compilation, while sometimes %check phase ... -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: sphinx: Intention to orphan package
The ownership of the 'sphinx' package [1] has been transferred to me. I've removed access for users 'brandfbb' and 'cdamian' to the package (both had 'admin' privileges before) since there haven't been any activity around the package from them for a _long_ time. I've added user 'hhorak' with role 'admin' as a backup, should I be unreachable. In the case anybody is interested to contribute, feel free to contact me and I'll assign you the access rights accordingly - if needed at all. (As I prefer PR workflow) I do not intend to maintain the package once there will be no other package depending on 'sphinx'. However the decision and eventual deprecation and removal of the Sphinx SE from the MariaDB server will take time (a ~ year ?), so I don't expect it to be anytime soon. [1] https://src.fedoraproject.org/rpms/sphinx -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Mon, Feb 28, 2022 at 11:38 AM Michal Schorm wrote: > > 1/ Go to the package page: > https://src.fedoraproject.org/rpms/sphinx > > 2/ Log in > > 3/ On top bar go to "Settings" > (next to "Source", "Issues", "Pull Requests", "Stats") > > 4/ Left column "Give project" > > -- > > Michal Schorm > Software Engineer > Core Services - Databases Team > Red Hat > > -- > > On Mon, Feb 28, 2022 at 11:28 AM Sergio Arroutbi wrote: > > > > It makes sense to hand it over to you. I am OK with it. > > > > Does anybody have a guide on how to do so? > > > > On Mon, Feb 28, 2022 at 10:18 AM Michal Schorm wrote: > >> > >> Sorry for the delay. > >> I checked with MariaDB upstream. > >> > >> https://mariadb.zulipchat.com/#narrow/stream/118759-general/topic/Sphinx.20SE > >> > >> The upstream last updated the version they are using ~7 years ago to > >> version 2.2.6 and since it isn't a very important storage engine, it > >> might be best to deprecate and remove it in the future. > >> > >> I offer to take over the package myself, and put the best effort I'll > >> find to keep it alive and orphan it once MariaDB stops using it or it > >> just won't build anymore. > >> > >> Michal > >> > >> -- > >> > >> Michal Schorm > >> Software Engineer > >> Core Services - Databases Team > >> Red Hat > >> > >> -- > >> > >> On Thu, Jan 13, 2022 at 2:17 PM Michal Schorm wrote: > >> > > >> > MariaDB provides a Sphinx storage engine [1] which build is enabled in > >> > Fedora. > >> > The 'mariadb' SPECfile mentions following requirements: > >> > > >> > BuildRequires:sphinx libsphinxclient libsphinxclient-devel > >> > Requires: sphinx libsphinxclient > >> > > >> > I guess that orphaning all (C or Python) versions of Sphinx in Fedora > >> > will make me unable to keep building this SE. (The fact that it is > >> > available via Pip doesn't help me during a package build) > >> > > >> > I haven't looked at this piece of MariaDB in years, I have to check > >> > both myself and with the MariaDB upstream - whether they are aware of > >> > this situation or if they already have a plan. > >> > > >> > [1] http://mariadb.com/kb/en/about-sphinxse/ > >> > > >> > -- > >> > > >> > Michal Schorm > >> > Software Engineer > >> > Core Services - Databases Team > >> > Red Hat > >> > > >> > -- > >> > > >> > On Thu, Jan 13, 2022 at 1:48 PM Vitaly Zaitsev via devel > >> > wrote: > >> > > > >> > > On 13/01/2022 13:33, Sergio Arroutbi wrote: > >> > > > Latest binary versions from previous link (for example, v3.4.1) link > >> > > > to > >> > > > python base source code. > >> > > > >> > > Also they decided co close sources last year: > >> > > > >> > > > 3.0 and up sources are currently only available under a delayed FOSS > >> > > > or commercial licenses for several reasons; going back to regular > >> > > > plain old GPL is planned but timing is moot; so email us if you > >> > > > require the sources immediately. > >> > > > > >> > > > Sources for previous 2.x versions can be found either in the Archive > >> > > > below or on GitHub, github.com/sphinxsearch/sphin
Re: sphinx: Intention to orphan package
1/ Go to the package page: https://src.fedoraproject.org/rpms/sphinx 2/ Log in 3/ On top bar go to "Settings" (next to "Source", "Issues", "Pull Requests", "Stats") 4/ Left column "Give project" -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Mon, Feb 28, 2022 at 11:28 AM Sergio Arroutbi wrote: > > It makes sense to hand it over to you. I am OK with it. > > Does anybody have a guide on how to do so? > > On Mon, Feb 28, 2022 at 10:18 AM Michal Schorm wrote: >> >> Sorry for the delay. >> I checked with MariaDB upstream. >> >> https://mariadb.zulipchat.com/#narrow/stream/118759-general/topic/Sphinx.20SE >> >> The upstream last updated the version they are using ~7 years ago to >> version 2.2.6 and since it isn't a very important storage engine, it >> might be best to deprecate and remove it in the future. >> >> I offer to take over the package myself, and put the best effort I'll >> find to keep it alive and orphan it once MariaDB stops using it or it >> just won't build anymore. >> >> Michal >> >> -- >> >> Michal Schorm >> Software Engineer >> Core Services - Databases Team >> Red Hat >> >> -- >> >> On Thu, Jan 13, 2022 at 2:17 PM Michal Schorm wrote: >> > >> > MariaDB provides a Sphinx storage engine [1] which build is enabled in >> > Fedora. >> > The 'mariadb' SPECfile mentions following requirements: >> > >> > BuildRequires:sphinx libsphinxclient libsphinxclient-devel >> > Requires: sphinx libsphinxclient >> > >> > I guess that orphaning all (C or Python) versions of Sphinx in Fedora >> > will make me unable to keep building this SE. (The fact that it is >> > available via Pip doesn't help me during a package build) >> > >> > I haven't looked at this piece of MariaDB in years, I have to check >> > both myself and with the MariaDB upstream - whether they are aware of >> > this situation or if they already have a plan. >> > >> > [1] http://mariadb.com/kb/en/about-sphinxse/ >> > >> > -- >> > >> > Michal Schorm >> > Software Engineer >> > Core Services - Databases Team >> > Red Hat >> > >> > -- >> > >> > On Thu, Jan 13, 2022 at 1:48 PM Vitaly Zaitsev via devel >> > wrote: >> > > >> > > On 13/01/2022 13:33, Sergio Arroutbi wrote: >> > > > Latest binary versions from previous link (for example, v3.4.1) link to >> > > > python base source code. >> > > >> > > Also they decided co close sources last year: >> > > >> > > > 3.0 and up sources are currently only available under a delayed FOSS >> > > > or commercial licenses for several reasons; going back to regular >> > > > plain old GPL is planned but timing is moot; so email us if you >> > > > require the sources immediately. >> > > > >> > > > Sources for previous 2.x versions can be found either in the Archive >> > > > below or on GitHub, github.com/sphinxsearch/sphinx >> > > >> > > -- >> > > Sincerely, >> > >Vitaly Zaitsev (vit...@easycoding.org) >> > > ___ >> > > devel mailing list -- devel@lists.fedoraproject.org >> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> > > Fedora Code of Conduct: >> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> > > List Archives: >> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > > Do not reply to spam on the list, report it: >> > > https://pagure.io/fedora-infrastructure >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure > > > > -- > Sergio Arroutbi Braojos >
Re: sphinx: Intention to orphan package
Sorry for the delay. I checked with MariaDB upstream. https://mariadb.zulipchat.com/#narrow/stream/118759-general/topic/Sphinx.20SE The upstream last updated the version they are using ~7 years ago to version 2.2.6 and since it isn't a very important storage engine, it might be best to deprecate and remove it in the future. I offer to take over the package myself, and put the best effort I'll find to keep it alive and orphan it once MariaDB stops using it or it just won't build anymore. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Jan 13, 2022 at 2:17 PM Michal Schorm wrote: > > MariaDB provides a Sphinx storage engine [1] which build is enabled in Fedora. > The 'mariadb' SPECfile mentions following requirements: > > BuildRequires:sphinx libsphinxclient libsphinxclient-devel > Requires: sphinx libsphinxclient > > I guess that orphaning all (C or Python) versions of Sphinx in Fedora > will make me unable to keep building this SE. (The fact that it is > available via Pip doesn't help me during a package build) > > I haven't looked at this piece of MariaDB in years, I have to check > both myself and with the MariaDB upstream - whether they are aware of > this situation or if they already have a plan. > > [1] http://mariadb.com/kb/en/about-sphinxse/ > > -- > > Michal Schorm > Software Engineer > Core Services - Databases Team > Red Hat > > -- > > On Thu, Jan 13, 2022 at 1:48 PM Vitaly Zaitsev via devel > wrote: > > > > On 13/01/2022 13:33, Sergio Arroutbi wrote: > > > Latest binary versions from previous link (for example, v3.4.1) link to > > > python base source code. > > > > Also they decided co close sources last year: > > > > > 3.0 and up sources are currently only available under a delayed FOSS or > > > commercial licenses for several reasons; going back to regular plain old > > > GPL is planned but timing is moot; so email us if you require the sources > > > immediately. > > > > > > Sources for previous 2.x versions can be found either in the Archive > > > below or on GitHub, github.com/sphinxsearch/sphinx > > > > -- > > Sincerely, > >Vitaly Zaitsev (vit...@easycoding.org) > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64
The time had to come, when two packages would generate the same hash.
I was hit by:
---
Error: Transaction test error:
file /usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
conflicts between attempted installs of discord-0.0.16-1.fc35.x86_64
and skypeforlinux-8.79.0.95-1.x86_64
---
some time ago but since neither is a package maintained by Fedora
Project maintainers, no one gave a damn about the core of the issue.
That time, I got one of the apps as a Flatpak instead, but not all
packages have such workarounds at hand.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Sun, Feb 13, 2022 at 2:13 PM Miro Hrončok wrote:
>
> Hey,
> apparently some ELF files are identical between Fedora's pypy3.7-libs and
> pypy3.8-libs packages.
>
> On Fedora 34, this leads to installation conflict:
>
> Error: Transaction test error:
>file /usr/lib/.build-id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>file /usr/lib/.build-id/40/682aae1fc61eaa03230eac9033407ce96488c9 from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>file /usr/lib/.build-id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>file /usr/lib/.build-id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>file /usr/lib/.build-id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>file /usr/lib/.build-id/c9/e94d839699198b0e87c334f8e03160fec054de from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>file /usr/lib/.build-id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>file /usr/lib/.build-id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>file /usr/lib/.build-id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>
> As reported in https://bugzilla.redhat.com/2053880
>
> I've read all the previous discussion about this on Fedora devel list, but I
> still have no idea what should I do to prevent this conflict.
>
> Moving the files to a common component seems like a bad idea given it's not
> "two packages bundle the same thing" but rather "two packages built in a
> different way".
>
> I see this:
>
> https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.in#L177
>
> %{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
>
> I suppose I could pass in %{NAME} as well, right?
>
> What are the side effects for changing the seed like this?:
>
> %global __debug_install_post \
>
> %{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-id%-seed%s+"',
> rpm.expand('--build-id-seed "%{NAME}-')))}
>
>
> Actually, should RPM pass %{NAME} by default? Or at least have a macro I could
> redefine in a less cryptic and fragile way?
>
> --
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: sphinx: Intention to orphan package
MariaDB provides a Sphinx storage engine [1] which build is enabled in Fedora. The 'mariadb' SPECfile mentions following requirements: BuildRequires:sphinx libsphinxclient libsphinxclient-devel Requires: sphinx libsphinxclient I guess that orphaning all (C or Python) versions of Sphinx in Fedora will make me unable to keep building this SE. (The fact that it is available via Pip doesn't help me during a package build) I haven't looked at this piece of MariaDB in years, I have to check both myself and with the MariaDB upstream - whether they are aware of this situation or if they already have a plan. [1] http://mariadb.com/kb/en/about-sphinxse/ -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Jan 13, 2022 at 1:48 PM Vitaly Zaitsev via devel wrote: > > On 13/01/2022 13:33, Sergio Arroutbi wrote: > > Latest binary versions from previous link (for example, v3.4.1) link to > > python base source code. > > Also they decided co close sources last year: > > > 3.0 and up sources are currently only available under a delayed FOSS or > > commercial licenses for several reasons; going back to regular plain old > > GPL is planned but timing is moot; so email us if you require the sources > > immediately. > > > > Sources for previous 2.x versions can be found either in the Archive below > > or on GitHub, github.com/sphinxsearch/sphinx > > -- > Sincerely, >Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Does anybody still use `starship'?
I'd be happy if the package didn't die and was updated at least from time to time. I did an initial configuration based on what I liked and I don't expect to to change it for months. I'm personally not looking into the latest features but rather stability of what I already have. ❯ rpm -qa | grep starship starship-0.56.0-4.fc35.x86_64 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Sun, Jan 9, 2022 at 12:25 PM Igor Raits wrote: > > Hello, > > I saw some recent discussions (yet another time) how packaging Rust / > Go / Node.js is horrible, we should simply bundle everything and such. > Let's not discuss this here, though. > > I'm interested to hear if there are any users of the `starship' > application here in Fedora that consume it from the repositories. > Please speak up if you do! > > As pointed out in the other places, I don't think we are able to > update things like that as fast as releases popping out with just as > few people working on the packaging Rust stack these days (I'm pretty > much not contributing for last couple years due to the other work). > And the question, if we want to keep packaging it (with some slower > update cycle, as the time permits) or we want to retire it completely. > > Personally, I'd love to have more people working on packaging (and > most importantly keeping up-to-date) Rust crates / apps but I think > this is not so realistic :) > -- > — Igor Raits. > ___ > users mailing list -- us...@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/us...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora minimum hardware requirements
Thinking about this more, I always get to a question: "Who are the consumers of that information and what do they actually use it for?" My personal idea is that the _ recommended _ requirements (of any OS) are seeked by people that 1/ are going to install the system on some hardware on which that OS wasn't previously present 2/ are looking up values with which they expect fluent, smooth, experience both today and few year into the future 3/ _ want _ to install that OS, but have to purchase the HW yet, so they are looking at recommendations on what HW to buy The _ recommended _ HW requirements could be reviewed periodically also based on the current market offering. The market surely can differ through the world, as well as the average purchase power. However I wouldn't recommend anyone to e.g. go with less than 8GB of RAM today, when considering what new HW to buy or what HW to use for a setup intended to be used for years. Perhaps, we - as a community - might be able to gather our expectations and make some average for those values? The _ minimal _ requirements on the other hand are IMO seeked by an entirely different group of people that 1/ are looking up the minimal requirements on recent HW for e.g. IOT edition, or other use-cases in which you need to get the most of a not really powerful but recent HW 2/ are looking up whether some HW from a XYZ years or decades ago could run the Fedora Linux I understand it may be hard to check whether the HW meets the pure technical limitations. Though if we know how to do that, we may automate that and prepare some package, some script purely for the purpose of this check. We would also need to think about where to put it - the server edition maybe, or the net installer, or could we patch the GRUB2 itself with it, providing a custom call which could be selected as a separate boot entry in all the bootable media we provide ? What do you folks think - does the idea of defining the values based on the use cases of people that are _ actually likely to seek those values _ make sense as I tried to explain it? -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora minimum hardware requirements
Sigh, it is useless to search for Fedora documentation on google ... anything but _current_ Docs will be found. > Only Fedora Workstation edition explicitly states minimum hardware > requirements: "Fedora requires a minimum of 20GB disk, 2GB RAM, to > install and run successfully. Double those amounts is recommended." > https://getfedora.org/en/workstation/download/ And this doubling is not to be found in the Docs [1] in any other aspect than RAM size. The recommended HDD size value is 1/3 bigger than the minimal one. Also, the minimal CPU speed requirement apparently doubled between F32 and F33, but I don't see any Fedora Change for F33 listing that. [2] Both of that goes to a question - how are those values decided in the first place ? To target the Workstation edition regarding those values seems OK. However it seems to be far from the minimal requirements for a headless server, which is surely fine with less than 5GB of disk space. I believe that there are some technical limitations that we should list. E.g. having a 64-bit CPU with certain instructions / capabilities (at least for the X86_64 architecture family) Everything other than the hard technical limits is just an educated guess or assumption ... [1] https://docs.fedoraproject.org/en-US/fedora/f34/release-notes/welcome/Hardware_Overview/ [2] https://fedoraproject.org/wiki/Releases/33/ChangeSet -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, Oct 13, 2021 at 6:41 PM Chris Murphy wrote: > > Hi, > > Workstation working group was tracking this: > #241 Re-revisit Fedora Workstation minimums > https://pagure.io/fedora-workstation/issue/241 > > But to answer the questions, I think we need to broaden the > conversation, hence this email. > > Only Fedora Workstation edition explicitly states minimum hardware > requirements: "Fedora requires a minimum of 20GB disk, 2GB RAM, to > install and run successfully. Double those amounts is recommended." > https://getfedora.org/en/workstation/download/ > > Minimum hardware requirements is intended to setup some kind of > expectation of performance. The goal isn't the hardware requirement, > that's just the means of getting to the goal. So what's the goal? For > sure folks need to be able to install it plus some breathing room to > install additional software and user data. That gets to the minimum > storage space angle. > > But the CPU, memory, and IO angle are more complex. A completely > objective metric would account for the local workload, which we don't > know. So we're going to have to come up with a subjective > recommendation, i.e. take an educated guess. (I enjoy underscoring > that subjective != arbitrary.) > > How does the minimum hardware requirement achieve the intended goal? > And is it testable? We could ask folks to run some workloads on > low-CPU, low-memory hardware, and report 'grep -r . /proc/pressure' > whenever they think the system is performing worse than expected? Or > what? > > Anyway, this is just to kick off a conversation. Let's see where it goes. > > > > -- > Chris Murphy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
New package review - help needed from experienced Python maintainer(s)
Hello, I am a reviewer of a new Python package. [1] As I am far from being proficient, I seek another pair of eyes, a second opinion. I am an experienced packager, I am just new to Python packaging specifics. I'm looking for someone who will be able to help both the newcomer who submitted the package and me to learn Python packaging. Would you please someone join me and review my review? [1] [1] https://bugzilla.redhat.com/show_bug.cgi?id=2003700 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Packaging guidelines - clarification required - Users and Groups
Hello,
I seek a clarification on the "Users and Groups Guidelines" [1]
chapter of the "Fedora Packaging Guidelines" [2]
Please note I want such case to be clear to newcomers too.
While I am an experienced packager who has a fair idea how to navigate
in Fedora documentation, the same issue might be very confusing to the
packaging beginners among us.
--
During an attempt to update packages I maintain to match the Fedora
Packaging Guidelines, I encountered two different documents, from
which I cannot decide the correct one.
One is the (for me obviously) old [3] Guidelines page on the Wiki, but
it is NOT marked as obsolete, with the new guidelines ( I assume [1] )
linked, at the beginning of the document.
It is not easy to tell which of the documents is newer.
The "last edited" timestamp which is natural for Wiki is missing
entirely in the Docs.
The Docs has a value "Last build" in the footer, but that does not
provide information on the time the specific page was edited last.
My personal opinion is that Fedora has a fairly long ugly history of
documentation mess, so I'd deem it highly useful to NOT remove
lifebuoys (such as timestamps) from the pages, to allow Fedora
contributors to survive in the jungle of obsolete documentation. Git
blame on the page source is a lot of steps to be done to get such
information.
At first, it seems like part of the chapter "Soft static allocation"
with the code example from [4] is missing from the [5].
After careful investigation, it looks like a new system has been
adopted (".sysusers file" instead of "%pre scriptlet").
If that's true, the section "Values given to useradd and groupadd" [6]
feels more like a copy-paste error.
By examining the '%sysusers_create_compat' macro, I found out it does
the same thing as the code snippets in the other document [3].
The macro is brought in by 'systemd-rpm-macros' RPM. The name feels
deceiving - when talking about this very use case - as this very macro
itself is not related to systemd, but that's just one of the things
the package consists of. (so the name fits)
Then there is the package 'setup' [7], referenced by these Guidelines
documents. The package upstream is on Fedora Pagure [8].
And frankly, I have no idea what the package is supposed to do
regarding users, groups and ports listed in files 'uidgid' [9] and
'services' [10].
I am a maintainer of the packages 'community-mysql', 'mariadb' and more.
And I see that the 'mysql' name has a defined entry in both files and
neither is correct (up-to-date).
However I can't say I've ever encountered an issue with that, since I
create the 'mysql' user manually in the packages, as well as allowing
needed ports in the SELinux configuration.
So I would be grateful for an explanation of what those entries in the
'setup' package are used for.
Looking at the 'sysusers.generate-pre.sh' script [11], I can't tell
what the option "('m')" on line 67 is supposed to be for.
Actually, I'd use some documentation, since the code e.g. allows you
to set the shell only when you do not force a specific {UG}ID. I don't
understand this limitation and looking at [10] it is clear that a
_lot_ of system accounts use a different login shell than
"/sbin/nologin".
Summary:
Issues:
#1: Two Guideline documents with different content; neither marked as obsolete.
#2: Docs pages do not have a timestamp. Hard to tell which document is newer.
#3: The Guidelines differ and there seems to be a copy-paste error.
Questions:
#4: What is the purpose and usage of the 'setup' package?
#5: What are the guidelines around the 'setup' package? Does
everything that goes inside need FPC approval? Are the maintainers of
the referenced package responsible to keeping it up-to-date?
#6: Is there some documentation for the 'sysusers.generate-pre.sh' script?
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/
[3] https://fedoraproject.org/wiki/Packaging:UsersAndGroups
[4]
https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Soft_static_allocation
[5]
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_soft_static_allocation
[6]
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_values_given_to_useradd_and_groupadd
[7] https://src.fedoraproject.org/rpms/setup
[8] https://pagure.io/setup/tree/master
[9] https://pagure.io/setup/blob/master/f/services
[10] https://pagure.io/setup/blob/master/f/uidgid
[11]
https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/sysusers.generate-pre.sh
[12]
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email
Re: KOJI armv7hl builders out of resources
On Wed, Aug 4, 2021 at 6:31 PM Kevin Fenzi wrote: > Hopefully it fixes the community-mysql issue? Yes, I got a successful build on the first try without touching the Rawhide code. https://koji.fedoraproject.org/koji/taskinfo?taskID=73279974 Thank you very much for your help, Kevin ! Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, Aug 4, 2021 at 6:31 PM Kevin Fenzi wrote: > > On Tue, Aug 03, 2021 at 08:50:24AM -0700, Kevin Fenzi wrote: > > > > Yes, stupidly they updated to the normal kernel before the last reboot. > > So, they only see 3GB of their 40GB memory. :( > > > > I'll fix and reboot them today. I have no idea why this wasn't seen > > before now. I guess it shows that they are not really memory bound > > normally. :( > > Just to note that I fixed and rebooted all the armv7 builders yesterday. > > Sadly, this seems to have brought back > https://bugzilla.redhat.com/show_bug.cgi?id=1920183 > for python builds again. > > Hopefully it fixes the community-mysql issue? > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: KOJI armv7hl builders out of resources
Thank you for the suggestions.
I'll test reducing the debuginfo.
However I still believe something else is in play, as such errors are
normally very rare.
The package has already been built without issues; it was the F35 mass
rebuild which only bumped release, after which I noticed the FTBFS.
I also maintain a mysql module based on the same code. That's a lot of
builds already, so I would likely spot build issues, if they would
occur often.
Is there a way to check how much resources the KOJI build actually consumed ?
Michal
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Tue, Aug 3, 2021 at 11:44 AM Vitaly Zaitsev via devel
wrote:
>
> On 03/08/2021 11:31, Lukas Javorsky wrote:
> > And is there any suggested way how to handle this situation?
>
> Special hacks for ARMv7:
>
> 1. Build in one thread.
> 2. Reduce debug info: -g -> -g1 or even -g0.
>
> > Some spec build macro or something?
>
> %ifarch %{arm}
> %global optflags %(echo %{optflags} | sed 's/-g /-g0 /')
> %endif
>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
KOJI armv7hl builders out of resources
Hello, recently, package 'community-mysql' started to FTBFS, because of lack of resources on armv7hl builders in KOJI. Packages like 'mariadb' and 'community-mysql' are quite resource hungry, both for disk and memory. Occasionally it happens that out of random reasons, some builder here and there don't have enough resources. Usually because that particular builder was under heavy load. However this time, the armv7hl builds lack the resources in 100% builds for days in various times on various hosts. (1) Did the KOJI armv7hl builder's configuration change recently ? (2) Should I file an issue somewhere? Generic https://pagure.io/releng/new_issue ? First spotted: F35 mass rebuild. Reproducible: 100%, on all F33..Rawhide --- https://koji.fedoraproject.org/koji/taskinfo?taskID=73160741 https://koji.fedoraproject.org/koji/taskinfo?taskID=73161223 https://koji.fedoraproject.org/koji/taskinfo?taskID=72957127 https://koji.fedoraproject.org/koji/taskinfo?taskID=72968988 https://koji.fedoraproject.org/koji/taskinfo?taskID=73120117 https://koji.fedoraproject.org/koji/taskinfo?taskID=73120137 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Attempt to contact "Standard Test Interface" project collaborators
Hello, I tried to contact the people behind "Standard Test interface" CI. I sent the e-mail about 3 weeks ago. Then after about 2 weeks (= ~1 week ago) I reacted to the same email so it would appear in their inboxes again. Yet no response came, so i'm trying here. -- Original message ----- From: Michal Schorm Date: Wed, Jun 9, 2021 at 9:42 PM Subject: Fedora - Standard Test Interface - not enough verbose output To: , , Hello, I have a package: 'mariadb-connector-odbc'. It has a single STI test in it's dist-git repository, under 'tests' directory. I've made a PR to the package, attempting (amongst other stuff) to fix the test: https://src.fedoraproject.org/rpms/mariadb-connector-odbc/pull-request/2# This is the "Fedora CI - dist-git test", which is passing, but I'm not satisfied with: https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/dist-git-pipeline/job/master/49774/testReport/(root)/tests/ The thing is, that the Jenkins only show me a quiet log: https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/dist-git-pipeline/job/master/49774/testReport/(root)/tests/mariadb_connection/ However I want to see the verbose log by default. (A log that does not only show commands ran, but their output too) I've ran the STI test manually, in a VM. I've uploaded all the resulting artifacts here: https://mschorm.fedorapeople.org/ARCHIVE/Fedora-PR-Standard_Test_Interface-CI/ One of the artifacts is what I got in Jenkins: https://mschorm.fedorapeople.org/ARCHIVE/Fedora-PR-Standard_Test_Interface-CI/PASS-mariadb_connection-err.log And this is the one I want to see in jenkins: https://mschorm.fedorapeople.org/ARCHIVE/Fedora-PR-Standard_Test_Interface-CI/PASS-mariadb_connection.log Is there a way to get the type of the result I want from STI ? -- The artifact I want seems to be generated by default, so it shouldn't be difficult to add it to the Jenkins, right ? Also, it might be just a configuration issue in my own test. If I remember correctly, I wrote this test as an early adopter, about 3 year back. (git blame says 2018-05-10) and maybe I just need to update my 'tests.yaml' somehow ... -- Btw the Jenkins calls it "Standard Output", but when I ran it manually, that output was actually an error log: "PASS-mariadb_connection-err.log" The actual standard log was the verbose one :) "PASS-mariadb_connection.log" -- I've found your contacts here: https://docs.fedoraproject.org/en-US/ci/standard-test-interface/#_contact -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RPMLint 2.0 released!
This sounds terrific ! I too can't wait till Fedora adopts it. > * RPMLint includes _many more checks_! Nearly all of the generally However I always have a hard time understanding what the issue caught by RPMLint actually is. I would like to see some library of the checks with the explanation of what it is, why it is important and usual examples of bad / correct code and how to fix it. Something like CWEs (e.g. [1]) Is there something like it already by any chance ? There is a long way between an error / warning being reported by RPMLint with maintainer just ignoring it, and the maintainer to understand the value and importance of having it fixed (as well as knowledge how to fix it) [1] https://cwe.mitre.org/data/definitions/416.html -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Tue, May 18, 2021 at 2:01 PM Neal Gompa wrote: > > Hey all, > > Nearly four years and *754 commits* since rpmlint 1.10, we are > releasing rpmlint 2.0.0! > > This new release has a _lot_ of new features, but here are the most notable: > > * RPMLint now is a "normal" Python application and now supports being > imported like a standard Python module! This means that all the normal > use-cases for RPMLint are still supported, but now you can make it a > part of larger Python-based applications or services. > * RPMLint uses a declarative TOML-based syntax for configuring RPMLint > policy instead of Python code. > * RPMLint now has an override system for the descriptions shown for > various checks, so that distributions who want to give specific policy > information can do so without patching the code. > * RPMLint includes _many more checks_! Nearly all of the generally > useful checks created by the openSUSE community have been merged into > the tree, so distributions can now benefit from a wider offering of > checks to implement policy enforcement. > * RPMLint is Python 3 only and now supports Python 3.6 and newer. > * RPMLint is now built and installed like a standard Python > application using setuptools. > > I want to specifically thank Tomáš Chvátal, Martin Liska, Kristyna > Streitova, Dirk Mueller, Miroslav Suchý, Ondřej Súkup, thisisshub, and > Miro Hrončok as top contributors to make this release happen! > > Full author list with number of commits: > >309 Tomáš Chvátal >197 Martin Liska > 47 Dirk Mueller > 26 Kristyna Streitova > 24 Neal Gompa (ニール・ゴンパ) > 24 marxin > 21 Neal Gompa > 21 Ondřej Súkup > 14 thisisshub > 11 Miro Hrončok > 9 Kristýna Streitová > 8 Miroslav Suchý > 6 Markéta Calábková > 5 Ville Skyttä > 4 Ben Greiner > 4 Frank Schreiner > 4 Van de Bugger > 3 David Greaves > 3 Matwey V. Kornilov > 2 Daniel Mach > 2 Matthias Gerstner > 1 Cathy Hu > 1 Ludwig Nussel > 1 MeggyCal > 1 Petr Menšík > 1 Stefan Brüns > 1 Steve Kowalik > 1 Werner Fink > 1 Wolfgang Stöggl > 1 Yanko Kaneti > 1 tpgxyz > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Trying to reach "python-sqlobject" maintainer - Peter Lemenkov
Hi Peter, Yes, there is so far no immediate need to replace the packages. It's more about the fact that we have a better and up-to-date variant so if we would finish the process before F35 branching for Fedora Rawhide, it would be nice. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Sun, May 2, 2021 at 10:46 AM Peter Lemenkov wrote: > > Hello! > Sorry - totally missed that one. I've just merged this PR. > It's intended only for F-35, am I right? > > вс, 2 мая 2021 г. в 01:54, Michal Schorm : > > > > Hello, > > > > As a part of the initiative of replacing "python-mysql" package by > > "python-mysqlclient" package, we tried to fill PRs to the packages to > > switch to the new implementation. [1] > > > > We filed PR against the "python-sqlobject" package [2], however even > > though the maintainer committed since then to the package, he hasn't > > responded to the PR. > > > > Hope this message will reach him and the request will be taken care of. > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1929101 > > [2] https://src.fedoraproject.org/rpms/python-sqlobject/pull-request/1 > > > > -- > > > > Michal Schorm > > Software Engineer > > Core Services - Databases Team > > Red Hat > > > > -- > > > > > -- > With best regards, Peter Lemenkov. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Trying to reach "trytond" maintainer - Dan Horák
Hello, As a part of the initiative of replacing "python-mysql" package by "python-mysqlclient" package, we tried to fill PRs to the packages to switch to the new implementation. [1] We filed PR against the "trytond" package [2], however even though the maintainer was active in Fedora since then, he hasn't responded to the PR. Hope this message will reach him and the request will be taken care of. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1929101 [2] https://src.fedoraproject.org/rpms/trytond/pull-request/3 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Trying to reach "python-sqlobject" maintainer - Peter Lemenkov
Hello, As a part of the initiative of replacing "python-mysql" package by "python-mysqlclient" package, we tried to fill PRs to the packages to switch to the new implementation. [1] We filed PR against the "python-sqlobject" package [2], however even though the maintainer committed since then to the package, he hasn't responded to the PR. Hope this message will reach him and the request will be taken care of. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1929101 [2] https://src.fedoraproject.org/rpms/python-sqlobject/pull-request/1 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Gnome BZ untouched for years #1414539
How many more years can I expect it will take to resolve or at least seriously examine this following BZ? https://bugzilla.redhat.com/show_bug.cgi?id=1414539 Does the maintainer of the utility care ? Does he check the BZ tickets ? Does the gnome-sig triage the BZs against gnome components at least once a year? Who to contact? Who to turn onto ? -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: src.fedoraproject.org branch conversion to rawhide/main tomorrow
I checked out https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main And in the section "Phase2" I wanted to check out the scripts in "Release engineering:" sub-section. Surprisingly (not surprisingly) the links are dead now. Will you also go through all https://fedoraproject.org/wiki links and fix them too ? -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, Feb 3, 2021 at 12:09 AM Kevin Fenzi wrote: > > Greetings everyone. > > We finally have everything in place and hopefully tested to make the > switch tomorrow from master to rawhide/main branches for > src.fedoraproject.org. > > At 13:30UTC we will adjust pagure to reject pushes to 'master' and then > will be moving all the branches over to rawhide/main. As soon as all > packages are done, we will be adjusting pdc/hooks/existing pr's. > > We will be sending an additional email once changes are complete and > hopefully any downtime will be limited. > > Once the change is completed you will want to checkout rawhide/main > instead of master and update/recreate any existing forks you have. > > See > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main > for more information. > > Thanks, > > kevin > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel-annou...@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: HEADS UP: Intent to update python-mysql to 2.0.3
Hello, Even though I am the main admin of the package, I am not very proficient with Python packaging. I only made a few updates which were either effortless; or thoroughly consulted with a skilled Python packager. (I took over the package after Jakub become mostly inactive as a Fedora packager) Feel free to contribute. I will take a look at any PR proposed and try to test it - at least. If you want to rebase it to the latest version, it will be welcomed. --- > I also found reference to a 1 yo pull request to trytond[1] which appears to > be abandoned. You probably wanted to add following link: [1] https://src.fedoraproject.org/rpms/trytond/pull-request/2# Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Fri, Jan 1, 2021 at 4:22 PM Richard Shaw wrote: > > Looks like we've missed a few releases... Current version in Fedora is 1.4.6. > > I also found reference to a 1 yo pull request to trytond[1] which appears to > be abandoned. > > Affected packages are: > > $ dnf repoquery --repoid=rawhide --whatrequires "MySQL-python3" > trytond-mysql-0:4.0.4-15.fc33.noarch > > $ dnf repoquery --repoid=rawhide --whatrequires "python3-mysql" > dmlite-shell-0:1.14.2-1.fc34.x86_64 > holland-mysql-0:1.2.2-1.fc34.noarch > holland-xtrabackup-0:1.2.2-1.fc34.noarch > python3-biopython-0:1.78-2.fc34.x86_64 > python3-mysql-debug-0:1.4.6-5.fc34.x86_64 > python3-sqlobject-0:3.3.0-13.fc33.noarch > trytond-mysql-0:4.0.4-15.fc33.noarch > > While there is a major version bump looking at the changelog nothing drastic > jumps out at me. > > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F34 Change proposal: MariaDB 10.5 (Self-Contained Change)
I update the Wiki page to state that the current contingency plan is a revert of the change by bumping 'mariadb' package epoch. I also added a note about the dependent packages that need rebuild. That is a single package (amarok); I tested the rebuild in COPR and discussed it with the 'amarok' package maintainer. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Tue, Nov 17, 2020 at 8:12 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Nov 05, 2020 at 02:06:37PM +0100, Michal Schorm wrote: > > On Thu, Nov 5, 2020 at 12:21 AM Fabio Valentini > > wrote: > > > On Mon, Oct 26, 2020 at 5:21 PM Ben Cotton wrote: > > > > == Contingency Plan == > > > > > > > > Modules will provide the functional version of MariaDB 10.4, available > > > > to all users. > > > > * Contingency mechanism: Fedora Modules for 10.4 available > > > > > > This is not a sufficient contingency plan. Leaving broken 10.5 > > > non-modular packages in f34 is a non-starter. > > > > > > Is there a realistic path to back out of the 10.5 update in rawhide / > > > F34 if there are problems? > > > It looks like the 10.4 -> 10.5 update requires database upgrades as > > > well, so would MariaDB 10.4 have problems with accessing databases > > > that have been migrated to 10.5? > > > > In the worst case scenario, I would be forced to revert the change, > > bump MariaDB 10.4 package epoch and release F34 with MariaDB 10.4 > > instead. > > > > Database upgrades in general (this is not just about MariaDB or MySQL) > > are very problematic. > > Every sane DB upgrade *ever* should have a data backup prior and I > > don't want, nor have any means to, solve the cases of corrupted DB > > data which haven't got a backup. > > > > What would be an issue however, if a significant number of users would > > report the upgrade is problematic and they can't use the DB with the > > new version. > > The best thing both they and I can do is to file a BZ ticket (so we > > are informed about it in the first place). > > I will search the upstream JIRA ticket system for workarounds as a > > part of the problem solving. > > If any are found, I'd try to apply them or at least provide them to the > > users. > > > > If the issues would be in place but no solution in sight, the revert > > to MariaDB 10.4 in Rawhide (and F34 if already branched) is the way to > > go. > > > > If you will agree to this contingency mechanism, I will add it to the > > Self-Contained Change wiki page. > > Otherwise I'd ask you for a suggestion of what you picture as > > sufficient contingency mechanism. > > So, any progress on this? > > 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: F34 Change proposal: MariaDB 10.5 (Self-Contained Change)
On Thu, Nov 5, 2020 at 12:21 AM Fabio Valentini wrote: > On Mon, Oct 26, 2020 at 5:21 PM Ben Cotton wrote: > > == Contingency Plan == > > > > Modules will provide the functional version of MariaDB 10.4, available to > > all users. > > * Contingency mechanism: Fedora Modules for 10.4 available > > This is not a sufficient contingency plan. Leaving broken 10.5 > non-modular packages in f34 is a non-starter. > > Is there a realistic path to back out of the 10.5 update in rawhide / > F34 if there are problems? > It looks like the 10.4 -> 10.5 update requires database upgrades as > well, so would MariaDB 10.4 have problems with accessing databases > that have been migrated to 10.5? In the worst case scenario, I would be forced to revert the change, bump MariaDB 10.4 package epoch and release F34 with MariaDB 10.4 instead. Database upgrades in general (this is not just about MariaDB or MySQL) are very problematic. Every sane DB upgrade *ever* should have a data backup prior and I don't want, nor have any means to, solve the cases of corrupted DB data which haven't got a backup. What would be an issue however, if a significant number of users would report the upgrade is problematic and they can't use the DB with the new version. The best thing both they and I can do is to file a BZ ticket (so we are informed about it in the first place). I will search the upstream JIRA ticket system for workarounds as a part of the problem solving. If any are found, I'd try to apply them or at least provide them to the users. If the issues would be in place but no solution in sight, the revert to MariaDB 10.4 in Rawhide (and F34 if already branched) is the way to go. If you will agree to this contingency mechanism, I will add it to the Self-Contained Change wiki page. Otherwise I'd ask you for a suggestion of what you picture as sufficient contingency mechanism. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F34 Change proposal: MariaDB 10.5 (Self-Contained Change)
On Wed, Nov 4, 2020 at 10:55 AM Miro Hrončok wrote: > Are there packages that require rebuilding? E.g. I see that some packages > require libmariadbd.so.19. What is the plan regarding them? Packages that require the server (embedded) library "libmariadbd.so.19" are the only one that might need rebuild. Currently this is only a single package 'amarok', so I can cooperate with its maintainer if rebuild would be needed. The changes between the server embedded library between MariaDB 10.4 and 10.5 shouldn't be significant, other than added functionality. I have to check the ABI compatibility to be sure. If the functionality would be only extended, the dependent package might not need rebuild at all; though it still would get one during some mass rebuild. I added my above reply to the Self Contained Change. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: EOL and Obsoletes in Modularity
I haven't got a need to use obsolete modules yet, so I'll write my opinion about the module EOL only. Q: Should the EOL be configurable to mid-release date? The others in this discussion showed it makes sense to EOL a module mid-release. Since the modules are built on and on (new build targets are added, unless you blacklist them), it easily happens that it starts building for targets you didn't want to. (e.g. next fedora release; or 'el8') I would have used the mid-release EOL ability to kill the module on targets I haven't intended it would be built for. Real case with mysql 5.7 module. I don't want to maintain it any longer, after I maintained it for a release or two the MySQL 8.0 came out. But I haven't got any other choice than going to relengs and ask to EOL it; but since it was already built for rawhide, I had to wait for the Rawhide to EOL. I should maintain it, since I am it's maintainer and it wasn't EOL yet, but I didn't. I closed every CVE with WONTFIX ... as it was on the very bottom of my priority list but still not EOL ... and it is not EOL until this day. (synced with F31 EOL, so I'm already preparing a small celebration) So the answer is: * YES - I would be grateful to use mid-release EOL in some cases Q: How to set the EOL ? Pretty please, let me (the maintainer) do it! Any other way is IMHO the wrong way. Having to wait on someone, who does not know anything about the module content (e.g. upstream release cycles and decisions) is just awful. Both for maintainers and the poor people who must to process that. An ideal place is IMHO the same, single modulemd file used for defining the module. I don't understand why it had to be a separate file, but I can live with that. So the answer is: * YES - I, the maintainer, MUST to be able to set EOL on my own. Ideally in the same modulemd file A related question is - who knows how to find out the EOL dates now? Well I don't. PDC is a mess for me. And you know what? Based on a link provided by Petr Pisar: https://pdc.fedoraproject.org/rest_api/v1/component-branch-slas/?branch_type=module_component=mysql=5.7 MySQL 5.7 has EOL date set to 2020-09-15. Wtf is that date? Anytime I wanted to assure about the EOL date, I looked back at the releng ticket: https://pagure.io/releng/issue/8699 and checked it should be F31 EOL for mysql 5.7 But yeah, I get it. Since the Fedora release dates are not ultimately set, even releng couldn't know the exact date of F31 EOL back then, so it seems the module EOLed mid-release already, huh? So the side note is: * let me check the EOL date in some SANE way. (checking an EOL line e.g. in modulemd file is a sane way for me - the maintainer) Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F34 Change proposal: MariaDB 10.5 (Self-Contained Change)
Thanks Ben for the announcement. The MariaDB modules are available for testing right now in Rawhide and in BODHI. [1] I'll be thankful for any testing of the modules, so I can look into any issues that might appear, before getting the MariaDB 10.5 in the Fedora Rawhide base. MariaDB upstream aligned their release cycles to be more predictable. A new series should come out every year. With that said, I look forward to similar Self Contained Changes with similar failover mechanisms (modules of the current and new version available), so I'll also be glad for any tips for improvements of handling this and similar changes. [1] https://bodhi.fedoraproject.org/updates/?search=mariadb-10.5 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Announcement: unixODBC - moving unversioned plugins and libraries
On Fri, Oct 23, 2020 at 8:31 AM Ondrej Dubaj wrote:
> announcing moving unversioned libraries from unixODBC main package to
> unixODBC-devel package. Also moving unversioned plugins, which are in main
> package from %{_libdir} to %{_libdir}/unixODBC according to fedora packaging
> standards
I'm glad to see this happening.
Will you also take care of the packages which pack the ODBC plugins
(e.g. ODBC connectors to databases) to the %{_libdir} at the moment
(so their location is aligned with the other unixODBC libraries) ?
I know that at least two of my packages are affected, however it would
be great if you would either post a list of affected packages and
their maintainers, or submit PRs to them.
Michal
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)
On Thu, Sep 10, 2020 at 3:58 PM Ondrej Mosnacek wrote: > On Thu, Sep 10, 2020 at 3:48 PM Michal Schorm wrote: > > Does this mean, the "setenforce 0" won't work anymore? > No, no, don't worry, "setenforce 0" (i.e. switching SELinux to > "Permissive" mode) would not be affected and would work as before. That wasn't clear to me. Might be nice to add such a few words to the proposal. Thanks for clarification. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)
Does this mean, the "setenforce 0" won't work anymore? I use it quite a lot to examine the denials and audit2allow to generate updated rules which fixes my issues. I would see the inability of such workflow as a major drawback for *anyone* who doesn't just consume the default configuration. e.g. "My database datadir should reside elsewhere"; "my container should access pulseaudio socket"; "I've ran the default configuration with my data and it crashed" ... -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: %{_vpath_builddir} needs to be in the Cmake packaging guidelines
I further discussed it with Neil. We came to a compromise. We will document this macro and its potential usage, as well as the warning why and when it shouldn't be used; and an information that it will be removed in some future Fedora release. I've made a PR to the Docs [1], we should discuss its wording further there. Once the PR is accepted, the maintainers will be allowed to use this macro for the special compatibility reasons we talked about here, knowing of the drawbacks. (unstable private macro that will be removed) [1] https://pagure.io/packaging-committee/pull-request/1012 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Aug 6, 2020 at 1:13 PM Richard Shaw wrote: > > On Thu, Aug 6, 2020 at 5:35 AM Neal Gompa wrote: >> >> On Thu, Aug 6, 2020 at 6:20 AM Michal Schorm wrote: >> > >> > On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa wrote: >> > > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa wrote: >> > > > > You are not supposed to use %__cmake_builddir. >> > > >> > > It is not documented, and eventually will be removed. So don't rely on >> > > it. If you want to change the build directory, set %_vpath_builddir >> > > instead. >> > >> > Well, just make it documented ? >> > >> >> The %_vpath_builddir macro is *already* documented: >> https://docs.fedoraproject.org/en-US/packaging-guidelines/vpath/ > > > Ok, that helps, but it's rather non-intuitive that it's not with the CMake > packaging guidelines. A link would be nice from there would be nice. > > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: %{_vpath_builddir} needs to be in the Cmake packaging guidelines
On Thu, Aug 6, 2020 at 12:35 PM Neal Gompa wrote:
>
> On Thu, Aug 6, 2020 at 6:20 AM Michal Schorm wrote:
> >
> > On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa wrote:
> > > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa wrote:
> > > > > You are not supposed to use %__cmake_builddir.
> > >
> > > It is not documented, and eventually will be removed. So don't rely on
> > > it. If you want to change the build directory, set %_vpath_builddir
> > > instead.
> >
> > Well, just make it documented ?
> >
>
> The %_vpath_builddir macro is *already* documented:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/vpath/
But it doesn't do what we need.
This %_vpath_builddir macro gives a path to the defined builddir.
While %__cmake_builddir macro gives a path to the *actual* directory
that was used as a builddir.
Which is a huge difference, especially, when we talk about unifying
SPECfiles for F31, F32 and F33.
I see the macro defined as:
%__cmake_builddir
%{!?__cmake_in_source_build:%{_vpath_builddir}}%{?__cmake_in_source_build:.}
This very line will either be in the
"/usr/lib/rpm/macros.d/macros.cmake" from the
"cmake-rpm-macros.noarch" package, or in every SPECfile that needs
this macro.
Why can't it be part of the standard CMake macros set, given that it
does a different thing than %_vpath_builddir ?
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: %{_vpath_builddir} needs to be in the Cmake packaging guidelines
On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa wrote: > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa wrote: > > > You are not supposed to use %__cmake_builddir. > > It is not documented, and eventually will be removed. So don't rely on > it. If you want to change the build directory, set %_vpath_builddir > instead. Well, just make it documented ? Otherwise I probably would literally copy it to all of my SPECfiles ... . And from other replies I see I most likely won't be the only one who needs *exactly* behaviour of that macro. (To find out what the builddir path is; without need of changing it) It only makes sense to provide it in some central place - like among cmake macros - to avoid a lot of code duplication. The only other solution I see for now would be to change the builddir to some other location and use that around the SPECfile. But ... why? The re-defining of the location from a standard (for Fedora CMake SPECs) location neither does bring any benefit, nor do we actually want to do it. The solution is already in-place. And already we know we will want to use this macro (To find out what the builddir path is) in the future. If documenting it and making it "stable" is the only thing needed, I see it as a max. 5 minute work to save *a lots* of 5-minute work from others. (For each one per each SPECfile) Maybe there are some real issues behind the macro which makes it hard to standardize. I'd like if you share them in that case, so we might come up with a better solution together, on this list. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: %{_vpath_builddir} needs to be in the Cmake packaging guidelines
On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa wrote:
> On Tue, Aug 4, 2020 at 9:10 AM Richard Shaw wrote:
> > On Tue, Aug 4, 2020 at 6:17 AM Michal Schorm wrote:
> >>
> >> Since this change, all (subsequent) CMake commands (after "%cmake")
> >> MUST be used with the builddir argument ( "-B %{__cmake_builddir}" ).
> >
> > Ok, I'll use that in the future, but it still needs a mention in the
> > guidelines :)
> >
> You are not supposed to use %__cmake_builddir.
You say I'm not supposed to use that macro, but that's exactly the macro I need.
> That macro only exists
> so we don't have to mutate %_vpath_builddir when switching behaviors
> through %__cmake_in_source_build.
Any other way would do exactly what you just wrote here - I would be
re-implementing this macro - which doesn't make sense.
I'm open to new ideas, but this (using the "%__cmake_builddir" )
sounds like the most straightforward and easy way to do it.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: %{_vpath_builddir} needs to be in the Cmake packaging guidelines
Since this change, all (subsequent) CMake commands (after "%cmake")
MUST be used with the builddir argument ( "-B %{__cmake_builddir}" ).
I use in my packages "cmake -LAH" from time to time, to verify that
all CMake arguments (-D...) were passed and processed correctly, since
the processing logic behind each such argument can be quite
complicated.
Now (with the new CMake behaviour), when you call "cmake -LAH" after
you used the "%cmake", it will create a *new* cache, in the current
(that usually mean source) directory, *with incorrect values* and show
you that values instead of the correct ones (from the correct
builddir).
That was a nice quantum physic problem - since the new incorrect cache
was only created when you wanted to observe it :)
I'd like to anyone after me to not get caught by this (probably
correct, but not intuitive) behaviour.
I'd like to have the "%{__cmake_builddir}" and "%_vpath_builddir" more
visible, than hidden behind "See the Defining source and build
directories for more information".
I was on that page several times but I haven't clicked that link since
I was looking how to *get* the patch of the builddir, instead of
defining it.
I'd submit a PR, but unfortunately no good idea how to reword the
sentence has passed my mind yet.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Tue, Aug 4, 2020 at 9:37 AM Igor Raits
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Mon, 2020-08-03 at 22:14 -0500, Richard Shaw wrote:
> > Sometimes you need to get into the build directory, in my case for
> > OpenColorIO I use help2man to generate some of the man pages.
> >
> > I had to rely on the power of Google/Gmail to find Neal's response to
> > one
> > of my earlier emails to find the answer again...
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/
>
> %__cmake_in_source_build
>
> Controls whether builds are done in-source (when defined) or out-
> of-source (when undefined). See the Defining source and build
> directories for more information.
>
> Links to:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/vpath/
>
> Feel free to submit a PR to make it more visible.
>
> >
> > %{_vpath_builddir}
> >
> > But that begs the question, now that we have updated %cmake, and new
> > %cmake_build & %cmake_install, why is it %_vpath_builddir and not
> > %_cmake_builddir?
> >
> > 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
>
> - --
> Igor Raits
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8pECIACgkQEV1auJxc
> Hh4L7Q/+M7N/MJg0od9JZ2ri3Kcd7dtzd7WzU6X6/MPtoTtnTYd5AlJQM8zZYrfj
> jLFM6Hd9JdhReUodTeXYMzcuIRctjFNJv3ycI7E7pF5XvkQc6rnie6e/NwrUyCUG
> b0/I4F4RUpHQfAbR/Pa05lbBfFb1pN0jCoXsc77dLWLZ//FefBYEVYTdzc44mKhx
> TMOX8MPapBlu6P4XITajcI/cXMwecqgSfGPmiGwz2aqn9Ec4415khsKhjhT6CnaA
> IkgLGPHZwrO1WwZXnOR+TLR6QBpGyna3xLOCE7VskH+WmsYgd6UGTm+t86BFbBDl
> hThVdjK4I+uV0SU7qVq+NqtOIQRd014aKBGJpl1pmadjJhvBApJgZyC8e83OiOLm
> FC1OziylaOsYvJuUIZzBG7VMyFNM4J7YR8CKD4r0CLkvkCTT0Re0jzxmXzvZzQd+
> mmAsvehjIHPG0SDti8521l22dN7pvkvVO0OAfb0XDXKAdQaIQnosZyEi2G3Q4w1j
> kRNLyKsIvLdHaXMqqQ/6T/O5zkaSdM7vdD54HebdzcR3iVqy3TyaI8TmMsSlA0jz
> DfSd5/+W/dIen6lBOAwVO6R935Y9LCt5IdD5Szbs75wAJNOyRLnwHj2I8beNHxVi
> iaUNm4KdaKxupzqwiQ9EPpClssNdkgEi2HQi/q3B+PXSu57RrOI=
> =ZYgX
> -END 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor
+1 for nano. What I miss is the presence of nano in the default installations and images. I strongly believe it was there just a few Fedora releases back, but now, it's gone. I would really simplify - or atleast make more friendly - fast file editing / configuration on fresh systems. This might not be what this discussions is about, but I feel that it would be nice to have nano part of the default images / installations before we would start talking about making it default editor. (Assuming vi won't disappear) -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-packaging] Let's standardize the way to disable tests during RPM build?
On Fri, Jun 5, 2020 at 5:48 PM Nicolas Mailhot via devel
wrote:
> Some language ecosystems have very low quality unit tests ...
I'd discourage the "some test suites are bad, so let's disable them
all '' attitude.
Some very small and very stable testsuites may still be beneficial to
be run every time.
Though the "small" and "stable" again relies on the maintainer. (But
what does not, anyway ...)
On Fri, Jun 5, 2020 at 4:39 PM Miro Hrončok wrote:
> However rpmbuild itself doesn't support "CheckRequires", so the bcond often
> looks like this:
> %if %{with tests}
> BuildRequires: python3-pytest
> %endif
I fully agree. If the testsuite is not required to be run, sometimes
dozens of packages which are only test dependencies are not required
to be in the buildroot - thus they shouldn't be there.
---
Here's a little insight to huge MariaDB and MySQL packages:
MariaDB & MySQL have about 5000 tests in their testsuites nowadays
from which we run more than 4000.
Many of them scratch the whole DB and re-deploy it again, which *is*
time consuming.
While the build of the DB generally takes hours, the testsuite may
take ten times longer.
Historically on some slow-ass architectures, one build took about 2
days (looking at you 32-bit ARM)
Now if you add randomly failing tests - some because of the testsuite,
some because of the build machine (not enough ports available, or a
sudden heavy load triggered the test timeout, ...),
there's a huge need for decreasing the build time.
Currently, I implemented a macro which holds the "last tested version" value.
Once the maintainer (well, me), goes through the full testsuite for
all architectures, he can bump the macro value (to match the current
DB release version), and from then on, all later re-builds will run
only a very basic "sanity" testsuite which is short and stable, while
still check if the DB works at all.
Until a new release of the package is packed and the "last tested
version" value becomes lower than the current version and the full
testsuite needs to be run again.
This really helps anyone doing rebuilds and PRs.
Of course, that's not all. There are also implemented macros for "do
not run testsuite at all"; "run the full testsuite even though only
sanity check is required"; "if the testsuite will be run, ignore the
results (= always pass)", and so on.
Some may say such a huge testsuite shouldn't be run at the build time,
but well, this is just the upstream set of tests.
We have several other test frameworks with a lot of tests which are
triggered on each build. (e.g. installability tests, Red Hat internal
security regression tests, ... ) And the whole test suite again to
assure it passes in a real environment outside the buildroot.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Mon, Jun 8, 2020 at 10:58 AM Florian Festi wrote:
>
> May be https://github.com/rpm-software-management/rpm/pull/1256 does the
> trick. Comments welcome!
>
> Florian
>
> On 6/5/20 4:39 PM, Igor Raits wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > On Fri, 2020-06-05 at 16:10 +0200, Tomas Orsava wrote:
> >> Hi,
> >> I think it would be useful to have a standard way of disabling the
> >> running of tests during RPM build (in the %check section of a spec
> >> file).
> >>
> >> I see a lot of packages already having %bcond's or other macro
> >> definitions to archieve this, but each package has their own way,
> >> there's no real standard. Thus you have to first look into the spec,
> >> locate the appropriate %bcond or macro name and only then you can
> >> disable the tests.
> >>
> >> I would like to propose two approaches:
> >>
> >> (a) Add a *SHOULD* rule to the guidelines that specifies what is the
> >> preferred way to conditionalize the tests.
> >>
> >> (b) Or, if that's too strong, mention in the guidelines the common
> >> methods that are being used (e.g. %bcond tests and %bcond check) so
> >> that
> >> new packagers have something to use.
> >>
> >> What do you think?
> >
> > I'd like to have this finally be implemented in
> > https://github.com/rpm-software-management/rpm/issues/316. That way it
> > would be simply rpmbuild --nocheck or define %_without_check 1 which
> > would skip %check section entirely.
> >
> > For now, all Rust crates just have `%bcond_without check` so using `--
> > without check` works just fine there.
> >
> > Since this would be more generic thing to the RPM ecosystem, adding
> > rpm-ecosystem@ to the copy.
> >
> >> Tomas
> >>
Untouched BZ against cinnamon-desktop
Hi, A long time ago I filled a BZ for F29 against the package group @cinnamon-desktop-environment. [1] Now I checked, and the issue still exists, so I re-opened it and moved against F32. How can I get someone appropriate to notice it? The generic "Assignee: Alternative GTK desktop environments" seems unresponsive. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1684764 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Strange covert module builds [sbergmann ?]
> That new thing then gets leveraged into the next new thing with multiple > layers that would make MC Escher and Rube Goldberg proud. Awesome :D ... TL;DR: I don't need to investigate it further. I was afraid of rouge Fedora Module builds, which actually didn't happen. If flatpack needs to rebuild everything for them again, it's a pity (from the infrastructure load POV), but I'd guess there's no other way currently. Thanks for confirmation and clarification. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Mon, Mar 2, 2020 at 2:05 PM Stephen John Smoogen wrote: > > > > On Mon, 2 Mar 2020 at 07:32, Michal Schorm wrote: >> >> Can you please brief me really quick on how does the flatpack work >> from maintainer POV? (what does it need for build / creation; what >> does it need for runtime ) >> >> If the flatpack uses the packages from base Fedora; >> 'rpms/mariadb-connector-c', which I'm the maintainer of probably sent >> me the email to notify me, that someone somewhere built the package - >> which would be expected. >> >> Anyway, that doesn't clarify to me why the builds looks so much like >> module builds. >> > > The build system usually has to leverage whatever currently works and is > available to make whatever new thing people want to work. That new thing then > gets leveraged into the next new thing with multiple layers that would make > MC Escher and Rube Goldberg proud. > > I believe that Flatpacks use the container buildsystem which then relies on > parts of the module build system and some other items to accomplish their > tasks. How each of those deliver emails would depend on what tool emailed.. > it might be the build system itself or it could be some part of the FMN (no > idea what that stands for today) which saw a fedmsg which matched a filter > you are marked to get. > > > -- > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Strange covert module builds [sbergmann ?]
Can you please brief me really quick on how does the flatpack work from maintainer POV? (what does it need for build / creation; what does it need for runtime ) If the flatpack uses the packages from base Fedora; 'rpms/mariadb-connector-c', which I'm the maintainer of probably sent me the email to notify me, that someone somewhere built the package - which would be expected. Anyway, that doesn't clarify to me why the builds looks so much like module builds. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Mon, Mar 2, 2020 at 1:23 PM Stephan Bergmann wrote: > > On 02/03/2020 12:48, Michal Schorm wrote: > > I'm the maintainer of 'mariadb' & 'mariadb-connector-c' packages > > (rpms) and also 'modules/mariadb'. > > Recently, I discovered a 'modules/mariadb-connector-c' exists. Created > > by my colleague years ago, discontinued in 2017. > > This is correct - as we don't want it to build (anymore, most likely > > ever). There is 'mariadb-connector-c' in base Fedora (rpms namespace) > > and it should do all the job anyone would need. > > > > But I got this e-mail, saying it was recently built again: [1] [2] [3] [4] > > > > And it is very strange: > > 1) I don't know why I received the email (even though I'm glad I did). > > I'm not a maintainer of the 'modules/mariadb-connector-c', nor > > watching it (AFAIK). > > 2) I don't understand how the most recent release of the > > 'mariadb-connector-c' was built, since in the > > 'modules/mariadb-connector-c' repo, there's only versions from 2017 > > and last commits 2-3 years ago; but new release (rebuild from the same > > branch but newer (rpms/...) commit *REQUIRES* new (modules/...) commit > > ). > > 3) In all history of MBS [5] there are only 2 builds of > > 'modules/mariadb-connector-c', #1462 & #1463. > > No recent build, no nothing. > > 3) It is tagged for the LibreOffice. > > I'd like to know *why* anyone would like to build > > 'mariadb-connector-c' themselves instead of using the one available. > > 4) I tried to search for the "libreoffice" module, but haven't found any ! > > [6] > > > > > > At this point, I have no idea what's going on. > > The only hint is a LibreOffice *flatpack* [7] > > which mentions 'mariadb-connector-c' [8] > > I haven't met flatpack before, so I don't know how it works (and > > what's it good for), but still: > >A) I don't see the need to build the package again > >B) I don't understand why it would disguise so much as a Fedora > > Module. That would be really confusing and misleading, if that would > > be the case. > > > > > > The nick in Subject is the author of the KOJI build and a maintainer > > of the 'flatpaks/libreoffice'. > > Hope he may confirm / disprove that he's responsible for the build and > > some rel-eng or infrastructure member would explain why it behave so > > weird ... > > I assume whatever notification emails you get are a consequence of me > doing a Flatpak-from-Fedora-RPMs build of LibreOffice (see > <https://docs.fedoraproject.org/en-US/flatpak/>, > <https://src.fedoraproject.org/flatpaks/libreoffice>). > > But I have no idea how/why building that LibreOffice flatpak would > involve builds of a discontinued modules/mariadb-connector-c, or why you > are getting confusing email. Maybe Owen (in cc) can shed some light on > that? > > > [1] mbs/mbs.fedoraproject.org's > > mariadb-connector-c-3.1.7-1.module_f31+8201+43134e23 completed > > [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=1470803 > > [3] mbs/mbs.fedoraproject.org's > > mariadb-connector-c-3.1.7-1.module_f31+8207+96410d98 completed > > [4] http://koji.fedoraproject.org/koji/buildinfo?buildID=1471050 > > [5] https://release-engineering.github.io/mbs-ui/modules > > [6] https://src.fedoraproject.org/projects/modules/%2A > > [7] https://src.fedoraproject.org/flatpaks/libreoffice > > [8] > > https://src.fedoraproject.org/flatpaks/libreoffice/blob/master/f/libreoffice.yaml#_173 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Strange covert module builds [sbergmann ?]
Hello, I'm the maintainer of 'mariadb' & 'mariadb-connector-c' packages (rpms) and also 'modules/mariadb'. Recently, I discovered a 'modules/mariadb-connector-c' exists. Created by my colleague years ago, discontinued in 2017. This is correct - as we don't want it to build (anymore, most likely ever). There is 'mariadb-connector-c' in base Fedora (rpms namespace) and it should do all the job anyone would need. But I got this e-mail, saying it was recently built again: [1] [2] [3] [4] And it is very strange: 1) I don't know why I received the email (even though I'm glad I did). I'm not a maintainer of the 'modules/mariadb-connector-c', nor watching it (AFAIK). 2) I don't understand how the most recent release of the 'mariadb-connector-c' was built, since in the 'modules/mariadb-connector-c' repo, there's only versions from 2017 and last commits 2-3 years ago; but new release (rebuild from the same branch but newer (rpms/...) commit *REQUIRES* new (modules/...) commit ). 3) In all history of MBS [5] there are only 2 builds of 'modules/mariadb-connector-c', #1462 & #1463. No recent build, no nothing. 3) It is tagged for the LibreOffice. I'd like to know *why* anyone would like to build 'mariadb-connector-c' themselves instead of using the one available. 4) I tried to search for the "libreoffice" module, but haven't found any ! [6] At this point, I have no idea what's going on. The only hint is a LibreOffice *flatpack* [7] which mentions 'mariadb-connector-c' [8] I haven't met flatpack before, so I don't know how it works (and what's it good for), but still: A) I don't see the need to build the package again B) I don't understand why it would disguise so much as a Fedora Module. That would be really confusing and misleading, if that would be the case. The nick in Subject is the author of the KOJI build and a maintainer of the 'flatpaks/libreoffice'. Hope he may confirm / disprove that he's responsible for the build and some rel-eng or infrastructure member would explain why it behave so weird ... [1] mbs/mbs.fedoraproject.org's mariadb-connector-c-3.1.7-1.module_f31+8201+43134e23 completed [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=1470803 [3] mbs/mbs.fedoraproject.org's mariadb-connector-c-3.1.7-1.module_f31+8207+96410d98 completed [4] http://koji.fedoraproject.org/koji/buildinfo?buildID=1471050 [5] https://release-engineering.github.io/mbs-ui/modules [6] https://src.fedoraproject.org/projects/modules/%2A [7] https://src.fedoraproject.org/flatpaks/libreoffice [8] https://src.fedoraproject.org/flatpaks/libreoffice/blob/master/f/libreoffice.yaml#_173 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[rpms/perl-Test-mysqld] PR #1: Use the correct name of the required package
mschorm commented on the pull-request: `Use the correct name of the required package` that you are following: `` Hello, I'm the mainatiner of 'mariadb' and 'community-mysql', which both provides this "mysql-compat*" names. I'm trying to clean up ancient artifact and get rid of them. Your package is the only one using them nowadays. I changed the mysql-compat*" names to the actual result resolved by DNF, which is (correctly) 'mariadb' `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Test-mysqld/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[rpms/perl-Test-mysqld] PR #1: Use the correct name of the required package
mschorm opened a new pull-request against the project: `perl-Test-mysqld` that you are following: `` Use the correct name of the required package `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Test-mysqld/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora & Containers
Hidden from sight of any mortal man, I've found 'Fedora Container SIG' with as little information as possible [1], although they state, they have notes from 2019 DevConf meetup [2], but locked [3]. Atleast I found first place of discussion! [4] ... if you can say that about bunch of threads with 8k views on single thread, but no more than 100 replies in all topics & threads together. [1] https://fedoraproject.org/wiki/Container_SIG [2] https://fedoraproject.org/wiki/Container_SIG#Notes_from_meetings [3] https://public.etherpad-mozilla.org/p/fedoracontainerSIG [4] https://discussion.fedoraproject.org/c/server/containers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 & Containers
Hello, Will anybody be able to explain to me the current state of the containers & containerization in Fedora, please? I have some questions, but the more I searched for whom & where to ask, the more confused I became. -- 1) There ́s an IRC on freenode, '#fedora-containers' channel. The TOPIC set contains the following message: "The place for container runtimes and application containers. Forums @ https://discussion.fedoraproject.org/c/containers, visit the site @ https://containers.fedoraproject.org (website operational at some point in August)." However no link mentioned are accessible. 2) There is 'Fedora Container & Tools Documentation' [1] It is only half-filled with information, some part missing entirely. Even parts as 'Container Guidelines' [2]. Btw the wiki gladly redirects there ^ [3]. Btw there are some scratch notes about the guidelines from damn 2017 [4], which google offers me rather than the actual guidelines (because they don't exist) 3) So ... who is in charge of it? Whom to contact? How? Where? Does Fedora count with Containers or does it already thrown it overboard? 4) The container I am maintainer of (in pagure in 'container' namespace) is not branched automatically. The last branch is 'f30', but now I want to update it and add the missing branches. I have no idea how should I do it though, since (1) (2) are such a mess. I can try 'git push', but anyway, it won't solve the issue, it's not branched automatically. 5) The Dockerfile (are we still using this name? shouldn't it be 'containerfile' now, with podman?) starts with line like: " FROM registry.fedoraproject.org/f30/." How can I substitute the Fedora release version with a variable, so I can share the same content amongst branches for different Fedora releases? [1] https://docs.fedoraproject.org/en-US/containers/ [2] https://docs.fedoraproject.org/en-US/containers/guidelines/guidelines/ [3] https://fedoraproject.org/wiki/Container:Guidelines [4] https://fedoraproject.org/wiki/Talk:Container:Guidelines -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Defining the future of the packager workflow in Fedora
What is IMHO crucial is the understanding that the part of Fedora
infrastructure facing maintainers *needs* to respect the fact that
each (upstream) project is different, has different workflow, version
control system, way to make releases and to ship them, ... . Thus
Fedora must allow different approaches for different package(r)s.
A lot of automation would be appreciated, but it would turn to great
pain if enforced.
So, allow to go with PR-only workflow. Allow the PRs to be tested and
allow them to be automatically merged after passed testing, if the
maintainer sets so.
Opening PRs by release monitoring would be nice. Though the release
monitoring doesn’t work for my pkgs, since upstream does a series of
changes, git submodules fetching, and patching by other projects
before they release the tarball meant to be used as the sources.
Though it takes days to weeks after the upstream mark a certain commit
as “this we will release as version X.Y.Z.”, before they prepare the
tarball and test it for every channel they support.
Also, I *strongly believe*, we - as a significant GNU/Linux distro -
should use tools as are intended, instead of contrariwise.
And I believe the Git commit messages weren’t ever supposed to contain
magic words which will be parsed by some other tooling in order to
take actions. The annotated tags, on the other hand, seems (to me)
like a brilliant idea allowing us to kill the changelog that so much
maintainers desire to.
At the same time, there is so little documentation about “the right
way” to do things, as they are meant to. And only a small amount of
packagers knows the right ways and even less are taking them.
Commit messages are often useless as they don’t explain what changed,
why, and how. Patches doesn’t have any comments. Specfiles often
doesn’t have any good comments too - what the patch does, what for is
this dependency, why is that bundled, why is that test disabled, why
the build flags override … . (not only just) Provenpackages walking
around introducing changes that doesn’t make sense and doesn’t even
have a good justifications. Some people don't even care about e.g.
mentioning bundled part of the code … .
Working with other people’s packages are really hard. But IMHO, mostly
because of the people … .
As I work with newcomers, I see that it is really hard for new faces
to start - both before becoming packagers and even after that.
A huge number of tools and places they *should ideally* work with -
dist git, bodhi, bugzilla, PRs, pagure (to reach rel-engs), FAS,
koschei, abrt, anytia, modularity, wiki pages about the packages, wiki
pages about the changes, mailing lists, IRC, rpmlint, testing, … .
Even I find difficult to explore the full toolset that Fedora offers
and after years I still have no idea what the infrastructure looks
like, or where should I look it up.
And what is IMHO missing is the easy to explore documentation, or at
least some map of tools, ways and places with a “you are standing
here” mark and easy way to understand how to get where you want to be.
A huge FAQ (which would just link to the part of the documentation
with the answer) might help too, as I constantly see people new around
me asking the same questions again and again. Example questions: “can
I delete a branch? How to set EOL date for a module - it still keeps
building. How to write this and that in RPM. what to write to
changelog, what to commit message, what to bodhi update message, … ?
What does men the “rm -rf $RPM_BUILD_ROOT” in %install section? What
does that macro means? How do I find macro for this? Never heard of
“%{?systemd_requires}”, what’s that good for? Hey, you made that
scratch build just for aarch64 - how? ...”
All other observations, based on previous 200 mails, I’d summarize as:
*Please do:*
- kill changelog, please
- by annotated git tags, please
- Unificate the authentication methods
- Make release monitoring submit PRs instead of patches to bugzilla
- Give packagers tools for working with the distribution (e.g. show me
my dependency tree.)
- Tools to maintain the package as a part of ditro, instead of alone
- "Give me a list of all the things my package depends on, what
hasn't been updated in X years"
- “rebuild things that depend on my package upon this commit”
- unified web UI with all the information & build states and a unified
CLI client for doing literally everything.
- Allow to adjusts packager’s workflow as he wants (in some mantinels)
via automatization
- here I mean mostly automated testing, reporting, bodhi updates
(templates?), PR merging
*Please don’t:*
- require {most of the ideas} (like PR-only access, single branch,
source git, every commit is built...)
- because they just doesn't work for everybody
- Kill ancient artifact around Fedora packaging (e.g. “rm -rf
$RPM_BUILD_ROOT” in `rpmdev-newspec`, about which newcommers still
asking )
--
Michal Schorm
Software Engineer
Core Services - Database
Re: Question regarding systemd service unit cleanup
Hello, Can you specify which packages are the A & B? I wanted to reproduce the initial situation - that the service requiring another will put a symlink to the "/usr/lib/systemd/system". I forged iptables RPM containing service file mentioning "Requires=firewalld.service" to see the link to be created, but it wasn't. (iptables because it builds fast and firewalld because it is already installed) I wanted to run audit on the location to catch a process which would create the symlink, in a hope that it won't be systemd itself, but rather some systemd helper script, which name would be good starting point for google. ( "auditctl -w /etc/systemd/system/" and "ausearch -f /etc/systemd/system/" ) -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Sat, Oct 12, 2019 at 8:12 AM Ravindra Kumar via devel wrote: > > > You need something like this in a scriptlet: > > if systemctl is-enabled A; systemctl reenable A; done > > > > This will remove the old links and create the new ones. > > Thanks Zbigniew for the idea. It seemed very promising and I tried it. > Unfortunately, it still did not help because "reenable" command seems to > recreate the links based on the service unit file which is newer and does not > reference the dropped dependency. So, the old link to service B was still > left around. > > The only working solution I have found is to disable service B explicitly in > post install scriptlet when it is called during upgrade. > > Thanks, > Ravindra > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: Renewing the Modularity objective
> When MySQL 8 is being developed and being packages as module, do you > build the module for Rawhide only or for all Fedoras? > > If you build it for all Fedoras, how do you deal with incompatible > changes during the MySQL 8 developement. I'm hitting on the Fedora > Updates Policy that forbids incompatible changes in stable Fedoras. > > If you build it for Rawhide only, how do you ensure that the module is > not inheritted into a stable Fedora on branching. Because in case of > branching F31 relengs tried very hard to branch the module and rebuild > them. (Despite I told them not to do that with perl:5.26.) That's a great observation. Ususally when the package (module in this case) is prone to breaking bugs, I develop it in Rawhide and only later, (e.g. Beta, but it depends from upstream to upstream) I extend the build to other Fedoras. > I'm still missing an offical recognition that there can be modules under > development in stable Fedora. Otherwise we have no way of developing new > modules. Fedora tries very hard to align module lifecycle to Fedora > lifecycle. It does not work for me. That's surely an *absolute need* to have an option to mark a module as "under developement" or something simmilar and have that anchored in the guidelines, if we want to use this chance a modularity technically offers. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Sep 19, 2019 at 2:33 PM Petr Pisar wrote: > > On 2019-09-19, Michal Schorm wrote: > > While the new major version of the database is being developed, I'd > > love to pack it in Fedora, test it, offer it to the users and provide > > feedback to the upstream, solving the uprising issues with them way > > before the GA. > > Because I want to keep a stable version in the base Fedora, I'm using > > modules to provide both of them. > > E.g. when MySQL 8 was being developed ( pre-GA releases ), I normally > > maintained the MySQL 5.7 (latest stable major version) in the base > > Fedora, while having MySQL 8 as a module. > > > When MySQL 8 is being developed and being packages as module, do you > build the module for Rawhide only or for all Fedoras? > > If you build it for all Fedoras, how do you deal with incompatible > changes during the MySQL 8 developement. I'm hitting on the Fedora > Updates Policy that forbids incompatible changes in stable Fedoras. > > If you build it for Rawhide only, how do you ensure that the module is > not inheritted into a stable Fedora on branching. Because in case of > branching F31 relengs tried very hard to branch the module and rebuild > them. (Despite I told them not to do that with perl:5.26.) > > I'm still missing an offical recognition that there can be modules under > development in stable Fedora. Otherwise we have no way of developing new > modules. Fedora tries very hard to align module lifecycle to Fedora > lifecycle. It does not work for me. > > -- 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Renewing the Modularity objective
I'd suggest that the Modularity team could preapre a list of example
use cases that will present the strenghts of the modularity.
I believe, there are currently many examples of packages that took a
path to become only modular and it always created more issues than it
solved.
Let's focus on a simple use cases first, which only modularity can
solve the best and leave the more complicated ones for later - after a
careful consideration if turning some regular packages into only
modules would really help both packager and user experience.
Keep in mind, there are still wide gaps in the modularity packager
experience, new bugs spawning every now and then.
In light of this persistent situation, I honor the new goal currently
set of focusing at those issues.
--
I'll start with my use case, which IMHO can be used as a great case
advocating for modularity.
I'm a maintainer of MariaDB, MySQL and some software around.
While the new major version of the database is being developed, I'd
love to pack it in Fedora, test it, offer it to the users and provide
feedback to the upstream, solving the uprising issues with them way
before the GA.
Because I want to keep a stable version in the base Fedora, I'm using
modules to provide both of them.
E.g. when MySQL 8 was being developed ( pre-GA releases ), I normally
maintained the MySQL 5.7 (latest stable major version) in the base
Fedora, while having MySQL 8 as a module.
When the MySQL 8 went GA, I had MySQL 5.7 in Fedora N and MySQL 8 in Fedora N+1.
However at the same time I also provided MySQL 5.7 as a module in both
Fedora N and N+1. Same for MySQL 8 module (in both Fedora N & N+1).
That way, the users weren't forced to upgrade right away (once the
Fedora N went EOL), but they got time to prepare and / or test it
first.
In a case, when user is hungry for the very latest version, he has the
MySQL 8 available before it went ot the base Fedora, and even before
the MySQL 8 went GA, so he can provide feedback to the upstream either
directly or through me (via BZ).
Since the upgrades between Fedora releases with modules when the
version in Fedora base changes are still not really thought through,
you (as a user) need the same module in the both Fedora N & N+1,
beacuse you can't upgrade Fedora version from MySQL 5.7 that was in
base to MySQL 5.7 module, since newly there is MySQL 8 is in the base
Fedora.
I believe no other applicable solution is as elegant for my use case,
as modularity has.
COPR repositories are hidden from the users (you first need to know
which repo you want to use before getting it's content), and the
builds from there are not pushed through the updtae system (BODHI) to
discover bugs early.
New package (named e.g. 'mysql-8' ) is also far from "elegant"
solution. Even further when I (the pkg mainatiner) plan to soon (once
GA is released) update to that version in the original package.
The same for MariaDB 10.3 -> 10.4; future 10.4 -> 10.5 ...
--
I strogly believe a list of use cases like this would make the
modularity much more clear to both mainatiners and users.
Stick to Unix philosophy ("Do One Thing and Do It Well") and don't
rush or even try to make modules from everything.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Wed, Sep 18, 2019 at 9:32 PM Ben Cotton wrote:
>
> Now that Modularity is available for all Fedora variants, it's time to
> address issues discovered and improve the experience for packagers and
> users. The Modularity team identified a number of projects that will
> improve the usefulness of Modularity and the experience of creating
> modules for packagers. Thoe team is proposing a renewed objective to
> the Fedora Council.
>
> You can read the proposal at:
> https://pagure.io/Fedora-Council/council-docs/pull-request/61#request_diff
>
> The Council will vote on this in two weeks.
>
> This is also posted to the Community Blog:
> https://communityblog.fedoraproject.org/renewing-the-modularity-objective/
>
> --
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: [Test-Announce] Fedora 31 Beta Release Announcement
> Featuritis? Actually, do not see any usefulness in any module. *any* module ? Maybe you just haven't met the right use case yet. I maintain packages of MariaDB and MySQL projects. There's no better way I can imagine, to develop two version of the packages of the DB, than modules. Fedora have MariaDB 10.3 in base. 10.4 in modules. I maintain both, I actively fix both and I try to cooperate with upstream to get it so stable, that Fedora could switch to 10.4. [1] Apart from that, I don't want to force useres to do the upgrade immediatelly. I'm providing both 10.3 and 10.4 as modules (even though 10.3 is also in base), so the user can switch to the desired stream and stay with it, no matter when I introduce the new version into the base Fedora. of course, I don't plan to mainatin the 10.3 forever after the change will be made, but I believe i surely might come handy to someone, who wants the up-to-date and secure Fedora, but haven't got time to upgrade 10.3->10.4 yet. Althought I agree with that many of the modularized packages are not useffull modularized, and / or creates more issues that way; I certainly find the modularity usefull. As per Unix motto "do one thing and do it well" [2], I never expected modularity to solve all of my problems and use cases. Just some. And it did. Just fine. For me. ( Disclaimer: modularity will need time to also comply with the part "do it well" ;) ) [1] https://fedoraproject.org/wiki/Changes/MariaDB_10.4 [2] https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, Sep 18, 2019 at 2:07 PM Ralf Corsepius wrote: > > On 9/18/19 12:11 PM, Kalev Lember wrote: > > > > On 9/18/19 10:29, Petr Pisar wrote: > >> On 2019-09-18, Ralf Corsepius wrote: > >>> - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is > >>> excluded > >> > >> Funnily DNF finds out that you could actually get that package satisfied > >> if you enabled a modular Perl. Unfortunatelly DNF does not report what > >> module stream the modular perl-libs packages comes from. There is indeed > >> some room for improvement. DNF could start recommending "maybe you wanted > >> to enable perl:5.28 stream?" :) > > Openly said, to me, the modules are permanent source of troubles. > > > Hm, did perl get moved to the modular repo? That sounds like it is going > > to cause more issues than solve as it's not a leaf package. Why can't it > > stay as a regular package? > Featuritis? Actually, do not see any usefulness in any module. > > Ralf > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Licensing of the bundled libraries
Hello, Q: Is it needed to explicitly list (or pack) license (files) of a library that a package bundles? [1] And if yes, what's the right way to do so? The built package only contain 1 binary (and it's manpage and license file). In this case - when no sources are packed - I'd understand that it is sufficient to list and pack only the single license of the resulting project. Is that correct? -- The package is 'pgloader' and it is now on a review to enter Fedora. [2] -- [1] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios [2] https://bugzilla.redhat.com/show_bug.cgi?id=1748233 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: How do I remove GLIBCXX_ASSERTIONS?
I personally use:
https://src.fedoraproject.org/rpms/galera/blob/master/f/galera.spec#_40
| %build
| %{set_build_flags}
|
| # FTBFS with the GLIBCXX_ASSERTIONS; #1546787
| CPPFLAGS=`echo $CPPFLAGS| sed -e "s|-Wp,-D_GLIBCXX_ASSERTIONS||g" `
| CFLAGS=`echo $CFLAGS| sed -e "s|-Wp,-D_GLIBCXX_ASSERTIONS||g" `
| CXXFLAGS=`echo $CXXFLAGS| sed -e "s|-Wp,-D_GLIBCXX_ASSERTIONS||g" `
| export CPPFLAGS CFLAGS CXXFLAGS
until it's solved.
Of course, if somebody has some more elegant solution, I'll be happy
to adopt it.
Michal
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Fri, Aug 2, 2019 at 5:01 PM Steven A. Falco wrote:
>
> The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS
> from the Fedora package, as described here:
> https://bugs.launchpad.net/kicad/+bug/1838448
>
> What is the best way to do that? I can add "%undefine _hardened_build"
> (which I am testing now) but I think that will remove other hardening
> features that I might want to leave enabled.
>
> Steve
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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 31 System-Wide Change proposal: No More i686 Kernels
I - and a people around me - have plenty of 32-bit hardware. In case of e.g. volunteer youth work. When you need a dozen or two of PCs where do you get them from? They are those old machines you no longer use; the one your uncle gave you when he bought new laptop; the friend's one that broke but you managed to paritally fix it ... that's how you accumulate dozens of machines through the years so you can use them now. Nobody will ever just buy you a bunch of modern laptops just because you prepared something cool for the kids. And I'd love to run Fedora on them, since I know the OS the best and I'm developing on it. I'm able to automatize "cluster" installations or configurations fo those machines without learning much new. I already said I wouldn't like to see i686 support dropped, when the discussion was on the table last time. However I learned back then from someone's reply, what I think should be a golden rule around here. There can't be a project without developer / maintainer. Do *YOU* want to maintain it? No? Then who should? We are a community of volunteers. You can't force anybody here to maintain it for you. i686 will be missed by me. But I'm both not able to maintain & bugfix the (32-bit) kernel, nor I'm willing to devote it my time to learn and do it. It's same as any other orphaned package. No one willing to maintain it? FTBFS? Say "bye" to that package. Pitiful, but easy as that. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, Jun 26, 2019 at 12:16 AM Dominik 'Rathann' Mierzejewski wrote: > > On Tuesday, 25 June 2019 at 14:36, Bruno Wolff III wrote: > > On Mon, Jun 24, 2019 at 23:17:30 -0500, > > Justin Forbes wrote: > > > > > > It is not a violent cheat. It was proposed this way 2 years ago. At > > > the time a SIG was created to maintain i686 so that it could continue > > > as a secondary arch. They are inactive. See the post in the SIG there. > > > When a call for a status was made (as the only traffic on their list > > > so far this year), it got a single reply from someone saying that they > > > would no longer have 32bit hardware as of August. > > > > I'm the one who responded. > > FWIW, I still have two Asus EeePCs (900 and 1000) that are being used. > They're Atom N270 based, so 32-bit only. I'd like to run the most recent > Fedora on them, but I don't have much time to devote to debugging > i686-specific issues. > > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: Any new restriction in Koji added recently in Rawhide?
You may consider adding your package to the Koschei service: https://apps.fedoraproject.org/koschei/package/python-elixir which will do rebuilds when the buildroot change, and it will show you the changes in a well readable way. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Jun 13, 2019 at 11:44 AM Peter Lemenkov wrote: > > Hello All! > I've noticed that I cannot build Elixir in Rawhide anymore. It got > stuck at tests and all I've got is a cryptic (at least to me) message: > > > + RPM_EC=0 > BUILDSTDERR: ++ jobs -p > + exit 0 > > > See this link for full build log: > > * https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log > * https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975 > > For comparison here is how successful build log for F-30 looks like > (the same package) > > * https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log > * https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984 > > Are there any differences between Koji settings for Rawhide and F-30 > which we should know about? Selinux, resource constraints etc? > -- > With best regards, Peter Lemenkov. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Wiki page correction: GRUB2
> Be bold and just update the page... it's a wiki, so it keeps a change > history, and if someone else has a problem with what you wrote, they can > either update it or roll back the changes. You shouldn't ever feel like you > have to ask permission or have the details 100% correct before updating > something on the wiki. I'm not looking for a permission. I'm looking for a sanity check. I personaly take care of several wiki pages. If that would be a subject I understand well and I'm confident in, I'd edit right away. I also take it as a chance, that someone may spot it's not right and uncover some packaging issue by it. The fact It's a wiki IMHO doesn't imply anyone *should* edit it without being confident about it. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, May 29, 2019 at 8:51 PM Jared K. Smith wrote: > > On Wed, May 29, 2019 at 8:01 AM Michal Schorm wrote: >> >> However I'm not confident enought to edit it prior to any discussions, >> so that's why I'm writing here. > > > Be bold and just update the page... it's a wiki, so it keeps a change > history, and if someone else has a problem with what you wrote, they can > either update it or roll back the changes. You shouldn't ever feel like you > have to ask permission or have the details 100% correct before updating > something on the wiki. > > -- > Jared Smith > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Wiki page correction: GRUB2
Also, it's IMHO worth mentioning, a package 'grub2-pc-modules' is
needed on BIOS systems in order to 'grub2-install' utility to work
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Wed, May 29, 2019 at 1:50 PM Michal Schorm wrote:
>
> Hello,
>
> I'd like to propose tiny correction for the Fedora wiki page about GRUB2 [1].
>
> However I'm not confident enought to edit it prior to any discussions,
> so that's why I'm writing here.
>
> In the chapter "Updating GRUB 2 configuration on UEFI systems"
> In the section "Install the bootloader files"
> I believe, there should be an information added, that the 'grub2-efi'
> package *must* match your architecture. So e.g. for x86_64, you want
> the 'grub2-efi-x64' package.
>
> By default the 'dnf install grub2-efi' will find 'grub2-efi-ia32'
> package which doesn't contain the files you need for boot on x86_64
> system, nor pulls the correct package as a dependency.
>
> Also, on once of my old F28 Cinnamon system, I can see, that there are
> packages:
> $ dnf list installed | grep grub2-efi | awk '{ print $1 }'
> grub2-efi-ia32.x86_64
> grub2-efi-ia32-cdboot.x86_64
> grub2-efi-x64.x86_64
> grub2-efi-x64-cdboot.x86_64
>
> but I believe I only need the 'grub2-efi-x64.x86_64'.
> Given that, maybe the anaconda installation should be checked to not
> pull uneeded packages?
>
> Correct me, if I'm wrong, thanks.
>
>
>
> [1] https://fedoraproject.org/wiki/GRUB_2
>
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
