Hi Sven, Would you mind bumping to 5.0.0_rc1 (unkeyworded) for wider testing? Quite excited to see movement towards it finally. Thank you!
5.0.0 is now out.
This required more work than expected - mostly removing patches, adding a new one and removing configure flags - but I have a working version at: https://github.com/hhoffstaette/portage/tree/master/app-misc/screen This includes the changes from pending PRs, incl. my multiuser rework. Feel free to steal.
The screen ebuild linked to from comment #2 does not depend on libutempter, nor does it specify --enable-utmp as a configure option. This results in certain commands being unavailable. In turn, the stock /etc/screenc causes screen to raise errors such as the one below. /etc/screenrc: bind: unknown command 'login' Such diagnostics may be difficult to observe because screen immediately proceeds to clear the screen after printing them, which is tremendously helpful of it. See, also, https://github.com/void-linux/void-packages/commit/0f6da07.
Also, https://lists.gnu.org/archive/html/screen-devel/2024-10/msg00007.html is worth keeping an eye on. It pertains to the quality of the initial 5.0 release, or potential lack thereof.
Thanks. I had some vague fears of this which is why I wasn't in a hurry to try bump it myself. I was hoping I'd got it wrong and surely such cherry-picking had been happening but I'd missed it, but apparently not. One of the times I didn't want to be right...
(In reply to kfm from comment #3) > The screen ebuild linked to from comment #2 does not depend on libutempter, > nor does it specify --enable-utmp as a configure option. This results in > certain commands being unavailable. In turn, the stock /etc/screenc causes > screen to raise errors such as the one below. > > /etc/screenrc: bind: unknown command 'login' > > Such diagnostics may be difficult to observe because screen immediately > proceeds to clear the screen after printing them, which is tremendously > helpful of it. All previous ebuilds unconditionally disabled utmp support and therefore didn't have a USE flag to enable it either. That being said, I just added support for USE=utempter to the mentioned 5.0.0 ebuild, please test it and let me know if it works for you. > See, also, https://github.com/void-linux/void-packages/commit/0f6da07. The musl build fix is indeed necessary and was also added; I successfully built screen with libutempter as dependency in my musl chroot.
(In reply to Holger Hoffstätte from comment #6) > (In reply to kfm from comment #3) > > The screen ebuild linked to from comment #2 does not depend on libutempter, > > nor does it specify --enable-utmp as a configure option. This results in > > certain commands being unavailable. In turn, the stock /etc/screenc causes > > screen to raise errors such as the one below. > > > > /etc/screenrc: bind: unknown command 'login' > > > > Such diagnostics may be difficult to observe because screen immediately > > proceeds to clear the screen after printing them, which is tremendously > > helpful of it. > > All previous ebuilds unconditionally disabled utmp support and therefore > didn't have a USE flag to enable it either. That being said, I just added > support for USE=utempter to the mentioned 5.0.0 ebuild, please test it and > let me know if it works for you. It shouldn't be subject to a USE flag unless one is either prepared to go as far as installing a screenrc whose contents depend on its state, or can find some way for the missing commands to be present in the absence of libutempter. In my opinion, the former option would amount to busywork and, barring some compelling reason for libutempter to be optional that I am unaware of, probably isn't worth it. Either way, whatever package eventually makes it into ::gentoo ought not to install /etc/screenc in such a way that the bindings are broken for a particular build configuration. I would add that it can have adverse effects for people that rely on screen readers. As for the second option, I don't know whether it is possible for commands such as login to be available in screen 5.0.0 in the absence of libutempter. It seems not. > > > See, also, https://github.com/void-linux/void-packages/commit/0f6da07. > > The musl build fix is indeed necessary and was also added; I successfully > built screen with libutempter as dependency in my musl chroot. Yes, though my primary reason for linking to it was to show that --enable-utmp needs to be specified. Merely having libutempter be installed prior isn't necessarily sufficient. Anyway, I'll try out your revised ebuild soon.
(In reply to kfm from comment #7) > > It shouldn't be subject to a USE flag unless one is either prepared to go as > far as installing a screenrc whose contents depend on its state, or can find > some way for the missing commands to be present in the absence of > libutempter. I can guarantee that had I made the dependency unconditional, somebody would have asked for it to be optional via USE, for whatever reason. If Sam thinks it should be an unconditional dependency/feature I can do so in a heartbeat. Personally I don't care either way. > Yes, though my primary reason for linking to it was to show that > --enable-utmp needs to be specified. Merely having libutempter be installed > prior isn't necessarily sufficient. No - that would have been wrong, and it's why 4.9.x had a patch to prevent just that. 5.0 no longer enables this automagic dependency and disables utmp support by default.
Alright. I did my bit by reporting what would constitute a genuine QA issue if - and I emphasise the word if - it were not attended to by the time 5.0.0 appears in the gentoo repo. Whomsoever does that work may obviously contend with the matter as they see fit.
I think it's reasonable to note potential pitfalls before a bump is done, indeed. I appreciate such heads-up notices.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=45ecc314b93ee72ed92f34aeff3ae9ea2289d4dc commit 45ecc314b93ee72ed92f34aeff3ae9ea2289d4dc Author: Sam James <sam@gentoo.org> AuthorDate: 2024-11-26 06:13:59 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-11-26 06:13:59 +0000 app-misc/screen: build w/ -std=gnu17 This might be fixed on master (5.0.x) although given the issue mentioned in bug #935755 wrt missed cherry-picks from stable -> master upstream, not sure if it really is or not. In any case, just build with -std=gnu17 for now, as it's harmless and screen is an important package. Bug: https://bugs.gentoo.org/935755 Closes: https://bugs.gentoo.org/944429 Signed-off-by: Sam James <sam@gentoo.org> app-misc/screen/screen-4.9.1-r1.ebuild | 2 ++ 1 file changed, 2 insertions(+)
(In reply to Larry the Git Cow from comment #11) > This might be fixed on master (5.0.x) although given the issue mentioned > in bug #935755 wrt missed cherry-picks from stable -> master upstream, > not sure if it really is or not. It is - 5.0 Makefile.in explicitly adds std=c17: Makefile.in:CFLAGS = @CFLAGS@ -Wall -Wextra -std=c17
