Kitty terminal new package, symlink problem

2024-05-22 Thread Lucy Coleclough

Hi Edison Ibáñez if you see this,
I am unsure if my reply on debuggs was sent, i am yet to get a email 
address that supports git send-email,
It seems that go embed does not support symlinks and in the kitty build 
dir, "/src/github.com/alecthomas/chroma/v2/**" the embed-ed files are 
symlinks to the chroma store directory.


https://pkg.go.dev/embed
"Patterns must not match files outside the package's module, such as 
‘.git/*’ or symbolic links. Patterns must not match files whose names 
include the special punctuation characters " * < > ? ` ' | / \ and :. 
Matches for empty directories are ignored. After that, each pattern in a 
//go:embed line must match at least one file or non-empty directory. "


I was just looking at what is the process which creates the link, it is 
possibly line 232 ( in my checkout) of guix/build/go-build-system

```
  (let ((dest (string-append (getenv "GOPATH") "/src/" unpack-path)))
    (mkdir-p dest)
    (if (file-is-directory? source)
    (copy-recursively source dest #:keep-mtime? #t)
    (unpack-maybe-strip source dest)))

```
there is not a symlink function call, i think build systems are 
inherited so maybe it is in a containing build system.


Im going out now but this seems to be the cause of the failure.

Also if anyone sees this and has an invite to riseup email service ( 
should the service be capable of handling another stranger) then please 
may i have a invite?, google sux

Thanks!


Re: Packaging Hyprland

2024-02-24 Thread Lucy Coleclough
Hey there, have been working on hyprland recently,
I have got plugins working in my hyprland service,
Each plugin can be built to a shared object and then referenced in the
config
plugins:
https://gitlab.com/lucyCole/GuixChannel/-/blob/main/lucyChannel/packages/hyprlandPlugins.scm?ref_type=heads
service:
https://gitlab.com/lucyCole/GuixConfig/-/blob/main/variationAndSource/existingSystemOperation/home/services/temporary.scm?ref_type=heads#L278

I also made a tomlplusplus package and submitted it to the rosenthal repo
but yh could probably just go in guix
https://github.com/rakino/Rosenthal/pull/13/files#diff-43c57fc1a44f0d3b5b7642f365df293ffada6ebe4e756ac1ce08ba849f38e361R155

On Sat, 24 Feb 2024 at 20:48, hutzdog  wrote:

> Hi all,
>
> I've been working on moving over to GNU Guix recently, and have hit a
> roadblock: there is no package for Hyprland (the one WLRoots based
> compositor with single window capture and automatic window swallowing that
> I know of). I've taken the liberty of packaging the latest version (see
> https://git.sr.ht/~hutzdog/patchwork/tree/master/item/patchwork/packages/desktop.scm
> for the package), but there are some changes that need to happen in order
> for it to be upstreamed (as of v0.35.0).
>
> # Pending Patches
> The following existing patches need to be merged:
> LibInput -> 1.25.0 (https://issues.guix.gnu.org/68844)
> LibDRM -> 2.4.120 (https://issues.guix.gnu.org/68845)
>
> # New Patches
> The following new patches will need to be created (I intend to submit
> these at some point in the near future):
> Cairo -> 1.18.0 (requires moving to Meson, I have a mostly complete set of
> changes to make it work)
> Toml++ (package will be sent as a patch soon)
> Hyprlang (for xdg-desktop-portal-hyprland, will publish after Hyprland)
>
> ## HWData
> As with packages using the release versions of WLRoots, due to how Guix
> packages HWData a patch is needed to make Meson find it. We have a few
> options: maintain a parallel package which simply farms all outputs of
> HWData as symlinks and adds the pkg-config file, maintain a patch on a much
> more volatile version of WLRoots, or find some other solution.
>
> # Hyprland
> This will allow me to submit packages for Hyprland and its XDG Desktop
> Portal at version 0.35.0 (the latest release). As it's one of the more
> popular Wayland compositors out there, I think it is worth adding it to the
> repos. For now, the package is available through my Guix channel (fair
> warning, it is still very WIP and I wouldn't recommend using it yet outside
> of maybe pulling the Hyprland packages). I look forward to working with
> Guix (Scheme is certainly a breath of fresh air after dealing with Nix for
> a while) and contributing to its ecosystem.
>
> --Hutzdog


Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

2023-10-09 Thread Lucy Coleclough
To counter this point:
> But the present organisation looks defunct. There’s no strong leadership.
A lack of central-ised leadership is a good thing
If this is their only reason for calling the organisation defunct then this
point is invalid however I am unsure if this is where the critique lies

In that spirit i am pondering how something akin to central leadership
mandating such a change occur in this environment.
The biggest concern I can think of about doing something like this and
degrading existing workflows would be alienating developers who prefer the
existing methods and perhaps had a hand in making them what they are
currently.
A lot of people in a company would likely grumble about such a mandate as a
way of getting over it.
I guess here some examples:
- consensus could be tried for in a formal polling process and it be worked
on post consensus
- one could also do the work and propose it then to dispell any concerns of
achievability but at the risk of it not being used
- one could also try building an approach in which the project would
gradually fade into a state where both options are viable, and then
perhaps, should consensus be reached then, the project could fade into a
state with solely the changed tooling
example stages:
- current tooling
- git repo-s mirrored, chat channel-s bridged
- facilitate project interaction on new git hosting method (
issues, mr-s, ...)
- fade towards solely using the consensus desired tooling

I think consensus is more suitable to large decisions than voting when
maintenance of the group boundary ( guix devs) and maintenance of the
number of states ( a set of tooling with only one tool per use case (
savannah or gitlab, matrix or irc, ...)) is desired
an issue like this could cause a split and sometimes that is ok
but when that is undesirable, if the one resulting state is formed then a
continuous discussion process to form this one state into something which
has the least cummulative "friction" is desirable.
whilst this may be slower initially than a top down mandate, those adapting
to a top down mandate would have to adjust from what they are most
comfortable causing slow down in the future
page 154 of this document presents a diagramatic representaion of a
consensus process:
https://www.radicalroutes.org.uk/wp-content/uploads/woocommerce_uploads/2022/10/How2WorkersCo-op2019A5Lo-Res-pslouz.pdf

In defence of meta discussion, i think meta discussion is really just
discussion where an assumed component is brought back into discussion.

I am new to the project as well, in my experience I have found the mailing
lists to be quite fun, i havent submitted any patches to guix yet so i can
not comment on that
perhaps an alternative could be mailing list propaganda to garner the
excitement that currently surrounds something like discord
one trend i have seen with guix is the tendency to use existing technology
with extensions to achieve ones means instead of using/ developing a
technology which includes all desired features as standard, maybe this is a
function of the older style
the irc and mailing lists are both publically logged and the system-s seem
cohesive
the logs on irc are harder to read than scrolling up in something like
matrix, also the lack of non-text media can be tricky

On Mon, 9 Oct 2023 at 11:29, Tao Hansen  wrote:

>
> Hello, I hope it's ok I'm replying to this email as a follow-up to
> decreasing the cognitive overhead for new users. I'm also brand new to
> the Guix community and ecosystem. I wanted to share a perspective from a
> user on a Lemmy instance who wrote why the Guix ecosystem was not
> friendly enough to meet them where they were, a person in their early
> twenties. I'd like to suggest approach their criticism with compassion
> and open-mindedness.
>
> @velox_vulnus writes at https://lemmy.ml/comment/4625080
>
> > I don’t like the vibe of ageism against young people that is
> > associated with GNU. What is also frustrating is their reluctance to
> > improve their infrastructure.
>
> > This reason is kind of terrible, I admit, but they could choose to
> > move over to Matrix over IRC, but they choose to be willingly open to
> > spam over having a proper, documented chat channel. I am also
> > reluctant to use my personal mail, for the mailing list. Matrix gives
> > me that anonymity, without also having to geopardize on participation.
> > NixOS is on Matrix, and that’s why I like it. I know Matrix isn’t
> > perfect, but it the better choice between any other messenger.
>
> This user could use an email address dedicated to Guix discussion but
> really I can only agree that sticking to IRC, which requires a lot of
> effort to keep a history log and more effort to host a bouncer makes
> contributing to synchronous discussions difficult. I, myself, am only
> active on the community-run Matrix server and another, less free,
> channel because the overhead is just too high.
>
> > They could choose to remove