Hi,
This adds a missing include of limits.h in compat.c.
I don’t have git send-email set up so I hope an attachment from
Thunderbird is fine.
Best,
Ruud
Hello,
On 2020-05-19 23:18:19 +0200, Ruud van Asseldonk wrote:
> This adds a missing include of limits.h in compat.c.> > I don’t have git send-email set up so I hope an attachment from Thunderbird> is fine.
Completely fine, thank you for taking the time to report this :) I would
just like to as, could you provide more information about your platform?
Like OS, compiler, their versions etc.? I would ideally like to add it
to the automated builds to make sure it does not break again.
Thank you,
W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
> Completely fine, thank you for taking the time to report this :)
Great to hear, thanks!
> I would> just like to ask, could you provide more information about your platform?> Like OS, compiler, their versions etc.? I would ideally like to add it> to the automated builds to make sure it does not break again.
I am building in an environment managed by Nix (https://nixos.org/nix)
on Linux. Currently that is using GCC 9.3.0. On Linux you can recreate
this exact environment with a checkout of
https://github.com/NixOS/nixpkgs by running
nix-shell --pure --attr acme-client path/to/nixpkgs/default.nix
Acme-client-portable is packaged in Nixpkgs, and the above command
starts a shell with PATH set up such that all dependencies of the
package (including build tools) are available, and your normal
system-wide build tools are not on the PATH. In that shell, in a
checkout of acme-client-portable, this will reproduce the compile error:
autoreconf --install
./configure
make
I hope this helps, let me know if there is anything I can do to help set
up the automated builds.
Best,
Ruud
Hello,
On 2020-05-20 23:17:15 +0200, Ruud van Asseldonk wrote:
> [..]>> I hope this helps, let me know if there is anything I can do to help set up> the automated builds.
So I think I've managed to put together the automated build, you can
take a look here:
https://git.sr.ht/~graywolf/acme-client-portable/tree/nix-build/.builds/nixpkgs.yml
However, there are two issues:
1. It needs to be run using sudo, or I get this error (
https://builds.sr.ht/~graywolf/job/214809 ):
+ nix-shell --pure --attr acme-client /home/build/nixpkgs/default.nix --run 'autoreconf -i'
error: getting status of /nix/var/nix/daemon-socket/socket: Permission denied
Is there a way around that? I would prefer not to run the build as a
root.
2. Even on successful builds ( https://builds.sr.ht/~graywolf/job/217076
) there is a warning:
+ sudo nix-shell --pure --attr acme-client /home/build/nixpkgs/default.nix --run 'autoreconf -i'
warning: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I), at (string):1:9; will use bash from your environment
I do not use nix, so I'm not really sure how to solve this (and if it is
something important).
It would be cool if you would manage to find some time to help me with
this.
Thanks,
W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Hi,
Thanks so much for looking in to this!
> 1. It needs to be run using sudo, or I get this error (> https://builds.sr.ht/~graywolf/job/214809 ):> > + nix-shell --pure --attr acme-client /home/build/nixpkgs/default.nix --run 'autoreconf -i'> error: getting status of /nix/var/nix/daemon-socket/socket: Permission denied> > Is there a way around that? I would prefer not to run the build as a> root.
It looks like the Nix package for Alpine adds a "nix" group that you
need to be a member of:
https://git.alpinelinux.org/aports/tree/testing/nix/APKBUILD#n90. Is it
possible to add the build user to that group?
> 2. Even on successful builds ( https://builds.sr.ht/~graywolf/job/217076> ) there is a warning:> > + sudo nix-shell --pure --attr acme-client /home/build/nixpkgs/default.nix --run 'autoreconf -i'> warning: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I), at (string):1:9; will use bash from your environment> > I do not use nix, so I'm not really sure how to solve this (and if it is> something important).
I also get this locally, it is not a problem. When you use Nix as your
main package manager, it expects a Nixpkgs somewhere in $NIX_PATH that
it uses as default. (It plays a role similar to the package index for
Apt, updating Nixpkgs to a more recent commit is like apt update.)
Nix-shell starts Bash, and it tries to use the Bash packaged in Nixpkgs
first, and it falls back to the system Bash with the above warning.
One way to remove the warning is to run with the NIX_PATH=/home/build
environment variable set. Then Nix will find the nixpkgs checkout in
/home/build, and use Bash from there.
About the Nixpkgs clone: you can use master, but sometimes things are
broken on master. Testing against master is like testing against Debian
Unstable. There are other branches in
https://github.com/NixOS/nixpkgs-channels that are verified more
extensively. The nixpkgs-unstable branch is a bit more like Debian
Testing, it passes CI checks. There are also release branches like
nixos-20.03, which fork from unstable at every release and then only get
security updates, similar to a Debian Stable release.
Best,
Ruud
Hey,
On 2020-05-24 12:00:39 +0200, Ruud van Asseldonk wrote:
> It looks like the Nix package for Alpine adds a "nix" group that you need to> be a member of:> https://git.alpinelinux.org/aports/tree/testing/nix/APKBUILD#n90. Is it> possible to add the build user to that group?
In the end it was not as trivial as I would hope so, but I've got it
working.
> > 2. Even on successful builds ( https://builds.sr.ht/~graywolf/job/217076> > ) there is a warning:> > > > + sudo nix-shell --pure --attr acme-client /home/build/nixpkgs/default.nix --run 'autoreconf -i'> > warning: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I), at (string):1:9; will use bash from your environment> > > > I do not use nix, so I'm not really sure how to solve this (and if it is> > something important).> > I also get this locally, it is not a problem. When you use Nix as your main> package manager, it expects a Nixpkgs somewhere in $NIX_PATH that it uses as> default. (It plays a role similar to the package index for Apt, updating> Nixpkgs to a more recent commit is like apt update.) Nix-shell starts Bash,> and it tries to use the Bash packaged in Nixpkgs first, and it falls back to> the system Bash with the above warning.
Thanks, I will just ignore this one.
> About the Nixpkgs clone: you can use master, but sometimes things are broken> on master. Testing against master is like testing against Debian Unstable.> There are other branches in https://github.com/NixOS/nixpkgs-channels that> are verified more extensively. The nixpkgs-unstable branch is a bit more> like Debian Testing, it passes CI checks. There are also release branches> like nixos-20.03, which fork from unstable at every release and then only> get security updates, similar to a Debian Stable release.
Thanks for telling me this, I had no idea :/ I've decided to use the
nixpkgs-unstable branch, it's a bit shame there is not a branch (or tag)
for "last stable" which I could just use.
Also, I've released 1.0.1 which includes your patch and builds fine in
the remote build using nixpkgs. Let me know if you run into any more
issues.
W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
> In the end it was not as trivial as I would hope so, but I've got it> working.
Looking at nixpkgs.yml, it indeed looks like a bit of a hassle. In
https://man.sr.ht/builds.sr.ht/compatibility.md#nixos it says that NixOS
is actually supported natively, perhaps that will allow a simpler config?
> Also, I've released 1.0.1 which includes your patch and builds fine in> the remote build using nixpkgs. Let me know if you run into any more> issues.
Awesome, thanks for the quick release!
Best,
Ruud
On 2020-05-24 23:35:45 +0200, Ruud van Asseldonk wrote:
> > > In the end it was not as trivial as I would hope so, but I've got it> > working.> > Looking at nixpkgs.yml, it indeed looks like a bit of a hassle. In> https://man.sr.ht/builds.sr.ht/compatibility.md#nixos it says that NixOS is> actually supported natively, perhaps that will allow a simpler config?
Hm, I should learn to RTFM. Thank you, the manifest is much easier on
the eyes now :)
W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.