January 2026 - gerrit-log - lists.osmocom.org

[M] Change in pysim[master]: personalization: refactor ConfigurableParameter, Iccid, Imsi
by neels 15 Jan '26

15 Jan '26

Attention is currently required from: dexter, fixeria, laforge, pespin. neels has posted comments on this change by neels. ( https://gerrit.osmocom.org/c/pysim/+/39742?usp=email ) Change subject: personalization: refactor ConfigurableParameter, Iccid, Imsi ...................................................................... Patch Set 15: (1 comment) File pySim/esim/saip/personalization.py: https://gerrit.osmocom.org/c/pysim/+/39742/comment/b19c4092_a565db5d?usp=em… : PS13, Line 50: r"""Base class representing a part of the eSIM profile that is configurable during the > While I'm not a python expert, I agree with fixeria and laforge here, I think fixeria wrote down qui […] Guys, think before jumping on the scrum. ABC is quite shortsighted about abstractness. In C++, abstract is well defined: a member function is NULL and the program will crash. In python, I can even instantiate a class, and then assign a function to it after that. In the particular use case, there are "abstract" classes that have a usable function definition. The concrete implementation then simply sets class member variables to form a useful result. So there is no use in probing whether a function is marked @abstract or not. because if i mark it abstract, i cannot instantiate it. The abstract concept is simply not related to where I can put those ABC decorators! The real landscape of what is useful to a caller is as complex as it is all the time. Callers pick the useful bits from an abundant API. We do not *need* to prevent anyone from instantiating anything. I can imagine scenarios where someone could lose important data when using an abstract database backend, or something. This here is not like that in any way. Using ABC here serves no purpose, and the ABC abstract decorators do not work. As I said, ABC servers no purpose and doesn't work. If you don't follow, then please stop tossing sticks between my legs, because I have spent a few hours thinking about this topic already because you guys will not stop pestering nonsense at me! -- To view, visit https://gerrit.osmocom.org/c/pysim/+/39742?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: pysim Gerrit-Branch: master Gerrit-Change-Id: I6522be4c463e34897ca9bff2309b3706a88b3ce8 Gerrit-Change-Number: 39742 Gerrit-PatchSet: 15 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Thu, 15 Jan 2026 04:21:38 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de> Comment-In-Reply-To: laforge <laforge(a)osmocom.org> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>

1 0

[M] Change in pysim[master]: personalization: make AlgorithmID a new EnumParam
by neels 15 Jan '26

15 Jan '26

Attention is currently required from: laforge. neels has posted comments on this change by neels. ( https://gerrit.osmocom.org/c/pysim/+/40201?usp=email ) Change subject: personalization: make AlgorithmID a new EnumParam ...................................................................... Patch Set 5: (1 comment) Patchset: PS5: > This lokks like a workaround for asn1struct which ahould do this in a generic way based on the ASN. […] (Slight counter argument: This is not a map to the binary representation. These are definitions for the AlgorithmId(EnumParam) caller, let's call it the frontend, so it is semantically correct to be separate from whichever binary representation the backend chooses.) But I agree that it is less shimmy if we can just pick up all possible values from the asn.1 def. My problem: it is highly mysterious to me how to use the asn.1 mappings, because they magically appear without a python definition i can look up. please assist with a quick code snippet, at least a starting point? that would help tremendously, thanks -- To view, visit https://gerrit.osmocom.org/c/pysim/+/40201?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: pysim Gerrit-Branch: master Gerrit-Change-Id: I71c2ec1b753c66cb577436944634f32792353240 Gerrit-Change-Number: 40201 Gerrit-PatchSet: 5 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Comment-Date: Thu, 15 Jan 2026 04:09:21 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: laforge <laforge(a)osmocom.org>

1 0

[M] Change in pysim[master]: personalization: implement reading back values from a PES
by neels 15 Jan '26

15 Jan '26

Attention is currently required from: laforge. neels has posted comments on this change by neels. ( https://gerrit.osmocom.org/c/pysim/+/40198?usp=email ) Change subject: personalization: implement reading back values from a PES ...................................................................... Patch Set 6: (1 comment) File pySim/esim/saip/personalization.py: https://gerrit.osmocom.org/c/pysim/+/40198/comment/6748553e_7e8c1591?usp=em… : PS6, Line 56: de > this is somewhat of a copy of pySim.esim.saip.File. […] thanks for helping, because i could not figure this out. ...actually i still can't figure out the API. I tried to find example callers of file_content_from_tuples() but they simply do not exist. I'm stuck with from_tuples() which doesn't do what i want. Essentially, I need a ProfileElement.get_bytes() function? In detail, how exactly do I improve this caller? for pe in pes.get_pes_for_type('usim'): imsi_pe = pe.decoded.get('ef-imsi', None) if imsi_pe: yield dec_imsi(b2h(file_tuples_content_as_bytes(imsi_pe))) ^^^^^^^^^^^^^^^^^^^ thanks -- To view, visit https://gerrit.osmocom.org/c/pysim/+/40198?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: pysim Gerrit-Branch: master Gerrit-Change-Id: I234fc4317f0bdc1a486f0cee4fa432c1dce9b463 Gerrit-Change-Number: 40198 Gerrit-PatchSet: 6 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Comment-Date: Thu, 15 Jan 2026 03:56:18 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: laforge <laforge(a)osmocom.org>

1 0

[L] Change in pysim[master]: personalization: add param_source.py, implement batch personalization
by neels 15 Jan '26

15 Jan '26

Attention is currently required from: laforge. neels has posted comments on this change by neels. ( https://gerrit.osmocom.org/c/pysim/+/40096?usp=email ) Change subject: personalization: add param_source.py, implement batch personalization ...................................................................... Patch Set 8: (3 comments) File pySim/esim/saip/param_source.py: https://gerrit.osmocom.org/c/pysim/+/40096/comment/770a282b_008ad68b?usp=em… : PS3, Line 33: abstract > plug here the same conclusion i formed about the other is_abstract flag. […] Done https://gerrit.osmocom.org/c/pysim/+/40096/comment/8d6da696_1f0fd0b1?usp=em… : PS3, Line 132: RandomDigitSource > ack Done https://gerrit.osmocom.org/c/pysim/+/40096/comment/41ec6dc4_2a00211f?usp=em… : PS3, Line 133: 'incrementing sequence of digits' > (i never got over it, python used to be so single-quote-y, but at some point linters started making […] Done -- To view, visit https://gerrit.osmocom.org/c/pysim/+/40096?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: pysim Gerrit-Branch: master Gerrit-Change-Id: I497c60c101ea0eea980e8b1a4b1f36c0eda39002 Gerrit-Change-Number: 40096 Gerrit-PatchSet: 8 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Comment-Date: Thu, 15 Jan 2026 02:33:30 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de> Comment-In-Reply-To: laforge <laforge(a)osmocom.org>

1 0

[S] Change in osmo-gsm-manuals[master]: logging: Improve file & stderr log documentation
by pespin 14 Jan '26

14 Jan '26

Hello Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/41843?usp=email to look at the new patch set (#2). The following approvals got outdated and were removed: Verified+1 by Jenkins Builder Change subject: logging: Improve file & stderr log documentation ...................................................................... logging: Improve file & stderr log documentation Change-Id: I90114f634ae0411e58d2f3da86d5a2e470b4d828 --- M common/chapters/logging.adoc 1 file changed, 20 insertions(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-gsm-manuals refs/changes/43/41843/2 -- To view, visit https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/41843?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: osmo-gsm-manuals Gerrit-Branch: master Gerrit-Change-Id: I90114f634ae0411e58d2f3da86d5a2e470b4d828 Gerrit-Change-Number: 41843 Gerrit-PatchSet: 2 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder

1 0

[S] Change in osmo-gsm-manuals[master]: logging: Improve systemd-journal log documentation
by pespin 14 Jan '26

14 Jan '26

pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/41844?usp=email ) Change subject: logging: Improve systemd-journal log documentation ...................................................................... logging: Improve systemd-journal log documentation Change-Id: I9a67b9b8c38868004a794164724cdffc5b86a044 --- M common/chapters/logging.adoc 1 file changed, 18 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-gsm-manuals refs/changes/44/41844/1 diff --git a/common/chapters/logging.adoc b/common/chapters/logging.adoc index 57ffbae..1fa16af 100644 --- a/common/chapters/logging.adoc +++ b/common/chapters/logging.adoc @@ -439,6 +439,24 @@ being passed to systemd. No additional fields will be attached, except the logging level (`PRIORITY`). This mode is similar to _syslog_ and _stderr_. +NOTE: systmed-journal logging target uses libsystemd, which implements _Native +Journal Protocol_ (_AF_UNIX _DATAGRAM_ socket). That socket is internally +configured in synchronous blocking I/O mode, which means transmitting a big +amount of messages or text over it in a short amount of time (before +systemd-journald has time to read it) could potentially block the osmocom +program's thread issuing the logging. libsystemd currently sets the _AF_UNIX_ +socket `SO_SNDBUF` to 8MB, In Linux, the `SO_SNDBUF` value being set on the +socket will be trimmed by the kernel to a maximum allowed by sysctl +`net.core.wmem_max`. Hence, if you want to be on a safer side minimizing +dropping messages or blocking the process (depending on the I/O mode set), make +sure sysctl `net.core.wmem_max` on your system is set to `4194304` (8MB) or +more. Moreover, limits amount of messages queued in _AF_UNIX_ sockets to value +from sysctl `net.unix.max_dgram_qlen`, so you may also want to increase that one +to be on the safe side if planning to log with a high frequency. + +NOTE: Linux Kernel used to have a `net.core.wmem_max` of `212992`(208KB) until +recently (2025, a6d4f25888b83b8300aef28d9ee22765c1cc9b34), where it was +increased to `4194304` (4MB) . ==== Logging to stderr -- To view, visit https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/41844?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-gsm-manuals Gerrit-Branch: master Gerrit-Change-Id: I9a67b9b8c38868004a794164724cdffc5b86a044 Gerrit-Change-Number: 41844 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de>

1 0

[S] Change in osmo-gsm-manuals[master]: logging: Improve file log documentation
by pespin 14 Jan '26

14 Jan '26

pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/41843?usp=email ) Change subject: logging: Improve file log documentation ...................................................................... logging: Improve file log documentation Change-Id: I90114f634ae0411e58d2f3da86d5a2e470b4d828 --- M common/chapters/logging.adoc 1 file changed, 15 insertions(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-gsm-manuals refs/changes/43/41843/1 diff --git a/common/chapters/logging.adoc b/common/chapters/logging.adoc index 849d7bc..57ffbae 100644 --- a/common/chapters/logging.adoc +++ b/common/chapters/logging.adoc @@ -300,9 +300,10 @@ ---- OsmoBSC> enable OsmoBSC# configure terminal -OsmoBSC(config)# log file /path/to/my/file +OsmoBSC(config)# log file /path/to/my/file <1> OsmoBSC(config-log)# ---- +<1> Configure a file logging target writing to /path/to/my/file This leaves you at the config-log prompt, from where you can set the detailed configuration for this log file. The available commands at @@ -310,6 +311,19 @@ `logging filter`, `logging level` as well as `logging color` and `logging timestamp`. +The file logging target will by default use a synchronous non-blocking I/O +write. If writing cannot be performed synchronously (would block), the message +is stored in a workqueue where asynchronous write (driven by poll event loop) +will be performed at a later stage. The file logging target can be configured +during the VTY "log file" VTY command to perform blocking I/O with the +_blocking-io_ parameter. This I/O mode should not be used in any osmocom program +driven by an event loop (which includes any program using a VTY), since it may +block the thread for an un specified (potentially long or event infinite) amount +of time and hence prevent the event loop to run and process events. This I/O +mode should only be used under specific cinrcumstances, like debugging a crash, +in which case it's interesting to get the logging output to the UDP socket and +hence recorded before the program crashes. + TIP: Don't forget to use the `copy running-config startup-config` (or its short-hand `write file`) command to make your logging configuration persistent across application re-start. -- To view, visit https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/41843?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-gsm-manuals Gerrit-Branch: master Gerrit-Change-Id: I90114f634ae0411e58d2f3da86d5a2e470b4d828 Gerrit-Change-Number: 41843 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de>

1 0

[M] Change in osmo-gsm-manuals[master]: logging: Improve GSMTAP log documentation
by pespin 14 Jan '26

14 Jan '26

Hello Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/41842?usp=email to look at the new patch set (#2). The following approvals got outdated and were removed: Verified+1 by Jenkins Builder Change subject: logging: Improve GSMTAP log documentation ...................................................................... logging: Improve GSMTAP log documentation The section about "logs are also duplicated to stderr" is removed because it is not true at all?. Change-Id: I9434939d2a9a41bb0011a067f5ff9b94752fa781 --- M common/chapters/logging.adoc 1 file changed, 52 insertions(+), 10 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-gsm-manuals refs/changes/42/41842/2 -- To view, visit https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/41842?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: osmo-gsm-manuals Gerrit-Branch: master Gerrit-Change-Id: I9434939d2a9a41bb0011a067f5ff9b94752fa781 Gerrit-Change-Number: 41842 Gerrit-PatchSet: 2 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder

1 0

[M] Change in osmo-gsm-manuals[master]: logging: Improve GSMTAP log documentation
by pespin 14 Jan '26

14 Jan '26

pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/41842?usp=email ) Change subject: logging: Improve GSMTAP log documentation ...................................................................... logging: Improve GSMTAP log documentation The section about "logs are also duplicated to stderr" is removed because it is not true at all?. Change-Id: I9434939d2a9a41bb0011a067f5ff9b94752fa781 --- M common/chapters/logging.adoc 1 file changed, 52 insertions(+), 10 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-gsm-manuals refs/changes/42/41842/1 diff --git a/common/chapters/logging.adoc b/common/chapters/logging.adoc index 0b31211..6f22fd3 100644 --- a/common/chapters/logging.adoc +++ b/common/chapters/logging.adoc @@ -215,27 +215,67 @@ ---- OsmoBSC> enable OsmoBSC# configure terminal -OsmoBSC(config)# log gsmtap 192.168.2.3 +OsmoBSC(config)# log gsmtap 192.168.2.3 <1> OsmoBSC(config-log)# ---- +<1> Configure a GSMTAP logging target recording to 192.168.2.3 The hostname/ip argument is optional: if omitted the default 127.0.0.1 will be used. The log strings inside GSMTAP are already supported by Wireshark. Capturing for `port 4729` on appropriate interface will reveal log messages including source file name and line number as well as application. This makes it easy to consolidate logs from several different network components alongside the air frames. You can also use Wireshark to quickly filter logs for a given subsystem, severity, file name etc. +The GSMTAP logging target also has different implementation I/O modes, which can +be configured during the VTY "log gmstap" VTY command: + +nonblocking-io:: + Use non-blocking, synchronous I/O. This is the default mode. It will set + the GSMTAP source socket as non-blocking, and attempt syncrhonous write + to the UDP socket, discarding a message if the UDP socket's send buffer + is full during write. +blocking-io:: + Use blocking, synchronous I/O. It will use the GSMTAP source socket in + blocking mode, and attempt syncrhonous write to the UDP socket, blocking + the entire thread if the UDP socket's send buffer is full during write. + This I/O mode should not be used in any osmocom program driven by an + event loop (which includes any program using a VTY), since it may block + the thread for an un specified (potentially long or event infinite) + amount of time and hence prevent the event loop to run and process + events. This I/O mode should only be used under specific cinrcumstances, + like debugging a crash, in which case it's interesting to get the + logging outputted to the UDP socket and hence recorded before the + program crashes. +wq:: + Workqueue mode: Use non-blocking, asynchronous I/O. It will set the + GSMTAP source socket as non-blocking, and attempt asyncrhonous write to + the UDP socket by means of a work queue driven by the process poll event + loop, delaying writing to the UDP socket until there's enough free space + in its send buffer. Since the workqueue has a maximum size, messages + will be discarded similar to _nonblocking-io_ once the UDP socket's send + buffer *and* the GSMTAP log target workqueue are full, messages. This + I/O mode provides some extra buffering space in the userspace workqueue, + at the expense of extra overhead and delay to transmit messages + asynchronously waiting for POLLOUT event from the UDP socket. + +In any of the I/O mode above, the UDP socket send buffer size of the GSMTAP log +target influences where messages may be dropped (_nonblocking-io_|_wq_) or the +process blocked (_blocking-io_) whenever a high number of messages or test are +transmitted in a short time. For that reason, the GSMTAP log target will attempt +to set the `SO_SNDBUF` sockopt of the UDP socket to 4MB. In Linux, the +`SO_SNDBUF` value being set on the socket will be trimmed by the kernel to a +maximum allowed by sysctl `net.core.wmem_max`. Hence, if you want to be on a +safer side minimizing dropping messages or blocking the process (depending on +the I/O mode set), make sure sysctl `net.core.wmem_max` on your system is set to +`4194304` (4MB) or more. + +NOTE: Linux Kernel used to have a `net.core.wmem_max` of `212992`(208KB) until +recently (2025, a6d4f25888b83b8300aef28d9ee22765c1cc9b34), where it was +increased to `4194304` (4MB) . + [[fig-wireshark-gsmtap-log]] .Wireshark with logs delivered over GSMTAP image::./common/images/wireshark-gsmtap-log.png[] -Note: the logs are also duplicated to stderr when GSMTAP logging is configured because stderr is the default log target which is -initialized automatically. To descrease stderr logging to absolute minimum, you can configure it as follows: ----- -OsmoBSC> enable -OsmoBSC# configure terminal -OsmoBSC(config)# log stderr -OsmoBSC(config-log)# logging level force-all fatal ----- NOTE: Every time you generate GSMTAP messages and send it to a unicast (non-broadcast/multicast) IP address, please make sure that the destination IP address actually has a socket open on the specified port, or drops @@ -244,7 +284,9 @@ arriving at the source (the host on which you run the Osmocom software sending GSMTAP), suppress generation of further GSMTAP messages for some time, resulting in incomplete files. In case of doubt, either send GSMTAP to multicast IP addresses, or run something like `nc -l -u -p 4729 > /dev/null` on the destination host to -open the socket at the GSMTAP port and discard anything arriving at it. +at the GSMTAP port and discard anything arriving at it. If the GSMTAP recording address is identified as a +local address, upon creation of the GSMTAP log target, an attempt will be made to create a dummy sink socket +to avoid such problems automatically. ==== Logging to a file -- To view, visit https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/41842?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-gsm-manuals Gerrit-Branch: master Gerrit-Change-Id: I9434939d2a9a41bb0011a067f5ff9b94752fa781 Gerrit-Change-Number: 41842 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de>

1 0

[XS] Change in docker-playground[master]: jenkins-common: use debian 13 by default
by osmith 14 Jan '26

14 Jan '26

osmith has submitted this change. ( https://gerrit.osmocom.org/c/docker-playground/+/41839?usp=email ) Change subject: jenkins-common: use debian 13 by default ...................................................................... jenkins-common: use debian 13 by default The testsuites were still using debian 12, switch to the current stable version (13). This also gives us a much newer bpftrace version: * Debian 12: 0.17.0-1 * Debian 13: 0.23.2-1 Change-Id: I231e1e93724faf6d659132be9b9d0e164502bf95 --- M jenkins-common.sh 1 file changed, 1 insertion(+), 1 deletion(-) Approvals: osmith: Looks good to me, approved Jenkins Builder: Verified pespin: Looks good to me, but someone else must approve diff --git a/jenkins-common.sh b/jenkins-common.sh index 57d2190..46b8891 100644 --- a/jenkins-common.sh +++ b/jenkins-common.sh @@ -1,6 +1,6 @@ CACHE_DIR="$(realpath ../_cache)" KERNEL_TEST_DIR="$(realpath ../scripts/kernel-test)" -DEBIAN_DEFAULT="bookworm" +DEBIAN_DEFAULT="trixie" SUB4_PREFIX="172.18" SUB6_PREFIX="fd02:db8" -- To view, visit https://gerrit.osmocom.org/c/docker-playground/+/41839?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: docker-playground Gerrit-Branch: master Gerrit-Change-Id: I231e1e93724faf6d659132be9b9d0e164502bf95 Gerrit-Change-Number: 41839 Gerrit-PatchSet: 2 Gerrit-Owner: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>

1 0

2026

2025

2024

2023

2022

gerrit-log January 2026