profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/postwait/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Theo Schlossnagle postwait @circonus @circonus-labs On the run http://lethargy.org/~jesus/ Founder Circonus. Founded OmniTI, Sparkpost, Fontdeck. ACM Queue co-chair. ACM Practitioners Board Member. ACM Member at Large.

omniti-labs/jsend 560

JSend is a specification for a simple, no-frills, JSON based format for application-level communication.

circonus-labs/circllhist-paper 8

Analysis of non-dynamic log-linear quantization in histograms

postwait/httpf 5

Solaris HTTP accept filters

circonus-labs/metrics-circonus 3

A Java Metrics integration for metrics and dropwizard.

postwait/libtz 3

A super-simple, super-minimal UNIX -> timezone library.

postwait/flot 1

Attractive Javascript charts for jQuery

postwait/gofq 1

A Go Fq client

postwait/leo 1

Automatic setup and configuration systems for nad

postwait/.tmux 0

Oh My Tmux! My pretty + versatile tmux configuration that just works (imho the best tmux configuration)

Pull request review commentapache/trafficserver

Add pointer/reference upcast function that is checked in debug builds.

 inkcoreapi void _ink_assert(const char *a, const char *f, int l) TS_NORETURN;  #ifdef __cplusplus }-#endif /* __cplusplus */ -/* workaround a bug in the  stupid Sun preprocessor+/*+Use dbg_dyn_cast() to do pointer/reference dynamic upcasts with checked dynamic_cast in debug builds, and with+static_cast in release (optimized) builds.  Use examples:++class A { public: virtual ~A(); };+class B : public A {};+B * foo(A *a) { return dbg_dyn_cast<B>(a); }+B & foo2(A &a) { return dbg_dyn_cast<B>(a); }+B const & foo3(A const &a) { return dbg_dyn_cast<B const>(a); } -#undef assert-#define assert __DONT_USE_BARE_assert_USE_ink_assert__-#define _ASSERT_H-#undef __ASSERT_H__-#define __ASSERT_H__ */++template <class Derived, class Base>+Derived *+dbg_dyn_cast(Base *b)

I was thinking this would only be used in cases where b was expected to never be null.

I think I understand where to use this. I was trying to say the name is confusing. People use static_cast in those cases, like the code for non-debug build does, and the behavior is more like static_cast since it never returns null, but it has dyn(amic) in its name. Why do we want to call it a kind of dynamic_cast?

I'd suggest dbg_static_cast or something doesn't mention dynamic nor static.

ywkaras

comment created time in 2 hours

push eventapache/trafficserver

Susan Hinrichs

commit sha 8977a45054302b37bcc0d0a1cca3ad2dae98df6a

Fix the final consumer write size from unchunked to chunked tunnel (#7577)

view details

push time in 3 hours

PR merged apache/trafficserver

Fix the final consumer write size from unchunked to chunked tunnel HTTP

Another issue I ran into with the H2 to origin work. This case may not occur outside of that.

Client is Http/1.1. Server is Http/2. The server returns a header with no content length set, so the data is coming back in a series of data chunks. Thus, it must be returned to the client chunked. The response tunnel is set up for do_chunking. That all works well, but the final call on the consumer side of the tunnel sets the total number of bytes read incorrectly. It only sets the number of data bytes. It does not include the header bytes which is tracked by p->chunked_handler.skip_bytes.

In my case, only 5 bytes were being returned to the client. From the client's perspective, it looked like a stall.

+4 -2

7 comments

1 changed file

shinrich

pr closed time in 3 hours

pull request commentapache/trafficserver

Build the test library for tls_engine consistently

[approve ci autest]

shinrich

comment created time in 3 hours

PR opened apache/trafficserver

Build the test library for tls_engine consistently AuTest

@bneradt fixed all the other tests so that the supporting programs and libraries are built in the main build. This PR fixes up the remaining test library, async_engine.so to be built the same way.

+317 -2

0 comment

3 changed files

pr created time in 4 hours

Pull request review commentapache/trafficserver

Add pointer/reference upcast function that is checked in debug builds.

 inkcoreapi void _ink_assert(const char *a, const char *f, int l) TS_NORETURN;  #ifdef __cplusplus }-#endif /* __cplusplus */ -/* workaround a bug in the  stupid Sun preprocessor+/*+Use dbg_dyn_cast() to do pointer/reference dynamic upcasts with checked dynamic_cast in debug builds, and with+static_cast in release (optimized) builds.  Use examples:++class A { public: virtual ~A(); };+class B : public A {};+B * foo(A *a) { return dbg_dyn_cast<B>(a); }+B & foo2(A &a) { return dbg_dyn_cast<B>(a); }+B const & foo3(A const &a) { return dbg_dyn_cast<B const>(a); } -#undef assert-#define assert __DONT_USE_BARE_assert_USE_ink_assert__-#define _ASSERT_H-#undef __ASSERT_H__-#define __ASSERT_H__ */++template <class Derived, class Base>+Derived *+dbg_dyn_cast(Base *b)

Hmm I was thinking this would only be used in cases where b was expected to never be null. Probably I should have noted that in the comments.

ywkaras

comment created time in 4 hours

pull request commentapache/trafficserver

Rollback LAZY_BUF_ALLOC remove in HttpTunnel

If this makes the flow control happier, looks good to me.

masaori335

comment created time in 4 hours

PR opened apache/trafficserver

Change the default value for verify.server.policy Configuration Incompatible

Change the default of verify.server.policy from PERMISSIVE to STRICT

I assume this is an incompatible change.

This closes issue #7474

+2 -2

0 comment

2 changed files

pr created time in 4 hours

issue openedconcurrencykit/ck

Riscv support

Is there any plan to support Riscv?

created time in 4 hours

PR opened apache/trafficserver

Reviewers
Fix crash in open_close_h2 AuTest Crash HTTP/2

Found this while running autest against 9.0.x. About half the time I'd get a crash from open_close_h2. A later version of the crash is below. During debugging I added an assert to verify that the read_vio.cont was the the Http2 session. In the origin crash, the read_vio.cont was the Http2ClientSession, so after reading the request header, the READ_COMPLETE was sent to the Http2ClientSession which caused it to try and read another frame, even though there was no more data in the buffer. This caused it to interpret a frame of a bogus type.

(gdb) bt
#0  0x00002acaf252e3d7 in raise () from /lib64/libc.so.6
#1  0x00002acaf252fac8 in abort () from /lib64/libc.so.6
#2  0x00002acaefaa40c8 in ink_abort (message_format=0x2acaefb11e78 "%s:%d: failed assertion `%s`") at ink_error.cc:99
#3  0x00002acaefa9fd11 in _ink_assert (expression=0xa27515 "read_vio.cont != _proxy_ssn", file=0xa27499 "Http2Stream.cc", line=168) at ink_assert.cc:37
#4  0x00000000007f0629 in Http2Stream::send_request (this=0x2acb02a78b80, cstate=...) at Http2Stream.cc:168
#5  0x00000000007e0a9b in rcv_headers_frame (cstate=..., frame=...) at Http2ConnectionState.cc:390
#6  0x00000000007e538e in Http2ConnectionState::main_event_handler (this=0x2acb14bb0798, event=2253, edata=0x2acafc308f60) at Http2ConnectionState.cc:1063
#7  0x000000000066b737 in Continuation::handleEvent (this=0x2acb14bb0798, event=2253, data=0x2acafc308f60) at /home/shinrich/vtrafficserver9/iocore/eventsystem/I_Continuation.h:167
#8  0x00000000007d6906 in send_connection_event (cont=0x2acb14bb0798, event=2253, edata=0x2acafc308f60) at Http2ClientSession.cc:65
#9  0x00000000007da8b4 in Http2ClientSession::do_complete_frame_read (this=0x2acb14bb0490) at Http2ClientSession.cc:570
#10 0x00000000007daf2d in Http2ClientSession::state_process_frame_read (this=0x2acb14bb0490, event=100, vio=0x2acb1b228ab0, inside_frame=false) at Http2ClientSession.cc:628
#11 0x00000000007d9ca8 in Http2ClientSession::state_start_frame_read (this=0x2acb14bb0490, event=100, edata=0x2acb1b228ab0) at Http2ClientSession.cc:482
#12 0x00000000007d8859 in Http2ClientSession::main_event_handler (this=0x2acb14bb0490, event=100, edata=0x2acb1b228ab0) at Http2ClientSession.cc:352
#13 0x000000000066b737 in Continuation::handleEvent (this=0x2acb14bb0490, event=100, data=0x2acb1b228ab0) at /home/shinrich/vtrafficserver9/iocore/eventsystem/I_Continuation.h:167
#14 0x00000000007d9a29 in Http2ClientSession::state_read_connection_preface (this=0x2acb14bb0490, event=100, edata=0x2acb1b228ab0) at Http2ClientSession.cc:462
#15 0x00000000007d8859 in Http2ClientSession::main_event_handler (this=0x2acb14bb0490, event=100, edata=0x2acb1b228ab0) at Http2ClientSession.cc:352
#16 0x000000000066b737 in Continuation::handleEvent (this=0x2acb14bb0490, event=100, data=0x2acb1b228ab0) at /home/shinrich/vtrafficserver9/iocore/eventsystem/I_Continuation.h:167
#17 0x000000000099b159 in read_signal_and_update (event=100, vc=0x2acb1b2288d0) at UnixNetVConnection.cc:83
#18 0x000000000099efa6 in UnixNetVConnection::readSignalAndUpdate (this=0x2acb1b2288d0, event=100) at UnixNetVConnection.cc:1042
#19 0x000000000095b997 in SSLNetVConnection::net_read_io (this=0x2acb1b2288d0, nh=0x2acaf6eb4a20, lthread=0x2acaf6eb0980) at SSLNetVConnection.cc:670
#20 0x00000000009904a0 in NetHandler::process_ready_list (this=0x2acaf6eb4a20) at UnixNet.cc:416
#21 0x0000000000990dc3 in NetHandler::waitForActivity (this=0x2acaf6eb4a20, timeout=60000000) at UnixNet.cc:551
#22 0x00000000009d4915 in EThread::execute_regular (this=0x2acaf6eb0980) at UnixEThread.cc:271
#23 0x00000000009d4b17 in EThread::execute (this=0x2acaf6eb0980) at UnixEThread.cc:332
#24 0x00000000009d3345 in spawn_thread_internal (a=0x2acaf33d9f80) at Thread.cc:92
#25 0x00002acaf18bfea5 in start_thread () from /lib64/libpthread.so.0
#26 0x00002acaf25f69fd in clone () from /lib64/libc.so.6

The problem is that the HttpSM::state_add_to_list() was calling a do_io_read and passing in the continuation associated with the netvc (the Http2ClientSession in this case). That is never the correct thing for a Http2 session. This logic was introduced in PR #7096

+14 -12

0 comment

3 changed files

pr created time in 4 hours

Pull request review commentapache/trafficserver

Add pointer/reference upcast function that is checked in debug builds.

 inkcoreapi void _ink_assert(const char *a, const char *f, int l) TS_NORETURN;  #ifdef __cplusplus }-#endif /* __cplusplus */ -/* workaround a bug in the  stupid Sun preprocessor+/*+Use dbg_dyn_cast() to do pointer/reference dynamic upcasts with checked dynamic_cast in debug builds, and with+static_cast in release (optimized) builds.  Use examples:++class A { public: virtual ~A(); };+class B : public A {};+B * foo(A *a) { return dbg_dyn_cast<B>(a); }+B & foo2(A &a) { return dbg_dyn_cast<B>(a); }+B const & foo3(A const &a) { return dbg_dyn_cast<B const>(a); } -#undef assert-#define assert __DONT_USE_BARE_assert_USE_ink_assert__-#define _ASSERT_H-#undef __ASSERT_H__-#define __ASSERT_H__ */++template <class Derived, class Base>+Derived *+dbg_dyn_cast(Base *b)

The behavior seems more like static cast because it doesn't return nullptr. We can use this as a replacement for static_cast but not dynamic_cast.

ywkaras

comment created time in 4 hours

PR opened apache/trafficserver

Fix double test crash AuTest Crash

I was getting the double test to crash for me fairly consistently with the following stack. This was running with debug enabled. It appears that the captive_action (the action object returned for the open_read and open_write actions) had been canceled from a previous open attempt. Adding logic to the open_write that cleared the cancel bit up from as it does for open_read fixed the issue.

@SolidWallOfCode thinks the issue was introduced by possibility of open write retries in PR #6053

#0  0x00002aac8856e3d7 in raise () from /lib64/libc.so.6
#1  0x00002aac8856fac8 in abort () from /lib64/libc.so.6
#2  0x00002aac85ae40c8 in ink_abort (message_format=0x2aac85b51e78 "%s:%d: failed assertion `%s`") at ink_error.cc:99
#3  0x00002aac85adfd11 in _ink_assert (expression=0xa1507e "captive_action.cancelled == 0", file=0xa14ff8 "HttpCacheSM.cc", line=161) at ink_assert.cc:37
#4  0x0000000000788aaf in HttpCacheSM::state_cache_open_write (this=0x2aacb3086638, event=1109, data=0xffffffffffffb04f) at HttpCacheSM.cc:161
#5  0x000000000066b737 in Continuation::handleEvent (this=0x2aacb3086638, event=1109, data=0xffffffffffffb04f) at /home/shinrich/vtrafficserver9/iocore/eventsystem/I_Continuation.h:167
#6  0x00000000008e5c95 in Cache::open_write (this=0x2aac96cf3990, cont=0x2aacb3086638, key=0x2aac9260a790, info=0x0, apin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP, 
    hostname=0x2aac8d5a8831 "127.0.0.12009http127.0.0.1:2009http://127.0.0.1:2009/", host_len=9) at CacheWrite.cc:1829
#7  0x00000000008b26e6 in CacheProcessor::open_write (this=0xf10d80 <cacheProcessor>, cont=0x2aacb3086638, expected_size=0, key=0x2aac9260a780, request=0x2aacb3085018, old_info=0x0, pin_in_cache=0, 
    type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3254
#8  0x000000000078995d in HttpCacheSM::open_write (this=0x2aacb3086638, key=0x2aac9260a780, url=0x2aacb3085030, request=0x2aacb3085018, old_info=0x0, pin_in_cache=0, retry=true, allow_multiple=false)
    at HttpCacheSM.cc:363
#9  0x00000000007185aa in HttpSM::do_cache_prepare_action (this=0x2aacb3084860, c_sm=0x2aacb3086638, object_read_info=0x0, retry=true, allow_multiple=false) at HttpSM.cc:4723
#10 0x000000000072df04 in HttpSM::do_cache_prepare_write (this=0x2aacb3084860) at HttpSM.cc:4650
#11 0x0000000000725c15 in HttpSM::set_next_state (this=0x2aacb3084860) at HttpSM.cc:7576
#12 0x000000000072465d in HttpSM::call_transact_and_set_next_state (this=0x2aacb3084860, f=0x0) at HttpSM.cc:7301
#13 0x00000000007083d5 in HttpSM::handle_api_return (this=0x2aacb3084860) at HttpSM.cc:1614
#14 0x00000000007080cb in HttpSM::state_api_callout (this=0x2aacb3084860, event=0, data=0x0) at HttpSM.cc:1546
#15 0x000000000071b18f in HttpSM::do_api_callout_internal (this=0x2aacb3084860) at HttpSM.cc:5239
#16 0x000000000072dceb in HttpSM::do_api_callout (this=0x2aacb3084860) at HttpSM.cc:353
#17 0x00000000007246e6 in HttpSM::set_next_state (this=0x2aacb3084860) at HttpSM.cc:7335
#18 0x000000000072465d in HttpSM::call_transact_and_set_next_state (this=0x2aacb3084860, f=0x0) at HttpSM.cc:7301
#19 0x0000000000724c67 in HttpSM::set_next_state (this=0x2aacb3084860) at HttpSM.cc:7380
#20 0x000000000072465d in HttpSM::call_transact_and_set_next_state (this=0x2aacb3084860, f=0x0) at HttpSM.cc:7301
#21 0x00000000007083d5 in HttpSM::handle_api_return (this=0x2aacb3084860) at HttpSM.cc:1614
#22 0x00000000007080cb in HttpSM::state_api_callout (this=0x2aacb3084860, event=0, data=0x0) at HttpSM.cc:1546
#23 0x000000000071b18f in HttpSM::do_api_callout_internal (this=0x2aacb3084860) at HttpSM.cc:5239
#24 0x000000000072dceb in HttpSM::do_api_callout (this=0x2aacb3084860) at HttpSM.cc:353
#25 0x000000000072de74 in HttpSM::setup_cache_lookup_complete_api (this=0x2aacb3084860) at HttpSM.cc:2508
#26 0x000000000070dd0a in HttpSM::state_cache_open_read (this=0x2aacb3084860, event=1103, data=0xffffffffffffb050) at HttpSM.cc:2570
#27 0x000000000070e177 in HttpSM::main_handler (this=0x2aacb3084860, event=1103, data=0xffffffffffffb050) at HttpSM.cc:2612
#28 0x000000000066b737 in Continuation::handleEvent (this=0x2aacb3084860, event=1103, data=0xffffffffffffb050) at /home/shinrich/vtrafficserver9/iocore/eventsystem/I_Continuation.h:167
#29 0x000000000078874e in HttpCacheSM::state_cache_open_read (this=0x2aacb3086638, event=1103, data=0xffffffffffffb050) at HttpCacheSM.cc:133
#30 0x000000000066b737 in Continuation::handleEvent (this=0x2aacb3086638, event=1103, data=0xffffffffffffb050) at /home/shinrich/vtrafficserver9/iocore/eventsystem/I_Continuation.h:167
#31 0x00000000008ce55d in CacheVC::openReadFromWriterFailure (this=0x2aac991a1bd0, event=1103, e=0xffffffffffffb050) at CacheRead.cc:189
#32 0x00000000008cf1f1 in CacheVC::openReadFromWriter (this=0x2aac991a1bd0, event=2, e=0x2aac8a96d4e0) at CacheRead.cc:338
#33 0x000000000066b737 in Continuation::handleEvent (this=0x2aac991a1bd0, event=2, data=0x2aac8a96d4e0) at /home/shinrich/vtrafficserver9/iocore/eventsystem/I_Continuation.h:167
#34 0x00000000009d41a1 in EThread::process_event (this=0x2aac8d1320c0, e=0x2aac8a96d4e0, calling_code=2) at UnixEThread.cc:132
#35 0x00000000009d4765 in EThread::execute_regular (this=0x2aac8d1320c0) at UnixEThread.cc:241
#36 0x00000000009d4aa5 in EThread::execute (this=0x2aac8d1320c0) at UnixEThread.cc:332
#37 0x00000000009d32d3 in spawn_thread_internal (a=0x2aac893d9fc0) at Thread.cc:92
#38 0x00002aac878ffea5 in start_thread () from /lib64/libpthread.so.0
#39 0x00002aac886369fd in clone () from /lib64/libc.so.6
+3 -2

0 comment

1 changed file

pr created time in 5 hours

push eventapache/trafficserver

Susan Hinrichs

commit sha d31e518ba7e0d3ddd2836592939c0b411e637a44

Reactivate accept_no_activity_timeout (#7408)

view details

push time in 5 hours

PR merged apache/trafficserver

Reviewers
Reactivate accept_no_activity_timeout Connection Timeouts

Discussion in the issue. Should also extend one of the autest timeout cases to exercise the accept_no_timeout for at least HTTP/1.x.

This closes #7390.

+131 -2

2 comments

5 changed files

shinrich

pr closed time in 5 hours

issue closedapache/trafficserver

accept_no_activity_timeout seems obsolete but not removed.

Practical tests measuring the behaviour of accept_no_activity_timeout shows that is has no effect as documented.

https://docs.trafficserver.apache.org/en/9.0.x/admin-guide/files/records.config.en.html#proxy-config-http-accept-no-activity-timeout

The timeout interval in seconds before Traffic Server closes a connection that has no activity.


A test such as: time telnet localhost 80

Show that the parameter that affects this timeout is: proxy.config.http.default_inactivity_timeout

There was a suggestion that the parameter proxy.config.http.transaction_no_activity_timeout_in may affect it also. However in practical tests I cannot achieve this.

It doesn't look as though it's possible to remain in the state where this parameter is in effect within the state machine for more than an instant. I cannot begin to imagine the failure type that would cause this to occur, and be required.

There is an intent/architectural question about whether a client that has never submitted data should have a different timeout than one that has previously been active. Personally I would use this if available, being more aggressive to this client type.

At the very least: This parameter and references to it should be removed, and descriptions of default_inactivity_timeout updated to include this case. However, I'm not certain this makes sense as the default timeout, being the least specific, is often longer. The use case for accept_no_activity_timeout is typically one of the most agressive.

closed time in 5 hours

c-taylor

PR opened apache/trafficserver

Reviewers
Call constructors and destructors for H1/2 Session/Transaction via ClassAllocator Cleanup

#6241 enabled to call constructors which receive arguments, and destructors.

+12 -18

0 comment

12 changed files

pr created time in 5 hours

pull request commentapache/trafficserver

Use EVP API instead of legacy APIs (s3 auth)

This is on hold because there's a discussion about dynamic context object allocation on #7447. We may prefer to use the old API as long as it's available.

maskit

comment created time in 5 hours

PR opened apache/trafficserver

Reviewers
Rollback LAZY_BUF_ALLOC remove in HttpTunnel HTTP

This is partial revert of b4f8d1c2ca5895c81dd7137b11620e421c1e8582 which removed LAZY_BUF_ALLOC. The MIOBuffer allocation change is fine, but the change in the HttpTunnel.cc might be a problem.

At the beginning of HttpTunnel::consumer_reenable(HttpTunnelConsumer *c), the change is below

-  if (p && p->alive
- #ifndef LAZY_BUF_ALLOC
-       && p->read_buffer->write_avail() > 0
- #endif
+  if (p && p->alive && p->read_buffer->write_avail() > 0

https://github.com/apache/trafficserver/pull/5029/files#diff-fa7d3bd44e7a4b62e39f491b2cfa19b9f93b9fe7e20bdae1bcccd251b0583342L1275-L1278

LAZY_BUF_ALLOC was defined prior to the commit, so the change is equivalent to

- if (p && p->alive)
+ if (p && p->alive && p->read_buffer->write_avail() > 0)

This might change the behavior of the HTTP throttling when the read_buffer is full.

+2 -2

0 comment

1 changed file

pr created time in 6 hours

push eventapache/trafficserver

Masakazu Kitajo

commit sha fa603fd8c7878fe452218e45482fb4b5a0a726f5

Tidy up session/transaction destruction process (#7571)

view details

push time in 7 hours

PR merged apache/trafficserver

Tidy up session/transaction destruction process Cleanup Core

The primary goal is to call destructors of ProxySession, ProxyTransaction and their subclasses.

ProxySession Made free() pure virtual function -- ProxySession does not know how to free itself and current code does not free. Added destructor -- The code originally in free() is now in the destructor.

ProxyTransaction Removed destroy() -- I don't see any reasons to have this as a normal function. The existence is confusing. Added destructor -- The code originally in destroy() is now in the destructor

Http1ClientSession Added destructor -- To call ProxySession's destructor automatically. The normal destruction process is easier to follow. Changed a function name to call -- See Http1Transaction.

Http1ServerSession Added destructor -- Just for consistency. Added free() -- It does nothing because it's freed in destroy() unlike Http1ClientSession.

Http1Transaction Renamed destroy() to reset() -- Http1Transaction::destroy() didn't actually destroy itself, but reset its state.

Http2ClientSession Added destructor -- To call ProxySession's destructor automatically.

Http2Stream Converted destroy() to the destructor Unified the process to destroy itself

Http3Session Added free() -- It has never been freed.

+127 -122

4 comments

17 changed files

maskit

pr closed time in 7 hours

PR opened omniosorg/omnios-build

setuptools-rust: update to 0.12.0

setuptools-rust: update to 0.12.0

+24 -24

0 comment

10 changed files

pr created time in 7 hours

PR opened omniosorg/illumos-omnios

Update Intel microcode to 20210216
+3 -3

0 comment

5 changed files

pr created time in 7 hours

pull request commentapache/trafficserver

Add failed state to hostdb to better track failing origins

[approve ci]

shinrich

comment created time in 9 hours

issue commentapache/trafficserver

Sporadic crash and core dump in Mutex_trylock

@masaori335 - thank you. We saw many http2 changes in 8.1.x. We will update if the issue continues.

bdgranger

comment created time in 12 hours

push eventcirconus/docs

Eric Sproul

commit sha 8dbcac8a911e74e495d55fd16998b5494d21e00e

Release notes 20210308 (#170)

view details

push time in 13 hours

PR merged circonus/docs

Release notes 20210308
+130 -0

0 comment

1 changed file

esproul

pr closed time in 13 hours

PR opened omniosorg/omnios-extra

smartmontools: set BUILD_INFO
+3 -1

0 comment

1 changed file

pr created time in 14 hours

push eventomniosorg/omnios-build

Andy Fiddaman

commit sha 5ded33df54908e42062d0bd070481f7a0d2ef322

Update bhyve firmware to the new upstream stable202102 tag

view details

Dominik Hassler

commit sha 4ed683d9f839648f17957fdd4a33b310e6856f88

Merge pull request #2239 from citrus-it/bhyve Update bhyve firmware to the new upstream stable202102 tag

view details

push time in 14 hours

PR merged omniosorg/omnios-build

Update bhyve firmware to the new upstream stable202102 tag package update

Update bhyve firmware to the new upstream stable202102 tag

+2 -2

0 comment

1 changed file

citrus-it

pr closed time in 14 hours

push eventomniosorg/kayak

Andy Fiddaman

commit sha 0bf72f63811ffaec756546dc871bac2be5453f67

Add bhhwcompat to the installer miniroot

view details

Dominik Hassler

commit sha 0a961e4aab05b76b193cfe20f4ade69a4b4ac40a

Merge pull request #196 from citrus-it/bhhwcompat Add bhhwcompat to the installer miniroot

view details

push time in 14 hours