, we do not have the issue any more as we no longer see nodes
with NOT_RESPONDING.
Nice to hear that you found a solution though.
Best,
Xaver
On 19.09.24 15:04, nate--- via slurm-users wrote:
Hi Xaver,
I found your thread while searching for a solution to the same issue with cloud
nodes. In
Hi Harry,
I applied this patch and the two issues I mentioned before are gone.
I noticed a new problem though: Changes in the COLOR_PIPELINE value
aren't always applied immediately. For testing I played an HDR video
on an SDR screen with the work/zamundaaa/drm-colorop KWin branch, and
made it full
Hi Harry,
I applied this patch and the two issues I mentioned before are gone.
I noticed a new problem though: Changes in the COLOR_PIPELINE value
aren't always applied immediately. For testing I played an HDR video
on an SDR screen with the work/zamundaaa/drm-colorop KWin branch, and
made it full
Hi Harry,
I applied this patch and the two issues I mentioned before are gone.
I noticed a new problem though: Changes in the COLOR_PIPELINE value
aren't always applied immediately. For testing I played an HDR video
on an SDR screen with the work/zamundaaa/drm-colorop KWin branch, and
made it full
cription
>
> v2:
> - Rebased on drm-misc-next
> - Introduce a VKMS Kunit so we can test LUT functionality in vkms_composer
> - Incorporate feedback in color_pipeline.rst doc
> - Add support for sRGB inverse EOTF
> - Add 2nd enumerated TF colorop to VKMS
> - Fix LUTs and
cription
>
> v2:
> - Rebased on drm-misc-next
> - Introduce a VKMS Kunit so we can test LUT functionality in vkms_composer
> - Incorporate feedback in color_pipeline.rst doc
> - Add support for sRGB inverse EOTF
> - Add 2nd enumerated TF colorop to VKMS
> - Fix LUTs and
cription
>
> v2:
> - Rebased on drm-misc-next
> - Introduce a VKMS Kunit so we can test LUT functionality in vkms_composer
> - Incorporate feedback in color_pipeline.rst doc
> - Add support for sRGB inverse EOTF
> - Add 2nd enumerated TF colorop to VKMS
> - Fix LUTs and
Am Do., 1. Aug. 2024 um 14:34 Uhr schrieb Jani Nikula
:
>
> On Mon, 01 Jul 2024, Xaver Hugl wrote:
> > Am Do., 20. Juni 2024 um 22:22 Uhr schrieb Xaver Hugl
> > :
> >> Merging can only happen once a real world userspace application has
> >> implemented
Am Do., 1. Aug. 2024 um 14:34 Uhr schrieb Jani Nikula
:
>
> On Mon, 01 Jul 2024, Xaver Hugl wrote:
> > Am Do., 20. Juni 2024 um 22:22 Uhr schrieb Xaver Hugl
> > :
> >> Merging can only happen once a real world userspace application has
> >> implemented
Hi,
On Dienstag, 9. Juli 2024 09:46:56 MESZ Arun R Murthy wrote:
> Each plane has its own capability or interoperability based on the
> harware restrictions. If this is exposed to the user, then user can read
> it once on boot and store this. Later can be used as a lookup table to
> check a corres
Hi,
The patch makes sense to me, and with this fix, my implementation for
tearing in KWin can be a lot simpler. Consider it Tested-by: Xaver
Hugl
Am Mo., 1. Juli 2024 um 21:02 Uhr schrieb Mario Limonciello
:
> Hmm I'm a bit surprised the IGT tests I did didn't catch this.
>
> Are you working on a system with two GPUs by chance (like a Framework
> 16)? If so; can you try the "other GPU"?
No, I tested on a Framework 13.
> As it seems your P
Am Mo., 1. Juli 2024 um 21:02 Uhr schrieb Mario Limonciello
:
> Hmm I'm a bit surprised the IGT tests I did didn't catch this.
>
> Are you working on a system with two GPUs by chance (like a Framework
> 16)? If so; can you try the "other GPU"?
No, I tested on a Framework 13.
> As it seems your P
Am Do., 20. Juni 2024 um 22:22 Uhr schrieb Xaver Hugl :
> Merging can only happen once a real world userspace application has
> implemented support for it. I'll try to do that sometime next week in
> KWin
Here's the promised implementation:
https://invent.kde.org/plasma/kwin/-/
Am Do., 20. Juni 2024 um 22:22 Uhr schrieb Xaver Hugl :
> Merging can only happen once a real world userspace application has
> implemented support for it. I'll try to do that sometime next week in
> KWin
Here's the promised implementation:
https://invent.kde.org/plasma/kwin/-/
Thanks Steffen,
that makes a lot of sense. I will just not start slurmd in the master
ansible role when the master is not to be used for computing.
Best regards,
Xaver
On 24.06.24 14:23, Steffen Grunewald via slurm-users wrote:
On Mon, 2024-06-24 at 13:54:43 +0200, Slurm users wrote:
Dear
is *DRAINED* the correct setting in such a case?
Best regards,
Xaver
--
slurm-users mailing list -- slurm-users@lists.schedmd.com
To unsubscribe send an email to slurm-users-le...@lists.schedmd.com
Am Mi., 19. Juni 2024 um 06:08 Uhr schrieb Mario Limonciello
> Thanks! I don't have permissions, so can you (or someone else) please
> apply to drm-misc-next for me?
>
> After it's merged I'll rebase and work on the feedback for the new IGT
> tests.
Merging can only happen once a real world user
Am Mi., 19. Juni 2024 um 06:08 Uhr schrieb Mario Limonciello
> Thanks! I don't have permissions, so can you (or someone else) please
> apply to drm-misc-next for me?
>
> After it's merged I'll rebase and work on the feedback for the new IGT
> tests.
Merging can only happen once a real world user
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856246#comment-17856246
]
Xaver commented on MBUILDCACHE-73:
--
I think this Issue may be closed.
Am Di., 21. Mai 2024 um 19:28 Uhr schrieb Leo Li :
>
>
>
> On 2024-05-21 12:21, Mario Limonciello wrote:
> > On 5/21/2024 11:14, Xaver Hugl wrote:
> >> Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello
> >> :
> >>>
> >>> On 5/2
Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello
:
>
> On 5/21/2024 08:43, Simon Ser wrote:
> > This makes sense to me in general. I like the fact that it's simple and
> > vendor-neutral.
> >
> > Do we want to hardcode "panel" in the name? Are we sure that this will
> > ever only apply t
Am Di., 21. Mai 2024 um 19:28 Uhr schrieb Leo Li :
>
>
>
> On 2024-05-21 12:21, Mario Limonciello wrote:
> > On 5/21/2024 11:14, Xaver Hugl wrote:
> >> Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello
> >> :
> >>>
> >>> On 5/2
Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello
:
>
> On 5/21/2024 08:43, Simon Ser wrote:
> > This makes sense to me in general. I like the fact that it's simple and
> > vendor-neutral.
> >
> > Do we want to hardcode "panel" in the name? Are we sure that this will
> > ever only apply t
/produktinformationen.html)
Bevor wirklich der teure, proprietäre Kram gekauft werden muss, schaue ich noch
nach OS-Alternativen, um weitere Abhängigkeiten von Archikart AG zu verhindern.
Gibt man in Google einfach nur "Flurstücksverwaltung" ein, dann ist da
Archikart AG ganz oben.
Beste Grüße
Xave
ctly" show the added
partition when calling sinfo on them.
Is the stored slurm.conf on every instance just a fallback for when
connection is down or what is the purpose? The documentation only says:
"This file should be consistent across all nodes in the cluster."
Best regards,
Xaver
or now I feel like using the master to setup workers is
the better structure.
Best regards,
Xaver
On 08.04.24 18:18, Brian Andrus via slurm-users wrote:
Xaver,
You may want to look at the ResumeRate option in slurm.conf:
ResumeRate
The rate at which nodes in power save mode are ret
.
Is this somehow possible?
Best regards,
Xaver
--
slurm-users mailing list -- slurm-users@lists.schedmd.com
To unsubscribe send an email to slurm-users-le...@lists.schedmd.com
quest them, no matter what -
and if that is not possible or desirable, uAPI has to be changed, for
example by introducing the mentioned "pageflip failed" event.
Looking forward to some answers,
Xaver Hugl
Am Mi., 6. März 2024 um 18:19 Uhr schrieb Mario Limonciello
:
> So the idea being if the compositor isn't using it we let
> power-profiles-daemon (or any other software) take control via sysfs and
> if the compositor does want to control it then it then it writes a DRM
> cap and we destroy the sysf
Like already mentioned in the power profiles daemon repository, I don't think
this makes sense. This is a display setting, which compositors have interest
in controlling, for example to:
- disable it in a bright environment, because afaiu it reduces the maximum
screen brightness
- disable it whe
Am Mi., 6. März 2024 um 18:19 Uhr schrieb Mario Limonciello
:
> So the idea being if the compositor isn't using it we let
> power-profiles-daemon (or any other software) take control via sysfs and
> if the compositor does want to control it then it then it writes a DRM
> cap and we destroy the sysf
Like already mentioned in the power profiles daemon repository, I don't think
this makes sense. This is a display setting, which compositors have interest
in controlling, for example to:
- disable it in a bright environment, because afaiu it reduces the maximum
screen brightness
- disable it whe
ify how to handle "NOT_RESPONDING".
I would really like to improve my question if necessary.
Best regards,
Xaver
On 23.02.24 18:55, Xaver Stiensmeier wrote:
Dear slurm-user list,
I have a cloud node that is powered up and down on demand. Rarely it
can happen that slurm's resumeT
After a while NOT_RESPONDING is removed, but I would like to move it
directly from within my fail script if possible so that the node can
return to service immediately and not be blocked by "NOT_RESPONDING".
Best regards,
Xaver
--
slurm-users mailing list -- slurm-users@lists.schedmd.com
To uns
job.
Is there some way to achieve the described effect i.e. tell Slurm: "You
can stop waiting, the node won't come alive." or am I missing the
correct way how this should be handled in Slurm?
Best regards,
Xaver
--
slurm-users mailing list -- slurm-users@lists.schedmd.com
To unsu
Signed-off-by: Xaver Hugl
---
drivers/gpu/drm/drm_connector.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b0516505f7ae..01e13984629b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm
ret.key` on the master at
`etc/slurm` and that was enough, but I must admit that I am not
completely familiar with it, but I will now look into it closer and also
double check whether such a key is stored there in the old slurm version.
Best regards,
Xaver
On 08.02.24 11:07, Luke Sudbery via slur
t be coming from a
previous problem I tried to fix (basically a few deprecated keys in the
configuration).
I will try to restart the entire cluster with the added changes to rule
out any follow up errors, but maybe it's something obvious a fellow list
user can see.
Best regards,
Xaver
--
slurm-use
Am Mo., 22. Jan. 2024 um 16:50 Uhr schrieb Harry Wentland
:
>
>
>
> On 2024-01-19 13:25, Ville Syrjälä wrote:
> > On Fri, Jan 19, 2024 at 03:12:35PM -0300, André Almeida wrote:
> >> AMD GPUs can do async flips with changes on more properties than just
> >> the FB ID, so implement a custom check_asy
Am Mo., 22. Jan. 2024 um 16:50 Uhr schrieb Harry Wentland
:
>
>
>
> On 2024-01-19 13:25, Ville Syrjälä wrote:
> > On Fri, Jan 19, 2024 at 03:12:35PM -0300, André Almeida wrote:
> >> AMD GPUs can do async flips with changes on more properties than just
> >> the FB ID, so implement a custom check_asy
gt; >>> What kind of userspace would take advantage of this and in what
> > > situations?
> > > >>>
> > > >>> Or is this not meant for generic userspace?
> > > >>
> > > >> Sorry, I forgot to document this. So the ide
gt; >>> What kind of userspace would take advantage of this and in what
> > > situations?
> > > >>>
> > > >>> Or is this not meant for generic userspace?
> > > >>
> > > >> Sorry, I forgot to document this. So the ide
>> instead of having capabilities for each prop.
> >
> > That's the theory, but do you have a practical example?
> >
> > What other planes and props would one want change in some specific use
> > case?
> >
> > Is it just "all or n
>> instead of having capabilities for each prop.
> >
> > That's the theory, but do you have a practical example?
> >
> > What other planes and props would one want change in some specific use
> > case?
> >
> > Is it just "all or n
Great, thank you!
Am Do., 11. Jan. 2024 um 19:05 Uhr schrieb André Almeida <
andrealm...@igalia.com>:
> Em 11/01/2024 14:59, Xaver Hugl escreveu:
> > Am Do., 11. Jan. 2024 um 18:13 Uhr schrieb Simon Ser
> > mailto:cont...@emersion.fr>>:
> >
> > Are we
Am Do., 11. Jan. 2024 um 18:13 Uhr schrieb Simon Ser :
> Are we sure that all drivers handle these two props properly with async
> page-flips? This is a new codepath not taken by the legacy uAPI.
>
I've only tested on amdgpu so far. Afacs the other drivers that would need
testing / that support at
Like with FB_ID, the driver never has to do bandwidth validation to use
these properties, so there's no reason not to allow them.
Signed-off-by: Xaver Hugl
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gp
Am Mi., 10. Jan. 2024 um 01:28 Uhr schrieb Zack Rusin <
zack.ru...@broadcom.com>:
> On Tue, Jan 9, 2024 at 11:06 AM Xaver Hugl wrote:
> >
> > Hi,
> >
> > KWin does use DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT.
>
> Can you point me to the code that implements
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804848#comment-17804848
]
Xaver edited comment on MBUILDCACHE-73 at 1/9/24 8:3
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804848#comment-17804848
]
Xaver commented on MBUILDCACHE-73:
--
Hi there,
V1.0.1 works awesome (we use it
Hi,
KWin does use DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT. Tying the check to
DRM_CLIENT_CAP_ATOMIC instead would IMO make more sense though (even if it's
still weird) and would work with older versions of KWin and other compositors.
Greetings,
Xaver Hugl
Hi,
I tested the patch and it fixes the issue for me too. Consider it
Tested-By Xaver Hugl
- Xaver
Am Mo., 1. Jan. 2024 um 22:37 Uhr schrieb Joshua Ashton :
> From the issue:
>
> ```
> Thank you for for fixing this!
> I built a custom kernel with this patch on the fedora
large file(s) got
removed immediately.
I will take a look at /var/log. That's a good idea. I don't think that
there will be anything unusual, but it's something I haven't thought
about yet (the reason of the error being somewhere else).
Best regards
Xaver
On 10.12.23 00:41, B
Slurmd is placing in this dir that fills
up the space. Do you have any ideas? Due to the workflow used, we have a
hard time reconstructing the exact scenario that caused this error. I
guess, the "fix" is to just pick a bit larger disk, but I am unsure
whether Slurm behaves normal here.
Sorry, it looks like I sent this too soon. I tested the patch on a
second PC and it doesn't fix the issue there.
Am Do., 7. Dez. 2023 um 19:25 Uhr schrieb Xaver Hugl :
>
> With VRR, every atomic commit affecting a given display must trigger
> a new scanout cycle, so that usersp
://gitlab.freedesktop.org/drm/amd/-/issues/3034
Cc: sta...@vger.kernel.org
Signed-off-by: Xaver Hugl
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display
Sorry, it looks like I sent this too soon. I tested the patch on a
second PC and it doesn't fix the issue there.
Am Do., 7. Dez. 2023 um 19:25 Uhr schrieb Xaver Hugl :
>
> With VRR, every atomic commit affecting a given display must trigger
> a new scanout cycle, so that usersp
://gitlab.freedesktop.org/drm/amd/-/issues/3034
Cc: sta...@vger.kernel.org
Signed-off-by: Xaver Hugl
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display
or not, but it's worth a try.
Best regards
Xaver
On 06.12.23 12:03, Ole Holm Nielsen wrote:
On 12/6/23 11:51, Xaver Stiensmeier wrote:
Good idea. Here's our current version:
```
sinfo -V
slurm 22.05.7
```
Quick googling told me that the latest version is 23.11. Does the
upgrade chang
Hi Ole,
Good idea. Here's our current version:
```
sinfo -V
slurm 22.05.7
```
Quick googling told me that the latest version is 23.11. Does the
upgrade change anything in that regard? I will keep reading.
Xaver
On 06.12.23 11:09, Ole Holm Nielsen wrote:
Hi Xaver,
Your version of Slur
But I will take a look at
`DebugFlags=Power`. `PrivateData=cloud` was an annoying thing to find
out; SLURM plans/planned to change that in the future (cloud key behaves
different than any other key in PrivateData). Of course our setup
differs a little in the details.
Best regards
Xaver
On 06.12.23 10:3
rs.
Maybe someone has a great idea how to tackle this problem.
Best regards
Xaver Stiensmeier
I'm afraid that would not be very useful. It indeed depends on the refresh
rate, but also on how close to vblank the compositor does its commits / on
what the latency requirements for the currently shown content are.
When the compositor presents a fullscreen video with frames that are queued
up in
I'm afraid that would not be very useful. It indeed depends on the refresh
rate, but also on how close to vblank the compositor does its commits / on
what the latency requirements for the currently shown content are.
When the compositor presents a fullscreen video with frames that are queued
up in
Am Fr., 27. Okt. 2023 um 12:01 Uhr schrieb Sebastian Wick <
sebastian.w...@redhat.com>:
> On Fri, Oct 27, 2023 at 10:59:25AM +0200, Michel Dänzer wrote:
> > On 10/26/23 21:25, Alex Goins wrote:
> > > On Thu, 26 Oct 2023, Sebastian Wick wrote:
> > >> On Thu, Oct 26, 2023 at 11:57:47AM +0300, Pekka
Am Fr., 27. Okt. 2023 um 12:01 Uhr schrieb Sebastian Wick <
sebastian.w...@redhat.com>:
> On Fri, Oct 27, 2023 at 10:59:25AM +0200, Michel Dänzer wrote:
> > On 10/26/23 21:25, Alex Goins wrote:
> > > On Thu, 26 Oct 2023, Sebastian Wick wrote:
> > >> On Thu, Oct 26, 2023 at 11:57:47AM +0300, Pekka
Hi,
Victoria wanted to take part in this meeting, but she's on vacation during
that week. Would you mind having the meeting the week afterwards instead?
Best regards,
Xaver
Am Do., 17. Aug. 2023 um 21:44 Uhr schrieb Simon Zeni :
> Hello there!
>
> Apologies again for the duplica
Hi everyone,
Monday 7th of August 2023, 11:00 CEST has been selected for next weeks
meeting.
Best regards,
Xaver
Am Do., 3. Aug. 2023 um 00:58 Uhr schrieb Xaver Hugl :
> This is a meeting annoucement.
>
> The Wayland Governance Meeting is semi-regular meeting to drive
> discussio
of August.
Notes of previous meetings can be found
here:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/wikis/meetings
In the interest of not having the meeting-link publically available,
please contact me under xaver.h...@kde.org if you wish to
participate.
Best regards,
Xaver Hugl
emctl restart slurmd*
# master
run without any issues afterwards.
Thank you for all your help!
Best regards,
Xaver
On 19.07.23 17:05, Xaver Stiensmeier wrote:
Hi Hermann,
count doesn't make a difference, but I noticed that when I reconfigure
slurm and do reloads afterwards, the er
ameters are
correct, so I assume it must be the gpus entry, but I don't see where
it's wrong:
NodeName=NName SocketsPerBoard=8 CoresPerSocket=1 RealMemory=8000
Gres=gpu:1 State=CLOUD # bibiserv
Thanks for all the help,
Xaver
On 19.07.23 15:04, Hermann Schwärzler wrote:
Hi Xaver,
further. I am thankful for any ideas in that regard.
Best regards,
Xaver
On 19.07.23 10:23, Xaver Stiensmeier wrote:
Alright,
I tried a few more things, but I still wasn't able to get past: srun:
error: Unable to allocate resources: Invalid generic resource (gres)
specification.
I should
=100,max_rpc_cnt=0,max_sched_time=2,partition_job_depth=0,sched_max_job_start=0,sched_min_interval=2
I am a bit unsure what to do next to further investigate this issue.
Best regards,
Xaver
On 17.07.23 15:57, Groner, Rob wrote:
That would certainly do it. If you look at the slurmctld log when
just for testing purposes. Could this be the issue?
Best regards,
Xaver Stiensmeier
On 17.07.23 14:11, Hermann Schwärzler wrote:
Hi Xaver,
what kind of SelectType are you using in your slurm.conf?
Per https://slurm.schedmd.com/gres.html you have to consider:
"As for the --gpu* option, the
(GPU, MPS, MIG) and using one of
those didn't work in my case.
Obviously, I am misunderstanding something, but I am unsure where to look.
Best regards,
Xaver Stiensmeier
:
Allowing all nodes to be powered up, but without automatic suspending
for some nodes except when triggering power down manually.
---
I tried using negative times for SuspendTime, but that didn't seem to
work as no nodes are powered up then.
Best regards,
Xaver Stiensmeier
I can't say anything about the other commits in this series, but
"Document in which order the CTM matrix elements are stored" is
Reviewed-by: Xaver Hugl
I can't say anything about the other commits in this series, but
"Document in which order the CTM matrix elements are stored" is
Reviewed-by: Xaver Hugl
both partitions and allocates
all 8 nodes.
Best regards,
Xaver Stiensmeier
question as my question asks
how to have multiple default partitions which could include having
others that are not default.
Best regards,
Xaver Stiensmeier
On 17.04.23 11:12, Xaver Stiensmeier wrote:
Dear slurm-users list,
is it possible to somehow have two default partitions? In the best cas
Dear slurm-users list,
is it possible to somehow have two default partitions? In the best case
in a way that slurm schedules to partition1 on default and only to
partition2 when partition1 can't handle the job right now.
Best regards,
Xaver Stiensmeier
or
were larger instances started than needed? ...
I know that this question is currently very open, but I am still trying
to narrow down where I have to look. The final goal is of course to use
this evaluation to pick better timeout values and improve cloud scheduling.
Best regards,
Xaver Stiensmeier
nodes.
So I am basically looking for custom requirements.
Best regards,
Xaver Stiensmeier
n" in `JobSubmitPlugins`
and this might be the solution. However, I think this is something so
basic that it probably shouldn't need a plugin so I am unsure.
Can anyone point me towards how setting the default partition is done?
Best regards,
Xaver Stiensmeier
Dear community,
we are currently facing the challenge that some devices at which we import
.p12 certificate containers from our OpenXPKI, are having problems
processing them.
After checking with the vendor of one of the devices, it seems that
OpenXPKI are encrypting the .p12 container with SHA2
ent - close windows and adopt a penguin!
[Anhang "attleugg.txt" gelöscht von Franz-Xaver Birnboeck/KG/Lindner]
[Anhang "att7wvqf.txt" gelöscht von Franz-Xaver Birnboeck/KG/Lindner]
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.
Dear community,
we currently have the challenge that we need a TLS-certificate that has
"IP security end system (1.3.6.1.5.5.7.3.5)" as extended key usage
configured.
Looking at the options in the certificate profiles, we can set a wide
variety of extended usages like code_signing , server_aut
am just stating this to be
maximum explicit.
Best regards,
Xaver Stiensmeier
PS: This is the first time I use the slurm-user list and I hope I am not
violating any rules with this question. Please let me know, if I do.
great!
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to kwin in Ubuntu.
https://bugs.launchpad.net/bugs/1990783
Title:
[radeon] Distorted mouse pointer under Wayland in Kubuntu 22.10
To manage notifications about this bug go to:
https://bu
.
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to kwin in Ubuntu.
https://bugs.launchpad.net/bugs/1990783
Title:
[radeon] Distorted mouse pointer under Wayland in Kubuntu 22.10
To manage notifications about this bug go to:
https://bugs.la
Can someone with an affected setup confirm whether or not it's still an
issue with 5.26?
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to kwin in Ubuntu.
https://bugs.launchpad.net/bugs/1990783
Title:
[radeon] Distorted mouse pointer under
** Summary changed:
- wait_for_server doesn't actually wait till server is state=active
+ wait_for_server doesn't actually wait till server is state=active (mistake,
can be deleted)
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member
Public bug reported:
openstack connection states that wait_for_server "Wait for a server to
reach ACTIVE status." but it doesn't. It waits longer than usual, but
not until server reaches ACTIVE status.
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug not
Public bug reported:
Description: When using connections available_floating_ip(network, server) in
the past it automatically attached an existing un-attached floating-ip (or
created a new one) to the given server.
Now available_floating_ip(network, server) only returns the ip address when
findi
Dear community,
we upgraded to version 3.20 a while ago since we wanted to test out the
new SCEP features, to get some systems working that have problems with it
currently. After we enabled the new scepv3 script in webserver, we get the
following error when trying to request the ca certs via SC
Greetings,
Xaver
zamundaaa added a comment.
If you want to make it official, would you be interested in helping to make
tiling a part of KWin directly? https://invent.kde.org/plasma/kwin/-/issues/10
If it's bult-in then more integration could be done, for example with effects
and the current quick tile syst
schrieb am So. 20. Juni 2021
um 12:00:
> Send NetBehaviour mailing list submissions to
> netbehaviour@lists.netbehaviour.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.netbehaviour.org/mailman/listinfo/netbehaviour
> or, via email, send a message
company it will be lot money
to pay. And you don't know if other companies will money to...
Greetings Xaver
-Ursprüngliche Nachricht-
Von: swinog-boun...@lists.swinog.ch [mailto:swinog-boun...@lists.swinog.ch] Im
Auftrag von roger mgz
Gesendet: Sonntag, 28. Februar 2021 14:53
An: s
1 - 100 of 1154 matches
Mail list logo
