Orphaning rubygem-echoe
by Athos Ribeiro
Hi,
I am orphaning rubygem-echoe.
The upstream project is dead, some of its dependencies upstreams are
dead and it's past time to let it go.
Regards,
Athos
4 years, 1 month
Re: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)
by virgo
> On Tue, May 12, 2020 at 12:47:51PM +0000, virgo wrote:
> ...
>
> > I recommend you to ask the question about v2 support on Fedora
>
> Bugzilla for=
>
> > the
> >
> > libcgroup package
> > <https://bugzilla.redhat.com/buglist.cgi?classification=3DFedora&compo...
> > =3Dlibcgroup&product=3DFedora&query_format=3Dadvanced>.
>
> Prior to the top post, I went through the Bugzilla tickets, with these
> parameters:
>
> * component=libcgroup
> * order=changeddate DESC
> * product=Fedora
> * query_format=advanced
>
> and the hits dating back to 2015[fn:1] were just a dozen, none making
> mention
> of v2. So, I am not sure whether opening feature requests would help.
>
> Fedora uses systemd that enforces cgroup v2. If libcgroup package is not
> compatible with cgroup v2, then libcgroup package is not compatible with
> Fedora and this is a bug and should be reported to the Fedora's Bugzilla.
>
> ...
>
> By the way, what would you and (and others) recommend as a
>
> replacement for
>
> libcgroup-tools?[fn:2]
>
> No idea. I don't use cgroups for anything on purpose. As far as I know,
> cgroups membership in Fedora is defined by systemd's logind. Whether it
> suits
> your needs, I have no idea. I also think it's possible to manage the
> membership manually by editing files in cgroup2 pseudo file system.
Duly noted, thank you for your time.
>
> -- Petr
4 years, 1 month
Summary/Minutes from today's FESCo Meeting (2020-05-11)
by Igor Raits
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=====================================
#fedora-meeting-1: FESCO (2020-05-11)
=====================================
Meeting started by ignatenkobrain at 15:03:42 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-05-11/fesco.2020-...
.
Meeting summary
- ---------------
* init process (ignatenkobrain, 15:04:07)
* #2372 F33 Self-contained Change: Network Time Security
(ignatenkobrain, 15:05:24)
* ACTION: ignatenkobrain to contact change owners and clarify
anaconda
part of the change. (ignatenkobrain, 15:10:14)
* AGREED: APPROVED (+9, ±0, -0) (ignatenkobrain, 15:10:17)
* #2381 F33 System-Wide Change: systemd-resolved (ignatenkobrain,
15:10:20)
* AGREED: APPROVED (+4, ±5, -0) (ignatenkobrain, 15:18:40)
* AGREED: APPROVED (+5, ±4, -0) (ignatenkobrain, 15:20:51)
* AGREED: APPROVED (+6, ±3, -0) (ignatenkobrain, 15:21:23)
* Next week's chair (ignatenkobrain, 15:21:27)
* ACTION: sgallagh will chair next meeting (ignatenkobrain,
15:22:24)
* Open Floor (ignatenkobrain, 15:22:31)
* ACTION: sgallagh to open a ticket to discuss abstention policy
(sgallagh, 15:26:19)
* LINK: https://hackmd.io/Eqsf5wFoQRGYhAVwSKJvIA is our running
planning/tasks (but might be too detailed) (nirik, 15:34:15)
* LINK:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-2c6c85202d
this is the update, which has upstream fixes (bookwar, 15:48:58)
* LINK:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-073c252157
(nirik, 15:53:24)
* ACTION: bookwar to discuss with Fedora QA how to cover runtime
testing better (ignatenkobrain, 16:01:06)
Meeting ended at 16:05:41 UTC.
Action Items
- ------------
* ignatenkobrain to contact change owners and clarify anaconda part of
the change.
* sgallagh will chair next meeting
* sgallagh to open a ticket to discuss abstention policy
* bookwar to discuss with Fedora QA how to cover runtime testing better
Action Items, by person
- -----------------------
* bookwar
* bookwar to discuss with Fedora QA how to cover runtime testing
better
* ignatenkobrain
* ignatenkobrain to contact change owners and clarify anaconda part
of
the change.
* sgallagh
* sgallagh will chair next meeting
* sgallagh to open a ticket to discuss abstention policy
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* ignatenkobrain (71)
* bookwar (43)
* mhroncok (40)
* zbyszek (37)
* sgallagh (36)
* nirik (33)
* dcantrell (25)
* zodbot (22)
* decathorpe (7)
* bcotton (3)
* contyk (3)
* smooge (1)
* bookwar1 (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
- --
Igor Raits <ignatenkobrain(a)fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl65e3MACgkQEV1auJxc
Hh4B+w/9FHtHZPycgzgyOeIzATes2zDuUxabvDTMyLFSl2Zs+q+XNYOmX01uohic
+Pk2//vnQHVXkg1ptA5/gtiNnt9H4/Fjes4ScgRhysVjb+75dIB8wNmxh8URLxkF
AAVY3wQm1/q3EQIpuOqVMFG8LfkjJ1idREu+7pfzvxxuAdEp3WnflC9B/zw79dYx
iN1wJ1pjHO9e7vtGoKEBKeirH34isQg4fIJsInIUpc8yvwcGN2O2jSJwxqQv4Hwf
L+EP6CV+tiEivxXXEXg65d6/CGQlHsAz2o1ctSex1w2c1rx3YlUAZRpZnYxsOJ9e
JAf0LodtDv9WjBWzlxRHlH7tccoRcuE914KY5g6vfQLdaUeDySHp7O3sDSfHKucr
d+LoJgbtywp0K1cuoM51fhDW3cyyYSnnMEZP2EtHtjuPQDePf+NrXp/jfyMzHRwo
dn7s+5ADkljSnlxv8oWm+8415BK9jchTglHL07DpYeC5qjdioGU/vmnAfocw/GPy
k0nMTuH0E3u5yu/ZDG6qXcqQ2Jm3Qoj4qRDSZ2qCn9zzPOzwimKZyZ0DR1q2OlDp
CZpVinKCc5a0k0R419gZydXp+j+qHbm5IFMqmMwB3tFV6l/6+TCuowTznXzohKHx
H3Rl2HNXcHrMtrgBhS/VuZEPfFLaan/0DBeC2wQhK10a2d9GZKA=
=iux/
-----END PGP SIGNATURE-----
4 years, 1 month
Re: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)
by virgo
> > On 12/05/2020 15:06, virgo wrote:
> >
> > ...
> >
> > Let’s say I want to compile `pandoc` with modifications of my own and
> >
> > many non-
> >
> > default compiler options. At the same time, on the same machine, I still
> > want
> > to do other stuff. `cgexec` et al. helped a lot to cap the memory and CPU
> > usage of tasks like that, without needing container and virtual machines
> > setups. Nowadays, I am into `systemd-nspawn` because it requires minimal
> > configuration from my end. It is still a hammer deployed to kill an ant.
> > In pages like>
> >
> > `systemd.resource-control(5)`, one can read:
> > See the New Control Group Interfaces[1] for an introduction on how
> > to
> >
> > **make use of resource control APIs from programs.**
> >
> > Great! But I do not know how to make programs consuming those APIs. The
> > tools
> > talked about in this thread helped a lot and I am searching for
> > replacement
> > that would fit with my low-proficiency in Devops.
4 years, 1 month
Re: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)
by virgo
> On 12/05/2020 14:13, Petr Pisar wrote:
> ...
>
> On Tue, May 12, 2020 at 12:47:51PM +0000, virgo wrote:
> >> I recommend you to ask the question about v2 support on Fedora Bugzilla
> >> for=
> >>
> >> the
> >>
> >> libcgroup package
>
> <https://bugzilla.redhat.com/buglist.cgi?classification=3DFedora&compo...
>
> >> =3Dlibcgroup&product=3DFedora&query_format=3Dadvanced>.
> >
> > Prior to the top post, I went through the Bugzilla tickets, with these
> > parameters:
> >
> > * component=libcgroup
> > * order=changeddate DESC
> > * product=Fedora
> > * query_format=advanced
> >
> > and the hits dating back to 2015[fn:1] were just a dozen, none making
> > mention
> > of v2. So, I am not sure whether opening feature requests would help.
>
> Fedora uses systemd that enforces cgroup v2. If libcgroup package is not
> compatible with cgroup v2, then libcgroup package is not compatible with
> Fedora and this is a bug and should be reported to the Fedora's Bugzilla.
>
> That's not really true. Fedora now defaults to v2 but you can still
> choose to boot to v1 instead and systemd still supports both.
Yes, that is well documented. I am not desperate to the point of fiddling with
kernel boot options, though.
>
> > By the way, what would you and (and others) recommend as a
>
> replacement for
>
> > libcgroup-tools?[fn:2]
>
> No idea. I don't use cgroups for anything on purpose. As far as I know,
> cgroups membership in Fedora is defined by systemd's logind. Whether it
> suits
> your needs, I have no idea. I also think it's possible to manage the
> membership manually by editing files in cgroup2 pseudo file system.
>
> Yes as I understand it you're not supposed to fiddle with cgroups
> manually, you're supposed to use systemd-run or something and let
> systemd do the necessary.
>
> It would probably help if the original user described what his goal
> was rather than the low level details of how he achieved that with
> cgroups v1.
Let’s say I want to compile `pandoc` with modifications of my own and many non-
default compiler options. At the same time, on the same machine, I still want
to do other stuff. `cgexec` et al. helped a lot to cap the memory and CPU usage
of tasks like that, without needing container and virtual machines setups.
Nowadays, I am into `systemd-nspawn` because it requires minimal configuration
from my end. It is still a hammer deployed to kill an ant. In pages like
`systemd.resource-control(5)`, one can read:
See the New Control Group Interfaces[1] for an introduction on how to
**make use of resource control APIs from programs.**
Great! But I do not know how to make programs consuming those APIs. The tools
talked about in this thread helped a lot and I am searching for replacement
that would fit with my low-proficiency in Devops.
That said, I read somewhere about user units, I am under the impression those
would help. Somewhere on my computer, there already many tools to accomplish
all of I need and beyond, the issue is that I have not yet met documentation
dumbed down enough to make me see the light.
>
> Tom
>
> --
> Tom Hughes (tom(a)compton.nu)
> http://compton.nu/
4 years, 1 month
Re: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)
by virgo
> On Di, 12.05.20 14:21, Fedora Development ML
> (devel(a)lists.fedoraproject.org) wrote:
>
> ...
>
> cgroupsv2 is built around a single-writer scheme. That means any
> section of the tree shall only have a singler writer, i.e. one
> subsystem 'owning' it. On systemd systems the root of the tree is
> owned by systemd, it's the single writer of it. Other software may
> read from the tree but not make changes to it.
>
> You can ask systemd for a delegated subtree of the main cgroup tree
> however. You can do this via Delegate=yes in a service file, or by
> doing "systemd-run --scope -p Delegate=yes -t /bin/bash" on the
> command line. If you do that you get your own subtree in which you can
> do whatever you want, and systemd will not step on your toes.
>
> Making changes to the top-level cgroup tree, i.e. stepping into
> systemd's explicitly owned territory means voiding your warranty
> though.
>
> This design choice is made by the cgroupsv2 subsystem in the kernel
> btw, it's not something systemd came up with.
>
> It's documented here in all detail:
> https://systemd.io/CGROUP_DELEGATION
>
> hence, if libcgroups wants to do cgroup stuff it really needs to ask
> systemd for delegation first (or be invoked inside a service where
> something else asked for it). If it doesn't then it's simply broken.
Thank you for the explanation. The page you linked is more than clear upfront:
Intended audience: hackers working on userspace subsystems that require
direct cgroup access, such as container managers and similar.
I will keep that in mind.
>
> In general, I am not sure why one would even want the cgroup tools on
> a systemd system though.
I just wrote something along those lines to Tom, the onus is on me to catch-up
and leverage what is available.
> We should provide most of it natively anyway,
> though possibly in a different manner.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
4 years, 1 month