Build scripts are fragile (wrong arch in systemd-nspawn) #325
Comments
|
Interesting. On my system (ubuntu-16.04-desktop-amd64.iso), What is your system? |
|
It is Debian Sid/Unstable
s3nt fr0m a $martph0ne, excuse typ0s
…On 06-Jan-2017 21:05, "probonopd" ***@***.***> wrote:
Interesting. On my system (ubuntu-16.04-desktop-amd64.iso),
***@***.***:~$ uname -p
x86_64
***@***.***:~$ uname -m
x86_64
What is your system?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#325 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAD_yJxgit3zr9xCVBlBKTImGhw0YkTPks5rPl8ugaJpZM4LczJN>
.
|
|
I forgot to add that there are git cloning issues too. Can you please change them to plain git urls ? |
|
@rickysarraf looks like you are running this in a LXC container? Could it be that your SSL CA certs are missing? And possibly LXC mixes up the uname output? |
|
Not LXC, but systemd-nspawn. The name got stuck because I was using lxc before nspawn came. The uname output is from bare machine. My RPi, my cloud instance and my secondary machine; all have the same output. It could very well be that this is a bug in the Debian package, and something Ubuntu may have detected and fixed. On the other hand, the manpage mentions a different story. I think, when using https, github expects you to have an account configured. And that error may be misleading, because I get the same message over http too. From a distribution packaging point of view, the current build will not work. It is mixing up sources from different locations. It expects that network is available, something which is disabled in build environments. Perhaps you should break out external sources (git submodules) into a separate automated script or document. And let the main build script be restricted to a Makefile only, which should do the job of compiling the sources and installation of the binaries. |
|
What are you trying to achieve in the end? |
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Sat, 2017-01-07 at 02:19 -0800, probonopd wrote:
What are you trying to achieve in the end?
This is feedback for your build scripts. That they are fragile. They work for
one use case, which is the most common one. Perhaps the reason why it wasn't
reported to you before.
As you may have guessed, I have no clue about how distribution packaging
works, and yes, my build scripts fetch things from various places and assume
that the build system is online. In which scenarios would that be a problem?
I can speak on what is the case in Debian. I'm not sure about other
distributions. ON Debian, on the buildd infrastructure, network access is
disabled. And there are good reasons to do that.
Your git submodules are just defined as a git repository. It works right now
because squashfs-tools is a forked one, which you control. And squashfuse is a
similar repo. What happens when that repo diverges.
But as a distribution, where point releases are preferred, this doesn't fit
well. Not that we don't pick projects solely maintained in git, but in such
cases, that is the only factor. Other dependencies are standardized.
See, for example: https://tracker.debian.org/pkg/perf-tools-unstable
for which, we pick the sources from:
https://github.com/brendangregg/perf-tools
who doesn't do releases either.
Now in Debian, we already have squashfs-tools available. So, it makes no sense
to carry another set of squashfs-tools sources. For one, it is duplication, but
otherwise too, now there are 2 targets to track (for security).
Note: I see you mention that squashfs-tools development stalled. In cases like
this, it makes more sense to import those sources into your tool itself.
Anyways, this was feedback from my initial interaction. I know the whole idea of
the project is to provide an easier distribution mechanism but for the base
tools (appimaged, appimagetool etc), having a better build and release structure
will be better.
- --
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlhxLXQACgkQpjpYo/Lh
dWk1dRAAp+LA2OHOg9m0jwieqz7CCJxsBhOUjXZLHPW2Tkb6KH8vO8zlni6ua6Jf
qx5WKUSIMWct8qwNQYOMCPiuI2fRuT2G+H13UwiXzMTsjsOtKDpkqz5ckihdCag3
u+DHFYyevPE/79IYJCeIMt0sVh2ldfOokWldLukOgMELsasoqaItS8A1RVNH4PUU
iNTKB1fYZt11Ma0IN5EiWhHmzIVJjH6suOn/vzUo23hfCs2H4QoHs6PVs2L/JzUS
CdAhbKUGBA68rzCMXOSCxJT2yYidMn/F0Px2ubm8sofARWSKP2dv3vsizJDAzQBX
EXW9Ud836PbIkoIsgVAGpY4HtU0MjGNcVOnmqRFCDVBoKZXRg+jw1DE0KFtv9U0R
V3cf5K4rpKLnwRjHhLcpBaxJaCXOqXVrWXX20sRysT2ICB7RjdLJPtP8JD2E/Qhb
/+ws2/LiGURMBhPmVwHf5HSUkjuJ1VJkltTypUELs626OgvwCYymN75oUhaP0q8e
Wcwrnk4Cyn2VN2Que6OS7FmdFME2G/6aQakJ0wXSzNuMjrn/US7kKE0cuqogtSnw
16UqBxjp5beFp4rqyMwPKpKCvlEtpURpKlu04RykBw4RPsB/sBtHtO2MtDY09jqP
hxeUY0CWQ3hMxpRBLeJwj18XYgFBwcSr9iVjEtM4UNB+eJi5n4w=
=SLzN
-----END PGP SIGNATURE-----
|
|
Thanks for your feedback Ritesh. It is appreciated. Still learning these things. |
I have opened a separate issue about generating a native debian package for appimaged. @rickysarraf please join the discussion in https://github.com/probonopd/AppImageKit/issues/339. |
probonopd
changed the title
|
Also see the RPM spec file used for OBS: https://build.opensuse.org/package/view_file/OBS:AppImage/AppImageKit/appimagetool.spec?expand=1 |
|
All this might be fixed when #408 is implemented. But don't expect that too soon, it's quite some work. |
|
We have a CMake build infrastructure, which provides reliable, incremental builds. There is no longer a need to use |
Hello Simon,
The build scripts (install-build-deps.sh) seem to be using the wrong switch the determine the architecture, which results in build failure.
The text was updated successfully, but these errors were encountered: