FS#60226 - [lightdm-webkit-theme-archlinux] Theme crashing

Attached to Project: Community Packages
Opened by MB (MB4E) - Thursday, 27 September 2018, 21:32 GMT
Last edited by Filipe Laíns (FFY00) - Monday, 25 March 2019, 19:50 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Filipe Laíns (FFY00)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Webkit is crashing after configuring 'webkit_theme = archlinux' in file /etc/lightdm/lightdm-webkit2-greeter.conf.

Additional info:
* community/lightdm-webkit-theme-archlinux 0.5.0-1
* /var/log/lightdm/seat0-greeter.log

** (WebKitWebProcess:2113): WARNING **: 22:39:18.953: request scheme error: https
file:///usr/share/lightdm-webkit/themes/archlinux/js/greeter.js:12:28: CONSOLE ERROR TypeError: null is not an object (evaluating 'user.image.length')
This task depends upon

Closed by  Filipe Laíns (FFY00)
Monday, 25 March 2019, 19:50 GMT
Reason for closing:  None
Additional comments about closing:  Packaged moved back to the AUR. I don't have the time and/or motivation to track javascript issues. I don't really use this anymore, maybe someone in the AUR will be able to give the package the attention it needs. If you want a suggestion for other theme, I you refer you to the litarvan one.
Comment by Eli Schwartz (eschwartz) - Thursday, 25 October 2018, 13:06 GMT
FFY00,

Don't give this completely mysterious, blackbox "hurr durr upstream" thing. If there's an upstream issue, the least you could do is tell the OP what issue you've discovered... And you apparently, clearly acknowledge it is an issue.

If the software is so broken the only response you can come up with is "I dunno, go ask upstream", maybe we should not be packaging this clearly broken software!

Comment by Filipe Laíns (FFY00) - Thursday, 25 October 2018, 14:49 GMT
> Don't give this completely mysterious, blackbox "hurr durr upstream" thing

What blackbox?? Is it that difficult to click on the upstream url in the package page and see the details there?

> the least you could do is tell the OP what issue you've discovered

What would I say? Repeat what has been said in upstream? I didn't even experience the issue.

> If the software is so broken the only response you can come up with is "I dunno, go ask upstream",

I didn't say that. I closed this as "Upstream" then I proceeded to ask upstream for a new release since they apparently already fixed the issue. If this wasn't answered in a few days I would then patch the software in the packaging process. AFAIK it's always better to ask upstream for these kind of things instead of immediately patching the package ourselves.

> maybe we should not be packaging this clearly broken software!

Seriously?? After all of this, did you even checked the issue? Perhaps your definition of "clearly broken software" is different than mine. I don't consider a bad configuration file making the software misbehave "clearly broken software".


With all of that said. I should have provided a link for the upstream issue, my bad. I think you're blowing this out of proportion.
Comment by Filipe Laíns (FFY00) - Thursday, 25 October 2018, 14:52 GMT
I've updated the software to a version after the patch was applied. It should be fixed now. Be ready for another update if upstream creates a new tag.
Comment by Eli Schwartz (eschwartz) - Thursday, 25 October 2018, 16:22 GMT
> What would I say? Repeat what has been said in upstream? I didn't even experience the issue.

You would say "upstream issue, see https://github.com/Dissonant-Tech/lightdm-webkit-theme-archlinux/issues/3 and https://github.com/Dissonant-Tech/lightdm-webkit-theme-archlinux/pull/4", then you would leave the bug report open until you fixed the package.

For upstream projects that haven't had 5 issues/PRs and 35 commits ever in the history of the project, it can be less than exactly trivial to find the root cause of an issue. I, eschwartz, may be personally capable of hunting down obscure causes of things, but that's hardly an excuse to force me and other, less capable users, to do so. It is however very trivial to simply drop a link you've already tracked down.

> I closed this as "Upstream"

Instead of saying it's broken upstream, hold on while I ask for a new release so I can fix this... you opted to use the bugtracker status to mark this as something you're not going to fix.

> then I proceeded to ask upstream for a new release since they apparently already fixed the issue.

Without telling the OP you're going to do that.

> If this wasn't answered in a few days I would then patch the software in the packaging process.

At which point this bug report would *incorrectly* state that the bug status is "upstream, no comment", instead of stating "fixed, in version XXXX". Thus making people have to do a lot of unnecessary legwork in order to analyze the state of the upstream bugtracker, figure out if and where the bug was reported, if and where it was fixed, and whether or not the current Arch package contains the fix.

And it's not like they could look at the commit logs: https://git.archlinux.org/svntogit/community.git/log/trunk?h=packages/lightdm-webkit-theme-archlinux&showmsg=1
Because you didn't include a commit message describing why this update happened, which means that the best guess anyone has as to *why* it was updated is "routine upstream update". Given that, the bugtracker status is actually rather important.

> AFAIK it's always better to ask upstream for these kind of things instead of immediately patching the package ourselves.

In 80% of cases, upstream will not rush out a new version tag, either because their development model operates on a schedule or because upstream is simply dead. Personally, I'd avoid this problem for inactive projects by simply packaging the latest commit as long as it seems stable, but failing that, I see no active harm in fixing first and asking for release tags after. Okay, users might have to pacman -Syu two updates instead of one...

It's a moot point, because I never said I cared how you package the fix, all I said is that you should actually communicate with other people about what you are doing.

> I don't consider a bad configuration file making the software misbehave "clearly broken software".

Bad configuration file? From how I'm reading this issue and the upstream issue, the "bad configuration" is "configuring lightdm to use this theme", and the bug is that the theme itself has buggy handling of a not-bad-at-all configuration file. If you're going to claim that everyone who doesn't add some pointless picture to their Unix user account has "bad configuration", well...

The software as it is currently in the repos would seem to be broken under what I consider to be a very common configuration indeed.

...

All of this is to say that I get that there's a simple fix for the package, I simply don't understand why it is so *hard* to communicate what you're doing to fix it. Leaving a bug alone for weeks, then finally coming around and closing it without saying anything and without releasing a new version at that time, is not sterling quality communication.
Comment by Eli Schwartz (eschwartz) - Thursday, 25 October 2018, 16:24 GMT
> With all of that said. I should have provided a link for the upstream issue, my bad. I think you're blowing this out of proportion.

My issue is that you didn't provide a link, and you're admitting that you should have provided a link but telling me that I'm blowing it out of proportion?
Comment by Filipe Laíns (FFY00) - Friday, 26 October 2018, 19:37 GMT
> For upstream projects that haven't had 5 issues/PRs and 35 commits ever in the history of the project, it can be less than exactly trivial to find the root cause of an issue. I, eschwartz, may be personally capable of hunting down obscure causes of things, but that's hardly an excuse to force me and other, less capable users, to do so. It is however very trivial to simply drop a link you've already tracked down.

Yeah, it's less than trivial. I didn't provide a link because at the time it was actually very inconvenient for me. And I apologize for not referencing it.

> obscure causes of things

You're kidding right???

> Instead of saying it's broken upstream, hold on while I ask for a new release so I can fix this... you opted to use the bugtracker status to mark this as something you're not going to fix.

Right, do you have any other words you want to put in my mouth?

> In 80% of cases, upstream will not rush out a new version tag, either because their development model operates on a schedule or because upstream is simply dead. Personally, I'd avoid this problem for inactive projects by simply packaging the latest commit as long as it seems stable, but failing that, I see no active harm in fixing first and asking for release tags after. Okay, users might have to pacman -Syu two updates instead of one...

So, better not trying? I could do that but I don't because if there's a chance upstream will reply and that's always the better way.

> From how I'm reading this issue and the upstream issue, the "bad configuration" is "configuring lightdm to use this theme"

Huh?? "I found that user.image is null if there isn't an image", the theme fails to load when you provide an invalid image. If you provide a valid image or leave the field empty it works. This is obviously a bug but the software isn't "clearly broken". What are you trying to achieve with this comments? I think you of all people are smart enough to understand the issue after reading what was posted on github. From my POV it just looks like you're actively trying to create drama and/or you just can't admit you're wrong.

Man, I'm wrong and I'm sorry for not proving a link to the issue but this is getting crazy. What do you want me to do? Seriously, what can I do apart from apologizing and fixing the issue??

> All of this is to say that I get that there's a simple fix for the package, I simply don't understand why it is so *hard* to communicate what you're doing to fix it. Leaving a bug alone for weeks, then finally coming around and closing it without saying anything and without releasing a new version at that time,

I apologize for that, I have been busy and I forgot about this issue (I'm sorry for that, next time please bump it so that I get notified again).

> is not sterling quality communication.

Funny you saying that.

> My issue is that you didn't provide a link, and you're admitting that you should have provided a link but telling me that I'm blowing it out of proportion?

Look at your reply, doesn't it seem unnecessarily aggressive to you?
Comment by Eli Schwartz (eschwartz) - Sunday, 28 October 2018, 20:31 GMT
My apologies for misreading the upstream issue and thinking this was bigger than it is. The title was unclear, and I didn't (but should have) read further.

That being said, the bugtracker *resolution* status of "upstream" is traditionally used to mark bugs that we don't intend to fix here. To put it another way, it's a synonym for "not our bug". If you simply want to mark that the root problem is upstream but you're fixing it downstream, that's what "Category" is for, not "reason for closing".
(In this case, I'd argue that it is not an upstream bug at all -- upstream fixed it.)

Anyway, it seems less than 100% optimal to close the bug report before actually fixing it, when you could just wait a few days, leave the bug report open to remind you that it's still an issue, then close it with "fixed in lightdm-webkit-theme-archlinux x.y-z". ;)
Comment by Filipe Laíns (FFY00) - Saturday, 10 November 2018, 15:45 GMT
Matthieu, can you confirm this is working in the last release of the package?
Comment by MB (MB4E) - Saturday, 10 November 2018, 16:25 GMT
For me it's not working.

$ sudo cat /var/log/lightdm/seat0-greeter.log
file:///usr/share/lightdm-webkit/themes/archlinux/js/bootstrap.min.js:6:88: CONSOLE ERROR Error: Bootstrap's JavaScript requires jQuery
file:///usr/share/lightdm-webkit/themes/archlinux/js/greeter.js:45:2: CONSOLE ERROR ReferenceError: Can't find variable: $
file:///usr/share/lightdm-webkit/themes/archlinux/index.html:69:10: CONSOLE ERROR ReferenceError: Can't find variable: $
file:///usr/share/lightdm-webkit/themes/archlinux/index.html:325:3: CONSOLE ERROR ReferenceError: Can't find variable: $
** (lightdm-webkit2-greeter:645): WARNING **: 17:19:44.904: [ERROR] :: A problem was detected with the current theme. Falling back to default theme...
Comment by Filipe Laíns (FFY00) - Sunday, 11 November 2018, 14:19 GMT
Seems like a configuration error. Can you share your config?
Comment by MB (MB4E) - Sunday, 11 November 2018, 16:52 GMT
$ sudo cat /etc/lightdm/lightdm-webkit2-greeter.conf | grep -v ^# | grep -v ^$
[greeter]
debug_mode = true
detect_theme_errors = true
screensaver_timeout = 300
secure_mode = true
time_format = LT
time_language = auto
webkit_theme = archlinux
[branding]
background_images = /usr/share/backgrounds
logo = /usr/share/pixmaps/archlinux-logo.svg
user_image = /usr/share/pixmaps/archlinux-user.svg

$ cat /etc/lightdm/lightdm.conf | grep -v ^# | grep -v ^$
[LightDM]
run-directory=/run/lightdm
[Seat:*]
pam-service=lightdm
greeter-session=lightdm-webkit2-greeter
session-wrapper=/etc/lightdm/Xsession
greeter-setup-script=/usr/bin/numlockx on
[XDMCPServer]
[VNCServer]
Comment by Filipe Laíns (FFY00) - Sunday, 11 November 2018, 17:03 GMT
Hum, I don't see anything wrong there. Can you open an issue in the upstream?
Comment by MB (MB4E) - Sunday, 11 November 2018, 17:15 GMT
I'm not sure but error "Bootstrap's JavaScript requires jQuery" makes me think that jquery is missing.

Looking inside index.html.

$ cat /usr/share/lightdm-webkit/themes/archlinux/index.html | grep jquery
<script src="js/jquery-2.1.4.js"></script>

And this path doesn't exists.

$ ls /usr/share/lightdm-webkit/themes/archlinux/js/jquery*.js
/usr/share/lightdm-webkit/themes/archlinux/js/jquery-2.1.4.min.js

I did not try to make the change to test but ...

Loading...