Package Details: zettlr 1.8.9-1

Git Clone URL: https://aur.archlinux.org/zettlr.git (read-only, click to copy)
Package Base: zettlr
Description: A markdown editor for writing academic texts and taking notes
Upstream URL: https://www.zettlr.com
Licenses: GPL, custom
Submitter: BrLi
Maintainer: BrLi (caleb)
Last Packager: BrLi
Votes: 11
Popularity: 0.39
First Submitted: 2019-06-17 04:47
Last Updated: 2021-05-23 18:41

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

languitar commented on 2020-11-30 14:35

Just to add a tiny bit to the frustration...

Some translations do not validate after the package upgrade:

==> Validating source files with sha256sums...
    Zettlr ... Skipped
    fix-lang-search-path.patch ... Passed
    master.zip ... Passed
    chicago-author-date.csl ... Passed
    zh-TW.json ... Passed
    de-DE.json ... FAILED
    en-GB.json ... FAILED
    en-US.json ... FAILED
    fr-FR.json ... Passed
    ja-JP.json ... Passed
    zh-CN.json ... Passed
    es-ES.json ... Passed
    ru-RU.json ... Passed

caleb commented on 2020-11-28 08:56

@BrLi I well understand the frustration with Electron and the whole app ecosystem surrounding it. I think its a disastrous garbage heap and a crazy way to build desktop GUI apps.

That being said I've offered to help co-maintain this package before and the offer is still open. You don't have to give up a weekend for this—accepting help from co-maintainers is one way to limit the stress of updates coming down when you aren't ready to sit down and fight with them.

BrLi commented on 2020-11-28 07:35

F the world that it costs me the weekends to just update it to next version...

F the electron eco system, F the nodejs/npm whatsoever package managements.

Is it just so wild a wish not to recompile the whole electron/chromium binary in order to just make a functional GUI?

Is it just so hard for the eco system not to re-invent shxts and apply them without test.

For the record, electron-forge on AUR failed to build, webpack and webpack-cli on AUR are poor-written consider the PKGBUILD.

electron-forge upstream is utilizing unlisted executable in their package.json, namely, bolt.

zettlr itself depends on beta release of packaging tool, the electron-forge 6.0.0-beta-54.

the electron-forge doesn't have stop point during making the chromium binary.

and it doesn't even have default recognition to output to dir under linux.

I'm so regret but this PKGBUILD is what I can do to the limit for now, to just fetch a bunch of shxt and lift them down to have the slightest drop, which just works with system electron without needed to install another shxt.

Mainframed commented on 2020-10-14 00:09

Electron version 10 broke the app for me (white screen). Should change dependency to electron9, until the bug is fixed. Issue: https://github.com/Zettlr/Zettlr/issues/858

But this was not enough. I had to remove the electron package and symlink electron9 to electron (both in /usr/lib and /usr/bin). Would appreciate better solution suggestions.

BrLi commented on 2020-07-06 17:47

@eschwartz, I've then revamped the pkgbuild for shell sack, though I'd still hold the opinion that a lot of pkgbuild from official repo are also not that rigorous either. TBH, it is laziness causing me to use tag instead of commit, for that I don't have to really c/p the hash from github to update the pkgbuild when out-of-date alarmed.

@adubray, sorry for the inconvenience, it seems to be a bug upstream, I've fixed it in 1.6.0-3, and this is fixed upstream since 1.7.0, so should not be a problem anymore.

adubray commented on 2020-06-02 11:56

Hi, After a fresh install of the package I had troubles running the application. More precisely, at the start of the application (via the command zettlr) it can not find icons/png/64x64.png.

I see that the icons are installed under /usr/share/icons/hicolor/PXxPX/apps/zettlr.png (for different PX) but in the config of zettlr (/lib/zettlr/main/zettlr-window.js, the winConf variable), it does not look at the right directory.

Should it be fixed in the PKGBUILD?

eschwartz commented on 2020-03-12 14:14

@BrLi,

1) The advantage of git over tarballs is that when building the same package again and again, each update is fairly small. The disadvantage is that an uncached download over git is 84M and with a tarball it is 30M. I'm not going to claim either one is fundamentally better, though. Note you can still use checksumming over git, by pinning to a #commit= instead of a tag, and manually updating the commit as well as the pkgver every time a new release comes out. checksumming can provide TOFU as well.

2) shellcheck is indeed lossy, but the srcdir and pkgdir variables, at least, must be quoted as they can and will contain spaces. $pkgname and $pkgver do not need to be quoted, since they cannot contain spaces (and makepkg will immediately abort with a fatal error if they do).

It's strange that before you fixed the quoting, you had quoted "$px"x"$px".png which does not need quoting since they are hardcoded integers without spaces, and failed to quote the $srcdir variable... I'd actually recommend removing the quotes on "$px" and "$pkgname" there since the more you enter and leave a quoting context, the harder it becomes to read. Either quote the entire string, or only quote the "$srcdir"/ part, either one is valid shell and equally readable.

BrLi commented on 2020-03-08 02:01

Hi, @caleb, thanks for the input.

I'd explain some below why I'm writting script in this way:

  1. the git source instead of tarball: it isn't unstable just because I'm fetching source from git, there are plenty of packages in official repos doing so, so I see it fine. And tbh, even using tarball, I'm just updpkgsums on every version pump, which is equivalently insecure to not check sum. btw git source is a better way when dealing with remote CI packaging.

  2. the quoting, well...it is...well...let me just say that the PKGBUILD can be really lossy, I could certainly update it to a way that passes shellcheck, but who cares?

  3. the usage of /dev/stdin <<: this is used in official firefox packages, and I find it brilliant as it stuff infos in whole one PKGBUILD instead of where ppl have to look around to gather what is changed by go through all the source files included in git tree.

  4. gendesk and node-prune: the concept is to avoid too many out of official repo dependencies when it comes to AUR package, especially when they are not runtime requirements, thus, I might add node-prune as it sees its seat in [community] but not now. gendesk on the other hand, is not handy I must say, I've tried it for a few times, but the outcome is less pleasant than manually written desktop file.

  5. thanks for the catch up of 512 px icon. Besides, since it is the same as logo, I see no reason to include another file to /usr/share/pixmaps, as the org.freedesktop standards work with icons under /usr/share/icons/ directly.

  6. the sed lines: it is just a matter of taste.

caleb commented on 2020-03-07 08:55

@BrLi I've done a major overhaul of the PKGBUILD to address a number of issues including packaging things you missed that are new in 1.6.0, but also fixing the issue with the source, a lot of shell quoting issues, etc. You can see the result in my fork here. Please at least add that as a remote and then cherry pick this commit into your branch. You can also add me as a co-maintainer and I'll push it directly and help keep this updated.

caleb commented on 2020-03-07 06:54

Please build this from a tar archive rather than a git tag, this is not a -git package and should have a checksumed download.

I can help fix this up if you add me as a co-maintainer.