Re: What is Fedora?
I'm no lawyer here, and I've only worked with Linux for roughly 8 years now, but I find all of this GPL / redhat terms of agreement very confusing and seems at the face of it to be in conflict with each other. For example, Red Hat states: "If you use the Individual Developer Subscriptions for any other purposes or beyond the parameters described in these Program Terms, you are in violation of Red Hat’s Enterprise Agreement and are required to pay the Subscription fees that would apply to such use, in addition to any and all other remedies available to Red Hat under applicable law. Examples of such violations include, but are not limited to, ● using the Red Hat Subscription Services for Individual Development Use and/or Individual Production Use on more than sixteen (16) Physical or Virtual Nodes, or ● selling, distributing and/or rebranding the Red Hat Subscription Services (or any part thereof) contained in the Individual Developer Subscriptions. " However, the GPL section 4 seems to make pretty clear on how I can "convey verbatim copies" , allowing me to essentially copy/modify the built binaries and take those to any machines as I see fit. Although redhat provides a free Developer license and access to its source, all I could find with a Dev license was the iso image, either its very difficult to find, or does not exist and I don't believe access to an ISO complies with the GPL either, as the GPL guarantees access to the preferred form of work for the making of modifications to it. Even if redhat did in fact provide access to a git repo of some kind walled off by a user account and buried behind mouse clicks, would I still be able to compile and build rhel from source and run that on more then 16 machines? Or will I be in violation with Rhels terms and in for a potential lawsuit? On 6/21/23 14:45, JT wrote: There are mirrors online that you can pull from as well if you dont have an account or know someone who has an account. Or you can create a dev account with a throw away email to get the ISOs. I'll happily download any ISO you want. :P I know several people that their dev account is linked with their personal gmail account, but I havent created a new dev account in a while so IDK if they filter for domains. Red Hat has even released instructions on how you can run your own mirror. I believe you do need a RH login to access those instructions. https://access.redhat.com/solutions/23016 Example sources: https://archive.org/details/rhel-baseos-9.1-x86_64-dvd_202212 http://calipso.linux.it.umich.edu/pulp/isos/UM/Library/content/dist/rhel8/8/x86_64/baseos/iso/ If you're concerned about getting an ISO from anywhere other than RedHat.com, then I'd suggest you sign up for a free account with a fresh email account that is only used for your RH account. At the end of the day, the source will always be available in some form, Red Hat cannot violate the GPL without opening itself up to massive lawsuits. On Wed, Jun 21, 2023 at 5:27 PM Philip Wyett wrote: On Wed, 2023-06-21 at 17:18 -0400, JT wrote: > > > How are you downloading RHEL ISO images? > > I already sent you the URL in a prior response: > https://developers.redhat.com/products/rhel/download > > > Please do not tell me to take a deep breath and relax. Show some respect. > > I am being respectful, I've been trying to explain to you that this isn't anything to get > stressed out over. I've calmly addressed the questions you've raised. > What you are worried about is not possible because of the legal requirements of the GPL which Red > Hat has accepted by using GPL licensed code. > > You're stressing out over a non issue... you dont need to stress over this... aka... you can > relax... it's going to be ok. > > If me addressing your concerns and telling you that you dont need to worry is disrespectful... > well... I'm sorry that you think I'm being disrespectful. I'm trying to make you feel better by > explaining that you dont need to be worried. > I did say I tried this, but nobody is listening... Attached: One mage saying Download/Signup One image when you click on download at no cost and you need to login or create an account. Beauty of using clean VM's Regards Phil -- *** Playing the game for the games own sake. *** Associations: * Debian Maintainer (DM) * Fedora/EPEL Maintainer. * Contributor member of the AlmaLinux foundation. WWW: https://kathenas.org Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg Twitter: @kathenasorg Instagram: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-le...@lists.fedoraproject.org Fedora Code of Con
Re: Towards enabling rpm sysusers integration
On 6/22/23 18:01, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jun 22, 2023 at 01:18:27PM +0300, Panu Matilainen wrote:
Hey all,
Now that the initial hurdle of getting rpm 4.19 into rawhide is over, it's
time to start looking towards enabling the sysusers integration:
https://rpm-software-management.github.io/rpm/manual/users_and_groups.html
Cool, let's do this!
That's the spirit :D
We (as in rpm-team) are not pushing for doing all this in Fedora 39, this is
more to start discussion and lay down the necessary steps. In the 4.19
builds so far, the sysusers integration has been entirely disabled because
it needs more coordination than just drop it in. Much of it is between
systemd and rpm, but any package with non-root ownerships will be affected
in the end. At least the following, and not necessarily exactly in this
order:
1. systemd has it's own user/group provides generator which directly
conflicts (both on generated content and file level) with the new native
generator in rpm, and the feature will not work with the provides generated
by systemd.
I merged your PR to disable this, so this first step is done.
Thanks! I'll enable the generator in rpm then.
2. systemd provides users and groups that are actually owned by the setup
package. As rpm is now turning non-root file ownership into dependencies,
systemd could end up pulled in where setup is needed (eg early install
stage) which will not end up well. So systemd will need to stop providing
users it does not actually own.
I was hoping we would be make the dependency on setup optional.
It is a fairly heavyweight package (700+ kb) and with lots of
not-that-useful-on-a-typical-modern-installation stuff (mail alias support,
csh profile, /etc/hosts, nfs exports, etc.). Most of this is tiny, but it
clutters /etc, which ideally would be empty, and also /etc/services is 700 kb.
setup is currently pulled in by dependencies, but e.g. in the initrd we should
be fine without it. (And the same applies for e.g. minimal container
images without login users or a shell.)
Maybe the non-essential stuff could be split out into a new
subpackage, with setup only providing /etc/{passwd,group,shadow,gshadow}
with the base set of users and groups, and all other files moved to
setup-clutter.
Oh, "setup" is not special to rpm in any way, I only talk of it because
that's where /etc/{passwd,group} traditionally reside. Rpm grabs the
user/group provides from those files on encounter, so no rpm-side
changes are needed if they get moved to some other package.
3. The various %sysuser_()* macros in systemd-rpm-macros need to be phased
out. As it'll be a long time before the sysusers feature is in all Fedora
versions, it needs a longer term plan. One simple possibility is do what was
done with all those ldconfig from %post back then: change the %sysusers_()
macros to no-ops in rawhide to let rpm handle it, and only actually bother
updating packages once all relevant versions have the sysusers feature.
+1 to this plan.
4. The sysusers "hook" in rpm needs to be enabled (uncomment
%__systemd_sysusers macro in rpm). It wont do anything at all before 1) and
3) are done though.
6. The user/group dependencies for non-root users need to be turned into
hard requires (initially these are just recommends). I would be suprised if
this doesn't cause some disruption somewhere, although the content that is
not root:root owned is pretty scarce these days.
7. Packages creating or using non-root user/group need to be rebuilt.
7. One day a few years from now, replace
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
with "supply a sysusers file for your needs" :P
In reality, it'll need adjusting long before that and for that, it'll need
FPC recommendations and all.
8. Remove all user/group addition related macro and script fubar from specs
for good. The first commit in rpm source tree is from 1995, it'd be a nice
30 year celebration... but I don't expect it to happen quite that soon.
Maybe in 2035 new people will start look at old specs in horror, "What do
you mean they had to deal with all this user/group stuff manually! For 30
years!"
I've begun from 1) now:
https://src.fedoraproject.org/rpms/systemd/pull-request/109
This is merged now and the package is built. (I guess it's probably in
gating now.)
https://src.fedoraproject.org/rpms/rpm/pull-request/45
After those have been done, people can start experimenting with the feature.
I don't remember seeing an actual Fedora Change for either file-trigger
enablement or current %sysuser_* macros so I'm not sure it's needed here
either?
https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format
Thanks, I've missed that.
Guess it's best to make a Change out of this too then.
- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
Re: Towards enabling rpm sysusers integration
On 6/22/23 19:55, Steve Grubb wrote:
Hello,
On Thursday, June 22, 2023 11:01:28 AM EDT Zbigniew Jędrzejewski-Szmek wrote:
2. systemd provides users and groups that are actually owned by the setup
package. As rpm is now turning non-root file ownership into dependencies,
systemd could end up pulled in where setup is needed (eg early install
stage) which will not end up well. So systemd will need to stop providing
users it does not actually own.
I was hoping we would be make the dependency on setup optional.
It is a fairly heavyweight package (700+ kb) and with lots of
not-that-useful-on-a-typical-modern-installation stuff (mail alias support,
csh profile, /etc/hosts, nfs exports, etc.). Most of this is tiny, but it
clutters /etc, which ideally would be empty, and also /etc/services is 700
kb. setup is currently pulled in by dependencies, but e.g. in the initrd
we should be fine without it. (And the same applies for e.g. minimal
container images without login users or a shell.)
There are several trusted databases there that things like getservbyport
consult. I would think csh stuff could be installed by tcsh.
Maybe the non-essential stuff could be split out into a new
subpackage, with setup only providing /etc/{passwd,group,shadow,gshadow}
with the base set of users and groups, and all other files moved to
setup-clutter.
I think a few more files than that are still needed. But it could use some
pruning.
3. The various %sysuser_()* macros in systemd-rpm-macros need to be
phased
out. As it'll be a long time before the sysusers feature is in all Fedora
versions, it needs a longer term plan. One simple possibility is do what
was done with all those ldconfig from %post back then: change the
%sysusers_() macros to no-ops in rawhide to let rpm handle it, and only
actually bother updating packages once all relevant versions have the
sysusers feature.
+1 to this plan.
4. The sysusers "hook" in rpm needs to be enabled (uncomment
%__systemd_sysusers macro in rpm). It wont do anything at all before 1)
and 3) are done though.
6. The user/group dependencies for non-root users need to be turned into
hard requires (initially these are just recommends). I would be suprised
if this doesn't cause some disruption somewhere, although the content
that is not root:root owned is pretty scarce these days.
7. Packages creating or using non-root user/group need to be rebuilt.
7. One day a few years from now, replace
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
with "supply a sysusers file for your needs"
In reality, it'll need adjusting long before that and for that, it'll
need
FPC recommendations and all.
8. Remove all user/group addition related macro and script fubar from
specs for good. The first commit in rpm source tree is from 1995, it'd
be a nice 30 year celebration... but I don't expect it to happen quite
that soon. Maybe in 2035 new people will start look at old specs in
horror, "What do you mean they had to deal with all this user/group
stuff manually! For 30 years!"
I've begun from 1) now:
https://src.fedoraproject.org/rpms/systemd/pull-request/109
This is merged now and the package is built. (I guess it's probably in
gating now.)
https://src.fedoraproject.org/rpms/rpm/pull-request/45
After those have been done, people can start experimenting with the
feature. I don't remember seeing an actual Fedora Change for either
file-trigger enablement or current %sysuser_* macros so I'm not sure
it's needed here either?
https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format
I would caution against this whole proposal. Not that I'm against it, but
just saying be careful doing it. People often forget about our security
concerns. Currently, shadow-utils has about 400 places which generate audit
events during the managing of system and user accounts. libuser (I saw the
deprecation email) has 55 places where it sends audit events managing
accounts.
There is a 10 year old (or more) standard published here:
https://github.com/linux-audit/audit-documentation/wiki/SPEC-User-Account-Lifecycle-Events
If %pre getent, useradd, and groupadd are being replaced by something, that
something needs to conform to the expected security safeguards that currently
exist. It needs to match the kind of events and the format that currently
exists.
Rpm's sysuser integration simply calls out to the configured helper to
do the heavy lifting. By default that's systemd-sysusers, I have no idea
what audit events if any it generates, but it's entirely possible to
replace that with a script that calls out to useradd and groupadd instead.
The system accounts still need to be accessible by the getpw* family of
functions or there could be a lot of breakage.
Uh, yes? Users and groups do need to be created. We're merely talking
about letting rpm automate the task based on already packaged sysusers.d
files instead of requiring packagers to fill out tedious boilerplate to
handle it.
On
Re: Koji builders cannot build Wine Mono
On 6/25/23 3:06 PM, Kevin Fenzi wrote: Do you have any idea what the bug might be here? All builders are now on 6.3.8-200.fc38. The "mono-sgen" process is crashing on kernel 6.2. Not every time either so it would take some time to debug. I have not narrowed it down further. Koji builders successfully built Wine Mono 8.0.0. Thank you for the quick update, Kevin. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: LibuserDeprecation (System Wide)
On Thu, Jun 22, 2023 at 12:33 PM Aoife Moloney wrote: > The main benefit is to decrease the maintenance and packaging work > on library that does not bring much value while the functionality is > provided by another components. On most (all?) Linux distributions, Puppet relies on libuser in order to manage group membership as an attribute of a group (1), because historically the shadow-utils package could not. There are folks who use Puppet to manage Fedora systems, and pulling the libuser package will break the ability of Puppet to manage group membership on Fedora. Background: libuser provides the ability to intuitively manage local group membership as an attribute of the group, instead of attributes of users. To add a user to a group: lgroupmod -M someuser somegroup To remove a user from a group: lgroupmod -m someuser somegroup For shadow-utils, adding can be achieved with: groupmod -a -U someuser somegroup But groupmod has no ability to remove a user from a group. Historically, before shadow-utils 4.10, the only way to remove a user from a group was to use: usermod -G groupset someuser …where groupset was the set of all supplementary groups for the user but with somegroup removed. This was racy and error-prone. For shadow-utils 4.10 or later, usermod has a new -r option, so it is possible to construct an equivalent: usermod -r -G somegroup someuser While this is a vast improvement, I would argue this option was added to the wrong utility: groupmod should have the ability to remove a user from a group, the same as lgroupmod. It’s also fairly new (RHEL9 still has shadow-utils 4.9, for example). I don’t disagree with the reasons for wanting to drop libuser; I just wish that… * the shadow-utils package could provide the equivalent functionality in a more intuitive way, and… * this change could be pushed to at least Fedora 40, to provide more time for downstream consumers of libuser to move away from it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
bc license correction
Hi, On bc package ( https://www.gnu.org/software/bc/ ), it was corrected the license tag from GPLv2+ (GPL-2.0-or-later) to GPL-3.0-or-later in rawhide Best regards, -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]
On 2023-06-25 14:29, Dominik 'Rathann' Mierzejewski wrote: The FOSS licenses give you the right to share the SRPMS, sans the Red Hat trademarks. The GPL, specifically, might guarantee that right, but not all of the distribution is under the terms of the GPL. I don't have a license count for RHEL components, but Fedora looks like it's made up of about 30% GPL components, with the majority being MIT, BSD, or Apache license, none of which prohibit Red Hat from imposing restrictions on their redistribution. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]
On Sunday, 25 June 2023 at 02:44, Kevin Kofler via devel wrote: > Neal Gompa wrote: > > > On Fri, Jun 23, 2023 at 6:09 PM Kevin Kofler via devel wrote: > >> > >> Josh Boyer wrote: > >> > Agree with Matthew fully here. We've been working rather hard > >> > internally to adjust the development process for RHEL to be more > >> > collaborative and open than it ever has before. > >> > >> The *development process* is more open, but the production > >> releases, which is the only thing end users are interested in, are > >> less open! > > > > Actually, this is not true either. Since December 2020, Red Hat > > Enterprise Linux has added a number of avenues in which you can > > freely get it: > > > > 1. Individuals (16 entitlements, prod use permitted): > > https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux > > > > 2. Teams (mucho entitlements for companies, no prod): > > https://developers.redhat.com/articles/2022/05/10/access-rhel-developer-teams-subscription > > > > 3. OSS projects running their own infra (mucho entitlements, prod > > use permitted): > > https://www.redhat.com/en/blog/extending-no-cost-red-hat-enterprise-linux-open-source-organizations > > That is not "open", it is just free as in beer, for a restricted > subset of people. If you are not (explicitly! Not just "try and hope > we do not terminate your subscription at our whim") entitled to share > the SRPMs, it is NOT open. The FOSS licenses give you the right to share the SRPMS, sans the Red Hat trademarks. Red Hat's terms of use for their subscriptions state explicitly (in several places), that: [...] This Agreement establishes the rights and obligations associated with Red Hat Products and is not intended to limit your rights to software code under the terms of an open source license. [...] So, unless you have some specific and verifiable examples, please stop spreading FUD. 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Towards enabling rpm sysusers integration
* Zbigniew Jędrzejewski-Szmek: > On Thu, Jun 22, 2023 at 10:25:10AM -0500, Chris Adams wrote: >> Once upon a time, Zbigniew Jędrzejewski-Szmek said: >> > I was hoping we would be make the dependency on setup optional. >> > It is a fairly heavyweight package (700+ kb) and with lots of >> > not-that-useful-on-a-typical-modern-installation stuff (mail alias support, >> > csh profile, /etc/hosts, nfs exports, etc.). Most of this is tiny, but it >> > clutters /etc, which ideally would be empty, and also /etc/services is 700 >> > kb. >> >> /etc/services and /etc/protocols are AFAIK mandatory if you want to have >> network services (either client or server). I don't think there's >> anything else providing that information. > > getservbyname would use /etc/services, but I'm not sure how widely it > is used. The getaddrinfo function uses it as well, to fill in the port number. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Koji builders cannot build Wine Mono
On Sat, Jun 24, 2023 at 01:33:31PM -0700, Kevin Fenzi wrote: > We typically do update/reboot cycles every month or two, there's no hard > and fast schedule. If there's a reason we can do the builders sooner. > > I can see about rebooting them next week (or perhaps this weekend, but > not sure if I will have time to do so). > > Do you have any idea what the bug might be here? All builders are now on 6.3.8-200.fc38. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Unretire lua-ldap
Hello, According to https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/ I'd like to announce that I'm going to unretire the package "lua-ldap". I didn't find a concrete reason why it was removed, it looks like it was retired because it was orphaned for too long. Specifically, I'd like to use it to re-enable LDAP support in the XMPP server "prosody" with its "mod_auth_ldap" plugin. I'm planning to update/maintain it also in EPEL. Upstream moved to here: https://github.com/lualdap/lualdap/commits/master and it looks like they are medium active, last commit this March 2023. Re-Review: https://bugzilla.redhat.com/show_bug.cgi?id=2217273 Best regards, Christian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
Fedora rawhide compose report: 20230625.n.0 changes
OLD: Fedora-Rawhide-20230624.n.0 NEW: Fedora-Rawhide-20230625.n.0 = SUMMARY = Added images:10 Dropped images: 1 Added packages: 1 Dropped packages:1 Upgraded packages: 43 Downgraded packages: 0 Size of added packages: 27.65 KiB Size of dropped packages:13.35 KiB Size of upgraded packages: 240.16 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 608.54 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Everything boot ppc64le Path: Everything/ppc64le/iso/Fedora-Everything-netinst-ppc64le-Rawhide-20230625.n.0.iso Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20230625.n.0.ppc64le.tar.xz Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20230625.n.0.ppc64le.qcow2 Image: Kinoite dvd-ostree x86_64 Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20230625.n.0.iso Image: Server dvd ppc64le Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20230625.n.0.iso Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20230625.n.0.ppc64le.raw.xz Image: Server_KVM qcow2 ppc64le Path: Server/ppc64le/images/Fedora-Server-KVM-Rawhide-20230625.n.0.ppc64le.qcow2 Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20230625.n.0.iso Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-Rawhide-20230625.n.0.ppc64le.tar.xz Image: Kinoite dvd-ostree aarch64 Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20230625.n.0.iso = DROPPED IMAGES = Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20230624.n.0.iso = ADDED PACKAGES = Package: rust-expect-test-1.4.1-1.fc39 Summary: Minimalistic snapshot testing library RPMs:rust-expect-test+default-devel rust-expect-test-devel Size:27.65 KiB = DROPPED PACKAGES = Package: golang-github-vmihailenco-tagparser-0.1.2-6.fc38 Summary: Opinionated Golang tag parser RPMs:golang-github-vmihailenco-tagparser-devel Size:13.35 KiB = UPGRADED PACKAGES = Package: PyDrive2-1.16.0-1.fc39 Old package: PyDrive2-1.15.4-1.fc39 Summary: Google Drive API Python wrapper library, maintained fork of PyDrive RPMs: python3-PyDrive2 Size: 127.75 KiB Size change: 557 B Changelog: * Sat Jun 24 2023 Mikel Olasagasti Uranga - 1.16.0-1 - Update to 1.16.0 - Closes rhbz#2217138 Package: apache-commons-text-1.10.0-1.fc39 Old package: apache-commons-text-1.9-5.fc39 Summary: Apache Commons Text is a library focused on algorithms working on strings RPMs: apache-commons-text apache-commons-text-javadoc Size: 605.19 KiB Size change: -120.69 KiB Changelog: * Sat Jun 24 2023 Didik Supriadi - 1.10.0-1 - Update to version 1.10.0 - Disable tests Package: bluez-5.66-6.fc39 Old package: bluez-5.66-5.fc38 Summary: Bluetooth utilities RPMs: bluez bluez-cups bluez-deprecated bluez-hid2hci bluez-libs bluez-libs-devel bluez-mesh bluez-obexd Size: 9.61 MiB Size change: 5.34 KiB Changelog: * Sun Jun 25 2023 Bastien Nocera - 5.66-6 - Add patch that fixes some devices not being discoverable in GNOME's Bluetooth Settings Package: distrobox-1.5.0.2-1.fc39 Old package: distrobox-1.5.0.1-1.fc39 Summary: Another tool for containerized command line environments on Linux RPMs: distrobox Size: 220.28 KiB Size change: 488 B Changelog: * Sat Jun 24 2023 Alessio - 1.5.0.2-1 - Update to 1.5.0.2 Package: gh-2.31.0-1.fc39 Old package: gh-2.30.0-2.fc39 Summary: GitHub's official command line tool RPMs: gh golang-github-cli-2-devel Size: 33.52 MiB Size change: 706.44 KiB Changelog: * Sat Jun 24 2023 Mikel Olasagasti Uranga - 2.31.0-1 - Update to 2.31.0 - Closes rhbz#2216708 Package: golang-github-lithammer-fuzzysearch-1.1.8-1.fc39 Old package: golang-github-lithammer-fuzzysearch-1.1.1-6.fc38 Summary: Tiny and fast fuzzy search in Go RPMs: golang-github-lithammer-fuzzysearch-devel Size: 17.16 KiB Size change: 947 B Changelog: * Sat Jun 24 2023 Mikel Olasagasti Uranga - 1.1.8-1 - Update to 1.1.8 - Closes rhbz#1963479 Package: golang-github-otiai10-mint-1.6.1-1.fc39 Old package: golang-github-otiai10-mint-1.5.1-1.fc39 Summary: Minimum assertion for Golang testing framework RPMs: golang-github-otiai10-mint-devel Size: 24.40 KiB Size change: 2.53 KiB Changelog: * Sat Jun 24 2023 Mikel Olasagasti Uranga - 1.6.1-1 - Update to 1.6.1 - Closes rhbz#2217159 Package: golang-github-quic-qtls-go1-20-0.2.2-1.fc39 Old package: golang-github-quic-qtls-go1-20-0.2.0-1.fc39 Summary: Go standard library TLS 1.3 implementation, modified for QUIC. RPMs: gol
Re: Something for a python maintainer for nihtest
On 25-06-2023 11:55, Sandro wrote: Hi, libzip have switch from old perl test suite to a new python based one using nihtest https://github.com/nih-at/nihtest https://pypi.org/project/nihtest/ As I don't want to dig in python packaging and as there is probably enough python guys here is there is one king enough to look at this one ? Sure. I'll take a look and submit a review. Would you be able to do the review? Then I ping you when it's ready. I packaged nihtest and submitted it for review: https://bugzilla.redhat.com/show_bug.cgi?id=2217257 -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Something for a python maintainer for nihtest
On 25-06-2023 09:04, Remi Collet wrote: Hi, libzip have switch from old perl test suite to a new python based one using nihtest https://github.com/nih-at/nihtest https://pypi.org/project/nihtest/ As I don't want to dig in python packaging and as there is probably enough python guys here is there is one king enough to look at this one ? Sure. I'll take a look and submit a review. Would you be able to do the review? Then I ping you when it's ready. libzip may be updated to 1.10.0 without this, but without its test suite, which seems a bad idea Thanks Remi P.S. of course I may try to help, after initial packaging to update to newer version when needed Thanks for the offer. Would you like to be co-maintainer once the package lands in Fedora? Cheers, -- Sandro FAS: gui1ty IRC: Penguinpee Elsewhere: [Pp]enguinpee ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
Something for a python maintainer for nihtest
Hi, libzip have switch from old perl test suite to a new python based one using nihtest https://github.com/nih-at/nihtest https://pypi.org/project/nihtest/ As I don't want to dig in python packaging and as there is probably enough python guys here is there is one king enough to look at this one ? libzip may be updated to 1.10.0 without this, but without its test suite, which seems a bad idea Thanks Remi P.S. of course I may try to help, after initial packaging to update to newer version when needed ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
