Siduction Forum

hmm...
Ändere ich besagtes "yes" in "= true", mit Komma am Ende oder ohne, meckert conky wie du sagst die nächste Zeile an, aber conky verschwindet auch wieder im Hintergrund. Ändere ich weiter mit "own_window_type = 'normal' " statt "own_window_type normal", egal ob mit oder ohne Hochkomma bzw Komma am Ende , meckert er mir diese Zeile weiter an, aber auch die "hints", bei denen ich auch machen kann was ich will, es bleiben syntax errors.
Conky startet neu, das ist im Konsolenfenster zu sehen, bleibt aber unsichtbar.

 Bevor ich ganz bekloppt werde lass ich die config jetzt mal wie oben gepostet bis ich mal wieder einen Tag Zeit habe, dann schau ich mir das nochmal an, im Moment tut conky ja (noch?) was es soll.
Grüße
Jürgen

Quote from: aylaWas ich nicht herausfinden konnte ist wieso da ein syntax terror near yes auftaucht wenn ich von Konsole starte:

Du verwendest mit conky-all-1.24.2 (der in Syntax 1.10 vorliegt) eine Konfiguration mit dem Syntax1.9   😉

syntax error (/home/cal/.conkyrc:2: syntax error near 'yes') while reading config file '/home/cal/.conkyrc' er meckert hier gleich die 1.Zeile an: own_window yesDas "yes" kennt er nicht. Er erwartet: own_window = trueWürdest du das jetzt korrigieren, dann meckerst er die 2.Zeile an, und so weiter und sofort, bis du mit der "Korrektur" oberhalb von TEXT durch wärst( im oder mit Syntax1.10).

Hier sollte eigentlich ein Bild meines Desktop kommen, krieg ich aber irgendwie nicht rein "img invalid" oder so

own_window yes
own_window_type normal
--own_window_transparent false
own_window_hints skip_taskbar,skip_pager,undecorated
own_window_colour 88335588
own_window_class Conky
own_window_title test.konky.txt

--own_window_argb_visual true
--own_window_argb_value 150

gap_x 10

gap_y 50

minimum_size 380 200
--maximum_width 300

alignment tr
override_utf8_locale yes
use_xft yes
--xftfont Fantasque Sans Mono:bold:size=12
--xftfont Monofur:bold:size=14
--xftfont DejaVu Sans Mono:bold:size=10
xftfont Fira Mono:medium:size=12
-- Alpha of Xft font. Must be a value at or between 1 and 0
xftalpha 1.0

draw_shades no
default_shade_color 000000
draw_outline no
default_outline_color 000000

default_color  FFDEAD


draw_borders yes
stippled_borders 0
border_inner_margin 5
border_outer_margin 0
border_width 0
draw_graph_borders no
-- default_graph_size 15 40


background true
use_spacer none
text_buffer_size 3328
no_buffers yes
short_units yes
pad_percents 2
imlib_cache_size 0
double_buffer yes
max_user_text 48000

update_interval 1




TEXT

${color cyan}${font DejaVu Sans:size=30}${alignc}${time %T %Z}${font}
${color cyan}${font DejaVu Sans:size=12}${alignc}${time %A, %e. %B %Y}${font}

${color black}Kernel: ${color gold}$kernel

${color black}Uptime:    ${color orange}$uptime

${color black}CPU model:  ${color light blue}${exec grep -m1 "model name" /proc/cpuinfo |cut -c 32-53}
${color black}Chipset:    ${color light blue} Intel CometLake-U GT2
#${exec glxinfo | awk '/Intel/{print $6" "$7}'}
${color cyan}${font Terminus:size=9}TEMPS
${font Terminus:size=9}${color orange}Core 0: ${if_match ${execi 5 sensors | grep 'Core 0' | awk '{print $3}' | cut -c2-3} <= 65} ${color green}${execi 5 sensors | grep 'Core 0' | awk '{print $3}'} ${else}${if_match ${execi 5 sensors | grep 'Core 0' | awk '{print $3}' | cut -c2-3} > 65} ${color gold}${execi 5 sensors | grep 'Core 0' | awk '{print $3}'} ${endif}${endif}    ${color orange}Core 1: ${if_match ${execi 5 sensors | grep 'Core 1' | awk '{print $3}' | cut -c2-3} <= 65} ${color green}${execi 5 sensors | grep 'Core 1' | awk '{print $3}'} ${else}${if_match ${execi 5 sensors | grep 'Core 1' | awk '{print $3}' | cut -c2-3} > 65} ${color gold}${execi 5 sensors | grep 'Core 1' | awk '{print $3}'} ${endif}${endif}
${color orange}Core 2: ${if_match ${execi 5 sensors | grep 'Core 2' | awk '{print $3}' | cut -c2-3} <= 65} ${color green}${execi 5 sensors | grep 'Core 2' | awk '{print $3}'} ${else}${if_match ${execi 5 sensors | grep 'Core 2' | awk '{print $3}' | cut -c2-3} > 65} ${color gold}${execi 5 sensors | grep 'Core 2' | awk '{print $3}'} ${endif}${endif}  ${color orange}Core 3: ${if_match ${execi 5 sensors | grep 'Core 3' | awk '{print $3}' | cut -c2-3} <= 65} ${color green}${execi 5 sensors | grep 'Core 3' | awk '{print $3}'} ${else}${if_match ${execi 5 sensors | grep 'Core 3' | awk '{print $3}' | cut -c2-3} > 65} ${color gold}${execi 5 sensors | grep 'Core 3' | awk '{print $3}'} ${endif}${endif}

${color black}CPU1-4 (MHz):
${color orange}${execi 3 grep  -m4 MHz /proc/cpuinfo| cut -f3 | awk '{print $2}'}

${color black}CPU1-8 (%):
${color red}${cpubar cpu0 7,145} ${cpubar cpu1 7,145}
${color red}${cpubar cpu2 7,145} ${cpubar cpu3 7,145}
${color red}${cpubar cpu4 7,145} ${cpubar cpu5 7,145}
${color red}${cpubar cpu6 7,145} ${cpubar cpu7 7,145}

${color black}NAME $alignc  CPU% $alignr MEM%
${color gold}${top name 1}$alignc${top cpu 1}%$alignr${top mem 1}
${color light blue}${top name 2}$alignc${top cpu 2}%$alignr${top mem 2}
${color light blue}${top name 3}$alignc${top cpu 3}%$alignr${top mem 3}
#${color #828282}${top name 4}$alignc${top cpu 4}%$alignr${top mem 4}
#${color #616161}${top name 5}$alignc${top cpu 5}%$alignr${top mem 5}

${color green}Akku:${alignr} ${battery BAT0}
${color green}${alignr} ${battery_time BAT0}
${color green}${battery_bar BAT0}

${color gold}RAM    :  $mem /  $memmax $memperc%
${membar }
${color orange}Temp  :  ${fs_used /tmp} /  ${fs_size /tmp} ${fs_used_perc /tmp}%
${color #D41A1F}${fs_bar /tmp}$color
${color cyan}Swap  :  $swap  /  $swapmax $swapperc%
${swapbar }
root  :  ${fs_used /} /  ${fs_size /} ${fs_used_perc /}%
${fs_bar /}
home  : ${fs_used /home} /  ${fs_size /home} ${fs_used_perc /home}%
${fs_bar /home}$color

##################################
##          NETWORK            ##
##################################
${voffset 4}${color light blue}NETWORK${offset 8}${voffset -2}${hr 2}${font}
${voffset 4}${color light blue}${offset 5}Download${goto 120}${color gold}${downspeed wlan0}${alignr}${color light blue}${totaldown wlan0}${font}
${voffset 0}${color light blue}${offset 5}Upload${goto 120}${color gold}${upspeed wlan0}${alignr}${color light blue}${totalup wlan0}${font}
${voffset 4}${color cyan}${offset 5}Private${offset 3}IP${goto 123}${alignr}${addr wlan0}${font}
${voffset 0}${offset 5}IP${alignr}${exec curl -s www.icanhazip.com}
So, dank der Config von @Sektor11 in diesem https://forum.siduction.org/index.php?topic=10061.0 thread ,die ich auf meine Wünsche angepasst habe, hab ich jetzt ein Conky das zwar nur halb transparent ist aber nach Anpassung der Farben jetzt eingermaßen zu meinem Desktop passt. Meine uralt  Config hab ich aufgeräumt.

Weil ich schon mal dabei war, hab ich mich auch mal mit "if else" im Conky beschäftigt, so dass meine Temperaturanzeige, wenn sie denn so langsam kritische Werte erreicht, die Farbe wechselt. Da hat die KI der google Suche richtig anständig geholfen. Komplexe Frage mit meiner Vorstellung des Codes wie der aussehen könnte gestellt, auf Anhieb funktionierenden Code vorgeschlagen bekommen und auch noch Erklärungen dazu wie und warum dies so besser, bzw überhaupt funktioniert. -WOW-

Was ich nicht herausfinden konnte ist wieso da ein syntax terror near yes auftaucht wenn ich von Konsole starte:

[2026-10-15 17:10:17.183] [info ] [src/conky.cc:1898] 'KDE' wayland session running
[2026-10-15 17:56:16.084] [info ] [src/conky.cc:2038] '/home/cal/.conkyrc' modified, reloading
[2026-10-15 17:56:17.087] [warn ] [src/conky.cc:2210] syntax error (/home/cal/.conkyrc:2: syntax error near 'yes') while reading config file '/home/cal/.conkyrc'
[2026-10-15 17:56:17.087] [info ] [src/conky.cc:2212] assuming old config syntax and attempting conversion
[2026-10-15 17:56:17.088] [info ] [src/output/x11.cc:700] window type - normal
[2026-10-15 17:56:17.089] [info ] [src/output/x11.cc:814] drawing to created window 0x1000002
[2026-10-15 17:56:17.089] [info ] [src/lua/x11-settings.cc:67] drawing to double buffer
 
Danke an alle Beteiligten,

Grüße
Jürgen

Mh, well, I am not a professional, but I have one question (off-topic): If I understand it right by reading your website, you are providing enterprise solutions.
So why do you use siduction/debian unstable and not debian stable with backports?
I am just curious.

Hi everyone,

We are configuring an internal batch synchronization workflow on Siduction/Debian sid to bridge project tasks between Jira Cloud and external tracking platforms (specifically Teamwork Projects).

When dealing with high-throughput webhook updates across both systems, we noticed occasional race conditions when task updates arrive out of sequence. For native marketplace connectors (such as the SoftSync Teamwork Integration for Jira connector), task mapping and idempotency appear to be handled at the middleware layer via transaction tokens.

When building custom Python daemon services on Debian to consume Atlassian Jira Cloud Webhooks alongside the Teamwork REST API v3, we need to ensure message deduplication adheres to standard HTTP idempotency rules under IETF RFC 7230 Section 6.

Here is the lightweight webhook ingest worker we are testing with FastAPI and Celery on our Siduction dev workstations:

from fastapi import FastAPI, Header, HTTPException, Request
import hmac
import hashlib

app = FastAPI()

@app.post("/webhooks/jira-sync")
async def handle_jira_webhook(
    request: Request,
    x_atlassian_webhook_signature: str = Header(None)
):
    payload = await request.body()
    # verify HMAC signature before dispatching to Celery queue
    if not verify_signature(payload, x_atlassian_webhook_signature):
        raise HTTPException(status_code=401, detail="Invalid signature")
   
    event_data = await request.json()
    task_id = event_data.get("issue", {}).get("key")
    # dispatch background async sync worker
    sync_external_task.delay(task_id, event_data)
    return {"status": "accepted", "issue": task_id}

Has anyone deployed similar bidirectional task bridges on Siduction/Debian? Do you prefer delegating the deduplication logic to a Redis state lock or relying on database-level upserts with optimistic locking?

Thanks for any insights or recommended architecture patterns!

Funktioniert!
Danke!

Kannst Du den Output von
$ grep -v xxx /etc/sddm.conf.d/*posten, um zu sehen, welchen Server/Compositor der sddm-greeter
beim Login benutzt?