Re: emacs-jedi package bug missing crucial python server file

[jgart]

On Wed, 22 Jun 2022 12:14:10 +0300 Munyoki Kilyungi  
wrote:
> but do you have all your Emacs configs in Guix?  

I get my emacs plugin dependencies with guix but I write my config in elisp:

https://git.sr.ht/~whereiseveryone/jgart-dots/tree/master/item/dot_emacs

Not sure how I feel yet about quoting elisp code in guile code. On first
thought it seems like a nice party trick but not as nice to work with
in the day to day when you just need to get the elisp code to work and
to extend emacs. If I could write guile directly to confgure emacs that
would be simpler, I think. Also, one less level of abstracting if you
need to debug the elisp code quoted in your guile code but maybe there
is a way around that?...

The above emacs config is bound to change. It's just what I'm using on this
particular thinkpad that I'm writing this email from at the moment. Mind
the funny spacing of the code. That said, I'm hoping to keep my .emacs
to a minimum number of lines for now. Just exploring that for now and
really milking `execute-extended-command` for all it's worth, which I
have bound to space d, btw.

Emacs packages to note in the above config:

https://codeberg.org/akib/emacs-corfu-terminal
https://codeberg.org/akib/emacs-corfu-doc-terminal

```
$ guix install emacs-corfu-terminal emacs-corfu-doc-terminal
```

I'm mostly using emacs-no-x (terminal only).

I'm not using guix-home yet. It fails to build my config on void linux
with some arcane error I haven't had the time to properly debug yet/get
help with ;)

> Also, how does your python set-up look like in Guix/Emacs?

I mostly have been using eglot without any configuration. I just run
M-x eglot and use it with python-lsp-server or jedi-language-server.

I haven't explored the emacs-jedi package much that I sent an update for in
this thread ;) It's on my TODO list.

If you want to read my favourite guix-home managed config out in the wild
that I've found, I highly recommend unmatched-parens' config:

https://git.sr.ht/~unmatched-paren/conf

I appreciate the minimalism and simplicity of the way paren has set up
their dots with guix-home. It's very clear how to copy it and take it
for your own purposes.

happy hacking,

jgart

https://whereis.みんな/

Wiki && Re: [feature request] merge sxml->html from (haunt html) into guile?

[Nathan Dehnel]

>I have some free time for the next month, and should be able to knock out a 
>basic wiki system in this time (I found what looks like a nice book about 
>wikis that I could read and use as a guide for implementing it).

Sounds interesting, what's the name of the book?

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

[Maxime Devos]

Small clarification to old discussion:

Hello,

Ludovic Courtès  writes:

> Hi!
>
> Maxime Devos  skribis:
>
>> Ludovic Courtès schreef op vr 01-04-2022 om 10:58 [+0200]:
>>> As a first milestone, maybe we could start running ‘autoreconf’
more
>>> often, for packages higher in the graph.  We could change the
>>> ‘bootstrap’ build phase to do that unless it’s explicitly turned
off.
>>> It may turn out to be a Sisyphean task though…
>>>
>>> Thoughts?
>>
>> Changing all pre-existing packages, maybe.  But doing this for new
>> packages (reducing review effort) and perhaps when a package is
updated
>> (for purity) should be feasible I think?  Then gradually things
would
>> improve and eventually(TM) doing the switch in the bootstrap phase
may
>> become feasible ...
>
> Yes, we could do that as a first step (in fact it’s already happening
as
> some projects no longer distribute tarballs).
>
> What do maintainers think of that policy?

No strong opinion, but I agree that having a complete development
environment capable of building from the bare sources (e.g. a git tree)
is useful in general.  On the other hand, using tarballs is often
more efficient and practical (it's made to be built by downstream
users,
rather than by developers, so it includes everything needed).  Release
tarballs are also often signed by the projects, which is neat.  So
perhaps we can leave some flexibility there and not make it a hard
rule, but a case of best judgment?

We can both use tarballs _and_ unbundle/regenerate, no need to switch
from tarball to git (though that's one way to do things)!  E.g., adjust
the bootstrap phase to always "autoreconf -vif" and/or add snippets or
post-unpack phases to remove generated or bundled Autotools files.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Why is greetd greeter user in so many groups?

[kiasoc5]

Hi Lars,

On Wed, Jun 29 2022, 09:41:51 AM +0200
Lars-Dominik Braun  wrote:

> indeed, agreety works fine with that patch. I’d still keep the video
> supplementary group, so one can run gtkgreet/wlgreet (if they ever pop
> up in Guix). Any objections?

Sounds good, thanks for the fix!

Re: emacs-jedi package bug missing crucial python server file

[Luis Felipe]

Hi Maxime,


On Friday, June 24th, 2022 at 04:03, Maxim Cournoyer 
 wrote:

> Hi,
> 

> Luis Felipe luis.felipe...@protonmail.com writes:
> 

> > Hi jgart
> > 

> > On Wednesday, June 22nd, 2022 at 03:59, jgart jg...@dismail.de wrote:
> > 

> > > Hi Guixers,
> > 

> > > Just wanted to report a bug with emacs-jedi:
> 

> 

> [...]
> 

> > > I'll try to work on it when I get a chance but feel free to fix it if you 
> > > have the time.
> > 

> > > all best,
> > 

> > Oh, thanks, so this is why I lost Python completion after updgrading
> > my profile... I'm too busy too to try to fix it though...
> 

> 

> It's already been fixed with 299be00adb427441c0cb7d301bf918594f61400e.

I haven't been able to try it out yet because of time and lack of substitutes 
to upgrade my whole profile, but thank you very much for fixing it :)


publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Missing tags in Debbugs?

[Bengt Richter]

On +2022-06-29 09:29:20 +0200, zimoun wrote:
> Hi,
> 
> Thanks for the feed back
> 
> On Wed, 29 Jun 2022 at 08:07, b...@bokr.com wrote:
> 
> > Anyway, the idea is to make the Subject: line greppable for both
> > what the bug is about and its status when it was closed.
> 
> I agree that it is hard to work with the Debbugs archive.  What you are
> asking seems possible with Debbugs but the GNU instance is not
> supporting many tags [1].  Using the ’Subject:’ line as tagging system
> could be a workaround but I am not convinced the ratio effort /
> usefulness is worth because it is too error-prone, IMHO.
> 
> Arun has presented nice ideas about improving Mumi and it appears to me
> the direction to go.
> 
> 
> 1: 

Thanks, that LGTM: Looks like easy-to-parse html :)

This looks interesting too, that I just found:

2: 

Will have to try it. Maybe emacs already has a mode for that?
(I need to refresh my emacs-fu ;/ )
> 
> 
> Cheers,
> simon
--
Regards,
Bengt Richter

Re: Non-free data in Poppler test suite

[zimoun]

Hi Marius,

On Tue, 28 Jun 2022 at 23:19, Marius Bakke  wrote:

> I discovered a potential freedom issue with the Poppler test suite.
> Specifically it includes a file with the CC BY-NC-ND (non-commercial)
> license:

BY-NC-ND in short:

This license allows reusers to copy and distribute the material
in any medium or format in unadapted form only, for
noncommercial purposes only, and only so long as attribution is
given to the creator.


>   
> https://gitlab.freedesktop.org/poppler/test/-/commit/920c89f8f43bdfe8966c8e397e7f67f5302e9435

And the PDF provided by this commit is the extraction of page 8 from

https://arxiv.org/pdf/2204.06128.pdf

which is a document of 21 pages.  Therefore, is this distribution of an
extracted derivative allowed by BY-NC-ND in the first place?

Maybe it seems worth to ask to Poppler devs their opinion.


Cheers,
simon

PS: I recommend the reading of https://arxiv.org/pdf/2204.06128.pdf :-)

Re: Why is greetd greeter user in so many groups?

[Lars-Dominik Braun]

Hi,

> Since greetd is currently being run as root, it doesn't need any 
> extra group membership.
indeed, agreety works fine with that patch. I’d still keep the video
supplementary group, so one can run gtkgreet/wlgreet (if they ever pop
up in Guix). Any objections?

Cheers,
Lars

Missing tags in Debbugs?

[zimoun]

Hi,

Thanks for the feed back

On Wed, 29 Jun 2022 at 08:07, b...@bokr.com wrote:

> Anyway, the idea is to make the Subject: line greppable for both
> what the bug is about and its status when it was closed.

I agree that it is hard to work with the Debbugs archive.  What you are
asking seems possible with Debbugs but the GNU instance is not
supporting many tags [1].  Using the ’Subject:’ line as tagging system
could be a workaround but I am not convinced the ratio effort /
usefulness is worth because it is too error-prone, IMHO.

Arun has presented nice ideas about improving Mumi and it appears to me
the direction to go.


1: 


Cheers,
simon

Re: Wiki && Re: [feature request] merge sxml->html from (haunt html) into guile?

[Dr. Arne Babenhauserheide]

Maxime Devos  writes:

> Blake Shaw schreef op wo 29-06-2022 om 01:34 [+0700]:
>> Which brings up another thing I've been considering working on thats
>> been discussed in the Guix community: the need for click-to-edit
>> wiki, written in Guile. [...]
>
> I don't think ‘written in Guile’ has been discussed?
>
> Also, I don't see the point in writing our own wiki software in Guile
> when there's already plenty of Wiki software in existence with lots of
> tools for moderation, version control, backups, lots of testing, etc.
> Why not reuse pre-existing work instead of reinventing the wheel (likely
> poorly, at least at first)?

There are at least two good reason for re-inventing the wheel:

- learning the domain
- experimenting with how the ways to a good implementation differ in another 
language

If those were rejected out of hand, most existing wiki software would
have never been written.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: Dealing with upstream issues

[bokr]

Hi zimoun, et al,

On +2022-06-28 18:25:05 +0200, zimoun wrote:
> Hi,
> 
> On Tue, 28 Jun 2022 at 14:31, Maxime Devos  wrote:
> 
> > You often close bugs with as rationale: ‘no response since X months,
> > hence closing’, so it seems to me that you would simply close bug
> > reports if the bug reporter is gone.
> 
> [...]
> 
> > That's the issue I wanted to highlight -- issues are closed before
> > being fixed when the the reporter disappears (and hence, cannot provide
> > "more info", or has other things to do than provide a fix by
> > theirselves), even if the bug is understood.
> 
> These claims are inaccurate.  And it appears to me unfair considering
> all the amount of time I personally spend on old bug triage; instead of
> doing other (funner?) things.
> 
> My workflow dealing with old bugs is: pick one and read the report (and
> the complete thread, if any), then,
> 
>  1. the report provides enough information for reproducing; I try to
> reproduce myself and report more info, and then I try to collaborate
> for fixing or closing.
> 
>  2. the report does not provide enough information to understand what
> the bug is about or to find a way to reproduce; then I ask more info
> – sometimes my reply is even the first one, then,
> 
> a) an answer is back so it is similar as #1.
> 
> b) no answer after 2 or more weeks, so I try to determine if the
>report is actionable and if the next action is fine-grained
>enough to be doable.  After 2 or more weeks, I ask again.
> 
>Therefore, if a bug report after 2 or 3 years is not commented,
>especially after 2 or more attempts to understand and ask for the
>next steps without an answer back by the whole community, what
>could be the action other than just close the report.
>

Nothing, except maybe special archiving, or tagging for indexing?

By bug closing time, you have typically produced the best summary
of the bug chase, with clues and tips and examples for reproducing
and links where to find more info, such as links to Ludo's
(particularly, but others too) debugging examles. ( Kudos and thanks :)

So it's a matter of making sure your valuable work is archived for
easy use in future bug chases, ISTM.

Of course, your posts /are/ archived in the mailing lists.
(I like the POP3 mbox-format archives, where it's easy
to grep the headers. I do wget -c 
to make myself copies of selected mail list months,
so I can search offline and view with mutt.

What I'd like is something in the Subject: line
to make it greppable for /both/ what the bug is about
and how it was closed, i.e. bug status.

Maybe if a post that says "closing" could have
"[closing: ]" in the Subject: line, where
 could say "fixed upstream" or "unresolved"
or whatever (bikeshed for dev ideas?).

Then you could use "[closing: unresolved]" in the closing
post Subject: line for a case that withered from inattention,
(your 2b) but still looks suspicious (if you think so).

E.g. suspicious like an fseg that went away because
new linkage for an update made the bad write
clobber something still, but without fseg:
It would be misleading to mark that "fixed" IMO.
Maybe "disappeared" :)

Anyway, the idea is to make the Subject: line greppable for both
what the bug is about and its status when it was closed.

> Ultimately, nothing is perfect and people are doing their best with
> their resource at hand; at least, I do my best with the resource at my
> hands.  I would be more than happy if more people would try to sort,
> classify or fix the old bugs.  Maybe, you will join the effort ?
> 
> I stop now the discussion in this thread since I do not see what we are
> discussing.
> 
> Cheers,
> simon
> 
--
Regards,
Bengt Richter