Re: [new] x11/alacritty
On Thu, Aug 25, 2022 at 12:30:43AM +0200, Jeremie Courreges-Anglas wrote: > > Resurrecting this as it seems the requirements are much more reasonable > > nowadays, and I can build the latest version in 4 minutes on my Ryzen 5 > > PRO 2500U laptop: > > > > Finished release [optimized] target(s) in 4m 07s > > Now that the build time is much smaller, what about enabling it on more > architectures? The diff below would enable it on all archs, including > powerpc64 and riscv64 (should be enabled soonish). Sounds reasonable to me. OK fcambus@ > I won't argue over the usefulness of this port on said architectures > but all the rust archs have drm drivers for GPU acceleration so why not? Well, it doesn't hurt to exercise the compiler on those arches, and it ensures the used crates keep building :)
Re: [new] x11/alacritty
On Fri, Sep 03 2021, Frederic Cambus wrote:
> On Mon, Aug 12, 2019 at 07:39:23AM +0200, Theo Buehler wrote:
>> On Sun, Aug 11, 2019 at 11:30:09PM +0100, Stuart Henderson wrote:
>> > So the claimed advantage is that it's super fast, but actually it uses way
>> > more cpu than probably any other terminal emulator in the tree except
>> > cool-retro-term?
>>
>> Yes, it is blazing fast. matthieu's test of 'cat /etc/termcap' completes
>> in under 0.1s while xterm uses 0.2-0.3s. It does feel way snappier than
>> xterm in general.
>>
>> It looks like I made CPU use worse by about a factor of 2 due to using
>> vm.malloc_conf=CFJ. Still, ~5% is way more than it should need.
>>
>> Another advantage is that contrary to xterm it is trivial to configure
>> thanks to a self-documenting .yml config file.
>>
>> > Is this useful enough to be worth adding so much time to a bulk build?
>>
>> I doubt it.
>>
>> > It will likely need to be amd64-only.
>>
>> Probably. Testing on other archs would need more time than I currently
>> have.
>
> Resurrecting this as it seems the requirements are much more reasonable
> nowadays, and I can build the latest version in 4 minutes on my Ryzen 5
> PRO 2500U laptop:
>
> Finished release [optimized] target(s) in 4m 07s
Now that the build time is much smaller, what about enabling it on more
architectures? The diff below would enable it on all archs, including
powerpc64 and riscv64 (should be enabled soonish).
I won't argue over the usefulness of this port on said architectures
but all the rust archs have drm drivers for GPU acceleration so why not?
ok?
Index: .//Makefile
===
RCS file: /home/cvs/ports/x11/alacritty/Makefile,v
retrieving revision 1.6
diff -u -p -p -u -r1.6 Makefile
--- .//Makefile 11 Mar 2022 20:15:20 - 1.6
+++ .//Makefile 24 Aug 2022 22:26:13 -
@@ -1,5 +1,3 @@
-ONLY_FOR_ARCHS = amd64
-
COMMENT = cross-platform, GPU-accelerated terminal emulator
# devel/cargo MODULES adds DISTFILES, GH_* didn't
DISTFILES += ${DISTNAME}${EXTRACT_SUFX}
@@ -10,6 +8,7 @@ MAINTAINER = Eric Auge = 1.0.73 and libc >= 0.2.113
+MODCARGO_CRATES_UPDATE = cc libc
MODCARGO_RUSTFLAGS += -L${PREFIX}/lib
# Disable wayland feature. Breaks the build if libxkbcommon is absent
Index: .//crates.inc
===
RCS file: /home/cvs/ports/x11/alacritty/crates.inc,v
retrieving revision 1.3
diff -u -p -p -u -r1.3 crates.inc
--- .//crates.inc 11 Mar 2022 20:15:20 - 1.3
+++ .//crates.inc 24 Aug 2022 21:20:29 -
@@ -8,7 +8,7 @@ MODCARGO_CRATES += bitflags1.2.1 # MIT/
MODCARGO_CRATES += block 0.1.6 # MIT
MODCARGO_CRATES += bumpalo 3.9.1 # MIT/Apache-2.0
MODCARGO_CRATES += calloop 0.9.3 # MIT
-MODCARGO_CRATES += cc 1.0.72 # MIT/Apache-2.0
+MODCARGO_CRATES += cc 1.0.73 # MIT/Apache-2.0
MODCARGO_CRATES += cfg-if 0.1.10 # MIT/Apache-2.0
MODCARGO_CRATES += cfg-if 1.0.0 # MIT/Apache-2.0
MODCARGO_CRATES += cgl 0.3.2 # MIT / Apache-2.0
@@ -79,7 +79,7 @@ MODCARGO_CRATES +=khronos_api 3.1.0 # A
MODCARGO_CRATES += lazy-bytes-cast 5.0.1 # BSL-1.0
MODCARGO_CRATES += lazy_static 1.4.0 # MIT/Apache-2.0
MODCARGO_CRATES += lazycell1.3.0 # MIT/Apache-2.0
-MODCARGO_CRATES += libc0.2.112 # MIT OR Apache-2.0
+MODCARGO_CRATES += libc0.2.132 # MIT OR Apache-2.0
MODCARGO_CRATES += libloading 0.7.2 # ISC
MODCARGO_CRATES += linked-hash-map 0.5.4 # MIT/Apache-2.0
MODCARGO_CRATES += lock_api0.4.5 # Apache-2.0/MIT
Index: .//distinfo
===
RCS file: /home/cvs/ports/x11/alacritty/distinfo,v
retrieving revision 1.2
diff -u -p -p -u -r1.2 distinfo
--- .//distinfo 29 Jan 2022 12:11:51 - 1.2
+++ .//distinfo 24 Aug 2022 21:20:29 -
@@ -9,7 +9,7 @@ SHA256 (cargo/bitflags-1.2.1.tar.gz) = z
SHA256 (cargo/block-0.1.6.tar.gz) =
DYwf72kJQdPneI0yhRdZH+zGhMCECEcC1v8WQemTaZo=
SHA256 (cargo/bumpalo-3.9.1.tar.gz) =
pKRaRqsfJBLlPToK3nb/rSAlgEKUVpquOHIxoM1uCJk=
SHA256 (cargo/calloop-0.9.3.tar.gz) =
vy7sYe/laqHoE/USaVkpaTPPBwADDkMUeGxId5pmq4I=
-SHA256 (cargo/cc-1.0.72.tar.gz) = IqkTe5XqBoZOAYN1tyrft9tub2jPyN9aBNACiAUEhe4=
+SHA256 (cargo/cc-1.0.73.tar.gz) = L/8qaSezu4f5WV1nGWpwST9idoenHYeg1pIkLDP1jBE=
SHA256 (cargo/cfg-if-0.1.10.tar.gz) =
R4W90clrKoRrK9fMAuhraz2/FOflNEbE9UySo2EECCI=
SHA256 (cargo/cfg-if-1.0.0.tar.gz) =
uvHeQzl2FYi8Bhnjy8ASDuWC67dLU7Tvv3kRe9LaQP0=
SHA256 (cargo/cgl-0.3.2.tar.gz) = DO0FUSNOh6/uEkEdU1ZI3YnS5/NMeLdTOVVnr/PUR/8=
@@ -80,7 +80,7 @@ SHA256 (cargo/khronos_api-3.1.0.tar.gz)
SHA256 (cargo/lazy-bytes-cast-5.0.1.tar.gz) =
ECV0mfCJzRVq2C0KnNV9lQH6LJiQaJkql+s8J4NvIGs=
SHA256 (cargo/lazy_static-1.4.0.tar.gz) =
4qutI/vEKzcA8vJ5hE3IMq2ysusGmy35GPRVxOGMxkY=
SHA256 (cargo/lazycell-1.3.0.tar.gz) =
Re: [new] x11/alacritty
Oops, did not read carefully, thx for correcting. hth anyway, cheers, Eric. On Sat, Oct 30, 2021 at 5:24 PM Frederic Cambus wrote: > > On Tue, Oct 26, 2021 at 11:48:40AM +, Eric Auge wrote: > > diff attached, all ok? > > What sthen@ was suggesting is to add a @comment marker instead of removing > the entry for share/terminfo/a/alacritty+common. > > On top of what he mentioned, this ensures that nobody reintroduces the line > accidentally in the future when doing an update introducing a PLIST change. > > I committed the change, thanks for pointing this out Alexis!
Re: [new] x11/alacritty
On Tue, Oct 26, 2021 at 11:48:40AM +, Eric Auge wrote: > diff attached, all ok? What sthen@ was suggesting is to add a @comment marker instead of removing the entry for share/terminfo/a/alacritty+common. On top of what he mentioned, this ensures that nobody reintroduces the line accidentally in the future when doing an update introducing a PLIST change. I committed the change, thanks for pointing this out Alexis!
Re: [new] x11/alacritty
diff attached, all ok? hth, cheers, Eric. On Tue, Oct 26, 2021 at 11:03 AM Frederic Cambus wrote: > > On Sun, Oct 24, 2021 at 02:28:23PM +0200, Alexis H wrote: > > Yes, that's what I meat. > > > > Excellent suggestion, Stuart, thanks for bringing this up! > > Sounds good to me as well, please send a diff :) > > This will require a revision bump. alacritty-0.9.0p0.diff Description: Binary data
Re: [new] x11/alacritty
On Sun, Oct 24, 2021 at 02:28:23PM +0200, Alexis H wrote: > Yes, that's what I meat. > > Excellent suggestion, Stuart, thanks for bringing this up! Sounds good to me as well, please send a diff :) This will require a revision bump.
Re: [new] x11/alacritty
Yes, that's what I meat. Excellent suggestion, Stuart, thanks for bringing this up!
Re: [new] x11/alacritty
On 2021/10/24 08:32, Alexis H wrote: > Hello all, > > while inspecting the terminfo for alacritty I noticed > that the alacritty+common entry is labeled as > "base-fragment for alacritty" > (see > https://github.com/alacritty/alacritty/blob/master/extra/alacritty.info#L26) > Yet it currently gets installed to /usr/local/share/terminfo, > > Looking at other package managers I found that nixpkgs only > installs alacritty and alacritty-direct using > tic -xe alacritty,alacritty-direct -o "$terminfo/share/terminfo" > extra/alacritty.info > (see > https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/terminal-emulators/alacritty/default.nix#L124) > > It seems that this could be a worthwhile change to this port. > What do you think? > You mean stop installing the alacritty+common file? If so, it's probably better to do it subtractively rather than additively, e.g. @comment the unwanted file in the PLIST rather than using tic -e, so that if a future change to the info file results in a new entry, it will get included automatically without relying on the porter to notice the change.
Re: [new] x11/alacritty
Hello all, while inspecting the terminfo for alacritty I noticed that the alacritty+common entry is labeled as "base-fragment for alacritty" (see https://github.com/alacritty/alacritty/blob/master/extra/alacritty.info#L26) Yet it currently gets installed to /usr/local/share/terminfo, Looking at other package managers I found that nixpkgs only installs alacritty and alacritty-direct using tic -xe alacritty,alacritty-direct -o "$terminfo/share/terminfo" extra/alacritty.info (see https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/terminal-emulators/alacritty/default.nix#L124) It seems that this could be a worthwhile change to this port. What do you think?
Re: [new] x11/alacritty
Thanks for addressing the suggsted changes so quickly, Eric. I've installed alacritty from the latest tar.gz and the alacritty terminfo is now available in /usr/local/share/terminfo/a. Great patch to change the shell program to ksh in example config. ok from me
Re: [new] x11/alacritty
On 2021/10/22 18:20, Frederic Cambus wrote:
> On Fri, Oct 22, 2021 at 04:16:53PM +0100, Stuart Henderson wrote:
> > Please remove MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}, it is the default
> >
> > crates.inc is missing license info (modcargo-gen-crates-licenses)
> >
> > README underlining with === has the wrong number of chars
> >
> > ${PKGSTEM}(1) makes no sense, just use alacritty(1). Maybe "read through"
> > instead of "go through".
>
> Makes sense. Here is an updated tarball with the mentioned changes.
>
> Comments? OK?
ok
Re: [new] x11/alacritty
On Fri, Oct 22, 2021 at 04:16:53PM +0100, Stuart Henderson wrote:
> Please remove MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}, it is the default
>
> crates.inc is missing license info (modcargo-gen-crates-licenses)
>
> README underlining with === has the wrong number of chars
>
> ${PKGSTEM}(1) makes no sense, just use alacritty(1). Maybe "read through"
> instead of "go through".
Makes sense. Here is an updated tarball with the mentioned changes.
Comments? OK?
alacritty.tar.gz
Description: application/tar-gz
Re: [new] x11/alacritty
Please remove MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}, it is the default
crates.inc is missing license info (modcargo-gen-crates-licenses)
README underlining with === has the wrong number of chars
${PKGSTEM}(1) makes no sense, just use alacritty(1). Maybe "read through"
instead of "go through".
--
Sent from a phone, apologies for poor formatting.
On 22 October 2021 11:54:26 Frederic Cambus wrote:
On Mon, Oct 18, 2021 at 12:03:32PM +, Eric Auge wrote:
An update after some useful comments from a person (Alexis
Hildebrandt) off list, as diff:
+ tic -s -x -o ${PREFIX}/share/terminfo ${EXTRA_DIR}/alacritty.info
Thanks! I updated the PLIST so the generated files are installed.
Here is an updated tarball with the following changes, discussed
with tb@:
- Some pkg/README tweaks and fixes
- Patch the default shell to /bin/ksh and switch argument from --login
to -l, so users can simply uncomment those lines and get a working
configuration
- Add missing $OpenBSD$ RCS ID marker for patches
- Add missing terminfo entries in PLIST
Comments? OK to import?
Re: [new] x11/alacritty
On Mon, Oct 18, 2021 at 12:03:32PM +, Eric Auge wrote:
> An update after some useful comments from a person (Alexis
> Hildebrandt) off list, as diff:
> + tic -s -x -o ${PREFIX}/share/terminfo ${EXTRA_DIR}/alacritty.info
Thanks! I updated the PLIST so the generated files are installed.
Here is an updated tarball with the following changes, discussed
with tb@:
- Some pkg/README tweaks and fixes
- Patch the default shell to /bin/ksh and switch argument from --login
to -l, so users can simply uncomment those lines and get a working
configuration
- Add missing $OpenBSD$ RCS ID marker for patches
- Add missing terminfo entries in PLIST
Comments? OK to import?
alacritty.tar.gz
Description: application/tar-gz
Re: [new] x11/alacritty
Hello all, I'd like to show my full support for this port as it would be great to be able to install alacritty on OpenBSD using: pkg_add alacritty Thank you, Eric, for considering the feedback. I've tried the latest version of alacritty.tar.gz attached to your previous post and and installed it via: make fake; make package; make install It seems that the alacritty.info isn't properly installed, possibly to due to /usr/local/share/terminfo not existing. Best Alexis
Re: [new] x11/alacritty
Hello,
An update after some useful comments from a person (Alexis
Hildebrandt) off list, as diff:
--- alacritty/Makefile
+++ alacritty/Makefile
@@ -7,9 +7,9 @@
DISTFILES += ${DISTNAME}${EXTRACT_SUFX}
CATEGORIES = x11
-MAINTAINER = Eric Auge
+MAINTAINER = Eric Auge
-GH_ACCOUNT = jwilm
+GH_ACCOUNT = alacritty
GH_PROJECT = alacritty
GH_TAGNAME = v0.9.0
@@ -49,6 +49,7 @@
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/alacritty
${INSTALL_DATA} ${WRKSRC}/alacritty.yml \
${PREFIX}/share/examples/alacritty/alacritty.yml
+ tic -s -x -o ${PREFIX}/share/terminfo ${EXTRA_DIR}/alacritty.info
.include "crates.inc"
Please let me know if anything else should be changed.
Attached the updated package.
hth,
Cheers,
Eric.
On Sat, Oct 16, 2021 at 10:39 PM Eric Auge wrote:
>
> ping.
>
> On Sat, Sep 11, 2021 at 2:18 PM Eric Auge wrote:
> >
> > Hello,
> >
> > attached the updated the port (followed Stuart comments):
> > - made a patch for the live_config_reload default.
> > - updated DESCR and README according to comments & alacritty updated
> > self description.
> > - the xcursors-themes port does not seem necessary anymore.
> >
> > Did I miss anything?
> >
> > HTH,
> > Eric.
> >
> > On Fri, Sep 3, 2021 at 2:41 PM Stuart Henderson
> > wrote:
> > >
> > > On 2021/09/03 16:31, Frederic Cambus wrote:
> > > > On Mon, Aug 12, 2019 at 07:39:23AM +0200, Theo Buehler wrote:
> > > > > On Sun, Aug 11, 2019 at 11:30:09PM +0100, Stuart Henderson wrote:
> > > > > > So the claimed advantage is that it's super fast, but actually it
> > > > > > uses way
> > > > > > more cpu than probably any other terminal emulator in the tree
> > > > > > except
> > > > > > cool-retro-term?
> > > > >
> > > > > Yes, it is blazing fast. matthieu's test of 'cat /etc/termcap'
> > > > > completes
> > > > > in under 0.1s while xterm uses 0.2-0.3s. It does feel way snappier
> > > > > than
> > > > > xterm in general.
> > > > >
> > > > > It looks like I made CPU use worse by about a factor of 2 due to using
> > > > > vm.malloc_conf=CFJ. Still, ~5% is way more than it should need.
> > > > >
> > > > > Another advantage is that contrary to xterm it is trivial to configure
> > > > > thanks to a self-documenting .yml config file.
> > > > >
> > > > > > Is this useful enough to be worth adding so much time to a bulk
> > > > > > build?
> > > > >
> > > > > I doubt it.
> > > > >
> > > > > > It will likely need to be amd64-only.
> > > > >
> > > > > Probably. Testing on other archs would need more time than I currently
> > > > > have.
> > > >
> > > > Resurrecting this as it seems the requirements are much more reasonable
> > > > nowadays, and I can build the latest version in 4 minutes on my Ryzen 5
> > > > PRO 2500U laptop:
> > > >
> > > > Finished release [optimized] target(s) in 4m 07s
> > > >
> > > > Here is a new tarball with the following changes:
> > > >
> > > > - Update to alacritty 0.9.0
> > > > - Move MODCARGO_CRATES directives into crates.inc.
> > > > - Remove the ulimit checks, as I was able to build the port as a regular
> > > > user with the default limits without running out of memory
> > >
> > > README needs either rewriting or removing. Some of the sentences don't
> > > parse. The configuration section says what the program does but doesn't
> > > really say what the user should do with that information.
> > >
> > > There's a conflict between what DESCR says ("It provides sane choices
> > > for defaults and requires no additional setup") and README: "Although
> > > the default configuration work on OpenBSD, some values are not optimal
> > > [...] This option leads alacritty to a non negligeable CPU overhead on
> > > OpenBSD". If it's bad enough to document then I would suggest patching
> > > the default setting for live_config_reload instead. And rather than
> > > telling the user "please install pkg_add xcursors-themes port" it would
> > > be better to just RUN_DEPENDS on it. If that's done then there isn't
> > > really any more need for the pkg-readme, the standard documentation
> > > should suffice.
> > >
alacritty.tar.gz
Description: application/gzip
Re: [new] x11/alacritty
ping.
On Sat, Sep 11, 2021 at 2:18 PM Eric Auge wrote:
>
> Hello,
>
> attached the updated the port (followed Stuart comments):
> - made a patch for the live_config_reload default.
> - updated DESCR and README according to comments & alacritty updated
> self description.
> - the xcursors-themes port does not seem necessary anymore.
>
> Did I miss anything?
>
> HTH,
> Eric.
>
> On Fri, Sep 3, 2021 at 2:41 PM Stuart Henderson wrote:
> >
> > On 2021/09/03 16:31, Frederic Cambus wrote:
> > > On Mon, Aug 12, 2019 at 07:39:23AM +0200, Theo Buehler wrote:
> > > > On Sun, Aug 11, 2019 at 11:30:09PM +0100, Stuart Henderson wrote:
> > > > > So the claimed advantage is that it's super fast, but actually it
> > > > > uses way
> > > > > more cpu than probably any other terminal emulator in the tree except
> > > > > cool-retro-term?
> > > >
> > > > Yes, it is blazing fast. matthieu's test of 'cat /etc/termcap' completes
> > > > in under 0.1s while xterm uses 0.2-0.3s. It does feel way snappier than
> > > > xterm in general.
> > > >
> > > > It looks like I made CPU use worse by about a factor of 2 due to using
> > > > vm.malloc_conf=CFJ. Still, ~5% is way more than it should need.
> > > >
> > > > Another advantage is that contrary to xterm it is trivial to configure
> > > > thanks to a self-documenting .yml config file.
> > > >
> > > > > Is this useful enough to be worth adding so much time to a bulk build?
> > > >
> > > > I doubt it.
> > > >
> > > > > It will likely need to be amd64-only.
> > > >
> > > > Probably. Testing on other archs would need more time than I currently
> > > > have.
> > >
> > > Resurrecting this as it seems the requirements are much more reasonable
> > > nowadays, and I can build the latest version in 4 minutes on my Ryzen 5
> > > PRO 2500U laptop:
> > >
> > > Finished release [optimized] target(s) in 4m 07s
> > >
> > > Here is a new tarball with the following changes:
> > >
> > > - Update to alacritty 0.9.0
> > > - Move MODCARGO_CRATES directives into crates.inc.
> > > - Remove the ulimit checks, as I was able to build the port as a regular
> > > user with the default limits without running out of memory
> >
> > README needs either rewriting or removing. Some of the sentences don't
> > parse. The configuration section says what the program does but doesn't
> > really say what the user should do with that information.
> >
> > There's a conflict between what DESCR says ("It provides sane choices
> > for defaults and requires no additional setup") and README: "Although
> > the default configuration work on OpenBSD, some values are not optimal
> > [...] This option leads alacritty to a non negligeable CPU overhead on
> > OpenBSD". If it's bad enough to document then I would suggest patching
> > the default setting for live_config_reload instead. And rather than
> > telling the user "please install pkg_add xcursors-themes port" it would
> > be better to just RUN_DEPENDS on it. If that's done then there isn't
> > really any more need for the pkg-readme, the standard documentation
> > should suffice.
> >
Re: [new] x11/alacritty
Hello,
attached the updated the port (followed Stuart comments):
- made a patch for the live_config_reload default.
- updated DESCR and README according to comments & alacritty updated
self description.
- the xcursors-themes port does not seem necessary anymore.
Did I miss anything?
HTH,
Eric.
On Fri, Sep 3, 2021 at 2:41 PM Stuart Henderson wrote:
>
> On 2021/09/03 16:31, Frederic Cambus wrote:
> > On Mon, Aug 12, 2019 at 07:39:23AM +0200, Theo Buehler wrote:
> > > On Sun, Aug 11, 2019 at 11:30:09PM +0100, Stuart Henderson wrote:
> > > > So the claimed advantage is that it's super fast, but actually it uses
> > > > way
> > > > more cpu than probably any other terminal emulator in the tree except
> > > > cool-retro-term?
> > >
> > > Yes, it is blazing fast. matthieu's test of 'cat /etc/termcap' completes
> > > in under 0.1s while xterm uses 0.2-0.3s. It does feel way snappier than
> > > xterm in general.
> > >
> > > It looks like I made CPU use worse by about a factor of 2 due to using
> > > vm.malloc_conf=CFJ. Still, ~5% is way more than it should need.
> > >
> > > Another advantage is that contrary to xterm it is trivial to configure
> > > thanks to a self-documenting .yml config file.
> > >
> > > > Is this useful enough to be worth adding so much time to a bulk build?
> > >
> > > I doubt it.
> > >
> > > > It will likely need to be amd64-only.
> > >
> > > Probably. Testing on other archs would need more time than I currently
> > > have.
> >
> > Resurrecting this as it seems the requirements are much more reasonable
> > nowadays, and I can build the latest version in 4 minutes on my Ryzen 5
> > PRO 2500U laptop:
> >
> > Finished release [optimized] target(s) in 4m 07s
> >
> > Here is a new tarball with the following changes:
> >
> > - Update to alacritty 0.9.0
> > - Move MODCARGO_CRATES directives into crates.inc.
> > - Remove the ulimit checks, as I was able to build the port as a regular
> > user with the default limits without running out of memory
>
> README needs either rewriting or removing. Some of the sentences don't
> parse. The configuration section says what the program does but doesn't
> really say what the user should do with that information.
>
> There's a conflict between what DESCR says ("It provides sane choices
> for defaults and requires no additional setup") and README: "Although
> the default configuration work on OpenBSD, some values are not optimal
> [...] This option leads alacritty to a non negligeable CPU overhead on
> OpenBSD". If it's bad enough to document then I would suggest patching
> the default setting for live_config_reload instead. And rather than
> telling the user "please install pkg_add xcursors-themes port" it would
> be better to just RUN_DEPENDS on it. If that's done then there isn't
> really any more need for the pkg-readme, the standard documentation
> should suffice.
>
alacritty.tar.gz
Description: application/gzip
Re: [new] x11/alacritty
On 2021/09/03 16:31, Frederic Cambus wrote:
> On Mon, Aug 12, 2019 at 07:39:23AM +0200, Theo Buehler wrote:
> > On Sun, Aug 11, 2019 at 11:30:09PM +0100, Stuart Henderson wrote:
> > > So the claimed advantage is that it's super fast, but actually it uses way
> > > more cpu than probably any other terminal emulator in the tree except
> > > cool-retro-term?
> >
> > Yes, it is blazing fast. matthieu's test of 'cat /etc/termcap' completes
> > in under 0.1s while xterm uses 0.2-0.3s. It does feel way snappier than
> > xterm in general.
> >
> > It looks like I made CPU use worse by about a factor of 2 due to using
> > vm.malloc_conf=CFJ. Still, ~5% is way more than it should need.
> >
> > Another advantage is that contrary to xterm it is trivial to configure
> > thanks to a self-documenting .yml config file.
> >
> > > Is this useful enough to be worth adding so much time to a bulk build?
> >
> > I doubt it.
> >
> > > It will likely need to be amd64-only.
> >
> > Probably. Testing on other archs would need more time than I currently
> > have.
>
> Resurrecting this as it seems the requirements are much more reasonable
> nowadays, and I can build the latest version in 4 minutes on my Ryzen 5
> PRO 2500U laptop:
>
> Finished release [optimized] target(s) in 4m 07s
>
> Here is a new tarball with the following changes:
>
> - Update to alacritty 0.9.0
> - Move MODCARGO_CRATES directives into crates.inc.
> - Remove the ulimit checks, as I was able to build the port as a regular
> user with the default limits without running out of memory
README needs either rewriting or removing. Some of the sentences don't
parse. The configuration section says what the program does but doesn't
really say what the user should do with that information.
There's a conflict between what DESCR says ("It provides sane choices
for defaults and requires no additional setup") and README: "Although
the default configuration work on OpenBSD, some values are not optimal
[...] This option leads alacritty to a non negligeable CPU overhead on
OpenBSD". If it's bad enough to document then I would suggest patching
the default setting for live_config_reload instead. And rather than
telling the user "please install pkg_add xcursors-themes port" it would
be better to just RUN_DEPENDS on it. If that's done then there isn't
really any more need for the pkg-readme, the standard documentation
should suffice.
Re: [new] x11/alacritty
On Mon, Aug 12, 2019 at 07:39:23AM +0200, Theo Buehler wrote: > On Sun, Aug 11, 2019 at 11:30:09PM +0100, Stuart Henderson wrote: > > So the claimed advantage is that it's super fast, but actually it uses way > > more cpu than probably any other terminal emulator in the tree except > > cool-retro-term? > > Yes, it is blazing fast. matthieu's test of 'cat /etc/termcap' completes > in under 0.1s while xterm uses 0.2-0.3s. It does feel way snappier than > xterm in general. > > It looks like I made CPU use worse by about a factor of 2 due to using > vm.malloc_conf=CFJ. Still, ~5% is way more than it should need. > > Another advantage is that contrary to xterm it is trivial to configure > thanks to a self-documenting .yml config file. > > > Is this useful enough to be worth adding so much time to a bulk build? > > I doubt it. > > > It will likely need to be amd64-only. > > Probably. Testing on other archs would need more time than I currently > have. Resurrecting this as it seems the requirements are much more reasonable nowadays, and I can build the latest version in 4 minutes on my Ryzen 5 PRO 2500U laptop: Finished release [optimized] target(s) in 4m 07s Here is a new tarball with the following changes: - Update to alacritty 0.9.0 - Move MODCARGO_CRATES directives into crates.inc. - Remove the ulimit checks, as I was able to build the port as a regular user with the default limits without running out of memory alacritty.tar.gz Description: application/tar-gz
Re: [new] x11/alacritty
On Sun, Aug 11, 2019 at 11:30:09PM +0100, Stuart Henderson wrote: > So the claimed advantage is that it's super fast, but actually it uses way > more cpu than probably any other terminal emulator in the tree except > cool-retro-term? Yes, it is blazing fast. matthieu's test of 'cat /etc/termcap' completes in under 0.1s while xterm uses 0.2-0.3s. It does feel way snappier than xterm in general. It looks like I made CPU use worse by about a factor of 2 due to using vm.malloc_conf=CFJ. Still, ~5% is way more than it should need. Another advantage is that contrary to xterm it is trivial to configure thanks to a self-documenting .yml config file. > Is this useful enough to be worth adding so much time to a bulk build? I doubt it. > It will likely need to be amd64-only. Probably. Testing on other archs would need more time than I currently have.
Re: [new] x11/alacritty
On 2019/08/11 22:45, Eric Auge wrote:
> Re,
>
> attached is the updated the port:
> - added a pkg/README explaining basic config template location and how
> to disable the "lstat(2) polling" and prevent another "default config"
> CPU overhead trigger.
> - left the pre-configure target ulimit check (as I did not find how to
> do pre-fetch).
The earliest you can do such a check is pre-extract.
> - updated PLIST.
> - tested it.
>
> ok?
>
>
> On Sun, Aug 11, 2019 at 1:51 PM Eric Auge wrote:
> >
> > Hello,
> >
> > inlined.
> >
> > On Sun, Aug 11, 2019 at 11:52 AM Theo Buehler wrote:
> > >
> > > On Sun, Aug 11, 2019 at 07:05:00AM +0200, Eric Auge wrote:
> > > > Hello,
> > > >
> > > > attached is the updated port for alacritty including a "pre-configure"
> > > > target data size check taken from the lang/rust port.
> > > > ok?
> > >
> > > I would prefer the ulimit check to happen before the dependencies are
> > > downloaded, but that will need a suggestion from somebody who knows the
> > > cargo module better than me. I'm not sure the cargo module needs such a
> > > check by default, for instance, ripgrep and exa do just fine with the
> > > defaults.
> >
> > agreed, as it is my first port I was wondering and asked for advices,
> > pre-fetch target would be preferred then, correct?
> >
> > >
> > > I am not going to use this port, as it is quite CPU hungry (~10-13% when
> > > just idling at the shell prompt) and for some reason it lstats its
> > > config file more than 10 times a second.
> >
> > I am currently using it, idling at the shell prompt takes 0.5 - 1% on
> > mine (x1c5), noticed the lstat "poll" seems ugly indeed... but you can
> > disable it in the config file ("live_config_reload: false"), however
> > it seems it's the "default" behaviour.
> > I could also "pre"-tune a little bit the default behaviour in the
> > provided .yml template configuration or a package README to indicate
> > those elements?
> >
> > Another set of errors appears with "cursor themes" and you might need
> > "xcursor-themes" package (to remove the constant attempt to open a non
> > existent file), should I add it as a necessary dependancy?
> >
> > Compilation is quite heavy and long..., however I got curious of the
> > "super fast terminal" claim, I don't really know rust nor graphic
> > related code, another part is the large number of "rust" dependencies,
> > but again new to the rust "ecosystem" and testing...
> >
> > in any case, it was a good practice to experience port contributions
> > and i wanted to avoid recompilation, so binary package could be handy
> > and updating it will be easy if it improves.
> > it still does have some sporadic refreshing problems that are not
> > clearly identified ( i have to open an issue on their project ) and
> > happens only from time to time.
> >
> > I was using xterm -u8 and then rxvt-unicode (urxvtd and urxvtc) which
> > are my fallback, in case i grow unhappy of alacritty.
> >
> > I can provide an updated port attempting to mitigate those identified
> > problems, would that be ok?
> >
> > >
> > > Nevertheless, the port looks good to me now and if more experienced
> > > porters think this is ok portswise, I'm ok with importing this -- I
> > > certainly would not want to build this on a slower machine (it takes a
> > > whopping 45 minutes to build on my x280).
> > >
So the claimed advantage is that it's super fast, but actually it uses way
more cpu than probably any other terminal emulator in the tree except
cool-retro-term?
Is this useful enough to be worth adding so much time to a bulk build?
It will likely need to be amd64-only.
Re: [new] x11/alacritty
Re,
attached is the updated the port:
- added a pkg/README explaining basic config template location and how
to disable the "lstat(2) polling" and prevent another "default config"
CPU overhead trigger.
- left the pre-configure target ulimit check (as I did not find how to
do pre-fetch).
- updated PLIST.
- tested it.
ok?
On Sun, Aug 11, 2019 at 1:51 PM Eric Auge wrote:
>
> Hello,
>
> inlined.
>
> On Sun, Aug 11, 2019 at 11:52 AM Theo Buehler wrote:
> >
> > On Sun, Aug 11, 2019 at 07:05:00AM +0200, Eric Auge wrote:
> > > Hello,
> > >
> > > attached is the updated port for alacritty including a "pre-configure"
> > > target data size check taken from the lang/rust port.
> > > ok?
> >
> > I would prefer the ulimit check to happen before the dependencies are
> > downloaded, but that will need a suggestion from somebody who knows the
> > cargo module better than me. I'm not sure the cargo module needs such a
> > check by default, for instance, ripgrep and exa do just fine with the
> > defaults.
>
> agreed, as it is my first port I was wondering and asked for advices,
> pre-fetch target would be preferred then, correct?
>
> >
> > I am not going to use this port, as it is quite CPU hungry (~10-13% when
> > just idling at the shell prompt) and for some reason it lstats its
> > config file more than 10 times a second.
>
> I am currently using it, idling at the shell prompt takes 0.5 - 1% on
> mine (x1c5), noticed the lstat "poll" seems ugly indeed... but you can
> disable it in the config file ("live_config_reload: false"), however
> it seems it's the "default" behaviour.
> I could also "pre"-tune a little bit the default behaviour in the
> provided .yml template configuration or a package README to indicate
> those elements?
>
> Another set of errors appears with "cursor themes" and you might need
> "xcursor-themes" package (to remove the constant attempt to open a non
> existent file), should I add it as a necessary dependancy?
>
> Compilation is quite heavy and long..., however I got curious of the
> "super fast terminal" claim, I don't really know rust nor graphic
> related code, another part is the large number of "rust" dependencies,
> but again new to the rust "ecosystem" and testing...
>
> in any case, it was a good practice to experience port contributions
> and i wanted to avoid recompilation, so binary package could be handy
> and updating it will be easy if it improves.
> it still does have some sporadic refreshing problems that are not
> clearly identified ( i have to open an issue on their project ) and
> happens only from time to time.
>
> I was using xterm -u8 and then rxvt-unicode (urxvtd and urxvtc) which
> are my fallback, in case i grow unhappy of alacritty.
>
> I can provide an updated port attempting to mitigate those identified
> problems, would that be ok?
>
> >
> > Nevertheless, the port looks good to me now and if more experienced
> > porters think this is ok portswise, I'm ok with importing this -- I
> > certainly would not want to build this on a slower machine (it takes a
> > whopping 45 minutes to build on my x280).
> >
alacritty-2019081101.tgz
Description: Binary data
Re: [new] x11/alacritty
Hello,
inlined.
On Sun, Aug 11, 2019 at 11:52 AM Theo Buehler wrote:
>
> On Sun, Aug 11, 2019 at 07:05:00AM +0200, Eric Auge wrote:
> > Hello,
> >
> > attached is the updated port for alacritty including a "pre-configure"
> > target data size check taken from the lang/rust port.
> > ok?
>
> I would prefer the ulimit check to happen before the dependencies are
> downloaded, but that will need a suggestion from somebody who knows the
> cargo module better than me. I'm not sure the cargo module needs such a
> check by default, for instance, ripgrep and exa do just fine with the
> defaults.
agreed, as it is my first port I was wondering and asked for advices,
pre-fetch target would be preferred then, correct?
>
> I am not going to use this port, as it is quite CPU hungry (~10-13% when
> just idling at the shell prompt) and for some reason it lstats its
> config file more than 10 times a second.
I am currently using it, idling at the shell prompt takes 0.5 - 1% on
mine (x1c5), noticed the lstat "poll" seems ugly indeed... but you can
disable it in the config file ("live_config_reload: false"), however
it seems it's the "default" behaviour.
I could also "pre"-tune a little bit the default behaviour in the
provided .yml template configuration or a package README to indicate
those elements?
Another set of errors appears with "cursor themes" and you might need
"xcursor-themes" package (to remove the constant attempt to open a non
existent file), should I add it as a necessary dependancy?
Compilation is quite heavy and long..., however I got curious of the
"super fast terminal" claim, I don't really know rust nor graphic
related code, another part is the large number of "rust" dependencies,
but again new to the rust "ecosystem" and testing...
in any case, it was a good practice to experience port contributions
and i wanted to avoid recompilation, so binary package could be handy
and updating it will be easy if it improves.
it still does have some sporadic refreshing problems that are not
clearly identified ( i have to open an issue on their project ) and
happens only from time to time.
I was using xterm -u8 and then rxvt-unicode (urxvtd and urxvtc) which
are my fallback, in case i grow unhappy of alacritty.
I can provide an updated port attempting to mitigate those identified
problems, would that be ok?
>
> Nevertheless, the port looks good to me now and if more experienced
> porters think this is ok portswise, I'm ok with importing this -- I
> certainly would not want to build this on a slower machine (it takes a
> whopping 45 minutes to build on my x280).
>
Re: [new] x11/alacritty
On Sun, Aug 11, 2019 at 07:05:00AM +0200, Eric Auge wrote: > Hello, > > attached is the updated port for alacritty including a "pre-configure" > target data size check taken from the lang/rust port. > ok? I would prefer the ulimit check to happen before the dependencies are downloaded, but that will need a suggestion from somebody who knows the cargo module better than me. I'm not sure the cargo module needs such a check by default, for instance, ripgrep and exa do just fine with the defaults. I am not going to use this port, as it is quite CPU hungry (~10-13% when just idling at the shell prompt) and for some reason it lstats its config file more than 10 times a second. Nevertheless, the port looks good to me now and if more experienced porters think this is ok portswise, I'm ok with importing this -- I certainly would not want to build this on a slower machine (it takes a whopping 45 minutes to build on my x280).
Re: [new] x11/alacritty
Hello, attached is the updated port for alacritty including a "pre-configure" target data size check taken from the lang/rust port. ok? On Sat, Aug 10, 2019 at 9:14 PM Eric Auge wrote: > > Hello, > > On Sat, Aug 10, 2019 at 7:39 PM Theo Buehler wrote: > > > > On Wed, Aug 07, 2019 at 09:18:31AM +0200, Eric Auge wrote: > > > Hello, > > >=20 > > > is the updated port all ok? > > > > I could not build this with a login class staff user without bumping > > ulimit -d quite a bit (I ended up doubling it). Should there perhaps be > > a warning similar to the one in lang/rust? > > at the pre-configure target? > ok, I will send an updated port in a few after re-testing it with the > additional warning. > > > > > LLVM ERROR: out of memory > > error: Could not compile `alacritty`. > > > > I was wondering how to deal with that from the port POV in my first > reply to Brian: > ... > Additionally on OpenBSD, there is a comment on alacritty project: > "The default user limits in OpenBSD are insufficient to build > Alacritty. A datasize-cur of at least 3GB is recommended (see > login.conf)." > > How should I deal with this from the port POV? > ... > > > > Caused by: > > process didn't exit successfully: `/usr/local/bin/rustc --edition=3D2018 = > > --crate-name alacritty alacritty/src/main.rs --color never --crate-type bin= > > --emit=3Ddep-info,link -C opt-level=3D3 -C lto -C debuginfo=3D1 --cfg 'fea= > > ture=3D"default"' -C metadata=3D34165af3ffc40356 -C extra-filename=3D-34165= > > af3ffc40356 --out-dir /usr/ports/pobj/alacritty-0.3.3/build-amd64/target/re= > > lease/deps -L dependency=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/targ= > > et/release/deps --extern alacritty_terminal=3D/usr/ports/pobj/alacritty-0.3= > > =2E3/build-amd64/target/release/deps/libalacritty_terminal-c754dfeab36402eb= > > =2Erlib --extern clap=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/= > > release/deps/libclap-9637bb071988a172.rlib --extern crossbeam_channel=3D/us= > > r/ports/pobj/alacritty-0.3.3/build-amd64/target/release/deps/libcrossbeam_c= > > hannel-f53712b3a546b2cf.rlib --extern env_logger=3D/usr/ports/pobj/alacritt= > > y-0.3.3/build-amd64/target/release/deps/libenv_logger-a5dfb8ebfd133b30.rlib= > > --extern log=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/release/= > > deps/liblog-be423954d857bbd9.rlib --extern serde_yaml=3D/usr/ports/pobj/ala= > > critty-0.3.3/build-amd64/target/release/deps/libserde_yaml-022d6ddaeaf5d04e= > > =2Erlib --extern time=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/= > > release/deps/libtime-d0c34424d8a465ea.rlib --extern xdg=3D/usr/ports/pobj/a= > > lacritty-0.3.3/build-amd64/target/release/deps/libxdg-eeeb620cbb933477.rlib= > > -L/usr/X11R6/lib -L native=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/t= > > arget/release/build/libloading-26ba8eff14b79f78/out -L native=3D/usr/X11R6/= > > lib -L native=3D/usr/X11R6/lib` (signal: 6, SIGABRT: process abort signal) > > *** Error 101 in . (/usr/ports/devel/cargo/cargo.port.mk:171 'do-build': @c= > > d /usr/ports/pobj/alacritty-0.3.3/alacritty-0.3.3 && /usr/bin/env...) > > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2777 '/usr/ports= > > /pobj/alacritty-0.3.3/build-amd64/.build_done') > > *** Error 1 in /usr/ports/x11/alacritty (/usr/ports/infrastructure/mk/bsd.p= > > ort.mk:2447 'all') > > alacritty-2019081100.tgz Description: Binary data
Re: [new] x11/alacritty
Hello, On Sat, Aug 10, 2019 at 7:39 PM Theo Buehler wrote: > > On Wed, Aug 07, 2019 at 09:18:31AM +0200, Eric Auge wrote: > > Hello, > >=20 > > is the updated port all ok? > > I could not build this with a login class staff user without bumping > ulimit -d quite a bit (I ended up doubling it). Should there perhaps be > a warning similar to the one in lang/rust? at the pre-configure target? ok, I will send an updated port in a few after re-testing it with the additional warning. > > LLVM ERROR: out of memory > error: Could not compile `alacritty`. > I was wondering how to deal with that from the port POV in my first reply to Brian: ... Additionally on OpenBSD, there is a comment on alacritty project: "The default user limits in OpenBSD are insufficient to build Alacritty. A datasize-cur of at least 3GB is recommended (see login.conf)." How should I deal with this from the port POV? ... > Caused by: > process didn't exit successfully: `/usr/local/bin/rustc --edition=3D2018 = > --crate-name alacritty alacritty/src/main.rs --color never --crate-type bin= > --emit=3Ddep-info,link -C opt-level=3D3 -C lto -C debuginfo=3D1 --cfg 'fea= > ture=3D"default"' -C metadata=3D34165af3ffc40356 -C extra-filename=3D-34165= > af3ffc40356 --out-dir /usr/ports/pobj/alacritty-0.3.3/build-amd64/target/re= > lease/deps -L dependency=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/targ= > et/release/deps --extern alacritty_terminal=3D/usr/ports/pobj/alacritty-0.3= > =2E3/build-amd64/target/release/deps/libalacritty_terminal-c754dfeab36402eb= > =2Erlib --extern clap=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/= > release/deps/libclap-9637bb071988a172.rlib --extern crossbeam_channel=3D/us= > r/ports/pobj/alacritty-0.3.3/build-amd64/target/release/deps/libcrossbeam_c= > hannel-f53712b3a546b2cf.rlib --extern env_logger=3D/usr/ports/pobj/alacritt= > y-0.3.3/build-amd64/target/release/deps/libenv_logger-a5dfb8ebfd133b30.rlib= > --extern log=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/release/= > deps/liblog-be423954d857bbd9.rlib --extern serde_yaml=3D/usr/ports/pobj/ala= > critty-0.3.3/build-amd64/target/release/deps/libserde_yaml-022d6ddaeaf5d04e= > =2Erlib --extern time=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/= > release/deps/libtime-d0c34424d8a465ea.rlib --extern xdg=3D/usr/ports/pobj/a= > lacritty-0.3.3/build-amd64/target/release/deps/libxdg-eeeb620cbb933477.rlib= > -L/usr/X11R6/lib -L native=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/t= > arget/release/build/libloading-26ba8eff14b79f78/out -L native=3D/usr/X11R6/= > lib -L native=3D/usr/X11R6/lib` (signal: 6, SIGABRT: process abort signal) > *** Error 101 in . (/usr/ports/devel/cargo/cargo.port.mk:171 'do-build': @c= > d /usr/ports/pobj/alacritty-0.3.3/alacritty-0.3.3 && /usr/bin/env...) > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2777 '/usr/ports= > /pobj/alacritty-0.3.3/build-amd64/.build_done') > *** Error 1 in /usr/ports/x11/alacritty (/usr/ports/infrastructure/mk/bsd.p= > ort.mk:2447 'all') >
Re: [new] x11/alacritty
On 2019/08/10 19:33, Theo Buehler wrote: > On Wed, Aug 07, 2019 at 09:18:31AM +0200, Eric Auge wrote: > > Hello, > >=20 > > is the updated port all ok? > > I could not build this with a login class staff user without bumping > ulimit -d quite a bit (I ended up doubling it). Should there perhaps be > a warning similar to the one in lang/rust? Maybe worth adding a check to cargo.port.mk? > LLVM ERROR: out of memory > error: Could not compile `alacritty`. > > Caused by: > process didn't exit successfully: `/usr/local/bin/rustc --edition=3D2018 = > --crate-name alacritty alacritty/src/main.rs --color never --crate-type bin= > --emit=3Ddep-info,link -C opt-level=3D3 -C lto -C debuginfo=3D1 --cfg 'fea= > ture=3D"default"' -C metadata=3D34165af3ffc40356 -C extra-filename=3D-34165= > af3ffc40356 --out-dir /usr/ports/pobj/alacritty-0.3.3/build-amd64/target/re= > lease/deps -L dependency=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/targ= > et/release/deps --extern alacritty_terminal=3D/usr/ports/pobj/alacritty-0.3= > =2E3/build-amd64/target/release/deps/libalacritty_terminal-c754dfeab36402eb= > =2Erlib --extern clap=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/= > release/deps/libclap-9637bb071988a172.rlib --extern crossbeam_channel=3D/us= > r/ports/pobj/alacritty-0.3.3/build-amd64/target/release/deps/libcrossbeam_c= > hannel-f53712b3a546b2cf.rlib --extern env_logger=3D/usr/ports/pobj/alacritt= > y-0.3.3/build-amd64/target/release/deps/libenv_logger-a5dfb8ebfd133b30.rlib= > --extern log=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/release/= > deps/liblog-be423954d857bbd9.rlib --extern serde_yaml=3D/usr/ports/pobj/ala= > critty-0.3.3/build-amd64/target/release/deps/libserde_yaml-022d6ddaeaf5d04e= > =2Erlib --extern time=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/= > release/deps/libtime-d0c34424d8a465ea.rlib --extern xdg=3D/usr/ports/pobj/a= > lacritty-0.3.3/build-amd64/target/release/deps/libxdg-eeeb620cbb933477.rlib= > -L/usr/X11R6/lib -L native=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/t= > arget/release/build/libloading-26ba8eff14b79f78/out -L native=3D/usr/X11R6/= > lib -L native=3D/usr/X11R6/lib` (signal: 6, SIGABRT: process abort signal) > *** Error 101 in . (/usr/ports/devel/cargo/cargo.port.mk:171 'do-build': @c= > d /usr/ports/pobj/alacritty-0.3.3/alacritty-0.3.3 && /usr/bin/env...) > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2777 '/usr/ports= > /pobj/alacritty-0.3.3/build-amd64/.build_done') > *** Error 1 in /usr/ports/x11/alacritty (/usr/ports/infrastructure/mk/bsd.p= > ort.mk:2447 'all') >
Re: [new] x11/alacritty
On Wed, Aug 07, 2019 at 09:18:31AM +0200, Eric Auge wrote: > Hello, >=20 > is the updated port all ok? I could not build this with a login class staff user without bumping ulimit -d quite a bit (I ended up doubling it). Should there perhaps be a warning similar to the one in lang/rust? LLVM ERROR: out of memory error: Could not compile `alacritty`. Caused by: process didn't exit successfully: `/usr/local/bin/rustc --edition=3D2018 = --crate-name alacritty alacritty/src/main.rs --color never --crate-type bin= --emit=3Ddep-info,link -C opt-level=3D3 -C lto -C debuginfo=3D1 --cfg 'fea= ture=3D"default"' -C metadata=3D34165af3ffc40356 -C extra-filename=3D-34165= af3ffc40356 --out-dir /usr/ports/pobj/alacritty-0.3.3/build-amd64/target/re= lease/deps -L dependency=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/targ= et/release/deps --extern alacritty_terminal=3D/usr/ports/pobj/alacritty-0.3= =2E3/build-amd64/target/release/deps/libalacritty_terminal-c754dfeab36402eb= =2Erlib --extern clap=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/= release/deps/libclap-9637bb071988a172.rlib --extern crossbeam_channel=3D/us= r/ports/pobj/alacritty-0.3.3/build-amd64/target/release/deps/libcrossbeam_c= hannel-f53712b3a546b2cf.rlib --extern env_logger=3D/usr/ports/pobj/alacritt= y-0.3.3/build-amd64/target/release/deps/libenv_logger-a5dfb8ebfd133b30.rlib= --extern log=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/release/= deps/liblog-be423954d857bbd9.rlib --extern serde_yaml=3D/usr/ports/pobj/ala= critty-0.3.3/build-amd64/target/release/deps/libserde_yaml-022d6ddaeaf5d04e= =2Erlib --extern time=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/= release/deps/libtime-d0c34424d8a465ea.rlib --extern xdg=3D/usr/ports/pobj/a= lacritty-0.3.3/build-amd64/target/release/deps/libxdg-eeeb620cbb933477.rlib= -L/usr/X11R6/lib -L native=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/t= arget/release/build/libloading-26ba8eff14b79f78/out -L native=3D/usr/X11R6/= lib -L native=3D/usr/X11R6/lib` (signal: 6, SIGABRT: process abort signal) *** Error 101 in . (/usr/ports/devel/cargo/cargo.port.mk:171 'do-build': @c= d /usr/ports/pobj/alacritty-0.3.3/alacritty-0.3.3 && /usr/bin/env...) *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2777 '/usr/ports= /pobj/alacritty-0.3.3/build-amd64/.build_done') *** Error 1 in /usr/ports/x11/alacritty (/usr/ports/infrastructure/mk/bsd.p= ort.mk:2447 'all')
Re: [new] x11/alacritty
Hello,
is the updated port all ok?
Eric.
On Sat, Aug 3, 2019 at 3:31 PM Eric Auge wrote:
>
> On Sat, Aug 3, 2019 at 2:01 AM Brian Callahan wrote:
> >
> > Hi Eric --
> Hello Brian,
>
> answers inlined.
> >
> > On 8/1/19 1:56 PM, Eric Augé wrote:
> > > Hello,
> > >
> > > This is a new port of gpu accelerated terminal emulator written in
rust:
> > > https://github.com/jwilm/alacritty
> > >
> > > portcheck seems ok, I was not sure about adding or not the completion
> > > or how to check for the presence of zsh / fish / bash before
> > > installing those completions files.
> > >
> > > also afaik this is amd64 only, but I'm not sure how to mention that in
> > > the Makefile.
> > > please let me know if any changes are needed and if that could makes
> > > its way in ports?
> > >
> > > hth,
> > > Eric.
> >
> > Thanks for this. Alacritty was on my list. Glad I don't have to do it
now.
> >
> > Here is an updated tarball, with some necessary and convenience tweaks:
> > * Reel in excess whitespace
>
> Oops :)
>
> > * Make the list of cargo crates easier to read at a glance (wow that's a
> > long list!)
> > * Rearrange variables
> > * Sync WANTLIB
>
> Thanks, btw do we need to have USE_X11 ?
>
> > Things that are still needed:
> > * A comment to say why the do-install is needed. Is it that upstream
> > doesn't provide one?
>
> Hmm the documentation, mainly give you manual steps and generate a
> package base for debian only, even the manpage must be copied by hand,
> the Makefile provide an install target,
> but it is mainly to open the dmg on os/x, so I did not find an
> "install" as such and assumed, following is the install steps from
> the alacritty project:
>
> https://github.com/jwilm/alacritty/blob/master/INSTALL.md
>
> Additionally on OpenBSD, there is a comment on alacritty project:
> "The default user limits in OpenBSD are insufficient to build
> Alacritty. A datasize-cur of at least 3GB is recommended (see
> login.conf)."
>
> How should I deal with this from the port POV?
>
> > * Missing a MAINTAINER line. Would you like to be maintainer?
> yes, I can do that, I've added the line to the Makefile, ok?
>
> > * A better pkg/DESCR
> I mainly copied the headline from the project itself, the rest being
> kinda "marketing'y", should I put the complete project description or
> should I make a slightly modified/longer version of the short one?
> something like:
>
> "
> Alacritty is a cross platform, GPU accelerated terminal emulator with
> a strong focus on simplicity and performance.
> It provides sane choices for defaults and requires no additional
> setup. However, it does allow configuration of many aspects of the
> terminal.
> The software is considered to be at a beta level of readiness -- there
> are a few missing features and bugs to be fixed, but it is already
> used by many as a daily driver.
> "
> ok?
>
> > * `make test' is broken. It looks like there's some missing LDFLAGS on
> > -L${X11BASE}/lib
>
> I've added a MODCARGO_RUSTFLAGS described in port-modules(5) and make
> test runs ok now.
>
> >
> > ~Brian
> HTH,
> Eric.
>
> Attached is a new version of the port (integrating Stuart comments on
> crates license), ok?
Re: [new] x11/alacritty
On Sat, Aug 3, 2019 at 2:01 AM Brian Callahan wrote:
>
> Hi Eric --
Hello Brian,
answers inlined.
>
> On 8/1/19 1:56 PM, Eric Augé wrote:
> > Hello,
> >
> > This is a new port of gpu accelerated terminal emulator written in rust:
> > https://github.com/jwilm/alacritty
> >
> > portcheck seems ok, I was not sure about adding or not the completion
> > or how to check for the presence of zsh / fish / bash before
> > installing those completions files.
> >
> > also afaik this is amd64 only, but I'm not sure how to mention that in
> > the Makefile.
> > please let me know if any changes are needed and if that could makes
> > its way in ports?
> >
> > hth,
> > Eric.
>
> Thanks for this. Alacritty was on my list. Glad I don't have to do it now.
>
> Here is an updated tarball, with some necessary and convenience tweaks:
> * Reel in excess whitespace
Oops :)
> * Make the list of cargo crates easier to read at a glance (wow that's a
> long list!)
> * Rearrange variables
> * Sync WANTLIB
Thanks, btw do we need to have USE_X11 ?
> Things that are still needed:
> * A comment to say why the do-install is needed. Is it that upstream
> doesn't provide one?
Hmm the documentation, mainly give you manual steps and generate a
package base for debian only, even the manpage must be copied by hand,
the Makefile provide an install target,
but it is mainly to open the dmg on os/x, so I did not find an
"install" as such and assumed, following is the install steps from
the alacritty project:
https://github.com/jwilm/alacritty/blob/master/INSTALL.md
Additionally on OpenBSD, there is a comment on alacritty project:
"The default user limits in OpenBSD are insufficient to build
Alacritty. A datasize-cur of at least 3GB is recommended (see
login.conf)."
How should I deal with this from the port POV?
> * Missing a MAINTAINER line. Would you like to be maintainer?
yes, I can do that, I've added the line to the Makefile, ok?
> * A better pkg/DESCR
I mainly copied the headline from the project itself, the rest being
kinda "marketing'y", should I put the complete project description or
should I make a slightly modified/longer version of the short one?
something like:
"
Alacritty is a cross platform, GPU accelerated terminal emulator with
a strong focus on simplicity and performance.
It provides sane choices for defaults and requires no additional
setup. However, it does allow configuration of many aspects of the
terminal.
The software is considered to be at a beta level of readiness -- there
are a few missing features and bugs to be fixed, but it is already
used by many as a daily driver.
"
ok?
> * `make test' is broken. It looks like there's some missing LDFLAGS on
> -L${X11BASE}/lib
I've added a MODCARGO_RUSTFLAGS described in port-modules(5) and make
test runs ok now.
>
> ~Brian
HTH,
Eric.
Attached is a new version of the port (integrating Stuart comments on
crates license), ok?
alacritty.tgz
Description: Binary data
Re: [new] x11/alacritty
On 2019/08/03 14:13, Stuart Henderson wrote:
> On 2019/08/02 20:01, Brian Callahan wrote:
> > Hi Eric --
> >
> > On 8/1/19 1:56 PM, Eric Augé wrote:
> > > Hello,
> > >
> > > This is a new port of gpu accelerated terminal emulator written in rust:
> > > https://github.com/jwilm/alacritty
> > >
> > > portcheck seems ok, I was not sure about adding or not the completion
> > > or how to check for the presence of zsh / fish / bash before
> > > installing those completions files.
> > >
> > > also afaik this is amd64 only, but I'm not sure how to mention that in
> > > the Makefile.
> > > please let me know if any changes are needed and if that could makes
> > > its way in ports?
> > >
> > > hth,
> > > Eric.
> >
> > Thanks for this. Alacritty was on my list. Glad I don't have to do it now.
> >
> > Here is an updated tarball, with some necessary and convenience tweaks:
> > * Reel in excess whitespace
> > * Make the list of cargo crates easier to read at a glance (wow that's a
> > long list!)
>
> standard is to paste from "make modcargo-gen-crates-licenses" for these,
> otherwise it's hard to see what is changed in an update.
>
> > * Rearrange variables
> > * Sync WANTLIB
> >
> > Things that are still needed:
> > * A comment to say why the do-install is needed. Is it that upstream doesn't
> > provide one?
>
> i don't think a comment is needed for this ...
>
> > * Missing a MAINTAINER line. Would you like to be maintainer?
> > * A better pkg/DESCR
> > * `make test' is broken. It looks like there's some missing LDFLAGS on
> > -L${X11BASE}/lib
> >
> > ~Brian
> >
>
> ONLY_FOR_ARCHS =amd64
> COMMENT = cross-platform, [...]
>
> rust ports are so funny. sure they have files for 32 and 64-bit Windows and
> say "cross-platform" but it ends up ONLY_FOR_ARCHS=amd64 ...
>
heh, the previous submission of alacritty on ports@ said "In the process of
porting, I realized the extensive dependencies list and decided to stick
to xterm and base applications as much as possible" :-)
Re: [new] x11/alacritty
On 2019/08/02 20:01, Brian Callahan wrote:
> Hi Eric --
>
> On 8/1/19 1:56 PM, Eric Augé wrote:
> > Hello,
> >
> > This is a new port of gpu accelerated terminal emulator written in rust:
> > https://github.com/jwilm/alacritty
> >
> > portcheck seems ok, I was not sure about adding or not the completion
> > or how to check for the presence of zsh / fish / bash before
> > installing those completions files.
> >
> > also afaik this is amd64 only, but I'm not sure how to mention that in
> > the Makefile.
> > please let me know if any changes are needed and if that could makes
> > its way in ports?
> >
> > hth,
> > Eric.
>
> Thanks for this. Alacritty was on my list. Glad I don't have to do it now.
>
> Here is an updated tarball, with some necessary and convenience tweaks:
> * Reel in excess whitespace
> * Make the list of cargo crates easier to read at a glance (wow that's a
> long list!)
standard is to paste from "make modcargo-gen-crates-licenses" for these,
otherwise it's hard to see what is changed in an update.
> * Rearrange variables
> * Sync WANTLIB
>
> Things that are still needed:
> * A comment to say why the do-install is needed. Is it that upstream doesn't
> provide one?
i don't think a comment is needed for this ...
> * Missing a MAINTAINER line. Would you like to be maintainer?
> * A better pkg/DESCR
> * `make test' is broken. It looks like there's some missing LDFLAGS on
> -L${X11BASE}/lib
>
> ~Brian
>
ONLY_FOR_ARCHS =amd64
COMMENT = cross-platform, [...]
rust ports are so funny. sure they have files for 32 and 64-bit Windows and
say "cross-platform" but it ends up ONLY_FOR_ARCHS=amd64 ...
Re: [new] x11/alacritty
Hi Eric --
On 8/1/19 1:56 PM, Eric Augé wrote:
Hello,
This is a new port of gpu accelerated terminal emulator written in rust:
https://github.com/jwilm/alacritty
portcheck seems ok, I was not sure about adding or not the completion
or how to check for the presence of zsh / fish / bash before
installing those completions files.
also afaik this is amd64 only, but I'm not sure how to mention that in
the Makefile.
please let me know if any changes are needed and if that could makes
its way in ports?
hth,
Eric.
Thanks for this. Alacritty was on my list. Glad I don't have to do it now.
Here is an updated tarball, with some necessary and convenience tweaks:
* Reel in excess whitespace
* Make the list of cargo crates easier to read at a glance (wow that's a
long list!)
* Rearrange variables
* Sync WANTLIB
Things that are still needed:
* A comment to say why the do-install is needed. Is it that upstream
doesn't provide one?
* Missing a MAINTAINER line. Would you like to be maintainer?
* A better pkg/DESCR
* `make test' is broken. It looks like there's some missing LDFLAGS on
-L${X11BASE}/lib
~Brian
alacritty.tgz
Description: application/compressed-tar
[new] x11/alacritty
Hello, This is a new port of gpu accelerated terminal emulator written in rust: https://github.com/jwilm/alacritty portcheck seems ok, I was not sure about adding or not the completion or how to check for the presence of zsh / fish / bash before installing those completions files. also afaik this is amd64 only, but I'm not sure how to mention that in the Makefile. please let me know if any changes are needed and if that could makes its way in ports? hth, Eric. alacritty.port.tgz Description: Binary data
