profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/steckerhalter/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
steckerhalter https://framagit.org/steckerhalter I have deleted my repos because of the acquisition. See my profile url for the new code location.

menduo/gitit-bigger 279

Gitit Bigger: 超棒的个人、团队Wiki/文档方案(Git、Markdown、Bootstrap、Ace、Docker)

Openmedianetwork/Search 4

This is the space for openweb search https://openworlds.info

steckerhalter/git-ftp 0

Uses Git to upload only changed files to FTP servers.

steckerhalter/melpa 0

Recipes and build machinery for the biggest Emacs package repo

release home-sweet-gnome/dash-to-panel

v43

released time in 3 days

startedFederated-HospEx/federated-trustroots

started time in a month

startedornicar/lila

started time in a month

startedaaronraimist/element-themes

started time in a month

starteddannycolin/riot-compact

started time in a month

startedigniterealtime/openfire-pade-plugin

started time in 2 months

startedwclr/vscode-autosave-ext

started time in 2 months

MemberEvent

startedturt2live/matrix-dimension

started time in 2 months

startedvector-im/element-android

started time in 2 months

issue openedquelpa/quelpa-use-package

quelpa :upgrade attribute has no effect in quelpa-use-package

This was working for a while but sometime around last October I realized that my quelpa packages were no longer being updated, and if I delete them they don't get re-installed. I am using quelpa-use-package to install the newest version of cc-mode, so I have this in my emacs init:

(use-package cc-mode
  :ensure t
  :quelpa (cc-mode :fetcher hg
                   :url "http://hg.code.sf.net/p/cc-mode/cc-mode"
                   :upgrade t))

This used to work but now is a no-op. I didn't notice so I'm not sure when it changed but the last time my cc-mode was updated was Oct 2020. Now when I start Emacs if I look in my messages buffer I see:

Newer package has been installed. Not upgrading.

and no updates are done.

Debugging shows that the :upgrade setting that I've given is ignored, and quelpa's quelpa-upgrade-p variable is nil, not t which is what I want, when it runs the quelpa-build method.

I was able to force it to install by evaluating this in my scratch buffer:

(quelpa '(cc-mode :fetcher hg
                  :url "http://hg.code.sf.net/p/cc-mode/cc-mode")
        :upgrade t)

Note, that the :upgrade attribute must appear outside of the package definition; it's a plist attribute for the invocation of the quelpa function; an :upgrade attribute inside the package definition is ignored. It seems that the quelpa-use-package wrapper isn't managing this attribute as expected?

created time in 2 months

issue openedquelpa/quelpa

Docs for :upgrade are confusing / inadequate

I was using quelpa plus quelpa-use-package to install the latest cc-mode for a long time but sometime around last October it stopped working: I realized I've just been re-using the same version without any updates since then, and if I delete that version then quelpa doesn't install a new version. All I see in my minibuffer is:

Newer package has been installed. Not upgrading.

I spent a lot of time this morning trying to work out what is happening. Finally after much time in the elisp debugger I figured out that the :upgrade attribute has to be handled specially but this is not clear at all in the docs.

Based on the docs I was evaluating this:

(quelpa '(cc-mode :fetcher hg
                  :url "http://hg.code.sf.net/p/cc-mode/cc-mode"
                  :upgrade t))

But this does nothing. After trial and error I discovered that the :upgrade must come AFTER the definition; this will work:

(quelpa '(cc-mode :fetcher hg
                  :url "http://hg.code.sf.net/p/cc-mode/cc-mode")
        :upgrade t)

It would be great if some kind of example for this would be added to the docs and/or the behavior of upgrade was more clearly explained.

I will file an issue with quelpa-use-package so they can figure out why their setting of :upgrade is not having any effect.

created time in 2 months

MemberEvent

startedyanyu5025/landing-page

started time in 3 months

push eventquelpa/quelpa

kiennq

commit sha 9acc440f8c200b1e6134f53e219d84360ee1b6b7

quelpa-git-clone-partial: check version berfore doing partial clone (#219)

view details

push time in 3 months

issue closedquelpa/quelpa

Partial cloning requires very recent versions of git

For instance, --filter=blob:none was added in git v2.20, which was released in late 2018, so would only be available in the most recent Ubuntu LTS. Centos lags even further behind: Centos 7 includes only Git v1.8. It would be nice if quelpa detected such installations and either printed a warning message to the user or automatically fell back to setting quelpa-git-clone-partial to nil.

Or, at the very least, mention the git version consequences in the Prerequisites section of Readme.

closed time in 3 months

cubranic

PR opened quelpa/quelpa

quelpa-git-clone-partial: check version berfore doing partial clone

Fix #218

+13 -3

0 comment

2 changed files

pr created time in 3 months

issue commentquelpa/quelpa

Partial cloning requires very recent versions of git

Thank you!

cubranic

comment created time in 3 months

issue commentquelpa/quelpa

Partial cloning requires very recent versions of git

I would definitely recommend to upgrade to latest Git version if possible since old Git client can contains some very serious security bugs Will add the mention in prerequisite and some code to check for git version.

cubranic

comment created time in 3 months

issue openedquelpa/quelpa

Partial cloning requires very recent versions of git

For instance, --filter=blob:none was added in git v2.20, which was released in late 2018, so would only be available in the most recent Ubuntu LTS. Centos lags even further behind: Centos 7 includes only Git v1.8. It would be nice if quelpa detected such installations and either printed a warning message to the user or automatically fell back to setting quelpa-git-clone-partial to nil.

Or, at the very least, mention the git version consequences in the Prerequisites section of Readme.

created time in 3 months

issue openedquelpa/quelpa

Feature request: `:patches` keywords

It's common that sometimes users want to install a modified version of a package. Currently, the user needs to fork the package and host it somewhere (with or without version-control, remote or local, etc).

I propose to add a new keyword :patches, which accepts an ordered list of patch files represented as their local file path or remote locations. And quelpa would apply those patches, after checking out/downloading the upstream package but before building.

The advantage of using :patches over a fork is:

  • Many modifications to upstream packages are trivial and :patches approach fits this AD-HOC nature very well.
  • Often time users still want to keep updated with the upstream. Forking would require the user to take additional steps to keep it updated, while patching always download the latest upstream packages.
  • Suppose users somehow managed to keep their forks updated, they still have the compatibility issue should there be any API changes in the upstream. Patching doesn't solve this, but it's a little bit more robust because it could fail during package build-time.

created time in 3 months

startedversatica/mediasoup

started time in 3 months