You are not logged in.
Pages: 1
On the other hand, there was yet another set of xorg security updates that we don’t get because it's forked.
openssh-client finally showed up. I wonder why this security update took four days to make its way through Devuan.
That shows just xorg-server-source, but the runtime pieces have names like xserver-xorg-*. And the xserver-xorg-core in Daedalus is 2:21.1.7-3+deb12u2devuan1.
xorg-server had vulnerabilities fixed in Debian about six days ago. I know Devuan’s is forked because of the libseat situation.
In such a case, is “TODO: merge xorg-server security fixes” added to some list of items somewhere, or…?
About a day and a half ago, Debian announced “For the stable distribution (bookworm), these problems have been fixed in version 1:9.2p1-2+deb12u2.”
I haven’t seen the update, and pkginfo.devuan.org search for openssh* shows 1:9.2p1-2+deb12u1 for daedalus and no mention of daedalus-security.
Is something wrong?
There's a more recent fix in the X server that could be relevant: https://bugs.devuan.org/cgi/bugreport.cgi?bug=799. And, if nowhere else, I suppose you could get the old debs out of installation media.
Thanks!
I as well don’t want whatever else happens to be in daedalus-proposed-updates. How would I set my pinning properly?
I looked around and found apt_preferences(5), and I think I have an idea of what to do for Package and Pin-Priority, but it is not obvious what would be correct for Pin: release a= or n= to correspond to daedalus-proposed-updates.
I don’t want to get it wrong and make a mess and need more help to undo it all.
Another possibility is probably within the infinitude of git.devuan.org. Maybe something will happen on some branch in https://git.devuan.org/devuan/xorg-server/branches as an indication of code getting into Daedalus. Or maybe not. That might be not the right region of git at all.
One possibility might be to look at
https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=xorg
https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=*seat*
each day. I would have to recognize when version numbers had changed.
Given that I won’t be using that Daedalus system regularly until this has been fixed, what is the most efficient way to check periodically from somewhere else whether the fix has happened yet?
I'm not sure there is a bug report, but that particular issue of having multiple Xorg (in different VT) with seatd, is currently being worked on, and I believe an update is coming fairly soon.
I’m glad to know that!
I don’t see a bug report, but I’m not experienced with the bug tracker.
Would it be more appropriate to have this topic moved to a lower-level subforum where more of the right people might see it, since, strictly speaking, this subforum suggests being about things running on X and not about getting X to run.
If this forum is even capable of moving topics, that is.
I have always been using a plain startx in each, but using startx -- :1 for the second one fails in the same way.
I startx on one vt (pretty minimal, starts up a window manager).
I try to startx again on another vt — same user or different user — and it fails. seatd says "Could not add client: seat is VT-bound and has an active client".
Since I don’t know whether being VT-bound is good or bad, I found SEATD_VTBOUND=0 and tried that on the seatd invocation. But seatd is still unhappy because it still sees an active client regardless.
I presume switching away from a vt is supposed to make an X session become *not* active somehow.
It looks like FEATURE_C12 may be orphan_file. I'd heard that new mkfs.ext4 was going to use that feature by default, and that older versions of e2fsck weren't going to understand it
Pages: 1