~sircmpwn/public-inbox

General catch-all for patches, questions, and discussions for sircmpwn's projects that don't have their own mailing list.

When posting patches to this list, please edit the [PATCH] line to include the specific project you're contributing to, e.g.

[PATCH scdoc v2] Add thing to stuff

Patches

8 3

Build fails on non-glibc systems

Piotr Wójcik
Details
Message ID
<e522a087-ffea-cf34-5eb1-6f94bb03c67a@tlen.pl>
Download raw message
strptime("%s" is glibc extension, so build fails on musl system when SOURCE_DATE_EPOCH is set. Could it be used standard compliant way shown on https://reproducible-builds.org/docs/source-date-epoch/#c ?
Details
Message ID
<20181231175550.GB1524@homura.localdomain>
In-Reply-To
<e522a087-ffea-cf34-5eb1-6f94bb03c67a@tlen.pl> (view parent)
Download raw message
Can you send a patch?
Details
Message ID
<20190101151616.GC1621@homura.localdomain>
In-Reply-To
<20181231175550.GB1524@homura.localdomain> (view parent)
Download raw message
On 2019-01-01  3:44 PM, Piotr Wójcik wrote:
> > Can you send a patch?
> 
> Sorry, I am not that much interested to make it work. Just reported
> issue with updating package for distro. I can test though.
> 
> Previously linked code is nearly drop-in replacement for strptime
> call.

This is the wrong attitude to have about open source. This is a
community effort, and you should be willing to write patches -
especially ones as small as this, and doubly so if you work on a Linux
distribution. Distro maintainers should know better.

scdoc is a small, simple, and easy to understand POSIX C codebase.
You've probably already spent as much time on this issue as it would
require to make a patch.
Sam Whited
Details
Message ID
<1546357250.1158212.1622855352.23B58E78@webmail.messagingengine.com>
In-Reply-To
<20190101151616.GC1621@homura.localdomain> (view parent)
Download raw message
On Tue, Jan 1, 2019, at 09:16, Drew DeVault wrote:
> > Sorry, I am not that much interested to make it work. Just reported
> > issue with updating package for distro. I can test though.
> > 
> > Previously linked code is nearly drop-in replacement for strptime
> > call.
> 
> This is the wrong attitude to have about open source. This is a
> community effort, and you should be willing to write patches -
> especially ones as small as this, and doubly so if you work on a Linux
> distribution. Distro maintainers should know better.
> 
> scdoc is a small, simple, and easy to understand POSIX C codebase.
> You've probably already spent as much time on this issue as it would
> require to make a patch.

Many (most?) people may not have the time or resources to figure out an open source project to contribute a small patch; even one as simple as this. We don't know their motivations or technical capabilities, they may not know the language or tooling, or they may not be proficient in the contribution workflow (eg. if they've never used Git from the command line before), all of these things can make what seems like a simple patch very time consuming, even if they already know the exact code that needs to change.

However, those users can still find bugs and contribute issues; it's still a valuable service. Demanding more free work (even if you think it's only a small thing) will only scare off these contributors and bugs like this will go unnoticed.

—Sam
Details
Message ID
<20190101154351.GD1621@homura.localdomain>
In-Reply-To
<1546357250.1158212.1622855352.23B58E78@webmail.messagingengine.com> (view parent)
Download raw message
On 2019-01-01  9:40 AM, Sam Whited wrote:
> Many (most?) people may not have the time or resources to figure out
> an open source project to contribute a small patch; even one as simple
> as this. We don't know their motivations or technical capabilities,
> they may not know the language or tooling, or they may not be
> proficient in the contribution workflow (eg. if they've never used Git
> from the command line before), all of these things can make what seems
> like a simple patch very time consuming, even if they already know the
> exact code that needs to change.

This is only true once. If they put in the time to learn these tools,
they'll have learned valuable skills _and_ seen the bug fixed. I'm
always willing to spend 10x more of my own time helping a new
contributor learn the ropes than I'd spend fixing the bug myself.

> However, those users can still find bugs and contribute issues; it's
> still a valuable service. Demanding more free work (even if you think
> it's only a small thing) will only scare off these contributors and
> bugs like this will go unnoticed.

They're demanding free work of me, though. It's a two-way street. I
don't believe learning to write and contribute simple patches is out of
anyone's reach, and instead of fixing easy problems like this I choose
to use them as a means of inviting new contributors into the open source
community.
Sam Whited
Details
Message ID
<1546357745.1159972.1622862064.2B5BCB21@webmail.messagingengine.com>
In-Reply-To
<20190101154351.GD1621@homura.localdomain> (view parent)
Download raw message
On Tue, Jan 1, 2019, at 09:43, Drew DeVault wrote:
> This is only true once. If they put in the time to learn these tools,
> they'll have learned valuable skills _and_ seen the bug fixed. I'm
> always willing to spend 10x more of my own time helping a new
> contributor learn the ropes than I'd spend fixing the bug myself.

This is a good attitude to have as a maintainer; thanks for being willing to do that for people. However, they may still have a real job, not be a developer at all and just know a bit about QA and packaging, be busy, or have some other reason they can't take you up on your generous offer.

> They're demanding free work of me, though. It's a two-way street. I
> don't believe learning to write and contribute simple patches is out of
> anyone's reach, and instead of fixing easy problems like this I choose
> to use them as a means of inviting new contributors into the open source
> community.

Maybe I'm missing some context, but that sounded like a polite bug report, not a demand.
I'm not suggesting you shouldn't invite them to contribute a patch; your first email was fine. Just that after they politely declined you shouldn't accuse them of having a bad attitude. Not everyone wants to provide free work to your commercial project, even if it is generously open source.

We don't know why they don't want to provide free work, and they weren't demanding that you immediately fix something as so many entitled open source issue reporters do. They were just letting you know about a potential bug in a polite way; please don't shoot them down and scare them off. I would possibly also like to use this on a muscl based system eventually possibly, so it would be nice if people were reporting bugs, even if they can't fix them themselves for whatever reason.

—Sam
Details
Message ID
<20190101160409.GF1621@homura.localdomain>
In-Reply-To
<1546357745.1159972.1622862064.2B5BCB21@webmail.messagingengine.com> (view parent)
Download raw message
On 2019-01-01  9:49 AM, Sam Whited wrote:
> This is a good attitude to have as a maintainer; thanks for being
> willing to do that for people. However, they may still have a real
> job, not be a developer at all and just know a bit about QA and
> packaging, be busy, or have some other reason they can't take you up
> on your generous offer.

I have a "real job", too, I work on FOSS in my spare time. I can hold
someone's hand through the patch authoring and submission process in
maybe 20 minutes. Almost anyone can make that time, it's just a matter
of putting forth the effort.

I was harder on this person than I usually would be because they're
working with a Linux distro, and I expect better of distro maintainers.
Distro maintainers should be fostering a good relationship with their
upstreams and this isn't the right attitude for that.

Regardless, I stated my opinion politely. You can choose to disagree
with it, but I was cordial nonetheless.

> Just that after they politely declined you shouldn't accuse them of
> having a bad attitude.  Not everyone wants to provide free work to
> your commercial project, even if it is generously open source.

scdoc is not a commercial project, it's largely unrelated to sr.ht other
than being hosted here.

https://git.sr.ht/~sircmpwn/scdoc

I take bug reports on sr.ht more seriously as an obligation to paying
customers, and don't have the same expectations of my users here as I do
for most of my other projects.

In this case, scdoc is free software in both senses of the word. This
person is expecting me to do free (as in beer) work for them.

> We don't know why they don't want to provide free work, and they
> weren't demanding that you immediately fix something as so many
> entitled open source issue reporters do.

This person is still showing the same entitlement, they're just being
more subtle about it. I work with _a lot_ of open source projects. You
can read this sort of thing after a while. You have to nip this attitude
in the bud or it just turns into the entitled junk we're all regrettably
familiar with.

[PATCH scdoc v1] Don't use a GNU-extension for $SOURCE_DATE_EPOCH parsing

Silvan Jegen
Details
Message ID
<20190102000149.18450-1-s.jegen@gmail.com>
In-Reply-To
<20190101160409.GF1621@homura.localdomain> (view parent)
Download raw message
Patch +28 -11
Code gratefully copied from the link below.

https://reproducible-builds.org/docs/source-date-epoch/#c
---
Took me way longer than expected but I think this should work.

I couldn't get cc to pick-up the strerror declaration from <string.h>
for some reason so I ended up declaring the function prototype like it
is being done for strstr. Not sure what I missed there...

 src/main.c | 39 ++++++++++++++++++++++++++++-----------
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/src/main.c b/src/main.c
index 645d521..d49a202 100644
--- a/src/main.c
+++ b/src/main.c
@@ -1,6 +1,8 @@
 #define _XOPEN_SOURCE 600
 #include <assert.h>
 #include <ctype.h>
+#include <errno.h>
+#include <limits.h>
 #include <stdbool.h>
 #include <stdio.h>
 #include <stdlib.h>
@@ -11,6 +13,7 @@
 #include "util.h"
 
 char *strstr(const char *haystack, const char *needle);
+char *strerror(int errnum);
 
 static int parse_section(struct parser *p) {
 	str_t *section = str_create();
@@ -67,23 +70,37 @@ static void parse_preamble(struct parser *p) {
 	str_t *extras[2] = { NULL };
 	int section = -1;
 	uint32_t ch;
+	time_t date_time;
 	char date[256];
 	char *source_date_epoch = getenv("SOURCE_DATE_EPOCH");
 	if (source_date_epoch != NULL) {
-		struct tm source_date_epoch_tm;
-		char *ret = strptime(source_date_epoch, "%s", &source_date_epoch_tm);
-		if (ret == NULL || *ret != '\0') {
-			fprintf(stderr,
-					"Error: $SOURCE_DATE_EPOCH is set but malformed.\n");
-			exit(1);
+		unsigned long long epoch;
+		char *endptr;
+		errno = 0;
+		epoch = strtoull(source_date_epoch, &endptr, 10);
+		if ((errno == ERANGE && (epoch == ULLONG_MAX || epoch == 0))
+				|| (errno != 0 && epoch == 0)) {
+			fprintf(stderr, "Environment variable $SOURCE_DATE_EPOCH: strtoull: %s\n", strerror(errno));
+			exit(EXIT_FAILURE);
 		}
-		strftime(date, sizeof(date), "%F", &source_date_epoch_tm);
+		if (endptr == source_date_epoch) {
+			fprintf(stderr, "Environment variable $SOURCE_DATE_EPOCH: No digits were found: %s\n", endptr);
+			exit(EXIT_FAILURE);
+		}
+		if (*endptr != '\0') {
+			fprintf(stderr, "Environment variable $SOURCE_DATE_EPOCH: Trailing garbage: %s\n", endptr);
+			exit(EXIT_FAILURE);
+		}
+		if (epoch > ULONG_MAX) {
+			fprintf(stderr, "Environment variable $SOURCE_DATE_EPOCH: value must be smaller than or equal to %lu but was found to be: %llu \n", ULONG_MAX, epoch);
+			exit(EXIT_FAILURE);
+		}
+		date_time = epoch;
 	} else {
-		time_t now;
-		time(&now);
-		struct tm *now_tm = localtime(&now);
-		strftime(date, sizeof(date), "%F", now_tm);
+		date_time = time(NULL);
 	}
+	struct tm *date_tm = localtime(&date_time);
+	strftime(date, sizeof(date), "%F", date_tm);
 	while ((ch = parser_getch(p)) != UTF8_INVALID) {
 		if ((ch < 0x80 && isalnum(ch)) || ch == '_' || ch == '-' || ch == '.') {
 			int ret = str_append_ch(name, ch);
-- 
2.20.1

Re: [PATCH scdoc v1] Don't use a GNU-extension for $SOURCE_DATE_EPOCH parsing

Details
Message ID
<20190102000923.GA18959@homura.localdomain>
In-Reply-To
<20190102000149.18450-1-s.jegen@gmail.com> (view parent)
Download raw message
Fixed up the lines which were >80 cols and pushed:

To git.sr.ht:~sircmpwn/scdoc
   2e2ccda..599a615  master -> master

Thank you!