Re: [gentoo-user] Re: meson build woes
On Tuesday, August 25, 2020 2:23:57 A.M. AEST Grant Edwards wrote: > On 2020-08-24, Franz Fellner wrote: > > On Mo 24 Aug 2020 11:21:10 +0200, Hogren wrote: > >> Maybe try to : > >> > >> - Unmerge all python and python-setuptools versions > > > > No, don't do that!!! > > Unmerging all python version will leave you with a non-working portage. > > Indeed -- I've done that. It's not fun. You certainly won't do it a > second time. > > -- > Grant I'm trying again. I started by removing all the Python version stuff I'd added under /etc/ portage to try and bring things back to standard. Now I'm seeing instances where a package has had multiple "python_single_target" variable set, like the example below. I'm not sure how this is possible, or where they are coming from. It makes it look like something may be wrong in my profile, but that should get corrected every time I sync portage with the mirrors, shouldn't it? ## [Tue Aug 25 11:42:14]# emerge --autounmask-keep-masks y --verbose \ --quiet-fail y --backtrack=99 --keep-going --jobs 6 --with-bdeps y \ --quiet --update --buildpkg --deep --reinstall changed-use --usepkg n \ -a -e world !!! The ebuild selected to satisfy ">=dev-util/gdbus-codegen-2.48" has unmet requirements. - dev-util/gdbus-codegen-2.62.6::gentoo USE="" ABI_X86="(64)" PYTHON_SINGLE_TARGET="python3_6 python3_7 -python3_8" The following REQUIRED_USE flag constraints are unsatisfied: exactly-one-of ( python_single_target_python3_6 python_single_target_python3_7 python_single_target_python3_8 ) ## -- Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/ Asking for technical help in newsgroups? Read this first: http://catb.org/~esr/faqs/smart-questions.html#intro
[gentoo-user] Re: meson build woes
On 2020-08-24, Thomas Mueller wrote: >> >> - Unmerge all python and python-setuptools versions > >> > No, don't do that!!! >> > Unmerging all python version will leave you with a non-working portage. > >> Indeed -- I've done that. It's not fun. You certainly won't do it a >> second time. > How did you recover? You couldn't even use setup.py at that stage. Right. > Did you have to download the python distfile if you didn't have it > already, and build using configure and make directly? IIRC, I copied Python binaries and libraries from another computer. That took some trial-and-error, but I eventually got to the point where I could do an "emerge python". -- Grant
Re: [gentoo-user] Re: meson build woes
On 2020-08-24 17:24, Thomas Mueller wrote: > > How did you recover? You couldn't even use setup.py at that stage. > > Did you have to download the python distfile if you didn't have it > already, and build using configure and make directly? You can find someone you trust with the same architecture and get a binary or quickpkg copy of the python package from them. Failing that, you can use the livecd or one of openstack VM images from gentoo.org to boot into a working system and create the binary package there.
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
[gentoo-user] Re: meson build woes
> >> - Unmerge all python and python-setuptools versions > > No, don't do that!!! > > Unmerging all python version will leave you with a non-working portage. > Indeed -- I've done that. It's not fun. You certainly won't do it a > second time. > Grant How did you recover? You couldn't even use setup.py at that stage. Did you have to download the python distfile if you didn't have it already, and build using configure and make directly? Tom
[gentoo-user] Re: meson build woes
On 2020-08-24, Franz Fellner wrote: > On Mo 24 Aug 2020 11:21:10 +0200, Hogren wrote: >> Maybe try to : >> >> - Unmerge all python and python-setuptools versions > > No, don't do that!!! > Unmerging all python version will leave you with a non-working portage. Indeed -- I've done that. It's not fun. You certainly won't do it a second time. -- Grant
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] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On Sat, Aug 22, 2020 at 09:17:56PM +0100, Ashley Dixon wrote: > On Sat, Aug 22, 2020 at 04:15:38AM +, Caveman Al Toraboran wrote: > > just to double check i got you right. due to > > flushing the buffer to disk, this would mean that > > mail's throughput is limited by disk i/o? [...] > When an M.T.A. encounters mail, the content of the mail will first exist in > the > M.T.A.'s local memory, in a buffer. Before sending an "OK" to the > sending > server, it should first make an attempt to write it to disk, through an > fwrite > (stdio) or write (POSIX) call. At that point, it is, in theory, the > kernel's > choice if and when it is _actually_ written to disk, but if one of > the > aforementioned functions return a success code, the M.T.A. has done its bit, > and > can consider the message "safely stored". true and yes given a sink willing to accept your throughput, an mta is generally disk i/o bound -- Eray
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.
Re: [gentoo-user] meson build woes
Sorry sorry sorry… Franz is right... Do not uninstall all python versions ! Hogren On 24/08/2020 11:39, Franz Fellner wrote: On Mo 24 Aug 2020 11:21:10 +0200, Hogren wrote: Maybe try to : - Unmerge all python and python-setuptools versions No, don't do that!!! Unmerging all python version will leave you with a non-working portage. portage is written in python. You can fix that but it requires some manual intervention... - Verify your package.use files. Run "grep -Ri 'python' /etc/portage/package.use/" and delete old files. - Run a "emerge --newuse --update --autounmask-write --deep --with-bdeps=y @world". This should be the first thing to check. package.use and probably also make.conf should be looked for PYTHON settings. Uncomment affected lines first (put the character # at the beginning) before deleting. The "--deep --newuse" emerge options should take care for the rest.
Re: [gentoo-user] meson build woes
On Mo 24 Aug 2020 11:21:10 +0200, Hogren wrote: > Maybe try to : > > - Unmerge all python and python-setuptools versions No, don't do that!!! Unmerging all python version will leave you with a non-working portage. portage is written in python. You can fix that but it requires some manual intervention... > - Verify your package.use files. Run "grep -Ri 'python' > /etc/portage/package.use/" and delete old files. > > - Run a "emerge --newuse --update --autounmask-write --deep > --with-bdeps=y @world". This should be the first thing to check. package.use and probably also make.conf should be looked for PYTHON settings. Uncomment affected lines first (put the character # at the beginning) before deleting. The "--deep --newuse" emerge options should take care for the rest.
Re: [gentoo-user] meson build woes
Hi,
In your logs, I saw that python 3.7 is executed.
And you wrote that python 3.6 is selected.
I had many problem with the python transition too. I have no simple
solution. I uninstalled many things for reinstall after.
Maybe try to :
- Unmerge all python and python-setuptools versions
- Verify your package.use files. Run "grep -Ri 'python'
/etc/portage/package.use/" and delete old files.
- Run a "emerge --newuse --update --autounmask-write --deep
--with-bdeps=y @world".
Hogren
On 23/08/2020 07:16, Paul Colquhoun wrote:
For the past month or so (since the recent Python version changes) I
haven't been able to get a full emerge update to complete.
The main culprit seems to be meson, but only because what looks like
an internal Python module, "setup.py", can't import 'setup' from
'setuptools'
All the remaining failures are either the same error, or dependencies
of packages that get the error.
I have been trying various combinations of which Python version is the
default and which versions are in the "PYTHON_TARGETS" variable, but
nothing seems to change much.
Rebuilding dev-python/setuptools didn't help either.
My google searches for the error message
"cannot import name 'setup' from 'setuptools'"
also haven't turned up anything that seemed relevent to my system
Does anyone have any suggestions on what I can try before I rebuild my
system from scratch?
The relevant section of the build log in included below, and the full
log is attached.
"eselect python list" tells me tjhat the default should be python3.6
###
* python3_7: running distutils-r1_run_phase distutils-r1_python_compile
python3.7 setup.py build -j 6
Traceback (most recent call last):
File "setup.py", line 24, in
from setuptools import setup
ImportError: cannot import name 'setup' from 'setuptools' (unknown
location)
* ERROR: dev-util/meson-0.54.2::gentoo failed (compile phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 125: Called src_compile
* environment, line 2949: Called distutils-r1_src_compile
* environment, line 1219: Called _distutils-r1_run_foreach_impl
'distutils-r1_python_compile'
* environment, line 447: Called python_foreach_impl
'distutils-r1_run_phase' 'distutils-r1_python_compile'
* environment, line 2557: Called multibuild_foreach_variant
'_python_multibuild_wrapper' 'distutils-r1_run_phase'
'distutils-r1_python_compile'
* environment, line 2056: Called _multibuild_run
'_python_multibuild_wrapper' 'distutils-r1_run_phase'
'distutils-r1_python_compile'
* environment, line 2054: Called _python_multibuild_wrapper
'distutils-r1_run_phase' 'distutils-r1_python_compile'
* environment, line 846: Called distutils-r1_run_phase
'distutils-r1_python_compile'
* environment, line 1210: Called distutils-r1_python_compile
* environment, line 1079: Called esetup.py 'build' '-j' '6'
* environment, line 1600: Called die
* The specific snippet of code:
* "${@}" || die "${die_args[@]}";
###
--
Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/
Asking for technical help in newsgroups? Read this first:
http://catb.org/~esr/faqs/smart-questions.html#intro
