Package Details: pulsar-bin 1.122.0-1

Git Clone URL: https://aur.archlinux.org/pulsar-bin.git (read-only, click to copy)
Package Base: pulsar-bin
Description: A community-led hyper-hackable text editor, built on electron
Upstream URL: https://github.com/pulsar-edit/pulsar
Keywords: atom editor pulsar
Licenses: MIT
Conflicts: pulsar
Provides: pulsar
Submitter: jonian
Maintainer: jonian
Last Packager: jonian
Votes: 30
Popularity: 0.075501
First Submitted: 2022-11-07 13:13 (UTC)
Last Updated: 2024-10-20 15:14 (UTC)

Dependencies (5)

Required by (0)

Sources (1)

Latest Comments

1 2 3 Next › Last »

AlexWayfer commented on 2024-09-21 15:46 (UTC)

Is it still normal? More warnings and errors:

==> Making package: pulsar-bin 1.121.0-1 (Sat 21 Sep 2024 18:36:10 MSK)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Entering fakeroot environment...
==> Starting package()...
==> Tidying install...
  -> Removing libtool files...
  -> Purging unwanted files...
  -> Removing static library files...
  -> Stripping unneeded symbols from binaries and libraries...
libfakeroot internal error: payload not recognized!
objcopy: ./opt/Pulsar/libEGL.so: debuglink section already exists
objcopy: ./opt/Pulsar/libGLESv2.so: debuglink section already exists
libfakeroot internal error: payload not recognized!
objcopy: ./opt/Pulsar/libffmpeg.so: debuglink section already exists
objcopy: ./opt/Pulsar/libvk_swiftshader.so: debuglink section already exists
objcopy: ./opt/Pulsar/pulsar: debuglink section already exists
libfakeroot internal error: payload not recognized!
objcopy: ./opt/Pulsar/resources/app.asar.unpacked/node_modules/symbol-provider-ctags/vendor/ctags-linux: debuglink section already exists
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
libfakeroot internal error: payload not recognized!
objcopy: ./opt/Pulsar/swiftshader/libEGL.so: debuglink section already exists
objcopy: ./opt/Pulsar/swiftshader/libGLESv2.so: debuglink section already exists
  -> Compressing man and info pages...
==> Checking for packaging issues...
==> Creating package "pulsar-bin"...

jonian commented on 2024-09-18 18:55 (UTC)

@shoryuken no worries :) unfortunately the tag is not enough because it does not have the pre-built binaries.

shoryuken commented on 2024-09-18 18:50 (UTC)

Oops, sorry, I thought the tag was enough :)

jonian commented on 2024-09-18 18:46 (UTC)

@shoryuken please don't flag the package out of date when there is no new version.

shoryuken commented on 2024-06-17 09:57 (UTC) (edited on 2024-06-17 09:58 (UTC) by shoryuken)

The build takes far too long due to the deletion/copying of debug symbols in my opinion, so to speak, it defeats the original purpose of packaging a binary to save time. You may not want to do this upstream, but personally I've added this to PKGBUILD locally:

options+=('!debug' '!strip')

AlexWayfer commented on 2024-02-16 18:39 (UTC)

Is it okay to see these messages by objcopy?

==> Making package: pulsar-bin 1.114.0-1 (Fri 16 Feb 2024 21:29:10 MSK)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Entering fakeroot environment...
==> Starting package()...
==> Tidying install...
  -> Removing libtool files...
  -> Purging unwanted files...
  -> Removing static library files...
  -> Stripping unneeded symbols from binaries and libraries...
objcopy: ./opt/Pulsar/libEGL.so: debuglink section already exists
objcopy: ./opt/Pulsar/libGLESv2.so: debuglink section already exists
objcopy: ./opt/Pulsar/libffmpeg.so: debuglink section already exists
objcopy: ./opt/Pulsar/libvk_swiftshader.so: debuglink section already exists
objcopy: ./opt/Pulsar/pulsar: debuglink section already exists
objcopy: ./opt/Pulsar/resources/app.asar.unpacked/node_modules/symbol-provider-ctags/vendor/ctags-linux: debuglink section already exists
objcopy: ./opt/Pulsar/swiftshader/libEGL.so: debuglink section already exists
objcopy: ./opt/Pulsar/swiftshader/libGLESv2.so: debuglink section already exists
  -> Compressing man and info pages...
==> Checking for packaging issues...
==> Creating package "pulsar-bin"...
  -> Generating .PKGINFO file...
  -> Generating .BUILDINFO file...
  -> Generating .MTREE file...
  -> Compressing package...

jonian commented on 2024-01-17 11:00 (UTC)

@impulse Updated to 1.113.0 and added you as a co-maintainer. Thanks for offering to help!

alerque commented on 2024-01-16 18:59 (UTC)

@impulse Creating a new package for something that has been out of date a few hours is absolutely not appropriate and against the AUR rules. Please don't do that. You can bump and build this yourself locally if you can't wait for the maintainer.

impulse commented on 2024-01-16 17:09 (UTC)

May i co-maintain this package? ive made a pulsar-new-bin package in the meantime which is up-to-date. But would be nice if i could help maintain this version.

alerque commented on 2023-12-19 08:18 (UTC)

22 is currently not even a good option since it is EOL and will be dropped as soon as feasible. By the time Pulsar adapts I expect another version or two will be EOL as well. But I do actually kind of expect them to jump all the way to a current version at some point. We'll see I guess.

And yes pings don't work here. I do have notifications turned on but may miss that. You can ping me on other channels like GitHub or the Arch bug tracker or IRC or whatever if I don't catch it when this becomes viable to package. Since I'm following upstream progress I'll probably notice myself.

1 2 3 Next › Last »