Re: [gentoo-user] Portage package removals due to python-2.7
On Mon, Aug 24, 2020 at 9:48 AM Michael wrote: > > On Monday, 24 August 2020 13:02:56 BST Rich Freeman wrote: > I may give virt-manager a spin, because the users will require a GUI manager > to launch VMs, but then if I start emerging packages at large I could emerge > VBox from source instead. On my personal machine I just run QEMU, but I find > plugin/unplugin USBs and other hardware via the QEMU monitor console to be > rather clunky. I've stayed with QEMU over the years as a more minimalist > solution. I preferred it as a more direct and simple solution to multiple > virt layers, APIs and what not. Yeah, it is a little more complex. Also, it is linux-only. However, it is libvirt under the hood which means a lot of other stuff is compatible with it. If you're just running traditional images in a directory somewhere it is pretty easy to set up. One advantage of VirtualBox is that you can run the same VM on Windows as well. > > I'll also note that 95% of the time when you're using a VM running > > Linux you're probably better-off using a container. > > I use QEMU to run full virtual OSs - MSWindows, Android, other Linux distros. > A container wouldn't do this You can run other linux distros in a container, minus the kernel. Many of my containers are non-Gentoo on a Gentoo host. Since kernel compatibility is very robust it generally isn't an issue to not run one tailored to the distro. Containers are popular enough that most distros have some sort of container root tarball available. -- Rich
Re: [gentoo-user] Portage package removals due to python-2.7
Thank you all for your responses. On Monday, 24 August 2020 13:02:56 BST Rich Freeman wrote: > On Mon, Aug 24, 2020 at 6:57 AM Neil Bothwick wrote: > > On Mon, 24 Aug 2020 11:50:42 +0100, Michael wrote: > > > I have a number of VBox VM systems, some with active software licenses > > > running on them and the VBox-bin is a low-maintenance and convenient > > > way to run them. I'd prefer to avoid emerging a non-bin VBox. Is there > > > some way I could keep older packages running in Gentoo, until more up > > > to date versions appear again in the tree (if ever)? > > > > Copy the ebuild to a local overlay and add app-emulation/virtualbox-bin > > to /etc/portage/profile/package.unmask. > > You would probably also want to grab a copy of all the distfiles and > keep them safe, because they'll disappear from the mirrors. > > Note that this is really only a stopgap. As packages that require > python 2.7 are removed from the repo, we may see more and more core > python packages removed as well over a longer timeframe. It will > probably become increasingly less practical to continue to use python > 2.7 as a result. > > You could in theory move all of this stuff into an overlay. As such > they will probably work "forever," but you will end up shouldering all > the work around maintaining security, compatibility, etc. I'm pressed for time presently and adding to my list of maintenance liabilities is the very thing I'm trying to avoid. ;-) > I would encourage using this as an opportunity to transition to something > else. Yes, good point. My workaround has been to look for MSWindows versions of any needed/desired applications and run these in a VM, or keep a couple of older binary distros in QEMU images. The VBox-bin was my preferred option for production PCs, because it required a short emerge time (VBox-bin plus VBox- modules) and little disk space taken up. > On a side note, I've used VirtualBox in the past, and it is pretty > simple to use. However, you might find KMS a much better solution > all-around. Virt-manager is a package that wraps a nice GUI around > it, and it isn't too different from Virtualbox. It is a little more > complex in that it is more layered - you could stick your VMs on Ceph > block storage or iSCSI or whatever, or build your VMs with > virt-manager and run them from virsh from the command line. One key > feature is that the kernel layer of it is built into the upstream > kernel and it is 100% FOSS, so you have a VERY robust level of > support. The complexity comes from the fact that > kernel/userspace/UI/etc is all separated into different packages, but > emerge virt-manager should give you everything (you might need to > enable KMS in your kernel as well, and maybe set up networking). I may give virt-manager a spin, because the users will require a GUI manager to launch VMs, but then if I start emerging packages at large I could emerge VBox from source instead. On my personal machine I just run QEMU, but I find plugin/unplugin USBs and other hardware via the QEMU monitor console to be rather clunky. I've stayed with QEMU over the years as a more minimalist solution. I preferred it as a more direct and simple solution to multiple virt layers, APIs and what not. > I'll also note that 95% of the time when you're using a VM running > Linux you're probably better-off using a container. I use QEMU to run full virtual OSs - MSWindows, Android, other Linux distros. A container wouldn't do this - but I have been thinking of deploying container(s) to sandbox/isolate specific desktop applications like e.g. Skype. It's just that I haven't yet invested the time to learn and try LXC/LXD/ namespaces and a plethora of management apps and frameworks for them. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Portage package removals due to python-2.7
On Mon, 24 Aug 2020 12:24:26 +0100, Michael wrote: > > > I have a number of VBox VM systems, some with active software > > > licenses running on them and the VBox-bin is a low-maintenance and > > > convenient way to run them. I'd prefer to avoid emerging a non-bin > > > VBox. Is there some way I could keep older packages running in > > > Gentoo, until more up to date versions appear again in the tree (if > > > ever)? > > > > Copy the ebuild to a local overlay and add > > app-emulation/virtualbox-bin to /etc/portage/profile/package.unmask. > > Thanks Neil, will this keep all requisite build and run time > dependencies, or will they have to be added to package.unmask too? I thought the same immediately after hitting send. You'll have to do the same for any deps, although for now it's only VBox itself that is at risk. -- Neil Bothwick ** I'm not going to get married again ** ** I'll just find a woman I don't like and give her a house ** pgpn2j12Nc6RI.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Portage package removals due to python-2.7
On Mon, Aug 24, 2020 at 6:57 AM Neil Bothwick wrote: > > On Mon, 24 Aug 2020 11:50:42 +0100, Michael wrote: > > > !!! The following installed packages are masked: > > - app-emulation/virtualbox-bin-5.2.40.137108::gentoo (masked by: > > package.mask) /usr/portage/profiles/package.mask: > > # Michał Górny (2020-08-22) > > # These packages (or package versions) still require Python 2.7. > > # They are either dead upstream, their Python 3 porting efforts are > > # not progressing or their maintainers are simply unresponsive. > > # Please do not remove any packages from this list unless you actually > > # port it to Python 3. > > # Removal in 30 days. Tracker bug #694800. > > > > For more information, see the MASKED PACKAGES section in the emerge > > man page or refer to the Gentoo Handbook. > > = > > > > I have a number of VBox VM systems, some with active software licenses > > running on them and the VBox-bin is a low-maintenance and convenient > > way to run them. I'd prefer to avoid emerging a non-bin VBox. Is there > > some way I could keep older packages running in Gentoo, until more up > > to date versions appear again in the tree (if ever)? > > Copy the ebuild to a local overlay and add app-emulation/virtualbox-bin > to /etc/portage/profile/package.unmask. You would probably also want to grab a copy of all the distfiles and keep them safe, because they'll disappear from the mirrors. Note that this is really only a stopgap. As packages that require python 2.7 are removed from the repo, we may see more and more core python packages removed as well over a longer timeframe. It will probably become increasingly less practical to continue to use python 2.7 as a result. You could in theory move all of this stuff into an overlay. As such they will probably work "forever," but you will end up shouldering all the work around maintaining security, compatibility, etc. I would encourage using this as an opportunity to transition to something else. On a side note, I've used VirtualBox in the past, and it is pretty simple to use. However, you might find KMS a much better solution all-around. Virt-manager is a package that wraps a nice GUI around it, and it isn't too different from Virtualbox. It is a little more complex in that it is more layered - you could stick your VMs on Ceph block storage or iSCSI or whatever, or build your VMs with virt-manager and run them from virsh from the command line. One key feature is that the kernel layer of it is built into the upstream kernel and it is 100% FOSS, so you have a VERY robust level of support. The complexity comes from the fact that kernel/userspace/UI/etc is all separated into different packages, but emerge virt-manager should give you everything (you might need to enable KMS in your kernel as well, and maybe set up networking). I'll also note that 95% of the time when you're using a VM running Linux you're probably better-off using a container. Also, note that sometimes packages that get masked may still end up getting migrated. So, you should think about migration once the mask appears but you have 30 days, and if you want to try to proxy maintain the package you could do so, or perhaps another gentoo dev will notice the problem and step in. If upstream doesn't support python 3 this is unlikely, but if upstream does and the package is just out of date in Gentoo it is more likely that you or somebody else could fix it. -- Rich
Re: [gentoo-user] Portage package removals due to python-2.7
On Mon 24 Aug 2020 12:24:26 GMT, Michael wrote: > Thanks Neil, will this keep all requisite build and run time dependencies, or > will they have to be added to package.unmask too? You will have to do the same for all the packages you want to keep (no matter if it’s a dep or a manually emerged one). -- Alarig
Re: [gentoo-user] Portage package removals due to python-2.7
On Monday, 24 August 2020 11:57:02 BST Neil Bothwick wrote: > On Mon, 24 Aug 2020 11:50:42 +0100, Michael wrote: > > !!! The following installed packages are masked: > > - app-emulation/virtualbox-bin-5.2.40.137108::gentoo (masked by: > > package.mask) /usr/portage/profiles/package.mask: > > # Michał Górny (2020-08-22) > > # These packages (or package versions) still require Python 2.7. > > # They are either dead upstream, their Python 3 porting efforts are > > # not progressing or their maintainers are simply unresponsive. > > # Please do not remove any packages from this list unless you actually > > # port it to Python 3. > > # Removal in 30 days. Tracker bug #694800. > > > > For more information, see the MASKED PACKAGES section in the emerge > > man page or refer to the Gentoo Handbook. > > = > > > > I have a number of VBox VM systems, some with active software licenses > > running on them and the VBox-bin is a low-maintenance and convenient > > way to run them. I'd prefer to avoid emerging a non-bin VBox. Is there > > some way I could keep older packages running in Gentoo, until more up > > to date versions appear again in the tree (if ever)? > > Copy the ebuild to a local overlay and add app-emulation/virtualbox-bin > to /etc/portage/profile/package.unmask. Thanks Neil, will this keep all requisite build and run time dependencies, or will they have to be added to package.unmask too? signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Portage package removals due to python-2.7
On Mon, 24 Aug 2020 11:50:42 +0100, Michael wrote: > !!! The following installed packages are masked: > - app-emulation/virtualbox-bin-5.2.40.137108::gentoo (masked by: > package.mask) /usr/portage/profiles/package.mask: > # Michał Górny (2020-08-22) > # These packages (or package versions) still require Python 2.7. > # They are either dead upstream, their Python 3 porting efforts are > # not progressing or their maintainers are simply unresponsive. > # Please do not remove any packages from this list unless you actually > # port it to Python 3. > # Removal in 30 days. Tracker bug #694800. > > For more information, see the MASKED PACKAGES section in the emerge > man page or refer to the Gentoo Handbook. > = > > I have a number of VBox VM systems, some with active software licenses > running on them and the VBox-bin is a low-maintenance and convenient > way to run them. I'd prefer to avoid emerging a non-bin VBox. Is there > some way I could keep older packages running in Gentoo, until more up > to date versions appear again in the tree (if ever)? Copy the ebuild to a local overlay and add app-emulation/virtualbox-bin to /etc/portage/profile/package.unmask. -- Neil Bothwick Having children will turn you into your parents. pgp8hn0jykHaM.pgp Description: OpenPGP digital signature
[gentoo-user] Portage package removals due to python-2.7
As python-2.7 was EOL'ed I find some packages are being retired and have/will fall off the tree; e.g. app-office/taskcoach. I keep a version of taskcoach running in a VM in the hope the devs/maintainer will come up with a version updated to run on later python releases. Then I see this: === !!! The following installed packages are masked: - app-emulation/virtualbox-bin-5.2.40.137108::gentoo (masked by: package.mask) /usr/portage/profiles/package.mask: # Michał Górny (2020-08-22) # These packages (or package versions) still require Python 2.7. # They are either dead upstream, their Python 3 porting efforts are # not progressing or their maintainers are simply unresponsive. # Please do not remove any packages from this list unless you actually # port it to Python 3. # Removal in 30 days. Tracker bug #694800. For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. = I have a number of VBox VM systems, some with active software licenses running on them and the VBox-bin is a low-maintenance and convenient way to run them. I'd prefer to avoid emerging a non-bin VBox. Is there some way I could keep older packages running in Gentoo, until more up to date versions appear again in the tree (if ever)? signature.asc Description: This is a digitally signed message part.
