Tunis
Computer science undergraduate, libre software developer and amateur gardener.
Comment by ~grtcdr on ~xenrox/hut
maybe you can ask in IRC or on the mailing list.
Okay, I'll do that.
Otherwise you could create a new dedicated folder for assets which get uploaded by a different pipeline. Then you would not overwrite your other files.
This leads to unwanted redundancy; I could create a
cv
subdirectory but then the path to the file would look like/cv/cv.pdf
.
Ticket created by ~grtcdr on ~xenrox/hut
Greetings,
I'm trying to figure out a way to update one file in my website without overwriting the existing contents of that subdirectory.
Some more detail: I'm attempting to upload a file (a curriculum vitae) from one pipeline into a pre-published website (sourcehut pages) (handled in another pipeline).
This build log builds the curriculum vitae, places it in a tar archive (such that the only thing contained within is a
cv.pdf
file) and runs:hut pages publish cv.tar.gz --domain grtcdr.tn --subdirectory assets
I had expected
hut
to unarchive the tar file and place its contents in the website's assets subdirectory, what in fact happened was thathut
overwrote the whole directory and then placed thecv.pdf
file. I was therefore able to accesscv.pdf
but not some of the other files that were originally contained there.I'd really appreciate it if
hut
could take use case into account, as that would really simplify making modifications from outside pipelines.
Comment by ~grtcdr on ~grtcdr/darkman.el
You're very welcome :)
REPORTED
RESOLVED CLOSEDComment by ~grtcdr on ~grtcdr/darkman.el
Hi,
I've implemented your request in commit ecbeeee3b596123755ebb2d2b4bc0399b086ccbf.
-- Aziz
feature added by ~grtcdr on ~grtcdr/darkman.el
Comment by ~grtcdr on ~grtcdr/darkman.el
REPORTED
RESOLVED NOT_OUR_BUGComment by ~grtcdr on ~grtcdr/darkman.el
magically the issue resolved itself due time
Good to know, I'll close the issue then.
bug added by ~grtcdr on ~grtcdr/darkman.el
Comment by ~grtcdr on ~grtcdr/darkman.el
also the automatic switch of everything but emacs (which is i think able to switch once but not back eg to black theme but not to white back i am pasting the debug log in case you might be interested)
I'm not sure I understand the problem, could you please reformulate?
Debugger entered--Lisp error: (error "nl.whynothugo.darkman D-Bus service not available") signal(error ("nl.whynothugo.darkman D-Bus service not available")) error("%s D-Bus service not available" "nl.whynothugo.darkman") darkman--dbus-service-unavailable-error() darkman--check-dbus-service() darkman-mode(1) custom-set-minor-mode(darkman-mode t) custom-theme-recalc-variable(darkman-mode) enable-theme(user) enable-theme(modus-operandi) load-theme(modus-operandi) darkman--load-theme(modus-operandi) darkman-set-theme() darkman-mode(1) custom-set-minor-mode(darkman-mode t) custom-theme-recalc-variable(darkman-mode) enable-theme(user) enable-theme(modus-operandi)
I've flipped the stack trace for a more natural analysis, let's see what's going on.
So, you've run `darkman-toggle' interactively,
execute-extended-command(nil "darkman-toggle")
which internally invokes
darkman-current-mode' whose result will be reversed and passed as a parameter to
darkman-set-mode'.This is confirmed by this next function call in the stack trace,
darkman-set-mode(light)
which tells us that the D-Bus daemon replied with "dark" and thus `darkman-set-mode' is instructed to set the mode to its opposite, i.e. "light".
This is good news, we are able to communicate with the D-Bus daemon, but something else is going wrong later on in the stack trace.
The last function call should have triggered a "ModeChanged" event, which we can confirm from
command-execute(dbus-handle-event nil [(dbus-event :session 4 2557 ":1.23" nil "/nl/whynothugo/darkman" "nl.whynothugo.darkman" "ModeChanged" darkman--signal-handler (:string "light"))] t)
which would execute a callback function
apply(darkman--signal-handler "light")
loading the corresponding theme
load-theme(modus-operandi)
What I understand from this is that
darkman-toggle' works correctly. What doesn't work is
darkman-mode' whose first invocation works as expected, but fails on the second due to what I presume is a timeout in the ping operation between the two applications (Emacs and Darkman).I don't know what could be causing this ping timeout or why the behavior of `darkman-mode' is unpredictable.
I also can't reproduce this problem on my machine, so I'll keep the issue open in the hopes that someone more knowledgeable than me could help us figure it out.
Comment by ~grtcdr on ~grtcdr/darkman.el
Hi,
darkman--dbus-service-unavailable-error: nl.whynothugo.darkman D-Bus service not available
Can you please ensure the Darkman daemon is working properly before Emacs is started?
Making requests to a D-Bus object will activate the corresponding D-Bus service if it wasn't already activated, this explains why things start working when you've manually toggled `darkman-mode' yourself.
If you're using systemd, run the following in your shell:
systemctl is-active --user darkman.service
The command will print "active" if the service is running without issues.
#Regards,
Aziz