I committed this in r353331.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Nov 22 2019
In D22193#488245, @trasz wrote:FWIW, grepping for that pattern only brings up the one hit Warner has already mentioned, and it's already under #ifdef illumos:
% grep -r '%ss%d' * cddl/contrib/opensolaris/cmd/zpool/zpool_vdev.c: (void) snprintf(buf, sizeof (buf), "%ss%d", path, slice);
- Add OpenNMS files.
- Add a service file.
Further patches have to be applied to remove the errors.
- using ctf_flight_size instead of tcp_compute_pipe in rack
In D22425#491696, @dim wrote:@pkubaj if you can't commit it, I will be happy to do so.
- Fix tests. Now all pass.
- Improve pkg-descr.
Added checking if pointer to reply structure is not NULL
Shows how much I know about sysctls :-)
Please upload diff with full context.
Ping.
(Note that the refactor is not really needed, but I don't have strong opinion here).
- renaming unused flags
Still looks ok to me. I had a couple of comments.
Since replay field is optional, I think you need add the check that it is not NULL.
In D22492#491936, @adamw wrote:Sorry Alan, this was breaking the build on 11 so I committed it.
Sorry Alan, this was breaking the build on 11 so I committed it.
Always install man pages, but use USE=makeinfo
Normally I push hard against avoidable dependencies, but I think the right thing to do here is to make makeinfo non-optional. Major gnupg dependencies (like gnutls, libgcrypt, m4, nettle, and autoconf) depend on texinfo, so there's really nothing to gain from hiding it behind a MANPAGES option (which is normally used when dependencies are ludicrous, like pandoc or whatever nonsense python thing cmake uses).
The bucket_push and item_dtor refactors look reasonable. I'm not super familiar with this area of code.
Drop NO_BACKWARD_COMPATIBILITY shim.
This review is born out of frustration with having to manually build git on our systems where we need git-subversion and prefer to use pkg in general.
Check NULL pointers explicitly.
Looks reasonable to me.
I think the proposed change actually does change the code behavior slightly.
In D22487#491857, @darkfiberiru_gmail.com wrote:Trying to understand your bootp comment in summary. Are you pointing at no support yet for https://tools.ietf.org/html/rfc5970 or that there just isn't a ipv6 option for defining boot info like bootp had?
In D22474#491849, @imp wrote:Looks good to me. Other commands use different flags to run in foreground, though. IT's inconsistent...
Nov 21 2019
Trying to understand your bootp comment in summary. Are you pointing at no support yet for https://tools.ietf.org/html/rfc5970 or that there just isn't a ipv6 option for defining boot info like bootp had?