Logging: Add interface with default glog implementation #4085

justadreamer · 2024-12-04T00:35:34Z

This PR introduces a logger shim and was meant to accompany a more global proposal: #4084. With this different loggers can be swapped in compile-time, however leaving the possibility to also swap a global instance in runtime (during tests f.e.)

The global object is instantiated in logger/logger.go, the interface is defined in logger/interface.go, while implementations of loggers are in logger/default.go and logger/alternative.go.

hhhjort · 2024-12-04T19:19:49Z

I think we want to add something about the compile time usage of this feature to the README. Mention the default, and how to compile the alternate logger in.

justadreamer · 2024-12-06T16:09:09Z

@bsardo mentioned that a similar thing is done with the time package - will take a look

SyntaxNode

@zhongshixi This is very similar to an idea you wanted to implement. Could you please review this PR instead and share your views?

SyntaxNode · 2025-01-09T21:20:12Z

.semgrep/adapter/package-import.go

 	"github.com/mitchellh/copystructure"
 	// ruleid: package-import-check
-	"github.com/golang/glog"
+	"github.com/prebid/prebid-server/v3/di"


This code tests the semgrep rule. Please review the rule to check if any changes to the semgrep definition is required,

the semgrep rule seems to be checking that either of glog or copystructure packages is not used in the adapters, so I reverted this change to the package-import.go.

SyntaxNode · 2025-01-09T21:24:07Z

di/di.go

@@ -0,0 +1,8 @@
+package di


I prefer if this is called the "logger" package, which is more intuitive. I don't know if we'd want to put all global state items in one package and currently there is only one. For simplicity, I'd like to see the interfaces and providers packages collapsed up to this level under the same "logger" package.

SyntaxNode · 2025-01-09T21:33:46Z

di/interfaces/log.go

@@ -0,0 +1,18 @@
+package interfaces
+
+type ILogger interface {


Nitpick: The Java / C# naming convention does not apply to Go. It is most appropriate to name this "Logger".

SyntaxNode · 2025-01-09T21:35:48Z

di/providers/log/default.go

+	"github.com/prebid/prebid-server/v3/di/interfaces"
+)
+
+type GlogWrapper struct {


Nitpick: GlogLogger would be more direct name.

SyntaxNode · 2025-01-09T21:40:41Z

di/providers/log/alternative.go

@@ -0,0 +1,74 @@
+//go:build custom_logger


This project does not currently use build directives to choose features. Instead, we offer a configuration system.

I like the idea of having a global log variable to override. I've seen the same in other Go projects, and it provides support for #3961. I propose to keep this ability, while also providing a config option to switch to slog from glog.

This build tag is actually not required, it's just one potential mechanism that could be used to swap a dependency in compile time, so can probably removed. Configuration would require shipping both implementations and then have them swapped in runtime depending on the configuration, while compile time would only ship a single dependency. Just to be clear, by configuration - do you mean a host-level config file pbs.yaml / pbs.json right?

bsardo · 2025-02-17T04:19:44Z

@justadreamer we'll try to revisit this in a few weeks. Sorry for the delay.

bsardo · 2025-04-14T18:01:04Z

This was discussed at the last engineering subcommittee meeting. The suggestion was to move from a compile time config to a runtime config.

…tructure of the logger: encapsulate the logger object, call only external functions

# Conflicts: # modules/fiftyonedegrees/devicedetection/device_info_extractor.go

hhhjort

LGTM

linux019

Consider to use build flags to include only one logging lib instead of bringing up more libs to the project codebase

linux019 · 2025-06-09T16:05:35Z

logger/alternative.go

+}
+
+func (logger *SlogWrapper) Info(args ...any) {
+	msg := fmt.Sprint(args...)


The issue with this logger that glog or fmt.Sprintf use sync.Pool with buffer reuse but this logger always allocates a string to store message and pass it to the underlying function. At least this package should use sync.Pool to store formatted msg to bypass GC

buf := new(bytes.Buffer) // get it from sync.Pool msg := fmt.Fprintf(buf, args...) //it takes io.Writer slog.Info(buf.String()) // better to pass io.Reader instead of the string // put buf back to pool

this file will be removed as @bsardo mentioned on the call. build tags were used originally and were discarded by the committee in favor of runtime configuration.

bsardo · 2025-06-09T02:48:24Z

config/config.go

 		return nil, err
 	}

+	logger.New(c.Logger.Type, c.Logger.Depth)


We should validate Type is a valid string value

Type validation added

bsardo · 2025-06-09T14:30:32Z

README.md

+This can be done compile-time in the `logger` package.
+It contains `Logger` interface definition and `default` and `alternative` implementation.
+The `default` logger implementation based on `github.com/golang/glog` package.
+The `alternative` logger implementation based on `log/slog` package.


Delete line since we are proposing removing the alternative logger implementation for now.

bsardo · 2025-06-09T14:52:57Z

config/config.go

+type Logger struct {
+	// the type of logger: default or alternative
+	Type  string `mapstructure:"type"`
+	Depth *int   `mapstructure:"depth"`


I'm curious why this is a pointer? I imagine you want to detect presence for some reason. Is it because you want to know whether to apply some default depth if depth is not specified? What should the default be? Do you think it will dependent on the implementation?

I see you're detecting presence via a nil check and have declared a default depth of 1 in logger.go.

Should we verify that depth is > 0 or >= 0? What happens if depth is some large number? Perhaps validation is needed for the upper bound as well?

Should we verify that depth is > 0 or >= 0? What happens if depth is some large number? Perhaps validation is needed for the upper bound as well?

Fun fact: glog has no depth validation within itself:
https://github.com/golang/glog/blob/master/glog.go#L432

Re-check source code will show the same.

// If Depth is present, this function calls log from a different depth in the call stack. // This enables a callee to emit logs that use the callsite information of its caller // or any other callers in the stack. When depth == 0, the original callee's line // information is emitted. When depth > 0, depth frames are skipped in the call stack // and the final frame is treated like the original callee to Info.

I've tested with different values.
What I've got:

-1000
glog.ErrorDepth(-1000, "Hello World")

Log:
extern.go:304] Hello World

0
glog.ErrorDepth(0, "Hello World")

Log:
main.go:8] Hello World

1000
glog.ErrorDepth(0, "Hello World")

Log:
???:1] Hello World

I don't know in what range to validate the value, because glog doesn't have such validation, and the current implementation doesn't have any alternatives for it now.

bsardo · 2025-06-09T14:54:25Z

logger/default.go

+	glog.FatalDepthf(logger.depth, format, args...)
+}
+
+func ProvideDefaultLogger(depth int) Logger {


Nitpick: maybe call this NewDefaultLogger to follow patterns throughout the code base?

bsardo · 2025-06-09T16:10:42Z

logger/interface.go

+	Warning(args ...any)
+	Warningf(format string, args ...any)
+	Warningln(args ...any)


Do we need Warningln? The default implementation is the same as Warning.

bsardo · 2025-06-13T19:22:38Z

logger/alternative.go

Let's delete this file. We can add an slog implementation in the future. For now, simply defining the logger interface and the glog implementation suffices.
In the future we will expand the interface to include functions that are more suitable for structured logging .

# Conflicts: # stored_requests/backends/http_fetcher/fetcher.go # stored_requests/config/config.go

…with thread-safe operations; introduced extensive unit tests for the new logger structure.

…r module

…ger type; updated README for clarity

postindustria-code · 2025-10-20T12:52:13Z

Changes to the logger for PHASE 1:

Updated README.md
Removed the slog implementation and the custom logger integration
Kept the following logger interfaces:

Debug
Info
Warn
Error
Fatal – it wasn’t listed originally, but I believe it must be included in the implementation

All other methods (logger calls with context) were removed.

Updated the logger tests
Updated all logger calls (checked three times, seems like nothing was missed)
Verified all tests for the modified files — everything ran without errors

scr-oath · 2025-10-27T16:36:27Z

Comprehensive Review: Logger Abstraction Phase 1

I've reviewed PR #4085 with golang-pro, code-reviewer, and refactoring-specialist perspectives. Here's the synthesis:

🎯 Executive Summary

This phase 1 logger abstraction is well-structured and follows sound incremental refactoring principles.

Most importantly: Your preference to keep "f" suffixes (Errorf, Infof, Warningf) is CORRECT and essential for the eventual slog migration.

✅ Why the "f" Suffix Decision is Right

Phase 1 (current):

logger.Infof("formatted %s", value)   // Printf-style formatted logging
logger.Errorf("error: %v", err)       // Printf-style formatted logging

Phase 2 (future with structured logging):

// Formatted logging - legacy compatibility
logger.Infof("formatted %s", value)

// Structured logging - new slog style
logger.Info("message", "key", value, "error", err)

Why this naming is essential:

✅ Prevents naming conflicts: Infof (formatted) vs Info (structured) are distinct
✅ Self-documenting: The "f" makes it clear this is Printf-style formatting
✅ Go conventions: Follows fmt.Printf, log.Printf, testing.T.Logf patterns
✅ Migration path: Easy to identify legacy calls: grep -r "logger.*f("
✅ Industry standard: zap, zerolog, logrus all use this pattern

All major Go logging libraries use this pattern:

zap: Infow() (structured) vs Infof() (formatted)
zerolog: Info().Msg() vs Info().Msgf()
logrus: Info() (structured) vs Infof() (formatted)

✅ Strengths

Solid Incremental Refactoring: Phase 1 (syntax compatibility) → Phase 2 (structured logging)
Behavior Preservation: Maintains glog semantics (depth, exit behavior)
Clean Architecture: Interface-based design with clear separation
Comprehensive Migration: Covers 50+ files consistently

📋 Key Findings on Existing Comments

Depth Parameter Discussion

The depth parameter discussion is valid. Current implementation is appropriate - glog handles excessive depth gracefully (shows ???:1), so no upper bound validation is needed. The default value and validation logic are correct.

Type Validation

Good work by @postindustria-code adding type validation. Consider making it more type-safe with constants in future iterations.

Alternative Logger Removal

Correct decision to remove alternative.go for phase 1. Build tags add complexity without current value. Runtime configuration is more flexible.

Warningln Removal

Good call removing Warningln - it was redundant. Keep the interface minimal.

📝 Minor Recommendations

Documentation: Clarify phase 1 vs phase 2 distinction in README
Testing: Add test helper for swapping logger in tests
Interface: Consider adding Flush() method for clean shutdowns
Linting: Add semgrep/golangci-lint rule to prevent direct glog imports

🎯 Final Verdict

Strong approval. The "f" suffix decision is architecturally correct.

This PR demonstrates excellent refactoring discipline:

✅ Clear phase 1 scope (abstraction only)
✅ Proper naming for future evolution
✅ Comprehensive but reviewable changes
✅ Sets up phase 2 success

All three specialized review perspectives (golang-pro, code-reviewer, refactoring-specialist) concur: keep the "f" suffixes.

Great work on a well-executed phase 1! This sets up an excellent foundation for the eventual slog migration.

scr-oath · 2025-10-27T16:43:12Z

FYI - the previous comment was from 🤖 Claude - I had prompted with a preference to stay with Errorf for the glog since all other major logging solutions (including glog, the thing we're replacing) keep the "f" for "format" and have some other alternative - Error (without any suffix) in slog or Errorw (in zap) - I don't know if I like the w it was for zap's "sugared logger" (the one that does formatting) to do "with" like syntax.

I Believe that for formatted loggers and specifically this PR, we should stick with the f suffix. The only change in call-sites should be glog ⇒ logger

scr-oath · 2025-10-27T16:45:17Z

logger/interface.go

+type Logger interface {
+	// Debug level logging
+	Debug(msg string, args ...any)
+
+	// Info level logging
+	Info(msg string, args ...any)
+
+	// Warn level logging
+	Warn(msg string, args ...any)
+
+	// Error level logging
+	Error(msg string, args ...any)
+
+	// Fatal level logging
+	Fatal(msg string, args ...any)
+}


Suggested change

type Logger interface {

// Debug level logging

Debug(msg string, args ...any)

// Info level logging

Info(msg string, args ...any)

// Warn level logging

Warn(msg string, args ...any)

// Error level logging

Error(msg string, args ...any)

// Fatal level logging

Fatal(msg string, args ...any)

}

type Logger interface {

// Debug level logging

Debugf(msg string, args ...any)

// Info level logging

Infof(msg string, args ...any)

// Warn level logging

Warnf(msg string, args ...any)

// Error level logging

Errorf(msg string, args ...any)

// Fatal level logging

Fatalf(msg string, args ...any)

}

scr-oath · 2025-10-27T16:46:27Z

logger/logger.go

+// Debug level logging
+func Debug(msg string, args ...any) {
+	logger.Debug(msg, args...)
+}
+
+// Info level logging
+func Info(msg string, args ...any) {
+	logger.Info(msg, args...)
+}
+
+// Warn level logging
+func Warn(msg string, args ...any) {
+	logger.Warn(msg, args...)
+}
+
+// Error level logging
+func Error(msg string, args ...any) {
+	logger.Error(msg, args...)
+}
+
+// Fatal level logging and terminates the program execution.
+func Fatal(msg string, args ...any) {
+	logger.Fatal(msg, args...)
+}


Suggested change

// Debug level logging

func Debug(msg string, args ...any) {

logger.Debug(msg, args...)

}

// Info level logging

func Info(msg string, args ...any) {

logger.Info(msg, args...)

}

// Warn level logging

func Warn(msg string, args ...any) {

logger.Warn(msg, args...)

}

// Error level logging

func Error(msg string, args ...any) {

logger.Error(msg, args...)

}

// Fatal level logging and terminates the program execution.

func Fatal(msg string, args ...any) {

logger.Fatal(msg, args...)

}

// Debugf level logging

func Debugf(msg string, args ...any) {

logger.Debug(msg, args...)

}

// Infof level logging

func Infof(msg string, args ...any) {

logger.Info(msg, args...)

}

// Warnf level logging

func Warnf(msg string, args ...any) {

logger.Warn(msg, args...)

}

// Errorf level logging

func Errorf(msg string, args ...any) {

logger.Error(msg, args...)

}

// Fatalf level logging and terminates the program execution.

func Fatalf(msg string, args ...any) {

logger.Fatal(msg, args...)

}

scr-oath

So close - just change the names to add the f like glog and log.Printf have to differentiate formatted logs from the followup work to add structured logs. call sites should only change from glog to our logger module.

scr-oath · 2025-10-28T15:58:57Z

analytics/pubstack/eventchannel/sender.go

 		req, err := http.NewRequest(http.MethodPost, endpoint, bytes.NewReader(payload))
 		if err != nil {
-			glog.Error(err)
+			logger.Error(err.Error())


Suggested change

logger.Error(err.Error())

logger.Error("%v", err)

scr-oath · 2025-10-28T15:59:09Z

analytics/pubstack/eventchannel/sender.go

 	endpoint, err := url.Parse(baseUrl)
 	if err != nil {
-		glog.Error(err)
+		logger.Error(err.Error())


Suggested change

logger.Error(err.Error())

logger.Error("%v", err)

bsardo · 2025-10-28T15:43:29Z

config/structlog.go

+		logInternal.Error("LogStruct called on type %s, whuch is not a struct!", v.Type().String())
+		logger("LogStruct called on type %s, whuch is not a struct!", v.Type().String())
+		os.Exit(1)


Let's add a Fatalf instead of calling os.Exit(1) here.

…ated the interface implementation; Updated logger calls with a new signature

bsardo

This is looking good, just a couple of quick comments.

bsardo · 2025-11-11T15:10:34Z

config/structlog.go

 func logStructWithLogger(v reflect.Value, prefix string, logger logMsg) {
 	if v.Kind() != reflect.Struct {
-		glog.Fatalf("LogStruct called on type %s, whuch is not a struct!", v.Type().String())
+		logger("LogStruct called on type %s, whuch is not a struct!", v.Type().String())


Is this line needed? Did you determine this was just missing so you decided to add it?

I replaced the glog call with our internal logger

Yes but I see two logger calls in sequence now

logger("LogStruct called on type %s, whuch is not a struct!", v.Type().String()) logInternal.Fatalf("LogStruct called on type %s, whuch is not a struct!", v.Type().String())

I think we can delete logger("LogStruct called on type %s, whuch is not a struct!", v.Type().String()) and just have the fatal call.

bsardo · 2025-11-11T15:10:47Z

config/structlog.go

 func logMapWithLogger(v reflect.Value, prefix string, logger logMsg) {
 	if v.Kind() != reflect.Map {
-		glog.Fatalf("LogMap called on type %s, whuch is not a map!", v.Type().String())
+		logger("LogMap called on type %s, whuch is not a map!", v.Type().String())


Is this line needed? Did you determine this was just missing so you decided to add it?

I replaced the glog call with our internal logger

Same comment as above.

bsardo · 2025-11-11T15:16:12Z

main.go


 func main() {
-	flag.Parse() // required for glog flags and testing package flags
+	flag.Parse() // required for di.Log flags and testing package flags


What is di? Is this left over from a previous iteration of this PR?

Yes, you are right, this is a leftover from the previous implementation and is no longer relevant. Removed.

bsardo · 2025-11-11T15:28:45Z

logger/glog_test.go

+	}, "Debug with args should not panic")
+}
+
+func TestGlogLogger_Info(t *testing.T) {


Can we add a test for Fatal?

that can be tricky - but I've seen/written similar in other libraries that exit with a setting for whether fatal uses os.Exit or panic. If set to panic for testing, that can be easily caught and verified.

Fatal test added

bsardo · 2025-11-11T15:33:03Z

logger/logger_test.go

+	assert.True(t, ok, "Default logger should be *GlogLogger")
+}
+
+func TestDebug(t *testing.T) {


Can we add a fatal test?

Fatal test added

scr-oath · 2025-11-24T18:42:47Z

logger/glog.go

+
+func NewGlogLogger() Logger {
+	return &GlogLogger{
+		depth: 1,


question (not-blocking), should there be a way to set the depth? Would that be an interface on the logger or in the New method itself… Would we want to consider the Functional Options Pattern or a single config object that could be passed that knows to choose default values for any "zero" (uninitialized) fields?

Judging by the implementation phases, in the current phase 1

PHASE 1: interface with just the nonstructured logging functions (call it Error, Warning, Info, etc) swap out all calls to glog library with the nonstructured logging function calls from the glog concrete implementation

we are not implementing the logger settings at this stage.
Judging by the phase 2 description

PHASE 2 (should span multiple smaller PRs): host config option to choose logger type (just glog or slog, glog is the default) expand interface to include structured logging functions (ErrorS, WarningS, InfoS etc) add slog concrete implementation that implements the interface structured logging functions add shim so nonstructured calls when slog is enabled are converted to structured logging and vice versa slog conversion to text just sprintf msg glog conversion to structured (TBD) going forward, authors can either call the glog or the slog function

the settings will be implemented during the implementation of phase 2
in fact, in phase 2 we can decide which parameters we can specify and which methods will be added for them.

But you are absolutely right, this method will be needed in the future for full configuration of the logger.

scr-oath · 2025-11-24T18:43:59Z

logger/glog_test.go

+	}, "Debug with args should not panic")
+}
+
+func TestGlogLogger_Info(t *testing.T) {


that can be tricky - but I've seen/written similar in other libraries that exit with a setting for whether fatal uses os.Exit or panic. If set to panic for testing, that can be easily caught and verified.

bsardo · 2025-11-24T20:54:46Z

logger/logger_test.go

+		<-done
+	}
+
+	assert.Equal(t, 10, len(mock.infoCalls), "Should have 10 info calls from concurrent execution")


Is this test flaky or is something wrong? The test is failing in the the validate github action workflow.

I deleted this test because it runs correctly locally.

…f tests

postindustria-code · 2025-11-25T10:59:21Z

@bsardo @scr-oath

Updated the current branch with master
Removed obsolete code
Added tests for the Fatal method
Removed the broken test

Please review again

postindustria-code · 2025-11-25T11:00:53Z

The action also crashes due to problems with the publishonly.yml file.

bsardo · 2025-11-25T14:06:13Z

main.go

 }

 func main() {
-	flag.Parse() // required for glog flags and testing package flags


This is still needed so other flags may be passed in at startup.

Reverted the changes back

…ithLogger, replacing them with Fatalf for stricter error handling

PoC: light-weight compile time dependency injection for logger

1f0f6a8

This was referenced Dec 4, 2024

PBS-Go: Use global objects through shims to be able to swap implementations #4084

Open

Do not include hooks from disabled modules into execution plan #3829

Open

update README, rename provider files

1a01e27

SyntaxNode reviewed Jan 9, 2025

View reviewed changes

Merge branch 'master' into feat/di

6a4223a

justadreamer changed the title ~~PoC: light-weight compile time dependency injection for logger~~ PoC: global shim for logger Jan 13, 2025

logger shim: address review comments

bcc740b

justadreamer mentioned this pull request Feb 21, 2025

PBS attempts to build execution plan for hooks from disabled modules #3748

Open

bsardo added the do not port label Feb 27, 2025

justadreamer mentioned this pull request Apr 18, 2025

Proposal of type Logger interface instead of glog implementation #2951

Open

Marycka9 added 4 commits April 18, 2025 15:57

[Issue 4085] - Added logger config; Changed README.md; Modified the s…

751d703

…tructure of the logger: encapsulate the logger object, call only external functions

[Issue 4085] - Replaces logger calls

fd98c14

Merge branch 'master' into feat/di

b88a31d

# Conflicts: # modules/fiftyonedegrees/devicedetection/device_info_extractor.go

[Issue 4085] - Merge dependencies fix

efde5ad

bsardo assigned bsardo and hhhjort Apr 28, 2025

hhhjort previously approved these changes Apr 28, 2025

View reviewed changes

linux019 reviewed Jun 9, 2025

View reviewed changes

bsardo reviewed Jun 13, 2025

View reviewed changes

Marycka9 added 2 commits July 7, 2025 10:58

Merge branch 'master' into feat/di

51d4bba

# Conflicts: # stored_requests/backends/http_fetcher/fetcher.go # stored_requests/config/config.go

[Issue 4085] - Refactored logger architecture; added LoggerManager …

f997290

…with thread-safe operations; introduced extensive unit tests for the new logger structure.

Marycka9 dismissed hhhjort’s stale review via f997290 July 10, 2025 07:43

Marycka9 and others added 3 commits July 10, 2025 10:47

[Issue 4085] - Removed unused SlogWrapper implementation from logge…

d2cb565

…r module

[Issue 4085] - Added default logger configuration; removed unused log…

1340e80

…ger type; updated README for clarity

Merge remote-tracking branch 'origin/master' into feat/di

39b8c59

[Issue 4085] - Removed unused config logger.type

adc8372

scr-oath self-requested a review October 27, 2025 16:43

scr-oath reviewed Oct 27, 2025

View reviewed changes

scr-oath requested changes Oct 27, 2025

View reviewed changes

bsardo assigned scr-oath and unassigned hhhjort Oct 28, 2025

scr-oath requested changes Oct 28, 2025

View reviewed changes

bsardo reviewed Oct 28, 2025

View reviewed changes

postindustria-code added 5 commits October 29, 2025 13:42

Merge branch 'master' into feat/di

bcb8417

[Issue 4085] - Updated the logger interface - added the F suffix; Upd…

1b9f8c2

…ated the interface implementation; Updated logger calls with a new signature

Merge branch 'master' into feat/di

95f53b5

[Issue 4085] - Updated doc comments in logger interface

048d809

Merge branch 'prebid:master' into feat/di

553a8ab

bsardo changed the title ~~PoC: global shim for logger~~ Logging: Add interface with default glog implementation Nov 11, 2025

bsardo reviewed Nov 11, 2025

View reviewed changes

scr-oath self-requested a review November 24, 2025 18:38

scr-oath previously approved these changes Nov 24, 2025

View reviewed changes

bsardo reviewed Nov 24, 2025

View reviewed changes

postindustria-code added 2 commits November 25, 2025 11:08

Merge branch 'master' into feat/di

e0bae78

[Issue 4085] - Refactor logger comments for consistency and add Fatal…

9fe0516

…f tests

postindustria-code dismissed scr-oath’s stale review via 9fe0516 November 25, 2025 10:38

bsardo reviewed Nov 25, 2025

View reviewed changes

postindustria-code added 2 commits November 25, 2025 16:12

[Issue 4085] - Add flag parsing for glog flags in main function

a04c7ac

[Issue 4085] - Remove logger calls in logStructWithLogger and logMapW…

1e67a50

…ithLogger, replacing them with Fatalf for stricter error handling

Logging: Add interface with default glog implementation #4085

Are you sure you want to change the base?

Logging: Add interface with default glog implementation #4085

Conversation

justadreamer commented Dec 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hhhjort commented Dec 4, 2024

Uh oh!

justadreamer commented Dec 6, 2024

Uh oh!

SyntaxNode left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bsardo commented Feb 17, 2025

Uh oh!

bsardo commented Apr 14, 2025

Uh oh!

hhhjort left a comment

Choose a reason for hiding this comment

Uh oh!

linux019 left a comment

Choose a reason for hiding this comment

Uh oh!

linux019 Jun 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

postindustria-code Jul 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

postindustria-code commented Oct 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

justadreamer commented Dec 4, 2024 •

edited

Loading

linux019 Jun 9, 2025 •

edited

Loading

postindustria-code Jul 10, 2025 •

edited

Loading

postindustria-code commented Oct 20, 2025 •

edited

Loading