You are not logged in.
Pages: 1
Version 4.0.12 of LXCFS has been out since 2022-Feb, but no update past the 4.0.7-1 release is available in Debian :
https://packages.debian.org/bullseye/allpackages
https://packages.debian.org/bullseye-up … llpackages
The latest stable release of LXCFS, from the detailed changelog, indicates meminfo and swaps are now cgroupv2 aware. That has value to me as some software I use relies on meminfo to tune itself to available memory :
https://discuss.linuxcontainers.org/t/l … ased/13287
I found the Debian work-needing and prospective packages page, but no mention of updates for LXCFS appear forthcoming :
https://www.debian.org/devel/wnpp/
Is it accurate to say my options are "doing without" or "building my own"?
As a transplant from the RPM-world my question is a bit of an ecosystem/protocol question in the DEB-world. Can someone educate me as to a proper series of events that should take place to advance a Debian package update? I'm confident I can roll my own package (having done so in the RPM-world as needed), but that only helps me.
Thanks,
--K
Offline
By pkginfo.devuan.org/cgi-bin/policy-query.html?q=lxcfs it appears the coming upstream version is 5.0.2 (or later). That's for the coming release, daedalus (currently in testing) while the current stable and prior releases, chimaera, beowulf and ascii remain as they are.
You might also look it up at tracker.debian.org/pkg/lxcfs for a bit more detail of it's maintenance by Debian.
As for building it yourself, you possibly find some joy with https://backports.debian.org/
Offline
Thanks, RR
For my immediate needs I did this :
apt-get install devscripts
apt-get install quilt
mkdir /tmp/lxcfs
chown _apt:root /tmp/lxcfs
cd /tmp/lxcfs/
apt-get source lxcfs
apt-get build-dep lxcfs
wget https://linuxcontainers.org/downloads/lxcfs/lxcfs-4.0.12.tar.gz
cd lxcfs-4.0.7
uupdate -v 4.0.12-1 ../lxcfs-4.0.12.tar.gz
cd ../lxcfs-4.0.12-1
vi debian/rules
override_dh_installinit:
# mv debian/lxcfs/etc/rc.d/init.d/lxcfs debian/lxcfs.init
# rm -rf debian/lxcfs/etc/rc.d
dh_installinit -p lxcfs --no-stop-on-upgradeoverride_dh_installsystemd:
# dh_installsystemd -p lxcfs --no-stop-on-upgrade lxcfs.service
dpkg-buildpackage -us -uc -b
And this produced an "lxcfs_4.0.12-1-0devuan1_amd64.deb" package that I installed and confirmed the /proc/meminfo fix works. Nice.
So that is great ... for me. But I'm still at a loss, regarding Debian/Devuan culture (I earned my grey beard in the RPM world), as to how one effectively approaches/advocates/assists toward greater symmetry between stable vendor releases and distribution updates without stepping on toes within the Debian ecosystem.
Is there a Welcome-to-Debian blog somewhere tailored for old transplants?
--K
Offline
how one effectively approaches/advocates/assists toward greater symmetry between stable vendor releases and distribution updates without stepping on toes within the Debian ecosystem.
File a WNPP bug report with Debian to request that the newer version of lxcfs be added to the stable-backports repository.
The stable release is so named because the version numbers do not change.
Last edited by Head_on_a_Stick (2022-11-14 06:17:14)
Brianna Ghey — Rest In Power
Offline
Thank you, HoaS
I started looking into backports following RR's suggestion, which lead me to :
https://backports.debian.org/Instructions/
As a matter of Backports policy, packages in the stable-backports suite are taken from Debian testing ...
And following the tracker link RR provided, no releases in the vendor 4.x.x branch following 4.0.7 have been added to testing :
https://tracker.debian.org/pkg/lxcfs
It looks like immediately following the 4.0.7 release, the target was moved to 5.0.0 and then to 5.0.2.
If I understand policy correctly, I would be asking for a backport of 5.0.2 from testing to be made available for Bullseye in Backports. If I were the package maintainer receiving that request, my response would likely be something along the lines of "Why are you making more work for me? Eyes on Bookworm.", because experience suggests backporting a major 5.x.x version to a system built at the time 4.x.x was stable frequently gets hairy. If that kind of work were the norm, I would expect Backports to be a bit of an unstable mess.
My perception was that Debian Updates followed software vendor stable releases :
https://linuxcontainers.org/lxcfs/downloads/
lxcfs-4.0.7 => lxcfs-4.0.8 => lxcfs-4.0.9 => lxcfs-4.0.10 => lxcfs-4.0.11 => lxcfs-4.0.12
But, that seems not to be the case.
When you say "The stable release is so named because the version numbers do not change.", does that mean Updates are more like :
lxcfs-4.0.7-1 + patches => lxcfs-4.0.7-2 + patches => lxcfs-4.0.7-3 +patches => lxcfs-4.0.7-4
In which case patches are generally limited to bug squashing and mitigating security concerns?
If I were to produce a patch against lxcfs-4.0.7-1 that exclusively corrected the lxcfs presentation of /proc/meminfo ... would that be welcomed within the Debian ecosystem and worthy of an lxcfs-4.0.7-2 package being released?
Perhaps what I am looking for is a grey area between Backports and Updates where the software vendor has addressed minor issues within a major release and deemed a minor release is warranted. Do these minor releases get picked up in the Debian update cycle? Or do folks just wait for the next Debian stable release?
Thank you for your time as I build an understanding of the way things work,
--K
Last edited by kaiyel (2022-11-14 17:59:53)
Offline
Do not use Debian repos directly. All Debian packages including backports that won't break Devuan are pulled in by Amprolla to Devuan. You'll have to sort which branch is current . . . that magic is way beyond me.
You will also find https://pkginfo.devuan.org/cgi-bin/policy-query.html a useful tool to search for available packages and https://pkgmaster.devuan.org/bannedpackages.txt to know what shouldn't be installed on Devuan . . .
Offline
If I understand policy correctly, I would be asking for a backport of 5.0.2 from testing to be made available for Bullseye in Backports. If I were the package maintainer receiving that request, my response would likely be something along the lines of "Why are you making more work for me? Eyes on Bookworm.", because experience suggests backporting a major 5.x.x version to a system built at the time 4.x.x was stable frequently gets hairy. If that kind of work were the norm, I would expect Backports to be a bit of an unstable mess.
The lxcfs package was backported for the Debian stretch release[1] so it looks possible, at least.
You could even try it yourself:
https://wiki.debian.org/SimpleBackportCreation
^ That would ensure a ~bpo version suffix, which eases transitions between releases.
When you say "The stable release is so named because the version numbers do not change.", does that mean Updates are more like :
lxcfs-4.0.7-1 + patches => lxcfs-4.0.7-2 + patches => lxcfs-4.0.7-3 +patches => lxcfs-4.0.7-4
In which case patches are generally limited to bug squashing and mitigating security concerns?
Yes, that's right.
If I were to produce a patch against lxcfs-4.0.7-1 that exclusively corrected the lxcfs presentation of /proc/meminfo ... would that be welcomed within the Debian ecosystem and worthy of an lxcfs-4.0.7-2 package being released?
I would hope so. I think you should submit the patch. See https://www.debian.org/Bugs/Reporting for the preferred method.
Perhaps what I am looking for is a grey area between Backports and Updates where the software vendor has addressed minor issues within a major release and deemed a minor release is warranted. Do these minor releases get picked up in the Debian update cycle? Or do folks just wait for the next Debian stable release?
There are regular point releases that provides security and other bug fixes without major package version increments. There are some notable exceptions, however: firefox-esr & chromium will both be kept up to date with the respective upstream versions (although chromium can lag a little).
Brianna Ghey — Rest In Power
Offline
Thanks again, HoaS
I'll tag this thread solved and continue with the homework due-diligence.
Your time is much appreciated
--K
Offline
Sorry, Golinux, I overlooked your post above HoaS's. I appreciate the warning <thumbs-up>
--K
Offline
Pages: 1