Re: [gentoo-user] Seamonkey and Firefox clash over rust version.
Arve Barsnes wrote: > On Wed, 12 Jan 2022 at 02:14, Dale wrote: >> rsync: getaddrinfo: rsync.gentoofan.org 873: Temporary failure in name >> resolution > I noticed somewhere on the page it said that the layman method of > adding the overlay was deprecated, maybe he has removed rsync > capability for it. > > Regards, > Arve > > Well, that would make sense. Guess I'll steal the ebuild you linked to and put it in my overlay. I was hoping for a overlay that would update itself but maybe not. Thanks. Dale :-) :-)
Re: [gentoo-user] Seamonkey and Firefox clash over rust version.
On Wed, 12 Jan 2022 at 02:14, Dale wrote: > rsync: getaddrinfo: rsync.gentoofan.org 873: Temporary failure in name > resolution I noticed somewhere on the page it said that the layman method of adding the overlay was deprecated, maybe he has removed rsync capability for it. Regards, Arve
Re: [gentoo-user] Re: How to diagnose version conflicts?
On Wed, 12 Jan 2022 at 01:44, Grant Edwards wrote: > Still not sure what command one uses to determine what package is > preventing some other package from being upgraded... It should all be in the emerge output, although it's quite hard to read. If you want help interpreting it you could post the complete conflict output, but what you've posted in your initial message is just the bit that says that python-exec-2.4.8 requires python-exec-conf-2.4.6. That's not a conflict, that's just one of the packages having one dependency. To have a conflict, a different package would need to require a different version. Most of the times this particular kind of conflict is with an older package that requires older PYTHON_TARGETS than can be provided, and I expect something that got depcleaned with ipkg-utils, or ipkg-utils directly, required python-exec or python-exec-conf with PYTHON_TARGETS="python3_7". Note that dev-lang/python itself is not the source of any of these problems, I still have python 2.7 and 3.10 installed (along with 3.9 which is the default version on this machine now). Regards, Arve
Re: [gentoo-user] Seamonkey and Firefox clash over rust version.
Arve Barsnes wrote: > On Mon, 10 Jan 2022 at 12:28, Arve Barsnes wrote: >> On Mon, 10 Jan 2022 at 11:33, Dale wrote: >>> I read in a bug report that this is fixed in a overlay. Makes me wonder >>> why this has been going on for a month or so without a 'in tree' fix. >>> I'd rather not add a overlay but if it is the only fix, may have too. >> An alternative to adding the whole overlay (and the poly-c overlay is >> quite big) is to just copy the ebuild you want to your local overlay. >> It looks like poly is involved in the maintenance of this package >> normally, so I'm not sure why this is not in the main repo yet, if >> there is something weird being worked on. >> >> The biggest change if you copy it locally, is that you get the latest >> released version of seamonkey, and the rust dependency in the ebuild >> has been updated to: >> >>> =virtual/rust-1.34.0 >> That seems to indicate that the current requirement of <1.53 was never >> correct? >> >> Either way, worth a try if you ask me, you're on a newer version, the >> rust conflict with firefox will not come up again, and hopefully >> eventually, the main gentoo repo will get even newer versions so >> you'll get automatically updated without having added a full extra >> overlay. > Also, the ebuild to copy: > > https://www.gentoofan.org/gentoo/poly-c_overlay/www-client/seamonkey/seamonkey-2.53.10.2-r2.ebuild > > Cheers, > Arve > > I was going to add the overlay but I get this error: root@fireball / # layman -a poly-c * Adding overlay... * Running Rsync... # /usr/bin/rsync -rlptDvz --progress --delete --delete-after --timeout=180 --exclude=distfiles/* --exclude=local/* --exclude=packages/* rsync://rsync.gentoofan.org/poly-c/ /var/lib/layman/poly-c rsync: getaddrinfo: rsync.gentoofan.org 873: Temporary failure in name resolution rsync error: error in socket IO (code 10) at clientserver.c(137) [Receiver=3.2.3] * Failure result returned from Rsync * Deleting _empty_ directory "/var/lib/layman/poly-c" * Adding repository "poly-c" failed! * CLI: Errors occurred processing action add * Adding repository "poly-c" failed! root@fireball / # I been getting that for around 24 hours now. If I go to a web browser, the site works fine. No clue why it isn't working. Can someone test this and see if it works for them? If it works for someone else, then it is me. If it fails for someone else, then it's not just me. Thanks. Dale :-) :-)
[gentoo-user] Re: How to diagnose version conflicts?
On 2022-01-12, Jack wrote: >> python-exec-2.4.8 requires python-exec-conf which requires >> python-exec 2.4.6? > > I was going to wonder if you are caught in the middle of an upgrade > that's only partly reached the mirrors. Given that (as I see it, > having last done a sync a few hours ago) that there is ONLY one version > each in the tree for python-exec-2.4.8 and python-exec-conf-2.4.6. Yep, same here. > However, looking at the ebuilds: > python-exe requires python-exec-conf (no version specified) > python-exec-conf-2.4.6 requires "! should allow 2.4.8. > > I have both python 3.9.9-r1 and 3.10.0_p1-r1 installed (plus > 2.7.18_p13) so there doesn't seem to be any conflict there. What does > "equery d python-exec" tell you? After poking around a bit, I realized that the only machine that was having this problem was also the only one that had python2.7 installed. Python 2.7 was required by ipkg-utils (for which the ebuild seems to have long since vanished). The only thing I ever use from ipkg-utils is the ipkg-build bash script. I copied that script to ~/bin/ and unmerged ipkg-utils. emerge --depclean then removed python2.7, and then emerge -auvND happily upgraded python-exec to 2.4.8. Still not sure what command one uses to determine what package is preventing some other package from being upgraded... -- Grant
Re: [gentoo-user] How to diagnose version conflicts?
On 2022.01.11 19:11, Grant Edwards wrote: It seems that every time a new Python version is unmasks, it breaks something on one or another of my machines. This time it's a python-exec version conflict that prevents emerge -u. FAICT, Python 3.10 requires python-exec 2.4.8, and some other package requires 2.4.6. I've fixed things temporarily with: package.use: */* PYTHON_TARGETS: -python3_10 */* PYTHON_SINGLE_TARGET -python3_10 package.mask: >=dev-lang/python-3.10 Now, at least I can continue to update the machine. When I get the spare time to try to get Python 3.10 working, what is the easiest way to figure out which package is causing the problem by requring the older version of python-exec? I've tried adding a 't' to the emerge flags, but that doesn't seem to show anything useful. Is there any documentation on how to determine the cause of a package version conflict? Here's what emerge says: (dev-lang/python-exec-conf-2.4.6:2/2::gentoo, ebuild scheduled for merge) pulled in by dev-lang/python-exec-conf required by (dev-lang/python-exec-2.4.8:2/2::gentoo, ebuild scheduled for merge) USE="(native-symlinks) -test" ABI_X86="(64)" PYTHON_TARGETS="(pypy3) (python3_10) (python3_8) (python3_9)" python-exec-2.4.8 requires python-exec-conf which requires python-exec 2.4.6? I was going to wonder if you are caught in the middle of an upgrade that's only partly reached the mirrors. Given that (as I see it, having last done a sync a few hours ago) that there is ONLY one version each in the tree for python-exec-2.4.8 and python-exec-conf-2.4.6. My response would just be wait an hour and re-sync. However, looking at the ebuilds: python-exe requires python-exec-conf (no version specified) python-exec-conf-2.4.6 requires "!should allow 2.4.8. I have both python 3.9.9-r1 and 3.10.0_p1-r1 installed (plus 2.7.18_p13) so there doesn't seem to be any conflict there. What does "equery d python-exec" tell you?
Re: [gentoo-user] Strange behaviour disconnecting and reconnecting USB-C screen
What I would do is create a bash script and link to a keyboard shortcut to execute as needed. One of the advantages of xrandr is the ease of scripting. Lee On Jan 11, 2022 at 1:25 AM, Andreas Fink wrote: Hello, I've got a new laptop and see a strange behaviour when disconnecting and reconnecting my USB-C screen. Here are the steps that I am doing. I have a dual screen setup with xrandr, with my notebook screen being the primary screen and a second large external screen connected via USB-C to my notebook directly. Now I disconnect the USB-C cable and do not do anything software wise, i.e. my X-Server is still pretending to run on two screens, I can move the screen outside of my notebook screen (into the area where the external screen). Now I reconnect the USB-C cable but the screens stays blank (the the screen it says "No USB Type-C connection from your computer"). The only way to get a signal again is to first use xrandr to only use my notebook screen, and at the exact time udev gets a DRM event, and suddently my external monitor appears within xrandr as connected (I did not touch the cable, I only ran an xrandr command to use only the notebook screen). Right after the DRM event I can run the xrandr command to use both screens, but it is annoying to degrade first to one screen, because all windows are moved around and I do not end up with the same window setup as before. Using the same screen with the same experiment as described above but with a different notebook the screen is able to pick up the signal again, so it's not purely a problem with the external screen. Any idea what is going on and how I can workaround it? I just want to disconnect the cable and reconnect it without the need to switch any xrandr setup. Thanks for your ideas and help Andreas
[gentoo-user] How to diagnose version conflicts?
It seems that every time a new Python version is unmasks, it breaks something on one or another of my machines. This time it's a python-exec version conflict that prevents emerge -u. FAICT, Python 3.10 requires python-exec 2.4.8, and some other package requires 2.4.6. I've fixed things temporarily with: package.use: */* PYTHON_TARGETS: -python3_10 */* PYTHON_SINGLE_TARGET -python3_10 package.mask: >=dev-lang/python-3.10 Now, at least I can continue to update the machine. When I get the spare time to try to get Python 3.10 working, what is the easiest way to figure out which package is causing the problem by requring the older version of python-exec? I've tried adding a 't' to the emerge flags, but that doesn't seem to show anything useful. Is there any documentation on how to determine the cause of a package version conflict? Here's what emerge says: (dev-lang/python-exec-conf-2.4.6:2/2::gentoo, ebuild scheduled for merge) pulled in by dev-lang/python-exec-conf required by (dev-lang/python-exec-2.4.8:2/2::gentoo, ebuild scheduled for merge) USE="(native-symlinks) -test" ABI_X86="(64)" PYTHON_TARGETS="(pypy3) (python3_10) (python3_8) (python3_9)" python-exec-2.4.8 requires python-exec-conf which requires python-exec 2.4.6?
Re: [gentoo-user] Strange behaviour disconnecting and reconnecting USB-C screen
My normal layout #!/bin/sh xrandr --output eDP-1 --mode 1920x1080 --pos 3640x249 --rotate normal --output DP-1 --off --output HDMI-1 --off --output DP-2 --off --output HDMI-2 --off --output DP-1-1 --mode 1920x1080 --pos 0x0 --rotate left --output DP-1-2 --off --output DP-1-2-8 --primary --mode 2560x1600 --pos 1080x46 --rotate normal --output DP-1-2-1 --off --output DP-1-3 --off The layout I switch to to wake the screens up, before then switchign back to the normal layout #!/bin/sh xrandr --output eDP-1 --mode 1920x1080 --pos 3640x498 --rotate normal --output DP-1 --off --output HDMI-1 --off --output DP-2 --off --output HDMI-2 --off --output DP-1-1 --mode 1600x1200 --pos 0x0 --rotate left --output DP-1-2-8 --primary --mode 1920x1600 --pos 1080x46 --rotate normal --output DP-1-2-1 --off --output DP-1-2 --off --output DP-1-3 --off I used arandr to generate the commands and have the assigned to hotkeys On 11.01.22 12:13, Andreas Fink wrote: On Tue, 11 Jan 2022 10:57:28 +0100 Benjamin Blanz wrote: Hi, I have the same issue using a usb-c dockingstation. I have found it is enough to change the resolution of the connected screens to get them back. Still annoying, but at least the windows are not redistributed.On 11.01.22 10:25, Andreas Fink wrote: That did not work for me because xrandr complains that any resolution is an unknown mode. Which command do you use to change the resolution of the connected screen? OpenPGP_0x7AAC0ED205503D09.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] Strange behaviour disconnecting and reconnecting USB-C screen
On Tue, 11 Jan 2022 10:57:28 +0100 Benjamin Blanz wrote: > Hi, > I have the same issue using a usb-c dockingstation. > I have found it is enough to change the resolution of the connected screens > to get them back. > Still annoying, but at least the windows are not redistributed.On 11.01.22 > 10:25, Andreas Fink wrote: > That did not work for me because xrandr complains that any resolution is an unknown mode. Which command do you use to change the resolution of the connected screen?
Re: [gentoo-user] Strange behaviour disconnecting and reconnecting USB-C screen
Hi, I have the same issue using a usb-c dockingstation. I have found it is enough to change the resolution of the connected screens to get them back. Still annoying, but at least the windows are not redistributed.On 11.01.22 10:25, Andreas Fink wrote: Hello, I've got a new laptop and see a strange behaviour when disconnecting and reconnecting my USB-C screen. Here are the steps that I am doing. I have a dual screen setup with xrandr, with my notebook screen being the primary screen and a second large external screen connected via USB-C to my notebook directly. Now I disconnect the USB-C cable and do not do anything software wise, i.e. my X-Server is still pretending to run on two screens, I can move the screen outside of my notebook screen (into the area where the external screen). Now I reconnect the USB-C cable but the screens stays blank (the the screen it says "No USB Type-C connection from your computer"). The only way to get a signal again is to first use xrandr to only use my notebook screen, and at the exact time udev gets a DRM event, and suddently my external monitor appears within xrandr as connected (I did not touch the cable, I only ran an xrandr command to use only the notebook screen). Right after the DRM event I can run the xrandr command to use both screens, but it is annoying to degrade first to one screen, because all windows are moved around and I do not end up with the same window setup as before. Using the same screen with the same experiment as described above but with a different notebook the screen is able to pick up the signal again, so it's not purely a problem with the external screen. Any idea what is going on and how I can workaround it? I just want to disconnect the cable and reconnect it without the need to switch any xrandr setup. Thanks for your ideas and help Andreas OpenPGP_0x7AAC0ED205503D09.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[gentoo-user] Strange behaviour disconnecting and reconnecting USB-C screen
Hello, I've got a new laptop and see a strange behaviour when disconnecting and reconnecting my USB-C screen. Here are the steps that I am doing. I have a dual screen setup with xrandr, with my notebook screen being the primary screen and a second large external screen connected via USB-C to my notebook directly. Now I disconnect the USB-C cable and do not do anything software wise, i.e. my X-Server is still pretending to run on two screens, I can move the screen outside of my notebook screen (into the area where the external screen). Now I reconnect the USB-C cable but the screens stays blank (the the screen it says "No USB Type-C connection from your computer"). The only way to get a signal again is to first use xrandr to only use my notebook screen, and at the exact time udev gets a DRM event, and suddently my external monitor appears within xrandr as connected (I did not touch the cable, I only ran an xrandr command to use only the notebook screen). Right after the DRM event I can run the xrandr command to use both screens, but it is annoying to degrade first to one screen, because all windows are moved around and I do not end up with the same window setup as before. Using the same screen with the same experiment as described above but with a different notebook the screen is able to pick up the signal again, so it's not purely a problem with the external screen. Any idea what is going on and how I can workaround it? I just want to disconnect the cable and reconnect it without the need to switch any xrandr setup. Thanks for your ideas and help Andreas
