xpra icon
Bug tracker and wiki

Opened 8 months ago

Closed 8 months ago

Last modified 7 months ago

#2737 closed defect (invalid)

FTBFS on [armel,armhf]: Xdummy versus xvfb

Reported by: onlyjob Owned by: Antoine Martin
Priority: major Milestone: 4.0
Component: platforms Version: 3.0.x
Keywords: Cc:

Description

As reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956822
starting with 3.0.8 Xpra FTBFS on [armel,armhf] as follows:

  File "setup.py", line 788, in build_xpra_conf
    assert xvfb_command[0] == 'Xorg'
AssertionError

We've never had such build problem on Arms before...

I think the problem was introduced in r25652.

Please advise.

Full build logs are here:

Change History (9)

comment:1 Changed 8 months ago by Antoine Martin

Resolution: invalid
Status: newclosed

Don't modify the xpra source.

comment:2 Changed 7 months ago by onlyjob

This is a strange and unproductive response... :(

Anyway. do you recommend to use xvfb instead of Xorg on arm architectures??

Wouldn't it make sense to use Xorg on architectures where it works to avoid troubleshooting xvfb errors?

What was the reason for r25652? To address a build or run-time problem?

Thanks.

comment:3 Changed 7 months ago by Antoine Martin

This is a strange and unproductive response... :(

Didn't you break the build with your own patch?

Anyway. do you recommend to use xvfb instead of Xorg on arm architectures??

Yes, that's what the change does.

What was the reason for r25652? To address a build or run-time problem?

As per commit message, Xdummy so slow it is unusable on arm.

comment:4 Changed 7 months ago by onlyjob

I certainly did not break the build with "my" patch. As I've said it is a regression from former releases due to r25652 which (I'm guessing) could have been trying to address a non-Debian problem.

The reason for FTBFS is probably because there is no "xvfb" in Depends, as it was not required until 3.0.8.

I'll see if I can introduce "xvfb" as a dependency on arm architectures. I don't have arm hardware so I would not be able to test that...

Thanks.

comment:5 Changed 7 months ago by Antoine Martin

I certainly did not break the build with "my" patch.

Provably false: builds work without the patch on arm.
I've tested and verified this myself.

As I've said it is a regression from former releases

Absolutely not, it's a fix.
The packages you make for arm never worked on most devices (ie: even rpi3) - but since you don't test them, you would not know that.

could have been trying to address a non-Debian problem.

Reported by Debian users actually, who found that the Debian packages did not work.

comment:6 Changed 7 months ago by onlyjob

Do you think I'm lying to you or something? We did not introduce any new patches for several releases and build suddenly break on 3.0.8 most certainly due to lack of "xvfb" - a new required dependency on arm.

I certainly did not author any patch that caused this FTBFS. Please let me know if any particular patch should be removed.

Thanks for confirming new requirement. Of course I want to fix the problem and I should be able to address it shortly.

comment:7 Changed 7 months ago by Antoine Martin

We did not introduce any new patches for several releases and build suddenly break on 3.0.8

Like I said, and for the last time: the builds on arm do succeed, they only break because of the patch found only in Debian.
When and why Debian started using this patch is really not my concern, the patch is wrong and causes the problem you reported in this ticket.

most certainly due to lack of "xvfb"

No.
Not having Xvfb installed would not break at build time, it would break only some xpra subcommands at runtime.
At build time what breaks is precisely the problematic patch.

comment:8 Changed 7 months ago by onlyjob

Antoine, I just need to confirm: are you talking about the following patch?

https://salsa.debian.org/debian/xpra/-/blob/master/debian/patches/fix-xvfb-path.patch

Are you saying that it should be safe to remove it, even if Xorg is not available at build-time?

Of course I'll remove the patch if it is obsolete or causing the problem.

Thanks.

comment:9 Changed 7 months ago by Antoine Martin

Are you saying that it should be safe to remove it, even if Xorg is not available at build-time?

Sort of: I am saying that it breaks the arm builds because it assumes Xorg is always used.

If Xorg is not available at build time, the Xorg path detection may not work (for platforms that use Xorg), and you may end up with the wrong path.

Of course I'll remove the patch if it is obsolete or causing the problem.

Obsolete: I don't know. Doesn't look like it ever did anything useful. Path detection should always work. (if it doesn't work somewhere, then that's what should be fixed)
Causing the problem: definitely.

Note: See TracTickets for help on using tickets.