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
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
|
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.
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.
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!
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.
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.
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?
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?
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". ;)
$ 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...
[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]
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 ...